Наш опыт внедрения agile

Хочу поделиться опытом внедрения agile в нашей команде. Скажу сразу, — я не ставлю перед собой цели кого-то удивить, привлечь на «светлую сторону силы», либо разубедить. Это только моё личное понимание agile как процесса и наш общий опыт его внедрения в процесс.
Существует масса определений термина agile, я приведу, на мой взгляд, самые важные моменты:
Принятия решений, планирование сроков делегируется от руководителя к команде. Максимальная самоорганизация команды

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

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

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

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

Вот как выглядит scrum в googledocs

Site Footer

Sliding Sidebar

About Me

About Me

For whom this blog for?

For those who are interested in modern Internet technologies, IT business, startups, management, quality control, personal effectiveness, motivation. Here I write about what is interesting, about problems I faced and solutions I found. I hope it will be interesting to you either.

What motivates me to write?

The desire to improve, to study deeper topics that interest me. Find people with similar problems and tasks, together look for ways out and solutions.

Feel free to contact if you have anything to say to me

Old Flash site with my artistic works and misuc.