Майк Кон - Agile: оценка и планирование проектов

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

В проекте, где используется каскадный подход, все неопределенности, связанные с тем, что создается, пытаются устранить до решения проблемы неопределенности того, как это будет создаваться. Именно отсюда проистекает распространенное представление о том, что анализ связан с тем, чтó создается, а дизайн — с тем, как это создается. На рис. 9.1 представлены каскадный подход и agile-подход к устранению неопределенности.

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

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

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

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

• Риск срыва графика («Мы можем не успеть завершить работу к октябрю»).

• Риск увеличения затрат («Мы можем не найти аппаратные средства с подходящей ценой»).

• Риск функциональности («Мы не обязательно сможем реализовать это»).

Помимо этого, риски можно классифицировать как технологические или деловые.

Классическое противоборство в проекте наблюдается между функциями с высоким риском и функциями с высокой стоимостью. Следует ли проектной команде сначала сконцентрироваться на функциях с высоким риском, которые могут пустить под откос весь проект? Или ей лучше сосредоточить внимание на том, что Том Гилб (Tom Gilb, 1988) назвал «сочными кусками», — на функциях с высокой стоимостью, которые приносят больше всего клиентских долларов?

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

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

Наиболее целесообразная последовательность разработки функций показана на рис. 9.3. Функции с высокой стоимостью и высоким риском следует разрабатывать в первую очередь. Эти функции приносят наибольшую стоимость, а работа над ними устраняет значительные риски. Следующие на очереди — функции с высокой стоимостью и низким риском. Они приносят такую же стоимость, как и предыдущие, но менее рискованны. Как результат, ими можно заняться позднее. Возьмите за правило заниматься сначала функциями с высокой стоимостью, а риск используйте в качестве дополнительного фактора.