Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Skalowanie Agile dla ALE Krakow

1,611 views

Published on

W prezentacji:
- mój model skalowania Agile (2 wymiary, 4 obszary)
- omówienie wiodących "gotowych recept"

Published in: Leadership & Management
  • Be the first to comment

  • Be the first to like this

Skalowanie Agile dla ALE Krakow

  1. 1. SKALOWANIE MODEL I PRZEGLĄD METOD ANDY BRANDT PLB6
  2. 2. 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
  3. 3. 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
  4. 4. MODEL 2 wymiary 4 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Ć
  5. 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 • Zwykle nie wystarcza jeden PO • Konieczne jakieś dzielnie produktu na moduły/obszary
  6. 6. Produkt TEAM 1 TEAM 2 TEAM 3 TEAM 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 OBSZARY SKALOWANIA
  7. 7. 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.
  8. 8. Komunikacja Produkt TEAM 1 TEAM 2 TEAM 3 TEAM 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 OBSZARY SKALOWANIA
  9. 9. 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
  10. 10. Wymagania Komunikacja Produkt TEAM 1 TEAM 2 TEAM 3 TEAM 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 OBSZARY SKALOWANIA
  11. 11. 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
  12. 12. 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 Asvasdf 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 Asvasdf 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
  13. 13. DWA ROZWIĄZANIA DLA „DUŻEGO SKALOWANIA”W zarządzaniu wymaganiami
  14. 14. AUTONOMIA
  15. 15. HIERARCHIA
  16. 16. 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
  17. 17. Wymagania Komunikacja Produkt TEAM 1 TEAM 2 TEAM 3 TEAM 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 CZWARTYOBSZAR Biznes
  18. 18. 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.
  19. 19. PODSUMOWANIE MODELU • SKALOWANIE JEST PROBLEMEM INNEGO KALIBRU PRZY KILKU ZESPOŁACH (MAŁE SKALOWANIE) NIŻ GDY JEST ICH DUŻO WIĘCEJ (DUŻE SKALOWANIE) • 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.
  20. 20. 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…
  21. 21. 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)
  22. 22. 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.
  23. 23. 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ę.
  24. 24. 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
  25. 25. 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.
  26. 26. 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).
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. SCRUM AT SCALE
  31. 31. 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ę
  32. 32. SCRUM AT SCALE Pętla procesowa Zapewniać koordynację i komunikację między zespołami. Zbierać problemy i je rozwiązywać usprawniając proces.
  33. 33. 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ŚĆ
  34. 34. NEXUS
  35. 35. RECEPTY IDĄ W DWIE STRONY Empiryzm
  36. 36. 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
  37. 37. 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
  38. 38. 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 
  39. 39. ANDY@CODESPRINTERS.COM DZĘKUJĘ

×