際際滷

際際滷Share a Scribd company logo

Skalowanie Agile - rozszerzona wersja

Download as PPTX, PDF
Andy Brandt
Andy Brandt

Rozszerzona wersja mojej prezentacji na temat Skalowania zawierajca m.in. peniejsze om坦wienie LeSS.

1 of 31
SKALOWANIE ANDY BRANDT PLB6
PO CO CHCEMY SKALOWA? BY ROBI WICEJ? BY ROBI SZYBCIEJ? BY ZD纏Y NA JAKI TERMIN? BO MAMY DU纏O LUDZI I ZAKADAMY, 纏E WSZYSCY S POTRZEBNI?
ZANIM DODASZ KOLEJNY ZESP WYKORZYSTA REZERWY WYDAJNOCI W ISTNIEJCYM ZESPOLE. PRZEMYLE ZAKRES, UNIKA BUDOWANIA RZECZY ZBDNYCH (W.G. BADA JEDEN Z GWNYCH CZYNNIKW MARNOTRAWSTWA). BRA POD UWAG, 纏E ZWIKSZANIE ZESPOW NIESIE ZA SOB PROBLEMY, KTRE PRZYRASTAJ Z WIELKOCI SZYBCIEJ NI纏 KORZYCI. KORZY Z KA纏DEJ KOLEJNEJ DODANEJ OSOBY DO JEST CORAZ MNIEJSZA.
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
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 Konieczne jakie dzielnie produktu na moduy/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 3 Modu 1 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 saf Modu 2 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 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) DE FACTO OGRANICZONE MO纏LIWOCI PO PRZY TEAMACH ZWYKLE TRUDNO W CZSTYM WYDAWANIU PRODUKTU (TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTW) DLA WIELU ORGANIZACJI TO NIESTETY JEDYNA MO纏LIWO AUTONOMIA MODULARNA ARCHITEKTURA PRODUKTU ZESPOY ODPOWIEDZIALNE ZA OBSZARY FUNKCJONALNE, NIE KOMPONENTY TECHNOLOGICZNE POS WYSTARCZ OGLNE UZGODNIENIA CO DO KIERUNKU ROZWOJU MODUY 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 MODUOWA 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, 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 - rozszerzona wersja
SCRUM AT SCALE
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 CAO DZIAA W OPARCIU O STEROWAN METRYKAMI PRZEJRZYSTO
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.
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
ANDY@CODESPRINTERS.COM DZKUJ

More Related Content

Skalowanie Agile - rozszerzona wersja

  • 2. PO CO CHCEMY SKALOWA? BY ROBI WICEJ? BY ROBI SZYBCIEJ? BY ZD纏Y NA JAKI TERMIN? BO MAMY DU纏O LUDZI I ZAKADAMY, 纏E WSZYSCY S POTRZEBNI?
  • 3. ZANIM DODASZ KOLEJNY ZESP WYKORZYSTA REZERWY WYDAJNOCI W ISTNIEJCYM ZESPOLE. PRZEMYLE ZAKRES, UNIKA BUDOWANIA RZECZY ZBDNYCH (W.G. BADA JEDEN Z GWNYCH CZYNNIKW MARNOTRAWSTWA). BRA POD UWAG, 纏E ZWIKSZANIE ZESPOW NIESIE ZA SOB PROBLEMY, KTRE PRZYRASTAJ Z WIELKOCI SZYBCIEJ NI纏 KORZYCI. KORZY Z KA纏DEJ KOLEJNEJ DODANEJ OSOBY DO JEST CORAZ MNIEJSZA.
  • 4. 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
  • 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 Konieczne jakie dzielnie produktu na moduy/obszary Nie wystarcza jeden PO
  • 6. 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
  • 7. 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 Asv asdf 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 Asv asdf 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
  • 8. DWA ROZWIZANIA DLA DU纏EGO SKALOWANIAW zarzdzaniu wymaganiami
  • 11. ZESTAWIENIE HIERARCHIA MONOLITYCZNY PRODUKT (DU纏O ZALE纏NOCI) DE FACTO OGRANICZONE MO纏LIWOCI PO PRZY TEAMACH ZWYKLE TRUDNO W CZSTYM WYDAWANIU PRODUKTU (TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTW) DLA WIELU ORGANIZACJI TO NIESTETY JEDYNA MO纏LIWO AUTONOMIA MODULARNA ARCHITEKTURA PRODUKTU ZESPOY ODPOWIEDZIALNE ZA OBSZARY FUNKCJONALNE, NIE KOMPONENTY TECHNOLOGICZNE POS WYSTARCZ OGLNE UZGODNIENIA CO DO KIERUNKU ROZWOJU MODUY WYDAWANE NIEZALE纏NIE WYMAGA NIE TYLKO ODPOWIEDNIEJ ARCHITEKTURY PRODUKTU ALE I ORGANIZACJI.
  • 12. 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 MODUOWA METODA SKALOWANIA JEFFA SUTHERLANDA - HTTP://WWW.SCRUMINC.COM/SCRUM-AT-SCALE- PART-I/ NEXUS METODA SKALOWANIA KENA SCHWABERA -
  • 13. LESS
  • 14. 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.
  • 15. 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.
  • 16. 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
  • 17. 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.
  • 18. 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).
  • 19. 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
  • 20. 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
  • 21. 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
  • 24. 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 CAO DZIAA W OPARCIU O STEROWAN METRYKAMI PRZEJRZYSTO
  • 25. 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
  • 26. SCRUM AT SCALE Ptla procesowa Zapewnia koordynacj i komunikacj midzy zespoami. Zbiera problemy i je rozwizywa usprawniajc proces.
  • 27. NEXUS
  • 28. RECEPTY ID W DWIE STRONY Empiryzm
  • 29. 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
  • 30. 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

Editor's Notes

  1. In an Overall Retrospective, the systemic and organizational issues explored are above the level of a single team. Topics that might be discussed in an Overall Retrospective are: How well are the teams working together? Are the Communities of Practice working? Is there something that a team did that should be shared? Are the teams learning together? Are teams close to customers? Are there systemic organizational issues that cause problems in how teams operate? Is the Product Owner doing well? Is the Product Owner maintaining his five relationships?