SKALOWANIE

ANDY BRANDT

PL

B6

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?

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.

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

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

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

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

DWA ROZWIĄZANIA DLA

„DUŻEGO SKALOWANIA”W zarządzaniu

wymaganiami

AUTONOMIA

HIERARCHIA

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.

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 -

LESS

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.

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

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

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.

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

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

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

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

SCRUM AT SCALE

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

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ę

SCRUM AT SCALE

Pętla procesowa

Zapewniać koordynację i komunikację

między zespołami.

Zbierać problemy i je rozwiązywać

usprawniając proces.

NEXUS

RECEPTY IDĄ

W DWIE STRONY

Empiryzm

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

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

ANDY@CODESPRINTERS.COM

DZĘKUJĘ