Выработка критериев принятия

Как мы узнаем, что мы сделали все? Это ключевой вопрос, и именно с него следует начинать дискуссию, следующую за обсуждением пользовательской истории. Чтобы действовать эффективно, нужно знать, когда остановиться. Когда заканчивается наш проект? Сколько сил мы должны вложить в него? Как избежать переработки и неизбежной фрустрации? Для успешного использования пользовательских историй мы должны выработать критерии принятия – предпосылки к проекту, которые должны быть реализованы, чтобы история была оценена как выполненная.

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

• Дата доставки – всегда будет на следующий рабочий день после заказа.

• Если заказ был оставлен в субботу, то доставка будет в понедельник.

• Заказы на следующий рабочий день принимаются до трех часов по полудню.

• Клиент получает подтверждение о заказе по электронной почте.

• Все продукты в наличии доставляются по этим правилам.

• Мы сообщаем день заказа, но не точное время.

• У пользователя должна быть возможность оставить комментарий для курьера.

• Ожидаемый день доставки будет показан на экране при заказе.

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

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

 

Разделяя истории

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

Другой подход заключается в том, чтобы написать новую историю – так называемое разделение историй. Типичный пример – ситуация, когда владелец продукта считает некоторые из критериев принятия необязательными и хочет выработать новую историю, включающую в себя дополнительные характеристики продукта. Как только новая история написана, она может быть включена в журнал требований (бэклог) вместе со всем остальным.

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

 

– И нашему пользователю сразу будет понятно, где аварийный выход!

 

Когда размер имеет значение

Итак, у нас есть видение, бэклог, MVP, также набор продуманных пользовательских историй вместе с четкими критериями принятия. Отличная работа. Теперь стоит задаться вопросом: сколько времени и сил потребует практическая реализация всего этого? Обычно ответ на этот вопрос дают руководители проекта или профильные специалисты. Однако в Agile-проектах этим вопросом занимаются люди, непосредственно ответственные за реализацию проекта. Они не только смогут предоставить более реалистичную оценку. Это также позволит сплотить команду. Конечно же, от размера каждой пользовательской истории зависят сроки реализации MVP, как и проистекающие из этого характеристики. Тем не менее это все еще прекрасный способ оценить возможные проблемы с реализацией конкретных этапов проекта. Если вы видите, что члены команды чешут затылки, тяжело вздыхают и качают головами, то это не очень хороший знак.

Ряд оценочных техник исключительно хорошо подходит для Agile-проектов, например:

• Размеры одежды. Присвойте ярлычки S, M, L, XL и XXL каждой составляющей проекта, чтобы оценить приблизительное количество ресурсов, которое потребует ее реализация. Отличный способ для начинающих, который, впрочем, далеко не всегда точен.

• Оценочный подход. Используйте фиксированную шкалу, чтобы оценить трудозатраты для реализации составляющих проекта, например, на шкале от одного до ста 1 будет означать «очень легко», а 100 – «исключительно сложно». Данный подход начинает работать далеко не сразу, но у него много приверженцев.

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

 

Лучший способ выработать здравые оценки:

• Используйте открытый журнал требований.

• Не игнорируйте запутанные пользовательские истории.

• Большие, сложные и многофункциональные истории делают все интереснее.

• Надейтесь на лучшее.

• Не позволяйте сомнениям остановить вас.

• Не беспокойтесь – оценки все равно обычно бывают неверны.

 

Меньше значит больше

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

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

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

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

 

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

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