Сравнение RUP и других методологий разработки ПО - А сколько итераций потребуется?

А сколько итераций потребуется?

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

Начнем с более точного определения итерации. Итерация — это не просто календарный срок, это определенный этап выполнения проекта:

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

Итерации в процессе разработки позволяют:

• контролировать и корректировать ход выполнения вашего проекта (необходимость продемонстрировать работающий релиз в конце итерации не позволяет программисту ограничиться типичным ответом о 90% -ной готовности класса или метода);
• эффективнее работать с изменяющимися требованиями (например, осуществляя анализ изменившихся требований и решая, что будет переработано в продукте, в ходе подготовки к очередной итерации);
• эффективнее работать с рисками, корректируя планы очередной итерации в соответствие с текущим состоянием списка наиболее приоритетных рисков;
• на ранних этапах оценивать потенциальные характеристики системы (поскольку наличие работоспособного релиза позволяет начать тестирование системы с самых первых итераций);
• не тратить время на разработку бесполезных детальных планов на далекую перспективу (если требования к проекту могут существенно меняться раз в месяц, а принципиальная архитектура еще не выбрана, стоит ли детально планировать работы на следующий квартал?).

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

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

Еще одним фактором, влияющим на выбор длительности итерации, является использование инструментальных средств. Так средства управления изменениями и конфигурациями и средства автоматизации тестирования позволяют снизить не только трудоемкость процесса разработки, но и накладные расходы на подведение итогов итерации.

В отличие от некоторых других итеративных подходов, RUP не задает жесткие рамки на длительность итерации. На основании опыта собственных разработок, а также собранной статистики IBM Rational рекомендует выбирать продолжительность итерации в диапазоне от одной до восьми недель. Итерации длительностью в 8 недель, как правило, хватает даже для команд численностью порядка ста человек.

Можно ли применять RUP, если Заказчик требует строго соответствия ГОСТам 19 и 34? Можно. Для этого, во-первых, нужно постараться полностью использовать возможности «законной» дополнительной итерации, связанной с передачей продукта заказчику. Запланируйте ее такой длинной, насколько это будет возможно. Ну а, кроме того, запланируйте начало работ по разработке и проектированию как можно раньше, а завершение работ по выявлению требований и анализу — как можно позже. После этого никто вам не помешает организовать несколько итераций, не называя их итерациями. Единственная неприятность — придется потратить дополнительное время и ресурсы на формирование более детальной, чем это необходимо, первой версии многих документов и моделей. Впрочем, и этого иногда можно избежать, если договориться с заказчиком, о разработке ПО в несколько этапов.