×

Что делать, когда Scrum трещит по швам

Еще недавно Scrum и Kanban хватало для большинства проектов, с которыми я работал. Однако портфолио начало расти, и пришлось задуматься над альтернативными вариантами, которые позволили бы наращивать численность команд без существенных трансформаций процессов. После недавнего проекта Agile-трансформации для одного клиента из Global 500 мне в голову пришла идея структурировать знания о Scaled-подходах. Я долго искал такую статью, но находил только отрывки, поэтому приходится писать самому.

Scrum of Scrums

Начнем с простого — Scrum of Scrums. Это сложно назвать новым фреймворком или методологией. Суть в том, что мы просто делим большую команду на несколько подкоманд. Каждая работает по Scrum, к daily stand-up добавляем еще один daily stand-up, где присутствуют амбассадоры от каждой команды. По сути, мы добавляем к обычному Scrum еще один митинг, на котором команды синхронизируются между собой. Частота таких митингов может варьироваться в зависимости от бизнес-потребностей. Рекомендуется проводить их не реже двух раз в неделю. Именно этот митинг и называется Scrum of Scrums. Иногда используют еще один уровень — Scrum of Scrum of Scrums.

ПреимуществаНедостатки
  • Все просто, легко внедрить.
  • Подходит для 2–3 команд.
  • Этот подход не отвечает на ряд ключевых вопросов, которые возникают при росте команд (например, работа с бэклогом, роли, планирование и прочее).
Scale: 2–4 Scrum-команды (до 25–30 человек).

Nexus

Следующий подход, который мы рассмотрим, — Nexus. Разрабатывается и поддерживается Кеном Швабером и Scrum.org. Nexus — это надстройка над Scrum, которая позволяет скоординировать работу нескольких команд над одним инкрементом. Как и Scrum, состоит из таких элементов, как роли, церемонии и артефакты.

Что нового:

  • Новая роль — команда интеграции Nexus (Nexus Integration Team) осуществляет координацию, коучинг, мониторинг и контроль процессов.
  • Новые артефакты — Nexus Sprint Backlog и Integrated Increment. Команды работают над одним общим Product Backlog, у каждой команды на спринт есть свой Sprint Backlog, но есть еще Nexus Sprint Backlog — по сути, сумма бэклогов всех команд, чтобы все видели, кто над чем работает. Integrated Increment — результат совместной работы команд.
  • Новые церемонии — они не особо новые, все то же самое, что и в Scrum, только на уровень выше и с приставкой Nexus:
    • Nexus Sprint Planning;
    • Nexus Sprint Backlog;
    • Nexus Sprint Retrospective;
    • Nexus Sprint Review;
    • Nexus Daily Scrum (то же самое, что Scrum of Scrums).

Тем, кто знаком со Scrum, думаю, понятна суть церемоний, описанных выше. Подробнее можно почитать здесь: Nexus Guide.

Чуть более детально рассмотрим Nexus-команду. По сути, это еще одна Scrum-команда, которая работает над решением любой интеграционной проблемы. Эта команда отвечает за успешную интеграцию всей работы, производимой всеми Scrum-командами в Nexus. Интеграция предполагает разрешение любых технических и нетехнических межкомандных ограничений, которые могут препятствовать поставлять интегрированный инкремент в каждый спринт.

Состав Nexus Integration Team может со временем изменяться для учета текущих нужд. Nexus Integration Team состоит из:

  • Product Owner;
  • Scrum Master;
  • одного или нескольких членов команды интеграции.

Члены Nexus Integration Team могут также работать в Scrum-командах, если это возможно и необходимо. В этом случае приоритет должен отдаваться работе в рамках Nexus Integration Team.

Подробнее о Nexus Integration Team можно почитать здесь.

ПреимуществаНедостатки
  • Знакомые процессы для тех, кто практикует Scrum.
  • Фокус на интеграцию, ответственная команда для работы над вопросами интеграции.
  • Одна команда полностью выделена на работу с интеграцией. Для небольших команд это дополнительные затраты.
Scale: 3–9 Scrum-команд (до 50–60 человек).

