Привет, у нас довольно большой поток разношерстных проектов. В
какой-то момент нам пришла в голову светлая идея создать внутреннюю
хартию ведения проектов, с которой соглашается каждый участник команды.
Есть надежда, что это сократит издержки, увеличит качество и уменьшит
количество неразберихи, позволит проще вводить новых «игроков» и вообще В
качестве системы управления проектами выбрана Redmine, и надо сказать
даже в default устанвоке эта штука правильно решает много вопросов за
тебя: разделение на Ошибка\Улучшение, интеграция Git, лог действий,
подпроекты, удобная Wiki и.т.д.
Каждое приложение — один проект в формате Redmine
Например, мобильное приложение «Для поиска свежего хлеба». Скорее всего
приложение будет иметь три стороны: web, android&iOs, тогда
структура проектов выглядит так:
Первичный — web (там же все организационные вопросы)
Подпроект 1 — iOs
Подпроект 2 — Android
Задачи внутри проекта
Стандартный процесс статусов задачи (М. — менеджер, П. — программист): М.Создана → П.В работе → П.Решена → М.Закрыта. (М. при необходимости менять на К — клиент)
Уточнение параметров задачи: М. Создана → П. Обратная связь → М. Обратная связь → П. В работе.
Типа задач: Ошибка — багфикс, Поддержка — плановая работа, Улучшение — работы не входящие в первоначальный план.
Мало, но емко в Wiki.
Например: FTP доступ, контакты участников команды и.т.д. Иначе говоря
информация несущая административный характер. Redmine — стремление
построить единое информационное пространство, в котором каждому
участнику команды доступна вся необходимая информация.
Git
Обязательность связки коммит-задача. По возможности, следовать правилу
одна выполненная задача — привязанный коммит. И соответственно наоборот,
к каждому коммиту привязана задача. При описании коммита (commit -m),
указать ид задача — «refs #Issue ID».
Миграции БД
Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.
Хранение файлов
Файлы — хранение файлов внутри дирректории проекта. PSD и PDF в
соответствующих папках внутри первичного проекта (design и ui). Таким
образом сохраняется история рисования, места на hdd не жалко).
Описание test-cases.
По мере реализации проекта, менеджер совместно с программистом описывают
сценарии тестирования приложения. В завершении каждого микрорелиза, в
конце спринта проводится регрессивное тестирование проекта. На основании
выполненных задач в релизе документ дополняется.
Майлстоуны
Мы поддерживаем идеологию непрерывной интеграции, при старте проекта
менеджер проекта оценивает ключевые этапы в разработке проекта. И
отмечает их на оперативном плане. Например, «Возможна регистрация
пользователей» 15-го мая. Таким образом можно примерно оценить
протяженность проекта, стоимость и нагрузку специалистов.
Не проверено на практике Спринт
Длительность спринта для каждого проекта варьируется от 3-х до 5 рабочих
дней, и для каждой команды устанавливается индивидуально. В начале
спринта команда совместно выбирает задачи для следующей итерации
(берется в учет выставленный приоритет и личный интерес к задаче). По
окончании спринта команда встречается на «ретроспективе», обсуждая ход
предыдущего спринта, как правило это не занимает более 20 минут. Итак,
на входе есть задачи, в процессе спринта они решаются, в результате
получаем рабочие интерфейсы. Если задача не решена в ходе спринта,
программист в комментариях описывает причину. В конце каждого спринта
команда проводит регрессивное тестирование.
Алгоритм реализации проекта
Инициализация проекта в Redmine.
Проработка UI. На «Форуме проекта» открывается ветка UI. Файл PDF
прикрепляется прямо к сообщению в форуме, замечу, что обсуждения UI на
форуме не отменяют встреч в офисе. Как только UI завершен и согласован, в
разделе «Файлы» появляется файл «Final UI.pdf»
Менеджер проекта стартует первый спринт, по паралелльным процессам
дизайн и программирование. Вносит в оперативный план: дату завершения
спринта, версия 0.1. Для обсуждения дизайна формируется ветка на форуме,
в обсуждении участвуют: менеджер, дизайнер, ui специалист. Как и в
случае в UI, форум не отменяет живых встреч. Результат согласован, и в
разделе «Файлы» появляется файл «Final DESIGN»
Этап верстки и программирования, заслуживает отдельной статьи.
P.S. Итак, %username%, обращаюсь к тебе. Все пункты проверены на практике и написаны кровью.
Но если ты поделишься капелькой мудрости, я буду очень благодарен.
Конкрентно интересует, как вы используете Redmine, есть ли у вас в
команде стандарты написания кода?
Спринт лучше мерить неделями. 1-2, т.е. 5-10
ибо спринт в 3 рабочих дня — фигня какая-то :) Тратить время на ретроспективу и тестирование каждый 4 день — антивариант.
Стандартная практика 2 недели.
Это всё, конечно так, но практика показывает, что бывают ситуации,
когда нет возможности растягивать спринт на 2 недели, по самым разным
причинам.
К тому же, не обязательно проводить ретроспективу каждый такой маленький спринт — можно раз в 2 спринта.
И, наконец, тестирование — его периодичность зависит от типа и
потребностей. У нас тестирование проводится каждой* новой фичи, не важно
закончился спринт или нет.
Т.е. я к чему клоню — если использовать Agile, то нужно быть гибким, а не просто следовать «лучшим практикам».
p.s. К слову, у нас в компании мы вообще отошли от спринтов, в общем их понимании.
>Программист создает в корне проект файл migration.sql в котором содержится инструкция к созданию БД.
А почему вы не хотите пользоваться стандартным механизмом миграций?
В двух словах. Любое изменение базы сохраняется в отдельный файл,
которых попадает в репозиторий вместе с остальными изменениями. После
выкатки кода на продакшен по всем миграциям проходит скрипт, смотрит,
какие еще не были применены и применяет их в том порядке, в котором они
были добавлены. Если у вас нет проектов на нескольких серверах, то это
оптимальный, на мой взгляд, способ.
Можете посмотреть как это реализовано в популярных фрэймворках и
вытащить этот функционал к себе на проекты… ну или можно самим написать
по аналогии.
Как написано в комментариях ниже, это не правильный подход. Коммит
должен быть атомарным, но не обязательно, чтобы он закрывал задачу
целиком, мне кажется это правило вносит только неудобство разработчикам.
У нас обязательно принято, чтобы все коммиты были привязаны к задачам,
но их может быть сколько угодно, в редмайне они хорошо выводятся, не
мешает. Обычно их там получается 2-5.
Первичный — web (там же все организационные вопросы)
Подпроект 1 — iOs
Подпроект 2 — Android
По-моему гораздо логичнее в качестве первичного создавать как раз общий проект, для орг. вопросов.
А конкретные технологии уже выносить в подпроекты, потому как
— что если вы решите использовать другую технологию вместо PHP? Тогда логика будет нарушена.
И я думаю что все файлы лучше прикреплять к вкладке «Files», в случае
если возникнут какие-то вопросы, то те же первичные UI проще найти.
Это удобно для того чтобы новый разработчик мог просмотреть историю
развития архитектуры и не задавал лишних вопросов/не предлагал идей,
которые уже отмели и т.п.
ИМХО конечно.
Cтандартный процесс статусов задачи (М. — менеджер, П. —
программист): М.Создана → П.В работе → П.Решена → М.Закрыта. (М. при
необходимости менять на К — клиент)
1. Я неправильно выразился, миграция в моем понимании — файл позволяющий воспроизвести рабочую структуру БД.
2. Автоматизированные скрипты не используем, надеюсь — это временно, постигаем эту науку.
3. Дизайн, только после прототипов, потому программист может начать без графики.
Вам, спасибо за дельный комментарий и статью «про Мишу». Анализ
проекта на этапе проработки интерфейсов взаимодействия, тестирование при
каждой выполненной задаче\новой фиче. Или мы говорим о качестве кода:
code review, refactor и.т.д.?
Много времени уделяется проработке проекта на старте, в среднем — две
недели. Впрочем, мы строим машину, не космический корабль (ну вы
поняли) — ценности или концепция могут меняться. Протипы получа.тся
оцень приближенными к конечному результату, и содержат не только
интерфейсы, но и комментарии для программистов\верстальщиков\дизайнеров.
Вы, вроде как, используете некоторые плюшки из agile, но некоторыми
остальными вещами вы делаете процесс разработки не очень гибким.
Например, в agile нет никаких Final PDF, Final ТЗ, Final Tasks, там
финальная версия может быть только по истечении последнего спринта (до
этого момента все может «гибко» измениться). С гитом тоже не все супер —
идеологически неверно приравнивать коммит задаче. Иногда решение задачи
может разбиваться на несколько веток, не говоря уже о коммитах. Ваше
понятие непрерывной интеграции я вообще не понял :), но если у вас это
прижилось, то вы хороший PM.
Судя по описанию рабочего процесса основные задачи у вас — установка и настройка wordpress/drupal/e-shop :)
— У нас в компании приняты 2-х недельные спринты.
Этапы работы вполне стандартны: Задача — В процессе — Готово для тестов — Тест в процессе — QA — Готово.
Естественно перед каждым спринтом — планирование, игра в SCRUM карты. После — ретроспектива.
Кроме этого по четвергам — bugfix day, каждый берет какой-либо маленький
баг и фиксит его, создавая отдельную ветку. Затем создается пулл
реквест и отправляется в основной репозиторий на code review. После
прохождения code review пулл-реквест изменения сливаются в основную
ветку и тестируются командой QA, если все в порядке — изменения
одобряются и ждут релиза, если нет — делается revert пулл-реквеста.
Ну и конечно же ежедневные stand up митинги в формате: что делал вчера — что планирую делать сегодня
А можете расписать, что происходит, если код не проходит code review.
Интересует как организуется работа в системе контроля версий?
Накатывается новый коммит на ветку с исправленным кодом?
Если code review не проходит, данные изменения не попадают в релиз.
Есть неделя времени, чтобы все поправить и открыть новый пулл реквест.
Как у нас все это работает — разработчик мерджит master в свою ветку.
Т.к. master содержит revert его изменений, не прошедших code review,
необходимо сделать двойной revert, т.е. в логе смотрим какой коммит
отменяет пулл-реквест, делаем revert этого коммита и получаем наш
исходный код. Правим и отправляем очередной пулл-реквест.
Программист создает в корне проект файл migration.sql
Мы обычно пользуемся стандартными механизмами миграция или вручную, но в
таком случае используется далеко на 1 файл, как написано у вас. Есть
папка Sql, в которой находятся папки: insert, update, delete, create,
alter. И в каждой файлы, название которого соответствует названию
таблицы и в нем уже содержится ряд изменений.
У нас процесс несколько иначе построен, потому что там больше шагов. А именно:
1. Релиз раз в месяц, ответвляемся от development ветки в первое
воскресенье месяца и делаем feature freeze. Месяц гоняем по тестам и в
последнее воскресенье месяца выходим в production. Получается что у
каждого разработчика на харде как минимум три ветки: development,
current-release, upcoming-release где и ведутся разработки.
2. Все задачи ставят проект-менедждеры.
3. Задачи попадают главным по модулям системы.
4. Главные задачи описывают технически и разбивают на таски указывая
размер, приоритет и срок. Максимальный размер любой задачи не может
превышать 2 дня.
5. Разработчик в начале недели получает задачь на 4 дня (1 день — буфферный).
6. Взял таск, выполнил, сделал коммит для этого конкретного таска и отметил его «готовым для review»
7. Другой разработчик делает code review задачи, если всё ок идём дальше, если нет возвращаем разработчику.
8. Ответственный за модуль делает code review задачи, если всё ок идём дальше, если нет возвращаем разработчику.
9. Проект менеджер тестирует задачу, если всё ок идём дальше, если нет возвращаем разработчику.
10. Технический редактор документирует задачу, если всё ок идём дальше, если нет возвращаем разработчику.
11. Ответственный за репозиторий и целостность кода делает merge кода задачи в development branch.
Спасибо, у нас не практикуется code review, наверное это плохо. А вот у меня к вам такие вопросы:
1. судя по вашему описанию трудозатратность определяет менеджер, но он
должен должен быть не просто спецом в технической части, но и погружен в
проект не меньше чем программист?
2. что делаете если программист не уложился в отведенный срок?
3. есть ли у команды тех.лид, если есть какие задачи он выполняет?
4. есть ли ежедневные утренние совещения менеджер\программист?
5. Каким образом считается премия для програмиста?
6. Какие стандарты написания кода используете, есть ли они, как передаете новичкам?
7. Я так понимаю у вас не веб?)
Azy
#
Funcraft
#
↑
