Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00472 008136 10736970 na godz. na dobę w sumie
Large-Scale Scrum. Zwinne zarządzanie dużym projektem z LeSS - ebook/pdf
Large-Scale Scrum. Zwinne zarządzanie dużym projektem z LeSS - ebook/pdf
Autor: , Liczba stron: 360
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-3193-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook (-20%), audiobook).

Large-Scale Scrum. Zwinne zarządzanie dużym projektem

Scrum stoi w opozycji do tradycyjnych, hierarchicznych sposobów zarządzania procesami rozwoju oprogramowania. Pozwala na uzyskanie elastyczności i szybkości działania, dzięki czemu możliwe jest zaspokojenie coraz bardziej złożonych wymagań klientów. Metody zwinne doskonale sprawdzają się również w większej skali. Large-Scale Scrum, czyli LeSS, umożliwia pomyślne zarządzanie olbrzymimi międzynarodowymi projektami o dużej złożoności technicznej dzięki prostocie, skupieniu się na najistotniejszych aspektach zagadnień, a przede wszystkim dzięki ciągłemu zwracaniu uwagi na doskonałość techniczną.

Niniejsza książka jest przeznaczona dla każdego, kto chce poznać praktyczne aspekty wdrażania LeSS w procesach rozwijania oprogramowania. Jest szczególnie wartościowa dla osób zarządzających dużymi, skomplikowanymi projektami. Poza wyjaśnieniem koncepcji i zasad Scruma przedstawiono tu wnioski płynące z wielu lat doświadczeń wdrażania LeSS w przeróżnych organizacjach. Pokazano, jak można zapewnić, że dostarczony produkt będzie wyższej jakości, będzie prezentował wartości szczególnie cenne dla klienta, zespół będzie pracował wydajniej, elastyczniej i w o wiele prostszy sposób, a poszczególne cele będą osiągane przy znacznie mniejszej formalizacji!

Najważniejsze zagadnienia:

Craig Larman urodził się w Kanadzie. Specjalizuje się w kilku technikach projektowania oprogramowania, w tym również w metodykach zwinnych. Jest uznanym konsultantem i autorem wielu książek dotyczących rozwoju oprogramowania. Jako współtwórca LeSS od kilku lat angażuje się we wdrażanie tej metody w różnych organizacjach.

Bas Vodde urodził się w Holandii, obecnie mieszka w Singapurze. Jest trenerem, konsultantem, programistą i autorem książek. Specjalizuje się we wdrażaniu nowoczesnych technik rozwijania aplikacji, przede wszystkim w metodykach zwinnych. Wdrażał metodę Scrum w wielu różnych firmach, w tym w Nokia Networks.
LeSS: przygotuj swój zespół na sukces w dużej skali!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

• Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści 1 LeSS znaczy „więcej” 1 2 LeSS 5 Struktura LeSS 3 wdrożenie 53 4 Skup się na wartości dla klienta 77 5 Zarządzanie 113 6 Mistrzowie Młyna 135 Produkt LeSS 7 Produkt 155 8 właściciel Produktu 171 9 rejestr Produktu 197 10 Definicja ukończenia 229 Sprint w LeSS 11 Modyfikowanie rejestru Produktu 247 12 Planowanie Sprintu 275 13 Koordynacja i integracja 285 14 Przegląd i retrospekcja 313 Więcej za mniej 15 co dalej? 329 Dodatek A. reguły 331 Dodatek B. Zasady 335 Dodatek c. Bibliografia 337 Skorowidz 339 v Poleć książkęKup książkę Poleć książkęKup książkę LeSS Istnieją dwa podejścia do projektowania: Można tworzyć rzeczy tak proste, iż będzie oczywiste, że są pozbawione wad, albo czynić je tak złożonymi, że nie będą miały oczywistych wad. — C. A. R. Hoare Scrum w jednym zespole Scrum to framework pozwalający na tworzenie z zachowaniem empirycz- nej kontroli procesu. We frameworku tym zróżnicowany, samozarządzający Zespół tworzy produkt przyrostowo w wielu krokach1. W każdym ograni- czonym czasowo Sprincie tworzone jest możliwe do zapewnienia rozwinięcie produktu i — w idealnej sytuacji — jest ono zapewniane. Jeden Właściciel Produktu jest odpowiedzialny za utrzymanie jak najwyższej wartości pro- duktu, priorytetyzację elementów w Rejestrze Produktu i wybieranie celu każdego Sprintu z uwzględnieniem dostępnych informacji zwrotnych i zdo- bytej wiedzy. Mały Zespół jest odpowiedzialny za zapewnienie tego, co jest celem danego Sprintu; nie ma ograniczających, ściśle wyspecjalizowanych ról. Mistrz Młyna uczy zasad Scruma oraz tego, w jaki sposób można go wy- korzystać do dostarczenia czegoś wartościowego; jest trenerem Właściciela Produktu, Zespołu i organizacji podczas stosowania Scruma oraz służy za lustro. Nie ma menedżera projektu ani lidera zespołu. Empiryczna kontrola procesu wymaga przejrzystości, która pojawia się dzięki krótkim cyklom tworzenia i analizy możliwych do zapewnienia udoskonaleń produktu. W ten sposób podkreślana jest konieczność ciągłej nauki, kontroli i przystosowania procesu do produktu oraz sposobu jego tworzenia. Podej- ście to opiera się na zrozumieniu tego, że poszczególne aspekty tworzenia produktu są zbyt złożone i dynamiczne, aby możliwe było przygotowanie do- kładnej i sztywnej recepty na przeprowadzenie procesu, która pozwoliłaby zapobiec konieczności ciągłego zgłaszania wątpliwości, wykazywania zaan- gażowania i udoskonalania. W dokumentach Scrum Guide i Scrum Primer kładzie się nacisk na jeden Zespół; ważne jest, by we współpracę nie było zaangażowanych zbyt wiele Zespołów. Oczywiście prowadzi to też do rozważań na temat Scruma na dużą skalę. 1 We „Wstępie” można znaleźć informację, dlaczego rozdziały zaczynają się od takiego pod- rozdziału, oraz omówienie powtarzającej się w każdym rozdziale struktury, definicje nie- których kluczowych terminów i opis konwencji. 2 5 Poleć książkęKup książkę LeSS LeSS to Scrum przystosowany do potrzeb wielu zespołów współpracujących nad jednym produktem. Zobacz: rozdział 3. „Wdrożenie”. LeSS to Scrum… — LeSS2 nie jest nowym i ulepszonym Scrumem. Nie chodzi też o wykorzystanie Scruma w poszczególnych zespołach i dodanie czegoś innego na wyższym poziomie. Chodzi raczej o to, by znaleźć sposób, jak wykorzystać zasady, cele, elementy i elegancję Scruma na dużą skalę w najprostszy moż- liwy sposób. Tak jak Scrum i inne prawdziwie zwinne frameworki, LeSS jest „zaledwie wystarczającą metodologią” z ważnych przyczyn. Skalowalny Scrum nie jest specjalnym frameworkiem do skalowania, który korzysta ze Scruma jedynie na poziomie zespołu. Prawdziwie skalowalny Scrum jest skalowalny na sposób Scruma. Zobacz: rozdział 4. „Skup się na wartości dla klienta”. …przystosowany do potrzeb wielu zespołów — wielofunkcyjne, złożone, pracujące nad wieloma komponentami całego stosu zespoły składające się z od trzech do dziewięciu skoncentrowanych na uczeniu się osób wykonują- cych wszystko — od projektowania interakcji z użytkownikiem, przez kodo- wanie, do tworzenia materiałów wideo — aby wykonać poszczególne części i cały gotowy produkt. Zobacz: rozdział 13. „Koordynacja i inte- gracja”. …współpracujących — zespoły współpracują, ponieważ mają wspólny cel, którym jest dostarczenie jednego, możliwego do dostarczenia produktu na koniec wspólnego Sprintu; każdemu zespołowi zależy na jego osiągnięciu, ponieważ jest to zespół odpowiedzialny za całość, a nie za wybraną część. Zobacz: rozdział 7. „Produkt”. …nad jednym produktem — jakim produktem? Całym, kompletnym, prze- krojowym rozwiązaniem, w którym klient jest najważniejszym punktem oraz które jest używane przez rzeczywistych klientów. Nie jest to komponent, platforma, warstwa czy biblioteka. • Tło  • W 2002 roku, gdy Craig napisał Agile Iterative Development, wiele osób było przekonanych, że metody zwinne przeznaczone są jedynie dla małych grup. Jednak my obaj (Craig i Bas) zainteresowaliśmy się tym — i zaczęliśmy 2 Akronim LeSS sugeruje zarówno stosowanie Large-Scale Scrum, jak i upraszczanie przy skalowaniu (ang. less — „mniej”). 6 2. LeSSPoleć książkęKup książkę LeSS dostawać coraz więcej próśb — by dostosować Scruma do dużych, rozpro- szonych i międzynarodowych procesów wytwarzania. Tak więc od 2005 roku połączyliśmy siły, by pracować z klientami przy skalowaniu Scruma. Dziś dwa frameworki LeSS (mniejszy LeSS i LeSS Huge) są wykorzystywa- ne w dużych grupach na całym świecie pracujących nad różnorodnymi za- gadnieniami: sprzętem telekomunikacyjnym — Ericsson i Nokia Networks3, bankami inwestycyjnymi i detalicznymi — UBS, systemami transakcyjnymi — ION Trading, platformami marketingowymi i analizowaniem marek — Vendasta, wideokonferencjami — Cisco, grami online (zakładami) — bwin.party, outsourcingiem międzynarodowym — Valtech India4. Jeśli mówimy o wielkości, pojawia się pytanie o typowy przykład zastoso- wania LeSS. Może być to pięć zespołów w jednej lub dwóch lokalizacjach. Zajmowaliśmy się projektami o takich rozmiarach, w które było zaangażo- wanych kilkaset osób, ale też nad projektami z LeSS Huge, nad którymi pra- cowało dużo ponad tysiąc osób rozproszonych w zbyt wielu lokalizacjach — osoby te pracowały nad dziesiątkami milionów wierszy kodu C++ i specjalnie projektowanym sprzętem. Więcej materiałów na temat LeSS Aby pomóc innym dzięki naszym doświadczeniom w pracy z klientami, w 2008 roku i 2010 roku opublikowaliśmy dwie książki na temat skalowania procesów zwinnych i frameworków LeSS: 1. Scaling Lean Agile Development: Thinking and Organizational Tools for Large-Scale Scrum — wyjaśnia sposób myślenia, zagadnienie przywódz- twa i zmian organizacyjnych. 2. Practices for Scaling Lean Agile Development: Large, Multi-site Offshore Product Development with Large-Scale Scrum — opisuje setki rzeczy- wistych eksperymentów z LeSS na podstawie naszych doświadczeń z klientami. Są to eksperymenty związane z zarządzaniem produktem, architekturą, planowaniem, wieloma lokalizacjami, współpracą mię- dzynarodową, kontraktami i nie tylko. 3 Nokia Networks nie jest firmą produkującą telefony komórkowe wykupioną przez Micro- soft. 4 Więcej przykładów w studium przypadku na stronie less.works. 7 Poleć książkęKup książkę Książka niniejsza — LeSS: Large-Scale Scrum — jest trzecią związaną z LeSS, ale stanowi prequel i wprowadzenie. Znajdują się w niej synteza, wyjaśnienie i podkreślenie najważniejszych zagadnień. Oprócz tych książek na stronie internetowej less.works możesz znaleźć an- glojęzyczne materiały online (w tym rozdziały książek, artykuły i filmy), kursy i porady. •  Eksperymenty, zasady, reguły,  fundamenty  • W pierwszych dwóch książkach na temat LeSS podkreślaliśmy: nie ma czegoś takiego jak zbiór dobrych praktyk w tworzeniu produktu. Można tylko wyróżnić praktyki, które są najlepsze w konkretnym kontekście. Praktyki zależą od sytuacji. Nazywanie ich w ciemno „najlepszymi” prowadzi do utraty powiązania z przyczynami ich zastosowania i kontekstem. Stają się one wówczas rytuałami. Poza tym podpieranie się tzw. najlepszymi prakty- kami zabija kulturę uczenia się, kwestionowania, zaangażowania i ciągłego udoskonalania. Dlaczego ktoś miałby podważać coś, co jest najlepsze? Dlatego w naszych wcześniejszych książkach pokazywaliśmy eksperymenty, które przeprowadzaliśmy wraz z naszymi klientami, oraz zachęcaliśmy — i dalej zachęcamy — do takiego podejścia. Z czasem jednak zauważyliśmy dwa problemy związane z podejściem opartym jedynie na eksperymentach: Początkujące grupy podejmują niekorzystne decyzje prowadzące do niewłaściwego stosowania LeSS i powstawania oczywistych proble- mów. Przykład: grupy tworzące Obszary Wymagań oddzielnie dla każ- dego zespołu. Au! Początkujące grupy pytały: „Od czego mamy zacząć? Co jest najważ- niejsze?”. Widać było, że nie potrafią dostrzec kluczowych podstaw. Korzystając z takich informacji zwrotnych, przemyśleliśmy zagadnienie i po- wróciliśmy do modelu nauczania Shu-Ha-Ri: Shu — „przestrzegając reguł, naucz się podstaw”, Ha — „łam reguły i poznawaj kontekst”, Ri — „udoskonalaj się i znajdź swoją własną drogę”. We wdrażaniu LeSS na poziomie Shu istnieje kilka reguł opisujących minimalny wystarczający framework pozwalający uru- chomić empiryczną kontrolę procesu i skupić uwagę na całym produkcie5. Te reguły definiują dwa frameworki LeSS, które niedługo zaprezentujemy. 5 Scrum także ma w swoim frameworku kilka reguł, z takich samych przyczyn jak LeSS. 8 2. LeSSPoleć książkęKup książkę LeSS Aby podsumować podstawy, na których będziemy się dalej opierali, można napisać, że LeSS zawiera: Reguły — kilka reguł pozwalających rozpocząć i utworzyć podstawy. Definiują one kluczowe elementy frameworków LeSS, które powinny być dostępne, by wspierać empiryczną kontrolę procesu i skupianie uwagi na całym produkcie. Przykładowo: „Przeprowadzaj całościową retrospektywę każdego Sprintu”. Zasady — niezbyt duży zestaw zasad pozwalających efektywnie zasto- sować reguły i pewien zbiór eksperymentów, które na podstawie lat doświadczenia z LeSS oceniamy jako warte wypróbowania. Zasady za- wierają wskazówki. Zazwyczaj są pomocne i dają pole do ciągłego udo- skonalania. Przykładowo: „Trzy zasady przystosowania”. Eksperymenty — wiele eksperymentów, które są bardzo związane z konkretną sytuacją i mogą nie być warte wypróbowania. Przykłado- wo: „Wypróbuj… Tłumacz w Zespole”. Fundamenty — zestaw fundamentalnych wytycznych — wybranych z doświadczeń przy wdrażaniu LeSS — które wspomagają reguły, zasady i eksperymenty. Przykładowo: „Skupienie na całym produkcie”. Zasady i eksperymenty LeSS są opcjonalne. Zasady będą prawdopodobnie pomocne i zalecamy ich wypróbowanie. Należy jednak ominąć lub odrzucić te, które ograniczają możliwość udoskonalania lub po prostu nie pasują. Dobrym sposobem spojrzenia na LeSS jest wizualizacja pokazana na rysunku, który nazwaliśmy „Pełnia LeSS”. 9 Poleć książkęKup książkę Z ilustracji pokazującej „Pełnię LeSS” możemy odczytać kolejność, w jakiej będziemy prezentowali LeSS: 1. Fundamenty LeSS — za chwilę. 2. Frameworki LeSS (zdefiniowane przez reguły) — w dalszej części tego rozdziału. 3. Zasady LeSS — w następnych rozdziałach tej książki. 4. Eksperymenty LeSS — zostały już omówione w pierwszych dwóch książkach na temat LeSS. • Fundamenty LeSS • Reguły LeSS tworzą framework LeSS. Jednak te reguły są minimalistyczne i nie odpowiadają na pytanie, w jaki sposób można wykorzystać LeSS w Twoim, konkretnym przypadku. Fundamenty LeSS dają podstawy pozwalające na po- dejmowanie takich decyzji. LeSS to nadal SCRUM — nie jest to nowy i ulepszony Scrum. W LeSS chodzi raczej o znalezienie sposobu na wykorzystanie podstawowych zasad, reguł, elementów i celów Scruma na dużą skalę najprościej, jak to jest możliwe. 10 2. LeSSPoleć książkęKup książkę LeSS Przejrzystość — na podstawie konkretnych, „ukończonych” elementów, krótkich cyklów, współpracy, wspólnych definicji i przy odrzuceniu obaw w miejscu pracy. Więcej dzięki mniej — nie chcemy kolejnych ról, ponieważ większa ich liczba prowadzi do zmniejszenia odpowiedzialności Zespołów. Nie chcemy kolej- nych artefaktów, ponieważ większa ich liczba powoduje zwiększenie dystan- su pomiędzy Zespołami i klientami. Nie chcemy kolejnych procesów, ponie- waż utrudnia to naukę i zmniejsza w zespole poczucie odpowiedzialności za proces. Zamiast tego chcemy bardziej odpowiedzialnych Zespołów wskutek zmniejszenia liczby ról. Chcemy, by dzięki zmniejszeniu liczby artefaktów Zespoły bardziej skupiały się na klientach i dostarczaniu im użytecznych produk- tów, a także by dzięki zmniejszeniu liczby zdefiniowanych procesów Zespoły skupiały się bardziej na własnych procesach i konkretnej pracy. Pragniemy osią- gnąć więcej, robiąc mniej. Skupienie na całym produkcie — jeden Rejestr Produktu, jeden Właści- ciel Produktu, jeden produkt do dostarczenia, jeden Sprint — niezależnie od tego, czy mamy 3 czy 33 zespoły. Klienci chcą wartościowych funkcji w spój- nym produkcie, a nie technicznych komponentów w oddzielnych częściach. Klient w centrum — skupienie uwagi na poznaniu rzeczywistych proble- mów klientów i ich rozwiązywaniu. Identyfikowanie wartości i rzeczy zbęd- nych z punktu widzenia płacących klientów. Redukowanie odczuwanego przez nich czasu oczekiwania. Zwiększanie i wzmacnianie pętli sprzężenia zwrotnego z rzeczywistymi klientami. Wszyscy rozumieją, w jaki sposób ich codzienna praca bezpośrednio wpływa na osiąganie korzyści przez płacą- cych klientów. Ciągłe udoskonalanie w dążeniu do perfekcji — cel przy dążeniu do perfek- cji można opisać tak: tworzenie i dostarczanie prawie bez przerwy — niemal bez generowania kosztów, prawie bez defektów — produktu zadowalającego klientów, pozytywnie wpływającego na środowisko i sprawiającego, że życie staje się lepsze. Wykonywanie małych i dużych eksperymentów związanych z udoskonalaniem, aby przybliżyć się do tego celu. Elastyczne myślenie — tworzenie systemów organizacyjnych, w których podstawową rolę odgrywają menedżerowie-nauczyciele wykazujący się ela- stycznością w myśleniu i uczący tej umiejętności, zarządzający w taki spo- sób, by udoskonalać, zachęcający do naprawiania zauważonych błędów (ang. stop-and-fix) oraz stosujący w praktyce podejście empiryczne (ang. Go See). Dodatkowymi dwoma filarami są szacunek dla ludzi i nastawienie na kwe- stionowanie status quo. Wszystko to ma na celu dążenie do perfekcji. 11 Poleć książkęKup książkę Myślenie systemowe — obserwowanie, rozumienie i optymalizowanie ca- łego systemu6 (a nie tylko jego części), a także korzystanie z modelowania systemów w badaniu dynamiki systemu. Unikaj lokalnego optymalizowania wydajności lub produktywności jednostek albo pojedynczych zespołów. Klientom zależy na całym cyklu i przepływie od pomysłu do zwrotu z inwe- stycji, a nie na poszczególnych krokach, a lokalne optymalizowanie części prawie zawsze pogarsza całość. Empiryczna kontrola procesów — stale badaj i dostosowuj produkt, proce- sy, zachowania, strukturę organizacyjną i praktyki w taki sposób, by ewolu- owały odpowiednio do danej sytuacji. Rób tak, zamiast działać według tzw. najlepszych praktyk, ignorujących kontekst, powodujących tworzenie rytu- ałów, hamujących uczenie się i wprowadzanie zmian oraz niszczących w lu- dziach poczucie zaangażowania i odpowiedzialności. Teoria kolejek — zrozum, w jaki sposób działają systemy z kolejkowaniem w dziedzinie R D, i wykorzystaj te spostrzeżenia do zarządzania rozmiarami kolejek, liczbą rozpoczynanych prac, wielozadaniowością, pakietami zadań i zmiennością. • Dwa frameworki: LeSS i LeSS Huge • LeSS zawiera dwa frameworki: LeSS dla dwóch – ośmiu zespołów, LeSS Huge dla więcej niż ośmiu zespołów. Określenie LeSS jest przeciążone, ponieważ opisuje zarówno Large-Scale Scrum w całości, jak i mniejszy framework LeSS. Magiczna ósemka W rzeczywistości ósemka nie jest magiczną liczbą i jeśli Twoja grupa potrafi z sukcesem wdrożyć mniejszy framework LeSS, mając więcej niż osiem ze- społów, to wspaniale! My jednak nic takiego nie widzieliśmy… jeszcze. Jest to po prostu granica określona w wyniku obserwacji empirycznych. W niektó- rych przypadkach, przy zróżnicowanych złożonych celach i niedoświadczo- nych zespołach rozmieszczonych w wielu lokalizacjach i posługujących się różnymi językami, granicą może okazać się liczba mniejsza od ośmiu. 6 Systemem jest wszystko i wszyscy zaangażowani od pomysłu do jego spieniężenia oraz wszystkie związane z tym działania w czasie i przestrzeni, zwłaszcza z punktu widzenia klienta i użytkownika. 12 2. LeSSPoleć książkęKup książkę Framework LeSS W każdym razie w pewnym momencie okazuje się, że (1) jeden Właściciel Produktu nie jest już w stanie zapanować nad całością produktu, (2) Wła- ściciel Produktu nie może zachować równowagi pomiędzy czynnikami zewnętrznymi i wewnętrznymi oraz (3) Rejestr Produktu jest tak wielki, że trudno jednej osobie nad nim pracować. Gdy grupa dotrze do takiego przełomowego punktu, może być to odpowied- ni moment na zmianę mniejszego frameworka LeSS na LeSS Huge. Z drugiej strony sugerujemy przed podjęciem decyzji o powiększeniu najpierw spróbo- wać coś poprawić, zmniejszyć czy uprościć. Części wspólne obu frameworków Frameworki LeSS i LeSS Huge mają wspólne elementy: jednego Właściciela Produktu i jeden Rejestr Produktu, jeden wspólny Sprint we wszystkich zespołach, rozbudowywanie jednego, możliwego do dostarczenia produktu. Framework LeSS • Podsumowanie frameworka LeSS • Mniejszy framework LeSS jest przeznaczony dla jednego (i tylko jednego) Właściciela Produktu, który posiada produkt oraz zarządza jednym Reje- strem Produktu, nad którym zespoły pracują w jednym wspólnym Sprincie, optymalizując cały produkt. Elementy frameworka LeSS są prawie takie same jak w Scrumie dla jednego zespołu: 13 Poleć książkęKup książkę Role — jeden Właściciel Produktu, od dwóch do ośmiu Zespołów, Mistrz Młyna dla jednego do trzech Zespołów. Zespoły te koniecznie muszą zajmować się przekrojowymi aspektami produktu — muszą być to rzeczywiście wielofunk- cyjne zespoły mogące pracować nad wieloma komponentami całego stosu aplikacji i współpracować w środowisku pozwalającym na współdzielenie kodu, z których to zespołów każdy wykonuje wszystko, co jest potrzebne do tego, by dostarczyć ukończony element. Artefakty — jedna modyfikacja produktu, którą można zapewnić, jeden Rejestr Produktu oraz oddzielny Rejestr Sprintu dla każdego Zespołu. Zdarzenia — jeden wspólny Sprint dla całego produktu; obejmuje wszystkie zespoły i kończy się dostarczeniem jednej modyfikacji produktu gotowej do dostarczenia. Szczegóły są wytłumaczone w kolejnych historiach i w oddziel- nych rozdziałach. Reguły i zasady — reguły, które zaledwie wystarczają, by uzyskać skalowal- ny framework pozwalający na empiryczną kontrolę procesów i skupienie na całym produkcie. Zasady mogą w tym pomóc. •  Historie LeSS  • Uczenie się LeSS — jednym ze sposobów uczenia się jest czytanie szczegóło- wych opisów. Czytelnicy preferujący to podejście mogą bez problemu przesko- czyć do wprowadzenia do LeSS Huge w dalszej części rozdziału, a następnie do dalszych rozdziałów. Ci, którzy lubią historie, powinni kontynuować czytanie. Proste historie — te historie nie zagłębiają się w złożoności tworzenia pro- duktów na dużą skalę — od polityki do wyznaczania priorytetów — czego doświadczamy, pracując jako konsultanci. Tym zajmujemy się w późniejszych rozdziałach. Tutaj celowo zamieszczono proste historie, które mają jedynie zaprezentować podstawy Sprintu LeSS. Jeśli szukasz zajmujących dialogów i akcji, przeczytaj książkę o metodologii lean. Reguły i zasady — w historiach zauważysz, że na marginesach znajdują się odwołania do odpowiednich reguł i zasad LeSS z wyjaśnieniami. Dwie perspektywy — dwie kolejne powiązane historie skupiają się na dwóch różnych kluczowych perspektywach, aby w prostszy sposób pokazać pewne przepływy: 1. Przepływ zespołów w Sprincie LeSS. 2. Przepływ zorientowany na elementy ważne dla klienta (funkcje). 14 2. LeSSPoleć książkęKup książkę Framework LeSS •  Historia LeSS:  Przepływ z punktu widzenia zespołów  • Ta historia skupia się na przepływie pracy w Sprincie bardziej z punktu widzenia zespołów niż z punktu widzenia pracy nad częściami produktu. W rzeczywistości większość czasu w Sprincie poświęcana jest na pracę nad produktem, a nie spotkania. W tej historii jednak skupiamy się na spo- tkaniach i interakcjach, ponieważ celem jest zrozumienie tego, w jaki spo- sób zespoły współpracują podczas zdarzeń związanych z LeSS oraz w jaki sposób koordynują pracę dzień po dniu. Zenek, wchodząc do pokoju, w którym pracuje jego Zespół (Handel), do- strzega Zuzę7. — Dzień dobry! — mówi Zuza. — Przypominam, że w tym Sprincie reprezen- tujemy zespół, a Pierwsze Planowanie Sprintu zaczyna się za 10 minut. — Dobrze, spotkajmy się w dużym pokoju — stwierdza Zenek. Wskazówka: Zmieniaj reprezentantów w każ- dym Sprincie. Pierwsze Planowanie Sprintu (Zasada: Pierwsze Planowanie Sprintu, s. 276) Nadszedł czas wspólnego Pierwszego Planowania Sprintu. W dużym po- mieszczeniu zebrało się dziesięciu reprezentantów z pięciu zespołów two- rzących grupę produktową. Wszyscy pracują nad sztandarowym produktem do handlu papierami wartościowymi i instrumentami pochodnymi. Mateusz, Mistrz Młyna dla Zespołów Handel i Marża, również jest już na miejscu. Za- mierza obserwować i w razie potrzeby odgrywać rolę coacha. REGUŁA: Istnieje jeden Sprint dla całego produktu. Nie ma od- dzielnych Sprintów dla każdego Zespołu. Wiele Sprintów wcześniej wszyscy członkowie wszystkich zespołów uczest- niczyli w każdym Pierwszym Planowaniu Sprintu. Było to lepsze rozwiąza- nie, gdy grupa nie była w stanie przygotowywać i dopracowywać kolejnych elementów, ale jednak niezbyt dobrze funkcjonował przepływ wiedzy po- między zespołami. Pierwsze Planowanie Sprintu wykorzystywano wte- dy do uzyskania odpowiedzi na wiele ważnych pytań, które to odpowiedzi powinien znać każdy. Ostatnio jednak w obszarach tych nastąpiła znaczna poprawa i teraz grupa eksperymentuje z wykorzystaniem zmieniających się reprezentantów na tym zwykłym i szybkim w tej chwili spotkaniu, na którym rozpatruje się jedynie kilka mniej ważnych pytań, zwykle pojawiających się niespodziewanie. Jeśli nowe podejście nie sprawdzi się dobrze, zostanie to prawdopodobnie poruszone na Ogólnej Retrospekcji i zostanie utworzony kolejny eksperyment na Planowaniu Sprintu. 7 Aby ułatwić zapamiętywanie osób i ich ról, imiona zaczynamy tą samą literą; np. Zuza jako reprezentantka Zespołu, Mateusz jako Mistrz Młyna, Waldek jako Właściciel Produktu. REGUŁA: Planowanie Sprintu składa się z dwóch części: Pierw- sze Planowanie Sprintu (ang. Sprint Planning One) jest wspólne dla wszystkich zespołów, podczas gdy Drugie Planowanie Sprintu (ang. Sprint Planning Two) zazwyczaj wyko- nuje się oddzielnie dla każdego zespołu. Wspólne Drugie Planowanie Sprintu we wspólnej przestrzeni można zorganizować dla zespołów pracują- cych nad bardzo powią- zanymi elementami. 15 Poleć książkęKup książkę REGUŁA: W Pierwszym Planowaniu Sprintu uczestniczy Właściciel Produktu oraz Zespoły lub reprezentanci Zespołów. Wspólnie próbują oni wybrać elementy, nad którymi każdy z zespołów będzie pracował w kolejnym Sprincie. Wchodzi Waldek, który wita się krótkim „Cześć!”. Jest on Właścicielem Pro- duktu i głównym mene- dżerem produktu8. Waldek wykłada na stół 22 karty. — Oto najważniejsze za- gadnienia: rynek niemiec- ki, zarządzanie zamówie- niami i kilka raportów dla administracji — mówi. — Wyłożyłem je w kolejności zgodnej z moimi priory- tetami. Myślę, że wszyscy tutaj rozumieją, dlaczego mamy takie priorytety, ponieważ omawialiśmy to dość szczegółowo podczas Modyfikowania Reje- stru Produktu, ale jeśli coś nie jest jasne, to pytajcie. Wskazówka: Zespoły wybierają elementy dla siebie. Zuza i Zenek podchodzą do stołu (razem z innymi reprezentantami) i wy- bierają dwie karty z elementami związanymi z papierami wartościowymi na rynku niemieckim. W ciągu ostatnich dwóch Sprintów ich zespół dopracował szczegóły tych elementów w ramach zespołowych spotkań poświęconych Modyfikacji Rejestru Produktu (ang. Product Backlog Refinement — PBR). Wybierają również dwa dodatkowe elementy związane z zarządzaniem za- mówieniami, które Zespoły Handel i Marża dość dobrze znają. Oba wspólnie pracowały na międzyzespołowych spotkaniach PBR nad tymi właśnie ele- mentami. Dlaczego? Zespoły chciały maksymalnie opóźnić podjęcie decyzji o przypisaniu elementu do zespołu, tak by decyzja ta została podjęta na jed- nym z kolejnych spotkań w ramach Planowania Sprintu. Dzięki temu zwiększa się elastyczność grup — łatwość reagowania na zmiany — a lepsza znajomość całego produktu pozwala na samodzielną organizację i koordynowanie. Minutę później Maria z Zespołu Marża, przeglądając karty innych zespołów, pyta ich reprezentantów: — Może pozwolicie nam zrobić ten raport? Robiliśmy coś podobnego w ostat- nim Sprincie i założę się, że możemy zrobić to szybciej. Może zamienicie to na element związany z rynkiem niemieckim? Zgadzają się. 8 W firmach wytwórczych rola menedżera produktu lub osoby odpowiedzialnej za mar- keting produktu — we współpracy z Zespołami — skupia się na wizji i kierunku rozwoju, wprowadzaniu innowacji, analizowaniu konkurencji oraz odkrywaniu potrzeb klientów i rynku, a także panujących na rynku trendów. W grupach tworzących produkty dla klienta wewnętrznego rola ta może być wypełniana przez głównego użytkownika z grupy, która będzie korzystała z produktu. Właściciel Produktu w Scrumie i LeSS to zazwyczaj osoba taka jak Waldemar — główny menedżer produktu — który tutaj pełni tę rolę. Więcej infor- macji na ten temat możesz znaleźć w rozdziale 8. „Właściciel Produktu”. Zasada: Międzyzespo- łowy PBR, s. 252 Wskazówka: Nie przy- pisuj zbyt wcześnie ele- mentów do zespołów. 16 2. LeSSPoleć książkęKup książkę Framework LeSS Po kilku minutach zespoły kończą wybieranie i wymianę elementów, nad któ- rymi będą pracować, biorąc pod uwagę swoje zainteresowania, silne strony i potrzeby grupy. — Zauważyłem, że Zespół Marża ma cztery elementy o najwyższym prioryte- cie — stwierdza Mateusz (Mistrz Młyna). — Czy to może stać się problemem? Wywiązuje się krótka dyskusja, która sprawia, że grupa uświadamia sobie ryzyko tego, iż jeden z elementów o najwyższym priorytecie dla produktu może nie zo- stać wykonany, jeśli w Zespole Marża coś nie pójdzie gładko. Podejmują decyzję o przeniesieniu kilku elementów o najwyższym priorytecie do innych zespołów (z uwzględnieniem tego, na czym znają się poszczególne zespoły), co zwiększa prawdopodobieństwo, że najważniejsze elementy zostaną wykonane. Zasada: Pięć narzędzi Mistrza Młyna, s. 141 Wskazówka: Elementy o najwyższym prioryte- cie rozdzielaj pomiędzy zespoły. Reprezentanci wybrali w sumie 18 kart i zostawili na stole 4 o najniższym priorytecie. Mateusz przegląda pozostawione karty z elementami i wybiera dwie z nich. — Te dwa elementy są dla mnie dość istotne w tym Sprincie — mówi. — Po- winienem chyba dać im większy priorytet. Podwyższam teraz ich priorytet. Spróbujmy wymienić je na wybrane przez was elementy o niższym priory- tecie. Oczywiście jeśli jakiemuś zespołowi uda się wcześniej skończyć pracę, może wybrać któreś z pozostawionych elementów. 17 Poleć książkęKup książkę REGUŁA: Zespoły szukają możliwości współpracy i zadawania konkretnych pytań. — Dobrze, poświęćmy teraz trochę czasu na wyjaśnianie wątpliwości — oznaj- mia później Waldek. — Jak wiecie, skupiłem się bardziej na ustalaniu prioryte- tów, a większość z was zna szczegóły poszczególnych elementów dużo lepiej ode mnie. Sprawdźmy, co możemy razem zrobić, by doprecyzować szczegóły. Wskazówka: Różnicuj, aby wyjaśniać. Jednocześnie Zuza, Zenek i inni zastanawiają się nad ostatnimi szczegóła- mi do wyjaśnienia dotyczącymi ich elementów i zapisują niektóre pytania na kartach zawieszonych na ścianach pokoju. Waldek przechodzi pomiędzy po- szczególnymi strefami, omawiając kolejne zagadnienia. Wszyscy pomagają sobie nawzajem. Po około 30 minutach znane są odpowiedzi na wszystkie szczegółowe pytania, na jakie można było odpowiedzieć. Grupa zbiera się w kręgu, by podsumować spotkanie. Nikt nie porusza żad- nego tematu związanego z koordynacją, więc w końcu odzywa się Mateusz: — Zauważyłem, że Zespoły Handel, Marża i NiePochodne wybrały elementy silnie związane z zarządzaniem zamówieniami. — Zróbmy więc wspólne Drugie Planowanie Sprintu dla Zespołów Handel, Mar- ża i NiePochodne — proponuje Zuza. — Mamy okazję wspólnie popracować. Po uzyskaniu zgody wszystkich zainteresowanych spotkanie zostaje zakoń- czone. Drugie Planowanie Sprintu dla zespołu oraz międzyzespołowe Drugie Planowanie Sprintu (Zasada: Międzyzespołowe Drugie Planowanie Sprintu, s. 280) REGUŁA: Każdy Zespół ma swój Rejestr Sprintu. Po przerwie dwa z pięciu zespołów organizują oddzielnie Drugie Planowanie Sprintu, aby utworzyć swoje Rejestry Sprintu, zaprojektować i zaplanować pracę w Sprincie. REGUŁA: Wielozespo- łowe Drugie Planowa- nie Sprintu organizuj we wspólnej przestrze- ni dla blisko powiąza- nych elementów. W odróżnieniu od nich Zespoły Handel, Marża i NiePochodne organizu- ją wspólne międzyzespołowe Drugie Planowanie Sprintu w dużym pokoju, ponieważ implementują bardzo powiązane elementy, które wcześniej też wspólnie doprecyzowywali w międzyzespołowym PBR, i oczekują korzyści ze współpracy przy ich realizacji. Wskazówka: Sesja pro- jektowania i wspólnej pracy dla całej grupy. Zasada: Bez specjal- nego oprogramowania do przechowywania Rejestru Sprintu, s. 281 18 W ciągu 10-minutowej wspólnej dyskusji ustalają punkt wyjścia i identyfikują elementy wspólne (takie same zadania) oraz problemy projektowe. Następnie przechodzą do ograniczonej czasowo 30-minutowej sesji projektowej, pod- czas której decydują, by wizualizować: więcej rysować na tablicy, a mniej oma- wiać bez rysowania. W tym czasie odkrywają więcej wspólnych elementów i wypisują je na tablicy. Ding! Po 30 minutach pozostaje wiele nieomówionych szczegółów, ale mimo to zespoły przechodzą dalej. Każdy zespół udaje się do innego rogu dużego 2. LeSSPoleć książkęKup książkę Framework LeSS pokoju, gdzie zaczyna pracę nad swoim Drugim Planowaniem Sprintu i oma- wia bardziej szczegółowe problemy projektowe oraz tworzy oddzielne Reje- stry Sprintu z kartami. Dalsza koordynacja odbywa się poprzez zaawansowa- ną odmianę stosowanej w LeSS techniki Po prostu rozmawiaj: Po prostu krzyknij. Podczas rozmowy zespoły uświadamiają sobie potrzebę przeprowadze- nia bardziej szczegółowego międzyzespołowego warsztatu projektowego. Umawiają się na takie spotkanie jeszcze tego samego dnia. Zasada: Po prostu rozmawiaj, s. 287 Międzyzespołowy warsztat projektowy (Zasada: Międzyzespołowy warsztat projektowy, s. 301) Po Planowaniu Sprintu i kolejnej przerwie Zuza i Zenon z Zespołu Handel oraz kilka osób z Zespołów Marża i NiePochodne mają ograniczony do jed- nej godziny międzyzespołowy warsztat projektowy zorganizowany w celu dopracowania wspólnego i spójnego projektu dalszej pracy. Szkicują na dużej tablicy, omawiając, doprecyzowując i uzgadniając wspólne zagadnienia pro- jektowe i techniczne. Na szczęście wnioski, do jakich dochodzą, nie wpływają znacząco na plany dotyczące Sprintu, ale czują pewien dyskomfort, ponie- waż uświadomili sobie, że mogli przewidzieć wcześniej potrzebę rozwiąza- nia pewnych poważnych kwestii projektowych. Działania produkcyjne wspierające koordynację i ciągłe dostarczanie Po Planowaniu Sprintu zespoły zajmują się tworzeniem elementów z naci- skiem na komunikację w kodzie. Wszystkie zespoły zajmują się ciągłą integra- cją. Ciągła integracja całego kodu we wszystkich zespołach daje okazję do współpracy poprzez sprawdzanie, kto jeszcze wprowadza zmiany w kompo- nencie, nad którym się pracuje. Jest to przydatne, ponieważ grupa wykorzy- stuje integrację jako sposób informowania i wspierania koordynacji. Przykładowo, na początku drugiego dnia Sprintu Zenon, programista z Ze- społu Handel, pobiera najnowszą wersję komponentu, nad którym pracują, i przegląda najnowsze zmiany z nim związane. Odkrywa zmiany w kodzie dodane przez Zbigniewa z Zespołu Marża. Wie, że tamten zespół pracuje nad blisko powiązanym elementem, dlatego nie jest specjalnie zdziwiony. Ponieważ w kodzie znajduje komunikat, że konieczne jest skoordynowanie prac, oraz informację, z kim powinien o tym porozmawiać, bez zbędnej zwłoki rusza odwiedzić Zespół Marża pracujący w innym pomieszczeniu. Po prostu rozmawiają w celu ustalenia, w jaki sposób pracować, by na bieżąco wykorzy- stywać efekty pracy wykonanej przez drugą osobę. Zasada: Komuniko - wanie w kodzie, s. 292 Zasada: Integruj ciągle, s. 293 REGUŁA: Preferuj koordynację zdecentra- lizowaną i nieformalną, a nie koordynację scentralizowaną. Zasada: Po prostu rozmawiaj, s. 287 19 Poleć książkęKup książkę Dla elementu tworzonego przez Zespół Handel oraz w zasadzie dla każdego elementu we wszystkich zespołach napisali zautomatyzowane testy akcep- tacyjne przed rozpoczęciem pisania właściwego kodu. Dlatego poza ciągłym integrowaniem kodu integrują też zautomatyzowane testy. Te testy akcep- tacyjne są często uruchamiane przez członków zespołu i jeśli dowolny z nich zgłosi błąd, zespoły natychmiast otrzymują sygnał o konieczności skoordy- nowania swoich prac. Kod mówi im: „Hej! Jest problem! Musicie pogadać i go rozwiązać!”. REGUŁA: Celem udo- skonalenia jest takie poprawienie Definicji Ukończenia, aby wy- nikiem był gotowy do dostarczenia produkt w każdym Sprincie (lub nawet częściej). Oczywiście inną dużą korzyścią ze stosowania w grupie ciągłej integracji, au- tomatyzacji testów oraz zatrzymywania się i poprawiania, gdy tylko w proce- sie budowania pojawiają się błędy, jest to, że tworzone przez grupę produkty są ciągle w mniejszym lub większym stopniu gotowe do wdrożenia produk- cyjnego. Nie ma oddzielnego zespołu odpowiedzialnego za integrację ani zespołu testującego, których praca wprowadzałaby opóźnienia, utrudnienia i komplikowałaby proces. Ogólna Retrospekcja (Zasada: Ogólna Retrospekcja, s. 317) REGUŁA: Ogólna Retro- spekcja wykonywana jest po Retrospekcjach Zespołowych, aby omó- wić problemy między- zespołowe i dotyczące całego systemu oraz aby utworzyć eksperymenty mające na celu popra- wienie sytuacji. Uczest- niczą w niej: Właściciel Produktu, Mistrzowie Młynów, Reprezen- tanci Zespołów oraz menedżerowie (jeśli są zaangażowani). Zasada: Udoskonalaj system, s. 320 Drugiego dnia Sprintu Mateusz i inni Mistrzowie Młynów, Właściciel Pro- duktu Waldemar, menedżer biura oraz reprezentanci większości zespołów zbierają się na maksymalnie 90-minutową Ogólną Retrospekcję dotyczącą ostatniego Sprintu. Dlaczego nie przeprowadzili tej Ogólnej Retrospekcji przed rozpoczęciem nowego Sprintu? Mogliby tak zrobić, ale zazwyczaj kończą Sprint w piątek, a zaczynają kolejny w poniedziałek (choć Waldek proponował, by spróbować pracy z określeniem granicy między środą a czwartkiem). W ostatni piątek zorganizowali zarówno Przegląd Sprintu, jak i Retrospekcje Zespołowe. Po tym na koniec dnia nie mieli już energii do uczestniczenia z pełnym zaan- gażowaniem w Ogólnej Retrospekcji. W tej sytuacji zdecydowali się prze- nieść spotkanie na początek kolejnego Sprintu. Prywatna opinia Mateusza jest taka, że to opóźnienie nie jest najlepszym pomysłem — wolałby opóźnić odrobinę Planowanie Sprintu i wykonać je po tym spotkaniu — chce jednak, by grupa sama do tego doszła. Uczestnicy skupiają się na systemowych problemach i udoskonaleniach: w jaki sposób koordynować prace, wymieniać się informacjami oraz rozwią- zywać problemy dotyczące całej grupy podczas Sprintu. Wcześniej próbo- wali organizować spotkania typu Scrum Scrumów, ale okazało się, że nie były one zbyt efektywne. Mateusz opisuje technikę Otwartej Przestrzeni (ang. Open Space) i wspólnie decydują, by ją wypróbować w tym Sprincie. 20 2. LeSSPoleć książkęKup książkę Framework LeSS Aktywności związane z koordynowaniem („Koordynacja i integracja”, s. 285) Czwarty dzień pokazuje różnorodność sposobów koordynowania w LeSS. W LeSS każdy Zespół zazwyczaj przeprowadza Codzienny Scrum. Aby po- prawić koordynację pomiędzy Zespołami Handel i Marża, Zuza idzie jako skaut obserwować Codzienny Scrum Zespołu Marża, po czym wraca i prze- kazuje pozyskane w ten sposób informacje swojemu zespołowi. Ktoś z Ze- społu Marża analogicznie przekazuje informacje w drugą stronę. Zgodnie z ustaleniami z Ogólnej Retrospekcji grupa organizuje mające na celu koordynację i wymianę informacji 45-minutowe spotkanie Otwarta Przestrzeń, przed którym dostarczane są napoje i przekąski. Rolę prowadzącego pełni tu- taj Mateusz, który próbuje nauczyć grupę prowadzić spotkanie Otwarta Prze- strzeń. Zaproszeni są wszyscy, ale większość zespołów decyduje, by wysłać tylko kilku reprezentantów. Zuza i Zenek z Zespołu Marża są obecni. Grupa planuje spróbować organizować spotkania Otwarta Przestrzeń raz w tygodniu. Składająca się z ochotników z większości zespołów społeczność Testy poświę- ca pół godziny na wysłuchanie propozycji Żanety na temat wypróbowania nowego narzędzia do automatyzacji testów akceptacyjnych. Z entuzjazmem się zgadzają, więc Żaneta zgłasza gotowość swojego Zespołu Marża do tego, by eksperymentalnie z tym popracować w kolejnym Sprincie, ponieważ członkowie zespołu rzeczywiście są zainteresowani poznaniem narzędzia. REGUŁA: O koordyna- cji między zespołami decydują zespoły. Zasada: Skauci, s. 307 Zasada: Otwarta Przestrzeń, s. 305 Zasada: Społeczności, s. 295 Zuza należy do społeczności Projekt/Architektura. Nie ma potrzeby organi- zowania w tym Sprincie spotkania związanego z projektem systemu doty- czącego ogólnej architektury, ale w następnym Sprincie chciałaby poświę- cić pół dnia nowej technologii. Rozsyła swój pomysł poprzez narzędzie do współpracy wykorzystywane przez społeczność i sugeruje, by popracowała nad tym cała społeczność, tak aby razem więcej się nauczyć. Wskazówka: Utwórz społeczność zajmującą się architekturą. Wygląda na to, że w systemie kompilacji pojawia się dziwny błąd. Trzeba za- trzymać się i to poprawić! W tym Sprincie odpowiedzialny jest za to Zespół Handel. Jest to jedna z dodatkowych umiejętności Zenka, dlatego zgłasza się na ochotnika do naprawy błędu i prosi inną osobę z zespołu o współpracę, dzięki której dowie się ona więcej na ten temat. Wskazówka: Zatrzymuj się i poprawiaj, jeśli zauważysz problemy. Wskazówka: Eksperci uczą innych. Później Zuza i kilka innych osób z zespołu odwiedzają grupę odpowie- dzialną za obsługę klienta i szkolenia, która blisko współpracuje z użyt- kownikami końcowymi. Zespół Zuzy ukończył swój pierwszy element i chce zebrać pierwsze informacje zwrotne od osób pracujących bliżej klientów. Jeden z trenerów ma wolny czas i sprawdza działanie nowego REGUŁA: Zagadnienia doprecyzowywane są w idealnym przypad- ku między Zespołem a użytkownikami i inny- mi interesariuszami. 21 Poleć książkęKup książkę Wskazówka: Jak najwcześniej pytaj o informacje zwrotne. Zasada: Komunikowa- nie w kodzie, s. 292 Zasada: Integruj ciągle, s. 293 mechanizmu. Zespół Handel wynosi ze spotkania kilka pomysłów na usprawnienie elementu. Później tego samego dnia Zenek i reszta Zespołu Handel wykonują zadania związane z ich drugim elementem. Zenek właśnie skończył 10-minutowy cykl TDD i ma czysty stabilny kod po mikromodyfikacji. Ponownie — co około 10 minut — wprowadza małą modyfikację do wspólnego repozytorium, aby ciągle integrować kod ze swoim zespołem i wszystkimi innymi. Zerka na duży widoczny dla wszystkich czerwono-zielony ekran na ścianie i widzi, że w sys- temie kompilacji wszystkie testy dla całej grupy kończą się sukcesem. Wspólne Modyfikowanie Rejestru Produktu (PBR) (Zasada: Rodzaje Modyfikacji Rejestru Produktu, s. 249) REGUŁA: Wykonuj międzyzespołowe i ogólne Modyfikacje Rejestru Produktu (PBR), by zwiększać ogólne zrozumienie i odkrywać możliwości koordynacji w przypadku ściśle powiązanych elementów lub gdy zachodzi potrzeba pozyskania większej ilości informacji. Piątego dnia Zenek i Zuza uczestniczą we wspólnym spotkaniu PBR z repre- zentantami innych zespołów i Waldkiem, Właścicielem Produktu. Waldek zaczyna od podzielenia się swoimi najnowszymi przemyśleniami na temat kierunku rozwoju produktu oraz tego, co będzie robione w najbliższym cza- sie i, co najważniejsze, dlaczego. Aby pomóc grupie w zrozumieniu swojego toku myślenia, przedstawia swój model wyznaczania priorytetów, który uwzględnia wpływ na zyski i klienta, ryzyko biznesowe, ryzyko techniczne, koszty opóźnień oraz inne czynniki. Wskazówka: Zmieniaj reprezentantów w każdym Sprincie. Zasada: Priorytetyza- cja przed doprecyzo- wywaniem, s. 178 Zasada: Pięć relacji, s. 180 Wskazówka: Właściciel Produktu stara się, by zespoły również czuły się właścicielami produktu. Waldek prosi grupę o komentarze i pomysły dotyczące kierunku rozwo- ju, a grupa dyskutuje nad tym, jakie elementy powinny być modyfikowane. Choć Waldek ma świadomość, że sam będzie musiał ostatecznie wyznaczyć priorytety, bardzo stara się angażować zespoły, by zrozumiały sposób jego rozumowania oraz by samemu zrozumieć sposób myślenia członków grupy. Chce, by zespoły również czuły się właścicielami produktu. Grupa dzieli następnie kilka dużych elementów, częściowo je doprecyzowu- jąc (później będą doprecyzowywane bardziej szczegółowo), i wykorzystuje pokera planistycznego raczej po to, by dowiedzieć się więcej na temat elemen- tów niż do szacowania. Reprezentanci trzech zespołów (w tym Zespołów Handel i Marża) decydują, by później wspólnie przeprowadzić PBR dla niektórych elementów — dlate- go, żeby wspólnie lepiej je zrozumieć, i dlatego, że są one ściśle powiązane. Reprezentanci dwóch innych zespołów decydują się samodzielnie skupić na wybranych elementach w zespołowych sesjach PBR. Zasada: Dzielenie, s. 260 Zasada: Skalowanie estymacji, s. 269 22 2. LeSSPoleć książkęKup książkę Framework LeSS Międzyzespołowy PBR i zespołowy PBR (Zasada: Międzyzespołowy PBR, s. 252) Szóstego dnia wszyscy członkowie trzech z sześciu zespołów zbierają się wspólnie na międzyzespołowe spotkanie PBR w dużym pokoju. Choć głównym celem biznesowym firmy jest tworzenie i sprzedaż narzędzia do prowadzenia handlu, utrzymuje ona małą grupę osób handlujących papie- rami wartościowymi i korzystających z tego narzędzia w zakresie, który wy- maga zaangażowania, ale nie wiąże się ze znaczącym ryzykiem. Dzięki temu firma ma lepszy wgląd w trendy rynkowe, a eksperci korzystający z oprogra- mowania mogą łatwiej porozumiewać się z zespołami programistów. Zajmujący się handlem Hanna i Henryk powiedzieli Waldkowi o trendzie, który wymusił modyfikację elementów w czasie międzyzespołowej sesji PBR. W tej sytuacji dołączają oni jako eksperci, by pomóc zespołom zrozu- mieć i doprecyzować szczegóły nowych elementów. Dwa inne zespoły, dyskutując z innymi osobami zajmującymi się handlem, prowadzą oddzielne spotkania PBR, aby doprecyzować szczegóły niektó- rych elementów poddawanych modyfikacjom i rozpocząć pracę nad kilkoma nowymi. Do jednego z tych zespołów dołącza również jeden z zatrudnionych przez firmę prawników specjalizujących się w prawie związanym z rynkami finansowymi, który ma pomóc w doprecyzowaniu elementów. REGUŁA: Wszystkie priorytety przechodzą przez Właściciela Produktu, ale doprecy- zowywanie, jeśli tylko to możliwe, powinno przebiegać pomiędzy Zespołami a klientem, użytkownikami i innymi interesariuszami. Ostatnim krokiem na spotkaniach PBR jest wykonanie zdjęć wszystkiego, co znajduje się na ścianach i tablicach. Dodawane są one do stron wiki wy- korzystywanych jako rejestr wszystkiego, co dotyczy każdego z elementów. Ponadto na stronach wiki aktualizowane i porządkowane są tekst i tabele, które były w pośpiechu dodawane podczas dyskusji. Zasada: Narzędzia dla dużych Rejestrów Produktu, s. 210 Wskazówka: Do opisu szczegółów elementów użyj wiki. Rozmowa na temat rejestrów utrzymywanych w zespole i Właścicieli Produktu Po międzyzespołowym warsztacie PBR Zygmunt (który właśnie został za- trudniony w firmie) dostrzega Mateusza przy automacie do kawy i podcho- dzi, żeby porozmawiać. — Cześć, Mateusz — zagaja. — Ciekaw jestem, co o tym myślisz. Podczas warsztatu PBR, który przed chwilą skończyliśmy, zauważyłem, że pracowa- liśmy bezpośrednio z kilkoma osobami zajmującymi się handlem, żeby wy- jaśnić niektóre zagadnienia. Ale czy nie zmniejsza to wydajności? W firmie, w której wcześniej pracowałem, każdy zespół miał własnego Właściciela Produktu, który pisał historie, makiety i specyfikacje, a następnie przeka- zywał je nam do implementacji. Wtedy my mogliśmy skupić się na progra- 23 Poleć książkęKup książkę mowaniu. Każdy zespół miał osobny Rejestr Produktu, w którym priorytety ustalał Właściciel Produktu dla danego zespołu. Tutaj tego nie widzę. Dla- czego tutaj jest inaczej? — Interesująca kwestia — odpowiada Mateusz. — Czy odpowiesz mi na kilka pytań, abyśmy lepiej ją zrozumieli? — Oczywiście, dawaj. — Najpierw przyjrzyjmy się jednemu Rejestrowi Produktu i porównajmy go do wielu Rejestrów Produktu — jednego dla każdego zespołu. Załóżmy, że każdy zespół ma swój własny rejestr. Jak proste i efektywne jest dla jednego Wła- ściciela Produktu śledzenie tego? I jaką wiedzę mają zespoły o wymaganiach i projektach elementów znajdujących się w rejestrach innych zespołów? — Mogę na to dość łatwo odpowiedzieć na podstawie doświadczenia wynie- sionego z firmy, w której poprzednio pracowałem — stwierdza Zygmunt. — Niewielką. — Przypuśćmy więc, że mamy osiem zespołów i osiem Rejestrów Produktu — ciągnie Mateusz. — Co się stanie, jeśli, z punktu widzenia firmy lub produktu, z ja- kiegoś powodu elementy znajdujące się w dwóch z ośmiu Rejestrów Produktu przypisanych do zespołów staną się najważniejsze i otrzymają najwyższy priory- tet? Mogła np. zmienić się sytuacja rynkowa, co doprowadziło do takich konse- kwencji. Mam dla Ciebie kilka pytań: czy pozostałe sześć zespołów, które mają w Rejestrach Produktu elementy o niższych priorytetach, może łatwo rozpocząć pracę nad elementami o wyższych priorytetach znajdującymi się w Rejestrach Produktu innych zespołów? Albo czy w ogóle grupa będzie mogła zauważyć ten problem, jeśli będzie bardzo przywiązana do sytuacji, w której każdy z zespołów ma swój własny Rejestr Produktu i swoje własne, lokalne, priorytety? — Nasze zespoły w poprzedniej firmie pracowały jedynie nad elementami znajdującymi się w ich Rejestrach Produktu. Nie mogły zajmować się innymi. Ale dlaczego w ogóle miałyby chcieć to robić? Czy to nie zmniejsza efektyw- ności? — odpowiada Zygmunt. — Z punktu widzenia firmy zespoły pracują „wydajnie” tylko nad elementami o niskich priorytetach z powodu ograniczonego zakresu wiedzy wynikają- cego ze skupienia na różnych Rejestrach Produktu dla zespołów oraz braku możliwości dostrzeżenia pełnej perspektywy ze wszystkimi priorytetami. Zadam w takim razie dodatkowe pytania: czy widzimy tutaj elastyczność i zwinność, czy też brak elastyczności? czy pozwala to na optymalizację i skie- rowanie ludzi do pracy nad najważniejszymi elementami z punktu widzenia całej firmy? — pyta z kolei Mateusz. 24 2. LeSSPoleć książkęKup książkę Framework LeSS — Aha! — odpowiada Zygmunt po chwili. — Chyba zrozumiałem. W rzeczy- wistości nie ma tutaj zwinności, choć nasza grupa mówiła, że pracuje w spo- sób zwinny. W końcu nie mogliśmy reagować na zmiany priorytetów na naj- wyższym poziomie. Nawet Właściciel Produktu w moim poprzednim zespole mówił, że ustala priorytety, biorąc pod uwagę ważność elementów w Reje- strze Produktu dla naszego zespołu. Teraz widzę, że nasz zespół wydajnie pracował nad elementami, które mogły mieć stosunkowo niewielką wartość, jeśli popatrzymy na sytuację z wyższego poziomu. — Dokładnie tak — potwierdza Mateusz. — Jest to jeden z kilku powodów, dla których tutaj mamy jeden Rejestr Produktu bez rejestrów dla poszcze- gólnych zespołów mimo tego, że pracuje tutaj wiele zespołów. Mówiąc krótko, pozwala to skupić się na całym produkcie, optymalizować cały sys- tem i pracować zwinnie. Jest to też oczywiście prostsze i ułatwia orientację w tym, co dzieje się w całej grupie. — Zauważyłem też, że w mojej poprzedniej firmie dużo trudniej było zespo- łom pracować w tym samym czasie nad tymi samymi fragmentami systemu, ponieważ mieliśmy bardzo różne cele w asynchronicznych Sprintach — dodaje Zygmunt. — Tutaj wygląda na to, że wszystkie zespoły bardziej skupiają się na wspólnym celu i podążają razem w tym samym kierunku w jednym Sprincie. — Dokładnie tak — odpowiada Mateusz. — A oto kolejne pytanie: jeśli mamy tylko jeden Rejestr Produktu i jednego prawdziwego Właściciela Produktu, który ustala priorytety, ale każdy z ze- społów nadal ma swojego „Właściciela Produktu”, który z definicji nie może ustalać priorytetów w Rejestrze Zespołu, ponieważ taki nie istnieje, to co w tej sytuacji robi on przez cały dzień? — W mojej poprzedniej firmie — odpowiada Zygmunt — Właściciel Produktu pracujący na poziomie zespołu miał za zadanie komunikować się z użytkow- nikami i pisać historie dla zespołu, tak by inni jego członkowie mogli skupić się na efektywnym programowaniu, podczas gdy zespołowy Właściciel Pro- duktu pracował nad zbieraniem i zapisywaniem wymagań. — Zygmunt, zanim poznałeś stosowane w Scrumie określenia takie jak „Wła- ściciel Produktu”, jak nazywałeś człowieka pracującego pomiędzy programi- stami i rzeczywistymi klientami — takiego, który zbiera wymagania i przeka- zuje je programistom? — pyta Mateusz. — W mojej poprzedniej firmie zatrudniłem się, zanim zaczęliśmy tam stoso- wać Scruma — odpowiada Zygmunt. — Wtedy istniała w niej grupa zajmu- jących się tym analityków biznesowych. Po wdrożeniu Scruma poproszono nas, by nazywać ich Właścicielami Produktu. REGUŁA: Istnieją jeden Właściciel Produktu i jeden Rejestr Produk- tu dla całego dostarcza- nego produktu. REGUŁA: Właściciel Produktu nie powinien samodzielnie modyfiko- wać Rejestru Produktu. Powinien korzystać ze wsparcia współpracu- jących Zespołów mają- cych kontakt bezpo- średnio z klientami lub użytkownikami i innymi interesariuszami. REGUŁA: Cała priory- tetyzacja przechodzi przez Właściciela Produktu, ale wyja- śnianie szczegółów jest przeprowadzane w takim stopniu, jak to możliwe, bezpośrednio pomiędzy Zespołami a klientami i użytkow- nikami oraz innymi interesariuszami. 25 Poleć książkęKup książkę — Czy na dzisiejszym spotkaniu PBR rozmawiałeś z osobami zajmującymi się handlem? — pyta Mateusz. — Niech sobie przypomnę — odpowiada Zygmunt. — Tak, rozmawiałem z Hanią o jej pomyśle, by przeanalizować handel rosyjskimi obligacjami kor- poracyjnymi. Wyglądało to trochę niejasno, dlatego ją o to dopytywałem. Dlaczego pytasz? Wytłumaczyła, że spowodowane to było podejrzeniami o pranie pieniędzy na kontach zagranicznych. Okazało się, że nie wiedziała ona o tym, że pracujemy właśnie nad innymi mechanizmami, które pozwolą na integrację z nowymi rządowymi bazami danych w Unii Europejskiej i USA, by rozwiązywać tego typu problemy. Zaproponowałem jej inne podejście, które według mnie lepiej pomoże rozwiązać jej problem, i ona zgodziła się z moim stanowiskiem. — Gdy teraz o tym myślę — dodaje po chwili — widzę, że to prawdopodobnie nie byłoby możliwe w mojej poprzedniej firmie, ponieważ rzadko rozmawia- liśmy bezpośrednio z użytkownikami. Więcej programowania Minuta po minucie, dzień za dniem zespoły tworzą kod, ciągle integrując zmiany i korzystając z pełnej automatyzacji testów. Zatrzymują się, by na- prawić błędy w razie problemów z kompilacją, i podążają stale w kierunku głównego celu, jakim jest utrzymywanie gotowego do dostarczenia produk- tu, który mogą w dowolnej chwili dostarczyć klientom. Dlatego, gdy Sprint zbliża się do końca i zespoły przygotowują się do Przeglądu Sprintu, nie ma spóźnionych, panicznych wysiłków, by zintegrować i przetestować duże fragmenty kodu — wszystko jest integrowane i testowane na bieżąco. Przegląd Sprintu („Przegląd i Retrospekcja”, s. 313) REGUŁA: Dla produktu wykonywany jest tylko jeden Przegląd Sprintu, wspólny dla wszystkich zespołów. W końcu nadchodzi ostatni dzień i czas na wykonanie wspólnego Przeglądu Sprintu. Kto ma to zrobić? Waldek (Właściciel Produktu, główny menedżer produktu), wszyscy zajmujący się w firmie handlem obligacjami, kilku tre- nerów i przedstawicieli działu obsługi klienta, kilka osób z działu sprzedaży oraz czterech użytkowników z firm zewnętrznych, które płacą niższe ceny za roczny abonament, ale w zamian za to regularnie uczestniczą w takich prze- glądach. Obecni są również wszyscy członkowie zespołów. 26 2. LeSSPoleć książkęKup książkę Framework LeSS Ponieważ do przejrzenia jest dużo elementów, na początku odbywa się jed- nogodzinny „bazar” — coś w stylu targów naukowych — z wieloma urządze- niami przygotowanymi do przeglądania różnych zestawów elementów. Nie- którzy członkowie zespołów czekają w wyznaczonych miejscach, by zbierać informacje zwrotne, podczas gdy wszyscy inni testują nowe mechanizmy i dyskutują na ich temat. Zasada: Przegląd w formie bazaru, s. 316 27 Poleć książkęKup książkę Wskazówka: Omów kierunek kolejnych Sprintów. Po godzinie grupa zbiera się, by razem przedyskutować pytania oraz infor- macje zwrotne pod kierunkiem Waldka. Potem wspólnie omawiają kierunek prac na przyszłość. Waldek mówi o sytuacji na rynku i u konkurencji, a także opowiada o swoich przemyśleniach na temat dalszego rozwoju i prosi o rady. REGUŁA: Każdy z Ze- społów ma oddzielną Retrospekcję Sprintu. Retrospekcje Zespołowe Po przerwie Zespół Handel (oraz 11 innych zespołów) wykonują oddzielne, zespołowe Retrospekcje Sprintu. Dochodzą do wniosku, że zorganizowa- nie wspólnego warsztatu projektowego z Zespołem Marża po Planowaniu Sprintu (a nie wcześniej) było w tej sytuacji dalekie od ideału, ponieważ do ostatniej chwili nie były znane ważne problemy, które mogły zablokować lub bardzo skomplikować programowanie. Podejmują więc decyzję, że w ko- lejnym Sprincie będą starali się podczas sesji PBR identyfikować elementy, w przypadku których pojawiają się ważne problemy projektowe do przedys- kutowania z innymi zespołami, a jeśli takie znajdą, zorganizują międzyzespo- łowy warsztat projektowy tak szybko, jak będzie to możliwe. Zakończenie Zasada: Najlepsze jest piwo belgijskie. Sprint zakończony! Mateusz zaprasza resztę Zespołu Handel, by razem z nim i Zuzą wybrali się do ulubionego baru Zuzy świętować jej urodziny. Podsumowanie Najważniejsze elementy tej historii: Podkreśla przepływ ludzi i zespołów w Sprincie w LeSS. Połączyła elementy historii z konkretnymi regułami i zasadami LeSS. Dla znających Scrum zdarzenia powinny wyglądać znajomo. Historia pokazuje, że nawet przy wielu zespołach uwaga skupiona jest na całym produkcie. Aktywności podkreślają znaczenie pozyskiwania wiedzy w zespołach oraz koordynacji. Podczas tworzenia elementów integruj zmiany w kodzie na bieżąco, tak by komunikacja w nim pozwalała na zdecentralizowaną koordynację i komunikację, niezależnie od możliwości ciągłego dostarczania. Zespoły wyjaśniają niejasności bezpośrednio z użytkownikami i klien- tami, by uprościć komunikację i zwiększyć zrozumienie, empatię i po- czucie odpowiedzialności. 28 2. LeSSPoleć książkęKup książkę Framework LeSS •  Historia LeSS: Przepływ z punktu  widzenia elementów  • W tej historii skupimy się bardziej na tym, w jaki sposób przez Sprint przechodzą poszczególne elementy (do wykonania), a zwłaszcza — na wprowadzaniu modyfikacji i programowaniu. Marta zakończyła swoje spotkanie z ekspertem rządowym i kieruje się na lotnisko, by samolotem wrócić do domu. Jest menedżerem produktu — po- maga Waldkowi, a jej specjalnością są zagadnienia związane z regulacjami prawnymi i audytem9. Później Marta spotyka się z Waldkiem. Zapisując na kartach, podsumowuje nowe zasady, które będą miały wpływ na ich pro- dukt, oraz zaznacza, któ- re elementy jej zdaniem klienci będą chcieli mieć jako pierwsze. Waldek wskazuje na pięć kart. — Czy mamy tutaj wszystkie zadania do wy- konania? — pyta. Marta uśmiecha się. — Zagadnienia związane ze stanem prawnym nigdy nie są jasne ani komplet- ne — odpowiada. — Czy mogłabyś je dopisać do Rejestru Produktu, na razie w dowolnej kolej- ności na końcu? Zasada: Pomocnicy Właściciela Produktu, s. 179 — Oczywiście. Tydzień później Waldek oznajmia Marcie: — Niedługo chcę zacząć wdrażać niektóre części dużych zmian związanych z wymaganiami prawnymi dla instrumentów pochodnych. Na spotkaniu poświę- conym Modyfikacji Rejestru Produktu (PBR) w kolejnym Sprincie zamierzam po- prosić kilka zespołów, by się tym zajęły. Ty wiesz na ten temat najwięcej, dlatego proszę, żebyś wzięła udział w ogólnym PBR oraz w spotkaniach PBR zespołów, 9 Poza głównym menedżerem produktu, który często odgrywa też rolę Właściciela Produktu, wiele większych grup ma kilku wspierających go dodatkowych menedżerów produktu, z któ- rych każdy specjalizuje się w jednym z większych segmentów rynku lub grupie klientów. Zasada: Narzędzia dla dużych Rejestrów Produktu, s. 210 Wskazówka: Arkusz kalkulacyjny i wiki pomagają utrzymywać duży Rejestr Produktu. 29 Poleć książkęKup książkę które o to cię poproszą. Czy możesz też przygotować stronę wiki z odnośnikami do nowych dokumentów prawnych, aby dostarczyć je zespołom? — To już jest gotowe — odpowiada Marta. Ogólny PBR Waldek rozpoczyna krótkie ogólne spotkanie PBR: — Mamy dużo pracy związanej z nowymi regulacjami prawnymi. Niedługo bę- dziemy musieli dostarczyć związane z nimi elementy, ponieważ prawo wchodzi w życie wraz ze zbliżającym się końcem roku podatkowego. Będziemy wiedzie- li więcej po podzieleniu pracy i dodatkowym oszacowaniu, ale nie zdziwiłbym się, jeśli konieczne okaże się wykorzystanie dodatkowych trzech lub większej liczby zespołów do implementacji oraz poświęcenie temu dodatkowego czasu. Grupy dzielą nowy, olbrzymi element na kilka dużych części, żeby zapoznać się z jego najważniejszymi modułami. Dalszy podział zostanie wykonany później na sesjach PBR w poszczególnych zespołach lub na sesjach między- zespołowych. Marta podchodzi do tablicy. Po lewej stronie pisze: „Regula- cje związane z instrumentami pochodnymi”. Następnie podczas rozmowy z grupą szkicuje drzewo z czterema odnogami reprezentującymi podział na cztery główne elementy. Nie zagłębiają się jednak w to dalej, dzięki czemu unikają wchodzenia w zbytnie szczegóły. Następnie grupa tworzy cztery karty dla nowych elementów i wszyscy ra- zem szacują ich pracochłonność za pomocą pokera planistycznego oraz względnych punktów pozwalających odnieść rozmiar nowych elementów do rozmiarów dobrze znanych elementów z Rejestru Produktu. Ich głównym celem nie jest tworzenie oszacowań, ale sformułowanie pytań i wywołanie dalszej dyskusji z Martą. — Którą z tych czterech dużych części zajmiemy się najpierw, Marto? — pyta później Waldek. Marta wskazuje na drugą kartę. — Nieregulowane instrumenty pochodne egzotycznych obligacji. — Musimy zacząć dostarczać niektóre z tych rozwiązań jak najszybciej — mówi Waldek. — Przechodzą one do Rejestru Produktu. Chciałbym, aby jeden z ze- społów zajął się częścią tego w kolejnym Sprincie. Kto jest zainteresowany? Na ochotnika zgłasza się Zespół Handel. Ostatecznie członkowie trzech innych zespołów decydują, by zorganizować wspólne spotkanie PBR dla powiązanych elementów. Zasada: Rodzaje PBR, s. 249 Zasada: Dzielenie, s. 260 Zasada: Skalowanie estymacji, s. 269 30 2. LeSSPoleć książkęKup książkę Framework LeSS Zespo
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Large-Scale Scrum. Zwinne zarządzanie dużym projektem z LeSS
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: