SlideShare uma empresa Scribd logo
1 de 18
SKALOWANIE 
ANDY BRANDT 
PL 4.1
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 
• DOŚWIADCZENIE POKAZAŁO JUŻ, ŻE ZESPOŁY SCRUM SĄ BARDZO 
WYDAJNE PRZY BUDOWANIU PRODUKTÓW, SCRUM JEST JEDNAK 
MODELEM DLA JEDNEGO MAŁEGO ZESPOŁU 
• SKALOWANIE TO ROZWIĄZANIE PROBLEMU – JAK UTRZYMAĆ 
ZWINNOŚĆ I INNE KORZYŚCI SCRUM (I INNYCH METOD AGILE) PRZY 
WIELU ZESPOŁACH
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 
• Konieczne jakieś 
dzielnie produktu na 
moduły/obszary 
• Nie wystarcza jeden 
PO
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 
DIABEŁ TKWI W 
WYMAGANIACH 
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 
PRODUKT 
4 
1 
2 
3 
4 
Wymagania Komunikacja Produkt
DWA ROZWIĄZANIA DLA 
„DUŻEGO SKAWL zOarzWądzAaniNu IA” 
wymaganiami
AUTONOMIA
HIERARCHIA
ZESTAWIENIE 
HIERARCHIA 
• MONOLITYCZNY PRODUKT 
(DUŻO ZALEŻNOŚCI) 
• DE FACTO OGRANICZONE 
MOŻLIWOŚCI PO PRZY TEAMACH 
• ZWYKLE TRUDNOŚĆ W 
CZĘSTYM WYDAWANIU PRODUKTU 
(TRUDNIEJSZE TESTOWANIE, 
TWORZENIE PRZYROSTÓW) 
• DLA WIELU ORGANIZACJI TO 
NIESTETY JEDYNA MOŻLIWOŚĆ 
AUTONOMIA 
• MODULARNA ARCHITEKTURA 
PRODUKTU 
• ZESPOŁY ODPOWIEDZIALNE ZA 
OBSZARY FUNKCJONALNE, NIE 
KOMPONENTY TECHNOLOGICZNE 
• POS WYSTARCZĄ OGÓLNE 
UZGODNIENIA CO DO KIERUNKU ROZWOJU 
• MODUŁY 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://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/
LESS
SCRUM AT SCALE
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 NAWASZE PROBLEMY 
• WIEDZĘ O ISTNIEJĄCYCH METODACH I PRAKTYKACH 
• DOŚWIADCZENIE 
• OPARTE NA NIM PRZEKONANIE, ŻE MOŻNA („DA SIĘ”) 
• CHYBA WARTO 
DZĘKUJĘ 
ANDY@CODESPRINTERS.COM

Mais conteúdo relacionado

Destaque

Agile - 5 points for managers
Agile - 5 points for managersAgile - 5 points for managers
Agile - 5 points for managersAndy Brandt
 
Zapewnienie jakości w Scrum
Zapewnienie jakości w ScrumZapewnienie jakości w Scrum
Zapewnienie jakości w ScrumKrystian Kaczor
 
Quality Assurance in Scrum
Quality Assurance in ScrumQuality Assurance in Scrum
Quality Assurance in ScrumKrystian Kaczor
 
Agile Tester - Czy to w ogóle ma sens?
Agile Tester  - Czy to w ogóle ma sens?Agile Tester  - Czy to w ogóle ma sens?
Agile Tester - Czy to w ogóle ma sens?Krystian Kaczor
 
Dlaczego developerzy nie lubią scrum
Dlaczego developerzy nie lubią scrumDlaczego developerzy nie lubią scrum
Dlaczego developerzy nie lubią scrumKrystian Kaczor
 
Analityk biznesowy w agile
Analityk biznesowy w agileAnalityk biznesowy w agile
Analityk biznesowy w agileKrystian Kaczor
 
