Skalowanie Agile - rozszerzona wersja
-
Upload
andy-brandt -
Category
Leadership & Management
-
view
248 -
download
8
Transcript of Skalowanie Agile - rozszerzona wersja
![Page 1: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/1.jpg)
SKALOWANIE
ANDY BRANDT
PL
B6
![Page 2: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/2.jpg)
PO CO CHCEMY
SKALOWAĆ?
• BY ROBIĆ WIĘCEJ?
• BY ROBIĆ SZYBCIEJ?
• BY ZDĄŻYĆ NA JAKIŚ TERMIN?
• BO MAMY DUŻO LUDZI I ZAKŁADAMY, ŻE WSZYSCY SĄ POTRZEBNI?
![Page 3: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/3.jpg)
ZANIM DODASZ
KOLEJNY ZESPÓŁ…
• WYKORZYSTAĆ REZERWY WYDAJNOŚCI W ISTNIEJĄCYM ZESPOLE.
• PRZEMYŚLEĆ ZAKRES, UNIKAĆ BUDOWANIA RZECZY ZBĘDNYCH (W.G.
BADAŃ JEDEN Z GŁÓWNYCH CZYNNIKÓW MARNOTRAWSTWA).
• BRAĆ POD UWAGĘ, ŻE ZWIĘKSZANIE ZESPOŁÓW NIESIE ZA SOBĄ
PROBLEMY, KTÓRE PRZYRASTAJĄ Z WIELKOŚCIĄ SZYBCIEJ NIŻ
KORZYŚCI. KORZYŚĆ Z KAŻDEJ KOLEJNEJ DODANEJ OSOBY DO JEST
CORAZ MNIEJSZA.
![Page 4: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/4.jpg)
CO TO JEST
SKALOWANIE AGILE?
• ZWINNOŚĆ (ANG. AGILITY) – ZDOLNOŚĆ DO SZYBKIEJ LECZ
PRZEMYŚLANEJ ZMIANY.
• POLEGA NA DOSTOSOWANIU PRODUKTU [INFORMATYCZNEGO] DO
ZMIENIAJĄCYCH SIĘ WYMAGAŃ BEZ OBNIŻANIA JEGO JAKOŚCI.
• SKALOWANIE TO ROZWIĄZANIE PROBLEMU – JAK UTRZYMAĆ
ZWINNOŚĆ I INNE KORZYŚCI AGILE (SCRUM, KANBAN ITD.) PRZY
WIELU ZESPOŁACH.
Łatwość zmiany
wymagań
Mniej przykrych
niespodzianek
Wysoka wydajność
zespołówZaagnażowanie
Szybki feedback z
rynku
Wysoka jakość
Częste wydania
Dobra relacja z
biznesem
![Page 5: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/5.jpg)
WYMIARY SKALOWANIA
1
2
3
4
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
MAŁE SKALOWANIE
• Do ~55 osób, 4-6
teamów max.
• Wiele problemów
można nadal
rozwiązać
spotykając się całą
grupą
• Wystarcza jeden
backlog i jeden PO
DUŻE SKALOWANIE
• Więcej osób, wiele
teamów
• Konieczne jakieś
dzielnie produktu na
moduły/obszary
• Nie wystarcza jeden
PO
![Page 6: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/6.jpg)
Wymagania Komunikacja Produkt
ZESPÓŁ
1
ZESPÓŁ
2
ZESPÓŁ
3
ZESPÓŁ
4
Produkt
Efsdfsdfsdfs
Sdfsdfsdfsdfs
Sfsdfsdfs
Fsdfsdfsadfsadfsa
Fsadfasfsadfasdfasd
Sadfsadfasdfasdfasdfsadfsad
Safdsadfsadfsadvadf sav
af asd asdvc asdvc dsfv
Sdf vsdfv dsfv sdf vasf
Asv asdf sadf asdfdsafd
V adfv adfvfdv sdfv dfv f a
adfv dfv dafv dfavadfv
asdfa sdfsaf asdf asdf asdf
adfasdfsadfsadf saf
![Page 7: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/7.jpg)
Wymagania Komunikacja Produkt
1
2
3Moduł 1
EfsdfsdfsdfsSdfsdfsdfsdfsSfsdfsdfsFsdfsdfsadfsadfsaFsadfasfsadfasdfasdSadfsadfasdfasdfasdfsadfsadSafdsadfsadfsadvadf savaf asd asdvc asdvc dsfvSdf vsdfv dsfv sdf vasf Asv asdf sadf asdfdsafd V adfv adfvfdv sdfv dfv f aadfv dfv dafv dfavadfv asdfa sdfsaf asdf asdf asdf
saf
Moduł 2
EfsdfsdfsdfsSdfsdfsdfsdfsSfsdfsdfsFsdfsdfsadfsadfsaFsadfasfsadfasdfasdSadfsadfasdfasdfasdfsadfsadSafdsadfsadfsadvadf savaf asd asdvc asdvc dsfv
Sdf vsdfv dsfv sdf vasf Asv asdf sadf asdfdsafd V adfv adfvfdv sdfv dfv f aadfv dfv dafv dfavadfv asdfa sdfsaf asdf asdf asdf adfasdfsadfsadf saf
DIABEŁ TKWI W
WYMAGANIACH
PRODUKT4
1
2
3
4
![Page 8: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/8.jpg)
DWA ROZWIĄZANIA DLA
„DUŻEGO SKALOWANIA”W zarządzaniu
wymaganiami
![Page 9: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/9.jpg)
AUTONOMIA
![Page 10: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/10.jpg)
HIERARCHIA
![Page 11: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/11.jpg)
ZESTAWIENIE
HIERARCHIA
• MONOLITYCZNY PRODUKT
(DUŻO ZALEŻNOŚCI)
• DE FACTO OGRANICZONE
MOŻLIWOŚCI PO PRZY TEAMACH
• ZWYKLE TRUDNOŚĆ W
CZĘSTYM WYDAWANIU PRODUKTU
(TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTÓW)
• DLA WIELU ORGANIZACJI TO
NIESTETY JEDYNA MOŻLIWOŚĆ
AUTONOMIA
• MODULARNA ARCHITEKTURA
PRODUKTU
• ZESPOŁY ODPOWIEDZIALNE ZA
OBSZARY FUNKCJONALNE, NIE
KOMPONENTY TECHNOLOGICZNE
• POS WYSTARCZĄ OGÓLNE
UZGODNIENIA CO DO KIERUNKU ROZWOJU
• MODUŁY WYDAWANE NIEZALEŻNIE
• WYMAGA NIE TYLKO ODPOWIEDNIEJ
ARCHITEKTURY PRODUKTU ALE I
ORGANIZACJI.
![Page 12: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/12.jpg)
RECEPTY NA
SKALOWANIE?
• LARGE SCALE SCRUM (LESS) BY CRAIG LARMAN AND BAS VODDE –
HTTP://WWW.CROSSTALKONLINE.ORG/STORAGE/ISSUE-
ARCHIVES/2013/201305/201305-LARMAN.PDF
• SCALED AGILE FRAMEWORK (SAFE) BY DEAN LEFFINGWELL -
HTTP://SCALEDAGILEFRAMEWORK.COM
• SCRUM AT SCALE – MODUŁOWA METODA SKALOWANIA JEFFA
SUTHERLANDA - HTTP://WWW.SCRUMINC.COM/SCRUM-AT-SCALE-
PART-I/
• NEXUS – METODA SKALOWANIA KENA SCHWABERA -
![Page 13: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/13.jpg)
LESS
![Page 14: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/14.jpg)
LESS LARGE
• Do 8 zespołów po max. 8 osób każdy. Każdy
zespół krosfunkcjonalny, stały, z dedykowanymi
członkami.
• Nadal jeden Product Owner i jeden Backlog
Produktu (produkt jest przecież wciąż jeden).
• Wielu Scrum Masterów (zależnie od potrzeb)
• Wspólne sprinty o tej samej długości.
• Wspólne DoD i jeden produkt (przyrost) na koniec
sprintu.
• Planowanie sprintu w dwóch etapach – pierwszy
wspólny, drugi osobno.
• Wspólny przegląd sprintu.
• Oddzielne retrospekcje po czym wspólna
retrospekcja.
![Page 15: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/15.jpg)
LESS LARGE
PLANOWANIE SPRINTU
• Planowanie Sprintu cz. 1 – PO + 2 delegatów z
każdego z zespołów (>2 zespoły), SM nie może być
delegatem
• PO prezentuje backlog, zespoły (delegaci) wybierają
i dzielą wymagania między sobą.
• Omawia się wszelkie wątpliwości i pytania, jeśli
potrzebna jest ściślejsza koordynacja między jakimiś
zespołami możliwe jest zaplanowanie drugiej części
z wieloma zespołami
• Planowanie sprintu cz. 2 – każdy zespół osobno,
najczęściej równolegle.
• Jeśli jakieś dwa-trzy zespoły pracują nad zbliżonym
obszarem – mają duże zależności – odbywają cz. 2
jednym miejscu, co ułatwia koordynację.
![Page 16: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/16.jpg)
LESS LARGE
PIELĘGNACJA BACKLOGÓW
• Ogólna pielęgnacja• PO, delegaci zespołów, ew. eksperci
• Relatywnie krótka
• Rozbija się duże wymagania (epics)
• Wstępna zgrubna analiza
• Szacowanie
• Identyfikowanie wymagań wymagających większej
koordynacji przy pielęgnacji i realizacji
• Pielęgnacja w zespołach (5-10% sprintu)• Dla PBI, które będzie robił jeden zespół robi on
również dalszą dekompozycję i analizę, informując PO
o zmianach w backlogu (zmiana oszacowań, nowe
elementy w wyniku dekompozycji).
• Pielęgnacja wieloma zespołami dla wymagań
bardziej skomplikowanych – całe teamy lub delegaci,
niekoniecznie wszystkie teamy
![Page 17: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/17.jpg)
LESS LARGE
DAILY & SOS
• Daily Scrum wygląda tak samo jak „zwykłym”
Scrumie poza tym, że mogą w nim uczestniczyć
przedstawiciele innych zespołów jako obserwatorzy.
• Zaleca się stosowanie Scrum of Scrums (typowo 2-3
razy na tydzień) lub podobnych technik z obszaru
komunikacji np. spotkania Open Space, CoP lub
„guardians”.
• Zasada „just talk” i znaczenie komunikacji poprzez
sam kod.
![Page 18: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/18.jpg)
LESS LARGE
PRZYROST I DOD
• Integracja musi zostać wykonana podczas sprintu –
wszystkie zespoły dostarczają wspólnie jeden
przyrost.
• Zespoły mają wspólne Definition of Done.
• Definition of Done powinno być możliwie zbliżone do
„Ready to Release” (gotowy do wydania).
![Page 19: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/19.jpg)
LESS LARGE
PRZEGLĄD I RETROSPEKCJA
• Przegląd wspólny [2h]
• Produkt jest jeden, interesariusze wspólni
• Format tradycyjny dla 2 zespołów
• Przy większej liczbie format delegatów albo
format „targów”
• Retrospekcja dwuetapowa
• Część usprawnień jest na poziomie zespołów,
część dotyczy całości
• Retrospekcja w zespołach tak jak w Scrum [2h]
• Ogólna retrospekcja – PO, SM, delegaci
zespołów, skupia się na wspólnych tematach
• Ogólna retrospekcja może odbywać się na
początku kolejnego sprintu
![Page 20: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/20.jpg)
LESS HUGE
• Złożenie wielu obszarów LeSS Large
• Zachowany jeden PO, jeden główny
backlog, jedno DoD i jeden produkt
(inkrement)
• Pojawiają się obszary i APO (Area PO)
• Obszary są zdefiniowane kliento-
centrycznie, funkcjonalnie i mogą być
zmienne w czasie (ale nie w sprincie)
• Pojawiają się obszary w backlogach
• Pojawiają się backlogi wyższego i
niższego rzędu
![Page 21: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/21.jpg)
LARGE SCALE SCRUM
• TWÓRCOM PRZYŚWIECAŁA IDEA ZACHOWANIA ISTOTY SCRUMA W
WIĘKSZEJ SKALI
• DZIAŁANIE W WIĘKSZEJ SKALI OSIĄGNIĘTE PRZEZ RELATYWNIE
PROSTE DODATKOWE PRAKTYKI I WYDARZENIA ZWIĄZANE ZE
SKALOWANIEM
• EFEKT DŁUGIEJ EWOLUCJI, SPRAWDZONY W BARDZO DUŻYCH I
ZŁOŻONYCH PRODUKTACH
![Page 22: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/22.jpg)
![Page 23: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/23.jpg)
SCRUM AT SCALE
![Page 24: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/24.jpg)
SCRUM AT SCALE
• SKALOWANIE POSTRZEGANE JAKO ORGANICZNY ROZWÓJ STEROWANY
EMPIRYCZNIE ZGODNY Z KONTEKSTEM KONKRETNEJ FIRMY
• DWA ZASADNICZE PROCESY – PĘTLA PRODUKTOWA (PRODUCT OWNER
LOOP) I PĘTLA PROCESOWA (SCRUM MASTER LOOP)
• W KAŻDYM Z PROCESÓW RÓŻNE „MODUŁY” – RZECZY, KTÓRE MUSZĄ
BYĆ ZROBIONE – KONKRETNE „MODUŁY” SĄ OBECNE NA RÓŻNYCH
POZIOMACH ORGANIZACJI
• DLA KAŻDEGO Z MODUŁÓW PUBLICZNIE DOSTĘPNA BIBLIOTEKA
KONTEKSTOWO OPISANYCH PRAKTYK
• CAŁOŚĆ DZIAŁA W OPARCIU O STEROWANĄ METRYKAMI PRZEJRZYSTOŚĆ
![Page 25: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/25.jpg)
SCRUM AT SCALE
Pętla produktowa
Przełożyć wizję na wymagania,
zdekomponować je i dostarczyć do
zespołów
Dostarczyć (zintegrowany) przyrost
produktu klientom
Zebrać reakcje klientów, przeanalizować i w razie
potrzeby dostosować wizję
![Page 26: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/26.jpg)
SCRUM AT SCALE
Pętla procesowa
Zapewniać koordynację i komunikację
między zespołami.
Zbierać problemy i je rozwiązywać
usprawniając proces.
![Page 27: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/27.jpg)
NEXUS
![Page 28: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/28.jpg)
RECEPTY IDĄ
W DWIE STRONY
Empiryzm
![Page 29: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/29.jpg)
NIM ZAPYTASZ
„CO WYBRAĆ”?
• PO CO CHCECIE WPROWADZAĆ METODY AGILE NA DUŻĄ SKALĘ W
FIRMIE/PROJEKCIE/DZIALE/ETC.?
• JAKI JEST STAN WYJŚCIOWY?
• KSZTAŁT PRODUKTU – ARCHITEKTURA, STAN KODU
• MOŻLIWOŚCI ZESPOŁÓW
• OBECNE STRUKTURY I KULTURA ORGANIZACJI
• CZY JUŻ WYKORZYSTANO ISTNIEJĄCE REZERWY USPRAWNIEŃ W
JEDNYM ZESPOLE?
• POZIOM ODWAGI – LUB KONIECZNOŚCI
![Page 30: Skalowanie Agile - rozszerzona wersja](https://reader031.fdocuments.net/reader031/viewer/2022020110/55a80b881a28abba118b460a/html5/thumbnails/30.jpg)
O CZYM NALEŻY
PAMIĘTAĆ
• WSZYSTKIE METODY I PRAKTYKI ZWINNE SĄ ZASTOSOWANIEM
EMPIRYZMU DO TWORZENIA OPROGRAMOWANIA
• EMPIRYZM NIE MOŻE BYĆ Z GÓRY ZAPLANOWANY – TO
PRZECIWIEŃSTWO PODEJŚCIA PREDYKCYJNEGO
• ZMIANY PROCESU I KULTURY NIE DA SIĘ DO KOŃCA NARZUCIĆ ODGÓRNIE
• PROCES EMPIRYCZNY NIE MA STANU KOŃCOWEGO
• KAŻDA METODA JEST KROKIEM KU DALSZEMU ROZWOJOWI
• SAM PROCES NA POZIOMIE STRUKTURY I ZARZĄDZANIA NIE WYSTARCZY, NIEZBĘDNE SĄ ODPOWIEDNIE PRAKTYKI TECHNICZNE