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

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

Материал из CustisWiki

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

Аннотация

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

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

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

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

Видео



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

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


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


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

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

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

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



Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.