Рефакториране на провален Sprint в средата на седмицата
Научете как да спасите Sprint, който се разпада в средата на седмицата. Разберете как Scrum екипите предоговарят обхвата с Product Owner, запазвайки своя Sprint Goal непокътнат.
Всеки опитен екип познава усещането в сряда сутрин, когато планът се изпарява. Външно API се променя без предупреждение, миграция на база данни се проваля тихо или основното предположение зад най-важната функционалност се оказва погрешно. Дъската свети в червено, моралът пада, а първоначалната прогноза вече не важи. В този момент много екипи или изпадат в паника и работят по осемдесет часа, или се преструват, че всичко е наред чак до Sprint Review. И двата избора са грешни. Проваленият Sprint не е морален провал. Това е просто нова информация, дошла по-рано от очакваното.
Митът за замразения план
Някои екипи третират Sprint Backlog като договор, подписан с кръв по време на Sprint Planning. Те смятат, че промяната му по средата на итерацията нарушава правилата на Scrum. Ръководството за Scrum от 2020 г. казва точно обратното. Докато Sprint Goal е ясен ангажимент, който не бива да се застрашава, обхватът на спринта може да се уточнява и предоговаря между Developers и Product Owner с натрупването на нови знания.
Всеки Sprint е рамка за изследване, а не миниатюрна waterfall фаза. Когато техническите ви предположения рухнат в сряда, сляпото придържане към Backlog е проява на небрежност. Вие рефакторирате кода, когато откриете по-добра архитектура. По същия начин трябва да рефакторирате и своя Sprint, когато разберете, че планът ви не може да доведе до очаквания резултат.
Оценете първо своя Sprint Goal
Преди да местите задачи по дъската, погледнете своя Sprint Goal. Целта дава отговор на въпроса защо вършим тази работа. Ако целта ви е била да позволите на клиентите да плащат чрез PayPal, а избраната библиотека не поддържа вашия платежен портал, кодът се проваля, но целта все още може да бъде постижима чрез директна интеграция с API.
Задайте си един прост въпрос: Можем ли все още да постигнем своя Sprint Goal с оставащото време, ако променим подхода си? Ако отговорът е да, вие нямате провален Sprint. Имате просто остарели задачи. Developers имат пълна собственост върху Sprint Backlog и разполагат с правомощията да разглобят техническия план и да го изградят наново, за да защитят тази цел.
Как да извършите рестарт в средата на седмицата
Не чакайте следващия Daily Scrum, ако проблемът е критичен. Свикайте петнайсетминутна оперативна среща веднага щом Developers се съгласят, че текущата прогноза е невъзможна. Поканете Product Owner в стаята незабавно.
- Опишете точната техническа реалност без заобикалки. Обяснете какво се е счупило, защо се е счупило и какво не може да бъде направено.
- Определете минималната част от работата, необходима за постигане на Sprint Goal, като премахнете всички незадължителни подобрения и второстепенни задачи.
- Предоговорете премахването на обхват от спринта. Върнете незапочнатите елементи обратно в Product Backlog, за да не разсейват фокуса на екипа.
- Прогнозирайте отново оставащите дни със здравословна доза скептицизъм. Ако смятате, че едно заобиколно решение отнема един ден, планирайте два.
Кога отмяната е правилното решение
Понякога проблемът не е, че работата е по-трудна от очакваното. Понякога самата цел е загубила всякакъв смисъл. Представете си, че разработвате функционалност за експорт към партньорска платформа и във вторник този партньор обяви, че спира своята интеграционна крайна точка. Продължаването на работата по тази функционалност е чиста загуба на ресурс.
В рамката Scrum единствено Product Owner има правомощието да отмени даден Sprint. Това следва да се направи, ако целта, поставена в Sprint Goal, стане безсмислена. Отмяната на Sprint изглежда драматична стъпка, но всъщност е проява на дисциплина. Тя спира прахосването на средства и позволява на всички да се прегрупират, да проведат чисто ново планиране и да започнат начисто още на следващата сутрин.
Гъвкавостта означава управление на посоката
Ако шофирате кола и на пътя се появи препятствие, не затваряте очи и не държите волана прав само защото сте планирали този маршрут преди час. Завъртате волана или натискате спирачките. Разработката на софтуер изисква абсолютно същото поведение.
Възприемането на проваления Sprint като криза показва неразбиране на емпиризма. Цялата идея на кратките итерации е да ограничат риска от грешка до няколко дни, вместо до няколко месеца. Когато нещата се объркат в сряда, приемете това откритие, коригирайте обхвата заедно със своя Product Owner и завършете седмицата с нещо, което действително работи.