Блистательная мысль
Девяносто девять из ста Скрам-команд начинают свой первый спринт на излишне оптимистичной ноте и не особенно уделяют внимание планированию. Либо пользовательские истории не до конца проработаны, либо не сформирован план действий, либо не хватает критериев принятия – а то и все вместе. Девять из десяти команд повторят те же ошибки и на втором спринте.
Избегайте такого.
Раньше доработку или уточнение журнала называли «причесыванием» (grooming) по аналогии с причесыванием волос, но со временем термин сменился по очевидным причинам. Кто-то продолжает использовать это старое название, но вне зависимости от этого сама практика поддержания журнала требований продукта в актуальном состоянии только положительно сказывается на бизнесе и впоследствии на конечном пользователе.
Окончательное решение насчет распределения приоритета задач принимает владелец продукта, поэтому, так как это творческий процесс, точные рекомендации тут дать сложно. Не пытайтесь расположить все в идеальном порядке. Куда важнее поддерживать актуальность бизнес-требований, например пользовательских историй. Встречи с обсуждением всех доработок журнала и подготовки пользовательских историй для спринта должны проходить регулярно, и в идеале на них должны присутствовать по одному представителю каждой дисциплины из команды.
Некоторые команды просматривают журнал на предмет возможных обновлений каждый день, другие – намного реже. Но отсутствие доработки, без сомнений, приведет к проблемам на ближайшем спринте. Постоянная работа над журналом обязательно принесет свои плоды, но тут необходимо достичь определенного равновесия. Некоторые спринты будут посвящены реализации необходимых функций, а не тому, что полагают важным на данный момент бизнесмены.
Блистательная мысль
Владелец продукта отвечает за качество пользовательских историй и состояние журнала требований продукта. Если он делает свою работу хорошо, планирование спринта пройдет гладко. Если нет, то в ходе встречи по планированию скрипта постоянно нужно будет отвлекаться на уточнения.
Самый быстрый способ для команды разработки начать работу не так – это не до конца разобраться в требованиях.
Явное недопонимание – самая большая проблема, но, как правило, с нею разбираются быстро во время сеансов доработки журнала. Однако неявные недоразумения встречаются куда чаще; и так как они накапливаются, то могут выясниться на поздних этапах работы. Простейший способ избежать этого – совместно определить критерии принятия заранее; создать совместное представление того, как Владелец продукта будет судить о том, что выпуск продукта соответствует его видению. Это должно быть сделано не только на макроуровне (каждый спринт), но и для каждого требования (например, каждая пользовательская история).
