Скрам ръководство | 16. Масштабиране на Скрам

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

Мащабиране на Скрам – съдържание:

1. Въведение
2. Scrum@Scale
3. Скрам на Скрамите
4. Допълнително мащабиране и проблеми с Scrum@Scale
5. Резюме

Въведение

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

Много предприятия се справят добре без мащабиране на Скрам. Дори ако много Скрам екипи работят едновременно, те не се нуждаят от координация, тъй като групите действат независимо. Въпреки това, това не означава, че става въпрос за много екипен Скрам. Нуждата от мащабиране възниква само когато повечето от организацията работят по един продукт и могат ефективно да синхронизират своите многобройни Скрам екипи.

Повечето организации, които приемат гъвкави методи на управление в мащаб, избират модела SAFE или Scaled Agile Framework. Днес обаче няма да се фокусираме върху SAFE, а ще обсъдим различен модел, наречен Scrum@Scale, тъй като според 15-ия доклад за състоянието на гъвкавостта от 2021 г., той е вторият най-добър избор сред бизнеса, които избират гъвкавост.

Scrum@Scale

През 1996 г. създателите на Скрам, Джеф Сътерланд и Кен Швабер, работеха по голям проект. Докато го правеха, имаха проблеми с поддържането на по-малки екипи, работещи в Скрам, в синхрон. Те измислиха начин да го мащабират, който в крайна сметка нарекоха Scrum@Scale.

Аналогичен на официалното ръководство за Скрам беше Ръководството за Scrum@Scale, което определя този начин на мащабиране на работата като:

Рамка, в която мрежи от Скрам екипи работят, следвайки ръководството за Скрам, за да решават сложни адаптивни проблеми и креативно да доставят продукти с възможно най-голяма стойност.

Основната предпоставка на Scrum@Scale е простота и ефективност. Следователно, неговата работа се основава на архитектура без мащаб. С други думи, той използва Скрам, за да мащабира Скрам. По този начин, Скрам екип, съставен от индивиди, действащи като Продуктов собственик, Скрам майстор или Разработчик, става Скрам на Скрамите: екип, състоящ се от екипи.

Скрам на Скрамите

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

• Екип на продуктовите собственици – група от продуктовите собственици, които се срещат, за да се споразумеят за приоритети и да създадат единна визия за продукта
• Главен продуктов собственик – продуктовият собственик на Скрам екипа или лице, което се занимава изключително със Скрам на Скрамите
• Скрам на Скрамите майстор – лицето, което наблюдава ефективността на Скрам на Скрамите.

Те се срещат на същите Скрам събития и използват подобни артефакти.

Допълнително мащабиране и проблеми с Scrum@Scale

Архитектурата без мащаб на Scrum@Scale означава, че тя позволява мащабиране повече от веднъж. Ако една организация трябва да координира екипи на още по-голям мащаб, може да създаде Скрам на Скрамите.

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

Мащабиране на Скрам – резюме

Мащабирането на Скрам не е детска игра. То изисква Скрам екипите да прилагат умело принципите на Скрам и да синхронизират задачите си с другите Скрам екипи. Следователно, основният въпрос, на който трябва да се отговори, е: Нужно ли е мащабиране? Само защото в една организация има много Скрам екипи, не означава автоматично, че координирането им ще доведе до по-добри резултати.

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

Ако харесвате нашето съдържание, присъединете се към нашата активна общност на Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.