Rekomendacje dla tej książki

„Mówi się, że poznanie Scruma zajmuje 10 minut, ale jego opanowanie może zająć całe życie. W tej książce Richard zapewnia wskazówki pozwalające lepiej opanować zasady Scruma. Łączy elementy praktyczne z abstrakcyjnymi, zapewniając podstawy pomagające Developerom Scruma dostarczać wartościowe produkty i rozwiązywać złożone problemy. Ta książka jest dla tych, którzy korzystają z Azure DevOps i chcą być w tym lepsi.”

Dave West, Product Owner i CEO w Scrum.org

„Czy nam się to podoba, czy nie, wiele zespołów potrzebuje narzędzi pomagających w implementacji Scruma. W tym miejscu pojawia się Richard. Jego wiedzę i pasję można dostrzec we wszystkim, czego się dotknie – zwłaszcza w tym podstawowym przewodniku pokazującym, jak Scrum Teamy mogą korzystać z Azure DevOps. Jeśli ktoś wie cokolwiek o Richardzie i korzysta ze Scruma w usługach Azure DevOps, to będzie pewien, że ta książka jest lekturą obowiązkową.”

Daniel Vacanti, współzałożyciel ActionableAgile

„W tej książce Richard Hundhausen wykonuje świetną pracę, wyjaśniając i łącząc dziedzinę Professional Scrum z profesjonalnym opracowywaniem oprogramowania przy użyciu Microsoft Azure DevOps. Richard przedstawia historię i aktualny stan obu tych dziedzin i wzbogaca tę książkę o osobiste wskazówki i ilustracje poprzez studia przypadków.”

Gunther Verheyen, niezależny Scrum Caretaker,
Professional Scrum Trainer

„Strukturę Scruma jest łatwo zrozumieć, ale trudno dobrze opanować. Richard ułatwia zrozumienie najtrudniejszych kwestii. Wyróżnia go przy tym jego zdolność do pomagania innym nie tylko w zrozumieniu Scruma, ale też w jego mistrzowskim opanowaniu.”

Chris Roan, Wells Fargo Agile Transformation Leader

„Jeśli ktoś wykorzystuje Scrum w swoim zespole, powinien przeczytać tę książkę. Richard koncentruje w niej swoje wieloletnie doświadczenie praktyczne w prowadzeniu Scrum Teamów, aby pomóc innym zespołom w przejściu do metodyki DevOps. Jest to najlepsze miejsce, aby zacząć pracę nad szybszym dostarczaniem większej wartości swoim klientom.”

Jeff Beehler, Senior Director, Product Operations, GitHub, Inc.

„Podczas pracy w zespole Azure DevOps poznałem pasję Richarda do Professional Scrum i jego pragnienie zbudowania tego narzędzia w taki sposób, aby stało się ulubionym narzędziem Scrum Teamów. Podstawą DevOps jest uzyskanie odpowiedniej mieszanki procesów, narzędzi i osób pracujących płynnie nad dostarczaniem wartości dla klienta. Łącząc to ze Scrumem, mamy zwycięzcę. Richard świetnie sobie radzi, biorąc teorię Scruma i przekształcając ją w określone zestawy działań do wykonania przez wszystkie osoby w zespole (Product Ownerów, Developerów, testerów, interesariuszy). Ta książka jest dla tych, którzy chcą być ekspertami od Scruma, wprowadzającymi go w codzienną praktykę przy użyciu usług Azure DevOps!”

Ravi Shanker, Principal Group Program Manager i były
Product Owner w Azure Test Plans

„Richardowi udało się połączyć trzy ważne pojęcia: Azure DevOps, Scrum i tworzenie kodu wysokiej jakości. Ta książka stanowi obowiązkową lekturę dla każdego zainteresowanego tworzeniem rozwiązań w środowiskach deweloperskich firmy Microsoft.”

Donis Marshall, Microsoft MVP, Professional Scrum
Developer, prezes Innovation in Software

„Richard był od początku w czołówce zwinnego programowania oraz Scruma i jako pierwszy zdobył tytuł MVP w dziedzinie ALM/DevOps. Ta książka pokazuje jego rozległą wiedzę i zrozumienie tematyki Professional Scrum i Azure DevOps. Jest konieczną pozycją dla zespołów chcących się coraz bardziej doskonalić.”

Philip Japikse, CTO Pintas & Mullins, Microsoft MVP,
Professional Scrum Trainer

„Scrum jest prosty – albo tak się wydaje, dopóki ktoś nie spróbuje wprowadzić go w życie. Wspaniałą rzeczą w książce Richarda jest to, że daje czytelnikom praktyczne rady implementacyjne, tłumaczące proste słowa z Przewodnika po Scrumie na cenne działania wykonywane w zespołach.”

Steve Porter, Scrum.org Professional Series Manager,
Professional Scrum Trainer

„Azure DevOps jest pakietem narzędzi, a Scrum stanowi ramy postępowania, wykorzystywane do dostarczania produktu w iteracyjny i przyrostowy sposób. Oba te elementy mają wiele wspólnego, ale są oddzielnymi bytami. Richard łączy je ze sobą w zaskakująco wspaniały i łatwy do przyswojenia sposób, który jasno wyjaśnia, jak i gdzie je stosować, żeby pomóc zespołom dostarczać lepsze i bardziej wartościowe oprogramowanie.”

Jesse Houwing, Lead Consultant w Xpirit, Professional Scrum
Trainer, Microsoft MVP

„Jeśli ktoś korzysta z systemu Azure DevOps, to koniecznie powinien przeczytać tę książkę. Dla 80% zespołów programistycznych wykorzystujących Scrum, właśnie ta książka będzie pomocna w stosowaniu zasad Professional Scrum w ramach Azure DevOps oraz poprawieniu szans zespołu na sukces.”

Martin Hinshelwod, naked Agility, Professional
Scrum Trainer, Azure DevOps MVP

„Scrum jest łatwy do zrozumienia, ale niezwykle trudny do poprawnego zaimplementowania. W swojej książce Richard oferuje swoje zaprawione w bojach doświadczenie oraz praktyki, dzięki którym opanowanie Scruma staje się osiągalne dzięki usługom Azure DevOps.”

Ognjen Bajic, Professional Scrum Trainer, Azure DevOps MVP

„Richard korzysta ze swojej wiedzy jako Professional Scrum Trainer i guru od spraw DevOps, pisząc fantastyczną książkę, która opisuje, jak i dlaczego robić pewne rzeczy, wykorzystując Scrum w Azure DevOps. Ta książka jest przejrzyście napisana i powinna być na półce każdego, kto wykorzystuje usługi Azure DevOps i Scrum.”

Simon Reindl, Professional Scrum Trainer

„Postępując zgodnie z zaleceniami Richarda, nawet początkujący użytkownicy uzyskają właściwie skonfigurowaną i produktywną implementację Professional Scrum w usługach Azure DevOps. Doświadczeni praktycy będą mogli skonfrontować swoje sposoby działania i doświadczenia z poradami dostępnymi w tej książce.”

Ana Roje Ivancic, Professional Scrum Trainer, Azure DevOps MVP

„Codziennie korzystam z usług Azure DevOps. Nie zdawałem sobie sprawy, ile jeszcze muszę się nauczyć, dopóki nie przeczytałem tej książki. Jest ona wypełniona fachowymi wskazówkami maksymalizującymi wartość zespołu!”

Cory Isakson, Microsoft Senior Consultant

„Jeśli ktoś miałby przeczytać tylko jedną książkę na temat Scruma, powinna to być właśnie ta książka. Uczy ona wszystkiego, co trzeba wiedzieć na temat Professional Scrum Development – w jasny i zwięzły sposób, bez owijania w bawełnę.”

Martin Kulov, Microsoft DevOps MVP, Microsoft Regional Director

Profesjonalne wytwarzanie oprogramowania
z zastosowaniem
Scruma i Azure DevOps

Richard Hundhausen

Przekład:
Jakub Niedźwiedź

APN Promise
Warszawa 2021

Profesjonalne wytwarzanie oprogramowania z zastosowaniem Scruma i Azure DevOps

Authorized translation from the English language edition, entitled: Professional Scrum Development with Azure DevOps, ISBN 978-0-13-678923-9, by Richard Hundhausen, published by Pearson Education, Inc, publishing as Microsoft Press, a Division of Microsoft Corporation.

Copyright © 2021 by Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

Polish language edition published by APN PROMISE S.A., Copyright © 2021

Autoryzowany przekład z wydania w języku angielskim, zatytułowanego: Professional Scrum Development with Azure DevOps, ISBN 978-0-13-678923-9, by Richard Hundhausen, opublikowanego przez Pearson Education, Inc, publikującego jako Microsoft Press, oddział Microsoft Corporation.

Wszystkie prawa zastrzeżone. Żadna część niniejszej książki nie może być powielana ani rozpowszechniana w jakiejkolwiek formie i w jakikolwiek sposób (elektroniczny, mechaniczny), włącznie z fotokopiowaniem, nagrywaniem na taśmy lub przy użyciu innych systemów bez pisemnej zgody wydawcy.

APN PROMISE SA, ul. Domaniewska 44a, 02-672 Warszawa
tel. +48 22 35 51 600, e-mail: wydawnictwo@promise.pl

Książka ta przedstawia poglądy i opinie autorów. Przykłady firm, produktów, osób i wydarzeń opisane w niniejszej książce są fikcyjne i nie odnoszą się do żadnych konkretnych firm, produktów, osób i wydarzeń, chyba że zostanie jednoznacznie stwierdzone, że jest inaczej. Ewentualne podobieństwo do jakiejkolwiek rzeczywistej firmy, organizacji, produktu, nazwy domeny, adresu poczty elektronicznej, logo, osoby, miejsca lub zdarzenia jest przypadkowe i niezamierzone.

Microsoft oraz znaki towarowe wymienione na stronie http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx są zastrzeżonymi znakami towarowymi grupy Microsoft. Wszystkie inne znaki towarowe mogą być własnością ich odnośnych właścicieli.

APN PROMISE SA dołożyła wszelkich starań, aby zapewnić najwyższą jakość tej publikacji. Jednakże nikomu nie udziela się rękojmi ani gwarancji.
APN PROMISE SA nie jest w żadnym wypadku odpowiedzialna za jakiekolwiek szkody będące następstwem korzystania z informacji zawartych w niniejszej publikacji, nawet jeśli APN PROMISE została powiadomiona o możliwości wystąpienia szkód.

ISBN: 978-83-7541-454-7 (druk), 978-83-7541-455-4 (ebook)

Przekład: Jakub Niedźwiedź
Korekta: Ewa Swędrowska
Skład i łamanie: MAWart Marek Włodarz

Dedykuję tę książkę członkom swojego Scrum Teamu:
Esmay, Isla, Berlin, Blaize, Sawyer i Kristen.

Richard Hundhausen

Spis treści

Spis treści

Uwagi do wydania polskiego

O autorze

Przedmowa

Wprowadzenie

CZĘŚĆ. Podstawy Scruma

Professional Scrum

Przewodnik po Scrumie

Filary Scruma

Scrum w działaniu

Role w Scrumie

Interesariusze

Wydarzenia Scruma

Artefakty Scruma

Definicja Ukończenia

Wartości Scruma

Professional Scrum

Professional Scrum Developer

Retrospektywa rozdziału

Azure DevOps

Krótka historia

Ciągłe dostarczanie wartości

Azure DevOps Services

Azure Boards

Azure Repos

Azure Pipelines

Azure Test Plans

Azure Artifacts

Azure DevOps Server

Migracja do usług Azure DevOps Services

Visual Studio

Subskrypcje Visual Studio

Poziomy dostępu do Azure DevOps

Poziom dostępu Stakeholder (interesariusz)

GitHub i przyszłość

Retrospektywa rozdziału

Azure Boards

Wybieranie procesu

Typy elementów roboczych

Proces Scrum

Typy elementów roboczych w procesie Scrum

Zapytania o elementy robocze

Zmiany w Przewodniku po Scrumie

Dostosowywanie procesu

Proces Professional Scrum

Inne dostosowania

Retrospektywa rozdziału

CZĘŚĆ. Professional Scrum w praktyce

Gra wstępna

Przygotowywanie środowiska programistycznego

Tworzenie organizacji w Azure DevOps

Zapewnianie dostępu do organizacji

Inne konfiguracje organizacji

Rozszerzenia Azure DevOps

Konfigurowanie rozwoju produktu

Tworzenie projektu

Dodawanie członków projektu

Inne konfiguracje projektu

Ustanowienie nadajników informacyjnych

Lista kontrolna gry wstępnej

Retrospektywa rozdziału

Product Backlog

Tworzenie Product Backlog

Tworzenie Product Backlogu w usłudze Azure Boards

Dodawanie elementów Product Backlogu

Importowanie elementów Product Backlogu

Usuwanie elementu z Product Backlogu

Skuteczne tworzenie Product Backlogu

Raportowanie błędu

Jak wygląda dobre zgłoszenie błędu?

Skąd się biorą błędy?

Błędy w Sprincie i poza Sprintem

Reaktywacje błędów

Udoskonalanie Product Backlogu

Określanie kryteriów akceptacyjnych

Ustalanie rozmiarów elementów Product Backlogu

Dzielenie elementów Product Backlogu

Definicja gotowości

Zmienianie kolejności elementów w Product Backlogu

Planowanie wydania

Mapowanie historii

SpecMap

Lista kontrolna Product Backlogu

Retrospektywa rozdziału

Sprint

Sprint Planning

Obsługa Sprintów w Azure Boards

Tworzenie Sprint Backlogu

Tworzenie prognozy

Określanie Celu Sprintu

Tworzenie planu

Działania podczas Sprintu

Daily Scrum

Rozkładanie zadań

Taskboard

Zamykanie Sprintu

Lista kontrolna Sprint Planningu

Retrospektywa rozdziału

Planowanie testów

Azure Test Plans

Organizowanie testów

Przypadki testowe

Badanie postępów

Programowanie sterowane testami akceptacyjnymi

Programowanie sterowane testami

Zautomatyzowane testowanie akceptacyjne

Akceptacja != testowanie akceptacyjne

Ponowne wykorzystywanie testów

Testy regresji

Lista kontrolna testów akceptacyjnych

Retrospektywa rozdziału

Skuteczna współpraca

Osoby i interakcje

Wspólna przestrzeń

Organizacja pomieszczenia zespołu

Efektywne spotkania

Aktywne słuchanie

Wydajna współpraca

Bycie w kształcie litery T

Ciągłe informacje zwrotne

Praktyki współpracy przy rozwijaniu oprogramowania

Wspólna własność kodu

Komentarze w kodzie

Wiązanie zatwierdzeń z elementami roboczymi

Praca w parach, grupach i tłumie

Rozgałęzianie

Retrospektywa rozdziału

CZĘŚĆ. Doskonalenie

Poprawianie przepływu

Wizualizowanie przepływu

Tablica Kanban

Zarządzanie przepływem

Limity pracy w toku

Zarządzanie pracą w toku

Inspekcja i adaptacja przepływu zadań

Miary przepływu

Obliczanie miar przepływu

Wydarzenia Scruma oparte na przepływie

Sprint

Sprint Planning oparty na przepływie

Daily Scrum oparty na przepływie

Sprint Review oparty na przepływie

Sprint Retrospective oparty na przepływie

Retrospektywa rozdziału

Ciągłe usprawnianie

Typowe wyzwania

Przeszkody

Szacowanie

Ocenianie postępów

Renegocjowanie zakresu

Nieukończona praca

Dodatkowe prace

Scrum, a umowy z ustaloną ceną

Typowe dysfunkcje

Nieukończona praca

Wiotki Scrum

Brak inspekcji, brak adaptacji

Wyzwania Developerów

Praca z wymagającym Product Ownerem

Praca z wymagającymi interesariuszami

Praca z wymagającym Scrum Masterem

Zmienianie Scruma

Stawanie się profesjonalnym Scrum Teamem

Zatrudnienie trenera

Budowanie zespołu wielofunkcyjnego

Samozarządzanie

Zwiększanie przejrzystości

Szkolenia Professional Scrum Developer

Ocena swoje wiedzy

Stawanie się wysokowydajnym Scrum Teamem

Retrospektywa rozdziału

Skalowany Professional Scrum

Platforma Nexus

Przepływ procesu Nexus

Nexus Integration Team

Wydarzenia Nexusa

Artefakty Nexusa

Zintegrowany Increment

Wsparcie dla platformy Nexus w usługach Azure DevOps

Konfigurowanie dodatkowych zespołów

Zarządzanie Product Backlogiem

Retrospektywa rozdziału

Uwagi do wydania polskiego

Książka ta została przetłumaczona z uwzględnieniem specyficznych reguł narzuconych tłumaczom. Jedną z nich był wymóg utrzymania oryginalnego brzmienia nazw własnych elementów Scruma, zgodnie z aktualnie obowiązującą wersją Przewodnika po Scrumie. Poniżej zamieszczamy zestawienie nazw własnych z ich polskimi odpowiednikami wykorzystywanymi we wcześniejszych wydawnictwach, w tym również we wcześniejszych wersjach Przewodnika.

Events

Wydarzenia

Sprint

Sprint

Sprint Planning

Planowanie Sprintu

Daily Scrum

Codzienny Scrum

Sprint Review

Przegląd Sprintu

Sprint Retrospective

Retrospektywa Sprintu

Roles

Role

Scrum Team

Zespół Scrumowy

Scrum Master

Scrum Master

Product Owner

Właściciel Produktu

Developers

Deweloperzy

Artifacts

Artefakty

Product Backlog

Backlog Produktu

Sprint Backlog

Backlog Sprintu

Increment

Przyrost

Aktualną wersję Przewodnika po Scrumie można znaleźć pod adresem:
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

O autorze

RICHARD HUNDHAUSEN jest prezesem Accentient – firmy, która pomaga organizacjom i zespołom zajmującym się tworzeniem oprogramowania w dostarczaniu lepszych produktów dzięki zrozumieniu i wykorzystaniu usług Azure DevOps oraz Scruma. Jest profesjonalnym trenerem Scruma (Professional Scrum Trainer) i współtwórcą platformy Nexus Scaled Scrum.

Jako programista, konsultant i szkoleniowiec z niemal 40-letnim doświadczeniem rozumie, że oprogramowanie jest tworzone i dostarczane przez ludzi, a nie przez procesy lub narzędzia. Można się z nim skontaktować pod adresem richard@accentient.com.

Przedmowa

Do roku 2001 branża programistyczna była w tarapatach – więcej projektów kończyło się niepowodzeniem niż sukcesem. Klienci zaczęli domagać się kar umownych i zlecać pracę za granicą. Niektórzy programiści zaczęli jednak odnosić coraz większe sukcesy stosując „lekkie” procesy w rozwijaniu oprogramowania. Niemal zawsze procesy te były oparte na dobrze określonym, iteracyjnym i przyrostowym działaniu.

