Скрам

Я порекомендовал Ирен не позволять команде разработки приступать к какой-либо новой функциональности, пока они не завершат уже продемонстрированную. Неполное тестирование, исправление ошибок и другая неоконченная работа должны быть помещены в бэклог продукта как незавершенная работа. Участники команды еще хорошо помнят код, поэтому его отладка в следующем спринте займет меньше времени, чем на более поздних сроках. Если команда разработки отлаживает код сразу, то укрепляется общее понимание, что только полностью завершенная работа может быть принята. Но команда восстала, опасаясь, что следующий обзор спринта станет унизительным. На первом обзоре она выглядела суперкомандой, а на следующем, не показав ничего нового, выглядела бы нелепо, как картавый охотник Элмер Фадд, который гонится за кроликом Багзом Банни в мультсериале «Шоу Луни Тюнз». Разве можно было продемонстрировать ту же функциональность, что и на предыдущем обзоре спринта, добавив, что теперь функциональность работает?

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

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

Реальность

Команда разработки отличилась в части написания кода, но провалилась в части тестирования, а затем взломала демонстрацию, поскольку система могла работать только в лабораторных условиях по заранее прописанному сценарию. Функциональность, конечно же, не соответствовала «принципу сашими». Если владелец продукта решил бы поставить инкремент продукта после обзора спринта, потребовалось бы проделать еще много работы. В традиционных проектах команды тратят по несколько месяцев на анализ и проектирование, не создавая ничего ценного для заинтересованных лиц. Команда разработки Service1st сделала наоборот: было продемонстрировано функций больше, чем реально завершено. Заинтересованные лица полагали, что прогресс по проекту значительнее, чем на самом деле, – они были в восторге от несуществующей ситуации!

Аджайл-манифест – это описание ценностей и принципов, которых придерживаются различные аджайловые процессы[17]. Одним из таких процессов является скрам. Седьмой из 12 принципов аджайл-манифеста гласит: «Работающее программное обеспечение – основной показатель прогресса». Когда заинтересованное лицо или владелец продукта видит продемонстрированную часть функциональности, он предполагает, что она полностью завершена, и на этом убеждении основывает свое мнение о прогрессе проекта. Если какой-либо инкремент не завершен, все неоконченные работы должны быть идентифицированы и упомянуты в бэклоге продукта.

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