Роли в Scrum: Developers и реалността на самоуправлението
Научете как Developers в Scrum практикуват истинско самоуправление, поемат отговорност за Sprint Backlog, поддържат стандарти за качество и елиминират микромениджмънта.
Много организации твърдят, че искат самоуправляващи се екипи, но малцина разбират какво изисква това от софтуерните разработчици. В Scrum Guide от 2020 г. терминологията се промени от самоорганизиращи се към самоуправляващи се. Тази промяна беше целенасочена. Самоорганизирането означаваше, че екипът решава как да свърши работата. Самоуправлението означава, че екипът решава кой какво прави, кога и как. За Developers тази автономия носи пряка и неизбежна отговорност за продукта и неговия Increment.
Кой какво прави, кога и как
При традиционната организация на проектите архитектът определя техническия дизайн, проектният мениджър разпределя задачите, а тест мениджърът решава кога софтуерът е готов за пускане. Scrum заменя тази разпокъсана верига с една обща група, наречена Developers. Всеки, който допринася за създаването на използваем Increment по време на Sprint, е Developer, независимо дали специалността му е бекенд програмиране, UI дизайн или инфраструктура.
Когато един екип е наистина самоуправляващ се, никой мениджър не възлага индивидуални задачи. Ако дадена миграция на база данни трябва да се изпълни преди тестването на API endpoint, самите Developers координират тази работа помежду си. Те не чакат водещ специалист да раздели задачата на подзадачи. Те решават кой да я поеме, как да бъде прегледана и кога да бъде слята в основния клон.
Sprint Backlog принадлежи на Developers
Границата между ролите в Scrum е категорична. Product Owner определя какво да се изгради, като подрежда Product Backlog и изяснява нуждите на клиентите. Developers решават колко работа могат да прогнозират за даден Sprint и как точно да я изпълнят. След като Sprint Goal бъде избрана по време на Sprint Planning, самият Sprint Backlog принадлежи изцяло на Developers.
Това разделение предпазва екипа от микромениджмънт, но и елиминира оправданията. Мениджър не може насила да вмъква допълнителни задачи в активен Sprint. В същото време Developers не могат да обвиняват външен ръководител, ако прогнозата се окаже неточна. Developers притежават плана. Когато по средата на Sprint открият, че дадена задача е по-сложна от очакваното, те преговарят за обхвата с Product Owner, но техническите решения остават изцяло техни.
Отговорност и Definition of Done
Самоуправлението се проваля незабавно, ако качеството се приеме за нещо пожелателно. В Scrum качеството е безусловно фиксирано чрез Definition of Done. Scrum Guide изрично посочва, че Developers носят пряка отговорност за осигуряването на качество чрез стриктно спазване на този стандарт.
В неефективните компании екипите правят компромиси, за да спазят произволни крайни срокове, разчитайки, че QA отделът ще открие дефектите по-късно. Една самоуправляваща се група от Developers не може да работи по този начин. Ако даден елемент не покрива критериите в Definition of Done, той не може да бъде издаден и не може да се счита за завършен по време на Sprint Review. Developers държат един друг сметка за поддържането на тази дисциплина. Няма външна полиция за качество.
Наблюдаване на самоуправлението в ежедневната практика
Когато Developers разберат същността на самоуправлението, ежедневните навици се променят. Можете да разберете дали даден екип се управлява сам, като наблюдавате как се справя с рутинните предизвикателства:
- Те използват Daily Scrum за съвместна работа и пренастройване на дневния си план, вместо да докладват статус пред Scrum Master.
- Те се мобилизират колективно срещу техническите блокажи, вместо да чакат ръководител да преразпределя спрените задачи.
- Те отхвърлят външен натиск за пускане на функционалност, която нарушава приетата от тях Definition of Done.
- Те проактивно разговарят с Product Owner веднага щом техническата реалност влезе в противоречие с бизнес очакванията.
- Те споделят знанията в екипа чрез работа по двойки и прегледи на кода, вместо да разчитат на незаменими единични експерти.
Дисциплината на автономията
Автономията без отговорност води единствено до безпорядък. Даването на пълна свобода на Developers работи само тогава, когато те действат като професионалисти, посветени на общата Sprint Goal. Това изисква честност относно реалните възможности, взаимно уважение между колегите и готовност да се говори открито, когато възникнат проблеми.
Самоуправлението не е привилегия, предоставена едва след като екипът докаже, че може да изпълнява нареждания. То е основният работен принцип в Scrum от първия ден. Когато организациите премахнат излишните административни слоеве и оставят Developers да управляват своя технически процес, хората най-близо до кода вземат по-бързи и по-добри решения от всеки отдалечен мениджър.