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

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

Динамизм обеспечивается следующими характеристиками:

· непрерывная связь с заказчиком;

· простота (всегда выбирается минимальное решение)

· быстрая обратная связь (модульное и функциональное тестирование)

· смелость в проведении профилактики возможных проблем.

Базис XP образуют 12 методов:

1. Игра планирования - Локальный заказчик обеспечивает набор "историй", которые описывают требуемую функциональность. К каждой новой версии в текущий набор "историй" вносятся наиболее важные истории (сценарии обслуживания).

2. Частая смена версий - новые версии каждые 2 недели.

3. Метафора - вся разработка проводится на основе простой общедоступной истории о том, как работает система. Истории обеспечивают заказчики.

4. Простое проектирование.

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании.

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость.

7. Парное программирование - весь код пишется двумя программистами, работающими на одном компьютере. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%

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

9. Непрерывная интеграция - интегрирование системы несколько раз в день по мере завершения каждой задачи.

10. 40-часовая неделя - нельзя работать сверхурочно.

11. Локальный заказчик - в группе все время должен находиться компетентный представитель заказчика, готовый отвечать на все вопросы.

12. Стандарты кодирования - правила, обеспечивающие одинаковое представление программного кода.

Выбор модели ЖЦ программного проекта

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

При выборе модели ЖЦ программного проекта следует найти ответ на ряд следующих вопросов.

Насколько стабильны требования?

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

Кто же является конечным пользователем системы?

Уделите немного времени тому, чтобы ознакомиться с пользователями и заинтересованными сторонами. Кто они? Эта группа сосредоточена или разбросана по разным местам? Как они могут повлиять на проект? Контролируемая группа пользователей, которая имеет значительное влияние на проект, может помочь вам в определении требований и управлении изменениями. Это означает, что вы сможете достичь стабильности относительно требований проекта и использовать каскадную модель.

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

В последнее время методология разработки программного обеспечения от Microsoft (MSF - Microsoft Solution Framework) стала включать в себя гибкий подход. Что касается гибкой модели, то, согласно данной методологии, «маленькие итерации позволяют снизить уровень ошибок в предположениях и представить быстрый отчет о точности ваших планов. Каждая итерация должна в результате предоставлять стабильную часть всей системы». Microsoft и Google выбрали гибкость в разработке, потому что их клиенты представлены в виде очень распределенной группы пользователей.