Итак, подытожим два предыдущих подхода. Если команда вырастает до 20+ людей, мы добавляем к обычному Scrum еще один sync-up-митинг между представителями подкоманд и получаем Scrum of Scrums. Команда вырастает еще, у нас уже 30+ людей — мы собираем отдельную команду, которая занимается интеграцией работы остальных команд, а также добавляем еще один уровень церемоний — тех же, что и в Scrum, только на уровень выше. Получается Nexus.

Далее рассмотрим Large Scaled Scrum (LeSS). Он очень похож на Nexus, но все же имеет свои отличия.

LeSS

Общие черты LeSS и Nexus:

  • до 8 Scrum-команд;
  • один Product Owner;
  • общий бэклог;
  • общий DoD;
  • выровненные спринты;
  • общий инкремент.

Отличия между двумя подходами:

  • на первый этап планирования в LeSS предлагается приглашать не представителей команд, а всю команду целиком;
  • в LeSS появляется идея параллельного планирования на втором этапе;
  • Nexus описан в одном документе всего на 12 страницах, LeSS предлагает ресурсную базу данных (less.works), которая содержит множество описаний принципов и практик.

LeSS Huge

Когда количество команд становится больше 8, в LeSS предусмотрен расширенный вариант — LeSS Huge.

Что общего между LeSS и LeSS Huge:

  • один Product Backlog;
  • общее Definition of Done;
  • один Potentially Shippable Product Increment;
  • один (общий) Product Owner;
  • общий синхронизированный Sprint.

Что нового в LeSS Huge по сравнению с LeSS:

  • новая роль— Area Product Owner;
  • новые артефакты — Requirement Areas в Product Backlog и Area Backlog.

ПреимуществаНедостатки
  • Эффективное использование ресурсов, нет нефункциональных команд (Nexus) или нефункциональных спринтов (PI-Sprint).
  • Имеет две версии: до 8 и более 8 команд
  • Есть своя база знаний.
  • Требует тщательного разделения области работ между командами для минимизации зависимостей.
  • Данный подход в меньшей степени подходит для работы распределенных команд.
  • Некоторые церемонии подразумевают, что вся команда работает в одной локации или хотя бы временной зоне.
Scale: LeSS — 2–8 Scrum-команд, LeSS Huge — более 8 команд, <1000 FTE.

Итак, подведем еще один промежуточный итог (как можно заметить, в статье мы рассматриваем подходы от простого к сложному).

Первый (Scrum of Scrums), по сути, представляет собой один дополнительный митинг, второй (Nexus) — четкий процесс-надстройка над Scrum, третий и четвертый (LeSS и LeSS Huge) — это уже не только процесс, но и база знаний, где можно найти информацию по многим сопутствующим аспектам работы команд.

SAFe

Следующий подход ценен в равной степени и как методология, и как набор лучших практик и свод знаний (аналог PMBoK в мире Agile) — Scaled Agile Framework (SAFe). Так как база знаний постоянно обновляется и пополняется, он имеет версионность. На момент написания статьи актуальная версия — 4.6. По сути, SAFe не пропагандирует ничего сверхнового — это микс различных существующих практик, объединенных под одним большим зонтом. База данных отлично структурирована и имеет хорошую навигацию через главную страницу с кликабельными иконками. Даже если вы не планируете внедрять SAFe, можете просто почитать об интересующем аспекте работы Agile-команды.

О SAFe на DOU есть отличная статья — «Обзор Essential SAFe: про методологию человеческим языком».

Не буду повторять ее, дам лишь короткое описание. SAFe предусматривает 4 уровня скейла и свой набор Best Practices для каждого их них. Сведу общее описание в одну таблицу:

ПреимуществаНедостатки
  • Подходит для проектов разных размеров — от одной-двух команд до 25 000 человек («Почта Австралии»).
  • Отличная база знаний.
  • Предусмотрены очень многие аспекты процесса разработки, для каждого уровня есть свои роли, церемонии.
  • Описана не только процессная часть, но и технические аспекты (DevOps, архитектура и прочее).
  • Отличная экосистема сертификации и тренингов.
  • На уровне программы добавляется дополнительный нефункциональный PI-спринт.
  • Некоторые церемонии подразумевают, что вся команда работает в одной локации или хотя бы временной зоне.
  • Выглядит достаточно сложным для понимания.
