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