Всем привет,Данной статьей я бы хотел продолжить цикл статей, ссылка на который приведена внизу данного поста. Итак, мы построили хорошую команду разработчиков, где вас принимают как лидера, вы договорились с заказчиками вашего продукта о том, как должны ставиться задачи, и воплотили эту договоренность в жизнь.

Теперь пришла пора посмотреть на то, что мы получили от Заказчика, и как это можно запланировать, чтобы не сильно отклоняясь от графика работы, выполнить все задачи на высоком уровне качества, где качество это соответствие выданного продукта ожиданиям заказчика.

1 — Список

Итак, если мы все сделали правильно в прошлых действиях, то сейчас мы имеем некий список задач расположенный в отдельной ветке, в какой либо информационной системе. Основные поля, которые нас интересуют в этом списке задач, следующие:

ИД | Название задачи | Постановщик задачи | Важность | Ожидаемый срок

ИД — айди задачи в Системе, или другое условное обозначение, позволяющее уникально идентифицировать каждую задачу
Название задачи — краткое описание задачи
Постановщик задачи — от кого пришла данная задача
Важность — важность задачи для заказчика от 1 до 10, где 1 совсем не важно, а 10 критично важно
Ожидаемый срок — когда заказчик хотел бы получить задачу

Как вы назовете данный список задач не важно, «Беклог», «Кучка», «Бардак», важно что это список всех задач которые поставил Заказчик перед нашей командой. Тут необходимо понимать что должны быть разные списки между теми задачами, что поставил Заказчик и теми задачами что ваша команда ставит перед собой для улучшения кода, архитектуры приложения и тд, что мы называет емким словом рефакторинг кода. Соответственно у вас будут два списка Беклог заказчика и Рефакторинг от собственной команды.

В ветку рефакторинг задачи приходят от ваших старших разработчиков, архитекторов и тестеров.

2 — Домашняя работа

Для начала работы, нужно разобрать беклог тех задач что находятся на текущий момент в общей ветке. Правила разбора должны быть разными для каждой отдельной ситуации, и зависят от уровня задач, уровня работы команды, поддерживаемыми системами и тд. В нашем случае мы попробуем разобрать все задачи важность которых выше 5-ти.

Для этого в первую очередь, мы вычленяем задачи с важностью выше 5-ти. В качестве домашней работы, ваш тимлид уже должен был предоставить вам емкость команды на следующую итерацию в формате:

Сотрудник Должность ЕмкостьИтого:

Как планируем мы. Первоначально мы ограничиваем итерацию календарно. В частности, мы считаем что итерация должна длится пять недель:
Планирование — 1 неделя
Разработка — 2 недели
Тестирование — 1 неделя
Пилот — 3 дня
Запуск — 2 дня

Мы для себя определили что 5 недель является идеальным сроком для вывода новой версии продукта, позволяя оптимально реагировать на изменения рынка и пожелания заказчика. Получается что наш заказчик знает когда выходит каждая версия продукта заранее, и его основная задача это попытаться включить свои «хотелки» в наиболее раннюю версию, и это важно, к этому мы еще вернемся позднее.

Итак, мы имеем фиксированную по календарю итерацию, с фиксированным расписанием каждой итерации. Тимлид считает по должностям емкость итерации, и скажем мы определяем что у нас есть 400 часов, т.е. 10 рабочих дней х 8 часов х 5 разработчиков. Конечно обычно это не так, так как скажем капитан команды может тратить на разработку 3 часа в день и тд, но для целей данной статьи будем считать 400 часов в целом.

Важно отметить, что мы считаем только емкость разработчиком. Далее, вы поймете почему. При этом у нас имеется правило формирования команды:
Капитан — 1 человек
Разработчики — 5 человек
Тестер — 1 человек

Один проект может делать несколько команд, но любой проект, выполняется минимум одной командой.

3 — Дикий разбор задач

Зная емкость команды в 400 часов. Мы вычленяем все задачи с важностью более 5-ти, и составляем список этих задач. Далее, архитекторы и старшие разработчики дают «дикую» (wild) оценку тикетов в отобранном беклоге, на что выделяется один рабочий день. Если мы видим что предварительный беклог находится в пределах ±40% от общей оценки емкости команды то мы движемся дальше, если же порог превышен, то мы либо повышаем, либо понижаем уровень важности для отбора задач в беклог итерации, чтобы получить приблизительно необходимый объем задач.

Все задачи, тимлидом распределяются по разработчикам, в зависимости от типа задач и рекомендаций архитектора и старших разработчиков, все еще в пределах одного рабочего дня.

Итерации дается какое то имя, скажем «Новые поставщики и снижение нагрузок», чтобы все могли ее однозначно идентифицировать в разговоре.

4 — Время сказочников, легенды

На следующее утро, когда разработчик приходит на работу, он начинает разгребать свой персональный беклог на итерацию. Открывается каждый тикет, и разработчик производит его оценку. Разработчик должен пройтись по всем своим тикетам и к каждому тикету написать легенду.

Легенда это описание того, что разработчик будет делать с тикетом. Если тикет включает в себя формы, то разработчик рисует формы в простейшем схематичном виде. Легенда пишется обычным, русским, простым языком, чтобы ее мог понять заказчик. В легенде разработчик фиксирует что, конкретно, получит заказчик от работы разработчика. Скажем:

«Я собираюсь сделать кнопку выгрузки в Эксель в отчете по платежам. При этом я буду учитывать тот отчет, который сейчас отображается в окне отчетов, с учетом всех фильтров. Я должен буду выравнять размер колонок и строк в Экселе, проверить отработку Итоговых формул отчета, которые содержатся в окне программы. После нажатия на кнопку и отработки всех правил, я дам пользователю возможность сохранить отчет на компьютере в формате .xls. Данная кнопка будет доступна тем пользователям, у которых есть права на просмотр данного отчета. На время генерации отчета я показываю прогресс бар в виде крутящегося кружка, после окончания работы я показываю окно с информацией: Отчет такой-то сгенерирован и сохранен за %Х% секунд, кнопка ОК»

Каждый тикет должен содержать легенду, написанную исполнителем очень простым языком. Для технических тикетов, в ветке рефакторинг процесс немного отличается. На это тратится где-то три рабочих дня.

Дополнительный день отводится на то, чтобы заказчик явно утвердил легенду каждого тикета. Так как заказчик заранее знает когда будет день утверждений, обычно мы успеваем получить утверждения за 1 рабочий день. Утверждение происходит между исполнителем тикета, и тем, от кого задача пришла.

По окончанию написания легенд, каждая задача оценивается по сроку старшими разработчиками как «Эталонная оценка», сам разработчик пишет свою оценку, которая должна быть в пределах ± 30% от Эталонной оценки. Если пределы превышаются, разработчик должен выяснить почему это происходит со старшим разработчиком, и или поменять эталонную оценку, или отказаться от выполнения данного тикета и поменяться с тем разработчиком, кто будет ее готов сделать в заданные сроки.

5 — Утверждение

После того, как все разработчики разработали легенды и заявили те, сроки за которые они готовы сделать свои задачи. Мы проверяем ветку рефакторинг, к рефакторингу допускаются только старшие разработчики и архитекторы и они уже подготовили беклог с описание задачи, сроками и приоритетом задачи от 1 (не приоритетна) до 10 (блокер).

Тимлид, Капитаны, Архитекторы(Планировщики) начинают формировать список задач для итерации. В первую очередь в итерацию попадают задачи с уровнем приоритета 10 из ветки по рефакторингу. Из оставшегося времени вычисляется 20% и в рамках этого срока определяется какие задачи из рефакторинга еще можно засунуть в итерацию. После этих операций у нас остается время на задачи Заказчика.

Планировщики включают задачи в итерацию чтобы получить остаток по емкости максимально близкий к 0. Задачи включаются по их уровню Важности. Приоритет это важность, выставленная разработчиком, Важность — выставляется заказчиком. После того как мы сформировали итерацию с максимально близкими сроками к 0, мы смотрим нужно ли увеличить время итерации для особо критичных задач или нет. В любом случае заканчивается этап планирования объявлением Названия итерации, Времени начала итерации, Составом команд, Длительностью итерации.

Далее Тимлид утверждает данную итерацию с Заказчиком, путем переговоров, перетасовкой задач, Тимлид должен добиться понимания от Заказчика когда и что он должен получить. Мы допускаем максимальное увеличение срока одной итерации до + 1 неделя, из которой 3 дня выделяются на разработку. Мы не начинаем итерацию, пока не получим добро от Заказчика. План итераций утверждается на самом высоком уровне в начале года. Заказчик должен планировать свои задачи так. чтобы получить их как можно раньше. Заказчик не управляет сроками итерации, он не может начать завтра и получить результат послезавтра. Все новые задачи, идут строго итерационно.

Конечно, возникает ситуация для мега срочных тикетов, тогда итерация прерывается и мы решаем задачу если она имеет статус блокер. Потом возвращаемся к итерации, при этом тимлид должен предупредить заказчика, насколько решение данной задачи, изменило срок сдачи итерации. Если заказчик упирается и говори что мне нужна итерация на 3-4 дня, мы можем согласится, но заказчик подписывает бумагу что за качество в данной итерации мы ответственности не несем и он берет все риски на себя. За все время моей работы, ни один заказчик на это не согласился и был вынужден принять наши условия.

Заключение

У вас не получится предусмотреть все, будут ахтунги, переработки, срочные задачи, важным моментом всего этого является, что если у вас есть хорошая система коммуникаций, вы должны быть к этому готовы. Фиксируйте итерации в календаре с их емкостью, научите заказчика процессу постановки задач, и используйте эталонные оценки и легенды и я надеюсь вам удастся лучше попадать в заявленные сроки. Постарайтесь всегда быть проактивными в общении с заказчиком, не прячьте проблемы, и я думаю вы сможете построить доверительные отношения с заказчиком.

В следующей статье мы посмотрим как можно проводить мониторинг разработки, и стараться предупреждать проблемы, а не решать их по факту.

Предыдущие статьи:

Жизнь управленца, кадр 1, не надейтесь на понимание
Жизнь управленца, кадр 2, жесткая воля
Жизнь управленца, кадр 3, коммуникации
Жизнь управленца, кадр 4, Планирование — Постановка задачи

Автор: undry

Источник