Я использую термин «итерация» для описания процесса выполнения проекта в четко определенных, коротких, повторяющихся шагах. После каждой итерации вы останавливаетесь, чтобы определить, была ли и в какой степени реализована цель проекта, и при необходимости адаптируете исходный план. Цель – свести к минимуму риск неопределенности и неожиданностей. Та же процедура может использоваться в управлении изменениями.
Проведение ретроспектив позволяет наладить процесс непрерывного совершенствования, который постоянно проверяет, на правильном ли вы пути, а также дает возможность оперативно вмешаться и внести необходимые изменения. Выделив время для размышлений, вы сумеете решить проблему немедленно, не дожидаясь окончания процесса. Если не проводить ретроспективы до конца проекта, то вы рискуете к началу следующего забыть то, что узнали в текущем. Вы также получаете возможность реализовать улучшения в каждой итерации.
Слово agile имеет латинское происхождение, и его примерные значения «делать» или «действовать». Как уже было сказано, эта методология основана на 12 принципах agile-манифеста[3].
Суть agile-манифеста в следующем: мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь им непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.
Иными словами, не отрицая важности того, что записано справа, мы все-таки больше ценим то, что слева.
Соответствующие 12 принципов выглядят так:
1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны трудиться мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение – наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри нее.
7. Работающий продукт – основной