Заканчиваем спринт

Ранее:
Введение в Scrum
Роли при Scrum разработке
С чего начинается Scrum
Уходим в спринт
Работа в процессе спринта

Итерация закончена. Что дальше?

Настало время подведения итогов. Во первых, необходимо провести ретроспективу спринта. Для этого приглашаются все заинтересованные лица, включая Product Owner-а, представителей конечных потребителей вашего продукта, программистов из других команд. Ретроспектива на этом этапе заключается в том, что показываются те Product Backlog Item-ы, которые были успешно завершены в данном спринте. Разбирается что было хорошо, а что плохо. Собираются пожелания заказчика, чтобы их добавить в Backlog продукта для будущих спринтов.

А вот после того, как все заинтересованные в продукте разошлись и осталась только команда, самое время подумать о том, как улучшить работу на следующем спринте. И здесь весьма неплохое подспорье может оказать Burndown диаграмма. Если у вас она такая, как в предыдущей статье:

То в принципе у вас все весьма хорошо, и здесь можете не зацикливаться. Гораздо хуже, если диаграмма:

Т.е. команда не выполнила взятые на себя обязательства. С чем это может быть связано? Ну если у вас это первый спринт, то почему бы и нет. Во всех остальных случаях, надо разбираться в первопричинах. Их может быть несколько: неправильно запланированы Item-ы на спринт (очень много), возникло большое количество ошибок, которое приняли решение исправлять в рамках текущего спринта, пришел заказчик и слезно просил добавить еще вот этот функционал, ну и т.д. Если такие спринты бывают время от времени, то надо разбираться в причинах, и пытаться их устранять. Если такие спринты идут постоянно, то лучше пересобрать команду, поменять на время (или навсегда) процесс разработки, перебросить команду на другой проект, а на этот поставить другую команду.

Другая крайность, которая может всплыть на Burndown диаграммах, это недозагрузка команды, она может появиться как явно:

Так и не очень:

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

Ладно, будем считать, что у нас что то с графиком похожее на правду, и мы закрыли некоторое количество Backlog Item-ов на N Effort-ов (помните про оценку сложности?), так вот, получив эту оценку даже один раз, вы уже примерно сможете оценить срок реализации проекта. И эта оценка будет не по принципу 3-х П: пол, палец, потолок; а на основе реальной производительности команды. Так если у вас команда выполнила 40 Effort, а весь Backlog у вас на 200, то при спринте в 2 недели вы можете сказать заказчику, что закончите проект примерно через 8 недель. Причем, чем больше команда работает, и чем больше у вас статистика по производительности команды в рамках спринтов, тем все более точную и точную оценку вы будите получать.

Ну и в заключении, конец спринта это то самое время, когда можно и нужно улучшать процесс разработки. Смотрите что вам мешало на предыдущем спринте и старайтесь это устранить. Не хватает 2 недель? Сделайте спринт 3. Не получается команде адекватно разбить Backlog Item-ы на задачи, пригласите архитектора, ведущих программистов из других команд (именно на разбиение на задачи, оценка и выбоар Item-ов на спринт, это привилегия только этой команды) ну и так далее.