Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

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

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

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

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

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

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

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

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

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