Подготовка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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