Расписание – представленный в какой-либо форме (доска канбан, список, таблица и т. п.) перечень заданий с ожидаемым временем выполнения и способом контроля результата. Для составления расписания необходимо разбить определенные ранее задачи на несколько (одно или больше) заданий и определить плановые затраты времени на их выполнение.
Составление расписания – деятельность, требующая умения разбивать задачи на подзадачи и оценивать (самостоятельно или с помощью покер-планирования) время их выполнения. Заниматься этим должен разработчик, обладающий максимальной компетенцией в декомпозиции задач и оценке их трудоемкости для конкретных исполнителей. Поэтому первым шагом в управлении расписанием является назначение тимлида – разработчика, обладающего наибольшими компетенциями в отношении задач, решаемых на текущем этапе проекта.
1. ПМ определяет продолжительность этапа. Основной смысл разбития проекта на этапы заключается в защите разработчиков – в ходе всего этапа они занимаются только запланированными заданиями и могут свободно перераспределять свое время, не опасаясь, что начальство заставит делать что-то еще. Разработчики объективно заинтересованы в как можно более продолжительных этапах («сделал месячный план за неделю, и можно отдыхать»), а ПМ – в как можно менее продолжительных (корректировка планов возможна только в ходе планирования следующего этапа). Поэтому продолжительность этапа устанавливается как минимум, на который согласятся разработчики, но не меньше одной недели.
2. ПМ отбирает из бэклога (диаграммы Ганта) задачи для решения на текущем этапе. После этого определяется тимлид этапа – разработчик, лучше всего разбирающийся в технологиях, требуемых для решения отобранных задач. (Тимлид берется только на один этап, потому что, например, для бэкенда и для фронтенда нужны разные тимлиды.) ПМ разъясняет тимлиду его права и обязанности, а также мотивирует на работу по составлению расписания.
3. ПМ и тимлид проводят декомпозицию задач на отдельные задания. Формулируются требования и критерии выполнения. При необходимости привлекаются остальные разработчики, но не в формате общего совещания, а в диалоге «вопрос – ответ».
4. Тимлид оценивает время выполнения заданий. В случае если он хорошо знает производительность исполнителя, которому будет поручено задание, оценка производится исходя из предшествующего опыта. Для этого тимлид использует статистику выполнения предыдущих заданий, ведение которой входит в его должностные обязанности. Если знаний недостаточно, проводится совещание со всеми разработчиками, оценка производится методом покер-планирования.
5. В случае если суммарное время заданий укладывается в плановые сроки для задач, определяется последовательность выполнения заданий (назначается приоритет). Если не укладывается – производится возврат на этап 2, и декомпозиция задач проводится заново, с корректировкой требований, после чего пункты 3–5 повторяются.
Результат. Перечень заданий, каждое – с плановым временем выполнения, точно сформулированными критериями завершения и приоритетом (порядком) выполнения.
В традиционном SCRUM этому этапу соответствует «подготовка к планированию спринта».