Глава 6. Пора в путь: Скрам день за днем

Введение

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

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

Если вы не будете привносить свои изменения, пусть даже небольшие, то вы не поняли сути. Случается так, что желание менять что-то отступает, сменяясь готовностью принимать неудобный статус-кво. Иногда боязнь раскачивать лодку препятствует даже незначительным изменениям. Иногда, что может показаться абсурдным, люди даже считают текущее положение дел близким к идеальному!

Примите цикл жизни Скрама, но не идите ради этого на компромиссы или отказ от изменений. С одной стороны, этапы Скрама очень легко предсказать, так как в теории они остаются одними и теми же, но в то же время на практике они всегда очень сильно различаются.

Нет! Не пробуй. Сделай.

Мастер Йода

 

Подготовка

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

Блистательная мысль

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

Избегайте такого.

Доработка журнала

Раньше доработку или уточнение журнала называли «причесыванием» (grooming) по аналогии с причесыванием волос, но со временем термин сменился по очевидным причинам. Кто-то продолжает использовать это старое название, но вне зависимости от этого сама практика поддержания журнала требований продукта в актуальном состоянии только положительно сказывается на бизнесе и впоследствии на конечном пользователе.

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

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

Блистательная мысль

Владелец продукта отвечает за качество пользовательских историй и состояние журнала требований продукта. Если он делает свою работу хорошо, планирование спринта пройдет гладко. Если нет, то в ходе встречи по планированию скрипта постоянно нужно будет отвлекаться на уточнения.

Критерии принятия

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

Явное недопонимание – самая большая проблема, но, как правило, с нею разбираются быстро во время сеансов доработки журнала. Однако неявные недоразумения встречаются куда чаще; и так как они накапливаются, то могут выясниться на поздних этапах работы. Простейший способ избежать этого – совместно определить критерии принятия заранее; создать совместное представление того, как Владелец продукта будет судить о том, что выпуск продукта соответствует его видению. Это должно быть сделано не только на макроуровне (каждый спринт), но и для каждого требования (например, каждая пользовательская история).

Лучший способ избежать проблем – определить всей командой эти критерии принятия. Есть много вариантов, как это сделать, но, если у вас возникают проблемы, можно просто ответить на вопрос: я знаю, что я получу <что-то>, когда <что-то сделано>. Это «что-то» оказывает ощутимое влияние, а «что-то сделанное» может быть положительным или отрицательным. Используйте это для прогнозирования того, что скажет о продукте Владелец продукта, когда вы предоставите ему результат. Начинайте сначала.

Типы критериев успеха могут включать в себя:

• простое описание желаемого результата;

• ключевые тезисы;

• условия принятия работы;

• стиль языка Gherkin^[1] в формате «Дано», «Если», «То».

Блистательный пример

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

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

 

Приоритезация в действии

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

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

Лучшее – враг хорошего.

Вольтер

Оценивание в действии

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

• Неясные требования: расплывчатые пользовательские истории сложно оценить и, что куда более важно, сложно реализовать. Получите разъяснения.

• Слишком большая и сложная задача: если часть работы требует для реализации больше, чем несколько дней, сроки выпуска продукта станут излишне неопределенными. Разбейте задачу на части! Кроме того, требования к таким объемам работы обычно менее понятны.

• Неверно определенные критерии принятия: если пункт назначения неясен, трудно измерить, сколько времени потребуется, чтобы попасть туда. Даже с четкими критериями принятия кому-то может показаться, что эта часть работы огромна, в то время как другие решат, что она совсем невелика.

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

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

Прежде чем углубиться в спринт и его проблемы, нет необходимости в многочисленных проверках. Главное, убедитесь в трех вещах:

1. Задачи в журнале распределены по порядку их выполнения, и журнал согласован с владельцем продукта.

2. Критерии принятия (по крайней мере, некоторые из них) написаны совместно с командой.

3. Все пользовательские истории оценены.

Блистательный пример

 

Блистательное определение

В случае оценочного подхода один из наилучших вариантов – повышать баллы в соответствии с последовательностью чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 100… Все на меньшем конце последовательности будет означать задачу с наименьшими трудозатратами, и по возрастающей до самых объемных задач в конце. Такой метод прекрасно работает со многими Скрам-техниками, особенно с использованием для планирования покерных карт^[2].

Все задачи, которые очень сложны, получают оценку 100, чуть менее сложные пользовательские истории – 55, а 34 – те, которые требуют особого внимания.

Начало спринта

Спринт всегда должен начинаться с планирования спринта. Это планирование отличается от планирования релиза и особенно от планирования проекта. Планирование спринта – очень важный шаг, на котором должна присутствовать вся команда. Именно планирование является залогом успеха спринта, но оно же нередко становится причиной неудачи.

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