Sprint retrospective wartości scrum
Sprint retrospective   wartości scrumSprint retrospective   wartości scrum
Sprint retrospective wartości scrumKrystian Kaczor
 

Destaque (11)

Agile - 5 points for managers
Agile - 5 points for managersAgile - 5 points for managers
Agile - 5 points for managers
 
Kim jest Agile Tester
Kim jest Agile TesterKim jest Agile Tester
Kim jest Agile Tester
 
Zapewnienie jakości w Scrum
Zapewnienie jakości w ScrumZapewnienie jakości w Scrum
Zapewnienie jakości w Scrum
 
Wymagania w Agile
Wymagania w AgileWymagania w Agile
Wymagania w Agile
 
Wprowadzenie do Agile
Wprowadzenie do AgileWprowadzenie do Agile
Wprowadzenie do Agile
 
Quality Assurance in Scrum
Quality Assurance in ScrumQuality Assurance in Scrum
Quality Assurance in Scrum
 
Agile Tester - Czy to w ogóle ma sens?
Agile Tester  - Czy to w ogóle ma sens?Agile Tester  - Czy to w ogóle ma sens?
Agile Tester - Czy to w ogóle ma sens?
 
Dlaczego developerzy nie lubią scrum
Dlaczego developerzy nie lubią scrumDlaczego developerzy nie lubią scrum
Dlaczego developerzy nie lubią scrum
 
Analityk biznesowy w agile
Analityk biznesowy w agileAnalityk biznesowy w agile
Analityk biznesowy w agile
 
Sprint retrospective wartości scrum
Sprint retrospective   wartości scrumSprint retrospective   wartości scrum
Sprint retrospective wartości scrum
 
Agile fakty i mity
Agile fakty i mityAgile fakty i mity
Agile fakty i mity
 

Mais de Andy Brandt

Samozarzadzanie - Produkt nad Wisłą
Samozarzadzanie - Produkt nad WisłąSamozarzadzanie - Produkt nad Wisłą
Samozarzadzanie - Produkt nad WisłąAndy Brandt
 
Uważaj! Możesz urosnąć!
Uważaj! Możesz urosnąć!Uważaj! Możesz urosnąć!
Uważaj! Możesz urosnąć!Andy Brandt
 
Wymagania - cele, funkcjonalność, rozwiązania
Wymagania - cele, funkcjonalność, rozwiązaniaWymagania - cele, funkcjonalność, rozwiązania
Wymagania - cele, funkcjonalność, rozwiązaniaAndy Brandt
 
Startup Offshoring from StartupCamp Switzerland 2014
Startup Offshoring from StartupCamp Switzerland 2014Startup Offshoring from StartupCamp Switzerland 2014
Startup Offshoring from StartupCamp Switzerland 2014Andy Brandt
 
User stories and decomposing requirements
User stories and decomposing requirementsUser stories and decomposing requirements
User stories and decomposing requirementsAndy Brandt
 
Agile introduction for the American Chamber of Commerce members
Agile introduction for the American Chamber of Commerce membersAgile introduction for the American Chamber of Commerce members
Agile introduction for the American Chamber of Commerce membersAndy Brandt
 
Agile company pl
Agile company plAgile company pl
Agile company plAndy Brandt
 
Zwinne metodyki w zarządzaniu
Zwinne metodyki w zarządzaniuZwinne metodyki w zarządzaniu
Zwinne metodyki w zarządzaniuAndy Brandt
 

Mais de Andy Brandt (9)

Samozarzadzanie - Produkt nad Wisłą
Samozarzadzanie - Produkt nad WisłąSamozarzadzanie - Produkt nad Wisłą
Samozarzadzanie - Produkt nad Wisłą
 
Uważaj! Możesz urosnąć!
Uważaj! Możesz urosnąć!Uważaj! Możesz urosnąć!
Uważaj! Możesz urosnąć!
 