Scale: Team — 5–9. Program — <125 FTE. Large Solutions & Portfolio Level — ∞.

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

DAD

Последним в этом обзоре будет подход Disciplined Agile Delivery (DAD). Для начала разберемся, что такое Disciplined Agile (DA). Как называют его авторы, это process decision toolkit — другими словами, набор инструментов для принятия процессных решений. То есть он дает руководства, как выбирать процессы в зависимости от ситуации. DA описывает, как разные подходы работают в совокупности и в каком случае они нужны. Как и в SAFe, тут 4 уровня, но структура немного отличается.

В рамках данной статьи мы остановимся только на первом уровне, Disciplined Agile Delivery (DAD). По структуре DAD еще больше напоминает PMBoK. Здесь есть процессы, объединенные в группы. Процессы представлены в виде целей (ответ на вопрос «Чего мы хотим достичь?»). Группы процессов соответствуют стадиям проекта:

  1. Inception.
  2. Construction.
  3. Transition.

Подробнее о каждом процессе можно прочитать здесь:

Помимо этого, в DAD достаточно большой выбор ролей. Есть Primary Roles, которые присутствуют на проектах любого скейла, и Secondary Roles, которые могут появляться на скейле временно или по мере необходимости.

DAD позиционируется как инструментарий, который помогает выбрать правильный подход, методологию или фреймворк из существующего набора:

Как следует из названия, основной фокус в DAD делается на Delivery. Ниже представлен процесс в обобщенном виде.

Аудитории предоставляется 6 разных видов жизненного цикла разработки на выбор:

Жизненный цикл проектаСхема
DAD’s Agile lifecycle
DAD’s Lean lifecycle
DAD’s Continuous Delivery: Agile lifecycle 
DAD’s Continuous Delivery: Lean lifecycle
DAD’s Exploratory (Lean Startup) lifecycle
DAD’s Program (team of teams) lifecycle

DAD-команда адаптирует тот жизненный цикл, который ей подходит больше других. Более детальное описание того, как выбрать жизненный цикл, можно найти здесь: A Full Agile Delivery Lifecycle.

ПреимуществаНедостатки
  • Очень гибкий подход, дает свободу действий и выбора в зависимости от поставленной задачи.
  • Подход достаточно сложен в применении, требует высокого уровня от практиков.
  • DAD чаще полезен как отдельный набор компонентов, чем как целостная методология.
Scale: ∞.

Это самые распространенные, но далеко не все подходы к работе с большими командами с применением гибких (Agile) подходов. Вот их неполный перечень:

Enterprise-focusInter-Team focusTransformation Focus
Disciplined Agile (DA)Crystal FamilyCollabNet Agile Transformation Strategy
Enterprise AgilityDriving Strategy, Delivering More (DSDM)EBM — Agility Path
Enterprise Unified Process (EUP)Enterprise ScrumEnterprise Transformation Framework (ETF)
laCoCa ModelFAST AgileLeading Agile
Recipes for Agile Governance in the Enterprise (RAGE)Goal Driven AgileScALeD
Scaled Agile Framework(SAFe)Large Scale Scrum (LeSS)Aditi Agile Transformation Maturity Model
Scrum@ScaleNexusAgile Maturity Model
XScalePRINCE 2 AgileAgile Capability Maturity Model Integration
Scrum of ScrumsComparative Agility
Scrum Pattern Language of Programs (PloP)Roadmap for Agile success
Spotify ModelScrum Capability Ratings
Sustainable Cultural Agile Release in the Enterprise (SCARE)
Matrix of Services
Scrum Lean in Motion (SLIM)

Еще больше подходов можно посмотреть здесь.

Выбор действительно непрост. Чтобы правильно подобрать нужный подход, нужно исходить из потребностей и поставленных задач. Приведенная ниже таблица поможет сориентироваться.

