|
Страница 3 из 5
Характеристики адаптивного процесса У адаптивного жизненного цикла есть шесть базовых характеристик: Mission Focused (Целенаправленность), Component Based (Компонентный подход), Iterative (Итеративность), Timeboxed (Жесткие временные рамки), Risk Driven (Оценка с точки зрения рисков) и Change Tolerant (Допустимость изменений). Те, кто работают над проектами в сфере электронного бизнеса, редко с самого начала четко понимают, какими должны быть результаты их работы. Тем не менее, они ясно осознают общую цель, и эта цель достаточно ясно формулируется команде разработчиков. Основные положения цели служат направляющими для первоначального исследования, а далее, в процессе работы над проектом, начинают сужаться. Цель определяет, скорее, границы проекта, а не его конечный результат. Итеративный проект без правильно поставленной общей цели и постоянного пересмотра текущих задач становится "проектом-маятником" - разработки движутся туда-сюда, итерация за итерацией, без видимого прогресса. Артефакты, в которых зафиксирована цель всего проекта (их может быть несколько типов), не только помогают указать нужное направление работ, но и используются для того, чтобы в случае острой необходимости найти компромиссное решение. Если такие артефакты не помогают в принятии решений, то значит, они были созданы неправильно. Адаптивный жизненный цикл проекта строится исходя из результатов, а не задач, причем в качестве результатов выступают компоненты системы. В этом контексте под словом компонент понимается некий набор свойств программы (или некоторых элементов, входящих в поставку системы), который должен быть разработан в течение итерации. Конечно, документы (например, модель данных) тоже можно считать поставляемым компонентом, однако по отношению к свойству программы документация всегда второстепенна, так как только работающий программный код дает заказчику возможность ощутить реальные результаты работы. В итеративном жизненном цикле "переделка" продукта занимает не меньше места, чем его "создание". На производстве все обстоит по-другому. Там специальные программы, следящие за качеством работы станков, помогают избежать "брака" (результата ошибки в процессе изготовления какой-либо вещи) и последующей его переделки. Однако в области программных (и прочих интеллектуальных) разработок дело обстоит несколько по-иному, чем на конвейере, где бездушный автомат каждые несколько секунд штампует одинаковые штуковины. Кстати, весьма вероятно, что сама штуковина была спроектирована и разработана с применением итеративного процесса. Компоненты же, как правило, претерпевают изменения на протяжении нескольких итераций. Это происходит из-за того, что заказчики сообщают разработчикам свои комментарии относительно продукта по мере его развития. Жесткие временные рамки, или установление фиксированных сроков поставки для каждого итеративного цикла, нередко подвергается яростной критике со стороны поклонников быстрых программных разработок (rapid application development, RAD). Но это происходит потому, что они совершенно неверно подходят к вопросу установления этих сроков. Заранее установленные временные рамки проекта, из-за которых приходится то растягивать работу на долгие часы, то торопиться, жертвуя качеством работы, представляют собой самую настоящую тиранию и произвол, они подрывают ту атмосферу сотрудничества, к которой так стремится адаптивный процесс. В течение нескольких лет я руководил RAD-проектами, прежде чем понял (я вообще человек медлительный), что, говоря о жестких временных рамках, мы должны иметь в виду не столько время и сроки, сколько принятие сложных компромиссных решений. Когда тебя окружают постоянные изменения, нужно периодически задействовать некий фактор, который будет заставлять доводить начатое до конца. Кроме того, существование временных рамок заставляет команду разработчиков и клиентов постоянно пересматривать основные показатели проекта: его границы, расписание работ и поставок очередных версий, ресурсы, дефекты и т.д. Те команды, которые не могут (или не хотят) принимать быстрые решения и делать выбор, никогда не добьются успеха в экстремальных условиях. Как и в спиральной модели Бэрри Боэма (Barry Boehm), планирование в адаптивном жизненном цикле ведется исходя из осознания и анализа критических рисков. Кроме того, адаптивный способ разработки ПО приемлет и приветствует все возникающие изменения. С адаптивной точки зрения, возможность внесения изменений - это конкурентное преимущество, а не просто еще одна "проблема". |