Вальсируя с медведями
Шрифт:
Мы используем здесь термин «показатели завершенности» но отношению к определенному классу показателей состояния, показывающему состояние исполнения проекта. Совершенная система показателей завершенности (если только такие существуют) уверенно покажет, что выполнено 0% в начале проекта и 100% в конце успешно завершенного проекта. А между ними она будет показывать постепенно возрастающие величины от 0 до 100. В лучшем из миров анализ после завершения проекта приведет к выводу, что значения безупречной системы показателей на каждой стадии проекта точно и ясно предсказывали, сколько еще остается времени и усилий.
Понятно, что совершенных систем показателей завершенности не бывает, но существуют несовершенные, которые невероятно полезны. Мы – сторонники
• завершение описания граничных условий проекта
• освоенный объем функционала (ООФ) [26]
Эти показатели дают нам способ отслеживать пять главных рисков, рассмотренных в главе 13. Первая система защищает от главного риска, состоящего в нарушении спецификаций. Вторая представляет собой общий показатель чистого прогресса, используемый для отслеживания влияния остальных четырех главных рисков.
26
Earned Value Running, EVR (прим.ред.)
Система – это нечто, предназначенное для преобразования входов в выходы, как показано на следующей диаграмме:
Это – правильное описание, будь система, о которой идет речь, государственным ведомством, бухгалтерской компанией, типичной IT-системой, живым человеком или селезенкой… то есть чем бы то ни было, что мы склонны назвать словом «система».
В этом смысле у IT-систем есть отличие: они преобразуют потоки входных данных в потоки выходных данных. Традиционно задача спецификации таких систем сводилась почти полностью к определению правил преобразования, методики и подходов, применяемых системой при преобразовании входных потоков в выходные. Часто в процессе спецификации пропускают строгое и подробное описание самих потоков. Этот пропуск имеет некоторые непреодолимые причины: работа по определению этих потоков часто рассматривается как задача проектирования, которую программисты будут решать на более поздних стадиях. Она может оказаться очень затратной по времени. Откладывание полного определения разумно в проектах, где можно быть уверенными в успешном завершении проекта, но есть ведь и менее везучие проекты, где подробное определение потоков невозможно успешно провести, поскольку это вызовет обострение некоторых конфликтов среди участников проекта. Существование таких «дефективных» проектов вынуждает нас запихивать работу по описанию потоков обратно на раннюю стадию жизненного цикла с намерением заставить конфликт всплыть на поверхность пораньше, не позволяя ему оказаться замазанным на начальных стадиях и неожиданно появиться позднее.
При этом подходе граничные потоки определены, но не спроектированы. Под этим мы подразумеваем, что они разложены до уровня элементов данных, но еще не упакованы в какой-то формат. Цель раннего обращения к проблеме состоит в том, чтобы все стороны согласились с составом потоков. В большинстве проектов такое согласие удается получить в пределах первых 15% времени работы над проектом. Когда согласие еще не достигнуто, а проект явно прошел 15%-ную отметку, то это с очевидностью указывает на то, что существует либо конфликт между участниками проекта (нет единого мнения о том, какую систему строить), либо прискорбная ошибка в оценке длительности проекта. В любом случае отсутствие согласия представляет собой проявление риска, причем одного из главных. Нет смысла работать над чем-то другим, пока не будет завершено описание граничных элементов. Если этого не произойдет, нет лучшего выбора, чем прекращение проекта.
Освоенный объем функционала – это система показателей готовности проекта. Она должна говорить вам, насколько далеко вы продвинулись по пути от 0% готовности к 100% готовности.
Поскольку ООФ тесно связан с инкрементной разработкой проекта [27] , мы решили отложить подробное определение этой метрики до обсуждения метода инкрементной разработки в следующей главе. На этапе первого
27
Инкрементная разработка, инкрементный метод (Incremental development) – разработка модели или прочих артефактов системы в виде ряда законченных версий, каждая из которых выполнена на определенном уровне детализации и функциональности, причем таким образом, что каждая новая версия вносит дополнения в предыдушую. Этот метод хорош тем, что каждую модель сравнительно несложно оценить и отладить (попросту внеся небольшие изменения в предыдущую версию) (прим. ред.)
Допустим, что мы заглянули внутрь системы, которую вы намереваетесь построить, и изображаем ее разбитой примерно на сотню основных частей:
Если вы теперь начнете строить систему просто по методу «большого взрыва» (строить все эти части, соединять и тестировать их, поставлять их все вместе, когда все будут готовы), то вашей единственной метрикой готовности будет окончательная проверка при приеме проекта в целом. В виде функции от времени ваша показанная готовность будет выглядеть так:
Вы проявляете 0%-ную готовность до самого конца, а затем внезапно она сменяется 100%-ной готовностью. Единственной причиной верить, что дело обстоит иначе (скажем, верить в некоторый момент, что вы находитесь в состоянии 50%-ной готовности), являются косвенные признаки.
ООФ предназначен для обеспечения объективными свидетельствами частичной готовности, которые позволят вам нарисовать такую картинку и поверить в нее:
< image l:href="#"/>Все равно будет период на начальной стадии, когда прогресс подтверждается только верой. Однако уже намного раньше середины проекта, вы будете получать довольно надежные свидетельства от ООФ о частичной готовности.
ООФ зависит от вашей способности строить систему методом инкрементной разработки, скажем, используя выбранные подсистемы, составленные из частей системы и называемые версиями. Так, версия 1, например, может быть такой:
< image l:href="#"/>Здесь вы соединяете (как можно лучше) входящие <……> частичным продуктом. Разумеется, частичная система <……> все, что должна делать полная система, но что-то <……> можно тестировать. Итак, вы это тестируете. Вы проводите испытания версии 1 и, когда она их проходит, вы заявляете <……>
Версия 2 имеет больше функций:
Версия – % от общего ООФ
1 – 11%
2 – 19%
3 – 28%
4 – 38%
5 – 51%
6 – 60%
7 – 72%
8 – 81%
9 – 94%
10 – 100%
Теперь с момента, когда версия 1 проходит свои приемные испытания (ПИ1), вы можете построить кривую, показывающую ожидаемую дату каждого следующего приемного испытания (ПИ) [28] . По мере прохождения этих испытаний можно в такой форме проследить ожидаемый ООФ и соотнести его с реальным:
Проявление любого из главных рисков (или какого-то еще серьезного риска) вызовет заметное отставание реального завершения версий от ожидаемого.
28
Version Acceptance Test, VAT (прим. ред.)