Pasja, cierpliwość i zaufanie. Agile@GetResponse – historia zmianySławek Łukjanow
Podobno na mieście krążą informacje o udanych zmianach w GetResponse IT. Nadszedł zatem najwyższy czas, aby o nich opowiedzieć!
W czerwcu 2015 roku w GetResponse pojawiło się dwoje zaprawionych w bojach Scrum Masterów. Misja: wsparcie wdrożenia Scruma na poziomie całego IT.
Po 1.5 roku jest już nas pięcioro i uważamy, że wspólnie udało nam się sporo osiągnąć. Opowiem o tym jak podeszliśmy do procesu zmiany, co zrealizowaliśmy, na jakie problemy natrafiliśmy i jak je rozwiązaliśmy, co nas zaskoczyło, jakie popełnialiśmy błędy i czego nas to nauczyło. I jak wersję „wzorowy Scrum” zmieniliśmy na podążanie za zasadami kultury agile.
To będzie też historia o tym jak istotna w pracy Scrum Mastera jest pasja i wewnętrzny ogień, połączony z anielską cierpliwością. I jak bardzo pomaga zaufanie. Zarówno to otrzymane, jak i dawane.
Prezentował: Maciej Wilmiński
Scrum Master w GetResponse, mający niemałe doświadczenie we wprowadzaniu kultury i pracy agile, zarówno na poziomie zespołów deweloperskich, działów IT jak i całych organizacji.
Jego dużym atutem jest praktyka zdobyta w sporej ilości projektów, w których pełnił różne role: programisty, architekta oprogramowania czy lidera zespołu. W efekcie niewiele w IT jest go w stanie zaskoczyć lub przestraszyć.
Wierzy w moc pracy zespołowej, a jako wielki fan sportu, dostrzega sporo podobieństw pomiędzy pracą zespołu programistycznego, a budowaniu dobrej drużyny sportowej. Rolę Scrum Mastera postrzega jako kombinację kapitana, trenera, a czasem i zawodnika.
O Scrumie i agile’u pisze na blogu mlynarze.com, jest też założycielem Encyklopedii Rocka rockers.com.pl.
The document discusses three case studies of scaling Agile practices to the enterprise level. The first case study describes challenges with a team using only Scrum practices and how adopting additional XP practices like test-driven development and continuous integration helped. The second case study explains problems that arose from multiple teams working on a shared backlog and lack of synchronization; Kanban was introduced to help. The third case study outlines issues with multiple outsourced teams and lack of integration; Kanban, additional roles, and improved coordination helped address these challenges at the portfolio level.
Pasja, cierpliwość i zaufanie. Agile@GetResponse – historia zmianySławek Łukjanow
Podobno na mieście krążą informacje o udanych zmianach w GetResponse IT. Nadszedł zatem najwyższy czas, aby o nich opowiedzieć!
W czerwcu 2015 roku w GetResponse pojawiło się dwoje zaprawionych w bojach Scrum Masterów. Misja: wsparcie wdrożenia Scruma na poziomie całego IT.
Po 1.5 roku jest już nas pięcioro i uważamy, że wspólnie udało nam się sporo osiągnąć. Opowiem o tym jak podeszliśmy do procesu zmiany, co zrealizowaliśmy, na jakie problemy natrafiliśmy i jak je rozwiązaliśmy, co nas zaskoczyło, jakie popełnialiśmy błędy i czego nas to nauczyło. I jak wersję „wzorowy Scrum” zmieniliśmy na podążanie za zasadami kultury agile.
To będzie też historia o tym jak istotna w pracy Scrum Mastera jest pasja i wewnętrzny ogień, połączony z anielską cierpliwością. I jak bardzo pomaga zaufanie. Zarówno to otrzymane, jak i dawane.
Prezentował: Maciej Wilmiński
Scrum Master w GetResponse, mający niemałe doświadczenie we wprowadzaniu kultury i pracy agile, zarówno na poziomie zespołów deweloperskich, działów IT jak i całych organizacji.
Jego dużym atutem jest praktyka zdobyta w sporej ilości projektów, w których pełnił różne role: programisty, architekta oprogramowania czy lidera zespołu. W efekcie niewiele w IT jest go w stanie zaskoczyć lub przestraszyć.
Wierzy w moc pracy zespołowej, a jako wielki fan sportu, dostrzega sporo podobieństw pomiędzy pracą zespołu programistycznego, a budowaniu dobrej drużyny sportowej. Rolę Scrum Mastera postrzega jako kombinację kapitana, trenera, a czasem i zawodnika.
O Scrumie i agile’u pisze na blogu mlynarze.com, jest też założycielem Encyklopedii Rocka rockers.com.pl.
The document discusses three case studies of scaling Agile practices to the enterprise level. The first case study describes challenges with a team using only Scrum practices and how adopting additional XP practices like test-driven development and continuous integration helped. The second case study explains problems that arose from multiple teams working on a shared backlog and lack of synchronization; Kanban was introduced to help. The third case study outlines issues with multiple outsourced teams and lack of integration; Kanban, additional roles, and improved coordination helped address these challenges at the portfolio level.
1. Agile is still a form of management that focuses on empowering self-organizing teams through establishing the right environment and shielding them from obstacles.
2. Managers are responsible for both the physical workspace and cultural environment that allows teams to thrive, innovate, and feel safe to admit failures.
3. The role of the manager is to care for the mechanisms that support teams such as Scrum Masters, Product Owners, and to intervene only when necessary to remove impediments or resolve deadlocks between teams.
Nas świat przyspiesza, czas wydaje się biegnąć coraz szybciej a zalewający nas potok informacji nie ma końca. Potrzebujemy szybkich i skutecznych metod wytwarzania nowych produktów. W tym celu zostały opracowane metody i frameworki Agile, ze Scrum na czele.
Jest więcej niż bardziej prawdopodobne, że następny projekt, na którym będziesz pracował, lub nowy kontrakt będzie oznaczał pracę według reguł Agile. Organizacje już teraz zaczynają poszukiwać na rynku specjalistów określanych jako Agile Tester. Czy możemy w pełni opisać kim jest i jak działa taka osoba?
Co tester może zrobić, żeby odnieść sukces w nowej sytuacji? Jak trzeba zmienić podejście do swojej roli i sposobu wykonywania pracy. Czy potrzebne są nowe procesy i narzędzia? Czy zmienia się misja testowania? Czy to prawda, że w zespole Scrum są tylko Deweloperzy?
Zapraszam na prezentację podczas której odpowiem na pytania najbardziej nurtujące testerów spotykających Agile na swojej ścieżce zawodowej. Do pełnego zilustrowania profilu Agile Terstera posłużę się modelem popularnie stosowanym w coachingu.
No i stało się. Nadszedł ten dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę, to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z Edge of Tomorrow. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/miała kolejnego podejścia w przypadku porażki projektu.
Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.
This document contains slides from a 2010 presentation on testing in Scrum. It discusses key Scrum principles like iterations, self-organizing cross-functional teams, and continuous improvement. The slides cover testing practices like test-driven development, having no separate test team, continuous testing, and automating tests from the unit to GUI levels. User stories and their elements are explained. The document advocates testing that follows the Scrum process and values working software over documentation.
Jest już 2016, a różni guru i instytucje certyfikujące nadal promują pomysł specjalizacji Agile Tester. Jak są rozumiane Agile Tester i Agile Testing? Czy to jest zgodne z ramami Scrum? Czy Agile Testing to tylko techniki XP?
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
W trakcie transformacji do Agile jeden z problemów do rozwiązania to umiejscowienie roli analityka w nowej rzeczywistości. Pula rozwiązań wydaje się tutaj mocno ograniczona standardami. Scrum Guide nie wyznacza takiej roli i nie wskazuje co zrobić z analitykiem. A może analityk nie jest w ogóle potrzebny w Agile? Nawet jeśli znajdziemy dla niego miejsce to trudno jest pracować w iteracjach tak, żeby było to wartościowe i efektywne. W swojej pracy widziałem już kilka konfiguracji w mniejszych i większych przedsięwzięciach. Każdy wybór oczywiście ma swoje plusy dodatnie i plusy ujemne. Opowiem zatem jak funckjonowała w moim doświadczeniu analiza biznesowa w środowiskach Agile, w szczególności z zespołami Scrumowymi oraz jakie są opcje rozwiązania sytuacji Analityka.
Wielu Scrum Masterów nie ma pomysłu lub ma trudności z prowadzeniem wartościowych Retrospekcji Sprintu. Młodzi, niedoświadczeni adepci tej sztuki często ograniczają się do jednej dobrze przećwiczonej metody. Najgorzej, kiedy jest to wariacja oparta na plusach i minusach lub ćwiczeniu rozgwiazda. Każdy zespól to widział i szybko się znudzi. Z tego powodu, retrospekcja staje się "koniecznym złem” dla zespołu, nudnym spotkaniem, które nie przynosi żadnej wartości. Zespół przestaje się angażować. Dlatego warto poszerzać warsztat i sprawdzać inne metody. Dzisiaj chciałabym Ci przedstawić Retrospekcję z wykorzystaniem niedawnej zmiany w Scrum Guide - dodanych Wartości Scrum.
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Startup Offshoring from StartupCamp Switzerland 2014Andy Brandt
Offshoring software development for your startup - how to do it, how to do it well? A workshop led by Andy Brandt and David Butler on the StartupCamp Switzerland in Basel in February 2014.
User stories and decomposing requirementsAndy Brandt
This document discusses user stories, which describe features from the perspective of users to help focus product development. User stories have a simple format, typically including the user's role, goal and requested functionality. They promote transparency, focus on users and valuable outcomes. Large or complex stories can be broken down into smaller stories by considering workflows, acceptance criteria and other techniques.
Agile introduction for the American Chamber of Commerce membersAndy Brandt
This document provides an overview of Agile and Scrum. It begins with introducing Agile and its core values as outlined in the Agile Manifesto. It then provides a quick introduction to Scrum, describing the basic components of Scrum including roles, artifacts, and events like Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The document discusses the goals and purpose of each Scrum component and ceremony.
The document discusses the changing role of managers in agile environments. It notes that constant change and increasing complexity require new paradigms for management. The traditional "point-and-tell" approach is no longer adequate, and managers must now indicate general direction and create conditions for self-organizing teams. A key shift is that managers care for team culture and remove impediments, rather than telling teams what to do. The document advocates for creating an environment of trust, transparency, and craftsmanship to support agile ways of working.
1. Agile is still a form of management that focuses on empowering self-organizing teams through establishing the right environment and shielding them from obstacles.
2. Managers are responsible for both the physical workspace and cultural environment that allows teams to thrive, innovate, and feel safe to admit failures.
3. The role of the manager is to care for the mechanisms that support teams such as Scrum Masters, Product Owners, and to intervene only when necessary to remove impediments or resolve deadlocks between teams.
Nas świat przyspiesza, czas wydaje się biegnąć coraz szybciej a zalewający nas potok informacji nie ma końca. Potrzebujemy szybkich i skutecznych metod wytwarzania nowych produktów. W tym celu zostały opracowane metody i frameworki Agile, ze Scrum na czele.
Jest więcej niż bardziej prawdopodobne, że następny projekt, na którym będziesz pracował, lub nowy kontrakt będzie oznaczał pracę według reguł Agile. Organizacje już teraz zaczynają poszukiwać na rynku specjalistów określanych jako Agile Tester. Czy możemy w pełni opisać kim jest i jak działa taka osoba?
Co tester może zrobić, żeby odnieść sukces w nowej sytuacji? Jak trzeba zmienić podejście do swojej roli i sposobu wykonywania pracy. Czy potrzebne są nowe procesy i narzędzia? Czy zmienia się misja testowania? Czy to prawda, że w zespole Scrum są tylko Deweloperzy?
Zapraszam na prezentację podczas której odpowiem na pytania najbardziej nurtujące testerów spotykających Agile na swojej ścieżce zawodowej. Do pełnego zilustrowania profilu Agile Terstera posłużę się modelem popularnie stosowanym w coachingu.
No i stało się. Nadszedł ten dzień, kiedy szef poinformował Cię, że nadszedł czas na zmianę sposobu pracy na Agile. Jeśli miałeś wprowadzenie Agile robione metodą skoku na głęboką wodę, to możesz poczuć się jak szeregowiec Cage, główny bohater filmu z Edge of Tomorrow. Nie ma czasu na wyjaśnienia, weź nowe narzędzia i biegnij. Różnica jest taka, że Ty nie będziesz miał/miała kolejnego podejścia w przypadku porażki projektu.
Patrząc na Manifest Agile z punktu widzenia zarządzania wymaganiami możemy mieć pewne obawy. Zmiana jest mile widziana. Działające oprogramowanie ważniejsze niż wyczerpująca dokumentacja. Współpraca z klientem zamiast negocjowania kontraktu. Czy zmiana jest zawsze możliwa? Czy planowanie jest zbędne? Brak gruntownej wiedzy i wprowadzenie Agile na szybko tworzą kolejne mity. Opowiem jak pracować nad wymaganiami i jak Zespół Scrum może nimi zarządzać.
This document contains slides from a 2010 presentation on testing in Scrum. It discusses key Scrum principles like iterations, self-organizing cross-functional teams, and continuous improvement. The slides cover testing practices like test-driven development, having no separate test team, continuous testing, and automating tests from the unit to GUI levels. User stories and their elements are explained. The document advocates testing that follows the Scrum process and values working software over documentation.
Jest już 2016, a różni guru i instytucje certyfikujące nadal promują pomysł specjalizacji Agile Tester. Jak są rozumiane Agile Tester i Agile Testing? Czy to jest zgodne z ramami Scrum? Czy Agile Testing to tylko techniki XP?
Scrum jest z nami od 1995, ale tak naprawdę pod polskie strzechy zawitał stosunkowo niedawno. W ostatnich pięciu latach zainteresowanie Scrum w Polsce nieustannie rosło. W tej chwili albo już pracujesz w czymś przypominającym Scrum, albo za chwilę będziesz. Developerzy nawet pomimo początkowej ekscytacji szybko zniechęcają się do nowego sposobu pracy. Zaczyna się hejt i marudzenie. Pomimo całej samo-organizacji i zbliżenia do użytkownika pojawia się opór i postawa obronna. Dlaczego tak się dzieje? Czy to problem z developerami? Jak przeciwdziałać problemom i sprawić, żeby praca w Scrum była przyjemna i motywująca? Opowiem o tym podczas mojego wystąpienia.
W trakcie transformacji do Agile jeden z problemów do rozwiązania to umiejscowienie roli analityka w nowej rzeczywistości. Pula rozwiązań wydaje się tutaj mocno ograniczona standardami. Scrum Guide nie wyznacza takiej roli i nie wskazuje co zrobić z analitykiem. A może analityk nie jest w ogóle potrzebny w Agile? Nawet jeśli znajdziemy dla niego miejsce to trudno jest pracować w iteracjach tak, żeby było to wartościowe i efektywne. W swojej pracy widziałem już kilka konfiguracji w mniejszych i większych przedsięwzięciach. Każdy wybór oczywiście ma swoje plusy dodatnie i plusy ujemne. Opowiem zatem jak funckjonowała w moim doświadczeniu analiza biznesowa w środowiskach Agile, w szczególności z zespołami Scrumowymi oraz jakie są opcje rozwiązania sytuacji Analityka.
Wielu Scrum Masterów nie ma pomysłu lub ma trudności z prowadzeniem wartościowych Retrospekcji Sprintu. Młodzi, niedoświadczeni adepci tej sztuki często ograniczają się do jednej dobrze przećwiczonej metody. Najgorzej, kiedy jest to wariacja oparta na plusach i minusach lub ćwiczeniu rozgwiazda. Każdy zespól to widział i szybko się znudzi. Z tego powodu, retrospekcja staje się "koniecznym złem” dla zespołu, nudnym spotkaniem, które nie przynosi żadnej wartości. Zespół przestaje się angażować. Dlatego warto poszerzać warsztat i sprawdzać inne metody. Dzisiaj chciałabym Ci przedstawić Retrospekcję z wykorzystaniem niedawnej zmiany w Scrum Guide - dodanych Wartości Scrum.
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Startup Offshoring from StartupCamp Switzerland 2014Andy Brandt
Offshoring software development for your startup - how to do it, how to do it well? A workshop led by Andy Brandt and David Butler on the StartupCamp Switzerland in Basel in February 2014.
User stories and decomposing requirementsAndy Brandt
This document discusses user stories, which describe features from the perspective of users to help focus product development. User stories have a simple format, typically including the user's role, goal and requested functionality. They promote transparency, focus on users and valuable outcomes. Large or complex stories can be broken down into smaller stories by considering workflows, acceptance criteria and other techniques.
Agile introduction for the American Chamber of Commerce membersAndy Brandt
This document provides an overview of Agile and Scrum. It begins with introducing Agile and its core values as outlined in the Agile Manifesto. It then provides a quick introduction to Scrum, describing the basic components of Scrum including roles, artifacts, and events like Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The document discusses the goals and purpose of each Scrum component and ceremony.
The document discusses the changing role of managers in agile environments. It notes that constant change and increasing complexity require new paradigms for management. The traditional "point-and-tell" approach is no longer adequate, and managers must now indicate general direction and create conditions for self-organizing teams. A key shift is that managers care for team culture and remove impediments, rather than telling teams what to do. The document advocates for creating an environment of trust, transparency, and craftsmanship to support agile ways of working.
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
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/
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