W lutym 2001 programiści ci wydali manifest programowania zwinnego – Agile Manifesto. Manifest ten wzywał do zwinnego (agile) tworzenia oprogramowania w oparciu o cztery podstawowe wartości i dwanaście zasad. Dwie spośród tych zasad to: 1) zadowalać klientów wczesnym i ciągłym dostarczaniem działającego oprogramowania oraz 2) możliwie często dostarczać działające oprogramowanie (w okresie od kilku tygodni do kilku miesięcy).

Do roku 2009 używany był głównie proces Scrum Agile. Zapewniał proste ramy postępowania dla iteracyjnego, przyrostowego tworzenia oprogramowania. Uwzględniał też wartości i zasady Agile Manifesto. Dwóch autorów Scruma, Jeff Sutherland i ja, byliśmy też wśród autorów Agile Manifesto.

Spodziewałem się pewnych trudności, jakie napotkają organizacje (a nawet zespoły) wybierające Scrum. Wierzyłem jednak, że programiści rozkwitną w środowisku Scruma. Przyduszeni ograniczeniami kaskadowej metodologii wytwarzania oprogramowania, programiści odżyją, stosując zwinne praktyki, współpracę i narzędzia, na które nie było czasu w projektach opracowywanych wcześniej. Ku mojemu zaskoczeniu dotyczyło to może 20 procent wszystkich twórców oprogramowania.

W roku 2009 Martin Fowler określił większość zwinnego tworzenia oprogramowania jako „zwiotczałe”:

Słyszałem ostatnio o sporym bałaganie w całkiem dużej liczbie projektów. Odbywa się to często następująco:

Chcą wykorzystać proces Agile i wybierają Scrum.

Przyjmują praktyki Scruma, a może nawet jego zasady.

Po pewnym czasie postęp działań znacznie spowalnia, ponieważ w bazie kodu jest bałagan.

Nie przywiązywali wystarczającej uwagi do wewnętrznej jakości swojego oprogramowania. Popełniając ten błąd, można wkrótce odkryć, że produktywność jest ściągana w dół, ponieważ dużo trudniej jest dodawać nowe funkcje. Ze względu na paraliżujący dług techniczny zasady Scruma ledwo trzymają się na nogach (a jeśli ktoś naprawdę stosował Scrum, to wie, że to bardzo źle).”
http://martinfowler.com/bliki/FlaccidScrum.html

Opis „zwiotczałego” Scruma dokonany przez Martina zgadzał się z naszym doświadczeniem. Większość programistów była wykwalifikowana, ale nie dość wykwalifikowana w trzech wymiarach wymaganych do szybkiego budowania pełnych przyrostów użytecznej funkcjonalności. Wymiarami tymi są:

Ludzie Umiejętność pracy w małym, wielofunkcyjnym, samozarządzającym się zespole.

Praktyki Wiedza i umiejętność zastosowania nowoczesnych praktyk inżynieryjnych wymaganych przez krótki cykl rozwoju produktu.

Narzędzia Narzędzia, które integrują i automatyzują te praktyki, tak aby kolejne przyrosty mogły być szybko integrowane bez nagromadzania się artefaktów, które trzeba obsługiwać ręcznie.

Zawiesiliśmy naszą działalność, podczas gdy pracowaliśmy przez cały rok 2009, tworząc to, co stało się znane jako program Professional Scrum Developer. Zaproponowaliśmy warsztaty w trzydniowym formacie. Na wejściu byli programiści, których wiedza i zdolności dawały „zwiotczałe” przyrosty. Wyjście stanowiły zespoły programistów, które opracowywały solidne przyrosty oprogramowania wymagane przez manifest Agile oraz nowoczesne, konkurencyjne organizacje.

Richard był z nami od początku. Jego książka Profesjonalne wytwarzanie oprogramowania z zastosowaniem Scruma i usług Azure DevOps stanowi dalszy ciąg jego udziału w tym ruchu, rozpoczętym przez nas w roku 2009.

Czytając książkę Richarda, można poznać trzy wymiary potrzebne do zwinnego opracowywania oprogramowania: ludzi, praktyki i narzędzia. Jak podczas tego kursu, Richard przeplata je ze sobą w coś, co łatwo przyswoić. Warto przeczytać książkę Richarda, jeśli ktoś jest członkiem Scrum Teamu. Wymienić wymagane praktyki. Zidentyfikować, które praktyki stanowią największe wyzwania dla zespołu. Uszeregować je według największego wpływu. Następnie kolejno je skorygować.

Wiele osób wydaje pieniądze na konferencje dotyczące Agile. Lepiej je oszczędzić, kupując tę książkę, omawiając ją z innymi i chodząc na spotkania oraz inne nieformalne „konferencje” dla zaawansowanych.

Richard i ja czekamy na wzrost waszych umiejętności. Nasza branża i nasze społeczności tego potrzebują. Oprogramowanie jest największym skalowalnym zasobem potrzebnym naszemu coraz bardziej złożonemu społeczeństwu. Skuteczna i wydajna praca zespołowa grup Agile jest podstawą rozwiązywania problemów, których rozwiązania również oczekuje nasze społeczeństwo.

Bierzmy się za Scrum!

Ken Schwaber
Współtwórca Scruma

Wprowadzenie

