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