Чуйте аудио версията на тази статия

Независимо дали работите в малък стартъп или върху нов продукт в голяма компания, най-вероятно ще стигнете до момент, когато имате твърде много хора в един екип. Ранното идентифициране на признаците ще ви спести от достигане до най-неефективния етап на екипа.

Всеки продукт е различен, както и екипите, работещи по тях. По този начин разделянето на екип също ще изисква от вас да вземете някои решения, които отразяват вашите обстоятелства. Някои неща, които трябва да имате предвид, са:

• Как да поддържаме целостта на ноу-хау, когато съотборниците вече не работят заедно
• Трябва ли да разделите функциите (например екипи от предния и задния край)?
• Трябва ли новите екипи да имат отделни изоставания?
• Трябва ли екипът за мениджмънт на продукти да нараства съответно?

Кога трябва да започнете да създавате втори екип?

Най-очевидната индикация да започнете да мислите за разделяне на екип или добавяне на нов екип е, когато бюджетът ви се увеличи. Това може да се случи при нов инвестиционен кръг при стартиране или при нови цели за вашия продукт в предприятие. Ако увеличението на бюджета е толкова значително, че вашият екип ще нарасне 3 пъти или повече, тогава не е полезно, че ще трябва да разделите настоящия си екип, за да разпространявате ноу-хау. Решенията обаче не стават толкова ясни, когато нарастването на бюджета нараства и в крайна сметка добавяте няколко нови души към списъка. Ако, да речем, имате планове да разширите екипа си от 7 на 11 души, това изисква ли разделяне? Agile популяризира малки екипи, но също така насърчава индивиди и взаимодействия над процеси и инструменти. Наличието на два или повече екипа неизбежно създава повече процеси, за да могат да работят в синхрон.

Какво казват експертите?

Джеф Безос, основателят на Amazon, използва правило за две пици както за срещи, така и за отбори. Това означава, че всеки трябва да има само толкова хора, колкото две пици могат да хранят по време на обяд.

The Scrum Guide предлага да има между трима и девет членове на отбора, които всъщност изпълняват изоставането в спринта. Това означава, че не бихте включили собственика на продукта или капитана на скрама в общата сума, освен ако нито един от тях не внедри елементите на изоставането в спринта.

Изглежда, че тези числа имат интуитивен смисъл, но има и някаква математика зад тях. Ако мислите за екип, всеки човек е като възел и той се свързва с други възли. Това са междуличностните отношения между съотборниците. Те могат да бъдат приятелски настроени, състезателни, злобни или грижовни. Каквато и да е връзката между двама души, тя все още е връзка, която изисква известна умствена способност от всеки човек. С нарастването на екипа тези числа на тези връзки не растат линейно. Формулата за връзки между възлите е (n (n-1) / 2 ). Ето диаграмата за растеж на връзките:

Диаграмата ясно илюстрира от математическа гледна точка защо екипите работят най-ефективно, когато не са твърде големи. Ако вземем 3 до 9 членове на екипа, предложени от Scrum Guide, в крайна сметка получаваме между 3 и 36 връзки. Ако нараснахме до 15 души, щяхме да имаме над 100 връзки. Екип от това би могъл да работи ефективно само ако задълженията им са много добре дефинирани и рядко се припокриват или ако има някои неофициални подгрупи. Нито случаят, нито желанието при работа, базирана на Agile принципи.

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

Ежедневен скрам

Понякога наричан ежедневен режим, ежедневният скрам е сбирка на целия екип, за да обсъдят напредъка и пречките в спринта. Ръководството за Scrum предлага да ги отчитате на 15 минути и това е добър лакмус тест за размера на екипа. Ако започнете да забелязвате, че вашият екип превишава 15-минутната лента, това може да означава едно от двете неща:

• Ежедневните скрамове не са ефективни. Хората навлизат в твърде много подробности. Или няма ясен ред на говорене и отнема време на съотборниците да говорят. Може би собственикът на продукта или майсторът на scrum използва ежедневния scrum като възможност да предоставя различни актуализации, които не са свързани със спринта.
• Екипът е твърде голям. Ако ежедневните сбивания са ефективни, но все още превишавате 15-те минути, тогава може просто да имате твърде много хора в екипа. Трябва също да започнете да забелязвате, че хората губят интерес, защото има ограничение за това колко информация може да поеме човек. Ако твърде много хора предоставят актуализации, става трудно да се следи напредъка на всички и да се разбира състоянието на екипа . Това кара хората да се обърнат навътре и да обмислят само своя напредък, вместо да търсят възможности да помогнат на другите.

Груминг и планиране на спринта

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

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

Ретроспективна

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

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

Как да разделим екипа

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

Отборен морал

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

Междуфункционални екипи

Scrum популяризира междуфункционални екипи „с всички умения като екип, необходими за създаване на увеличение на продукта“. Това важи при мащабиране до два или повече отбора. За много разработчици, особено ако те са нови за Agile, естествената тенденция е да мислят заедно с техническите линии. Например, екипите често искат да се разделят на екипи от заден и преден край. Това може да има смисъл в някои редки случаи, но като продуктов мениджър , трябва да го съветвате през повечето време. Екип, пълен с предни специалисти, не е в състояние сам да достави увеличение на продукта и естествено ще започне да мисли повече за техническия капацитет, който ги обединява. Вместо това те трябва да се фокусират върху клиента и как да задоволят техните нужди.

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

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

