Skalowanie Agile dla ALE Krakow

SKALOWANIEMODEL I PRZEGLĄD METOD

ANDY BRANDT

PL B

6

OBOWIĄZKOWY SLAJD

O SOBIE

• PRAKTYK AGILE OD 2006 ROKU

• OD 2007 ROKU ZWIĄZANY Z CODE SPRINTERS – LIDEREM SZKOLEŃ I

DORADZTWA W OBSZARZE AGILE

• OD 2010 PIERWSZY POLSKI PROFESSIONAL SCRUM TRAINER

• OBECNIE KONSULTANT, COACH, MENTOR

• AUTOR „AGILE W PRAKTYCE”

• HTTP://PRAGMATICLEADER.NET/

@ANDYBRANDT NA TWITTER

http://agileszkolenia.pl/

https://leanpub.com/Agile_w_Praktyce

http://pragmaticleader.net/

https://twitter.com/andybrandt



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

MODEL

2 wymiary4 obszary

• JEST TO MODEL POMAGAJĄCY W ROZUMIENIU PROBLEMU I

PORÓWNYWANIU METOD SKALOWANIA

• MOŻE BYĆ UŻYTY DO ANALIZY JAKIE PRAKTYKI SĄ STOSOWANE W

KAŻDYM Z OBSZARÓW – LUB JAKIE NALEŻY WPROWADZIĆ

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

• Zwykle nie

wystarcza jeden PO

• Konieczne jakieś

dzielnie produktu na

moduły/obszary

Produkt

TEAM 1

TEAM 2

TEAM 3

TEAM 4

Produkt

Efsdfsdfsdfs

Sdfsdfsdfsdfs

SfsdfsdfsFsdfsdfsadfsadfsa

Fsadfasfsadfasdfasd

Sadfsadfasdfasdfasdfsadfsad

Safdsadfsadfsadvadf 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

OB

SZ

AR

Y

SK

ALO

WA

NIA

OBSZAR PRODUKTU

• CEL: ZAPEWNIĆ, BY PRODUKT JAKO CAŁOŚĆ DZIAŁAŁ NA KONIEC KAŻDEJ ITERACJI (SPRINTU)

• KONCEPCYJNIE JEDYNE DOBRE ROZWIĄZANIE TO CIĄGŁA INTEGRACJA (CONTINUOUS INTEGRATION).

• WYMAGA:

• ŚRODOWISKA CI (OPROGRAMOWANIE, CZASEM TAKŻE SPRZĘT)

• DOBRE POKRYCIE TESTAMI AUTOMATYCZNYMI (PIRAMIDA TESTÓW ITP.)

• KROSFUNKCJONALNOŚĆ ZESPOŁU

• REGUŁY (NAJLEPIEJ POWSTAŁE W ZESPOŁACH) I DYSCYPLINA W ICH STOSOWANIU

• JEŚLI CZEGOŚ TU BRAK:

• AUTOMATYZACJA TESTÓW FUNKCJONALNYCH DOBRYM POMYSŁEM JAK UZYSKAĆ SZYBKI FEEDBACK

DLA DEVELOPERÓW ZANIM POKRYCIE TESTAMI JEDNOSTKOWYMI BĘDZIE ODPOWIEDNIE

• ZMNIEJSZENIE ILOŚCI PRACY W SPRINCIE, MARGINESY NA INTEGRACJĘ, „ZESPÓŁ INTEGRACYJNY” ITP.

• JEŚLI OSIĄGNIĘCIE PEŁNEGO CI NIE JEST MOŻLIWE:

• ZBUDOWAĆ ZAŚLEPKI/MAKIETY I STOSOWAĆ CI DO NICH

• ROZWAŻYĆ „SPRINTY INTEGRACYJNE”

Produkt

Ważne: utrzymywać empiryzm poprzez przejrzystość

produktu – przestrzegane, znane Definition of Done.

Komunikacja Produkt

TEAM 1

TEAM 2

