Персональные инструменты
 

Трехуровневое планирование в Agile (Дмитрий Овечкин, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчик
Дмитрий Овечкин

На сегодняшний день Agile является основным мейнстримом в процессе разработки ПО. Существует большое количество статей и книг, описывающих SCRUM, Kanban и Lean, но после прочтения вы, возможно, задумаетесь о том, как на практике адаптировать эту замечательную методологию.

В своем докладе я расскажу, как я изучал и внедрял Agile, а также поделюсь реальным опытом многоуровневого планирования в Agile, который был адаптирован и проверен в реальном центре разработки. Я рассмотрю квартальное, релизное и спринтовое планирование.

Также, я затрону механизм реагирования на изменения заказчика, когда он меняет план и объем работ по ходу проекта и как вы должны реагировать на изменения, чтобы сохранить контроль и выпустить релиз вовремя. Никакой теории, только успешная практика, что является наиболее ценным в мире Agile.

Видео



Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).


Примечания и отзывы


Многовато банальностей, от пересказа Ветхого завета Agile-манифеста, стандартных SCRUM-картинок c шестеренками, и, кстати, аппеляция к Nokia-тесту «Правильный ли у вас SCRUM?», который более-менее OK встречался года три-четыре назад, сейчас вызывает кривую ухмылку.

Суть доклада, в том, что при изменении требований применяется дескопинг (ожидаемо) и обмен-торговля с заказчиками. А те самые три уровня планирования это

  • Квартал (где очень предварительная оценка)
  • Релиз
  • Спринт

Но зато интересное — очень большой блок вопросов, видно, что интересует аудиторию — куча тонких вопросов «кто с кем договаривается?», «а что если такая-то неожиданность?», «какой процент между багами и фичами?», и на все это конкретные ответы. Много разного оффтопа, например рассказ о самодельной реализации Continuous Integration на Python (Кстати, одобряю. Необходимость специальных систем-серверов считаю зачастую преувеличенной). Технодолги учитываются, как баги (а не как фичи), команде выделяется процент времени именно на это (не меньше 10%) и они сами выбирают, что и как разгребать. Но при этом сохраняется прозрачность.




Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».