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

В главе 10 «Приоритизация по финансовой отдаче» мы более подробно поговорим о себестоимости и приоритизации на основе финансового вознаграждения относительно затрат.

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

• Знания о продукте.

• Знания о проекте.

Знания о продукте — это знания о том, что должно разрабатываться. Это знания о тех функциях, которые должны включаться, и о тех, которые не должны включаться. Чем больше знаний о продукте имеет команда, тем лучше она принимает решения о характере и функциях продукта.

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

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

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

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

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

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