Approach Comparison
Aspects / CriteriaScrum-of-Scrums (SoS)
PO meta-scrum
Large Scale Scrum (LeSS)
Larman/Vodde
Scaled Agile Framework (SAFe)
Leffingwell
Discipled Agile Delivery (DAD) + Agility at Scale
Ambler/Lines
Nexus / Scaled Professional Scrum Scrum.orgNotes
DescriptionAn important mechanism that may be enough for smaller organizations but is not a full scaling approachLarman / Vodde model as documented in Scaling Lean & Agile DevelopmentThe method documented by Dean Leffingwell and Scaled Agile, Inc.Scott Ambler model documented in the book Disciplined Agile DeliveryScum-based scaling with an exoskeleton called Nexus plus over 40 practices
Completeness of coverage of levels, including:LowMediumHighHighMediumNote that not all Agilists believe there *should* be levels like this but they occur today in most larger orgs. Low may not = bad!
PortfolioLowMedium*MediumMediumMedium*In LeSS, Single PO and one Product Backlog is the portfolio view
Program StructureLowMedium*HighHighMedium*Less is Product focused not traditional Program release focused
Inter-team CoordinationMediumHighHighHighMedium
Team LevelMediumMediumHighHighHigh
Tech PracticesLowMediumMediumHighMedium
Popularity / Adoption (new/growing (low) vs. established/leader (high)HighMediumHighLowLow
Flexibility / Emergence: Prescriptive (low) vs. emergent (high)?HighHighLowMediumMediumNote that prescriptive may still include options or allow for customization
Typical Cost to ImplementLowLowHighMedium Can vary dramatically — usually can be free via a roll your own option
Availability of Details & SupportLowMediumHighMediumLow
What Team level frameworks are supported? (Scrum, Kanban, XP, etc.)ScrumScrumScrum / Kanban / specific XP practices mandatedScrum/LeanScrum
Emphasizes more Central control or distributed?Distributed with light coordinationCentralized prioritization and distributed coordinationMore Central & top-down on ideas but distributed ownership on howMixed — depending on chosen parts but can be somewhat centralCentral Product view and distributed remainder
Scale / Target size (small — med — large)SmallMed — LargeLarge — EnterpriseMed — LargeSmall but Nexus+ can go over 9Small: < 100 people or 10 teams
Med: >100 < 500 people or 50 teams
Large org.: >500 people or 100s of teams
*Ranges may be changed by anyone using this tool, based on their relative size preferences
Used typically by what Organization Types?Any that are running ScrumHas 2 suggested structures for different size organizationsFocused on enterprisesUsed in many diverse organizationsNew, so adoption is unclear
Focal point
(teams/structure — enterprise/ROI)
team/structure
Inter-team dependencies
org descaling, team/structure
Agile thinking, PO scale via areas
team/structure
A customizable but prescriptive framework for most aspects of Agile at scale
team/structure
Larger project stages; Technical process gaps for craftsmanship at scale
Using Scrum concepts and mindset at scale
Software centric — how often used outside of SW or IT?Could use anywhere you use ScrumFocused on Software or SW/HWFocused on Software or SW/HWHas been used outside of ITCould use anywhere you use Scrum
Big Positives / Key Differentiatorssimple, standard Scrum
focus on dependencies & resolutions
Good PO scaling; strong principle alignment, Non-prescriptive — gives suggestionsThe big picture and completeness; getting Agile in the door at large corporations; actively evolvingLots of content; strong in areas such as architecture, design and dev ops; incorporates many good modelsAuthored by Ken Schwaber
Key Risks / Concernslimited scaling, limited documentation, not clearly defined
Not likely sufficient for large scale; some differences in implementation
A more radically agile approach that may be a hard sell in larger traditional orgs with many layers and specializationsLittle info on how, most need certified SPCs to implement properly;
Seen as prescriptive; not agile enough in its structures; quick start and leave issues some places
vague in some areas about the how; can come across as a bit disjointed. Not prescriptive in lifecycleNew approach that is growing and adapting. Some of the parts are secret unless you go to the class
Training / Resource availabilityNone known;
roll your own
Training and coaching network availableYes, multi-level training & CertificationsYes, multi-level CertificationsScaled Professional Scrum training & certification is available
Deployment Approach
(how to get started and make it sustainable)
Self-Organize;
roll your own
Covered now on their siteCan roll your own but usually done with certified coaches (SPC’s) and trainingRoll your own & pick from a large number of possible practicesLikely go to class and probably need SPS coaching
NotesOften misused and turned into a status meetingNow offering certifications as practitioner or trainer. Many of its aspects are based on a fairly profound de-scaling of the org and removing of most specialist teamsBeginning to offer new certifications and have more overlap with Scrum Alliance & Scrum.orgDAD is a hybrid approach which extends Scrum with strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methodsStill evolving. There is an approach for > 9 teams (Neus+) but it is only taught at SPS class. Currently, practices are also only taught at SPS class and are not publicly available

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному4
LinkedIn

Схожі статті




62 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Отличная статья. Спасибо.

Отличная статья — обзорно по разным фремворкам. Я бы еще в обзор добавила Scrum @ Scale. Спасибо за статью!

Спасибо, очень познавательно. Учитывая емкость и краткость могло стать похожим на краткое изложение шедевров мировой литературы. Хорошая статья о структуре процессов при использовании различных гибких методологий. Интересно бы почитать о возможном алгоритме выбора при разных условиях.

покупайте наших слонов!

Как минимум все схемы, кроме двух последних, это всего лишь факт признания гурами скрама, что многоуровневая иерархия тоже нужна — и смысл в них ровно тот, что они наконец соизволили превозмочь свою гордыню и признаться, что плоских схем недостаточно.

Общий здравый смысл из остальных — это то, что если собираешь совещание на каком-то уровне (хотя мне больше нравится слово «нарада»), то обычно полезно из каждой подчинённой структуры призывать не только его начальника, а 2-3 человека. Больше обычно не надо, толпой дела не решить, хотя раз в месяц полезно и «общее собрание» на сотню-полторы, с напитками согласно духу конкретного места.
И да, в таком виде оно естественно расширяется на любое количество уровней иерархии, пока гуры с трудом осиливают проблемы двухуровневости.

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

TL;DR:
Нет скрама — нет проблем.

«Їхав скрам через скрам, бачить раптом — скрам, скрам, скрам».

Мені згадується та думка, що коли ти йдеш в лікарню і обираєш, до якого лікаря звернутися — то в цей самий момент ти обираєш свою хворобу, адже будь-який лікар що-небудь у вас та й знайде. Так само і тут — якщо ти обираєш для керівництва великим проектом професійного скрамщика — то буде в тебе і скрам, і скрам оф скрам, і скрам оф скрам оф скрам і так далі в будь-яких комбінаціях.

«Просто додамо ще один дейлік», «До 30% часу на комунікації» — боже, який жах.

повага до інфопульс зробила++

Припинити займатися хєрнею та почати деліверити. Нє? Надто складно? )

