Rozszerzona wersja mojej prezentacji na temat Skalowania zawierająca m.in. pełniejsze omówienie LeSS.

1. SKALOWANIE
ANDY BRANDT
PLB6

2. 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?

3. 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.

4. 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

5. 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

6. 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

7. Wymagania Komunikacja Produkt
1
2
3
Moduł 1
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
saf
Moduł 2
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
DIABEŁ TKWI W
WYMAGANIACH
PRODUKT
4
1
2
3
4

8. DWA ROZWIĄZANIA DLA
„DUŻEGO SKALOWANIA”W zarządzaniu
wymaganiami

9. AUTONOMIA

10. HIERARCHIA

11. 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.

12. 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 -

13. LESS

14. 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.

15. 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ę.

16. 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

17. 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.

18. 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).

19. 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

20. 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

21. 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

23. SCRUM AT SCALE

24. 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ŚĆ

25. 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ę

26. SCRUM AT SCALE
Pętla procesowa
Zapewniać
koordynację i
komunikację
między zespołami.
Zbierać problemy i je
rozwiązywać
usprawniając proces.

27. NEXUS

28. RECEPTY IDĄ
W DWIE STRONY
Empiryzm

29. 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

30. 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

31. ANDY@CODESPRINTERS.COM
DZĘKUJĘ