Skalowanie Agile dla ALE Krakow
•
0 recomendaciones•1,731 vistas
W prezentacji: - mój model skalowania Agile (2 wymiary, 4 obszary) - omówienie wiodących "gotowych recept"
Recomendados
Recomendados
Más contenido relacionado
Similar a Skalowanie Agile dla ALE Krakow
Similar a Skalowanie Agile dla ALE Krakow (20)
Más de Andy Brandt
Más de Andy Brandt (9)
Skalowanie Agile dla ALE Krakow
- 1. SKALOWANIE MODEL I PRZEGLĄD METOD ANDY BRANDT PLB6
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. DWA ROZWIĄZANIA DLA „DUŻEGO SKALOWANIA”W zarządzaniu wymaganiami
- 14. AUTONOMIA
- 15. HIERARCHIA
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
- 31. SCRUM AT SCALE
- 32. 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ę
- 33. SCRUM AT SCALE Pętla procesowa Zapewniać koordynację i komunikację między zespołami. Zbierać problemy i je rozwiązywać usprawniając proces.
- 34. 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ŚĆ
- 35. NEXUS
- 36. RECEPTY IDĄ W DWIE STRONY Empiryzm
- 37. 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
- 38. 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
- 39. 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