Если знаете более эффективный подход организации работы 40+ людей, поделитесь.

Береш 40+ людей і деліверіш (таблічка з іронієй).

60 тысяч лет назад люди не объединялись в такие большие группы. Максимум ~100, и то, обычно меньше. Больше природа не выдерживала.

О группах больше 1000 имеет смысл говорить только примерно 5-6 тысяч лет назад, и тогда была утверждена иерархическая схема (с богами на вершине).

Остальное опишу в комментарии верхнего уровня.

Хотя 1000 и 100000000 тоже в + входят.

Ыменно.

Вообще для 60000 лет типично было до 20-30 (ну, разумеется, с постоянным обменом с соседями).

Плоский скрам плывёт уже от 20 :)
«Совпадение? Не думаю» ™

Навскидку — только что до сотни добрался.

Ну вот он и вышел на этот уровень :)

Чесслово, я бы на нём скорее взял армейский устав и почитал обязанности командира роты. Всяко полезнее.

Не совсем.
У Паркинсона любой комитет становился бесполезным при переходе через границу 20. Оптимум он считал на основе в районе от 7 до 11, причём это ещё рабочее состояние. Источник, если что. По моему опыту примерно так же. Его рассказ, что выше 10 нельзя собрать, не подтверждается в нашей специфике — часто и трёх нельзя собрать, так что 10 даст больше шансов на устойчивость, чем 7.

