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