際際滷

際際滷Share a Scribd company logo

Skalowanie Agile dla ALE Krakow

Andy Brandt
Andy Brandt

W prezentacji: - m坦j model skalowania Agile (2 wymiary, 4 obszary) - om坦wienie wiodcych "gotowych recept"

1 of 40
SKALOWANIE MODEL I PRZEGLD METOD ANDY BRANDT PLB6
OBOWIZKOWY SLAJD O SOBIE PRAKTYK AGILE OD 2006 ROKU OD 2007 ROKU ZWIZANY 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
CO TO JEST SKALOWANIE AGILE? ZWINNO (ANG. AGILITY) ZDOLNO DO SZYBKIEJ LECZ PRZEMYLANEJ ZMIANY. POLEGA NA DOSTOSOWANIU PRODUKTU [INFORMATYCZNEGO] DO ZMIENIAJCYCH SI WYMAGA BEZ OBNI纏ANIA JEGO JAKOCI. SKALOWANIE TO ROZWIZANIE PROBLEMU JAK UTRZYMA ZWINNO I INNE KORZYCI AGILE (SCRUM, KANBAN ITD.) PRZY WIELU ZESPOACH. atwo zmiany wymaga Mniej przykrych niespodzianek Wysoka wydajno zespo坦wZaagna甜owanie Szybki feedback z rynku Wysoka jako Czste wydania Dobra relacja z biznesem
MODEL 2 wymiary 4 obszary JEST TO MODEL POMAGAJCY W ROZUMIENIU PROBLEMU I PORWNYWANIU METOD SKALOWANIA MO纏E BY U纏YTY DO ANALIZY JAKIE PRAKTYKI S STOSOWANE W KA纏DYM Z OBSZARW 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 MAE SKALOWANIE Do ~55 os坦b, 4-6 team坦w max. Wiele problem坦w mo甜na nadal rozwiza spotykajc si ca grup Wystarcza jeden backlog i jeden PO DU纏E SKALOWANIE Wicej os坦b, wiele team坦w Zwykle nie wystarcza jeden PO Konieczne jakie dzielnie produktu na moduy/obszary
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
OBSZAR PRODUKTU CEL: ZAPEWNI, BY PRODUKT JAKO CAO DZIAA NA KONIEC KA纏DEJ ITERACJI (SPRINTU) KONCEPCYJNIE JEDYNE DOBRE ROZWIZANIE TO CIGA INTEGRACJA (CONTINUOUS INTEGRATION). WYMAGA: RODOWISKA CI (OPROGRAMOWANIE, CZASEM TAK纏E SPRZT) DOBRE POKRYCIE TESTAMI AUTOMATYCZNYMI (PIRAMIDA TESTW ITP.) KROSFUNKCJONALNO ZESPOU REGUY (NAJLEPIEJ POWSTAE W ZESPOACH) I DYSCYPLINA W ICH STOSOWANIU JELI CZEGO TU BRAK: AUTOMATYZACJA TESTW FUNKCJONALNYCH DOBRYM POMYSEM JAK UZYSKA SZYBKI FEEDBACK DLA DEVELOPERW ZANIM POKRYCIE TESTAMI JEDNOSTKOWYMI BDZIE ODPOWIEDNIE ZMNIEJSZENIE ILOCI PRACY W SPRINCIE, MARGINESY NA INTEGRACJ, ZESP INTEGRACYJNY ITP. JELI OSIGNICIE PENEGO CI NIE JEST MO纏LIWE: ZBUDOWA ZALEPKI/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 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
OBSZAR KOMUNIKACJI CEL: ZESPOY KOMUNIKUJ SI ZE SOB I ROZWIZUJ POJAWIAJCE SI PROBLEMY NA BIE纏CO (PODCZAS ITERACJI/SPRINTW) PRAKTYKI W TYM OBSZARZE KONCENTRUJ SI NA WSPOMAGANIU I STYMULOWANIU KOMUNIKACJI I KOORDYNACJI. PRZYKADY: SCRUM OF SCRUMS PODSTAWOWA, WCI纏 STOSOWANA PRAKTYKA KOMPETENCYJNE STRUKTURY POZIOME (R纏NE NAZWY I SZCZEGOWE ROZWIZANIA ACOP, TRIBES, TECH GROUP ETC.) WSPLNE PLANOWANIA, PRZEGLDY I PIELGNACJE (REFINEMENTS) BACKLOGU, WSPLNE RETROSPEKCJE (POZA TYMI W ZESPOACH) (R纏NE SZCZEGOWE PRAKTYKI LESS ZAWIERA DU纏O DOBRYCH POMYSW W TYM OBSZARZE) WSPLNE STANDARDY TECHNICZNE WSPOMAGAJCE: INNE SPOTKANIA PONAD ZESPOAMI, ODPOWIEDNIE PRZESTRZENIE DLA ZESPOW (WSPLNE PRZESTRZENIE, PROMIENNIKI INFORMACJI ITP.). Komunikacja
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
OBSZAR WYMAGA CEL: ZAPEWNI DOSTARCZENIE WSZYSTKIM ZESPOOM WYMAGA, KTRE W SUMIE DADZ WARTOCIOWY, U纏YWALNY PRODUKT CO ITERACJ (SPRINT) PRZY MAYM SKALOWANIU PRAKTYCZNIE BRAK R纏NIC W STOSUNKU DO JEDNEGO ZESPOU JEDEN PO, JEDEN BACKLOG. Wymagania
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
DWA ROZWIZANIA DLA DU纏EGO SKALOWANIAW zarzdzaniu wymaganiami
AUTONOMIA
HIERARCHIA
ZESTAWIENIE HIERARCHIA MONOLITYCZNY PRODUKT (DU纏O ZALE纏NOCI) ZWYKLE TRUDNO W CZSTYM WYDAWANIU PRODUKTU (TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTW) AGILEFALL DE FACTO OGRANICZONE MO纏LIWOCI PO PRZY TEAMACH, HIERARCHIA POWODUJE, 纏E PO STAJ SI ARCHITEKTAMI, ANALITYKAMI ITP. DLA WIELU ORGANIZACJI TO NIESTETY JEDYNA MO纏LIWO AUTONOMIA MODULARNA ARCHITEKTURA PRODUKTU (ZBIR MNIEJSZYCH PRODUKTW) ZWYKLE CZSTE WYDANIA, DOJRZAOC PRAKTYK TECHNICZNYCH, OBSZARU PRODUKTU (CI ITP.) SILNY NACISK NA PRAKTYKI W OBSZARZE KOMUNIKACJI PO WSPPRACUJ LU店NO (BRAK PODLEGOCI), MO纏LIWE WYSOKOPOZIOMOWE METRYKI PRODUKTOWE LUB PER OBSZAR
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
OBSZAR BIZNESU CEL: WYKORZYSTA AGILE BIZNESOWO PRAKTYKI W TYM OBSZARZE POLEGAJ NA PRZEKADANIU ZDOLNOCI METOD AGILE DO CZSTYCH WYDA I ZMIAN NA PRZEWAG CZY KORZYCI NA RYNKU LEAN STARTUP & RODZINA EVO TOM GILB ROZWIJANIE PRODUKTW TAK BY OSIGN ZKWANTYFIKOWANE CELE BIZNESOWE CZENIE Z PROJEKTAMI LEAN PROJECT CARD, PRE-PROCESS ETC.
PODSUMOWANIE MODELU SKALOWANIE JEST PROBLEMEM INNEGO KALIBRU PRZY KILKU ZESPOACH (MAE SKALOWANIE) NI纏 GDY JEST ICH DU纏O WICEJ (DU纏E SKALOWANIE) W KA纏DYM PRZYPADKU MAMY TRZY OBSZARY, W KTRYCH MUSZ BY WDRO纏ONE ODPOWIEDNIE PRAKTYKI PRODUKT, KOMUNIKACJA I WYMAGANIA Z NICH OBSZAR WYMAGA JEST NAJTRUDNIEJSZYM, Z NAJWIKSZ R纏NORODNOCI ROZWIZA, NAJBARDZIEJ ZALE纏NYM OD KONTEKSTU PRAKTYKI POZWALAJCE 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 MODUOWA METODA SKALOWANIA JEFFA SUTHERLANDA - HTTP://WWW.SCRUMINC.COM/SCRUM-AT-SCALE- PART-I/ NEXUS METODA SKALOWANIA KENA SCHWABERA
LESS Large Scale Scrum Pr坦ba zachowania istoty Scruma w wikszej 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, stay (z dedykowanymi czonkami). 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 dugoci. Wsp坦lne DoD i jeden produkt (przyrost) na koniec sprintu. Planowanie sprintu w dw坦ch etapach pierwszy wsp坦lny, drugi osobno. Wsp坦lny przegld 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 zespoy), SM nie mo甜e by delegatem PO prezentuje backlog, zespoy (delegaci) wybieraj i dziel wymagania midzy sob. Omawia si wszelkie wtpliwoci i pytania, jeli potrzebna jest cilejsza koordynacja midzy jakimi zespoami mo甜liwe jest zaplanowanie drugiej czci z wieloma zespoami Planowanie sprintu cz. 2 ka甜dy zesp坦 osobno, najczciej r坦wnolegle. Jeli jakie dwa-trzy zespoy pracuj nad zbli甜onym obszarem maj du甜e zale甜noci odbywaj cz. 2 jednym miejscu, co uatwia koordynacj.
LESS LARGE PIELGNACJA BACKLOGW Og坦lna pielgnacja PO, delegaci zespo坦w, ew. eksperci Relatywnie kr坦tka Rozbija si du甜e wymagania (epics) Wstpna zgrubna analiza Szacowanie Identyfikowanie wymaga wymagajcych wikszej koordynacji przy pielgnacji i realizacji Pielgnacja w zespoach (5-10% sprintu) Dla PBI, kt坦re bdzie robi jeden zesp坦 robi on r坦wnie甜 dalsz dekompozycj i analiz, informujc PO o zmianach w backlogu (zmiana oszacowa, nowe elementy w wyniku dekompozycji). Pielgnacja wieloma zespoami dla wymaga bardziej skomplikowanych cae teamy lub delegaci, niekoniecznie wszystkie teamy
LESS LARGE DAILY & SOS Daily Scrum wyglda tak samo jak zwykym 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 zespoy dostarczaj wsp坦lnie jeden przyrost. Zespoy maj wsp坦lne Definition of Done. Definition of Done powinno by mo甜liwie zbli甜one do Ready to Release (gotowy do wydania).
LESS LARGE PRZEGLD I RETROSPEKCJA Przegld wsp坦lny [2h] Produkt jest jeden, interesariusze wsp坦lni Format tradycyjny dla 2 zespo坦w Przy wikszej liczbie format delegat坦w albo format targ坦w Retrospekcja dwuetapowa Cz usprawnie jest na poziomie zespo坦w, cz dotyczy caoci Retrospekcja w zespoach 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 pocztku kolejnego sprintu
LESS HUGE Zo甜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 rzdu
LARGE SCALE SCRUM TWRCOM PRZYWIECAA IDEA ZACHOWANIA ISTOTY SCRUMA W WIKSZEJ SKALI DZIAANIE W WIKSZEJ SKALI OSIGNITE PRZEZ RELATYWNIE PROSTE DODATKOWE PRAKTYKI I WYDARZENIA ZWIZANE ZE SKALOWANIEM EFEKT DUGIEJ EWOLUCJI, SPRAWDZONY W BARDZO DU纏YCH I ZO纏ONYCH PRODUKTACH
Skalowanie Agile dla ALE Krakow
SCRUM AT SCALE
SCRUM AT SCALE Ptla produktowa Przeo甜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 Ptla procesowa Zapewnia koordynacj i komunikacj midzy zespoami. Zbiera problemy i je rozwizywa usprawniajc proces.
SCRUM AT SCALE SKALOWANIE POSTRZEGANE JAKO ORGANICZNY ROZWJ STEROWANY EMPIRYCZNIE ZGODNY Z KONTEKSTEM KONKRETNEJ FIRMY DWA ZASADNICZE PROCESY PTLA PRODUKTOWA (PRODUCT OWNER LOOP) I PTLA PROCESOWA (SCRUM MASTER LOOP) W KA纏DYM Z PROCESW R纏NE MODUY RZECZY, KTRE MUSZ BY ZROBIONE KONKRETNE MODUY S OBECNE NA R纏NYCH POZIOMACH ORGANIZACJI DLA KA纏DEGO Z MODUW PUBLICZNIE DOSTPNA BIBLIOTEKA KONTEKSTOWO OPISANYCH PRAKTYK HTTP://SCRUMPLOP.ORG CAO DZIAA W OPARCIU O STEROWAN METRYKAMI PRZEJRZYSTO
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 WYJCIOWY? KSZTAT PRODUKTU ARCHITEKTURA, STAN KODU MO纏LIWOCI ZESPOW OBECNE STRUKTURY I KULTURA ORGANIZACJI CZY JU纏 WYKORZYSTANO ISTNIEJCE REZERWY USPRAWNIE W JEDNYM ZESPOLE? POZIOM ODWAGI LUB KONIECZNOCI
O CZYM NALE纏Y PAMITA WSZYSTKIE METODY I PRAKTYKI ZWINNE S ZASTOSOWANIEM EMPIRYZMU DO TWORZENIA OPROGRAMOWANIA EMPIRYZM NIE MO纏E BY Z GRY ZAPLANOWANY TO PRZECIWIESTWO PODEJCIA PREDYKCYJNEGO ZMIANY PROCESU I KULTURY NIE DA SI DO KOCA NARZUCI ODGRNIE PROCES EMPIRYCZNY NIE MA STANU KOCOWEGO KA纏DA METODA JEST KROKIEM KU DALSZEMU ROZWOJOWI SAM PROCES NA POZIOMIE STRUKTURY I ZARZDZANIA NIE WYSTARCZY, NIEZBDNE S ODPOWIEDNIE PRAKTYKI TECHNICZNE
CZY WARTO SIGA PO POMOC? KONSULTANCI I COACHE PRZYNOSZ: ZEWNTRZNE SPOJRZENIE NA WASZE PROBLEMY WIEDZ O ISTNIEJCYCH METODACH I PRAKTYKACH DOWIADCZENIE OPARTE NA NIM PRZEKONANIE, 纏E MO纏NA (DA SI) CHYBA WARTO
ANDY@CODESPRINTERS.COM DZKUJ