А вот выше 15 уже да, бардак и говорильня.
Стандапы в таком количестве уже почти не работают (хотя я вообще считаю их бесполезными: достаточно раз в неделю или две, в остальное время лучше что-то вроде общего чата).

Вот заглянул в скайп. У нас сейчас daily standups по видео. Последние несколько времён: 4:42, 12:42, 8:05, 5:55, 5:00, 6:02, 5:18, 3:28, 6:30, 3:17, 3:40...
вполне вкладывается в понятие «пятиминутка», ящетаю.
Или ты про идею вести только стоя? Ну чтобы 5 минут не превращалось в 45, оно, по слухам, помогает.

> Ну я же упростил и утрировал немного.

Ну оказалось не немного :)
проехали.

Команди до 7 людей. Звітують своєму керівнику (називайте його як завгодно), витрачаючи на це не більше 10% робочого часу. Керівник команди спілкується з керівниками паралельних команд і керівником вищого рівня — багато спілкується, це його робота. Періодично коригує задачі своєї команди для відповідності загальній цілі. Кожного разу, коли комусь зверху\знизу\збоку хочеться провести зайвий мітинг — на нього йде керівник команди, не відволікаючи інженерів від роботи.

витрачаючи на це не більше 10% робочого часу.

если что это 4 часа считая 40-часовую неделю итого 208 часов в год считай 5 недель +1 день непрерывной fulltime работы

Звітують своєму керівнику

к.м.к. это мягко говоря жопа простите ))

если что это 4 часа считая 40-часовую неделю

Полистайте коменти — автор статті пропонує спілкуватись 30% часу, а це 12 годин на тиждень або десь 4 місяці фултайму :)

к.м.к. это мягко говоря жопа простите ))

жопа чи не жопа, а таким способом людей в космос запускали і хмарочоси будували. А з нашим поточним скрамом — в кожному другому проекті, де треба форму і три кнопки на БД натягнути, затримки на три місяці і «моральне вигорання»

Удобнее считать на рабочий день, тогда получается ~45 минут говорильни на день.
Ну, если это совещания по методам реализации, я бы ещё понял, или там взаимообучение с обменом опытом, но если это именно стандап — то точно она самая двуединая.

Мне иногда кажется, что вы в параллельном мире живете. А как раньше организовывались 40+ людей? Может стоит попробовать нанимать толковых инженеров, которые знаю зачем и как педалить, а не вайтишников, которым нянька нужна? Зашел на ваш линк, бекграунд тупо манагерский, т.е. как и что работает вы слышали только краем уха, может быть что-то узнали из ДонНТУ, это все. И вы рассказываете как построить работу технарей? Интересно было бы послушать ребят из SoftServe с опытом 10+ в кодинге, что они думают по поводу этих ваших дейликов с дейликами над дейликами.

вам уже говорили что ви очень токсичный?)))

1) Зайти в сообщество медиков
2) Написать пост о гомеопатии
3) Получить по щам сцаными тряпками
4) Обвинить сообщество в токсичности

www.youtube.com/watch?v=D_KfgdsFkPc

Если Вам, как Вы говорите, не попадалась на глаза полная информация по управлению гигантскими проектами, то это означает одно из двух: эти техники слишком секретные, либо в огромных проектах никакие стройные техники не работают
И если по софту архитекторы IT-гигнтов постоянно устраивают конференции и митапы, то я лично не сталкивался ни с рекламой, ни с перепостами конференций сркам-мастера Microsoft Office или Mac OS. Что говорит в пользу второй версии.
Мое мнение такое, что вместо супер-скрам-мастера в этих компаниях используются супер-архитекторы, которые в тишине и спокойствии раздают разным проектам документацию по api. Дальше идет обычный agile, а разговорами занимаются больше менеджеры, чем тимлиды и амбасадоры. Которые, как тут правильно заметили, луше сотню тестов напишут ии код ревью сделают

Есть старая умная пословица, что нет смысла стегать дохлую лошадь.
Если конкретная методология управления «трещит по швам», вариантов тут немного:

