Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер

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

Расскажи мне историю

Пользовательские истории (user story) – короткие простые описания характеристик продукта с точки зрения человека, который собирается его использовать. Обычно это пользователь или покупатель. Пользовательские истории обычно следуют простому формату.

Будучи <тип пользователя>, мне нужно <цель> по <причина>.

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

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

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

ДАТА ДОСТАВКИ

БУДУЧИ НЕПОСТОЯННЫМ ПОКУПАТЕЛЕМ

МНЕ НУЖНА ГАРАНТИРОВАННАЯ ДАТА ДОСТАВКИ В МОМЕНТ СОВЕРШЕНИЯ ЗАКАЗА

ПО ПРИЧИНЕ ТОГО, ЧТО Я ДОЛЖЕН ЗНАТЬ, КОГДА ОЖИДАТЬ СВОЙ ЗАКАЗ, ЧТОБЫ ОН НЕ СГНИЛ ПОД ДВЕРЬЮ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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