Пользовательский поиск

Книга Вальсируя с медведями. Содержание - Часть II Почему бы и нет?

Кол-во голосов: 0

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

ООФ (первый проход)

Освоенный объем функционала – это система показателей готовности проекта. Она должна говорить вам, насколько далеко вы продвинулись по пути от 0% готовности к 100% готовности.

Поскольку ООФ тесно связан с инкрементной разработкой проекта[27], мы решили отложить подробное определение этой метрики до обсуждения метода инкрементной разработки в следующей главе. На этапе первого прохода мы покажем только основное назначение этой системы и ее отношение к инкрементному плану проекта.

Допустим, что мы заглянули внутрь системы, которую вы намереваетесь построить, и изображаем ее разбитой примерно на сотню основных частей:

Вальсируя с медведями - pic_44.jpg

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

Вальсируя с медведями - pic_45.jpg

Вы проявляете 0%-ную готовность до самого конца, а затем внезапно она сменяется 100%-ной готовностью. Единственной причиной верить, что дело обстоит иначе (скажем, верить в некоторый момент, что вы находитесь в состоянии 50%-ной готовности), являются косвенные признаки.

ООФ предназначен для обеспечения объективными свидетельствами частичной готовности, которые позволят вам нарисовать такую картинку и поверить в нее:

Вальсируя с медведями - pic_46.jpg

Все равно будет период на начальной стадии, когда прогресс подтверждается только верой. Однако уже намного раньше середины проекта, вы будете получать довольно надежные свидетельства от ООФ о частичной готовности.

ООФ зависит от вашей способности строить систему методом инкрементной разработки, скажем, используя выбранные подсистемы, составленные из частей системы и называемые версиями. Так, версия 1, например, может быть такой:

Вальсируя с медведями - pic_47.jpg

Здесь вы соединяете (как можно лучше) входящие частичным продуктом. Разумеется, частичная система все, что должна делать полная система, но что-то можно тестировать. Итак, вы это тестируете. Вы проводите испытания версии 1 и, когда она их проходит, вы заявляете

Версия 2 имеет больше функций:

Вальсируя с медведями - pic_48.jpg

Версия  – % от общего ООФ

1 – 11%

2 – 19%

3 – 28%

4 – 38%

5 – 51%

6 – 60%

7 – 72%

8 – 81%

9 – 94%

10 – 100%

Теперь с момента, когда версия 1 проходит свои приемные испытания (ПИ1), вы можете построить кривую, показывающую ожидаемую дату каждого следующего приемного испытания (ПИ)[28]. По мере прохождения этих испытаний можно в такой форме проследить ожидаемый ООФ и соотнести его с реальным:

Вальсируя с медведями - pic_49.jpg

Проявление любого из главных рисков (или какого-то еще серьезного риска) вызовет заметное отставание реального завершения версий от ожидаемого.

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

Глава 16

Инкрементный метод для ослабления рисков

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

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

Анализ различных стратегий ослабления риска в терминах «платы за удовольствие» выглядит так: ваше удовольствие представляет собой взвешенную оценку сокращения затрат и задержек на преодоление возможных проявлений риска, а ваша плата – это затраты и задержки, связанные с самим ослаблением. Лучшей известной нам стратегией ослабления риска в терминах «плата за удовольствие» является инкрементная поставка.

Под инкрементной поставкой мы понимаем…

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

Множество преимуществ инкрементной поставки были отмечены и документированы как нами самими, так и другими авторами (см. ссылки в конце книги). Есть несколько дополнительных причин особой привлекательности этого метода для менеджеров рисков:

• Он может подтвердить гипотезы планирования проекта или доказать их несостоятельность.

• Он требует упорядоченности компонентов системы.

• Он может быть использован для оптимизации выгоды от промежуточных результатов (что особенно приятно в случае, если проект перерасходовал время и/или деньги).

• Он обеспечивает обратную связь относительно истинной эффективности разработки.

• Он дает возможность сравнительно безболезненно прекратить проект, если это окажется необходимо.

Побочным достоинством инкрементной поставки является то, что она облегчает сбор данных для оценки ООФ и его объективных показателей прогресса.

Реактивный инкрементный метод (не такой уж славный подход)

Инкрементная поставка – это довольно выгодная стратегия, и почти все проекты либо применяют этот метод, либо, по крайней мере, лицемерно поддерживают его. Печально, что проекты, которые могли бы больше всего выиграть от этого, часто оказываются стремящимися принять то, что мы назовем реактивным подходом к этой идее.

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

вернуться

27

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

вернуться

28

Version Acceptance Test, VAT (прим. ред.)

27
© 2012-2016 Электронная библиотека booklot.ru