Скрам ръководство | 11. Статистика и метрики, които Скрам майсторът трябва да следи

Защо Scrum Master-ът се нуждае от статистики и метрики? Първо, за да провери дали методите му за работа върху предсказуемостта на резултатите и подобряване на ефективността на екипа са ефективни. Но също така, за да следи как техните действия влияят на Развойния екип. Тоест, как те оформят опита на служителите потребители (UX). Така в тази статия представяме статистики и метрики, които Scrum Master-ът трябва да следи.

Статистики и метрики, важни за Scrum Master-а – съдържание:

1. Измерване на резултатите от работата на Развойния екип
2. Наблюдение на опита на служителите потребители Разработчици
3. Резюме

Измерване на резултатите от работата на Развойния екип

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

Burndown Chart

Burndown chart показва на Scrum Master-а и Развойния екип колко работа е свършена и колко остава да се направи. X-осът показва времето, оставащо за завършване на работата. Y-осът показва количеството работа, което остава да се свърши, планирано в Sprint Backlog или Product Backlog.

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

Този прост инструмент позволява на Scrum Master-а не само да види колко ефективно работи екипът. Той също така помага да се отговори на въпросите:

• Каква част от работата вече е завършена?
• Колко задачи остават за завършване?
• Колко време ще отнеме разработването на продукта?

При използването на Burndown Chart, Scrum Master-ът трябва да има предвид, че това не е единственият инструмент за статистическа оценка на напредъка на екипа. Той работи най-добре за проекти, където обхватът на работата е фиксиран и известен. Не работи добре при създаването на много иновативни решения с нов клиент. Тогава количеството работа, което трябва да се свърши в целия проект – тоест съдържанието на Product Backlog – може да се промени значително по време на проекта, което затруднява използването на Burndown Chart.

Burnup chart

Burnup Chart е обратното на Burndown chart, обсъден по-горе. И тук Y-осът показва количеството работа, което остава да се свърши. X-осът, от друга страна, показва времето за завършване, изразено или в брой Sprints, или в дати.

Въпреки това, Scrum Master-ът използва Burnup Chart за малко по-различна цел. Това е, защото той не само помага за измерване на напредъка на продукта и напредъка на екипа. Тази метрика също оценява как обхватът на работата в проект променя с времето. Следователно, тя работи добре за проекти с променлив обхват.

Burnup Chart е също инструмент за планиране, който става все по-ефективен с времето. Той предоставя отговори на въпроса колко работа Развойният екип се очаква да свърши в следващия Sprint.

Cumulative Flow Diagram

Третият тип диаграма, който е много полезен в работата на Scrum Master-а с Развойния екип, е Cumulative Flow Diagram. Тя анализира колко стабилно е темпото и производителността на Развойния екип. Подредбата на осите й е същата като на Burnup Chart, така че често се нарича по-сложната версия на него.

Въпреки това, Cumulative Flow Diagram не служи само за определяне на броя на задачите, завършени в даден период от време. Тя също така взема предвид броя на задачите, които чакат в опашката за изпълнение. Благодарение на това, тя позволява диагностицирането на т.нар. “възли” – моменти от процеса, които забавят създаването на продукт.

Тази много диагностична функция я прави една от най-полезните метрики в ръцете на Scrum Master-а. Това е, защото позволява да се реорганизира работата по начин, който да разпредели силата на Развойния екип по различен начин и да се избегне времето на бездействие.

Наблюдение на опита на служителите потребители Разработчици

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

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

Вторият важен фактор на опита на служителите на разработчиците, за който Scrum Master-ът, работещ с статистически инструменти, трябва да се грижи, е начинът на управление на времето им. Това е, защото Scrum Master-ът трябва да има достатъчно време, за да се грижи за Развойния екип. Поради тази причина, в случай на голям проект, си струва да се обмисли включването на допълнителен човек в Scrum екипа. Той/тя ще действа като проектен мениджър и ще се грижи за метриките. Благодарение на това, ще облекчи Scrum Master-а – и до известна степен Product Owner-а – от задачите, които го разсейват от работата с Развойния екип.

Статистики и метрики – резюме

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

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