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