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
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 -
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
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.
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
In an Overall Retrospective, the systemic and organizational issues explored are above the level of a single team. Topics that might be discussed in an Overall Retrospective are:
How well are the teams working together?
Are the Communities of Practice working?
Is there something that a team did that should be shared?
Are the teams learning together?
Are teams close to customers?
Are there systemic organizational issues that cause problems in how teams operate?
Is the Product Owner doing well?
Is the Product Owner maintaining his five relationships?