Планирование релиза и итераций в Agile
Завершив планирование на первом уровне, переходим к следующим уровням планирования в Agile. Обсудив проект и его бизнес-цели, мы определим, какая еще функциональность необходима, особенно если посмотрим на продукт с точки зрения конечного пользователя. Планирование релиза - это, в первую очередь, сфера ответственности технической компании, но в сотрудничестве с бизнесом. Несмотря на то, что мы, по идее, должны разрабатывать функционал в порядке наибольшей ценности, это не всегда возможно, и разработка эффективного плана релиза - это баланс потребности в новой функциональности и необходимости учитывать соответствующие технологические возможности, проблемы инфраструктуры, взаимозависимости и другие соображения. Первая задача сессии планирования релиза - убедиться, что у нас есть функционал, необходимый для успешного продукта. Поэтому на данном этапе критичен поиск новых функций и пересмотр существующих. Следуя начальным изысканиям в плане функционала, мы должны расставить приоритеты. Часто это очень трудно сделать, поскольку, если рассматривать в целом, каждая отдельная функция сама по себе важна. Лишь обсуждение сравнительной важности функций относительно друг друга поможет пролить свет. После того, как мы определили приоритеты в перечне функций, можно начать делить эти функции на истории. Что-то станет пользовательской историей, что-то, возможно, технической - например, потребности в новых технических инструментах, базах данных и т.д. С ними нужно обращаться тем же образом. Истории - это более детальная разбивка каждой функции на части, которые можно разработать за одну итерацию, таким образом, чтобы у каждой истории был отдельный результат. К примеру, если мне нужно разбить функцию «Принять платеж по кредитной карте», я должен написать следующие истории: «Выбрать желаемый перелет» «Ввести данные кредитной карты (номер, срок действия, защитный код)» «Проверить кредитную карту» «Подтвердить платеж» «Отправить клиенту подтверждение по e-mail» Кроме того, от бизнеса потребуется решение, какие именно платежи нужно принимать. Нужно ли принимать карты American Express? А как насчет PayPal? А электронные деньги? Поскольку ранее мы уже расставили приоритеты среди функций, то в первую очередь мы потратим время на наиболее важную функциональность, детализируя те истории, которые хотим внедрить в первую очередь. Это одно из отличий гибкой методологии: вы фокусируетесь на том, что хотите реализовать раньше, не тратя время на то, относительно чего, возможно, передумаете. Это помогает не распыляться - и не тратить лишнее время - на проработку деталей ко всему, о чем мы перед тем подумали. Теперь, когда у нас есть набор историй для этого первого набора функций, нам снова нужно расставить приоритеты - теперь среди историй, чтобы знать, с чего начать и на чем сосредоточить усилия в первую очередь. Еще раз используем пример с авиалиниями. Мы написали истории для Visa, MasterCard, American Express и PayPal, но путем неких исследований выяснили, что 68% клиентов платит при помощи American Express, 26% использует Visa, 4% - MasterCard, и лишь 2% - другие способы. Следует ли в первом релизе тратить время и усилия (откладывая другие функциональности), чтобы реализовать платежи через MasterCard? Вероятно, нет, но решение в этом случае за бизнесом. Теперь нам надо оценить истории, снова используя подход Agile. Понимая, насколько быстро можно сделать работу, мы можем оценить, сколько времени понадобится на весь объем работы по выпуску релиза. Как только мы это поймем, можно начать обсуждение, не удалить ли какой-то функционал, если это время слишком велико, либо поменять ожидания относительно релиза. Планирование итераций - это сфера деятельности технической команды, но в сотрудничестве с бизнесом. Здесь мы можем поменять направление, представить новые возможности в виде историй, расставить приоритеты в работе или даже решить, что проделанная работа годится для раннего релиза. Если мы хорошо проделали перспективное планирование (см. далее), то итерационное планирование будет очень коротким. Это тот самый момент, когда у всей команды есть возможность убедиться, что они знают, какие истории запланированы на следующую итерацию, оценить, есть ли достаточное понимание, как их реализовать, и выявить проблемы, которые могут препятствовать команде в работе.
-- Автор: Пол Элларби Оригинал: http://www.agileconnection.com/print/article/five-levels-agile-planning Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
