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