• Итеративная разработка
• Частые сборки
• В начале итерации возможны любые изменения предыдущего плана, более того изменения приветствуются, широко применяется рефакторинг
• Масса практик для более тесного взаимодействия внутри команды: пересмотр кода, парное программирование, демонстрации результатов работы за итерацию

Agile — очень хорош. Настолько хорош, что даже не нуждается в подтверждении этого. Подтверждением служат тысячи команд, которые успешно работают, используя эту методологию для выпуска прекрасных и качественных продуктов. Однако и причин не использовать agile тоже может быть достаточно. В чем же подвох? В том, что заказчики, требования и команды — разные. Не каждому проекту нужна самоорганизованная команда, иногда достаточно точно четко спланировать задачи и придерживаться плана. Иногда команда бывает настолько большой, что «самоорганизация» будет поглощать слишком много времени и сил, а разделить её не представится возможным, в силу разных причин. Еще бывает: требования приходят и меняются так часто, что это становится сложно вписывать даже в самые короткие итерации. Причин может быть много, а реализаций agile в комбинации с другими практиками — еще больше, но те команды, у которых это прижилось, ценят свободу в принятии решений и творческий дух внутри команды.
Мы строили agile таким образом:

• Итерация (спринт), длилась неделю
• По понедельникам мы проводили планирование спринта: я печатал задачи на небольших листах бумаги, тестировщик выполнял роль скрам мастера (scrum master)
• По результатам планирования (planing pocker), на бумажках записывались ответственные и оценка
• Инструментальное ноу-хау: для построения burndown мы использовали расшаренный для всей команды на чтение гуглодоковый лист (типа excel). По мере того как мне приносились бумажки с закрытыми задачами я обновлял лист и все могли видеть прогресс

Ничего сложного. Что это дало? На мой взгляд, самым большим достижением было наибольшее вовлечение команды в процесс работы и результат за всю историю проекта. Я экспериментировал с несколькими практиками, но именно agile позволил мне максимально отстраниться от непосредственного принятия решений и предоставить команде свободу. Также печатание задач и burndown диаграммы на бумаге позволил немного по-новому оценить объем выполняемой работы, — солидная стопка из закрытых задач как бы говорила нам: вы отлично поработали. В электронном виде это выглядело так: