Хочу поделиться опытом внедрения agile в нашей команде. Скажу сразу, — я не ставлю перед собой цели кого-то удивить, привлечь на «светлую сторону силы», либо разубедить. Это только моё личное понимание agile как процесса и наш общий опыт его внедрения в процесс.
Существует масса определений термина agile, я приведу, на мой взгляд, самые важные моменты:
Принятия решений, планирование сроков делегируется от руководителя к команде. Максимальная самоорганизация команды
- Итеративная разработка
- Частые сборки
- В начале итерации возможны любые изменения предыдущего плана, более того изменения приветствуются, широко применяется рефакторинг
- Масса практик для более тесного взаимодействия внутри команды: пересмотр кода, парное программирование, демонстрации результатов работы за итерацию
Agile — очень хорош. Настолько хорош, что даже не нуждается в подтверждении этого. Подтверждением служат тысячи команд, которые успешно работают, используя эту методологию для выпуска прекрасных и качественных продуктов. Однако и причин не использовать agile тоже может быть достаточно. В чем же подвох? В том, что заказчики, требования и команды — разные. Не каждому проекту нужна самоорганизованная команда, иногда достаточно точно четко спланировать задачи и придерживаться плана. Иногда команда бывает настолько большой, что «самоорганизация» будет поглощать слишком много времени и сил, а разделить её не представится возможным, в силу разных причин. Еще бывает: требования приходят и меняются так часто, что это становится сложно вписывать даже в самые короткие итерации. Причин может быть много, а реализаций agile в комбинации с другими практиками — еще больше, но те команды, у которых это прижилось, ценят свободу в принятии решений и творческий дух внутри команды.
Мы строили agile таким образом:
- Итерация (спринт), длилась неделю
- По понедельникам мы проводили планирование спринта: я печатал задачи на небольших листах бумаги, тестировщик выполнял роль скрам мастера (scrum master)
- По результатам планирования (planing pocker), на бумажках записывались ответственные и оценка
- Инструментальное ноу-хау: для построения burndown мы использовали расшаренный для всей команды на чтение гуглодоковый лист (типа excel). По мере того как мне приносились бумажки с закрытыми задачами я обновлял лист и все могли видеть прогресс
Ничего сложного. Что это дало? На мой взгляд, самым большим достижением было наибольшее вовлечение команды в процесс работы и результат за всю историю проекта. Я экспериментировал с несколькими практиками, но именно agile позволил мне максимально отстраниться от непосредственного принятия решений и предоставить команде свободу. Также печатание задач и burndown диаграммы на бумаге позволил немного по-новому оценить объем выполняемой работы, — солидная стопка из закрытых задач как бы говорила нам: вы отлично поработали. В электронном виде это выглядело так:
