Скрам

Хелен, Джим и Энди рассказали об этой проблеме команде. Упростив схему технологической архитектуры системы, размещенную на стене в комнате команды разработки, они вместе разработали вариант для демонстрации менеджменту. Он изображен на рис. 7.5. Архитектуру разделили на слои и сервисы: представление, приложение и данные. Затем команда назначила цвета этапам проекта. К финальным датам каждого этапа руководство ожидало определенных возможностей продукта. Позднее они были синхронизированы с датами обзоров спринтов. Первый этап – синий цвет, второй – зеленый. Перед началом работы над сервисом команда окрашивала его в светлый оттенок цвета, а после завершения заменяла на темный.

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

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

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

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

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

Не все прозрачно в Service1st

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

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

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