3 гъвкави отчета за преработване и как да ги използвате

Пъргавите практики за непосветените и недостатъчно информирани понякога могат да се появят като ad hoc методологии за разработване на софтуер и управление на проекти. Истината е далеч по-различна.

Един от 12-те принципа на гъвкавия софтуер гласи: „Най-добрите архитектури, изисквания и дизайн възникват от самоорганизиращи се екипи“, но повечето организации, които прилагат гъвкави практики, включително scrum и Kanban, налагат някои значителни строги процеси и ритуали. Например много организации прилагат гъвкави практики за планиране, включително оценка на сюжетни точки, архитектурни стандарти и дисциплини за управление на изданията, за да подобрят въздействието върху бизнеса, качеството и надеждността на изданията на приложения.

Повечето отбори избират да използват гъвкав инструмент като Jira Software или Azure DevOps, за да управляват изоставанията, спринтовете и сътрудничеството между гъвкави екипи. Основната цел на тези инструменти е да управляват централно изискванията, състоянието на спринта, работния процес и сътрудничеството между гъвкави членове на екипа и множество пъргави екипи. Колкото по-строго обаче организациите използват тези инструменти, толкова повече тези инструменти могат да помогнат на лидерите и екипите да идентифицират проблеми, да докладват на заинтересованите страни за състоянието и да подобрят тяхното изпълнение.

Един от най-често отчитаните доклади е докладът за изгарянето. Тъй като гъвкавите практики позволяват на собствениците на продукти да определят приоритетите на изоставането въз основа на обратна връзка с клиентите, традиционните доклади като диаграмите на Гант не успяват да уловят плавния характер на пъргавото изпълнение. Основното за изгарящата диаграма е, че тя отчита завършената работа, новата работа, добавена към обхвата, и други промени в обхвата. Графиката за изчезване може да даде бърза картина на това как отборите вървят към целите си.

Четене на основна спринтова диаграма

Диаграмите на Burndown обикновено имат време по оста x и оценки по оста y. Много отбори правят оценка в сюжетни точки, но много гъвкави инструменти могат да очертаят преразглежданията по броя на историите или оценки в часове. За тази статия ще предположа, че се използват сюжетни точки.

Отчетът за изгаряне на спринта описва броя на сюжетни точки, които са в обхвата за интервала от време. Докато екипът завършва истории, диаграмата показва как те „изгарят“ списъка с истории и други видове работа (проблеми в Jira, типове работни елементи в Azure DevOps), докато работата приключи или спринтът приключи. Когато екипите завършат работата, ангажирана със спринта, начертаната линия пресича оста x, което показва, че всичко е направено.

Спринтовното изгаряне е най-лесно за концептуализиране. През първия ден на спринта екипът се ангажира с някои истории и общия брой точки от историята. Ако прегледате изгорената диаграма на този ден, трябва да видите една точка на оста y, представляваща броя точки, които екипът се е ангажирал в нулевия ден на спринта.

Тъй като историите са отбелязани като завършени, изгарянето на спринта показва оставащия брой точки за попълване.

Как се използва спринтово изгаряне на практика? Здравото изгаряне показва линейна и в идеалния случай експоненциална крива до нула. Ако кривата има равен наклон в ранната част на спринт, това може да показва блокове или много незавършена работа и че спринтът може да бъде изложен на риск. Плоското или бавно наклонено изгаряне може да бъде много проблематично, ако се извършват много тестове върху истории с пълен код и ако тестовата работа не може да започне до последните няколко дни от спринта.  

Бързо спускащото се спринтово изгаряне обикновено е нещо добро, но може да означава, че отборът не се ангажира или е избрал да поеме по-малки истории в спринта.

Epic burndowns проследяват напредъка спрямо бизнес и технически фактори

Sprint burndowns са изключително полезни за проследяване на краткосрочното изпълнение и помагат на екипите успешно да изпълняват ангажиментите за спринт. За да се проследи по-добре напредъкът спрямо дългосрочните цели, епичните и освобождаващи прегради осигуряват необходимата видимост.

