|
|
(не показано 9 промежуточных версий этого же участника) |
Строка 1: |
Строка 1: |
− | {{ActualBanner2}}
| |
− |
| |
| == Аннотация == | | == Аннотация == |
− | ;Докладчик: [http://agiledays.ru/members/profile/38/ Дмитрий Никонов] | + | ;Докладчик: [http://www.linkedin.com/in/dmitriyn Дмитрий Никонов] |
| | | |
| <blockquote> | | <blockquote> |
Строка 20: |
Строка 18: |
| {{vimeoembed|21226454|720|405}} | | {{vimeoembed|21226454|720|405}} |
| | | |
| + | <noinclude>{{ActualBanner2}}</noinclude> |
| + | |
| + | {{Нужен подкаст?}} |
| <!-- == Подкаст == | | <!-- == Подкаст == |
| {{podfmembed|belonesox.podfm.ru/addconf/}} --> | | {{podfmembed|belonesox.podfm.ru/addconf/}} --> |
| | | |
| <!-- == Презентация == | | <!-- == Презентация == |
− | [[Файл:Планирование релизов в методологиях быстрой разработки (Дмитрий Никонов, AgileDays-2011).pdf|center|640px]] | + | [[Файл:Планирование релизов в методологиях быстрой разработки (Дмитрий Никонов, AgileDays-2011).pdf|page=-|left|256px]] |
| | | |
| --> | | --> |
| | | |
− | == Примечания == | + | == Примечания и отзывы == |
− | * [http://agiledays.ru/reports/view/84/ страничка доклада на сайте конференции] | + | <!-- <blockquote>[©]</blockquote> --> |
| + | * [http://2011.agiledays.ru/reports/view/84/ страничка доклада на сайте конференции] |
| | | |
| <references/> | | <references/> |
| + | |
| + | {{include-review|Обсуждение:Планирование релизов в методологиях быстрой разработки (Дмитрий Никонов, AgileDays-2011)/Заметки Стаса Фомина}} |
| | | |
| [[Категория:AgileDays-2011 (наша запись)]] | | [[Категория:AgileDays-2011 (наша запись)]] |
− | {{feedback-appeal|AgileDays}}
| + | |
| + | http://inwebwetrust.org/~uploads/strip069_it_evolution.jpg |
| + | |
| {{replicate-from-custiswiki-to-lib}} | | {{replicate-from-custiswiki-to-lib}} |
| + | [[Категория: Менеджмент (доклады)]] |
Текущая версия на 21:54, 4 августа 2012
Аннотация
- Докладчик
- Дмитрий Никонов
Казалось бы структура релизов в командах быстрой разработки вообще не нужна, ведь в соответсвии с манифестом «Работающее ПО превыше всего». В теории внедрение должно производиться регулярными интервалами и весь контроль за релизом — это слова заказчика: «Я доволен, выпускайте».
В своем докладе Дмитрий обсудит с вами процесс управления релизами в А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ах.