ЗА АВТОРА: Роман Резников е Agile Process Consultant в SoftServe,  предишната му позиция е PMO Competence Manager.  В момента е отговорен за посоката People Excellence. Занимава се с разработване модели за компетентност за проджект мениджъри. Също така оптимизира процесите за подбор на външни кандидати, оценка на знанията и ефективността на ръководителите на проекти на всички нива. Координира програми за ментори и онбординг процеси за проджект мениджъри. Заедно с SoftServe university разработват обучения за проджект мениджъри.

 

 

Известно време Scrum и Kanban бяха напълно достатъчни за по-голямата част от проектите, с които работих. С нарастването на устойчивите проекти трябваше да мисля за алтернативни начини за изграждане на по-големи екипи без някакви фундаментални трансформации на процесите. След неотдавнашен проект за трансформация Agile за един от клиентите на Global 500 реших да структурирам познанията за мащабируеми подходи. Дълго време търсих такава статия, но успях да намеря само някои откъси, затова реших да я напиша сам.

Scrum of Scrums

Да започнем с нещо просто: Scrum of Scrums. Едва ли бих го нарекъл нова рамка или методология. По принцип разделихме един голям Scrum екип на подекипи. Всеки екип използва Scrum, като в допълнение към ежедневните срещи (стендъп) провеждаме още една, заедно с представители от всеки екип.

Казано по-просто, ние просто добавяме още една среща, където екипите могат да синхронизират работата си. Честотата на провеждане на такива срещи може да варира в зависимост от нуждите на бизнеса. Все пак се препоръчва да се прави допълнителна ежедневна среща (стендъп) поне два пъти седмично. Тази конкретна среща се нарича Scrum of Scrums. В редки случаи може да се използва още едно ниво — Scrum of Scrum of Scrums.

ПредимстваНедостатъци
Ясно и просто изпълнение

Приложимо за 2–3 екипа

Не важи за разрастващи се екипи (напр. работни задачи, роли, планиране и т.н.)
Мащаб: 2–4 екипа Scrum (до 25–30 лица)

Nexus

Следващият подход, който ще разгледаме, е Nexus. Nexus е разработен и поддържан от Кен Швабер и Scrum.org. Nexus е разширение на Scrum, позволяващо координиране на работата на няколко екипа върху един инкремент. Точно както и Scrum, Nexus се състои от роли, церемонии, събития и артефакти.

Какво е новото:

  • новата роля: функции на екипа за интеграция на Nexus (Nexus Integration Team): координация, инструктаж/обучение, мониторинг и управление на процеси.
  • нови артефакти: Nexus списък от работни задачи, които трябва да бъдат изпълнени в конкретния спринт (Sprint Backlog) и интегриран инкремент (Integrated Increment). Екипите работят по един списък със задачи (Product Backlog). По време на спринт всеки екип има свой списък задачи за спринта (Sprint Backlog). Има и Nexus Sprint Backlog — структура на работните задачи на всички екипи, която гарантира прозрачността на работата на всички. Интегриран инкремент (Integrated Increment) — резултат от съвместната работа на екипите.
  • нови церемонии: приблизително еднакви с тези на Scrum, но едно ниво по-високо и с представка Nexus:
  1. Nexus планиране на спринт (Nexus Sprint Planning)
  2. Nexus работни задачи за спринт (Nexus Sprint Backlog)
  3. Nexus ретроспекция на спринт (Nexus Sprint Retrospective)
  4. Nexus преглед на спринт (Nexus Sprint Review)
  5. ежедневна Scrum среща Nexus (подобно на Scrum of Scrums)

Вярвам, че за тези, които са запознати със Scrum, спецификите на церемониите, описани по-горе, ще бъдат съвсем ясни. Прочетете повече тук.

