Има причина, поради която прогнозите за времето ви казват, че има 70% вероятност да вали, вместо да ви обещават, че ще вали точно в 15:00 ч. Те използват наличната информация, отчитат несигурността и се актуализират с постъпването на нови данни. Все пак можете да планирате следобеда си според тях, стига да не бъркате прогнозата с гаранция.
Планирането на спринта работи по подобен принцип. Един Scrum екип разполага с продуктов беклог, оценка на наличния си капацитет и цел, която иска да постигне. Но някои детайли по работата стават ясни едва с напредването на спринта. Планирането с всеки час напред оставя малко място за тези открития, докато започването без обща посока затруднява вземането на решение какво заслужава внимание.
Целта е да се постигне съгласие относно ценен резултат и да се прогнозира колко работа екипът може да изпълни, за да го постигне. Оттам нататък екипът може да адаптира плана си, докато научава повече, без да губи от поглед целта на спринта.
Това ръководство обхваща подготовката на списъка със задачи, дневен ред за планиране с времеви разпределение, практически изчисления на капацитета и пример, който показва как да коригирате плана по време на спринта.
TL;DR Планирането на спринта събира екипа по Скрам, за да се съгласи по една цел за спринта, да избере елементи от списъка с задачи и да изготви първоначален план за изпълнение:
- Подгответе се, като прецизирате предстоящата работа и проверите наличността, незавършените задачи, зависимостите и дефиницията за „завършено“.
- Основете прогнозата на действителния капацитет и миналите резултати, като отчетете отпуските, срещите, задачите по поддръжка и несигурността, без да отчитате ангажиментите два пъти
- Приключете планирането с общ списък със задачи за спринта, след което коригирайте плана за изпълнение, докато екипът натрупва повече информация, като същевременно запазвате целта на спринта
- Използвайте двучасовата примерна програма и примера за капацитет като отправни точки, като ги адаптирате към нуждите на екипа
Какво е планиране на спринт?
Планирането на спринта е събитие по метода Scrum, което се провежда в началото на всеки спринт, за да се постигне съгласие относно това, което екипът иска да постигне, и как ще подходи към работата. То събира целия Scrum екип, включително продуктовия собственик, Scrum майстора и разработчиците. Други специалисти, като инженери по сигурността или ръководители, работещи с клиенти, също могат да се присъединят, когато техният принос би помогнал на екипа да вземе информирани решения.
Според „Ръководството за Scrum“ всяка сесия за планиране трябва да доведе до три резултата: цел на спринта, която обяснява стойността на работата; подбор на елементи от продуктовия беклог, които подкрепят тази цел; и първоначален план за тяхното изпълнение. Заедно те формират спринт беклога, който разработчиците продължават да актуализират с напредването на спринта.
В „Ръководството за Scrum“ е посочен максимален срок от осем часа за едномесечен спринт, а по-кратките спринтове обикновено отнемат по-малко време. При добре прецизиран списък със задачи, дневният ред по-долу се побира в два часа.
Ако някои от тези термини ви са непознати, в нашия речник ще намерите основните понятия от Agile и Scrum.
Трите въпроса, на които отговаря планирането на спринта
Всяка сесия за планиране на спринт се върти около три въпроса:
- Защо този спринт е ценен?
- Какво можем да постигнем?
- И как ще свършим работата?
„Ръководството за Scrum“ организира планирането около тези въпроси, като започва с ценността, която искате да предоставите. Щом всички са наясно с това, е по-лесно да се реши кои елементи от списъка с задачи заслужават внимание и колко работа е разумно да поеме екипът ви.
| Въпрос | Кой ръководи | Резултат | Пример за 2-седмичен спринт |
|---|---|---|---|
| Защо този спринт е ценен? | Продуктовият собственик прави предложение; целият екип го одобрява | Цел на спринта | Новите клиенти могат да платят с карта при финализиране на поръчката, без да се свързват с отдела по продажбите |
| Какво може да се направи през този спринт? | Разработчиците избират заедно с продуктовия собственик | Избрани елементи от списъка с задачи | Формуляр за плащане с карта, интеграция с доставчик на платежни услуги, имейл с разписка, обработка на грешки |
| Как ще бъде изпълнена избраната работа? | Разработчици | Първоначален план на задачите | Задачите се разделят на по-малки дейности, често с продължителност един ден или по-малко, като първоначалните отговорности се договарят |
Защо спринтът е важен
Целта на спринта дава на екипа насока, към която да се стреми, и помага на заинтересованите страни да разберат какво да очакват. Съгласувайте тази цел със своя Скрам екип, преди да приключи сесията по планиране.
Опишете резултат, който хората могат да разпознаят, като например „Потребителите на пробната версия могат да канят колеги“, вместо цел за обем на работа като „Да завършим 34 стори точки“. Ако възникне неочакван проблем, целта помага на екипа да реши коя работа да коригира, като същевременно запази желания резултат.
Прочетете още: Как да формулирате ефективни цели за спринт (+примери)
Какво може да завърши екипът през този спринт
След като се съгласите по целта, е време да определите какво е реалистично екипът да изпълни.
Разработчиците избират елементи от списъка с задачи в сътрудничество с продуктовия собственик, като вземат предвид наличния капацитет, постигнатите резултати в миналото и дефиницията за завършеност. Това е и подходящият момент да се преразгледат всички съществуващи ангажименти, които биха могли да повлияят на времето, с което разполага екипът за работата по спринта.
Много екипи използват точки за истории, за да сравняват относителния обем на работата и сложността на елементите в списъка с задачи. Скалата на Фибоначи може да помогне за структурирането на тези дискусии, особено когато необходимият обем на работа не е ясен.
Ако темата за „стори точки“ е нова за вас или искате да видите как се използват на практика, ето подробно описание на процеса на оценяване.
Как екипът ще изпълни работата
След като елементите от списъка с задачи са избрани, разработчиците обмислят как ще ги превърнат в готово продуктово инкремент, което отговаря на „Дефиницията за завършеност“. Наръчникът за Scrum препоръчва по-големите елементи да се разделят на по-малки части работа, често с продължителност един ден или по-малко.
Това не означава, че трябва да планирате всеки час от спринта. Първите няколко дни може да се наложи по-подробен план, докато по-късните задачи могат да останат отворени за корекции, когато се появят нови подробности. Ако третирате ранните оценки като твърди ангажименти, това може да окаже натиск върху екипа да спази първоначалните цифри, дори ако обхватът се промени по средата на проекта.
Както обяснява Дейв Уест, главен изпълнителен директор на Scrum.org:
Прогнозата, използвана за отстояване на дата, провокира точно онова поведение, което подкопава доверието – като завишаване на оценките, прикриване на рисковете или тихо предефиниране на понятието „завършено“, за да се постигне определена цифра.
Прогнозата, използвана за отстояване на дата, провокира точно онова поведение, което подкопава доверието – като завишаване на оценките, прикриване на рисковете или тихо предефиниране на понятието „завършено“, за да се постигне определена цифра.
Каква е разликата между планирането на спринта и усъвършенстването на списъка със задачи?
Уточняването на списъка с задачи дава на екипа ви по-ясно разбиране за предстоящата работа, преди да дойде време да се реши какво да бъде включено в следващия спринт. Планирането на спринта се основава на тази подготовка, за да се постигне съгласие по целта, да се подберат елементи от списъка с задачи и да се изготви първоначален план за изпълнение.
Двете дейности служат за различни цели в рамките на Scrum:
| Размер | Уточняване на списъка с задачи | Планиране на спринта |
|---|---|---|
| Цел | Изяснете, разделите и оценете предстоящите задачи от списъка с нерешени задачи | Определете целта на спринта, изберете задачите и планирайте изпълнението |
| Времева рамка | Провежда се през целия спринт | В началото на всеки спринт |
| Статус на Scrum | Непрекъсната дейност | Официално събитие по Scrum с времева рамка |
| Кой участва | Продуктов собственик и съответните разработчици | Целият Скрам екип |
| Резултат | Елементи от списъка с нерешени задачи с по-ясни подробности, оценки и обхват | Спринт беклогът: целта на спринта, избраните задачи и планът за изпълнение |
Поддържайте достатъчно задачи от предстоящия списък с нерешени задачи (backlog) достатъчно детайлизирани, така че екипът да има ясни възможности за избор по време на планирането на спринта. Колко подготовка е необходима зависи от това колко бързо се променят приоритетите и колко несигурност остава. Задачите, които са по-надолу в списъка с нерешени задачи, могат да останат по-малко детайлизирани, докато не се приближат към момента на избор.
Прочетете още: За повече насоки вижте нашите статии за поддържане на списъка с задачи и за организиране и приоритизиране на списъка с задачи за продукта.
Как да се подготвите за планирането на спринта
Няколко дни по-рано проверете дали списъкът с задачи е в добро състояние и дали всички разполагат с информацията, необходима за вземане на решения. По този начин ще можете да посветите сесията на обсъждане на това какво да доставите и как да подходите към него, без да се налага да решавате всяко изискване от нулата.
Ето списък с задачи, които да изпълните преди следващия си спринт:
- Изгответе цел за спринта: Помолете продуктовия собственик да предложи резултат, който подкрепя по-широката продуктова цел, като даде на екипа конкретни точки за обсъждане
- Прегледайте списъка с задачи за продукта: Уверете се, че задачите с най-висок приоритет са подредени, разбрани и оценени, където е необходимо
- Проверете наличността на екипа: Помолете разработчиците да споделят планираните си отпуски, графиците за дежурства и други ангажименти, които биха могли да повлияят на капацитета им
- Прегледайте незавършената работа: Прегледайте недовършените задачи от предишния спринт и всички подобрения, идентифицирани по време на ретроспективата
- Идентифицирайте зависимостите: Отбележете задачите, които изискват участието или одобрението на друг екип, и уточнете кой ще координира това
- Прегледайте „Дефиницията за завършеност“: Уверете се, че всички разбират стандартите за качество, на които трябва да отговаря всеки завършен елемент от списъка с задачи
Ако насрочвате ретроспективата на спринта и сесията за планиране в кратък интервал, оставете достатъчно време за пълноценно обсъждане и на двете. Изводите от ретроспективата трябва да бъдат отчетени в плана за следващия спринт, затова се уверете, че нито една от срещите не се провежда набързо.
Дневен ред за планиране на спринта: пример с времева разбивка за 2-седмичен спринт
За двуседмичен спринт започнете с двучасова сесия за планиране, особено когато списъкът с задачи вече е прецизиран. Предвидете допълнително време, ако работата включва сложни зависимости или няколко решения, които изискват обсъждане.
Можете да адаптирате този пример за дневен ред според нуждите на вашия екип.
| Време | Точка от дневния ред | Кой ръководи | Очакван резултат |
|---|---|---|---|
| 0:00–0:10 | Прегледайте резултатите от предишния спринт, незавършената работа и действията от ретроспективата | Скрам майсторът координира процеса | Общо разбиране за това, на какво трябва да се обърне внимание |
| 0:10–0:30 | Обсъдете предложената от продуктовия собственик цел на спринта и се споразумейте за желания резултат | Целият Скрам екип | Проект за цел на спринта, която всички разбират |
| 0:30–0:45 | Потвърдете наличността на екипа и прегледайте евентуалните ограничения на капацитета | Разработчици | Реалистична картина на наличния капацитет |
| 0:45–1:15 | Изберете задачи от списъка с нерешени задачи, които подкрепят целта | Разработчиците, заедно с продуктовия собственик | Подбор от задачи, които екипът смята, че може да изпълни |
| 1:15–1:45 | Разделете избраните задачи и обсъдете подхода за изпълнение | Разработчици | Първоначален план за завършване на работата |
| 1:45–2:00 | Прегледайте зависимостите, проверете увереността си и финализирайте целта на спринта | Целият Скрам екип | Съгласувана цел на спринта и списък със задачи за спринта, готов за използване от екипа |
Преди да приключите, можете да използвате бърза проверка на увереността, като например „Петте пръста“, при която всеки оценява увереността си в плана от нула до пет пръста. Ако някой даде ниска оценка, попитайте какво е причината за притеснението. Това може да разкрие нерешена зависимост, прекалено амбициозна прогноза или изискване, което се нуждае от допълнително обсъждане.
Целта е да се изявят евентуалните проблеми, докато все още има време да се коригира планът.
Как да проведете планиране на спринт в 6 стъпки
След като подготвите списъка с задачи и потвърдите кои лица ще присъстват, започнете сесията за планиране. Целта тук е да помогнете на екипа да превърне своите приоритети и наличния капацитет в план, за който е убеден, че може да изпълни.
Стъпка 1: Прегледайте предишната работа и се споразумейте за целта на спринта
Започнете с кратък преглед на това, което е завършено, какво остава незавършено и дали някакви действия от ретроспективата трябва да повлияят на следващия спринт. Фокусирайте се върху всичко, което би могло да промени приоритетите или подхода на екипа, вместо да преразглеждате целия спринт преглед.
След това нека продуктовият собственик представи предложената цел на спринта и обясни как тя подкрепя по-широката цел на продукта. Дайте възможност на разработчиците да поставят под въпрос обхвата ѝ, да посочат зависимости и да предложат корекции.
Например, ако целта е клиентите да могат да завършат поръчката си, без да се свързват с отдела по продажбите, договорете се как изглежда една успешна поръчка. Включва ли тя потвърждение на плащането и обработка на грешки? Необходимо ли е автоматичното изпращане на касови бележки за първото пускане на продукта?
Тези дискусии ви помагат да определите резултат, към който екипът да се стреми. Формулировката може да се променя с избора на задачите от списъка с нерешени задачи, но всички трябва да се съгласят с крайната цел, преди планирането да приключи.
Стъпка 2: Изчислете наличния капацитет на екипа
Преди да изберете задачите, определете колко време вашите разработчици реално могат да отделят за спринта.
Започнете с броя на работните дни и очакваната наличност на всеки човек. След това отчетете планираните отпуски, Scrum събитията, задълженията за поддръжка и други известни ангажименти. Ако един разработчик прекарва половината от седмицата си в разрешаване на проблеми в производствената среда, тези часове вече са ангажирани и не са на разположение за планираната работа по спринта.
Едно просто изчисление е: Наличен капацитет = Общо работни часове − Известни ангажименти
Например, един разработчик с 80 работни часа за две седмици може да има 8 часа отпуск, 10 часа срещи и 12 часа дежурства. Това оставя 50 часа, преди да се отчетат евентуални допълнителни непредвидени обстоятелства.
Сравнете тази цифра с предишните резултати на екипа. Велосити показва колко работа е изпълнил екипът в предишните спринтове, докато капацитетът отразява времето, с което разполагате за този спринт.
Съвет от професионалист: Ако използвате часове за планиране на капацитета, не ги смесвайте със „стори точки“. Двете мерки отразяват различни неща и няма универсално съотношение между тях.
Стъпка 3: Преоценете незавършената работа от предишния спринт
Незавършените задачи от списъка заслужават да бъдат прегледани отново, преди да ги добавите към новия спринт. Задача, която е била важна преди две седмици, може да е променила приоритета си, или екипът може да е научил нещо, което влияе върху обема на оставащата работа.
Прегледайте всяка точка заедно с продуктовия собственик и обмислете:
- Релевантност: Подкрепя ли това все още предложената цел на спринта или друг важен приоритет на продукта?
- Оставащ обем работа: Колко работа остава, след като част от задачата вече е изпълнена?
- Зависимости: Има ли нещо, което пречи на екипа да отбележи напредък?
- Приоритет: Трябва ли този елемент да бъде с по-висок приоритет от новоуточнените елементи в списъка с задачи?
За задачите, които все още са част от спринта, използвайте оставащия обем работа, за да прецените колко капацитет ще е необходим. Полузавършена задача може да изисква по-малко работа от първоначалната оценка, но все пак се счита за незавършена, докато не отговаря на дефиницията за „завършено“.
Стъпка 4: Изберете елементи от списъка с задачи, които подкрепят целта
След като са наясно с капацитета си и неизпълнената работа, разработчиците могат да изберат елементите от продуктовия беклог, които смятат, че ще успеят да завършат.
Започнете с задачи, които пряко подпомагат целта на спринта. Обсъдете критериите за приемане, техническите зависимости и всякакви неясни моменти, които биха могли да повлияят на изпълнението. Ако дадена задача е прекалено обширна или неясна, обмислете да я разделите на по-малки части, които могат да донесат полза в рамките на спринта.
Възможно е да имате време и за поддръжка или други приоритети, свързани с продукта, но проверете дали поемането на тази работа би могло да изложи на риск основната цел.
Колко капацитет трябва да запазите?
Планирането само на 80% от наличния капацитет може да бъде разумна отправна точка за екипи, които редовно се занимават с неочаквана работа по поддръжка, но Scrum не предписва фиксиран процент.
Ако екипът ви е изпитвал чести прекъсвания, можете да заделите 10–20% от коригирания му капацитет и да сравните тази резерва с това, което е било необходимо по време на предишните спринтове. Екип със стабилна работа и малко прекъсвания може да се нуждае от по-малко. Екип, поддържащ действаща услуга с чести инциденти, може да се нуждае от повече.
Избягвайте да отчитате едно и също задължение два пъти. Ако планираните часове за поддръжка вече са били приспаднати в стъпка 2, допълнителният резерв трябва да покрие несигурността, надхвърляща известния обем на работа. Използвайте получения капацитет като ориентир за обсъждане, а не като цел, която трябва да бъде постигната.
Не забравяйте: Спринт със свободен капацитет не означава непременно, че е недопланиран. Ако сте избрали достатъчно работа за постигане на целта на спринта, запълването на оставащите часове с несвързани задачи може да доведе до конфликт на приоритети. Понякога по-малка прогноза е по-реалистична, особено когато избраната работа е свързана със значителна несигурност.
Стъпка 5: Разделете работата на части и проверете зависимостите
След като сте избрали елементите от списъка с задачи, разработчиците могат да обмислят как ще ги изпълнят. Това може да включва разделяне на по-големите елементи на задачи за разработка, тестване, интеграция и преглед.
Обърнете специално внимание на реда на работата. Ако интерфейсът за плащане зависи от интеграция с доставчик на платежни услуги, екипът трябва да разбере кога тази интеграция трябва да бъде готова. Ако друг екип трябва да одобри промяна в сигурността, изяснете как и кога ще бъде взето това решение.
Планирайте непосредствената работа по-подробно, като оставите по-късните задачи отворени за по-нататъшно обсъждане. Наръчникът за Scrum предлага разбиването на избраните елементи на по-малки работни елементи, обикновено с продължителност до един ден или по-малко, но разработчиците сами решават как да организират и разпределят работата.
Проверете дали планът отчита „Дефиницията за завършеност“, включително необходимите тестове и интеграционна работа. Ако някаква зависимост може да попречи на доставката, преразгледайте избраните елементи или коригирайте подхода за доставка, преди да финализирате плана.
Стъпка 6: Финализирайте и споделете списъка със задачи за спринта
Запишете целта на спринта, избраните елементи от продуктовия беклог и първоначалния план за доставка на място, до което екипът има достъп и което може да актуализира. Взети заедно, те трябва да изяснят какво се стреми да постигне екипът и коя работа изисква внимание в следващия етап.
Преди да приключите срещата, потвърдете, че целта е одобрена, и дайте възможност на всеки да изрази евентуални останали опасения относно прогнозите. Ако някаква важна зависимост или проблем с капацитета остане нерешен, обсъдете какво трябва да се промени, преди екипът да започне работа.
По време на спринта ежедневният скрам дава възможност на разработчиците да проверят напредъка към целта и да коригират списъка със задачи за спринта. Диаграма за изразходване (burndown или burnup ) може да помогне за визуализиране на промените в напредъка, докато основните задачи предоставят подробности. Ако нова информация засегне избрания обхват, разработчиците могат да обсъдят корекции с продуктовия собственик, без да излагат на риск целта на спринта.
Пример за планиране на спринт: екип от 6 разработчици
Нека видим как тези решения се прилагат на практика.
Представете си, че планирате двуседмичен спринт за B2B продукт за фактуриране. Екипът ви се състои от шестима разработчици, а предложената цел на спринта е: „Новите клиенти могат да плащат с карта при финализиране на поръчката, без да се свързват с отдела по продажбите.“
Преди да изберете елементи от списъка с нерешени задачи, трябва да знаете с колко време разполага екипът. За целите на този пример приемете, че всеки разработчик разполага с шест потенциални часа за целенасочена работа по проекта на ден, преди да се приспаднат планираните Скрам събития и други ангажименти.
Ето как се изчислява капацитетът за период от 10 работни дни:
| Изчисляване на капацитета | Часове |
|---|---|
| Базов капацитет: 6 разработчици × 10 дни × 6 часа | 360 |
| Планиран отпуск: 1 разработчик отсъства за 2 дни | −12 |
| Дежурство: 1 разработчик с 50% наличност | −30 |
| Събития по Scrum: 8 часа на разработчик | −48 |
| Наличен капацитет | 270 |
| Заделете 20% за непредвидена работа | −54 |
| Наличен капацитет за планираната работа | 216 |
Сега разполагате с 216 часа за планираната работа, след като сте заделили примерна резерва от 20%. На практика бихте избрали този резерв въз основа на това колко непланирана работа е прекъснала предишните спринтове.
Изберете задачите, които подпомагат целта на спринта
След като капацитетът е установен, разработчиците преглеждат заедно с продуктовия собственик елементите от списъка с нерешени задачи, свързани с checkout.
Ето един илюстративен пример, базиран на първоначалните им оценки за усилието на ниво задача:
| Елемент от списъка с нерешени задачи | Очаквано усилие |
|---|---|
| Създайте формуляра за плащане с карта | 48 часа |
| Интегрирайте доставчика на платежни услуги | 88 часа |
| Справяне с неуспешни плащания и грешки при валидирането | 50 часа |
| Добавете потвърждение на плащането и доставка на разписката | 24 часа |
| Общо планирана работа | 210 часа |
Тези оценки оставят 6 часа в рамките на предвиденото време за работа, плюс 54-часовия резерв за непредвидена работа. Екипът разполага и с подобрение на таблото за отчети в списъка с задачи за продукта. Въпреки че то е ценно, то не допринася пряко за целта на спринта. Продуктовият собственик и разработчиците се съгласяват да го оставят за бъдещ спринт.
Коригирайте плана, когато нещо се промени
На шестия ден доставчикът на платежни услуги въвежда промяна в API-то, която нарушава част от интеграцията. Разработчиците проучват проблема и оценяват необходимата допълнителна работа.
Вместо да продължат с първоначалния ред на задачите, те обсъждат въздействието с продуктовия собственик. Ако поправката се побира в рамките на оставащия капацитет, те могат да ѝ дадат приоритет и да отложат опционалното оформление на разписките или друга задача с по-нисък приоритет. Потвърждението на плащането и друга съществена работа все пак трябва да отговарят на „Дефиницията за завършеност“.
Ако корекцията е по-голяма от очакваното, ще трябва да преоценят оставащия обхват и дали целта на спринта все още е постижима.
Екипът може да завърши със по-малко изпълнени задачи от първоначално прогнозираните. Но ако клиентите могат да завършат процеса на плащане както е предвидено и работата отговаря на „Дефиницията за завършеност“, целта на спринта е постигната.
Примери за цели на спринта за други екипи
Можете да приложите същия подход към планирането и за работа извън сферата на разработката на софтуер, въпреки че самият Scrum е специфична рамка с определени отговорности и събития.
Например, маркетинговият екип може да си постави цел като „Да публикуваме целевата страница за уебинара и да дадем възможност на посетителите да се регистрират без ръчна помощ“. Оперативният екип може да си постави за цел „Да гарантираме, че всеки служител от следващата група новопостъпили разполага с необходимото оборудване и достъп до системата още на първия си работен ден“.
И двете цели описват резултати, които могат да насочват решенията на екипа през целия спринт. Елементите от списъка с задачи и плановете за изпълнение ще се различават, но екипът все пак трябва да вземе предвид капацитета си и да се споразумее как изглежда успешното изпълнение.
Чести грешки при планирането на спринтове и как да ги поправите
Планирането на спринта може да срещне проблеми, когато екипите използват точки за истории, за да оценяват индивидуалното представяне, включват неясни елементи от списъка с задачи в срещата, разпределят работата твърде строго или пренебрегват изискванията за тестване и външните зависимости.
Няколко корекции могат да ви помогнат да откриете тези проблеми, преди те да повлияят на изпълнението.
| Грешка | Защо това създава проблеми | Как да го поправите |
| Използване на точки за историята за измерване на индивидуалното представяне | Сравняването на разработчиците по брой завършени точки може да насърчи преувеличаването на оценките или избягването на сложната работа. | Насочете точките за истории към прогнозиране на ниво екип. Прегледайте завършената работа от няколко спринта и обсъдете промените в оценките по време на уточняването. Оценявайте индивидуалните резултати чрез качеството на кода, сътрудничеството и постигнатите резултати. |
| Включване на неясни елементи от списъка с задачи в планирането | Липсващите критерии за приемане или неотговорените технически въпроси превръщат планирането в дискусия за това какво да се изгради, като оставят по-малко време за планиране на изпълнението. | Разрешете въпросите по време на прецизирането на списъка с задачи, за да могат разработчиците да направят разумна прогноза. Ако несигурността остане, обмислете по-малка и по-добре разбрана част от работата. Стремете се към достатъчна яснота, за да вземете решение, а не към перфектни спецификации. |
| Разпределяне на всяка задача към конкретен човек преди началото на работата | Фиксираните задачи затрудняват адаптирането, когато приоритетите се променят или един разработчик приключи по-рано, докато друг се нуждае от помощ. | Позволете на разработчиците да организират работата. Договорете се за непосредствените отговорности и участието на специалисти, след което дайте възможност на членовете на екипа да поемат, да работят в двойки или да преразпределят задачите по време на спринта. Поддържайте работата видима за целия екип. |
| Оставяне на външни зависимости нерешени | Липсващи данни за достъп до API, прегледи на сигурността или резултати от работата на друг екип могат да накарат екипа да чака за работа, върху която няма контрол. | Преди да финализирате списъка със задачи за спринта, определете необходимите ресурси, кой ще ги координира и кога се очаква да бъдат предоставени. Ако някаква критична зависимост остава неясна, обмислете алтернативна задача или по-малък обхват, който екипът може да изпълни самостоятелно. |
Ако едни и същи проблеми продължават да се появяват в няколко спринта, включете ги в ретроспективата на спринта и се споразумейте за промяна, която можете да тествате по време на следващия спринт. Тези шаблони за ретроспектива на спринта могат да ви помогнат да запишете наблюденията си и да определите последващите действия.
В края на спринта използвайте срещата за преглед на спринта, за да проверите завършеното инкремент заедно със заинтересованите страни и да обсъдите какво трябва да предприеме екипът след това.
Как да проведете планиране на спринт в ClickUp
Планирането на спринта отнема повече усилия, когато задачите, оценките за капацитета и решенията за планиране са разпръснати в различни инструменти. ClickUp обединява тази информация, така че екипът да може да преглежда работата заедно с капацитета и да преразгледа решенията за планиране, когато планът се промени.
Започнете с шаблона за планиране на спринт по метода Agile в ClickUp. Изгледите за списъка със задачи, състоянието на разработката и ресурсите ви помагат да прегледате предстоящата работа и да се подготвите за обсъждането на плана.
Ето как да вземете ключовите решения:
- Улеснете оценката на предстоящата работа: Съхранявайте изискванията, критериите за приемане, приоритетите и зависимостите в списък с нерешени задачи в ClickUp Tasks. Тези подробности помагат на разработчиците да обсъдят обхвата и да оценят усилията, преди да изберат задачите. Добавете избраните задачи към спринта, след като екипът се съгласи с плана
- Определете постоянен период за планиране: Настройте продължителността на спринта и датите на започване в ClickUp Sprints. Използвайте „Спринт точки“ или „Оценки на времето“, за да оцените усилието и да помогнете на екипа да прецени колко работа може да поеме
- Проверете дали работата е подходяща: Сравнете възложената работа с капацитета на всеки човек в изгледа „Работна натовареност“ на ClickUp. Прегледайте неравномерното разпределение на натоварването и обсъдете евентуални промени, преди да финализирате прогнозата.
- Дръжте дневния ред и решенията в тясна връзка с работата: Използвайте ClickUp Docs за дневния ред с времева разбивка, предложената цел на спринта и връзки към съответните задачи. Записвайте решенията относно обхвата и нерешените въпроси по време на сесията, за да може екипът да ги преразгледа с напредването на работата
- Записвайте дискусията по планирането: ClickUp AI Notetaker може да записва срещи в Zoom, Google Meet, Microsoft Teams или SyncUps и да запазва обобщение, ключови решения и задачи за изпълнение в документ. Прегледайте бележките, след което актуализирайте задачите на спринта с договорените последващи действия
- Използвайте данните за напредъка, за да насочвате дискусиите: Добавете карти „Sprint Burndown“ или „Burnup“ към таблото на ClickUp, за да прегледате завършената работа и оставащите задачи. Когато напредъкът се различава от плана, прегледайте съответните задачи за закъснения или промени в обхвата, които изискват внимание
Преди следващата сесия за планиране попитайте Brain²: „Какви нерешени зависимости възникнаха по време на последната ни сесия за планиране на спринт?“ Brain може да извлече контекста от записаните бележки от срещата. Сравнете тези подробности с текущите задачи, преди да ги използвате за изготвяне на следващата прогноза.
Цени на ClickUp
Най-подходящо за: Скрам екипи, които управляват множество спринтове, споделени зависимости и променящи се работни натоварвания, които изискват управление на беклога, планиране на капацитета и отчитане на напредъка в едно работно пространство. То е подходящо и за екипи, които координират работата по спринтовете с по-широки продуктови или бизнес проекти.
Пропуснете го, ако: Вашият екип се нуждае само от основна Scrum табло с малък списък със задачи и минимално отчитане. Гъвкавостта на ClickUp идва с възможността за настройка на параметрите на спринта, изгледите и полетата. Някои разширени функции за отчитане и автоматизация на спринтовете също изискват планове от по-висок ниво, което може да не е необходимо за прост работен процес.
Колко трябва да планирате преди началото на спринта?
Сесията за планиране на спринт трябва да даде на екипа достатъчна яснота, за да започне работа.
Дневният ред с времеви разпределение и примерът за капацитета по-горе служат като отправна точка. Адаптирайте ги към натоварването на екипа, след което сравнете прогнозата с извършената работа и прекъсванията, за да подобрите следващия спринт.
В ClickUp можете да свържете бележките от планирането със задачите на спринта и да актуализирате списъка със задачи за спринта при промени в работата. Екипът може да се позовава на договорения план, когато решава какво да коригира.
Често задавани въпроси относно планирането на спринта
Каква е разликата между планирането на спринт и планирането на версия?
Планирането на спринта се фокусира върху това, което екипът ви се стреми да постигне по време на един спринт и как ще изпълни тази работа. Планирането на версиите обхваща по-дългосрочен хоризонт, като например кои функции биха могли да бъдат налични в рамките на няколко спринта и кога потребителите биха могли да ги получат. Прогнозите за версиите могат да се променят, докато екипите натрупват повече информация, докато всяка цел на спринта насочва работата в рамките на текущия спринт.
Имате ли нужда от „Определение за готовност“ за планирането на спринта?
Не. Скрам не изисква формално „Определение за готовност“. Някои екипи използват такова, за да установят общи очаквания за елементите от списъка с задачи преди избора им, като например ясни изисквания, управляем обхват и известни зависимости. Поддържайте тези критерии достатъчно гъвкави, за да подпомагат дискусията, без да пречат на екипа да прецизира елементите, когато е необходимо.
Може ли спринтът да бъде отменен след планирането?
Да. Само продуктовият собственик може да отмени спринт, а отмяната е възможна, когато целта на спринта стане неактуална, например поради значителна промяна в бизнес приоритетите или пазарните условия. Сама по себе си една трудна задача или неточна оценка не е достатъчно основание за отмяна.
Каква е разликата между спринт и „аджайл“?
Аджайл е по-широк подход към управлението на работата, основан на ценностите и принципите на Аджайл манифеста. Спринтът е фиксиран период от един месец или по-малко в рамките на Скрам, през който екипът работи за постигане на целта на спринта и създава използваем инкремент. Можете да следвате Аджайл принципите, без да използвате спринтове. Канбан, например, поддържа непрекъснат поток на работа, без да изисква итерации с фиксирана продължителност.
Може ли един спринт да има няколко цели?
Скрам дефинира една цел на спринта като единствената цел на спринта. Можете да изберете елементи от списъка с задачи, които подкрепят други приоритети, стига те да не излагат тази цел на риск. Ако екипът ви редовно се нуждае от няколко несвързани цели, обсъдете дали работата подкрепя по-широк общ резултат или дали трябва да разрешите конфликтни приоритети преди планирането.
Трябва ли да оценявате бъговете в точки за история по време на планирането на спринта?
Точките за историята са по избор в Scrum, включително и за бъгове. Екипите, които оценяват бъгове, трябва да се споразумеят кога и защо да го правят. Известните дефекти могат да бъдат оценени по време на планирането, докато бъговете, открити по време на разработката, могат да попаднат в рамките на работата, която вече е необходима за изпълнение на „Дефиницията за завършеност“. Избягвайте да отчитате един и същ усилия два пъти.