Крос-функционалните екипи и скритите зависимости
Научете защо крос-функционалните екипи все още се борят със скрити зависимости и как Scrum екипите могат да премахнат външните прехвърляния на работа, за да доставят Done Increment всеки Sprint.
Повечето софтуерни организации твърдят, че имат крос-функционални екипи. На хартия всеки екип разполага с няколко програмисти, тестер и може би дизайнер. В действителност работата продължава да спира всяка седмица, защото някой извън екипа трябва да прегледа миграция на база данни, да конфигурира облачен клъстер или да одобри релийз. Scrum ръководството от 2020 г. дефинира крос-функционалните екипи като екипи, чиито членове притежават всички необходими умения за създаване на стойност всеки Sprint. Когато един екип не може да направи внедряване, без да чака външни контролни органи, крос-функционалността остава просто организационен етикет, а не оперативна реалност.
Фалшивият комфорт на списъците по отдели
Често срещаната грешка е сформирането на екипи въз основа на длъжностни наименования, а не според пътя на създаване на стойност. Мениджърите събират в една стая петима backend разработчици, един frontend разработчик и един инженер по качеството, след което ги обявяват за крос-функционален екип. Ако обаче тази група все още разчита на централен екип по сигурност за сканиране на уязвимости или на централен екип по поддръжка за качване на код в тестова среда, тя остава фундаментално зависима от останалата част от компанията.
Тези прехвърляния на задачи създават опашки, а опашките разрушават работния поток. Разработчик завършва функционалност за два дни, но тя престоява в опашка за външен преглед шест дни. Натрупва се незавършена работа, контекстът се губи и до момента, в който външната страна поиска промени, първоначалният разработчик вече е преминал към нещо друго. Това, което е изглеждало като автономен екип, всъщност е просто поредната станция на поточната линия.
Къде се зараждат скритите зависимости
Зависимостите рядко се проявяват по време на Sprint Planning. Те се крият в неизказаните предположения за начина, по който се върши работата. Обикновено можете да ги забележите, като наблюдавате къде работата спира да се движи:
- Инфраструктура и пайплайни за внедряване, контролирани изцяло от отделен платформен или DevOps отдел.
- Архитектурни съвети, които заседават на всеки две седмици, за да одобряват промени в схемата на базата данни или избор на технологии.
- Специализирани споделени услуги като информационна сигурност, съответствие с регулациите или преводи, които служат като финални бариери преди релийз.
- Споделени кодови бази, при които друг екип притежава хранилището и трябва да одобри pull request заявките, преди кодът ви да бъде обединен.
Зависимости, маскирани като управление
Много зависимости продължават да съществуват, защото компаниите бъркат доброто управление с контрола. Отделът по сигурност иска да гарантира надеждността на кода, затова изисква ръчни одити преди релийз. Администраторът на бази данни иска да предотврати бавни заявки, затова настоява сам да пише всички миграции към производствената среда. Тези политики започват с добри намерения, но съсипват скоростта на доставка.
Истинската крос-функционалност не означава пренебрегване на правилата и стандартите. Тя означава трансформация на контрола от ръчни проверки към автоматизирани защитни механизми. Вместо да се изисква външен инженер по сигурността да инспектира всяка заявка за сливане на код, екипът по сигурност може да осигури автоматизирани инструменти за сканиране и библиотеки, които се изпълняват директно в пайплайна на екипа. Когато екипът разполага с инструментите и правомощията да покрива организационните стандарти самостоятелно, зависимостта изчезва.
Как да изградите истинска автономия
Ако искате екипи, които доставят използваем, Done Increment всеки Sprint, трябва системно да премахнете тези външни връзки. Започнете с картографиране на всяка стъпка, необходима за придвижване на една идея от дефиницията до производствената среда. Всеки път, когато този път излезе извън рамките на Scrum екипа, вие сте открили зависимост, която застрашава предвидимостта.
След това имате два избора. Можете да внесете необходимата компетентност в екипа, като обучите съществуващи членове или привлечете специалист в съответната област, или можете да автоматизирате външната проверка, така че екипът да я изпълнява самостоятелно. Крос-функционалните екипи не се създават чрез преначертаване на организационната структура. Те се създават чрез премахване на прехвърлянията на работа, които пречат на хората да завършат започнатото.