Гибкая (agile) разработка программного обеспечения

Как говорится, «всё новое – это хорошо забытое старое». 😊 Так называемая «гибкая» (agile) разработка программного обеспечения (ПО) – это не какая-то принципиально новая методология, а всего лишь «новое дыхание» давно известных методологий. Есть несколько трактовок термина:

• eXtreme Programming (XP), Scrum, Feature-Driven Development (FDD), методология Crystal Clear и т. п. в чистом виде – как эффективные методологии для разработки небольших систем;
• компромисс между (ну или гибрид) RUP и XP – двумя крайностями («тяжёлой» и «лёгкой» методологиями);
• придание большей гибкости «тяжёлым» методологиям вроде RUP или MSF посредством их подстройки.

В любом случае главная идея состоит именно в гибкости процесса разработки по отношению к текущим (постоянно изменяющимся) требованиям и условиям.

Манифест

Существует так называемый «Манифест о гибкой разработке ПО» (agilemanifesto.org), подписанный известными товарищами (Kent Beck, Martin Fowler, Alistair Cockburn и другими):

Мы открываем лучшие способы разработки ПО, делая его сами и помогая его делать другим. Через эту работу мы начали ценить:

• индивидуумов и взаимодействия больше, чем процессы и инструменты;
• работающее ПО больше, чем понятную документацию;
• сотрудничество с заказчиком больше, чем переговоры по заключению договоров;
• ответ на изменения больше, чем следование плану.

То есть, несмотря на то, что ценность есть и в правой части этих пунктов, мы больше ценим то, что слева [жирным]».

Принципы

1. Наивысшим приоритетом является удовлетворение заказчика посредством ранней и постоянной поставке ценного ПО.
2. Изменяющиеся требования приветствуются, даже на поздних стадиях разработки. Гибкие процессы в своей совокупности изменяются для обеспечения конкурентного преимущества заказчика.
3. Работающее ПО должно поставляться часто, от пары недель до пары месяцев, с предпочтением более короткого цикла.
4. Представители заказчика и разработчики должны работать вместе, каждый день на протяжении всего проекта.
5. Строить проекты нужно вокруг мотивированных индивидуумов. Дайте им необходимое окружение, удовлетворяйте их потребности и доверяйте им, чтобы работа была сделана.
6. Самым эффективным методом передачи информации команде разработчиков и внутри неё является личное общение.
7. Работающее ПО – это первичная метрика прогресса.
8. Гибкие процессы обеспечивают стабильную разработку. Спонсоры, разработчики и пользователи должны всё время выдерживать постоянный темп.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышают гибкость.
10. Важна простота – искусство максимизации объема работы, которую удалось избежать.
11. Самые лучшие архитектуры, требования и дизайн создаются самоорганизующимися командами.
12. Через регулярные интервалы времени команда должна задумываться над тем, как стать более эффективной, и корректировать своё поведение соответствующим образом.

Данные принципы тесно связаны с манифестом.

Варианты

Существует несколько вариантов «гибких» методологий разработки ПО:

• Agile Enterprise Architecture – гибкая организация структур и процессов предприятия для максимально эффективной работы;
• Agile Modeling (AM) – практическая методология для эффективного моделирования и документирования;
• Agile Practices and RUP – официальные рекомендации по использованию RUP применительно к «гибким» (XP) проектам;
• Agile Unified Process (AUP) – упрощённая версия RUP;
• Crystal Clear, eXtreme Programming (XP), Scrum и т. п.;
• Microsoft Solutions Framework (MSF) for Agile – более «гибкая» версия MSF, в том числе имеющаяся в поставке VSTS 2005/08;
• Feature-Driven Development (TDD) и Test-Driven Development.

Элементы

Отдельными элементами, рекомендуемыми к использованию во всём «зоопарке» гибких методологий, являются:

• «кадры решают всё» (в том числе за счёт сознательности и самоорганизуемости), а не то, на чём пишут ПО;
• главное – написать ПО, а не документировать его;
• написанное ПО должно соответствовать текущим потребностям заказчика, а не когда-то написанному техническому заданию (ТЗ) на него;
• для этого надо постоянно работать с заказчиком и часто показывать ему новые версии ПО;
• наиболее эффективная форма взаимодействия как с заказчиком, так и внутри команды – личные встречи и устное общение.
• архитектуру ПО надо стараться поддерживать в максимально простом и гибком виде, готовом к любым изменениям.

Применение

Мы в «Инрэко ЛАН» уже давно применяем гибкие методологии разработки в том или ином виде:

• для небольших проектов мы используем BugTracker.NET – при всех его недостатках он является максимально гибким;
• в своих проектах я активно практикую стимуляцию самоорганизации команды и самостоятельности её участников;
• в рамках TFS нами был разработан шаблон жизненного цикла артефактов малого проекта именно на основе MSF for Agile;
• иногда мы довольно успешно «боремся с заказчиками», любящими писа́ть жёсткие ТЗ, посредством заключения рамочных договоров и написания «общесловесных» ТЗ (ОТЗ). 😊