Соглашение внутри команды

Привет, у нас довольно большой поток разношерстных проектов. В какой-то момент нам пришла в голову светлая идея создать внутреннюю хартию ведения проектов, с которой соглашается каждый участник команды. Есть надежда, что это сократит издержки, увеличит качество и уменьшит количество неразберихи, позволит проще вводить новых «игроков» и вообще В качестве системы управления проектами выбрана 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 минут. Итак, на входе есть задачи, в процессе спринта они решаются, в результате получаем рабочие интерфейсы. Если задача не решена в ходе спринта, программист в комментариях описывает причину. В конце каждого спринта команда проводит регрессивное тестирование.

Алгоритм реализации проекта

1. Инициализация проекта в Redmine.
2. Проработка UI. На «Форуме проекта» открывается ветка UI. Файл PDF прикрепляется прямо к сообщению в форуме, замечу, что обсуждения UI на форуме не отменяют встреч в офисе. Как только UI завершен и согласован, в разделе «Файлы» появляется файл «Final UI.pdf»
3. Менеджер проекта стартует первый спринт, по паралелльным процессам дизайн и программирование. Вносит в оперативный план: дату завершения спринта, версия 0.1. Для обсуждения дизайна формируется ветка на форуме, в обсуждении участвуют: менеджер, дизайнер, ui специалист. Как и в случае в UI, форум не отменяет живых встреч. Результат согласован, и в разделе «Файлы» появляется файл «Final DESIGN»
4. Этап верстки и программирования, заслуживает отдельной статьи.

P.S. Итак, %username%, обращаюсь к тебе. Все пункты проверены на практике и написаны кровью. Но если ты поделишься капелькой мудрости, я буду очень благодарен. Конкрентно интересует, как вы используете Redmine, есть ли у вас в команде стандарты написания кода?

Автор: RUQ