More Related Content

Skalowanie Agile dla ALE Krakow

  • 1. SKALOWANIE MODEL I PRZEGLD METOD ANDY BRANDT PLB6
  • 2. OBOWIZKOWY SLAJD O SOBIE PRAKTYK AGILE OD 2006 ROKU OD 2007 ROKU ZWIZANY 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 PRZEMYLANEJ ZMIANY. POLEGA NA DOSTOSOWANIU PRODUKTU [INFORMATYCZNEGO] DO ZMIENIAJCYCH SI WYMAGA BEZ OBNI纏ANIA JEGO JAKOCI. SKALOWANIE TO ROZWIZANIE PROBLEMU JAK UTRZYMA ZWINNO I INNE KORZYCI AGILE (SCRUM, KANBAN ITD.) PRZY WIELU ZESPOACH. atwo zmiany wymaga Mniej przykrych niespodzianek Wysoka wydajno zespo坦wZaagna甜owanie Szybki feedback z rynku Wysoka jako Czste wydania Dobra relacja z biznesem
  • 4. MODEL 2 wymiary 4 obszary JEST TO MODEL POMAGAJCY W ROZUMIENIU PROBLEMU I PORWNYWANIU METOD SKALOWANIA MO纏E BY U纏YTY DO ANALIZY JAKIE PRAKTYKI S STOSOWANE W KA纏DYM Z OBSZARW 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 MAE SKALOWANIE Do ~55 os坦b, 4-6 team坦w max. Wiele problem坦w mo甜na nadal rozwiza spotykajc si ca grup Wystarcza jeden backlog i jeden PO DU纏E SKALOWANIE Wicej os坦b, wiele team坦w Zwykle nie wystarcza jeden PO Konieczne jakie dzielnie produktu na moduy/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 CAO DZIAA NA KONIEC KA纏DEJ ITERACJI (SPRINTU) KONCEPCYJNIE JEDYNE DOBRE ROZWIZANIE TO CIGA INTEGRACJA (CONTINUOUS INTEGRATION). WYMAGA: RODOWISKA CI (OPROGRAMOWANIE, CZASEM TAK纏E SPRZT) DOBRE POKRYCIE TESTAMI AUTOMATYCZNYMI (PIRAMIDA TESTW ITP.) KROSFUNKCJONALNO ZESPOU REGUY (NAJLEPIEJ POWSTAE W ZESPOACH) I DYSCYPLINA W ICH STOSOWANIU JELI CZEGO TU BRAK: AUTOMATYZACJA TESTW FUNKCJONALNYCH DOBRYM POMYSEM JAK UZYSKA SZYBKI FEEDBACK DLA DEVELOPERW ZANIM POKRYCIE TESTAMI JEDNOSTKOWYMI BDZIE ODPOWIEDNIE ZMNIEJSZENIE ILOCI PRACY W SPRINCIE, MARGINESY NA INTEGRACJ, ZESP INTEGRACYJNY ITP. JELI OSIGNICIE PENEGO CI NIE JEST MO纏LIWE: ZBUDOWA ZALEPKI/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: ZESPOY KOMUNIKUJ SI ZE SOB I ROZWIZUJ POJAWIAJCE SI PROBLEMY NA BIE纏CO (PODCZAS ITERACJI/SPRINTW) PRAKTYKI W TYM OBSZARZE KONCENTRUJ SI NA WSPOMAGANIU I STYMULOWANIU KOMUNIKACJI I KOORDYNACJI. PRZYKADY: SCRUM OF SCRUMS PODSTAWOWA, WCI纏 STOSOWANA PRAKTYKA KOMPETENCYJNE STRUKTURY POZIOME (R纏NE NAZWY I SZCZEGOWE ROZWIZANIA ACOP, TRIBES, TECH GROUP ETC.) WSPLNE PLANOWANIA, PRZEGLDY I PIELGNACJE (REFINEMENTS) BACKLOGU, WSPLNE RETROSPEKCJE (POZA TYMI W ZESPOACH) (R纏NE SZCZEGOWE PRAKTYKI LESS ZAWIERA DU纏O DOBRYCH POMYSW W TYM OBSZARZE) WSPLNE STANDARDY TECHNICZNE WSPOMAGAJCE: INNE SPOTKANIA PONAD ZESPOAMI, ODPOWIEDNIE PRZESTRZENIE DLA ZESPOW (WSPLNE 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 ZESPOOM WYMAGA, KTRE W SUMIE DADZ WARTOCIOWY, U纏YWALNY PRODUKT CO ITERACJ (SPRINT) PRZY MAYM SKALOWANIU PRAKTYCZNIE BRAK R纏NIC W STOSUNKU DO JEDNEGO ZESPOU 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 ROZWIZANIA DLA DU纏EGO SKALOWANIAW zarzdzaniu wymaganiami
  • 16. ZESTAWIENIE HIERARCHIA MONOLITYCZNY PRODUKT (DU纏O ZALE纏NOCI) ZWYKLE TRUDNO W CZSTYM WYDAWANIU PRODUKTU (TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTW) AGILEFALL DE FACTO OGRANICZONE MO纏LIWOCI PO PRZY TEAMACH, HIERARCHIA POWODUJE, 纏E PO STAJ SI ARCHITEKTAMI, ANALITYKAMI ITP. DLA WIELU ORGANIZACJI TO NIESTETY JEDYNA MO纏LIWO AUTONOMIA MODULARNA ARCHITEKTURA PRODUKTU (ZBIR MNIEJSZYCH PRODUKTW) ZWYKLE CZSTE WYDANIA, DOJRZAOC PRAKTYK TECHNICZNYCH, OBSZARU PRODUKTU (CI ITP.) SILNY NACISK NA PRAKTYKI W OBSZARZE KOMUNIKACJI PO WSPPRACUJ LU店NO (BRAK PODLEGOCI), 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 PRZEKADANIU ZDOLNOCI METOD AGILE DO CZSTYCH WYDA I ZMIAN NA PRZEWAG CZY KORZYCI NA RYNKU LEAN STARTUP & RODZINA EVO TOM GILB ROZWIJANIE PRODUKTW TAK BY OSIGN ZKWANTYFIKOWANE CELE BIZNESOWE CZENIE Z PROJEKTAMI LEAN PROJECT CARD, PRE-PROCESS ETC.
  • 19. PODSUMOWANIE MODELU SKALOWANIE JEST PROBLEMEM INNEGO KALIBRU PRZY KILKU ZESPOACH (MAE SKALOWANIE) NI纏 GDY JEST ICH DU纏O WICEJ (DU纏E SKALOWANIE) W KA纏DYM PRZYPADKU MAMY TRZY OBSZARY, W KTRYCH MUSZ BY WDRO纏ONE ODPOWIEDNIE PRAKTYKI PRODUKT, KOMUNIKACJA I WYMAGANIA Z NICH OBSZAR WYMAGA JEST NAJTRUDNIEJSZYM, Z NAJWIKSZ R纏NORODNOCI ROZWIZA, NAJBARDZIEJ ZALE纏NYM OD KONTEKSTU PRAKTYKI POZWALAJCE 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 MODUOWA 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 wikszej 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, stay (z dedykowanymi czonkami). 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 dugoci. Wsp坦lne DoD i jeden produkt (przyrost) na koniec sprintu. Planowanie sprintu w dw坦ch etapach pierwszy wsp坦lny, drugi osobno. Wsp坦lny przegld 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 zespoy), SM nie mo甜e by delegatem PO prezentuje backlog, zespoy (delegaci) wybieraj i dziel wymagania midzy sob. Omawia si wszelkie wtpliwoci i pytania, jeli potrzebna jest cilejsza koordynacja midzy jakimi zespoami mo甜liwe jest zaplanowanie drugiej czci z wieloma zespoami Planowanie sprintu cz. 2 ka甜dy zesp坦 osobno, najczciej r坦wnolegle. Jeli jakie dwa-trzy zespoy pracuj nad zbli甜onym obszarem maj du甜e zale甜noci odbywaj cz. 2 jednym miejscu, co uatwia koordynacj.
  • 24. LESS LARGE PIELGNACJA BACKLOGW Og坦lna pielgnacja PO, delegaci zespo坦w, ew. eksperci Relatywnie kr坦tka Rozbija si du甜e wymagania (epics) Wstpna zgrubna analiza Szacowanie Identyfikowanie wymaga wymagajcych wikszej koordynacji przy pielgnacji i realizacji Pielgnacja w zespoach (5-10% sprintu) Dla PBI, kt坦re bdzie robi jeden zesp坦 robi on r坦wnie甜 dalsz dekompozycj i analiz, informujc PO o zmianach w backlogu (zmiana oszacowa, nowe elementy w wyniku dekompozycji). Pielgnacja wieloma zespoami dla wymaga bardziej skomplikowanych cae teamy lub delegaci, niekoniecznie wszystkie teamy
  • 25. LESS LARGE DAILY & SOS Daily Scrum wyglda tak samo jak zwykym 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 zespoy dostarczaj wsp坦lnie jeden przyrost. Zespoy 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 PRZEGLD I RETROSPEKCJA Przegld wsp坦lny [2h] Produkt jest jeden, interesariusze wsp坦lni Format tradycyjny dla 2 zespo坦w Przy wikszej liczbie format delegat坦w albo format targ坦w Retrospekcja dwuetapowa Cz usprawnie jest na poziomie zespo坦w, cz dotyczy caoci Retrospekcja w zespoach 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 pocztku kolejnego sprintu
  • 28. LESS HUGE Zo甜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 rzdu
  • 29. LARGE SCALE SCRUM TWRCOM PRZYWIECAA IDEA ZACHOWANIA ISTOTY SCRUMA W WIKSZEJ SKALI DZIAANIE W WIKSZEJ SKALI OSIGNITE PRZEZ RELATYWNIE PROSTE DODATKOWE PRAKTYKI I WYDARZENIA ZWIZANE ZE SKALOWANIEM EFEKT DUGIEJ EWOLUCJI, SPRAWDZONY W BARDZO DU纏YCH I ZO纏ONYCH PRODUKTACH
  • 32. SCRUM AT SCALE Ptla produktowa Przeo甜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 Ptla procesowa Zapewnia koordynacj i komunikacj midzy zespoami. Zbiera problemy i je rozwizywa usprawniajc proces.
  • 34. SCRUM AT SCALE SKALOWANIE POSTRZEGANE JAKO ORGANICZNY ROZWJ STEROWANY EMPIRYCZNIE ZGODNY Z KONTEKSTEM KONKRETNEJ FIRMY DWA ZASADNICZE PROCESY PTLA PRODUKTOWA (PRODUCT OWNER LOOP) I PTLA PROCESOWA (SCRUM MASTER LOOP) W KA纏DYM Z PROCESW R纏NE MODUY RZECZY, KTRE MUSZ BY ZROBIONE KONKRETNE MODUY S OBECNE NA R纏NYCH POZIOMACH ORGANIZACJI DLA KA纏DEGO Z MODUW PUBLICZNIE DOSTPNA BIBLIOTEKA KONTEKSTOWO OPISANYCH PRAKTYK HTTP://SCRUMPLOP.ORG CAO DZIAA 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 WYJCIOWY? KSZTAT PRODUKTU ARCHITEKTURA, STAN KODU MO纏LIWOCI ZESPOW OBECNE STRUKTURY I KULTURA ORGANIZACJI CZY JU纏 WYKORZYSTANO ISTNIEJCE REZERWY USPRAWNIE W JEDNYM ZESPOLE? POZIOM ODWAGI LUB KONIECZNOCI
  • 38. O CZYM NALE纏Y PAMITA WSZYSTKIE METODY I PRAKTYKI ZWINNE S ZASTOSOWANIEM EMPIRYZMU DO TWORZENIA OPROGRAMOWANIA EMPIRYZM NIE MO纏E BY Z GRY ZAPLANOWANY TO PRZECIWIESTWO PODEJCIA PREDYKCYJNEGO ZMIANY PROCESU I KULTURY NIE DA SI DO KOCA NARZUCI ODGRNIE PROCES EMPIRYCZNY NIE MA STANU KOCOWEGO KA纏DA METODA JEST KROKIEM KU DALSZEMU ROZWOJOWI SAM PROCES NA POZIOMIE STRUKTURY I ZARZDZANIA NIE WYSTARCZY, NIEZBDNE S ODPOWIEDNIE PRAKTYKI TECHNICZNE
  • 39. CZY WARTO SIGA PO POMOC? KONSULTANCI I COACHE PRZYNOSZ: ZEWNTRZNE SPOJRZENIE NA WASZE PROBLEMY WIEDZ O ISTNIEJCYCH METODACH I PRAKTYKACH DOWIADCZENIE OPARTE NA NIM PRZEKONANIE, 纏E MO纏NA (DA SI) CHYBA WARTO