Планирование релиза
В предыдущих постах я рассказывал о том, как мы используем TFS для реализации процессов.
В этом, мы поговорим о том, как мы планировали релиз.
В записи рабочего элемента Feature (Функционал) мы добавили закладку «Planning» (Планирование):
Увеличим масштаб:
Мы попросили людей выполнить примерную оценку (estimated cost) для каждой функциональности в рабочем элементе. Затем, мы перенесли их в таблицу с указанием рейтинга, как показано ниже:
Данная таблица Excel напрямую связана с TFS. Важно отметить следующее:
- Данная оценка (как и все остальные данные) напрямую поступает из TFS. И это – замечательно, поскольку все оценочные данные вводились независимо друг от друга, но могут быть вытащены в единственный документ, что облегчает планирование.
- Мы ранжировали весь функционал сверху донизу.
- Мы добавили некоторую логику в таблицу, чтобы иметь возможность сравнения общей нагрузки с потенциалом команды. Команды подсвечиваются желтым, если они используют свои резервы более, чем на 70%, и красным – если более, чем на 100%.
Такой подход дает нам возможность быстро понять что может, а что не может быть сделано, без необходимости возни с таблицами. Это помогло нам найти тонкие места и планировать путем изменения приоритетов функционала, чтобы достигнуть комфортного уровня загрузки. Например, некоторый объемный функционал мы сдвинули вниз, чтобы позволить нескольким малым функциям попасть в релиз.
Если честно, по прошествии времени, это выглядит, как видео игра. Мы называли ее игра в желтое и красное, поскольку было забавно наблюдать насколько мы можем уменьшить желтые и красные цвета! :)
Следующий пост: как мы контролировали продвижение работы.
Gregg Boer. Ссылка на оригинал.
Контроль за продвижением работ
Прежде, чем начать разговор о контроле за выполнением работы, будет полезно рассмотреть жизненный цикл функционала, о котором говорилось в предыдущем посте. Картинка ниже будет отправной точкой для данной публикации.
На картинке ниже представлена закладка «Progress» рабочего элемента типа «Feature».
Проще говоря, перед вами – мой отчет о статусе. Как человек, работающий над функционалом, мне было необходимо заполнять такой отчет раз в неделю. При этом не было необходимости использовать электронную почту или создавать документы, я просто обновлял поля в этом разделе.
Когда Developer Division принял решение о внедрении модели команды разработки функционала, а так же всех качественных характеристик (в оригинале – Quality Gates), мы решили не вмешиваться в процессы управления, которые команды разработчиков функционала приняли для себя.
Некоторые использовали метод «waterfall» с MS Project, другие – SCRUM, кто-то – Excel или клеили стикеры, а кто-то – просто рисовал на доске. Это действительно не имело никакого значения для подразделения в целом, пока ты обновляешь информацию в разделе, показанном выше.
Закладка «Progress» стала стандартом подразделения для предоставления минимального набора информации, необходимой для еженедельного общения.
Глядя на эту закладку, вы можете подумать, что это – слишком примитивная и простая игра. Однако факт в том, что это стало весьма полезным инструментом для отчетности. И это будет подробно рассмотрено в последующих публикациях.
Давайте подробно рассмотрим все элементы из этого рисунка.
- Key Dates (Ключевые даты) – мы отслеживали четыре ключевых даты: начало и конец работы над функционалом и две промежуточные контрольные даты. ВАЖНОЕ ЗАМЕЧАНИЕ: перед началом реализации функционала, команда должна была зафиксировать контрольную дату №1 и оценить наступление контрольной даты №2, а так же дату окончания этой работы. При наступлении контрольной даты №1, команда фиксирует контрольную дату №2 и оценивает дату окончания работ. Мне кажется, что эта модель работала хорошо.
- Percentage complete (Процент завершенности) – просто ожидаемая и законченная работа по всему функционалу. Поскольку мы не вмешивались в процессы управления внутри команд, мы требовали, чтобы они четко понимали о том, сколько было сделано и сколько предстоит.
- Risk Level (Уровень риска) – первое поле, как классический светофор, в индикаторе риска. Зеленый = мы укладываемся в сроки, Желтый = есть риск срыва сроков, Красный = мы сорвали сроки. Второе поле содержит текстовые комментарии.
- Дополнительные важные даты.
- Текстовые заметки о статусе работы.
В следующей публикации я покажу вам, как мы использовали информацию, описанную выше, для контроля над одновременной реализацией множественного функционала, а также об уроках, которые мы выучили.
