Со временем накопилось всяких ньюансов, которые нужно не забыть, когда работаешь Project Manager и нужно довести проект до успешного релиза и предоставить клиенту результат.
Планирование архитектуры
Если у клиента нет спецификации, по которой он хочет разрабатывать проект, тогда нужно составить ее самум. Чтобы понять, что клиент хочет, с ним нужно несколько раз поговорить. Услышать его идею, проверить как это работает и потом уточнить детали. Желательно все записать и этот документ уже обсуждать с клиентом на предмет реализации.
Следующие действия помогают составить правильную архитекруту.
- Нарисовать макеты страниц
- Расписать роли пользователей и разделить доступ (кто что видит)
- Расписать сценарии для каждой роли пользователей с последовательностью страниц, которые нужно пройти для выполнения того или иного сценария
- Утвердить все с заказчиком
- Спроектировать базу данных (нарисовать таблицы, поля и связи)
Процесс разработки
- Выбрать фреймворк, на котором команда или разработчик смогут разрабатывать (желательно, чтобы был опыт у Тех Лида, а лучше у всех команды). Это верно для любого языка программирования, который вы будете использовать;
- Использовать пакетный менеджер (лучше использовать проверенные кем то библиотеки);
- Использовать миграции для создания базы данных и внесения изменений. Вариант базы данных выбирается под задачи. Мне обычно хватает реляционных
- Использовать репозиторий для хранения кода: https://bitbucket.org/product Тут можно создать закрытый репозиторий и дать доступ 5-ти до человек. Можно и https://github.com. Создать для кода как минимум две ветки:
- master – тут должен быть рабочий код, который уже на продакшине
- dev – ветка в которой разрабатываются новые фичи
- Для кода нужно писать unit-tests:
- Логика такая, что нужно писать тесты:
- на все функции моделей, которые работают с базой данных.
- на все функции, которые отдают данные для фронтенда
- обязательно на все функции, которые считают деньги.
- Тесты запускаются на отдельной базе данных, с подготовленными данными. Тесты запускаются после добавления новых фич и перед тем, как запушить все в репозиторий.
- Разработчик пишет новые тесты на те функции, которые он создает.
- Логика такая, что нужно писать тесты:
- Vagrantup – разрабатывать нужно в Vagrante – это виртуальная машина, которая позволяет хранить конфигурацию в одном файле в проекте в репозитории. Настройка виртуальной машины, должна быть такой же как и настройка живого сервера.
- Сервера
- Нужно иметь как минимум два сервера
- staging – сервер идентичный по настройкам и размерам живому, на котором тестируются новый функционал и изменения.
- live – сервер с живым сайтом.
- root – управляющий сервер, на котором будет запущен мониторинг и система логирования.
- Для живого сервера нужно базу держать отдельно от кода, чтобы можно было бекапить базу отдельно и если фронтенд упадет – быстро поднять новый или даже два.
- Сервис рассылки почты, чтобы можно было хранить и проверить письма которые рассылаются пользователям.
- Нужно иметь как минимум два сервера
- Логирование и мониторинг – на отдельном сервере нужно поставить систему, например
- Senrty – это локальный сервер логов. В коде проекта отдельно прописывается отправка логово в этот серве. Можно разделать логи с живого сервера и логи с сервера разработчиков.
- NewRelic – онлайн сервер мониторинга. Он считает нагрузку на страницы, на базу данных. Есть бесплатная версия, которая показывает общую картину.
Документация
- Документации должно быть две.
- Техническая спецификация – план по разработке системы, где описана главная задача и модули системы
- Блог разработки – сюда нужно записывать принятые решения, почему решили делать так а не иначе. Должен вести руководитель, который в курсе всех решений. Это очень поможет в дальнейшем.
- Доступы – желательно завести отдельный документ с доступами ко всему, которые потом нужно передать клиенту. Нужно создать под проект отдельный gmail и потом все регистрировать на него, чтобы можно безболезненно передать клиенту.
Приоритеты разработки
- Проекты, в которых в план закладывается 3 и больше месяцев имеют свойство затягиваться очень надолго. По этому нужно как можно чаще выкачивать новые версии и показывать их клиенту.
- Вполне нормально делать спринты длительностью в 2-е недели. Это означает что мы сначала выбираем функционал, который сделаем за две недели, делаем его и через 2е недели он должен быть на продакшине.
- Приоритет по задачам должен быть таким
- версия 0.1
- Создание структуры базы данных
- Авторизация-регистрация пользователей
- Добавление системы ролей в архитектуру
- Редактирование пользователей в админке
- версия 0.1.1
- Редактирование всех справочников а админке
- версия 0.N
- Добавление по одной user-story в релиз. Это одно действие, которое пользователь может сделать на сайте
- версия 0.1
На мой взгляд это вполне универсальный набор советов, которые стоит не забыть сделать в начале, чтобы потом небыло “мучительно больно”