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 ScrumMicrosoft 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)DeveloperzyScrum 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.
