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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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