Нека разгледаме по-подробно един Nexus екип. Nexus екипът е просто още един Scrum екип, чиято цел е да разреши всички проблеми с интеграцията. Този екип е отговорен за успешното интегриране на работата, извършена от всички екипи Scrum в Nexus. Интеграцията включва справяне с всички технически и нетехнически ограничения между екипите, които могат да предотвратят доставката на интегрирани инкременти по време на всеки спринт.

С времето съставът на екипа за интеграция на Nexus (Nexus Integration Team) може да се променя, за да отразява текущите потребности. Екипът за интеграция на Nexus (Nexus Integration Team) се състои от:

  • отговорник за продукта (за определяне на работните задачи и техния приоритет)
  • Scrum мастер
  • един или повече членове на екипа за интеграция

Когато това е подходящо и съществува необходимост, членовете на екипа за интегриране на Nexus също могат да работят в Scrum екипите в този Nexus. В този случай работата в екипа за интеграция на Nexus има приоритет.

Открийте повече подробности за екипа за интеграция на Nexus тук.

 

ПредимстваНедостатъци
Процесите са подобни на тези за потребителите на Scrum

Фокусирани са върху интеграцията и отговорната екипна работа върху интегрирани проблеми

Един екип е изцяло посветен на работата по интеграция.

Допълнителни разходи особено за малките екипи

Мащаб: 3–9 Scrum-екипи (до 50–60 лица)

LeSS и Less Huge

Ако нашият екип нарасне до над 20 души, ние добавяме към обичайния Scrum още една среща за синхронизиране на представителите на екипи, като по този начин получаваме Scrum of Scrums. Ако екипът допълнително нарасне — до над 30 души, ще организираме отделен екип, който да интегрира работата на другите екипи. Добавяме и още едно ниво на церемонии: точно както в Scrum, само че с едно ниво по-високо. И така получаваме Nexus.

