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

Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для использования продукт, для других – продукт, предназначенный для тестирования закрытой группой. Помните, что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет абсолютно правильных подходов – выберите тот, что лучше подходит вам.

Добавление характеристик

Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же, именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну характеристику, проверенную практикой.

Получение информации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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