Цитаты из книги «Agile: оценка и планирование проектов»

Наконец, если позволяет время, нескольким привлекательным функциям необходимо присвоить такой

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

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

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

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

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

На рис. 3.2 показана петля обратной связи от новой модификации продукта к этапу определения условий удовлетворенности в начале обоих процессов планирования релиза и итерации.

Agile-команды достигают этого, осуществляя планирование для трех четко определенных горизонтов — релиз, итерация и текущий день. Взаимосвязь между этими (и другими) горизонтами планирования показана в виде так называемой луковицы планирования на рис. 3.1.

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

Аgile-команда поставляет какой-либо результат после каждой итерации Более важным, чем выбор определенной длины итерации, является то, что в процессе итерации команда превращает одно или несколько неточно сформулированных требований в скомпонованную, протестированную и потенциально готовую к поставке программу. Конечно, многие команды не поставляют результаты каждой итерации пользователям — цель заключается в том, чтобы это в принципе можно было сделать. Это означает, что команда последовательно добавляет одну или несколько небольших функций во время каждой итерации, но каждая добавленная функция встроена в продукт, протестирована и имеет качество, необходимое для релиза.