Аджайл-манифест – это описание ценностей и принципов, которых придерживаются различные аджайловые процессы
[17]. Одним из таких процессов является скрам. Седьмой из 12 принципов аджайл-манифеста гласит: «Работающее программное обеспечение – основной показатель прогресса». Когда заинтересованное лицо или владелец продукта видит продемонстрированную часть функциональности, он предполагает, что она полностью завершена, и на этом убеждении основывает свое мнение о прогрессе проекта. Если какой-либо инкремент не завершен, все неоконченные работы должны быть идентифицированы и упомянуты в бэклоге продукта.
Ирен получила сертификат только в прошлом месяце и еще была свежеиспеченным скрам-мастером. Неудивительно, что она проглядела ключевой симптом проблемы: команда разработки не поддерживала бэклог спринта в актуальном состоянии в течение всего проекта. После планирования он остался нетронутым. Желая просто состряпать какую-то функциональность, команда не тратит много времени на анализ, проектирование и тестирование. Она кодирует, кодирует и снова кодирует, а перед демонстрацией склеивает все вместе жвачкой. И напротив, разрабатывая программное обеспечение согласованно, команда детально планирует и распределяет всю работу, необходимую для создания завершенного инкремента продукта. Бэклог спринта должен отражать эти детали.
Следующее планирование спринта заняло целый день. Ирен не позволила продолжить работу, пока команда не разработала подробный бэклог спринта. Она наблюдала, как участники детализировали работу, которая была необходима для реализации новой функциональности бизнес-процесса. Затем Ирен получила от команды обещание обновлять бэклог спринта каждый день перед окончанием рабочего дня.
Кто-то подумает, что за один спринт команда могла бы изучить все, что нужно знать о самоуправлении. Но волнение от первого использования скрама может привести к недостаточному вниманию к его сложным частям. Управлять собой трудно. Гораздо легче, хотя и менее приятно позволить кому-то другому управлять вами. На планировании команда разработала бэклог спринта, состоящий из двух видов работ. Для каждой продемонстрированной на обзоре предыдущего спринта функции были добавлены задачи по ее проверке и исправлению найденных ошибок. Задачи по созданию новой функциональности бизнес-процесса составили остальную часть бэклога спринта. Задачи тестирования и отладки были настолько абстрактными и неточными, что невозможно было определить количество необходимого для их выполнения времени. Как определить в ходе спринта, успеваем ли мы завершить все запланированные работы? Никто не знал. Работы по тестированию и отладке нельзя было сжечь
[18], поскольку объем оставшейся работы был неизвестен.
Ирен встретилась с командой разработки и рассказала о трудности в понимании прогресса по спринту, пояснив, что скрам работает только тогда, когда все видно и каждый может проинспектировать прогресс и порекомендовать адаптацию. На ежедневных скрамах участники команды сообщали, что они тестировали и исправляли ошибки вчера и продолжат делать это сегодня, но эта информация была неподробной и поэтому практически бесполезной. После рассказа любого участника команды другие не смогли бы понять, нужна ли их помощь, и не смогли бы оценить, работают ли они над аналогичной проблемой или даже с той же частью функциональности или фрагментом кода. Количество обнаруженных и исправленных ошибок нельзя было установить.
Ирен попросила участников команды разработки сообщить о конкретных пройденных тестах и конкретных выявленных ошибках, попросила определить тесты для каждой ранее закодированной функции и добавить их в бэклог спринта. Она также попросила команду создать метрики тестирования и дефектов. Ирен хотела, чтобы команда разработки знала количество запланированных тестов, пройденных тестов, выявленных ошибок, исправленных ошибок и количество ошибок, которые останутся неисправленными в конце спринта. Она хотела, чтобы участники команды понимали уровень качества создаваемого ими продукта. Ирен учила команду, которая ранее всегда рассчитывала на группу тестировщиков, брать ответственность за тестирование и качество продукта на себя.
Перед следующим ежедневным скрамом Ирен разместила обновленный бэклог спринта на стене в комнате команды. Когда каждый участник команды сообщал о конкретных тестах и ошибках, над которыми работал, Ирен проверяла, чтобы они были указаны в бэклоге спринта. Она продолжала делать это на каждом ежедневном скраме, помогая команде фиксировать работу с тем уровнем детализации, который необходим для понимания происходящего. Команде разработке и Ирен удалось отслеживать тенденции дефектов: количество ошибок увеличивалось или уменьшалось; появлялись ли новые ошибки в результате исправления известных.
Рассказ каждого участника команды разработки в ходе ежедневного скрама должен быть конкретным. Обязательства перед командой реальны, только если их можно оценить. В отсутствие специфики команда Ирен скрывалась за многозначительной общей фразой «исправление ошибок», поэтому участники не могли планировать или синхронизировать свою работу.
Извлеченные уроки
Команда разработки была в восторге от того, что больше не находится под ограничениями чужого плана, в восторге от возможности заняться написанием кода, в восторге от возможности доказать, сколько может сделать за один спринт. Этот восторг и волнение привели к тому, что команда забыла о важных инженерных практиках.
Ирен научила команду управлять собой. Команда разработки должна была понять все аспекты выполняемой работы и часто сопоставлять их со своими задачами, чтобы в конце спринта поставить набор полноценных завершенных функций. Самоорганизация команд не означает отсутствие управления. Для управления собой команда должна создавать план работ и отчеты на его основе. Детали плана и отчетов должны быть достаточно конкретными, иначе они становятся бессмысленными. Команда должна иметь возможность синхронизировать свою работу.
Скрам-команда самоорганизуется: она берет на себя ответственность за планирование своей работы. Бэклог спринта – наглядное проявление этой ответственности команды. Я видел, как команды из трех очень опытных инженеров не использовали бэклог спринта, поставляя надежную рабочую функциональность по планам, хранящимся только в их головах. Тем не менее большинству команд разработки необходимо продумать и записать, что они делают, чтобы участники могли обращаться к плану по ходу работы. Ежедневный скрам синхронизирует работу участников только в случае, если работа тщательно продумана. В противном случае ежедневный скрам бесполезен.
Скрам-мастер должен обучать команду разработки и обеспечивать следование «принципу сашими». Иногда команды пытаются срезать углы. Иногда участники настолько привыкли к водопадным процессам разработки, что рассматривают тестирование как чужую проблему. Механизм определения того, выполняет ли команда всю необходимую работу, – бэклог спринта. Скрам-мастер должен убедиться, что задачи по тестированию отдельно указаны в бэклоге спринта до поры, пока команда не поймет значение слова «завершено». Как только команда осознает и привыкнет к тому, что разработка функциональности включает в себя анализ, проектирование, кодирование, тестирование и документацию, все эти уникальные водопадные подзадачи могут быть объединены в одну задачу бэклога спринта.