Епичните преработки работят най-добре, когато екипите определят няколко дългосрочни усилия, като например прилагане на основните възможности на крайния потребител, технически дългови стратегии, подобрения в производителността или еволюция на процесите. За да се възползвате от епичните прегради, изоставането трябва да има:

  • Между пет и 15 епоса, които ще продължат поне няколко месеца и ще отнемат шест или повече спринта.
  • Характеристики, истории и мъничета от истории, които се навиват под епоса и представляват план на високо ниво за изпълнение на епоса.
  • Оценки на високо ниво, в идеалния случай в сюжетни точки за всяка история или сюжет, който се навива под епосите.

След като те са налице, епичното изчезване начертава промените в този план. Неговата ос x представлява спринтове, а оста y представлява общата оценка на историите и историите, присвоени на епоса. В епичната изгаряща диаграма на Jira Software виждате стълбовидна диаграма с един цвят, представящ истории, завършени в спринта, и втори, който показва добавените точки от историята. Историческите точки се увеличават, когато към епоса се добавят нови истории или мъничета от истории или когато оценките се променят.

Има няколко начина да използвате епичната диаграма за изгаряне:

  • Тя илюстрира скоростта на завършване на функции и истории срещу плана. Когато плановете са точни и скоростта на екипа е последователна, тя може да осигури индикатор, когато работата на епоса е завършена.
  • Повечето гъвкави планове не са завършени и екипите добавят, променят и премахват истории въз основа на обратна връзка с крайния потребител, откриване на технически сложности и за справяне с техническия дълг, въведен по време на пътуването. След това епичното преразглеждане показва колко далеч епичът се основава на това колко нараства изоставането в сравнение със завършения спринт по спринт.
  • Epic burndowns също помагат за сравняване на усилията в множество спринтове и преценяват колко работа по планиране и доставка се извършва в една епопея спрямо други.

Прекъсванията на изданията информират екипите дали изданията ще достигнат датата и обхвата

Напредналите екипи, които напълно автоматизират своите тръбопроводи за доставка с непрекъсната интеграция, непрекъснато тестване и непрекъсната доставка, може да не се нуждаят от прекъсвания. Екипите, които често се разгръщат, трябва да проследяват какви функции и истории са свързани с изданието, но изчерпването на изданието не е много полезно, тъй като често проследява напредъка по спринт.

За други екипи, които следват практиките за управление на изданията и стандартизират изданията с много отпечатъци, преразглеждането на изданието може да е най-важният инструмент на собственика на продукта и екипа.

Презареждането на изданието е подобно на епичното изгаряне, с изключение на това, че вместо проследяване на функции, истории и мъничета от истории, присвоени на епос, освобождаването показва какво е присвоено на издание. Тогава оста и лентите са идентични с епичните преграждания.

По този начин екипите, използващи презареждания за издание, могат да проследяват обхвата и времевата линия за издание. Екипите, които са на път, ще видят изгорен наклон до оста x с наклон, съобразен със скоростта на отбора. Изданията, които може да се отклоняват от пистата, имат или по-малък наклон, или изобразяват повече добавени сюжетни точки (когато към изданието е добавен повече обхват) от това, което се завършва.

Jira Software ви помага с тези прогнози. Ако приемем, че екипът работи по проекта за поне три спринта, Jira Software ще изчисли средна скорост на екипа и ще предвиди крайния спринт за издание въз основа на тази скорост.

Спринт, епични и освобождаващи прекъсвания дават на отборите някои лесни за използване инструменти за привеждане в съответствие с целите. Когато екипите имат споделено разбиране за обхвата, договарят се за приоритети, планират няколко спринта напред и маркират по подходящ начин историите в изоставането си, преразглежданията разказват дали планирането и изпълнението са съобразени с целите. Когато не са, те са инструмент, управляван от данни, който може да подхрани дискусията относно това какви корекции могат да са необходими.