Она также имеет название («Номинировать видео на достижение»), которое дает возможность команде легко сослаться на эту конкретную историю, когда о ней заходит речь.

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

Не менее важно и то, чего в истории нет. Например, в ней ничего не говорится про какой-либо редактор критериев (добавленных командой без необходимости) или иных ненужных функций. Вот почему истории пользователей – эффективный инструмент для борьбы с золочением. Что происходит, когда команда описывает пользовательские истории, прорабатывает их с владельцем продукта (а также пользователями и другими заинтересованными лицами – всеми, у кого есть мнение о данном функционале) и ориентируется на них в ходе разработки? Если они применяют такую процедуру, то вряд ли «раздуют» программное обеспечение лишними функциями.

Истории пользователей также дают командам простой способ управлять бэклогом. У многих эффективных agile-команд в бэклоге содержатся почти исключительно пользовательские истории.

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

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

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

Критерии удовлетворенности, как и пользовательские истории, кажутся очень простыми, но выполняют сложную задачу. Большинство команд формулируют их для каждой пользовательской истории, вписывая конкретные операции, которые пользователь должен иметь возможность делать с программой, уже после создания такой истории. Обычно критерии удовлетворенности помещаются на задней части той же самой карточки (размером 7 × 12 сантиметров), что и пользовательская история. Владелец продукта обычно имеет право формулировать критерии удовлетворенности или высказывать свои замечания, если критерии уже сформулированы.

Критерии удовлетворенности для пользовательской истории «достижения» могут выглядеть следующим образом.

Рис. 5.3. Критерии удовлетворенности, написанные на обратной стороне карточки с пользовательской историей

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

Критерии удовлетворенности дают команде конкретное определение понятия «готово». Они позволяют команде и владельцу продукта понять, что обработка истории и ее реализация завершены. История может считаться готовой, только если выполнена вся работа, необходимая, чтобы ее понять, построить, испытать и развернуть. После этого пользователь может открыть рабочее программное обеспечение и проверить, что все критерии выполнены именно так, как описано в обзоре спринта. Пока член команды не может этого сделать, разработка пользовательской истории не считается завершенной и он продолжает трудиться над ней (помните о сфокусированности как одной из ключевых ценностей Scrum?). Когда работа закончена, история на доске задач перемещается из столбца «сделать» в столбец «готово». Дело сделано!

Очки историй и скорость команды

Во время планирования спринта команда совместно определяет, сколько они смогут сделать в текущем цикле, чтобы создать программное обеспечение для поставки по его итогам. Но как именно команда это делает?

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

Нет никаких жестких правил, определяющих, сколько баллов (очков) следует присваивать той или иной истории. Некоторые команды назначают от 1 до 5 баллов за любую пользовательскую историю. Максимальное значение «пять» выбрано произвольно. Другие команды дают своим историям от 1 до 10 баллов или используют другие пределы, не меняющиеся от спринта к спринту. Некоторые команды используют числа из последовательности Фибоначчи либо значения экспоненциальной зависимости. Вы можете выбрать любую из работающих схем, при которой все в команде чувствуют себя комфортно. Одна история, оцененная в 3 очка, должна требовать столько же работы, сколько и другая история, оцененная так же. Когда ваша команда оценивает в очках все истории, над которыми она работает, ее члены начинают понимать, на сколько очков они могут выполнить (или «сжечь») историй в текущем спринте. Если ваша команда завершает за один спринт в среднем историй на 25 очков, то говорят, что ее скорость составляет 25 очков историй за спринт.

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