Трябва ли екипите да имат отделни изоставания?

Ако даден екип е разделен, естественият въпрос е дали те трябва да работят от един и същи изоставане или да имат отделни такива. Можем да погледнем към Scaled Agile Framework за насоки.

[имейл защитен]

[имейл защитен] е методология, разработена от създателя на Scrum Guide. [имейл защитен] не е много предписателно и не очертава конкретно как да се справя с изоставането на продуктите. Той обаче отбелязва два момента:

• Процесът на ниво екип е същият, както е изложен в Scrum Guide.
• Собствениците на продукти формират екип от собственици на продукти, където създават единно обединено изоставане. Това се прави, за да се избегне дублиране на работата и да се създаде видимост в компанията. В същото време екипите имат своите отделни изоставания, които захранват елементи от обединеното изоставане.

По същество, [имейл защитен] изображения на новите екипи със собствени съответни поръчки и изоставания. Просто добавя някои допълнителни структури за координиране на работата между екипите. [имейл защитен] работи най-добре с няколко, десетки или стотици екипи, но може да предостави ценна информация, дори ако работите с два екипа.

Голям мащаб Scrum (LeSS)

По-малко насърчава интересен подход към изоставането на продуктите. В LeSS собственикът на продукт работи с два до осем екипа. Може да изглежда невъзможно за един ОО да работи с толкова много екипи. Философията на LeSS е, че организацията на поръчките работи на абстрактно ниво и делегира на екипите отговорностите за усъвършенстване на елементите на изоставането на продукти. В този случай екипите за междуфункционално разработване също трябва да включват знания за бизнес сферата, за да могат да осигурят увеличение на продукта. В LeSS има само едно изоставане.

Как да бъдете в течение

За продуктов мениджър множество екипи означават повече работа за проследяване на напредъка и отговаряне на запитвания.

Приоритизирайте срещите

Ако сте присъствали на ежедневните сбивания на един екип, продължаването на този навик най-вероятно ще бъде непродуктивно. Помислете за ежедневните сбивания като за шанс да навлезете, за да получите пулс на екипите и да им напомните, че сте на разположение за дискусии.

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

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

Ангажирайте повече със Scrum Masters

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

Уверете се, че можете да им се доверите, за да дадат честна представа за напредъка на отбора и всички проблеми, които възникват по време на спринтовете. Тези връзки ще ви позволят да бъдете в течение, без да е необходимо да участвате във всички скрам церемонии.

Представете Scrum of Scrums

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

Помислете за разширяване на продуктовия екип

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

Младши продуктови мениджъри. Един от начините е да поемете по-стратегическа роля за себе си, като същевременно добавите младши продуктови мениджъри, които да се справят с някои ежедневни задължения. Те могат да поемат някои задачи като осигуряване на качеството (QA), писане на спецификации за потребителски истории или създаване на макети на високо ниво за нови функции.

Бизнес анализатори. Друг начин е един или повече бизнес анализатори да работят в екипите или заедно с тях. Продуктовият мениджър може да работи с бизнес анализатори, за да идентифицира продуктовите предположения и след това да позволи на бизнес анализаторите да намерят начини да ги валидират чрез изследвания или нови функции.

Заключение

С нарастването на вашия екип е вероятно да започнете да забелязвате някои признаци, че той става твърде голям, особено в:

• Ежедневен скрам. Ако превишавате 15-минутния срок по време на ежедневни сбивания и виждате, че хората започват да губят интерес.
• Спринт планиране. Ако по време на планирането на спринта все по-често се озовавате в задънена улица.
• Ретроспективна. Ако започнете да забелязвате, че става все по-трудно да постигнете компромиси по време на ретроспективите.

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

• Отборен морал. В идеалния случай трябва да оставите екипа да реши как иска да се раздели, за да сведе до минимум броя на бракуваните добри работни взаимоотношения.
• Междуфункционални екипи. Екипите трябва да притежават всички умения, необходими за създаване на увеличение на продукта.
• Натрупване на продукти. Решете дали вашите екипи ще имат отделно или единно обединено изоставане.

Проследяването на два или повече отбора ще изисква да поставите приоритет. Ефективният продуктов мениджър трябва да планира как ще бъде в крак с новите екипи:

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

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

Разбиране на основите

Колко разработчици има в скрам екип?

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

Кои са членовете на скрам екип?

Екипът за скрам е многофункционален и включва всички хора, необходими за осигуряване на увеличение на продукта. Повечето scrum екипи ще имат специален собственик на продукта и scrum master. Останалата част от екипа може да включва разработчици, дизайнери, тестери или анализатори.

Какво е добрият скрам екип?

Добрият scrum екип е многофункционален с всички умения, необходими за създаване на нарастване на продукта. Той трябва да включва разработчици, дизайнери, тестери, анализатори и т.н.

Какъв е препоръчителният размер за скрам екип?

Scrum Guide препоръчва да имате от три до девет членове на екипа в един екип.