- Czym jest Refinement Backlogu Produktu? — 27/11/2024
- Czym jest burndown chart? — 22/11/2024
- Czym jest Retrospektywa Sprintu? — 18/11/2024
Ken Schwaber i Jeff Sutherland opublikowali specjalny post z okazji nowej wersji Scrum Guide, do którego trudno jest dotrzeć ze strony głównej. Gorąco polecam obejrzenie video, gdzie autorzy frameworku Scrum opowiadają także o rosnącej popularności Scrum i zaleceniach organizacji badających przemysł IT.
Oprócz nowego Scrum Guide możemy też ściągnąć listę sześciu zmian, którą publikuję poniżej z moim komentarzem.
- Dodano sekcję Artifact Transparency, czyli Przejrzystość Artefaktów.
Autorzy po prostu chcą podkreślić, że jeżeli Artefakty nie są przejrzyste, to podejmowane decyzje mogą być błędne.
Sekcja Artifact Transparency chyba była pisana w pośpiechu i bez przeglądu. Wskazują na to proste błędy jak i trudność w zrozumieniu przekazu. „Decisions to to optimize value” – powtórzone “to”?Co to znaczy “transparency is complete”? “Transparency doesn’t occur overnight, but is a path.” Jaka ścieżka. Czy ścieżka jest przeciwieństwem nagłej zmiany? Znacznie lepiej by brzmiało napisanie, że to jest proces.
“A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.” Powinien też nauczyć się tropić zwierzynę i leżeć na torach nasłuchując nadjeżdżającego pociągu.
“There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency.” Zatem jakie to są praktyki?
Dlaczego Definition of Done jest rozdziałem Artifact Transparency? - Sprint Planning jest teraz pojedynczym wydarzeniem.
A nie był? Oczywiście, że był. Prawdziwą zmianą jest brak sztywnego podziału na Co i Jak po 50%. Czy ktoś trzymał się kurczowo tego podziału czasu? Nie mam pojęcia. Osobiście nie widziałem. Ken i Jeff podkreślają też formalne wprowadzenie Celu Sprintu (Sprint Goal), ale przecież był on częścią Scrum Guide Oct 2011, gdzie jest napisane „After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.” - The Product Backlog is refined rather than groomed. Taka tam zmiana słówka ku uciesze Anglików. Podobno groomed źle im się kojarzyło. Dzisiaj słyszałem że grooming oznacza w UK na przykład sytuację, gdzie starszy mężczyzna zmienia wygląd, zeby wyglądać na młodszego i podrywać młode dziewczyny. Czyli nie przystrzygamy i nie układamy, ale ulepszamy, udoskonalamy.
Ważniejszą zmianą jest wprowadzenie pojęcia Ready, czyli stało się to o czym krążyły plotki. Od pewnego czasu Definition of Ready była praktyką Zespołów scrumowych. Teraz każde PBI może oficjalnie posiadać 2 stany – Ready i Done. - Wszystkie Wydarzenia (Events) oprócz Sprintu mogą się zakończyć przed czasem. Już wcześniej jasno było określone, że to że wydarzenie jest time-box’em, oznacza, że kończy się po upływie wyznaczonego maksymalnego okresu czasu. Dla mnie oczywiste jest, ze może skończyć się wcześniej, jeżeli cel został osiągnięty. Jeżeli zaplanowaliśmy Sprint wcześniej, to kończymy spotkanie zamiast siedzieć i czekać aż time-box na Sprint Planning Meeting upłynie, prawda? Czyli znowu żadna nowość.
- Żeby bardziej podkreślić, że Codzienny Scrum (Daily Scrum) jest wydarzeniem planowania a nie spotkaniem statusowym, zmieniono słynne 3 pytania uwzględniając w nich Cel Sprintu i zmieniając czas języka angielskiego.
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Na moje oko, nowe pytania są za długie do zapamiętania i wykorzystywania w praktyce. Rolą Scrum Mastera jest upewnić się, że Developerzy mówi ą tylko o pracy związanej ze Sprintem, a nie o tym, czym ogólnie byli zajęci wciągu dnia.
- Na końcu Sprint Review zastanawiamy się jak zoptymalizować wartość produktu i robimy dwa dodatkowe przeglądy
„Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.”
Czyli zastanawiamy się czy i jak się zmieniła następna wartościowa „rzecz” jaką dostarczymy. Sprawdzamy też rzeczy stricte związane z projektem, czyli budżet, harmonogram, rynek i potencjał. Przedtem jednak nadal zastanawiamy się co zrobić w kolejnym Sprincie tak jak w Scrum Guide Oct 2011, czyli
„The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;”
Czy nie powinniśmy najpierw sprawdzić co ma największą wartość, a potem zastanowić się co zrobić w kolejnym Sprincie? Czyżby znowu brak konsekwencji i zmiany w pośpiechu?
A teraz jeszcze dwie nieoficjalne zmiany.
- Wydarzenia scrumowe nie są już proporcjonalnie krótsze dla Sprintów krótszych niż jeden miesiąc, ale są „zazwyczaj krótsze”. I jak tu Scrum Master ma pilnować time-box’a?
- Mała rzecz, a jakże upierdliwa. Nie można klikać w numery stron w spisie treści i szybko przenosić się do kolejnych tematów.
Podsumowując można powiedzieć, że różnice pomiędzy Scrum Guide Oct 2011 a Scrum Guide July 2013 jest taka sama jak pomiędzy iPhone 4S i iPhone 5. Nowy jest nieco dłuższy. ;)
Nie wiadomo dlaczego Scrum Guide’y zostały przeniesione na stronę www.scrumguides.org. Dlaczego nie można trzymać oficjalnych przewodników na oficjalnej stronie Scrum? Nie wiem. Zgaduję, że może chodzić o duży ruch i obciążenie łącza przy ściąganiu Scrum Guide albo o pozostanie Scrum Guide jako neutralnego z punktu widzenia Scrum Alliance. Sam adres strony jest niezbyt dobrze dobrany, ponieważ odruchowo można wpisać scrumguide.com i możemy dojść do fałszywego wniosku, że ta organizacja jest wspierana przez Scrum.org.
Polskiej wersji Scrum Guide July 2013 na razie nie ma. Najszybsi są Bośniacy.