Scrum stanowi ramy postępowania do opracowywania i utrzymywania złożonych produktów, takich jak oprogramowanie. Scrum to tylko zestaw zasad zdefiniowanych w Przewodniku po Scrumie (https://scrumguides.org) i opisuje role, wydarzenia, artefakty oraz reguły wiążące je ze sobą. Gdy są poprawnie używane, te ramy postępowania umożliwiają zespołowi rozwiązywanie złożonych problemów, jednocześnie wydajnie i twórczo dostarczając produkty o najwyższej możliwej wartości. Scrum jest metodą Agile (zwinną). Właściwie jest najpopularniejszą metodą Agile będącą obecnie w użyciu.

Scrum stosuje iteracyjne i przyrostowe podejście do optymalizowania przewidywalności i kontrolowania ryzyka. Wynika to z empirycznego charakteru sterowania procesami w Scrumie. Poprzez właściwe użycie inspekcji, adaptacji i przejrzystości Scrum Team może próbować nowych sposobów wykonania jakiegoś zadania (eksperymenty) i mierzyć przydatność po krótkiej iteracji. Członkowie zespołu mogą następnie kolektywnie podjąć decyzję o przyjęciu, rozszerzeniu lub porzuceniu danej praktyki. Obejmuje to narzędzia wykorzystywane przez zespół oraz sposób ich użycia.

Połączenie Scruma z narzędziami dostępnymi w usługach Microsoft Azure DevOps stanowi silny związek. Celem tej książki jest ustanowienie podwalin do zrozumienia Scruma i sposobu obsługi Scruma w Azure DevOps. Zilustruję też, które praktyki zapewniają większą wartość przy realizacji bez użycia narzędzi. Ponadto wskażę narzędzia, które błędnie są reklamowane jako zwinne i skontrastuję je z bardziej preferowanymi praktykami.

W wytwarzaniu oprogramowania wszystko może się zmienić w mgnieniu oka. Wiedzą o tym zdrowe zespoły. Wiedzą też, że ciągłe sprawdzanie i adaptowanie sposobu wykonywania zadań jest sposobem na życie. Wydajne Scrum Teamy posuwają się nawet o krok dalej. Wiedzą, że w każdej przeszkodzie lub dysfunkcji jest okazja do nauki i doskonalenia. Przeczytanie tej książki jest świetnym pierwszym krokiem.

Kto powinien przeczytać tę książkę

Ta książka przyda się każdemu członkowi zespołu programistycznego, który wykorzystuje lub rozważa wykorzystanie Scruma. Skupiam się głównie na obowiązkach i zadaniach Developera (co w terminologii Scruma obejmuje projektantów, architektów, programistów, testerów, autorów technicznych, itd.). Product Ownerzy i Scrum Masterzy również będą czerpać wartość z tej książki, gdyż będą wykorzystywać wiele tych samych narzędzi Azure DevOps do planowania i zarządzania swoją pracą oraz do oceny postępów. Interesariusze, w tym klienci, użytkownicy, sponsorzy i menedżerowie również mogą uzyskać wartość z tej książki, zwłaszcza ucząc się, co powinni i czego nie powinni robić zgodnie z regułami Scruma oraz które narzędzia w usługach Azure DevOps wspierają te reguły.

Ta książka głównie skupia się na wykorzystaniu Scruma przy tworzeniu produktów programistycznych, gdyż jest to docelowa dziedzina Azure DevOps. Większość tej książki może jednak znaleźć zastosowanie również poza środowiskami programistycznymi i projektami informatycznymi. Ponieważ Scrum stanowi lekką platformę do opracowywania adaptacyjnych rozwiązań dla wszelkiego rodzaju złożonych problemów, wskazówki zawarte w tej książce mogą być stosowane przy opracowywaniu wszelkiego rodzaju produktów, takich jak usługi, produkty fizyczne lub coś bardziej abstrakcyjnego.

Ta książka może nie być odpowiednia, jeśli…

Ta książka jest przeznaczona dla zespołów wykorzystujących razem Scrum i usługi Azure DevOps przy opracowywaniu złożonych produktów, takich jak oprogramowanie. Nie będzie aż tak wartościowa dla zespołów niewykorzystujących Scruma albo zespołów opracowujących mniej skomplikowane produkty przy użyciu Scruma. Nie zapewni żadnej wartości zespołom wykorzystującym formalne, kaskadowe albo sekwencyjne projekty rozwoju oprogramowania, chyba że będzie sposobem na przekonanie takich zespołów do Scruma. Podobnie, jeśli zespół wykorzystuje Scrum, ale nie korzysta jeszcze z Azure DevOps, to duża część tej książki nie będzie zbyt ciekawa poza zdefiniowaniem i podkreśleniem charakteru Professional Scrum oraz wskazaniem, co takie zespoły mogą potencjalnie zyskać. Dotyczy to również zespołów wykorzystujących starsze wersje Team Foundation Server, które nie zawierają najnowszych, wartościowych narzędzi zespołowych do planowania i zarządzania pracą oraz umożliwiających współpracę w zespole.

Jeśli ktoś szuka „najlepszych praktyk”, to nie jest to właściwa książka ani właściwy autor. Staram się nie używać tego terminu, ponieważ oznacza on przyjęcie kilku błędnych założeń: (1) że dana praktyka jest naprawdę „najlepsza” dla wszystkich zespołów pracujących nad wszystkimi produktami we wszystkich organizacjach oraz (2) że zespół może przestać poszukiwać nowych rozwiązań i eksperymentować, gdy już odnajdzie taką najlepszą praktykę. Wolę zamiast tego określenie „sprawdzona praktyka”. Niezależnie od nazwy, ta książka jest pełna wielu praktyk, które osoby i zespoły mogą wziąć pod uwagę w swoim dążeniu do doskonałości.

Organizacja tej książki

Ta książka jest podzielona na trzy części, z których każda koncentruje się na innym aspekcie związku Professional Scrum z Azure DevOps. Część I „Podstawy Scruma” zapewnia podwaliny wiedzy na temat struktury Scruma, Professional Scrum, Azure DevOps, a w szczególności usługi Azure Boards. Część II „Professional Scrum w praktyce” składa się z kilku rozdziałów opisujących szczegółowo praktyczne zastosowania przez Professional Scrum Team poszczególnych funkcji Azure DevOps do tworzenia i zarządzania Product Backlogiem, Sprintu Planningu, tworzenia Sprint Backlogu i efektywnej współpracy podczas Sprintu. Część III „Doskonalenie” zawiera rozdział definiujący i usprawniający działanie Scrum Teamu, identyfikując typowe wyzwania i dysfunkcje, które należy usuwać oraz wykorzystując techniki ciągłego doskonalenia metod Scruma. Jest tam też rozdział dotyczący poprawy skalowalności poprzez Scaled Professional Scrum przy wykorzystaniu platformy Nexus Scaled Scrum. Czytając kolejno wszystkie części, można będzie zobaczyć, jak w efektywny sposób korzystać jednocześnie z usług Azure DevOps i Scruma i jak Scrum Team może przekształcić się w Professional Scrum Team, a później w wysokowydajny Professional Scrum Team.

W każdym rozdziale proponuję i polecam wiele praktyk i wzorców działania. Wykorzystuję terminy, takie jak Professional Scrum Team i wysokowydajny Scrum Team, aby odróżniać je od typowych Scrum Teamów, które praktykują Scrum mechanicznie bez zwracania uwagi na inspekcję, adaptację i doskonalenie. Czasami ktoś może odrzucać moje wskazówki jako „myślenie magiczne” i zakładać, że nie żyję w realnym świecie. Można by sądzić, że proponowane przeze mnie pomysły nie zadziałają w danym zespole, przy danej grupie ludzi lub w danej organizacji. Choć prawdą jest, że nie znam specyfiki danej organizacji, to jestem przekonany, że można dążyć do doskonałości, niezależnie od liczby napotykanych przeszkód. Byłem tego świadkiem, tak samo jak wielu moich kolegów prowadzących szkolenia jako Professional Scrum Trainer. Trzeba mieć na uwadze, że moje opisy tych wysokowydajnych zachowań powinny być traktowane jako wizja albo „cel doskonalenia”, do którego zespół powinien dążyć. Będzie to trudne. Będzie wymagać czasu. Będzie wymagać pomocy. Ostatecznie tacy właśnie ludzie będą prowadzić swoje zespoły na drodze do doskonałości.

Od czego najlepiej zacząć czytanie tej książki

Poszczególne części tej książki obejmują różne zakresy zagadnień. W zależności od potrzeb i aktualnej wiedzy na temat Scruma, usług Azure DevOps i powiązanych praktyk, można skupić się na określonych obszarach tej książki. Korzystając z poniższej tabeli, można określić, jak najlepiej korzystać z tej książki.

Jeśli ktoś

To powinien:

Nigdy nie słyszał o Scrumie lub jest jego nowym adeptem

Przeczytać Przewodnik po Scrumie, a następnie przeczytać rozdział 1

Nigdy nie słyszał o Professional Scrum lub jest jego nowym adeptem

Przeczytać rozdział 1

Jest nowym użytkownikiem zestawu narzędzi Azure DevOps

Przeczytać rozdział 2

Jest nowym użytkownikiem usługi Azure Boards lub chce wiedzieć więcej na temat tworzenia niestandardowego procesu Professional Scrum

Przeczytać rozdział 3

Jest zaznajomiony ze Scrumem oraz usługami Azure DevOps i jedynie chce dowiedzieć się, jak skonfigurować Azure DevOps dla Scrum Teamu

Przeczytać rozdział 4

Jest zaznajomiony ze Scrumem oraz usługami Azure DevOps i jedynie chce dowiedzieć się, jak planować Sprint i tworzyć Sprint Backlog

Przeczytać rozdział 6

Nie zna pojęcia programowania sterowanego testami akceptacyjnymi i chce dowiedzieć się, jak planować i śledzić Sprint przy użyciu Azure Test Plans

Przeczytać rozdział 7

Nie zna pojęcia przepływu albo sposobów wykorzystania tablicy Kanban do wizualizacji pracy i zarządzania jej przepływem

Przeczytać rozdział 9

Staje przed typowymi wyzwaniami Scruma i jest zainteresowany radzeniem sobie z dysfunkcyjnymi działaniami

Przeczytać rozdział 10

Staje w obliczu sytuacji skalowania, gdzie kilka Scrum Teamów współpracuje nad budowaniem wspólnego produktu

Przeczytać rozdział 11

Konwencje i zasady w tej książce

Ta książka przedstawia informacje, korzystając z konwencji zaprojektowanych tak, aby informacje te były czytelne i łatwe w odbiorze.

Dla orientacji udostępniane są zrzuty ekranów odpowiednich funkcji Azure DevOps.

Elementy w ramkach zatytułowanych „Uwaga” lub „Wskazówka” zapewniają dodatkowe informacje i porady związane z danym zagadnieniem.

Niektóre uwagi i wskazówki są praktycznymi poradami zapewnianymi przez zaprzyjaźnione osoby z tytułami Professional Scrum Developer i Professional Scrum Trainer, które pomagały w pracy nad tą książką.

Dodatkowo zawarłem dwa dodatkowe rodzaje ramek zatytułowanych „Brzydkie zapachy” i „Studium przypadku Fabrikam Fiber”.

Brzydki zapach W tej książce zwracam uwagę na konkretne sytuacje i pułapki, których Scrum Team i jego członkowie powinni unikać. Nazywam je brzydkimi zapachami. Te brzydkie zapachy zazwyczaj, ale nie zawsze, oznaczają jakieś zaburzenia lub inne niezdrowe zachowania. Dla zespołów będących nowicjuszami Scruma te brzydkie zapachy mogą być trudne do zidentyfikowania. Gdy jednak zostaną wskazane, powinny zostać wyeliminowane i wykorzystane jako okazja do nauki. W miarę rozwoju zespołu powinien coraz lepiej radzić sobie z rozpoznawaniem i usuwaniem takich zaburzeń. Zespoły Professional Scrum Team potrafią identyfikować potencjalnie szkodliwe elementy lub dysfunkcje, oceniać ryzyka z nimi związane, a nawet eliminować konkretne szkodliwe zachowania.

Studium przypadku Fabrikam Fiber

Na kolejnych stronach tej książki będziemy posługiwać się studium przypadku firmy Fabrikam Fiber. Fabrikam Fiber jest fikcyjnym dostawcą szerokopasmowych usług telekomunikacyjnych. Fabrikam Fiber jest wielką korporacją, która świadczy usługi w wielu stanach USA. Firma ta wykorzystuje wewnętrzną aplikację webową dla swoich przedstawicieli obsługi klienta do tworzenia i zarządzania zgłoszeniami problemów z obsługą klientów. Tworzący ją zespół korzysta ze Scruma od jakiegoś czasu i przeszedł od niedawna na usługi Azure DevOps. Moje opinie na temat zdrowych i niezdrowych zachowań są widoczne poprzez wybory dokonywane przez Scrum Team w firmie Fabrikam Fiber.

Wymagania systemowe

Mimo że ta książka nie zawiera żadnych ćwiczeń praktycznych, zachęcam do zarejestrowania się w usługach Azure DevOps, aby móc z nimi eksperymentować i ćwiczyć podczas czytania tej książki. Utworzenie swojej organizacji zajmuje tylko kilka minut, a pierwszych pięciu użytkowników w planie podstawowym może korzystać z tych usług za darmo – co powinno wystarczyć, aby grupa kolegów mogła korzystać ze wszystkich funkcji wspominanych w tej książce. Usługi Azure DevOps stanowią ofertę SaaS (Software as a Service – oprogramowanie jako usługa) opartą na chmurze i oferującą dostarczanie nowych funkcji co kilka tygodni, co oznacza, że zrzuty ekranów w tej książce mogą nie odpowiadać dokładnie temu, co będzie widoczne w przeglądarce czytelnika za jakiś czas.

Ponadto warto pobrać oprogramowanie Visual Studio Community Edition lub Visual Studio Code, aby zbadać, jak łączy się z Azure DevOps i jak może być wykorzystywane do współpracy przy użyciu usług Azure Boards i Azure Repos. Oba te produkty są darmowe.

Errata, aktualizacje i wsparcie

Dokonaliśmy wszelkich starań, aby zapewnić dokładność informacji w tej książce i jej materiałach towarzyszących. Aktualizacje tej książki mogą być dostępne w formie erraty i listy poprawek pod adresem:

MicrosoftPressStore.com/ProfScrumDevelopment/errata

W przypadku odkrycia błędu, który nie jest już wymieniony na tej liście, prosimy o przesłanie nam informacji, korzystając z formularza na tej samej stronie.

Dodatkowe wsparcie i informacje związane z tą książką można znaleźć pod adresem:
www.MicrosoftPressStore.com/Support.

Należy zwrócić uwagę, że wsparcie techniczne dla produktów programowych i sprzętowych firmy Microsoft nie jest oferowane pod powyższymi adresami. Pomoc dotyczącą oprogramowania lub sprzętu firmy Microsoft można uzyskać pod adresem http://support.microsoft.com.

Bądźmy w kontakcie

Chętnie porozmawiamy! Nasza strona w serwisie Twitter: http://twitter.com/MicrosoftPress

Podziękowania

Jest kilka osób, które pomogły mi w napisaniu tej książki. Podziękowania dla: Loretty Yates za kolejną szansę napisania książki dla wydawnictwa Microsoft Press; Charvi Arora, Tracey Croom, Elizabeth Welch, Songlin Qiu, Vaishnavi Venkatesan i Donny Mulder za cierpliwe przeglądanie moich materiałów i pomoc w poprawieniu stylu; Donis Marshall za inspirację do napisania kolejnej książki oraz bezpośrednie (i cenne) uwagi; Dana Hellema za mnóstwo odpowiedzi na pytania dotyczące Azure Boards i przejrzenie rozdziałów tej książki; Phila Japikse, Simona Reindla, Briana Randella, Ognjen Bajić, Ana Roje Ivančić, Martina Kulova, Cory’ego Isaksona, Davida Corbina, Charlesa Revella, Daniela Vacanti i Christiana Hassa za świetne pomysły i pomoc w dopracowaniu mojego przesłania; Kena Schwabera i Jeffa Sutherlanda za zaktualizowanie Przewodnika po Scrumie, gdy już niemal kończyłem pisanie tej książki.

Część I

Podstawy Scruma

Rozdziały w tej części kładą podwaliny pod zrozumienie trzech obszarów, które musi znać każdy praktyk Professional Scrum korzystający z narzędzi DevOps firmy Microsoft:

Scrum, a dokładniej Professional Scrum

Microsoft Azure DevOps (ogólnie)

Microsoft Azure Boards (w szczególności)

Zacznę od przyjrzenia się Scrumowi i zasadom Scruma. Skupię się na tym, jak i kiedy Developer wchodzi w interakcję z Product Ownerem i Scrum Masterem, uczestniczy w różnych wydarzeniach w Scrumie i współdziała z różnymi artefaktami Scruma. Ważne jest, aby wszyscy Developerzy rozumieli reguły Scruma i jakie są oczekiwania wobec nich i ich zespołu, a także kiedy i jak powinni wchodzić w interakcje z Product Ownerem, Scrum Masterem, interesariuszami i różnymi artefaktami.

Pozostałe rozdziały w tej części mają bardziej techniczny charakter i obejmują narzędzia dostępne w usługach Azure DevOps, a w szczególności usługę Azure Boards. Skupiam się na dostępnych w chmurze usługach Azure DevOps, a nie na lokalnym serwerze Azure DevOps. Choć istnieje wiele narzędzi DevOps dostępnych dla Scrum Teamu, staram się wymieniać i omawiać tylko te, które są istotne dla praktykujących Professional Scrum. Zwracam również uwagę na to, których błyszczących narzędzi lepiej nie wyciągać, pozwalając zespołowi raczej na ćwiczenie bardziej cenionych praktyk związanych ze współpracą. Poza wszystkim cenimy jednostki i interakcje bardziej niż procesy i narzędzia.

Uwaga W Przewodniku po Scrumie z 2020 roku rola Development Teamu została zastąpiona rolą Developera. Celem było wyeliminowanie pojęcia oddzielnego zespołu wewnątrz zespołu, co prowadziło do podziałów „my i oni” pomiędzy Product Ownerem a Development Teamem. Obecnie jest tylko jeden zespół – Scrum Team – i koncentruje się na tym samym celu przy trzech różnych zakresach odpowiedzialności, które stanowią: Product Owner, Scrum Master i Developerzy. Pamiętajmy, że Scrum uznaje testerów, programistów, projektantów, architektów, analityków, specjalistów od baz danych, autorów technicznych, po prostu za… Developerów.

Rozdział 1

Professional Scrum

Scrum to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów. Oprogramowanie jest złożonym problemem. Dlatego Scrum jest idealny do zarządzania rozwojem oprogramowania w celu znajdowania rozwiązań w sposób adaptacyjny. Opracowywanie oprogramowania nie generuje tego samego wyjścia za każdym razem przy określonym wejściu. Scrum uznaje ten fakt, a ze względu na jego empiryczny charakter, promuje wykorzystanie eksperymentów w celu przeprowadzania inspekcji i adaptacji.

Scrum nie jest metodologią ani procesem. Stanowi tylko ramy postępowania. Innymi słowy, jeśli weźmiemy Scrum i dodamy swoje własne praktyki uzupełniające, takie jak programowanie sterowane testami adaptacyjnymi, uzyskamy swój proces. Zespoły mogą wykorzystywać empiryczne atrybuty Scruma, aby regularnie sprawdzać skuteczność swoich praktyk i dokonywać odpowiednich zmian. W tej książce przedstawię wiele praktyk uzupełniających do wzięcia pod uwagę.

Uwaga Fundamentem Scruma jest empiryczna teoria sterowania procesem i koncepcja „lean” (szczupłego zarządzania). Empiryzm stwierdza, że wiedza pochodzi z doświadczenia i podejmowania decyzji w oparciu o to, co jest znane. Koncepcja „lean” ogranicza straty i koncentruje się na tym, co najważniejsze.

Nawet dzisiaj, po ponad 60 latach ewolucji tworzenia oprogramowania, istnieje poważne ryzyko, że projekt programistyczny średniej lub dużej wielkości się nie powiedzie. Na szczęście nasza branża w końcu zauważyła ten problem, lepiej go rozumie i zaczyna na niego reagować. Niektóre organizacje zwiększyły swoje szanse na sukces. Istnieją dowody, że praktyki zwinne, takie jak Scrum, prowadzą do tych sukcesów.

Wskazówka Korzystając z analogii programistycznej, możemy traktować Agile jako interfejs. Manifest Agile definiuje cztery abstrakcyjne wartości i 12 abstrakcyjnych zasad (http://agilemanifesto.org). Chociaż istnieje wiele sposobów implementacji tych wartości i zasad, Agile Manifesto ich nie opisuje. Scrum natomiast to robi. Możemy traktować Scrum jako konkretną klasę, która implementuje wartości i zasady Agile poprzez swoje role, wydarzenia, artefakty i reguły.

Zespoły Agile wiedzą, że muszą ciągle dokonywać inspekcji i adaptacji – nie tylko swojego produktu, ale też swojego procesu i praktyk. Dobre poznanie (np. z tej książki) Scruma, DevOps i narzędzi firmy Microsoft stanowi dobry początek. Doświadczenie w korzystaniu z nich razem w praktyce jest jeszcze lepsze. Ideałem jest umiejętność rozpoznawania i wykorzystania okazji do poprawy w ich stosowaniu! Oznacza to bycie profesjonalistą. To powinno być naszym celem. Nie wystarczy zadowalać się projektem, który jedynie nie zawiedzie. Warto dążyć do jak najlepszego ukończenia projektu, z większą wartością i płynącą z niego nauką, niż mogłoby się to wydawać możliwe.

Przewodnik po Scrumie

Scrum istnieje od wczesnych lat 90-tych poprzedniego wieku. Na początku definicja Scruma i związanych z nim praktyk pochodziła z książek, prezentacji i od specjalistów, którzy starali się go jak najlepiej objaśniać. Niestety te informacje nie zawsze były dokładne i prawie nigdy nie były spójne. Nawet dwaj twórcy Scruma – Ken Schwaber i Jeff Sutherland – bywali czasami niespójni. Obecny Scrum nie przypomina tego sprzed 25 lat.

W roku 2009 organizacja Scrum.org skodyfikowała Scrum, tworząc i publikując Przewodnik po Scrumie. Ten darmowy przewodnik stanowi oficjalne reguły Scruma i jest opracowywany przez twórców Scruma: Schwabera i Sutherlanda. Jest to bardzo zwięzły dokument. Wersja PDF z roku 2020 zajmuje tylko 14 stron. Jest on dostępny w 30 językach do pobrania pod adresem https://scrumguides.org.

Przewodnik po Scrumie jest świetnym źródłem, z którego można korzystać podczas czytania tej książki. Czytając ten przewodnik, można zobaczyć, że Scrum jest prosty i dość łatwy do zrozumienia. Niestety jest niezwykle trudny do pełnego opanowania. Przewodnik po Scrumie będzie w przyszłości aktualizowany i może nieco zmienić wskazówki dostępne w tym rozdziale i w pozostałej części książki.

Wskazówka Można potraktować Scrum jak grę w szachy. Jedno i drugie ma swoje reguły. Na przykład Scrum nie pozwala na istnienie dwóch Product Ownerów, tak jak szachy nie pozwalają graczowi mieć dwóch królów. Podczas gry w szachy należy postępować zgodnie z regułami gry. Jeśli nie będzie się tego robić, nie będzie to graniem w szachy. Tak samo jest ze Scrumem. Można by też powiedzieć, że to nie Scrum ani szachy wygrywają lub przegrywają. To gracze wygrywają lub przegrywają. Ci, którzy grają zgodnie z zasadami, będą grać coraz lepiej, choć opanowanie gry może zająć sporo czasu.

Platforma Scrum składa się ze Scrum Teamu (zespołu) i powiązanych z nim ról, wydarzeń, artefaktów i reguł. Każdy z tych elementów służy określonemu celowi, jak zobaczymy w tym rozdziale. Reguły Scruma zdefiniowane w Przewodniku po Scrumie wiążą ze sobą te role, wydarzenia i artefakty. Przestrzeganie tych reguł ma zasadnicze znaczenie dla powodzenia zdolności użycia Scruma przez zespół, a co ważniejsze, dla udanego opracowania i dostarczenia produktu o wysokiej wartości i jakości. Zmiana podstawowych zasad lub koncepcji Scruma, pominięcie pewnych elementów lub nieprzestrzeganie reguł zakrywa problemy i ogranicza korzyści zapewniane przez Scrum, potencjalnie czyniąc go wręcz bezużytecznym.

Scrum jest darmowy i jest oferowany w formie Przewodnika po Scrumie. Role, wydarzenia, artefakty i reguły Scruma są niezmienne, a choć możliwa jest implementacja tylko części Scruma, wynikiem nie będzie Scrum. Scrum istnieje tylko w całości i działa dobrze jako pojemnik dla innych praktyk, technik i metodologii. Często opisuję Scrum jako „ramy postępowania, w ramach których zespół może eksperymentować z różnymi praktykami uzupełniającymi”.

Filary Scruma

Fundamentem Scruma jest empiryzm i koncepcja „lean”. Empiryzm stwierdza, że wiedza pochodzi z doświadczenia i podejmowania decyzji w oparciu o to, co jest obserwowane i znane. Koncepcja „lean” ogranicza straty i koncentruje się na tym, co najważniejsze. Scrum stosuje iteracyjne i przyrostowe podejście do optymalizowania przewidywalności i kontrolowania ryzyka. Scrum angażuje grupy ludzi, którzy wspólnie mają wszystkie umiejętności i wiedzę do wykonania danej pracy i dzielą się nimi lub nabywają takie umiejętności w razie potrzeby.

Scrum łączy cztery formalne wydarzenia umożliwiające inspekcję i adaptację w ramach obejmującego je wydarzenia, jakim jest Sprint. Te wydarzenia działają, ponieważ implementują empiryczne filary Scruma, czyli inspekcję, adaptację i przejrzystość. Wydarzenia omówię później w tym rozdziale, ale chciałbym poświęcić chwilę na zdefiniowanie tych trzech filarów Scruma:

Inspekcja Artefakty Scruma oraz postępy w dążeniu do uzgodnionych celów muszą być poddawane częstej i rzetelnej inspekcji, aby możliwe było wykrycie potencjalnie niepożądanych odstępstw lub problemów. Aby ułatwić inspekcję, Scrum zapewnia stały rytm w postaci swoich pięciu wydarzeń. Inspekcja umożliwia adaptację. Inspekcja bez adaptacji jest uznawana za bezcelową. Celem wydarzeń w Scrumie jest wywoływanie zmian i poprawy.

Adaptacja Jeśli jakikolwiek aspekt procesu wykracza poza dopuszczalne limity lub jeśli uzyskany produkt jest niemożliwy do zaakceptowania, stosowany proces lub wytwarzane materiały należy odpowiednio skorygować. Zmian tych należy dokonać jak najszybciej, aby zminimalizować dalsze odstępstwa. Adaptacja staje się trudniejsza, kiedy osoby w nią zaangażowane nie mają odpowiednich uprawnień lub zdolności samozarządzania. Oczekuje się, że Scrum Team wprowadzi modyfikacje natychmiast po uzyskaniu jakiejkolwiek nowej wiedzy w wyniku inspekcji.

Przejrzystość Kształtujący się proces oraz praca muszą być widoczne dla osób ją wykonujących, jak również dla osób, na rzecz których praca ta jest wykonywana. W Scrumie ważne decyzje podejmowane są na podstawie zaobserwowanego stanu jego trzech formalnych artefaktów. Niedostateczna przejrzystość artefaktów może prowadzić do decyzji, których wynikiem jest zmniejszona wartość i zwiększone ryzyko. Przejrzystość umożliwia inspekcję. Inspekcja i adaptacja bez przejrzystości prowadzą do błędów i strat.

Scrum w działaniu

Czytając Przewodnik po Scrumie, można zrozumieć składniki i powiązane z nimi reguły, ale nie koniecznie łatwo dostrzec, jak współdziałają ze sobą. Do tego wymagane jest faktyczne doświadczenie w korzystaniu ze Scruma przy opracowywaniu produktu w zespole. Jako substytut tego doświadczenia rysunek 1-1 został stworzony przez Scrum.org, aby pomóc w zilustrowaniu ram Scruma w działaniu.

W Scrumie produkt jest nośnikiem, który zapewnia wartość. Ten produkt może być usługą, produktem fizycznym lub czymś bardziej abstrakcyjnym. Produkt ma wyraźne granice, znanych interesariuszy oraz dobrze zdefiniowanych użytkowników lub klientów. Oprogramowanie dobrze pasuje do tej definicji, choć Scrum może być używany nie tylko do wytwarzania oprogramowania. Ponieważ jest to też książka dotycząca usług Azure DevOps, będę opisywał Scrum i Professional Scrum w kontekście oprogramowania jako produktu.

Cel Produktu opisuje przyszły stan produktu, który może służyć jako cel planowania działań przez Scrum Team. Cel Produktu stanowi długoterminowe zamierzenie Scrum Teamu. Zespół musi zrealizować jeden cel (lub z niego zrezygnować), zanim przystąpi do realizacji kolejnego. Przykładem Celu Produktu w przypadku oprogramowania mogłoby być „uzyskać 100 tys. pobrań ze sklepu z aplikacjami”.

Product Backlog to uporządkowana lista wszystkiego, co jest konieczne do osiągnięcia Celów Produktu. Jest to jedyne źródło zmian dla produktu, które stale się zmienia, co oznacza, że będzie ciągle ewoluować ze względu na zmiany warunków biznesowych, dziedziny i technologii. Każdy element na tej liście jest określany skrótem PBI (Product Backlog Item). W przypadku oprogramowania Product Backlog obejmuje funkcje do zaimplementowania, błędy do poprawienia i eksperymenty do przeprowadzenia. Product Owner odpowiada za zarządzanie oczekiwaniami, zagrożeniami i wynikami produktu, a także za zapewnianie, aby Product Backlog był uporządkowany (ustawienie priorytetów), przejrzysty (dostępny) i zrozumiały.

Developerzy współpracują z Product Ownerem i innymi osobami w razie potrzeby podczas Sprint Planningu i udoskonalania Product Backlogu, aby rozumieć, szacować i przewidywać elementy PBI. Product Owner uporządkowuje Product Backlog zgodnie z czynnikami, takimi jak zwrot z inwestycji (ROI) dla tych elementów PBI, ryzyko, priorytety biznesowe, zależności i okazja do nauki.

Sprint jest okresem czasu o stałej długości, który obejmuje inne wydarzenia Scruma. Sprint powinien trwać miesiąc lub krócej, aby zmniejszać ryzyko i prowadzić do spójności. Nowy Sprint zaczyna się natychmiast po zakończeniu poprzedniego Sprintu.

Pierwszym wydarzeniem w Sprincie jest Sprint Plannning (planowanie Sprintu). W tym wydarzeniu Scrum Team współpracuje nad prognozowaniem i planowaniem pracy w danym Sprincie. Będą brane pod uwagę elementy PBI z górnej części Product Backlogu, które pozwolą jak najlepiej osiągnąć Cel Produktu. Scrum Team współpracuje nad prognozowaniem tych elementów, które wydają się możliwe do ukończenia przed końcem Sprintu. Formułowany jest Cel Sprintu i powstaje Sprint Backlog. Sprint Backlog zawiera prognozowane elementy oraz plan ich dostarczenia. Sprint Backlog na bieżąco pokazuje pracę pozostałą do wykonania podczas Sprintu.

Rysunek 1-1 Ramy Scruma

Znaczna część Sprintu będzie poświęcona na pracę nad osiągnięciem Celu Sprintu poprzez opracowywanie elementów ze Sprint Backlogu. Reguły Scruma nie określają dokładnie, co dzieje się codziennie podczas opracowywania produktu. Developerzy muszą spotykać się regularnie podczas wydarzenia Daily Scrum, aby synchronizować plan działań na następne 24 godziny.

Jeśli to konieczne, Developerzy powinni też spotykać się z Product Ownerem, aby udoskonalać Product Backlog. Podczas tego udoskonalania elementy w Product Backlogu otrzymują dodatkowe szczegóły i szacunki. To sprawia, że Product Backlog jest aktualny, tak aby Product Owner mógł prowadzić rzeczowe rozmowy z interesariuszami, planować wydania produktu i podejmować lepsze decyzje dotyczące przyszłych działań.

Podczas Sprintu zespół Scrum Team kończy prace nad elementami w Sprint Backlogu zgodnie z Definicją Ukończenia (Definition of Done). Ta definicja wymienia praktyki i standardy, które muszą być spełnione dla każdego elementu, zanim będzie mógł on zostać uznany za ukończony. Jeśli Definicja Ukończenia jeszcze nie istnieje, to jest tworzona przez Scrum Team. Istotne jest, aby wszyscy rozumieli tę definicję, ponieważ będzie używana w celu ułatwienia kontroli postępów i jakości. Praca, która nie spełnia Definicji Ukończenia… nie jest ukończona i nie może zostać wydana. Nie powinna również podlegać inspekcji podczas wydarzenia Sprint Review (przeglądu Sprintu).

Najlepiej, aby Developerzy współpracowali z Product Ownerem podczas całego Sprintu, żeby zapewnić powstanie świetnego produktu. Jeśli Developerzy wcześnie ukończą pracę nad swoimi prognozami, powinni współpracować z Product Ownerem nad znalezieniem dodatkowych elementów PBI do realizacji. Z kolei przy pierwszych sygnałach, gdy Developerzy podejrzewają, że nie będą w stanie ukończyć prognozowanej pracy, powinni współpracować z Product Ownerem, aby zidentyfikować i omówić kompromisowe rozwiązania i zmodyfikować Sprint Backlog w taki sposób, który nie wpłynie negatywnie na jakość ani nie zmieni Celu Sprintu.

Increment (przyrost) jest użytecznym i dostarczającym wartość fragmentem pracy podlegającej inspekcji, który spełnia Definicję Ukończenia. Increment składa się z jednego lub kilku ukończonych elementów PBI, które zostały prognozowane do wykonania w czasie danego Sprintu. Increment podlega inspekcji podczas Sprint Review. Product Owner może zaprosić różnych interesariuszy na Sprint Review, aby poznać ich zdanie. Te informacje są gromadzone i mogą stać się nowymi elementami w Product Backlogu. Istniejące elementy PBI mogą też zostać zaktualizowane lub usunięte. Informacje zwrotne od interesariuszy mogą wpłynąć na decyzję Product Ownera dotyczącą wydania produktu, kontynuowania jego rozwoju lub zatrzymania w ogóle prac nad produktem. Te ostatnie decyzje powinny być oparte na przesłankach biznesowych, a nie jakościowych. Niezależnie od tego, kiedy Increment zostanie wydany, Scrum Team powinien zawsze opracowywać go tak, jakby miał zostać wydany. Może to obejmować wielokrotne wydanie podczas Sprintu, co jest wspierane przez Scrum.

Ostatnim wydarzeniem w Sprincie jest Sprint Retrospective (retrospektywa Sprintu). Jest to okazja na to, aby Scrum Team dokonał inspekcji siebie i swojej pracy w celu poprawienia swoich praktyk i procesu. Jeśli określone zostaną eksperymenty prowadzące do usprawnienia, zespół powinien utworzyć plan działania dla następnego Sprintu. Aby zapewnić stałe doskonalenie, Scrum Team powinien określić co najmniej jedno priorytetowe ulepszenie procesu i wdrożyć je podczas następnego Sprintu. Nic nie wykracza poza zakres Sprint Retrospective – można omawiać relacje, ludzi, proces, praktyki i narzędzia. Scrum Team może też podjąć decyzję o dostosowaniu swojej Definicji Ukończenia w celu zwiększenia jakości. Po zakończeniu Sprint Retrospective rozpoczyna się nowy Sprint i cały cykl się powtarza.

Role w Scrumie

Grupa osób, która odpowiada za zbudowanie produktu i spełnienie jego celów, jest nazywana Scrum Teamem (Zespołem Scrumowym). Scrum Team składa się z następujących ról:

Product Owner (Właściciel Produktu)

Developerzy

Scrum Master (Mistrz Scruma)

Gdyby potraktować role jako świadczenie usług, to Developerzy służą Product Ownerowi, natomiast Scrum Master służy wszystkim. Dlatego Developerzy mogą wywierać silny wpływ na wybór Scrum Mastera. Product Owner może wywierać silny wpływ na wybór Developerów do zespołu (niezależnie od zasad i procedur kadrowych). Ze względu na ten rozdział obowiązków, role te powinny być odgrywane przez różne osoby. Zmniejsza to ryzyko wystąpienia konfliktu interesów. W mniejszych zespołach może być konieczne łączenie ról.

Developerzy

Developerzy są profesjonalistami w Scrum Teamie, którzy są w stanie zaprojektować, zbudować, przetestować i dostarczyć ukończony produkt. W Scrum Teamie jest od trzech do dziewięciu Developerów – jest to wystarczająco mała liczba, aby mogli się łatwo komunikować i żwawo działać, a przy tym wystarczająco duża, aby zapewniać wielofunkcyjność i współpracę w złożonej przestrzeni, takiej jak tworzenie oprogramowania.

Zespół składający się z tylko dwóch Developerów nie potrzebuje Scruma, ponieważ może się łatwo komunikować bezpośrednio i zachować wydajność. Istnieje też większe ryzyko, że tych dwóch Developerów nie będzie miało wszystkich umiejętności wymaganych do wykonania całej pracy. Z drugiej strony zespoły z większą liczbą Developerów niż dziewięć wymagają zbyt dużej koordynacji. Te większe zespoły zwykle generują zbyt dużo złożoności, żeby mogły czerpać wartość z empiryzmu Scruma. W sytuacjach, gdy mamy więcej niż dziewięciu Developerów, konieczne może być utworzenie kilku Scrum Teamów, które nawet mogą tworzyć Nexus (splot). Omówię dokładniej Nexus i Scaled Professional Scrum w rozdziale 11 „Skalowalny Professional Scrum”.

Uwaga Product Owner i Scrum Master nie wliczają się do tej liczby 3–9 Developerów, o ile sami nie pełnią również roli Developera, który będzie pracować nad Sprint Backlogiem podczas Sprintu. Tak, czy owak, Scrum Team zwykle liczy 10 lub mniej osób.

Warto zwrócić uwagę, że to, iż dana osoba pełni rolę Developera w Scrumie, nie oznacza, że jest developerem w klasycznym sensie – czyli kimś, kto pisze kod. W zależności od zadania, może zajmować się architekturą, interfejsem użytkownika, testami, schematem bazy danych, potokami wdrożeniowymi, wynikami testów, instalatorami albo dokumentacją. Każda z tych osób rozwija jakąś część produktu.

Tabela 1-1 zawiera listę działań wysokiego poziomu, które będą wykonywane przez Developerów w Scrum Teamie.

Tabela 1-1 Działania Developerów w Scrumie

Działanie

Kiedy

Współpraca z Product Ownerem przy prognozowaniu pracy na dany Sprint i opracowywaniu Celu Sprintu.

Sprint Planning

Współpraca z innymi Developerami przy planowaniu implementacji prognozowanej pracy.

Sprint Planning, Daily Scrum lub w razie potrzeby

Uczestnictwo w wydarzeniu Daily Scrum.

Codziennie

Opracowywanie Incrementu zgodnie z Definicją Ukończenia.

Po Sprint Planningu i przed Sprint Review

Współpraca z Product Ownerem nad dopracowaniem Product Backlogu.

Podczas Sprintu, jak określi Scrum Team

Wspólne określanie dodatkowych zadań, gdy prognozowana praca zostanie wcześnie zakończona.

Podczas Sprintu w razie potrzeby

Wspólne omawianie kompromisów i tworzenie planu awaryjnego, gdy prognozowane prace nie mogą zostać ukończone.

Podczas Sprintu w razie potrzeby

Wspieranie interesariuszy przy inspekcji Incrementu i zbieranie informacji zwrotnych.

Sprint Review lub w dowolnym czasie podczas Sprintu w razie potrzeby

Przemyślenie procesu i praktyk w celu ustalenia eksperymentów mających doprowadzić do poprawy.

Sprint Retrospective

Inspekcja, adaptacja, uczenie się i doskonalenie – życie wartościami Scruma.

Zawsze

Nie należy zakładać, że Developer będzie wykonywał tylko te typy zadań, w których jest dobry lub na których się dobrze zna. Na przykład to, że Dieter ma doświadczenie w programowaniu baz danych, nie oznacza, że będzie zajmował się tym rodzajem zadań. Jeśli podczas Sprintu okaże się, że następne logiczne zadanie do wykonania wymaga programowania bazy danych, a Dieter nie będzie dostępny, inny Developer powinien podjąć tę pracę, o ile to możliwe. Podczas opracowywania produktu osoba najlepiej predystynowana do wykonania danego zadania zostanie ustalona na podstawie wielu czynników, w tym wiedzy i dostępności. To właśnie z tego powodu szacunki dotyczące Sprint Backlogu są dokonywane kolektywnie, a nie indywidualnie przez Developerów – nawet jeśli poszczególne osoby są specjalistami lub nawet ekspertami w danych dziedzinach. Dlatego też Scrum Team powinien mieć po kilku Developerów z potrzebnym zestawem umiejętności. Zajmiemy się tym dokładniej w rozdziale 8, „Skuteczna współpraca”.

Wskazówka Znam bardzo niewiele Scrum Teamów, w których członkowie nazywają siebie „Developerami”. Nadal istnieje odruch, który zrównuje termin „developer” z programistą lub osobą piszącą kod. Jest to też wzmacniane przez całą naszą branżę. W takich przypadkach tymczasowo odpowiednim substytutem może być użycie terminu „członek zespołu” – żeby wyraźnie obejmował on też testerów, projektantów i inne osoby niebędące programistami.

Jako kolektyw Developerzy muszą być interdyscyplinarni. To znaczy, że musi istnieć co najmniej jeden Developer w Scrum Teamie, który ma potrzebne umiejętności do wykonania każdego typu wymaganego działania. Innymi słowy, Developerzy – jako całość – muszą mieć wszystkie umiejętności wymagane do ukończenia pracy. Ta interdyscyplinarność nie oznacza, że każdy Developer jest interdyscyplinarny – choć byłoby to idealne. Najlepiej, aby zawsze było kilku Developerów, którzy mają wymaganą umiejętność. Jeśli tak nie jest, to zespół powinien dążyć do poprawy tego stanu rzeczy przez pracę w parach i grupach lub wykorzystując jakieś inne techniki instruktażowe podczas opracowywania produktu. Posiadanie w zespole tylko jednego Developera z kluczową umiejętnością jest ryzykowne.

Uwaga Prędkość (velocity) jest historyczną miarą elementów PBI, które udało się dostarczyć Scrum Teamowi. Może być mierzona poprzez liczbę tych elementów, rozmiar/wysiłek (np. punkty) albo ich wartość biznesową. Prędkość pojedynczego Sprintu nie jest przydatną miarą, ale śledzenie jej na przestrzeni kilku Sprintów pokazuje ogólny trend wydajności zespołu. Po znormalizowaniu prędkość może być użyteczna w planowaniu Sprintów i wydaniach produktu. Na przykład, jeśli prędkość zespołu wynosi średnio 20 punktów na Sprint, a Product Backlog pokazuje 12 elementów PBI, które trzeba opracować w celu osiągnięcia Celu Produktu i mających w sumie 96 punktów, to możemy oczekiwać, że wydanie produktu będzie dostępne za mniej więcej 5 Sprintów, czyli za 2 i pół miesiąca przy 2-tygodniowych Sprintach. Prędkość nie jest wymieniana w Przewodniku po Scrumie i jest uważana za praktykę uzupełniającą. Zespoły mogą też śledzić i wykorzystywać miary przepływu, takie jak przepustowość, jako miarę przeszłej wydajności. Przepływ i miary przepływu omówię w rozdziale 9 „Poprawianie przepływu”.

Skład Scrum Teamu nie zmienia się podczas Sprintu. Jeśli miałby się zmienić, powinno to się odbywać tylko pomiędzy Sprintami. Zwykle jest to wynik decyzji podjętej wspólnie podczas wydarzenia Sprint Retrospective. Zmiany te mogą obejmować dodanie nowego członka zespołu, wymianę członka z innym zespołem, usunięcie członka z zespołu albo zmianę roli członka zespołu. Trzeba pamiętać, że wszelkie zmiany składu zespołu stanowią zakłócenie. Wydajność może początkowo zmniejszyć się na jakiś czas, a następnie powinna (miejmy nadzieję) ponownie wzrosnąć. Jeśli Scrum Team śledzi prędkość lub przepustowość prac, to takie zakłócenie będzie wyraźnie widoczne.

Studium przypadku Fabrikam Fiber

Developerzy w Scrum Teamie Fabrikam Fiber to pięć interdyscyplinarnych osób o różnym doświadczeniu, zestawach umiejętności i poziomach zaawansowania. Są nimi Andy, Dave, Dieter, Toni i Richard (ja sam). Andy i Toni mają doświadczenie w dziedzinie architektury, projektowania i pewną znajomość języka C#. Dave, Dieter i ja mamy solidne doświadczenie w programowaniu w języku C#. Dieter i ja mamy też doświadczenie w programowaniu SQL i Azure, w tym w programowaniu skryptów Windows PowerShell. Jako zespół wszyscy uczestniczyliśmy w szkoleniu Professional Scrum Developer organizowanym przez Scrum.org i uzyskaliśmy po nim pozytywne oceny.

Product Owner

Product Owner reprezentuje głos naszego użytkownika. To oznacza, że Product Owner zna nie tylko produkt, jego domenę, wizję i cele, ale też jego użytkowników. Sama wiedza, jak produkt działa i co w nim naprawić, nie wystarcza, aby być kompetentnym Product Ownerem. Dobry Product Owner jest na bieżąco z potrzebami swoich użytkowników. Dobry Product Owner podziela pasję swoich użytkowników i odczuwa empatię dla ich zmagań i oczekiwań. Product Owner reprezentuje też Developerów przed organizacją – przynajmniej do momentu, gdy Developerzy nie zostaną wprowadzeni do organizacji i nie zaczną współpracować bezpośrednio z innymi osobami w organizacji.

Uwaga Przez lata słyszałem, że Product Owner jest głosem interesariuszy lub klienta. Choć jest to prawda, to wolę myśleć o Product Ownerze głównie jako o głosie użytkownika. Jaka jest różnica? Interesariuszem jest każdy, kto jest zainteresowany produktem lub jego rozwojem. Klientem jest zwykle ten, kto sponsoruje lub płaci za produkt. Użytkownikiem jest ten, kto faktycznie go używa. Product Owner w Professional Scrum dąży do zadowolenia wszystkich zainteresowanych stron.

Product Owner musi reprezentować potrzeby użytkownika i przekierowywać wartość w ich kierunku, a nie tylko starać się zadowolić osobę, która płaci. W Scrum Teamie jest tylko jeden Product Owner, co pozwala unikać zamieszania. Gdy Developerzy mają jakieś pytanie dotyczące produktu, które trzeba przedstawić interesariuszowi, powinni przede wszystkim zwrócić się do Product Ownera. Product Owner być może będzie musiał skonsultować się z innymi, aby uzyskać odpowiedzi, zwłaszcza w przypadku dużych lub bardziej złożonych produktów. Product Owner powinien być osobą, do której kierowane są wszystkie pytania dotyczące wizji, celów i funkcjonalności produktu.

Product Owner odpowiada za maksymalizowanie wartości produktu poprzez pracę Developerów. Głównym narzędziem Product Ownera do komunikacji z Developerami jest udoskonalony i uporządkowany Product Backlog. Product Owner współpracuje z Developerami nad tym, co i kiedy ma zostać opracowane. Tabela 1-2 wymienia typowe interakcje Developerów z Product Ownerem.

Częstym nieporozumieniem – które zostało poprawione w Przewodniku po Scrumie z 2020 roku – jest to, że Developerzy opracowują produkt. W istocie to Scrum Team opracowuje i rozwija produkt – poprzez współpracę wszystkich członków zespołu.

Wskazówka Product Owner w Professional Scrum powinien znać produkt, znać dziedzinę produktu, znać klientów produktu, znać użytkowników produktu, znać Scrum, mieć uprawnienia do podejmowania decyzji związanych z kierunkiem produktu, być dostępnym dla reszty Scrum Teamu i mieć dobre umiejętności interpersonalne. Nie spotkałem jeszcze Product Ownera, który spełniałby wszystkie te kryteria. Spotkałem wielu Product Ownerów, którzy chcieli się doskonalić w tych obszarach i dążyli do tego celu.

Tabela 1-2 Interakcje Developera z Product Ownerem

Interakcja

Kiedy

Wspólne planowanie Sprintu i prognozowanie elementów PBI.

Sprint Planning

Uzyskiwanie odpowiedzi na pytania dotyczące produktu/dziedziny i przedstawianie ich interesariuszom.

Podczas Sprintu w razie potrzeby

Udoskonalanie Product Backlogu.

Podczas Sprintu, jak określi Scrum Team

Współpraca przy podejmowaniu dodatkowych zadań.

Podczas Sprintu w razie potrzeby

Współpraca przy planowaniu pracy awaryjnej.

Podczas Sprintu w razie potrzeby

Pomoc Product Ownerowi przy inspekcji Incrementu i innych pojawiających się prac.

Podczas Sprintu w razie potrzeby

Pomoc Product Ownerowi podczas inspekcji przez interesariuszy i zbieraniu informacji zwrotnych.

Przynajmniej podczas Sprint Review, ale również podczas Sprintu w razie potrzeby

Współpraca przy inspekcji praktyk Scrum Teamu i planowania udoskonalania.

Sprint Retrospective

Współpraca przy tworzeniu Definicji Ukończenia.

Sprint Retrospective

Profesjonalne Scrum Teamy rozumieją podział obowiązków pomiędzy Product Ownera a Developerów i oczekują, że każda ze stron będzie wypełniać swoją rolę. Choć Przewodnik po Scrumie nie określa jasno, że Product Owner nie może być Scrum Masterem lub Developerem, to uważam, że dobrze jest utrzymać taki podział. Receptą na sukces jest, aby Product Owner koncentrował się na tym, co rozwijać, Developerzy koncentrowali się na tym, jak to rozwijać, a Scrum Master skupiał się na tym, aby wszyscy rozumieli i stosowali się do reguł Scruma.

Ponieważ Product Owner może odpowiadać przed organizacją za zyski lub straty produktu, Product Owner powinien stale czuwać nad optymalizowaniem wartości produktu. Product Owner w Professional Scrum jest zaangażowanym Product Ownerem. Stale troszczy się o to, co jest najlepsze dla produktu, a co ważniejsze, co jest najlepsze dla jego użytkowników.