Нека да разгледаме по-нататък едромащабния Scrum (Large Scaled Scrum (LeSS). Той прилича на Nexus, но все пак има някои разлики. Общите характеристики на LeSS и Nexus:

  • до 8 Scrum екипа
  • един отговорник за продукт
  • общи работни задачи
  • общ DoD (критерий за готовност)
  • синхронизирани спринтове
  • общ инкремент

Разлики между двата подхода:

  • в LeSS на първия етап от планирането са поканени не само представители на екипите, а целите екипи
  • на втория етап LeSS въвежда идеята за едновременно планиране
  • Nexus е описан в документ от 12 страници, докато LeSS предлага ресурсна база данни (works) с описание на множество принципи и практики

Когато броят на екипите надхвърли 8, LeSS се мащабира до разширена версия — LeSS Huge.

Общи характеристики на LeSS и LeSS Huge:

  • списък с работни задачи за един продукт
  • общ критерий за готовност
  • един инкремент на потенциално готово програмно решение
  • един (общ) отговорник за продукт
  • общ синхронизиран спринт

Нови характеристики на LeSS Huge в сравнение с LeSS:

  • нова роля — отговорник за група продукти
  • нови артефакти — изисквания в области в работните задачи за продукт (Product Backlog) и работните задачи за група продукти (Area Backlog)

ПредимстваНедостатъци
Ефективно използване на ресурсите, отсъствие на нефункционални екипи (Nexus) или нефункционални спринтове (PI-Sprint)

Две версии: до 8 и над 8 екипа

Уникална база от знания

Изисква ясно разделяне на работната зона между екипите за свеждане на зависимостите до минимум

По-малко подходящи за разпределение екипи

За изпълнението на някои церемонии от съществено значение са общото местоположение и часовата зона

Мащаб: LeSS — 2–8 Scrum екипа, LeSS Huge — повече от 8 екипа, <1 000 служители на пълен работен ден (FTE).

В обобщение, току-що анализирахме подходите на база от „по-прост към по-сложен“. Първият подход (Scrum of Scrums) има форма на допълнителна среща, вторият (Nexus) е истинско разширение на процеса Scrum, докато третият и четвъртият подход (LeSS и LeSS Huge) не са просто процеси, а база от знания, съдържаща различни аспекти, свързани с екипната работа.

SAFe

Следващият подход е също толкова ценен както като методология, така и като набор от най-добри практики (еквивалентен на PMBoK в Agile) — Scaled Agile Framework (SAFe).

Тъй като базата от знания непрекъснато се актуализира и разширява, подходът се модифицира от само себе си. Към момента на написването на настоящата статия актуална бе версия 4.6. SAFe не се отличава с нищо свръхестествено — той е комбинация от съществуващи практики, обединени под един чадър. Базата му е добре структурирана и позволява добра навигация през главната страница с кликване върху икони. Дори да нямате намерение да имплементирате SAFe, можете просто да се запознаете с интересни аспекти на екипната работа в Agile.

SAFe се състои от четири нива и има четири конфигурации.

Основната конфигурация работи до 125 FTE (служители на пълен работен ден) (в действителност могат да бъдат повече). Има две нива: Програма и екип. На ниво екип SAFe следва Scrum, XP или Kanban. Единствената разлика е планирането на програмен инкремент (PI Plannings) и планиране и иновационни спринтове (Innovation sprints). Всички екипи трябва да следват принципите на SAFe и основните ценности. Екипите също трябва да използват една и съща продължителност на итерациите. Между SAFe Dev екип и Agile екип има още една разлика.

На програмно ниво SAFe се отнася към влаковете като график на работата по даден проект (scheduled value pipeline). Накратко, дългосрочен екип, съставен от екипи в Agile (Agile Release Train или ART), е програма за 5–12 екипа или 50–125 лица в екипа, работещи върху едно и също решение. На това ниво имаме нов набор от роли:

  • продуктов мениджър (Product Manager) — отговаря за работното съдържание на програмно ниво (за Release Train). POs супервайзър
  • системен архитект (System Architect) — отговаря за техническата и архитектурна визия на Release Train
  • RTE (Release Train Engineer) — насочен към улесняване и ръководство на работата на ART

За разлика от Nexus, където всички членове на екипа са равни на останалите, в SAFe има йерархия, при която ролите на програмно ниво се контролират на ниво екип. На това ниво има много други атрибути и по-добри практики, като оценената стойност на забавянето, разделена на обема на работата (WSJF), инструмента за прилагане на стратегията (Architectural Runway), DevOps и т.н.

Има още церемонии, подобни на Nexus

  • Scrum of Scrums и PO синхронизациите са само по-високо ниво на ежедневните срещи (стендъп)
  • честота на произвеждане на код (Cadence) — 8–12 седмици итерация на ниво програма. PI (програмен инкремент) като събитие, базирано на използване на регулярен, предвидим ритъм за разработка – писане на код (Cadence)
  • итерация на иновация и планиране — вместо подготовка на списък с работни задачи (backlog grooming). Единствената пълна итерация за изясняване и тълкуване на обхвата за следващото произвеждане на код

PI планиране — подобно на спринт планиране (Sprint Planning), но на едно ниво

Конфигурацията на портфолио (Portfolio Configuration) добавя по-високо ниво към Основната конфигурация (Essential Configuration). Осигурява необходимите процеси, роли и инструменти, за да помага на организациите да постигнат своите стратегически цели чрез изграждане на необходими системи и решения.

От гледна точка на ролите има друга скала от три подобни роли на предишното ниво на програма и екип:

  • функция, управляваща всяко портфолио SAFe, осигуряваща стратегия и инвестиционно субсидиране (Lean Portfolio Management)
  • инженери, отговарящи за най-грубата разбивка на програмата (Epic Owners)
  • главен архитект (Enterprise Architect)

Тази конфигурация предоставя набор от артефакти, подходящи за това ниво. Най-често се използва друго ниво на елементи от списъка с работни задачи, наречени теми (Themes) и големи части от работата (Epics). За да разрешим нашето решение по теми, а не по Epics, характеристики (Feature) и потребителски истории (User Stories), ние изграждаме класически WBS. Lean Portfolio Management предлага модел, подобен на бизнес модела Canvas, наречен Portfolio Canvas, независимо от това, че включва Lean подходи.

Конфигурацията с голямо решение, разработена за разработване на сложни системи, се състои от няколко потока Agile Release Train (ART). Нивото на портфолиото управлява корпоративния мащаб, като изравнява потоците от стойности с ARTs, докато нивото, поддържащо решения, изискващи множество ARTs (Large Solution), дава възможност за изграждане на екип за разработка и определен брой потоци в рамките на един продукт.

В обобщение, нивото на портфейла е вертикално мащабиране, Large Solution е хоризонтално мащабиране. От всички описани по-горе подходи конфигурацията на Large Solution може да се сравни с LeSS Huge.

Структурата на това ниво е подобна на програмното ниво. Вместо Agile Release Train (ART) на това ниво има организационна концепция, която се състои от множество ART. Организационната концепция (Solution train) интегрира всички ARTs в корпоративна мисия и бизнес цел. На това ниво са въведени три нови роли:

  • Solution Manager — отговаря за съдържанието на работата в решения с голям мащаб (за Solution Train). Освен това контролира PdMs
  • Solution Architect — отговаря за техническата и архитектурна визия на организационната концепция
  • инженер STE (Solution Train Engineer) — улеснява и ръководи работата по организационната концепция (Solution Train)

Както може би сте забелязали, те са много подобни на програмното ниво.

Освен нови роли на това ниво имаме и нов набор от срещи:

Както е показано на фигурата по-горе, има някои общи срещи за ниво големи решения и на програмно ниво. Например, подготовка за PI планиране и семинар за проверка и адаптиране (Inspect & Adapt). Някои срещи са подобни на програмното ниво, но просто са на едно ниво по-високо, например, демонстрация на решение Solution Demo и синхронизиране на Solution Train. Срещите Slight са съвсем нови и служат за хармонизиране на съвместната работа на всички ART, напр. Architect Sync, Pre- и Post-PI Plannings.

Освен нови роли и нови церемонии има и други подобрени практики, които предоставят насоки и управление на това ниво, напр. Solution Intent, Solution Context, Economic Framework и др.

Пълният цикъл включва конфигурация на ниво портфолио (Portfolio Configuration) и конфигурация на ниво големи решения (Large Solution Configuration), създавайки мащабируемо управление за участие на множество ART и привеждането им в съответствие с фирмените цели.

Обобщението на йерархията SAFe е представено в статията на Дарън Уилмсхърст в неговия блог.

Тази ERD диаграма показва зависимостите между различните нива на SAFe и как те взаимодействат помежду си. Освен Enterprise версия, SAFe предлага най-добрите практики за управление.

В заключение, SAFe е доста сложна рамка, предоставя разширен поглед върху различни аспекти на разработката на софтуер, които не са обхванати от други (например DevOps, Quality, Backlog структура). Въпреки че това работи добре при едромащабни продукти, с много вътрешни кръстосани зависимости, не винаги е лесно продуктът да бъде разделен на няколко части и просто да се определят различни екипи, които да работят върху тях, без никаква координация. SAFe предоставя модел за управление и надзор за тази цел до корпоративно ниво.

Прочетете повече за различните рамкови подходи в рамките на мащаб една компания тук.

ПредимстваНедостатъци
Прилага се за проекти с различен размер: от 1–2 екипа до екип от 25 000 лица (Australia Post)

Значителна база от данни за знания

Разгледани са много аспекти на разработката, като всяко ниво има свои роли и церемонии

Описва не само процеси, но и технически аспекти (DevOps, архитектура и т.н.)

Чудесна екосистема за сертифициране и обучение

Нова нефункционална PI spring, добавена към програмното ниво

Определени церемонии предполагат, че целият екип е в една и съща часова зона или местоположение, което е сложно за разбиране

 

Мащаб

Екип — 5–9 FTE

Програма — <125 FTE

Ниво големи решения (Large Solutions) и портфолио (Portfolio)

Следващият подход напомня базата от знания или Agile Wikipedia, а не рамка или методология. Той осигурява инструментариум и гъвкавост на действията, но изисква фундаментален опит от изпълнителя.

Ориентираният към хората, насочен към обучението хибриден Agile подход за доставка на IT решения (Disciplined Agile Delivery (DAD) е последният елемент в този отзив.

На първо място, нека да изясним какво представлява Disciplined Agile (DA) според неговите автори. Това е инструментариум за вземане на решения. С други думи DA е набор от инструменти за вземане на процесни решения. По принцип той дава насоки как да се избират процеси в зависимост от ситуацията.

DAD описва различни елементи и случаи на сътрудничество, които изискват специален подход. Както SAFe и той има 4 нива, но все пак се различава по своята структура:

В тази статия ще се съсредоточим само върху първото ниво на DAD.

По своята структура DAD изглежда дори още по-подобен на PMBoK.

Неговите процеси са подредени в групи. Процесите се представят като цели (обхващат въпроса — какво искаме да постигнем). Груповите процеси съответстват на етапите на проекта:

Освен това DAD притежава широк спектър от роли. Има първични роли, които могат да бъдат намерени в проекти от всякакъв мащаб и вторични роли, които се появяват временно на ситуационна (ad hoc) основа.

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

Както подсказва името, DAD е фокусиран основно върху доставката на продукт (Delivery). По-долу е представено обобщено описание на процеса:

На потребителите се препоръчва да направят избор от 6 различни типа жизнен цикъл на разработка:

 

DAD екипът се адаптира към най-подходящия жизнен цикъл.

Открийте по-подробно описание как да изберете жизнения цикъл тук: A Full Agile Delivery Lifecycle.

До неотдавна DAD беше собственост на PMI.

ПредимстваНедостатъци
Гъвкав подход за използване на различни възможности за избор в зависимост от поставените задачиДоста сложна имплементация, изисква от потребителите компетенции на високо ниво
Мащаб

 

Споменатите подходи/практики са най-често срещаните за големи екипи, използващи Agile, но има още много неща, които не са описани в тази статия. За да имате по-широк поглед върху „Agile World“, погледнете това графично представяне mind map.

Както се вижда, всички рамки са различни и трябва да бъдат избрани въз основа на бизнес изискванията. Този файл в Excel формат може да бъде полезен за по-добрата навигация сред рамките.

От моята гледна точка, по отношение на най-популярната рамка трябва да бъдат споменати SAFe (поради добрия маркетинг) и Scrum of Scrums (поради простотата). Последните анкети потвърждават моето твърдение:

Въз основа на втория годишен доклад за Agile на Scale Report 2019:

Въз основа на отчета за основните тенденции на Scrum 2019:

Въз основа на 13-ия годишен доклад за състоянието на Agile:

Силно вярвам, че по време на консултацията за Agile трансформация, предоставяна за нашите клиенти, е важно не само да изберем правилната рамка, но и да я възприемем правилно, а дори и да я коригираме в зависимост от обстоятелствата.

И както винаги, идеално решение няма 🙂

ЗА АВТОРА: Роман Резников е Agile Process Consultant в SoftServe,  предишната му позиция е PMO Competence Manager.  В момента е отговорен за посоката People Excellence. Занимава се с разработване модели за компетентност за проджект мениджъри. Също така оптимизира процесите за подбор на външни кандидати, оценка на знанията и ефективността на ръководителите на проекти на всички нива. Координира програми за ментори и онбординг процеси за проджект мениджъри. Заедно с SoftServe university разработват обучения за проджект мениджъри.

 

 

Share This