1. Методология сама по себе неудачна
2. Методология не подходит для конкретного проекта, по разным причинам (специфика бизнеса, специфика продукта, география, имеющиеся разработчики, whatever )
3. Все вокруг откровенные саботажники и враги народа

Пункт 3 в РЕАЛЬНОСТИ встречается очень редко. Проблемы же пунктов 1 и 2 не решаются очередным дополнительным уровнем скрамов в принципе.

По моим наблюдениям № 2 — самая частая причина. Плачут, колются, но продолжают жрать кактус потому что очередной евангелист красиво всё рассказал.

Хорошо написано, чувствуется опыт, который не пропьёшь ;)
Единственное уточнение, за SAFe, по: «Некоторые церемонии подразумевают, что вся команда работает в одной локации или хотя бы временной зоне».
Ни одна не подразумевает. Очень желательно, но не обязательно. Проверено многочисленной практикой групп с расположением команд в 4 разных таймзонах.

Спасибо, за комментарий.

Я не имел ввиду, что это не возможно, но, к примеру, PI Planning проводить по ремоуту менее эффективно. Многие клиенты свозят все команды в одну локацию, это дополнительные затраты на кост продукта.

Когда все (к примеру команда в 120 человек) находится в одном месте — это идеально, но очень редко случается в реальной жизни ;)
Поскольку SAFe абсолютно не ограничивает вас в выборе того как именно достичь цель конкретного мероприятия, народ придумывает очень интересные приемы, из того что видел сам:
— видеозаписи представлений идеи плана команд
— сдвигать время проведения планирования чтобы делать работу одновременно, комбинируя работу со стикерами и электронными досками
— собирать вместе в выбранном location не все команды, а по 1-2 представителя от каждой офиса. Тут достигается и экономия по средствам и инженерам очень полезно прокатиться в другю таймезону и там поработать в команде с коллегами...
P.S. sorry, только не надо это воспринимать как молитву кокретному фреймворку ;)

Обзор хороший. С одним проектом и кучей команд понятно как работать.
А вот как работать, когда одна команда и разные проекты?
Как построить завод?
Есть опыт у SoftServe?

Да, есть. К примеру DevOps команды. Одна команда на несколько проектов. Обычно работа таких команд организовывается как сервис. Если жесткие SLA, тогда выстраивается процесс по ITIL практикам (Service Operation), более простой вариант — Kanban.

Даже не хочу видеть этого несчастного ПО на 8 команд

Если вы про LeSS, то на практике, из того, что я видел, более 4 команд выделяют Area Product Owner-ов.

Это все хорошо и весело, но когда код писать? и главное — когда на него тесты писать?

Как показывает практика, на коммуникацию уходит до 30% времени. Если знаете более эффективный способ организовать работу 40+ людей, поделитесь.

Пишем код, бля💦ь macode.ru

Ответ прост: бухать. В любой непонятной ситуации нужно бухать.

Хорошая попытка, скрам-мастерята! Но нет, вы все еще бесполезны.

Це був не справжній соціалізм scrum

Нужно закрывать парковки для скрам-мастеров.

к daily stand-up добавляем еще один daily stand-up

это пять

Вопросов меньше чем ответов... Надо либо вопросов добавить, либо «крестик снять». В чем тут альтернатива, когда все без исключения в основе содержат Agile подходы?? Не понятно какое отношение все вышеизложенное имеет к упомянутому кейсу трансформации, если вообще имеет... В общем thx Cap!

Дмитрий, не очень понял какие вопросы-ответы вы имели ввиду, как и идиому с «крестиком».

В данной статье я описал наиболее популярные подходы организации работ нескольких команд над одним проектом/продуктом. Да, они все про Agile-разработку.

Кейс по трансформации навел на мысль собрать информацию в одном месте. Я не собирался тут публиковать кейс стади.

Роман, лично у меня один вопрос: «ЗАЧЕМ этот пост?». Заметьте, не «почему» — Вы ответили про трансформацию итд, а «ЗАЧЕМ». Вы дали массу ответов на не очень конкретный вопрос (он в заголовке — если Вы внезапно не заметили). Про «крестик снять» -> lmg4u)))

Підписатись на коментарі