TEAM 3

TEAM 4

Produkt

Efsdfsdfsdfs

Sdfsdfsdfsdfs


Fsadfasfsadfasdfasd







adfasdfsadfsadf saf

OB

SZ

AR

Y

SK

ALO

WA

NIA

OBSZAR KOMUNIKACJI

• CEL: ZESPOŁY KOMUNIKUJĄ SIĘ ZE SOBĄ I ROZWIĄZUJĄ POJAWIAJĄCE SIĘ

PROBLEMY NA BIEŻĄCO (PODCZAS ITERACJI/SPRINTÓW)

• PRAKTYKI W TYM OBSZARZE KONCENTRUJĄ SIĘ NA WSPOMAGANIU I

STYMULOWANIU KOMUNIKACJI I KOORDYNACJI. PRZYKŁADY:

• SCRUM OF SCRUMS – PODSTAWOWA, WCIĄŻ STOSOWANA PRAKTYKA

• KOMPETENCYJNE STRUKTURY POZIOME(RÓŻNE NAZWY I SZCZEGÓŁOWE ROZWIĄZANIA – ACOP, TRIBES, TECH GROUP ETC.)

• WSPÓLNE PLANOWANIA, PRZEGLĄDY I PIELĘGNACJE (REFINEMENTS) BACKLOGU, WSPÓLNE RETROSPEKCJE (POZA TYMI W ZESPOŁACH)(RÓŻNE SZCZEGÓŁOWE PRAKTYKI – LESS ZAWIERA DUŻO DOBRYCH POMYSŁÓW W TYM OBSZARZE)

• WSPÓLNE STANDARDY TECHNICZNE

• WSPOMAGAJĄCE: INNE SPOTKANIA PONAD ZESPOŁAMI, ODPOWIEDNIE PRZESTRZENIE DLA

ZESPOŁÓW (WSPÓLNE PRZESTRZENIE, PROMIENNIKI INFORMACJI ITP.).

Komunikacja

Wymagania Komunikacja Produkt

TEAM 1

TEAM 2

TEAM 3

TEAM 4

Produkt

Efsdfsdfsdfs

Sdfsdfsdfsdfs


Fsadfasfsadfasdfasd







adfasdfsadfsadf saf

OB

SZ

AR

Y

SK

ALO

WA

NIA

OBSZAR WYMAGAŃ

• CEL: ZAPEWNIĆ DOSTARCZENIE WSZYSTKIM ZESPOŁOM WYMAGAŃ,

KTÓRE W SUMIE DADZĄ WARTOŚCIOWY, UŻYWALNY PRODUKT CO

ITERACJĘ (SPRINT)

• PRZY MAŁYM SKALOWANIU PRAKTYCZNIE BRAK RÓŻNIC W STOSUNKU

DO JEDNEGO ZESPOŁU – JEDEN PO, JEDEN BACKLOG.

Wymagania


1

2

3Moduł 1

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

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)

• ZWYKLE TRUDNOŚĆ W CZĘSTYM

WYDAWANIU PRODUKTU (TRUDNIEJSZE

TESTOWANIE, TWORZENIE

PRZYROSTÓW) – „AGILEFALL”

• DE FACTO OGRANICZONE

MOŻLIWOŚCI PO PRZY TEAMACH, HIERARCHIA POWODUJE, ŻE PO STAJĄ

SIĘ ARCHITEKTAMI, ANALITYKAMI ITP.

• DLA WIELU ORGANIZACJI TO

NIESTETY JEDYNA MOŻLIWOŚĆ

AUTONOMIA

• MODULARNA ARCHITEKTURA

PRODUKTU (ZBIÓR MNIEJSZYCH

PRODUKTÓW)

• ZWYKLE CZĘSTE WYDANIA,

DOJRZAŁOŚC PRAKTYK TECHNICZNYCH,

OBSZARU PRODUKTU (CI ITP.)

• SILNY NACISK NA PRAKTYKI W

