Введение
Скрам – отличный инструмент, но все же это лишь инструмент. Все его достоинства проявляются тогда, когда он в работе. И как с любым инструментом, чем больше вы им пользуетесь, тем более искусно его применяете. Мастерство приходит с практикой, и Скрам очень соответствует этому утверждению – ведь он ориентирован на постоянное повторение циклов.
Доведение до совершенства не способствует прогрессу, так что не стоит планировать применение Скрама до мелочей еще до того, как вы начали его использовать. Намного лучше изменять тактику на ходу. Вы можете столкнуться с чем-то, что кажется не совсем очевидным, и придется подстраиваться уже в процессе. Или не совсем правильно будет составлена команда, или скептично настроенные коллеги будут излишне мешать. Со временем большие проблемы будут решены, и на их место придут меньшие, но решаемые куда легче.
Если вы не будете привносить свои изменения, пусть даже небольшие, то вы не поняли сути. Случается так, что желание менять что-то отступает, сменяясь готовностью принимать неудобный статус-кво. Иногда боязнь раскачивать лодку препятствует даже незначительным изменениям. Иногда, что может показаться абсурдным, люди даже считают текущее положение дел близким к идеальному!
Примите цикл жизни Скрама, но не идите ради этого на компромиссы или отказ от изменений. С одной стороны, этапы Скрама очень легко предсказать, так как в теории они остаются одними и теми же, но в то же время на практике они всегда очень сильно различаются.
Нет! Не пробуй. Сделай.Мастер Йода
Подготовка
Часто люди, не понимающие гибкого способа мышления, считают, что в Agile не предполагается никакого планирования. Но это не касается ни гибких подходов в целом, ни Скрама в частности. Планирование имеет первостепенное значение, и это справедливо не для единичных случаев, а постоянно. Скрам-мастер и владелец продукта определяют, что нужно сделать, а что реализовать будет невозможно. Все эти обсуждения отражены в журнале требований продукта. Он является самым важным артефактом, основой работы над любым проектом. Часто наполнение журнала напрямую отражает то, как идет работа над проектом, и наоборот. Даже самые лучшие команды не смогут добиться впечатляющих результатов без журнала требований продукта, и он постоянно пересматривается и обновляется в зависимости от актуальной информации.
Блистательная мысль
Девяносто девять из ста Скрам-команд начинают свой первый спринт на излишне оптимистичной ноте и не особенно уделяют внимание планированию. Либо пользовательские истории не до конца проработаны, либо не сформирован план действий, либо не хватает критериев принятия – а то и все вместе. Девять из десяти команд повторят те же ошибки и на втором спринте.
Избегайте такого.
Доработка журнала
Раньше доработку или уточнение журнала называли «причесыванием» (grooming) по аналогии с причесыванием волос, но со временем термин сменился по очевидным причинам. Кто-то продолжает использовать это старое название, но вне зависимости от этого сама практика поддержания журнала требований продукта в актуальном состоянии только положительно сказывается на бизнесе и впоследствии на конечном пользователе.
Окончательное решение насчет распределения приоритета задач принимает владелец продукта, поэтому, так как это творческий процесс, точные рекомендации тут дать сложно. Не пытайтесь расположить все в идеальном порядке. Куда важнее поддерживать актуальность бизнес-требований, например пользовательских историй. Встречи с обсуждением всех доработок журнала и подготовки пользовательских историй для спринта должны проходить регулярно, и в идеале на них должны присутствовать по одному представителю каждой дисциплины из команды.
Некоторые команды просматривают журнал на предмет возможных обновлений каждый день, другие – намного реже. Но отсутствие доработки, без сомнений, приведет к проблемам на ближайшем спринте. Постоянная работа над журналом обязательно принесет свои плоды, но тут необходимо достичь определенного равновесия. Некоторые спринты будут посвящены реализации необходимых функций, а не тому, что полагают важным на данный момент бизнесмены.
Блистательная мысль
Владелец продукта отвечает за качество пользовательских историй и состояние журнала требований продукта. Если он делает свою работу хорошо, планирование спринта пройдет гладко. Если нет, то в ходе встречи по планированию скрипта постоянно нужно будет отвлекаться на уточнения.
Критерии принятия
Самый быстрый способ для команды разработки начать работу не так – это не до конца разобраться в требованиях.
Явное недопонимание – самая большая проблема, но, как правило, с нею разбираются быстро во время сеансов доработки журнала. Однако неявные недоразумения встречаются куда чаще; и так как они накапливаются, то могут выясниться на поздних этапах работы. Простейший способ избежать этого – совместно определить критерии принятия заранее; создать совместное представление того, как Владелец продукта будет судить о том, что выпуск продукта соответствует его видению. Это должно быть сделано не только на макроуровне (каждый спринт), но и для каждого требования (например, каждая пользовательская история).
Лучший способ избежать проблем – определить всей командой эти критерии принятия. Есть много вариантов, как это сделать, но, если у вас возникают проблемы, можно просто ответить на вопрос: я знаю, что я получу <что-то>, когда <что-то сделано>. Это «что-то» оказывает ощутимое влияние, а «что-то сделанное» может быть положительным или отрицательным. Используйте это для прогнозирования того, что скажет о продукте Владелец продукта, когда вы предоставите ему результат. Начинайте сначала.
Типы критериев успеха могут включать в себя:
• простое описание желаемого результата;
• ключевые тезисы;
• условия принятия работы;
• стиль языка Gherkin в формате «Дано», «Если», «То».
Блистательный пример
Очень заманчиво начать спринт на оптимистичной ноте, пообещав себе, что вы все сделаете как надо, только чуть позже. Иногда в начале спринта энтузиазм перевешивает здравый смысл. Само собой, как же можно занудствовать, когда намечается что-то новое и интересное, – почему бы попросту не надеяться на лучшее? А потом неизбежно что-то случается – и неизвестно, как плохо все будет складываться потом.
Некоторые команды могут так и не оправиться после неправильного старта. Первая неудача в выпуске продукта может безвозвратно подорвать доверие, особенно если ожидания были высоки. Неверное начало может повлечь неудачи и во втором спринте, вовлекая вас в замкнутый круг. Проблемы и так возникнут – поэтому не игнорируйте хорошие советы и не увеличивайте шансы на возникновение неудач с самого начала.
Приоритезация в действии
При определении очередности нет необходимости излишне углубляться в детали. Это не Олимпиада, где разница между первым, вторым и третьим местом имеет значение, а четвертое может означать, что поездка сюда была впустую потраченным временем. Неважно, будет ли пользовательская история первой в списке, когда спринт начинается; все, что имеет значение – входит она в спринт или нет? Или, точнее, включена в этот выпуск продукта или нет.
Поскольку спринты относительно короткие, это больше похоже на ожидание автобуса. Скоро будет следующий. Это уменьшает давление, и нет необходимости бесконечно мучительно расставлять приоритеты. Владельцу продукта придется просто подождать еще две недели – или какой будет согласована стандартная длина спринта – до следующего выпуска продукта. Не нужно нервничать.
Лучшее – враг хорошего.Вольтер
Оценивание в действии
Очень важно, чтобы каждый элемент в журнале имел шанс попасть в следующий спринт – поэтому проводится приблизительное оценивание затрат на практическую реализацию. Не очень хорошо, когда оценки просто не могут быть согласованы по одной или нескольким причинам. Плохо, когда команда не может определиться с задачами на следующий спринт, но если члены команды никак не сойдутся в оценке задач, это может указывать на более фундаментальные проблемы:
• Неясные требования: расплывчатые пользовательские истории сложно оценить и, что куда более важно, сложно реализовать. Получите разъяснения.
• Слишком большая и сложная задача: если часть работы требует для реализации больше, чем несколько дней, сроки выпуска продукта станут излишне неопределенными. Разбейте задачу на части! Кроме того, требования к таким объемам работы обычно менее понятны.
• Неверно определенные критерии принятия: если пункт назначения неясен, трудно измерить, сколько времени потребуется, чтобы попасть туда. Даже с четкими критериями принятия кому-то может показаться, что эта часть работы огромна, в то время как другие решат, что она совсем невелика.
Оценка должна быть коллективной. Тут надо повторить в очередной раз: разговаривайте друг с другом. Разношерстная группа людей, обсуждающих проблему со всех сторон, снимет завесу таинственности со всех ее аспектов и определит, что нужно для выпуска продукта. Этот процесс не нужно доводить до совершенства; вполне достаточно обозначить широкими мазками самое главное.
Мы уже рекомендовали в качестве оценочной техники размеры одежды и оценочные подходы, но, возможно, новичкам проще будет использовать для оценки затрат времени старые добрые минуты, часы и дни. По опыту, приноровившись к Скраму, вчерашние новички впоследствии выбирают какую-то другую оценочную технику.
Прежде чем углубиться в спринт и его проблемы, нет необходимости в многочисленных проверках. Главное, убедитесь в трех вещах:
1. Задачи в журнале распределены по порядку их выполнения, и журнал согласован с владельцем продукта.
2. Критерии принятия (по крайней мере, некоторые из них) написаны совместно с командой.
3. Все пользовательские истории оценены.
Блистательный пример
Блистательное определение
В случае оценочного подхода один из наилучших вариантов – повышать баллы в соответствии с последовательностью чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 100… Все на меньшем конце последовательности будет означать задачу с наименьшими трудозатратами, и по возрастающей до самых объемных задач в конце. Такой метод прекрасно работает со многими Скрам-техниками, особенно с использованием для планирования покерных карт.
Все задачи, которые очень сложны, получают оценку 100, чуть менее сложные пользовательские истории – 55, а 34 – те, которые требуют особого внимания.
Начало спринта
Спринт всегда должен начинаться с планирования спринта. Это планирование отличается от планирования релиза и особенно от планирования проекта. Планирование спринта – очень важный шаг, на котором должна присутствовать вся команда. Именно планирование является залогом успеха спринта, но оно же нередко становится причиной неудачи.
Задача команды при планировании – убедиться в том, что она приступает к спринту с четким осознанием того, что его задачей является получение рабочего продукта, который можно предоставить владельцу продукта. Если команде не хватает времени на подготовку, то постарайтесь сделать так, чтобы планирование обязательно включило доработку и «причесывание» как подготовку продукта к реализации. Подобная ситуация далека от идеала, но даже она лучше, чем начинать спринт вслепую, руководствуясь надеждами на лучшее.
Блистательный совет для сохранения времени
Существует немало быстрых и легких способов потерпеть неудачу при планировании:
• Никто не знает, что делать дальше.
• Команда ходит по кругу.
• Все молчат и избегают смотреть друг на друга.
• Участники не доверяют друг другу.
• Не хватает прозрачности и базовой информации.
• Все переживают и злятся.
• Владелец продукта вышел за кофе и не вернулся.
• Команда не выдает результата!
Достойная реализация механик
Если подготовка была проведена на соответствующем уровне, в частности, пользовательские истории, критерии принятия и условные баллы оценивания задач прописаны заранее, то планирование сводится к достаточно недолгому обсуждению, где команда разработчиков убеждается в том, что все ее члены понимают, чего хочет владелец продукта, и приходит к консенсусу относительно того, какой результат команда ожидает выдать в ходе спринта. Основная задача на этом шаге уже очерчена, поэтому команде достаточно реализовать ее соответствующим образом, использовав для этого следующие механики.
• Логистика. Одна из основных задач Скрам-мастера во время планирования заключается в том, чтобы обеспечивать сотрудничество между участниками. Однако Скрам-мастер также должен позаботиться о вопросах логистики. На первый взгляд эти вопросы малозначительны, однако их важность сложно переоценить; примеры подобных вопросов включают в себя резервирование комнаты, пересылка приглашений Владельцу продукта и команде, проверка того, что пользовательские истории и цель спринта зафиксированы заранее и что Владелец продукта хорошо представляет себе, зачем он встречается с командой. В ходе самой встречи Скрам-мастер сосредоточивается непосредственно на переговорах.
• Продолжительность. Планирование – отличная возможность для прицельного обсуждения деталей проекта и поэтому требует особого внимания. Однако на практике невозможно поддерживать концентрацию участников на протяжении нескольких часов, поэтому с прагматической точки зрения лучше ограничить продолжительность встречи двумя часами. Если встреча подходит к концу прежде, чем команда добивается максимальной успешности, то не беда – в дальнейшем команда всегда сможет наверстать упущенное. На начальных этапах всегда лучше оставлять пространство для маневра и сохранять гибкость, вместо того чтобы чрезмерно фокусироваться на цели и терпеть неудачу.
• Результат. Основная задача планирования заключается в том, чтобы команда и владелец продукта сошлись на том, какой результат будет предоставлен в конце спринта; соответственно, этот процесс в основном вращается вокруг формирования ожиданий. Практически всегда владелец продукта будет хотеть больше, чем команда может дать. В силу этого команде стоит четко понимать свои возможности и здраво оценивать количество работы, которое они могут выполнить в разумные сроки. Первые несколько раз подобные оценки могут даваться нелегко, и это еще один повод держаться безопасной стороны.
Избегайте личностных конфликтов
Механики безусловно представляют собой важную часть подготовки спринта, однако гораздо большую угрозу представляют собой межличностные отношения. Планирование непосредственно связано с отношениями между членами команды, и всегда есть много моментов, которые могут пойти и, скорее всего, пойдут не так, как надо.
• Потеря интереса. Планирование должно быть быстрым, интересным и мотивирующим. Обычно если команде скучно, это значит, что команда либо не видит пользы в планировании, либо же Скрам-мастер не сумел заинтересовать ее участников. Несколько наиболее распространенных причин включают отсутствие понимания того, что требуется от команды, а также эгоистическое поведение отдельных участников, которые хотят, чтобы оставшиеся участники беспрекословно следовали их указаниям.
• Споры. Здоровое обсуждение – важная часть планирования, но споры исключительно контрпродуктивны и очень отвлекают от насущных задач. Не забывайте, что на этом шаге главное действующее лицо – это владелец продукта, от решений которого зависит то, как будет действовать команда.
• Фрустрация. Дайте команде возможность быть услышанной! Есть мало вещей, которые столь же контрпродуктивны и раздражающи, как игнорирование. Члены команды несут ответственность за реализацию проекта, и без них появление продукта будет невозможным. Поэтому, если любой из них хочет что-то сказать, лучше дать им такую возможность.
• Поиск решений. Если команда разработчиков начинает вдаваться в большое количество деталей при планировании, то существует вероятность того, что они пытаются найти решение. Задача планирования заключается в том, чтобы решить, что команда может выдать в конце спринта. Подробности того, как это сделать, лучше оставить для следующих этапов.
• Давление. Не стоит заставлять команду браться за большее количество работы, чем она может выполнить. Члены команды должны сами определить объемы работ. Это священное право членов команды, и его стоит беречь: если команда постоянно будет браться за слишком масштабные задачи или перетруждаться, последствия будут отрицательными.
Выработка хороших практик
Скрам-мастер несет ответственность за налаживание взаимоотношений между участниками и за формальные составляющие фазы планирования, но выработка хороших практик является коллективной задачей. Скрам-мастер должен стараться предотвратить возникновение плохих практик, но если это произойдет, то команде придется приложить усилия, чтобы преодолеть их. Один человек не может нести ответственность за работу всего коллектива.
• Никогда не переходите к планированию в отсутствие Владельца продукта и представителей ключевых отраслей.
• Избегайте соблазна принять плохо написанные или неподготовленные пользовательские истории, даже если вам кажется, что у вас будет время доработать их в дальнейшем.
• Не пытайтесь спасти ситуацию, интерпретируя истории, пытаясь связать их и вырабатывая критерии оценки на лету.
• Убедитесь в том, что все проблемы и возможные вопросы разрешены прежде, чем вы будете двигаться дальше. Иногда Владельцу продукта и команде может потребоваться для этого время.
• Если процесс забуксовал, примите меры. Старайтесь сохранять темп. Перейдите к следующему этапу и, если нужно будет, вернитесь к проблемному этапу позже.
• Не разрешайте никому и особенно Скрам-мастеру решать за команду, что делать и диктовать другим свои решения.
Блистательный пример
Скрам-команда выпустила новый электронный инструмент для управления корпоративными данными, и Владелец продукта запросил добавление новой функциональности. Во время планирования спринта ведущий IT-специалист оценил, что для реализации функциональности понадобится не больше 10 минут. Несмотря на то что график спринта был уже довольно напряженным, команда согласилась включить в работу эту небольшую задачу. На практике оказалось, что для реализации задачи требуется имплементация нескольких сложных процессов. Понадобились дни, чтобы учесть все возможные проблемы и провести необходимые тесты. Причиной было то, что представители команды по тестированию не присутствовали при планировании.
Небольшое изменение так и не удалось реализовать в ходе спринта, и две другие исключительно важные задачи пострадали от этого. Отсутствие представителей команды по тестированию означало, что решение было принято на основе недостаточной информации. Соответственно, невзирая на все старания, спринт закончился неудачей.
Владелец продукта был крайне недоволен, но вся команда получила очень полезный урок: в отсутствие представителей всех направлений вы можете полагаться только на удачу, а она улыбается далеко не всегда.
Рабочий процесс
Как только планирование завершено, наступает время для самой работы. С точки зрения команды, то, что происходит в это время, очень зависит от самой сути проекта. Главная цель команды – выпустить тот продукт, который был запланирован и утвержден. Скрам-мастер в это время играет важную роль, помогая команде следующим образом.
• Сохранение заданного темпа. Это кажется очевидным, но слишком часто упускается из виду. Всем ясно, что именно они должны делать? Нужна ли команде какая-то дополнительная информация? Чего члены команды ожидают друг от друга, как связана работа одних с другими? Даже опытным специалистам может понадобиться напоминание, что нужно обсуждать проблемы. Скрам-мастеру придется постоянно разрешать эти вопросы.
• Устранение препятствий (блокеров). Это наиболее широко известная задача Скрам-мастера и вопрос номер один на ежедневной встрече: есть ли у вас какие-то затруднения? Речь идет о том, что нужно сделать, чтобы работа шла постоянно. Задачи могут приходить в любой форме, от распутывания проводов под столами до помощи Владельцу продукта в составлении отчета для старшего руководства.
• Обеспечение обмена информацией. В обе стороны – как из команды, так и в команду. От команды ожидается информация обо всех взаимодействиях, трудностях и, разумеется, отчеты о ходе работы. В свою очередь, команда разработчиков будет ожидать ответы на вопросы со стороны владельца продукта и ясный и доступный журнал. Содействие этому двустороннему потоку информации, работа с людьми и обработка всех данных могут занимать весь рабочий день и быть непростой задачей.
• Отслеживание прогресса. Диаграмма сгорания и диаграмма сжигания – два наиболее полезных инструмента для отслеживания прогресса проекта. Диаграмма сгорания показывает, сколько задач осталось сделать, а диаграмма сжигания – сколько работы было уже сделано. Мы рекомендуем использовать как минимум диаграмму сгорания задач и обновлять ее на ежедневной основе.
• Подготовка к следующему спринту. Обновляется ли журнал регулярно? Хорошо ли сформулированы и проработаны пользовательские истории? Зарезервированы ли необходимые помещения для следующей встречи и приглашены ли на них необходимые люди? Все ли нормально с логистикой проекта? Ничего сложного, но это постоянно требующие внимания вопросы, за которыми нужно следить для избежания неприятных ситуаций. Лучше все продумать наперед.
Блистательный пример
Для отслеживания и демонстрации прогресса работы наиболее широко применяется диаграмма сгорания задач. Эта диаграмма показывает, сколько задач осталось до завершения спринта. На диаграмме изображены два графика:
• история выполнения задач во времени;
• целевая линия выполнения задач.
Начальная точка – это все задачи, которые должны быть выполнены за отведенное время. На рисунке ниже точками показана диагональная линия, начинающаяся от суммарной оценки задач до нуля, проходящая через все время, отведенное на спринт. Это целевая линия выполнения задач, на которую и следует опираться.
Упрощенно, если линия, отображающая прогресс работы, окажется выше этой диагонали – значит, налицо отставание от графика, а если ниже – команда выполняет работу раньше срока.
Точки, которые соединяет пунктирная линия, – это количество оставшейся работы. Как только задача выполнена, ее «стоимость» в баллах сложности отнимается от прошлого числа и отображается на графике. Некоторые задачи могут не быть выполнены в срок, поэтому график наверняка не получится ровным.
На примере ниже видно, что вначале команда испытывала некие трудности, но смогла завершить работу вовремя. Нет ничего необычного в том, что прогресс отклоняется от идеальной линии – но любые заметные отклонения свидетельствуют о том, что дела идут слишком хорошо или очень плохо.
Рис. 6.1. Блистательная диаграмма сгорания задач
Блистательная мысль
Если в конце спринта вас могут ожидать плохие новости, например, связанные с невыполнением поставленных задач, то владелец продукта должен узнать об этом как можно раньше, чтобы ожидания всех сторон соотносились с реальной ситуацией. Никогда не забывайте о важности перспективы.
Приближаясь к концу
Конец спринта всегда ближе, чем может показаться, и поэтому всегда стоит подготовиться к нему заранее. Скрам-мастер должен приготовить все для обзора продукта, ретроспективы для анализа действий команды и, конечно же, следующего спринта. Помимо планирования самих собраний необходимо учитывать вопросы, связанные с логистикой. Часто приходится прикладывать значительные усилия для того, чтобы собрать всех в одном месте и в одно и то же время.
В одном вы можете быть уверены наверняка: что-нибудь обязательно пойдет не по плану. Никто не может предсказать будущее, и поэтому невозможно предвидеть миллионы причин, которые могут нарушить план спринта. Начиная с непредвиденной болезни и заканчивая внезапным компьютерным вирусом, всегда будут вещи, которые сумеют сорвать самый совершенный план. Именно поэтому ключевой результат спринта – реализация договоренностей с владельцем продукта вместе с получением ценной обратной связи. Команда должна быть заинтересована в том, чтобы реализовать цели, поставленные в начале спринта, даже если для этого потребуется потратить чуть больше усилий, чем предполагалось первоначально.
За день или два до окончания спринта Скрам-мастеру следует перейти в состояние повышенной готовности и постараться определить список вопросов, которые должны быть разрешены для успешной реализации спринта.
Блистательная мысль
Планируйте заранее и старайтесь забронировать все, что нужно для Скрам-событий, как можно раньше, особенно когда речь идет о спринте, растянутом во времени. Старайтесь придерживаться одного и того же дня недели и того же времени. Постарайтесь сделать так, чтобы спринт стал частью привычного распорядка участников, и не меняйте этот распорядок без крайней нужды.
То же время и то же место – залог идеального спринта.
Это самое лучше время для того, чтобы обратить внимание группы на текущие проблемы и обсудить их в ходе ежедневной Скрам-встречи. Более того, это оптимальное время для определения и решения дополнительных проблем. Следите за поведением членов команды и обращайте особое внимание на тех, кто выглядит беспокойно или прячет глаза. Не забывайте задавать наводящие вопросы и помните, что Скрам-мастер является ключевым лицом в организации проекта, от деятельности которого зависят взаимоотношения команды разработчиков и Владельца продукта.
Конец спринта
Если результаты спринта не достигнуты, то это не очень хорошие новости, однако и не конец света. Конечно же, было бы неплохо понять, что именно пошло не так, и избежать этой проблемы в дальнейшем: этот принцип заложен в основу Agile с упором на наблюдения и адаптацию. И, конечно же, есть большая разница между факторами, которые невозможно контролировать (например, болезнью), и факторами, которые поддаются нашему контролю (например, разумное дозирование работы). Любые пользовательские истории, которые не были проработаны, могут быть перенесены на следующий спринт, но не стоит думать, что их проработка окажется легкой задачей. Обычно наилучшим подходом считается тот, при котором проработку этих историй придется начинать с нуля, чтобы избежать недооценки предстоящего массива работ.
Блистательная мысль
В конце каждого спринта общее количество баллов сложности выполненных пользовательских историй называют скоростью работы команды. Со временем средняя скорость становится более достоверным показателем.
Команда может в дальнейшем оценивать, сколько задач имеет смысл брать на следующий спринт.
В конце спринта вы уже имеете то, что имеете. К тому времени Скрам-мастер и опытные члены команды уже подумали о том, как прошел спринт, и сделали заметки о том, что прошло хорошо и плохо и на что нужно обратить особое внимание в следующий раз. Ведение этих заметок не обязательно должно быть буквальным – нет необходимости стоять у доски и измерять производительность труда.
Изучение уроков – жизненно важная составляющая гибкого процесса разработки, и лучшие Скрам-команды постоянно анализируют и улучшают свои рабочие практики. Мысленных замечаний обычно вполне хватает, и динамика взаимоотношений в команде представляет собой отличный источник информации. Как члены команды взаимодействуют друг с другом во время дневного Скрама? Как они разговаривают друг с другом и как обстоят дела в офисе? Кто настойчиво делает вид, что ему все равно, а кто явно обеспокоен? Что насчет групповой динамики, слухов и громких заявлений?
Стоит сосредоточиться на сообщении членов команды о том, что было закончено. Вне зависимости от того, какой был результат (или какого не было) – будут высказаны комментарии и вопросы. Иногда обсуждения продуктивности и результатов команды бывают даже слишком бурными. Наилучшая стратегия здесь – быть реалистами, однако картина сделанной работы должна быть позитивной. Расскажите о том, как прошел спринт и как вы пришли к этим результатам.
Окончание спринта – обычно самая напряженная и загруженная часть для Скрам-мастера и команды. Все напряжены, так как ожидания должны быть оправданы. Нужно осветить много тем, а еще потом предстоят обзор итогов, ретроспектива и планирование спринта. Важно, чтобы команда держалась вместе и стояла на своем, даже если ее приперли к стенке. Будьте профессиональны и последовательны; сосредоточьтесь на самых важных аспектах. Успокойтесь. Будьте терпеливы. И все будет хорошо.
Блистательный пример
Неопытному Скрам-мастеру необходимо выйти к группе из приблизительно 30 человек, включая нескольких высокопоставленных членов организации, которые ожидают оценки спринта, и сообщить им, что за последний трехнедельный спринт не была проработана ни одна пользовательская история. Скрам-мастер выглядит очень усталым после бессонной ночи, и очевидно, что ему очень неприятно сообщать о провале.
Невзирая на это, Скрам-мастер подробно объясняет, что произошло, и сообщает, какие выводы команда вынесла из спринта и как она собирается избегать неудач в дальнейшем. За этим следует нечто неожиданное. Начальство хвалит Скрам-мастера и его команду. Высокопоставленные члены организации оценили их честность и готовность учиться на ошибках. Более того, они предлагают им поддержку и ресурсы, чтобы выйти из этой ситуации.
Даже Скрам-проекты иногда терпят неудачи. Открытость – лучший подход в этих случаях, использование которого вызывает уважение. Всегда лучше выработать план по исправлению ошибок, чем потратить это время на придумывание оправданий.
Завершающие слова
Если в конце спринта Скрам-мастер и Владелец продукта выглядят спокойными, значит, дела идут хорошо. Мир и спокойствие – это священный Грааль Скрама: все его ищут, но мало кто находит. Когда Скрам работает хорошо, он выглядит очень легким в применении. В реальности идеал недостижим. Нет верного или неверного способа применять Скрам, но это всегда можно делать лучше. Даже если дела идут прекрасно, постоянно ищите способы для усовершенствования.
Скрам-команду в первую очередь будут оценивать по результату, но есть и другие положительные признаки. Один из них – полное взаимопонимание между командой разработки и владельцем продукта. Второй – самоорганизующаяся команда, способная принимать решения. Еще один – когда старшим менеджерам, конечным пользователям и прочим заинтересованным сторонам нравится, а главное, совершенно понятен ход работ над продуктом. Чего еще желать, если рабочий продукт выпускается в срок, ретроспективы выявляют только легко устранимые проблемы? Разве что не заскучать, почивая на лаврах.
Дух Скрама побуждает искать улучшения. В самом начале Скрам-проекта может быть очень много вариантов для совершенствования – иногда даже будет казаться, что некоторые проблемы слишком серьезные, но решать их интересно и даже иногда весело. Парадоксально, но и сам Скрам может стать препятствием. Команда может обнаружить, что именно эта методология сдерживает их дальнейшее развитие. Не все добираются до этой точки. Для большинства из нас важно искать что-то новое. Не останавливайтесь в своем поиске лучшего.
Именно практика приводит к совершенству.
Блистательный итог
• Устанавливайте планку высоко. Постоянно обновляйте журнал, выработайте критерии принятия и используйте в спринтах только хорошо написанные пользовательские истории.
• Скрам-мастер организует команду, помогает ей, разрабатывает новые практики и решает проблемы.
• Хорошие показатели помогают принимать взвешенные решения и обеспечивают отличный доклад.
• Не вмешивайтесь в работу команды – они прекрасно знают, как решить проблемы.
• Учитесь на ошибках и просчитывайте наперед.