На прошлой неделе был на новом тренинге Асхат Certified Leading SAFe. А сейчас готовлюсь к экзамену и сертификации. Собственно, чтобы все в голове уложилось решил написать пару постов.
Команда Эврики растет. Мы любим рассказывать, что у нас разработкой Контур.Бухгалтерии занимается уже 7 команд. Хотя, если быть честным, самая маленькая из этих команд состоит из одного человека:) Так или иначе вопросы организации разработки, когда вы вылезли за пределы одной скрам-команды, для нас стоят очень остро. SAFe это один из подходов для решения этой задачи.
На тренинге коллеги пришли к мысли, что SAFe для нас слишком тяжеловесен и предложили рассмотреть более легковесные подходы:
Поэтому давайте начнем с обзора различных подходов.
Как оказалось, подходов к масштабированию Agile-разработки существует over9000 и есть даже чуваки, которые посвящают свою жизнь их сравнению: http://www.agilescaling.org/
У них же можно скачать огромную эксельку со сравнением:
https://app.box.com/s/fqt8bub0l2ac2fhh76zye7bnky90gqui
Так что, если вы не знаете чем занять выходные…
Spotify
Источник: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf
Кейс Spotify достаточно известен и популярен, и я не буду на нем останавливаться.
Если вы вдруг его пропустили, здесь есть хороший перевод на русский:
http://agilerussia.ru/practices/spotifyscaling/
Nexus
Источник: https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf
Nexus очень простая и тупая вещь. Вы можете прочитать всё его описание за считанные минуты — там всего 11 страниц формата А4.
Nexus состоит из 3-9 скрам-команд. У этих команд:
- Один Product Owner
- Общий бэклог
- Общий Definition of Done
- Выровненные спринты — спринты всех команд начинаются и заканчиваются в одно время
- Общий интегрированный инкримент — команды на демо показывают интегрированный результат работы всех команд
Что забавно, те же требования к командам есть и в LeSS, и в SAFe.
Сам процесс в Nexus дополняется двумя новыми активностями:
- Nexus Sprint Planning
- Nexus Daily Scrum
Суть этих активностей плоть от плоти Scrum of Scrums.
Nexus Daily Scrum — представители команд собираются на статусную встречу, где обсуждают прогресс и проблемы в своих командах, доносят информацию, которую должны знать другие команды. Информацию с этих встреч доносят до своей команды на командном Daily Scrum.
Nexus Sprint Planning — представители команд перед планированием спринта в команде отбирают задачи из общего бэклога для планирования своей команды.
Результаты планирования в командах собираются в общий артефакт, который называется Nexus Sprint Backlog.
Так же появляется отдельная команда Nexus Integration Team, в задачи которой входит координация и коучинг остальных команд. Собственно, эта команда и отвечает за то, что интегрированный инкримент будет готов к концу спринта. Команда состоит из The Product Owner, A Scrum Master, и непонятных Nexus Integration Team Members.
Nexus Integration Team Members могут участвовать в работе других команд на других ролях, но задачи Integration Team для них первостепенны.
Вот и весь Nexus. Даже по-моему ничего существенного не опустил.
LeSS
Источник: http://less.works/
LeSS устроен почти также как Nexus: до 8 скрам-команд, один Product Owner, общий бэклог, общий DoD, выровненные спринты, общий инкримент.
Планирование спринта так же разбито на два этапа, однако в отличие от Nexus уже предлагается приглашать на первый этап выбора задач из бэклога не только представителей, но и всю команду целиком. И только если количество людей становится не разумным, переходить к схеме с представителями.
Так же в LeSS появляется идея параллельного планирования на втором этапе в опенспейсе для простой координации команд по ходу планирования.
В чем же отличие от Nexus?
И то и другое это скелет, процесс с которого вы можете стартовать, менять и и довешивать на него все, что вам нужно.
Nexus это одиннадцати страничная pdf-ка. И почти всю суть содержимого вы уже прочитали выше. Nexus не подсказывает вам что и как довешивать на этот скелет.
LeSS же это большой ресурс, который подробно описывает и что довесить, и как. Там есть множество описаний и принципов, и практик.
Думаешь такой: чот, у меня какая-то херня с тестированием:
- Открываешь http://less.works/
- Читаешь http://less.works/less/technical-excellence/thinking-about-testing.html
- Много думаешь
- Что-нибудь докручиваешь
Плюс у LeSS уже развитая в цивилизованном мире инфраструктура тренингов, коучей и консультантов.
SAFe
Источник: http://www.scaledagileframework.com/
Если LeSS и Nexus это скелет, на который вам нужно будет навешивать все недостающие практики, то SAFe это новый RUP — универсальное решение любых задач, из которого со временем вы скорее всего решите много повыкидывать.
SAFe это ядерный замес всего лучшего, что на сегодня придумала индустрия разработки ПО, упакованное в красивую упаковку.
SAFe создан для насаждения Agile сверху. Он полностью описан, чтобы при насаждении делать так:
— Почему мы должны использовать <подставь любую практику по вкусу>
— Потому, что наша организация внедряет SAFe и там предписывается использовать эту практику.
Конечно, после того как вы «внедрили SAFe» вы можете его адаптировать:)
SAFe описывает все устройство организации вплоть до вопросов стратегии и бюджетирования.
Но чтобы, наше сравнение было релевантным давайте рассмотрим только уровень программы в SAFe.
Здесь у нас 5-12 agile-команд(50-150 человек). SAFe не обязывает все команды использовать скрам. Это может быть канбан или что-то другое. Но накладывает на процесс разработки в командах такие ограничения, что они имхо быстро сдадутся и перейдут на скрам. В частности, команды должны обеспечивать выравнивание своего процесса с двухнедельным циклом:)
Здесь у нас и появляется выделенная команда почти как в Nexus, состоящая из продуктовых менеджеров, системных архитекторов и скрам-мастеров. В минимуме состоит из трех человек. Забавный факт: авторы SAFe называют эти команды русским словом Troika.
Общий бэклог(но это уже общее место нашего повествования).
Самое интересное — забудьте про представителей! Все кросс-командные активности проводятся полным составом всех команд для повышения прозрачности. Но редко.
В SAFe команды живут релизными циклами, которые называются Program Increment(PI). Этот цикл длится 5 двухнедельных итераций разработки.
Цикл начинается с ключевого события в жизни команды — PI Planning. Это двухдневное мероприятие, в рамках которого: менеджмент, продакты, системные архитекторы доносят свое виденье, вызовы и цели до команды, а команды выбирают из общего бэклога задачи и параллельно планируют следующие четыре спринта разработки своей команды.
Да, я не описался. PI занимает пять спринтов, а планировать разрешается только четыре. И нет, пятый спринт отдается не на закрыто хвостов предыдущих итераций, а на хакатоны, инновации и подготовку к следующему планированию.
Ватерфольненько на мой вкус. Но зато каждые два с половиной месяца можно попить пива за счет компании:)
Пойду я посплю, продолжение напишу завтра:)
