Скрам ръководство | 40. Поддържане на продуктовия беклог

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

Поддържане на продуктовия беклог – съдържание:

1. Въведение
2. Цел на поддържането на продуктовия беклог
3. Грешки в поддържането на продуктовия беклог
4. Поддържане на беклога срещу метрики, използвани в Scrum
5. Резюме

Въведение

Продуктовият беклог е един от артефактите на Scrum. Той съдържа приоритизирана списък с работа, необходима за създаването на продукт. С други думи, това е списък с потребителски истории, необходими за постигане на целта на продукта. Можете да намерите подробно описание на това какво представляват потребителските истории в тази статия. А тук са подробностите за характеристиките и как да поддържате продуктовия беклог.

Поддържането на продуктовия беклог е известно и с следните имена:

• Приоритизиране на беклога,
• Уточняване на беклога,
• Мащабиране на беклога.

Цел на поддържането на продуктовия беклог

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

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

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

Грешки в поддържането на продуктовия беклог

Една от най-честите проблеми, свързани с поддържането на продуктовия беклог, е позволяването му да се разширява неконтролируемо. Това е така, защото при работа по продукта, различни допълнителни функционалности и задачи, предложени както от заинтересованите страни, така и от членовете на Scrum екипа, спонтанно се появяват. Следователно, ограничаването на растежа на обхвата на продуктовия беклог (scope creep) е една от най-важните задачи, извършвани от продуктовия собственик. Най-честите грешки, които правят продуктовите собственици, се отнасят до:

1. Отклонение от целта на продукта – добавянето на твърде много идеи в продуктовия беклог извън основната цел на продукта не е добра практика, тъй като значително намалява четимостта му. По-добре е да се събират идеи за допълнителна функционалност в отделен документ.
2. Дублиране на съдържание – въвеждането на повторени или много подобни идеи от различни заинтересовани страни в беклога – преди да добави нов запис в беклога, продуктовият собственик трябва да се увери, че новият запис не дублира нито един от съществуващите.
3. Липса на по-широка перспектива – трябва да подредите записите в продуктовия беклог според тяхната стойност относно целта на продукта. Все пак, имайте предвид, че приоритизацията трябва да вземе предвид следващите няколко спринта, така че задачите, изпълнявани в даден спринт, да бъдат безпроблемно свързани както с предходния спринт, така и с непосредствено следващия.

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

Поддържане на беклога срещу метрики, използвани в Scrum

Продуктовият беклог съдържа описание на оставащата работа през целия проект. Въпреки това, само актуализиран и редовно поддържан беклог може точно да оцени съотношението на завършената работа спрямо общата. За да се изобрази количеството завършена работа, трябва да се приложи графиката на изгаряне (Burndown Chart), за която писахме в тази статия.

Друга популярна метрика за описание на работата на Scrum екипа е скоростта (Velocity). Можете да я измерите, като сравните броя на записите в продуктовия беклог, преобразувани в инкремент по време на един спринт. Описахме скоростта по-подробно в тази статия.

Резюме

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

Ако харесвате нашето съдържание, присъединете се към нашата общност на заети пчелички в Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.