OBSZARZE KOMUNIKACJI

• PO WSPÓŁPRACUJĄ LUŹNO (BRAK

PODLEGŁOŚCI), MOŻLIWE

WYSOKOPOZIOMOWE METRYKI

PRODUKTOWE LUB PER OBSZAR


TEAM 1

TEAM 2

TEAM 3

TEAM 4

Produkt

Efsdfsdfsdfs

Sdfsdfsdfsdfs


Fsadfasfsadfasdfasd







adfasdfsadfsadf saf

CZ

WA

RT

Y O

BS

ZA

R

Biznes

OBSZAR BIZNESU

• CEL: WYKORZYSTAĆ AGILE BIZNESOWO

• PRAKTYKI W TYM OBSZARZE POLEGAJĄ NA PRZEKŁADANIU

ZDOLNOŚCI METOD AGILE DO CZĘSTYCH WYDAŃ I ZMIAN NA

PRZEWAGĘ CZY KORZYŚCI NA RYNKU

• LEAN STARTUP & RODZINA

• EVO – TOM GILB – ROZWIJANIE PRODUKTÓW TAK BY OSIĄGNĄĆ

ZKWANTYFIKOWANE CELE BIZNESOWE

• ŁĄCZENIE Z PROJEKTAMI – LEAN PROJECT CARD, PRE-PROCESS

ETC.

PODSUMOWANIE

MODELU

• SKALOWANIE JEST PROBLEMEM INNEGO KALIBRU PRZY KILKU

ZESPOŁACH (MAŁE SKALOWANIE) NIŻ GDY JEST ICH DUŻO WIĘCEJ (DUŻESKALOWANIE)

• W KAŻDYM PRZYPADKU MAMY TRZY OBSZARY, W KTÓRYCH MUSZĄ BYĆ

WDROŻONE ODPOWIEDNIE PRAKTYKI – PRODUKT, KOMUNIKACJA I

WYMAGANIA

• Z NICH OBSZAR WYMAGAŃ JEST NAJTRUDNIEJSZYM, Z NAJWIĘKSZĄ

RÓŻNORODNOŚCIĄ ROZWIĄZAŃ, NAJBARDZIEJ ZALEŻNYM OD KONTEKSTU

• PRAKTYKI POZWALAJĄCE NA WYKORZYSTANIE TEGO CO DAJE AGILE

BIZNESOWO TO CZWARTY OBSZAR SKALOWANIA – BIZNES.

GOTOWE „RECEPTY” NA

SKALOWANIE?

• LARGE SCALE SCRUM (LESS) BY CRAIG LARMAN AND BAS VODDE –

HTTP://LESS.WORKS

• 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…

http://less.works/

http://scaledagileframework.com/

http://www.scruminc.com/scrum-at-scale-part-i/

LESS

Large Scale Scrum

• Próba zachowania istoty

Scruma w większej skali

• Proste modyfikacje ze

wzgledu na skale

• Model Large i Huge

(odzwierciedlenie

wymiarów skalowania)

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

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.

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 HTTP://SCRUMPLOP.ORG

• CAŁOŚĆ DZIAŁA W OPARCIU O STEROWANĄ METRYKAMI PRZEJRZYSTOŚĆ

http://scrumplop.org/

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

CZY WARTO SIĘGAĆ

PO POMOC?

• KONSULTANCI I COACHE PRZYNOSZĄ:

• ZEWNĘTRZNE SPOJRZENIE NA WASZE PROBLEMY

• WIEDZĘ O ISTNIEJĄCYCH METODACH I PRAKTYKACH

• DOŚWIADCZENIE

• OPARTE NA NIM PRZEKONANIE, ŻE MOŻNA („DA SIĘ”)

• CHYBA WARTO

[email protected]

DZĘKUJĘ

mailto:[email protected]

Skalowanie Agile dla ALE Krakow

Leadership & Management

Transcript of Skalowanie Agile dla ALE Krakow