Давайте снова посетим компанию Service1st, с которой начали знакомиться во второй главе и продолжили в четвертой. Здесь скрам использовался для разработки программного обеспечения клиентских служб версии 9.0. Команда прогнозировала реализацию множества функций в первом спринте. Скрам-мастер Ирен попыталась убедить команду разработки уменьшить свой прогноз, но участники настояли на том, что смогут завершить все взятые в спринт элементы бэклога. На обзоре спринта команда успешно продемонстрировала весь функционал и даже несколько дополнительных функций. Менеджмент был в восторге: скрам прекрасен, команда разработки прекрасна, все прекрасно. Руководство полагало, что релизы теперь могут происходить чаще или включать больше функциональности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда разработки была в восторге от того, что больше не находится под ограничениями чужого плана, в восторге от возможности заняться написанием кода, в восторге от возможности доказать, сколько может сделать за один спринт. Этот восторг и волнение привели к тому, что команда забыла о важных инженерных практиках.

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

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

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