Wymagania - cele, funkcjonalność, rozwiązania
Wymagania - cele, funkcjonalność, rozwiązaniaWymagania - cele, funkcjonalność, rozwiązania
Wymagania - cele, funkcjonalność, rozwiązania
 
Startup Offshoring from StartupCamp Switzerland 2014
Startup Offshoring from StartupCamp Switzerland 2014Startup Offshoring from StartupCamp Switzerland 2014
Startup Offshoring from StartupCamp Switzerland 2014
 
User stories and decomposing requirements
User stories and decomposing requirementsUser stories and decomposing requirements
User stories and decomposing requirements
 
Agile introduction for the American Chamber of Commerce members
Agile introduction for the American Chamber of Commerce membersAgile introduction for the American Chamber of Commerce members
Agile introduction for the American Chamber of Commerce members
 
Agile company pl
Agile company plAgile company pl
Agile company pl
 
Agile managers
Agile managersAgile managers
Agile managers
 
Zwinne metodyki w zarządzaniu
Zwinne metodyki w zarządzaniuZwinne metodyki w zarządzaniu
Zwinne metodyki w zarządzaniu
 

Skalowanie Agile

  • 2. 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 • DOŚWIADCZENIE POKAZAŁO JUŻ, ŻE ZESPOŁY SCRUM SĄ BARDZO WYDAJNE PRZY BUDOWANIU PRODUKTÓW, SCRUM JEST JEDNAK MODELEM DLA JEDNEGO MAŁEGO ZESPOŁU • SKALOWANIE TO ROZWIĄZANIE PROBLEMU – JAK UTRZYMAĆ ZWINNOŚĆ I INNE KORZYŚCI SCRUM (I INNYCH METOD AGILE) PRZY WIELU ZESPOŁACH
  • 3. 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 • Konieczne jakieś dzielnie produktu na moduły/obszary • Nie wystarcza jeden PO
  • 4. 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
  • 5. 1 2 3 Moduł 1 DIABEŁ TKWI W WYMAGANIACH 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 PRODUKT 4 1 2 3 4 Wymagania Komunikacja Produkt
  • 6. DWA ROZWIĄZANIA DLA „DUŻEGO SKAWL zOarzWądzAaniNu IA” wymaganiami
  • 9. ZESTAWIENIE HIERARCHIA • MONOLITYCZNY PRODUKT (DUŻO ZALEŻNOŚCI) • DE FACTO OGRANICZONE MOŻLIWOŚCI PO PRZY TEAMACH • ZWYKLE TRUDNOŚĆ W CZĘSTYM WYDAWANIU PRODUKTU (TRUDNIEJSZE TESTOWANIE, TWORZENIE PRZYROSTÓW) • DLA WIELU ORGANIZACJI TO NIESTETY JEDYNA MOŻLIWOŚĆ AUTONOMIA • MODULARNA ARCHITEKTURA PRODUKTU • ZESPOŁY ODPOWIEDZIALNE ZA OBSZARY FUNKCJONALNE, NIE KOMPONENTY TECHNOLOGICZNE • POS WYSTARCZĄ OGÓLNE UZGODNIENIA CO DO KIERUNKU ROZWOJU • MODUŁY WYDAWANE NIEZALEŻNIE • WYMAGA NIE TYLKO ODPOWIEDNIEJ ARCHITEKTURY PRODUKTU ALE I ORGANIZACJI.
  • 10. 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/
  • 11. LESS
  • 12.
  • 14. RECEPTY IDĄ W DWIE STRONY Empiryzm
  • 15. 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
  • 16. 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
  • 17. CZY WARTO SIĘGAĆ PO POMOC? • KONSULTANCI I COACHE PRZYNOSZĄ: • ZEWNĘTRZNE SPOJRZENIE NAWASZE PROBLEMY • WIEDZĘ O ISTNIEJĄCYCH METODACH I PRAKTYKACH • DOŚWIADCZENIE • OPARTE NA NIM PRZEKONANIE, ŻE MOŻNA („DA SIĘ”) • CHYBA WARTO 