- •Rup и другие методологии разработки по. Часть 1. Принципы сравнения методологий разработки по
- •Как «измерить» методологию
- •Итеративная или каскадная разработка
- •Каскадный подход
- •Итеративный подход
- •Почему это важно
- •Уровень формализма Что такое формализм в проекте
- •Почему важна степень формализма
- •Что будем сравнивать
- •Часть 2. Сравнение методологий разработки по
- •Как получится…
- •Структурные методологии
- •Гибкие методологии
- •EXtreme Programming, или xp (экстремальное программирование)
- •Crystal Clear
- •Feature Driven Development
- •Общие черты
- •Модели зрелости процесса разработки (cmm, cmmi)
- •Часть 3. Как выбирать методологию?
- •Сколько формализма нужно? Польза документации
- •Общение вместо документации
- •Как выбирать?
- •Сколько итераций потребуется? Еще раз об итерациях
- •Польза и вред итераций
- •Как выбирать?
- •Подведем итоги
Как выбирать?
К сожалению, не существует единого оптимального уровня формализации процесса. Он должен определяться для каждого конкретного проекта и может меняться в очень широком диапазоне. Из основных факторов, влияющих на оптимальный уровень формализации процесса, можно назвать:
масштаб проекта — чем больше людей участвует в проекте, тем более формально он должен вестись;
критичность проекта — проекты, в которых ошибки могут приводить к тяжелым последствиям, вплоть до гибели людей, должны проводиться гораздо более формально, чем те проекты, в которых ошибки приводят только к временным неудобствам (как, например, при разработке домашней интернет-странички);
распределение участников — чем компактнее расположены участники, чем легче им общаться между собой, тем менее формализованным может быть проект;
новизна проекта — если разработчики используют новые технологии и мало знакомы с предметной областью, то следует более тщательно прорабатывать проектные решения — соответственно это должно происходить более формально. Однако если над проектом работает небольшая группа высококвалифицированных программистов, возможно, более предпочтительным будет тщательное оформление уже отработанных решений перед их тиражированием;
требования заказчика — существенно различаются в зависимости от отрасли и статуса организации-заказчика. Как правило, эти требования выше для государственных предприятий;
ожидаемая долговечность проекта — если разрабатываемое для конкретного заказчика ПО планируется через пару лет заменить новым, то вряд ли имеет смысл тратить много сил на документацию, которая могла бы значительно удешевить длительный процесс сопровождения ПО. Если же срок жизни проекта предполагается достаточно длинным, то без хорошей документации не обойтись. Автору приходилось иметь дело с системой, созданной более 15 лет тому назад и продолжающей эксплуатироваться, — в такой ситуации поддержка системы в работоспособном состоянии без качественной документации была бы просто невозможна.
Таким образом, если ваша организация достаточно велика (больше десятка разработчиков) и если вы выполняете проекты для различных отраслей или для систем разного уровня критичности — желательно выбирать для каждого проекта свой оптимальный уровень формализации.
Сколько итераций потребуется? Еще раз об итерациях
Сколько или, точнее, какой длительности итерации лучше использовать? Вопреки первому предположению, более показательным параметром, чем количество итераций, в данном случае является именно длительность итерации.
Итерация — это не просто календарный срок, это определенный этап выполнения проекта:
на который составляется детальный план;
который завершается выпуском итогового релиза (в ходе итерации сборка программы может проводиться еженедельно или даже ежедневно, но итоговый релиз выпускается единожды в конце итерации);
по завершении которого могут меняться приоритеты дальнейшей разработки;
по окончании которого производится оценка используемого процесса и, при необходимости, вносятся соответствующие изменения.
