Scrum Guide 2020

Scrum ma już 25 lat. Właśnie opublikowano kolejną wersję jego przewodnika. Scrum Guide 2020 po polsku umieściłem w zasobach mojego bloga.

Nowy Scrum Guide odchodzi od nakazów i zakazów. Usunięto między innymi pytania z Daily Scrum, sformułowania odnoszące się do elementów Product Backlogu zostały złagodzone, mniej nakazowe stały się też sformułowania dotyczące włączania wniosków ze Sprint Retrospective do Sprint Backlogu, skrócono część mówiącą o przerywaniu Sprintu.

Ponadto scalono Scrum Team, który skupia się na jednym celu, a w jego ramach trzy różne zakresy odpowiedzialności: Product Owner, Scrum Mastera oraz Developerów. W tym miejscu warto zacytować przewodnik „Używamy słowa “deweloperzy” w Scrumie nie po to, by kogokolwiek wykluczać, lecz by upraszczać. Jeśli Scrum daje ci wartość, uznaj się za członka tej grupy.” Tak więc developerzy to także analitycy, testerzy i inne osoby dążące do celu produktu.

Cel produktu to nowa koncepcja, która została wprowadzona, aby zapewnić, że Scrum Team skupia się na większym, wartościowym zamierzeniu. Każdy Sprint powinien przybliżać produkt do osiągnięcia Celu Produktu.

Dodanie celu produktu pomogło w uporządkowaniu znanych już artefaktów takich jak Cel Sprintu i Definicję Ukończenia. Każdy z trzech artefaktów ma obecnie przypisane “zobowiązanie”. Dla Product Backlogu to Cel Produktu, dla Sprint Backlogu to Cel Sprintu, a dla Incrementu to Definicja Ukończenia.

Kolejną zmianą jest, dla mnie chyba najważniejszą, jest dodanie na Sprint Planningu dodatkowego pytania: „po co”. W ten oto sposób nie tylko analizujemy „co” robić i „jak” robić, ale także zastanawiamy się „po co” to robić i czy te zadania przybliżają nas do Celu Sprintu.

Jeśli interesujesz się podejściem zwinnym to zapraszam do lektury Scrum Guide 2020 po polsku oraz zapoznania się z moim przewodnikiem: Podstawy Scrum.

Podobne wpisy
Subiektywne porównanie narzędzi do modelowania procesów biznesowych

W wielu firmach, z którymi mam przyjemność współpracować jest stosowana nierozłączna para: JIRA i Confluence.  JIRA odpowiada za zarządzania zadaniami więcej

Architekt w podejściu zwinnym

W ostatnim wpisie opisałem co myślę o roli analityka w podejściu zwinnym. Drugą rolą, o której chciałbym wspomnieć jest rola więcej

Analityk w podejściu zwinnym

Rola analityka i znaczenie analizy w wielu organizacjach umacnia się a w innych zanika. Dość często tam, gdzie pojawia się więcej

Kanban w Enterprise Architect 13 część 2

W poprzednim tygodniu pisałem o kanban w Enterprise Architect (Kanban w Enterprise Architect 13 część 1). Dziś postaram się przedstawić więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry