Уже считается, что именно так — Agile at Scale и управления проектами выравниваются. На последнем AnalystDays был доклад от иностранцев на эту тему. Ну и хорошее видео на эту тему со стороны Agile@Scale.
Автор уехал учиться, я как второй ведущий игры у нас, дополню немного. Теоретическое понимание различий конечно же было, но игра помогает попробовать себя в некоторой конкретной реализации канбан-метода. Один из идеологов, Девид Андерсон в книге «Канбан» использует несколько Канбанов. Канбан (с большой буквы) — метод эволюционнных изменений, использующий вытягивающую систему канбан (с маленькой буквы), визуализацию и т.п. для введения идей бережливого производства в ИТ разработку. Вот мы наверное про него, про канбан-метод. Вводную к игре в тот момент и сейчас делаем «по Андерсону».
Можно, как и водопад, v-модель и т.д., только зачем? Каждая методика разрабатывалась для решения конкретных проблем управления проектами, если такие проблемы в проекте есть, методика помогает, если нет, то работает принцип «Лучше как-то управлять, чем не управлять».
Если требования гарантированно не меняются и достаточно детальны для выполнения работ, то «гибкие методики» не нужны. Если заказчику не нужно проверять гипотезу, то SCRUM не поможет, а будет мешать. Обычно берут лучшее, например, строгое проектное управление по созданию новой модели самолета, при котором на ранних этапах «создание проекта самого большого самолета» :) (с фиксированными сроками и бюджетом) кроссфункциональные команды работают по скраму. Как только майлстоун достигнут скрам «выключают» и продолжают идти «по ганту».
А ведь есть очень крупные и длительные проекты в которых все требования могут существенно меняться ежемесячно, и это никак нельзя предусмотреть. Там и живут скрамы скрамов.
C ходу: Низкая эффективность при наличии четко определенных требований. Легко «поломать», если участники (хотя бы один) не разделяют важности периодических мероприятий или 100% выполнения спринта. Заказчики очень долго привыкают к такому подходу — первая итерация всегда крайне болезненна. Заказчик, если требования меняются динамичнее, будет против фиксации состава sprint backlog. «Мы не используем наркоз, так как у нас Scrum-хирургия. Мы будем постоянно получать от вас обратную связь, особенно в первую итерацию».
Спасибо за статью.
Еще один акцент, чтобы ретро работали они не должны быть единичной активностью. Нужно делать PDCA на уровне ретроспектив, т.е. каждая следующая ретроспектива должна начинаться с анализа активностей прошлой ретроспективы и фиксации соответствующих результатов «спринт-эксперимента» (в идеале раз в месяц целенаправленно проводить ретроспективу самой ретроспективы).
Еще, с какого-то момента (когда процесс не «поломан»), лучше искать как работать сильно круче, чем искать что мы еще можем довести в процессе до блеска. Утверждение
Как правило, новые идеи рождаются в процессе обсуждения минусов прошлой итерации...
характерно для ретроспектив по качеству. В трех остальных приведенных форматах лучше стартовать с позитива.
Например, ретроспективу по проблемам (заказчика/владельца) проводить по следующему сценарию:
Активность со стикерами или доской при которой проблемы фиксируются без явного озвучивания на доске на 5-10 минут (energizer)
Мозговой штурм в формате — «решение внутреннее, решение внешнее, решение фантастическое»
Сортировка через «5 почему»
Фиксация 3-х экшенов и голосование за «Эксперимент на спринт»
Такой формат позволяет снизить напряжение между владельцем, у которого болит, и командой, которым принесли проблему которую они не ощущают. Сокращает риск возникновения «поиска виноватых».
Понял, что опыта именно по теме организации контактов маловато. Либо я общаюсь с заинтересовавшими докладчиками, либо с коллегами, которые спрашивают заинтересовавших докладчиков. Остальное на ваше личное обояние. А вот про фиксацию результатов чуть-чуть побольше написал.
Mind Map и таблица этапов с учетом средней скорости речи, это вообще круто для первого выступления. А сейчас, по прошествии лет, что бы себе еще посоветовали?
Спасибо. Попробую в следующей статье описать простые приемы для первого выступления, типа выбора человека для рассказа, что делать если люди ходят и как попадать в тайминг.
А ведь есть очень крупные и длительные проекты в которых все требования могут существенно меняться ежемесячно, и это никак нельзя предусмотреть. Там и живут скрамы скрамов.
Еще один акцент, чтобы ретро работали они не должны быть единичной активностью. Нужно делать PDCA на уровне ретроспектив, т.е. каждая следующая ретроспектива должна начинаться с анализа активностей прошлой ретроспективы и фиксации соответствующих результатов «спринт-эксперимента» (в идеале раз в месяц целенаправленно проводить ретроспективу самой ретроспективы).
Еще, с какого-то момента (когда процесс не «поломан»), лучше искать как работать сильно круче, чем искать что мы еще можем довести в процессе до блеска. Утверждение характерно для ретроспектив по качеству. В трех остальных приведенных форматах лучше стартовать с позитива.
Например, ретроспективу по проблемам (заказчика/владельца) проводить по следующему сценарию:
Такой формат позволяет снизить напряжение между владельцем, у которого болит, и командой, которым принесли проблему которую они не ощущают. Сокращает риск возникновения «поиска виноватых».
Отличный сайт с форматами проведения ретро http://www.funretrospectives.com/
От туда же менее формальный по букве формат с четырьмя частями "Якоря и паруса".