Практически ресурси за Scrum

Не. Scrum Guide определя отговорностите на Scrum Master, но не определя роля Project Manager. Обхватът на работата на Project Manager зависи от организацията и проекта. Scrum Master подкрепя ефективността и самоуправлението, вместо да управлява екипа чрез разпределяне на задачи.

Учебен пример: В проект някой може да следи бюджет, договори и външни срокове. Това не му дава автоматично отговорностите на Scrum Master. Ако започне да разпределя задачите на Developers, самоуправлението им се нарушава.

Извод: Сравнявайте реалните отговорности, не само длъжностите. Нито една от двете роли не е универсално по-добра.

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

Учебен пример: По време на Daily Scrum хората докладват поотделно на мениджъра. Scrum Master помага да се изясни целта на събитието. Developers насочват разговора към напредъка по Sprint Goal и необходимата адаптация на плана.

Извод: Питайте дали намесата помага на екипа да взема решения, или го прави по-зависим.

Product Owner носи отговорност за ефективното управление на Product Backlog, включително подреждането му. Може да делегира работата, но остава отговорен. Scrum не предписва универсална формула за приоритет. Стойността, рискът, зависимостите и наученото дават контекст на решението.

Учебен пример: Малка промяна може да остане след по-голяма, ако последната отстранява риск за основната употреба на продукта. Developers дават информация за размера и техническите зависимости. Product Owner използва тази информация, за да обоснове подредбата.

Извод: Усилието е важна информация, но не е заместител на продуктовото решение.

Започнете от Product Goal и проверете как всяко искане допринася за нея. Изяснете какво знаете и какво още е предположение. Разговорът за последствията от отлагане често е по-полезен от механично изчисляване на оценка.

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

Извод: Обяснете реда с конкретния контекст и го преразгледайте при нови данни.

В Sprint Planning Scrum екипът изяснява защо Sprint е ценен, какво може да бъде направено и как. Daily Scrum е за Developers: проверка на напредъка към Sprint Goal и адаптация на Sprint Backlog. Sprint Review е съвместна проверка на резултата със заинтересованите страни и разговор за следващите адаптации. Sprint Retrospective търси начини за повишаване на качеството и ефективността.

Учебен пример: Планираме да направим резервацията по-надеждна. В Daily Scrum Developers установяват зависимост и променят плана. На Review проверяват резултата и новата обратна връзка. На Retrospective избират подобрение в начина на тестване. Review не е само демонстрация, а Retrospective не е оценяване на хората.

Извод: Всяко събитие има различен предмет на проверка. Еднакъв статус отчет във всички срещи пропуска смисъла им.

Daily Scrum не изисква задължително три фиксирани въпроса. Product Backlog не е неизменен план. Scrum Master не е ръководител на Developers. Sprint Review не е задължителна врата за пускане на продукта. Scrum описва рамка, а не пълна процедура за всяка ситуация.

Учебен пример: Екипът има използваем Increment, който отговаря на Definition of Done. Не е необходимо да чака Sprint Review, за да го предостави. Решението за предоставяне зависи и от продуктовия контекст, но Review не е изисквано разрешение в Scrum.

Извод: Проверявайте дали дадено правило идва от Scrum Guide, или е местна практика на организацията.

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

Учебен пример: Екипът вижда, че приключените задачи не дават използваем Increment, защото тестването остава за по-късно. Прави това видимо, обсъжда причините и променя сътрудничеството при тестване. След това проверява дали промяната помага.

Извод: Свържете наблюдението с конкретна промяна и следваща проверка, а не с обещание за подобрение.