Скрам - читать онлайн книгу. Автор: Кен Швабер cтр.№ 35

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

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

Извлеченные уроки

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

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

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

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

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

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

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

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

Реальность

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