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

Планирование релизов в методологиях быстрой разработки (Дмитрий Никонов, AgileDays-2011)

Материал из CustisWiki

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

Аннотация

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

Казалось бы структура релизов в командах быстрой разработки вообще не нужна, ведь в соответсвии с манифестом «Работающее ПО превыше всего». В теории внедрение должно производиться регулярными интервалами и весь контроль за релизом — это слова заказчика: «Я доволен, выпускайте».

В своем докладе Дмитрий обсудит с вами процесс управления релизами в Аgile проектах на примерах компаний Майкрософт и Амазон, а также различные методы и подходы:

  • «Ship when ready»,
  • «Ship when needed»,
  • «Ship when scheduled».

Не стоит также забывать, что процесс управления релизами не ограничивается одним релизом, и команды одновременно могут работать (и работают) над несколькими одновременно. Прогнозируемость релиза, качество внедренного кода, соответствие кода ТЗ заказчика — это залог успеха релиза.

Видео


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

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


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


Дмитрию наверное, осталось поработать в Oracle, Apple и Facebook, и им будут покорены все шесть чудес света.

Докладчика позиционируется как софтверный гуру, ибо до микрософта он работал в Амазоне, до Амазона, вроде тоже в микрософте, причем в самом софтверном месте, в разработке Visual Studio Team System, да и вроде изнутри знает про процесс в Гугле. Еще говорит по-русски, хотя уже с акцентом.

Мне он запомнился тем, что на прошлых AgileDays-2009, в кулуарах я вылил на него всю свою злобу на Амазон — и вот результат, он оттуда уволился :)

Тема же именно разрешение конфликта, между легкостью и краткостью итераций, без проблем работающих в заказной разработке c небольшим числом потребителей, и рисками многопользовательской продуктовой разработке. Если раньше об гибких Agile-релизах и речи не могло быть, ибо дистрибьюция релиза была завязана на долгие техпроцессы, типа изготовление сидюков, то сейчас жить можно, осталось решить технические проблемы.

  • Какие бывают релизы (основные и промежуточные), и зачем?
  • Как нарезать итерации на релизы?
  • Как их планировать и вообще нужно ли?
  • Когда их проводить? (не нужно проводить релизы в «нервные» периоды, типа аттестации и пересмотра зарплат). Но иногда надо — «к красной дате календаря».
  • Как тестировать и интегрировать? (production branches, reverse и forward integration и т.п.).
  • Что в планировании деляет PO, а что SM?

Релиз — как путь совершенствования от «it works on my machine», затем прохожденре все большего набора тестов, получение одобрения бизнеса на демонстрациях и наконец, «вроде работает всегда и везде» «не падает при внедрении в продакшн». Релиз — «освобождение из тюрьмы» (англ). «На свободу с чистой совестью!»

Никаких волшебных инструментов — распределение UserStory по релизам с помощью сортировки по важности в Excel.

  • В микрософте и амазоне — три тестировочных среды. Всего.

Очень интересные механизмы («Triage») отслеживания незапланированных задач (ну и в частности багов).

  • Если человек «бажит», он попадает в «Bug Jail», и ему запрещают работать над фичами, пока все не исправит.
  • Механизм бумажный! Специальные тикеты-беджики по багам, которые вешают на людей!

Кстати — много скриншотов из внутренних систем, полезно для рефлексии специалистам по QA-процессам.

Ну и много-много оффтопа, на тему понимания Agile, важности коммитмента (хватит «я могу», давайте «я делаю»).

Судя по вопросам, народ пытался вкуривать схему с множественными ветками и специально обученными людьми, занимающимися проносом изменений, и подозревал, что она сильно неоптимальна. Ну, тут видимо «огромная codebase», наверное надо было привести ее размер, в SLOCах.


strip069_it_evolution.jpg


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