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.
"Gram w Scrum - Zaprojektuj centrum" to gra symulacyjna, w trakcie której gracze, projektując przestrzeń wokół Pałacu Kultury, przyswajają sobie założenia metodyki Scrum, które będą mogli wykorzystać w realizowanych przez siebie projektach.
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.
"Gram w Scrum - Zaprojektuj centrum" to gra symulacyjna, w trakcie której gracze, projektując przestrzeń wokół Pałacu Kultury, przyswajają sobie założenia metodyki Scrum, które będą mogli wykorzystać w realizowanych przez siebie projektach.
Prezentacja z pierwszego Jesiennego Wieczoru Scrum organizowanego przez Fluid Circle (fluidcircle.net).
Uwaga: nowsza wersja tej prezentacji pochodzące z Wiosennych Wieczorów ze Scrum znajduje się tutaj: http://www.slideshare.net/FluidCircle/wiosenne-wieczory-ze-scrum-1-rzut-okiem-na-scrum
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Prezentacja dotycząca wykorzystania Scruma w procesie reorientacji firmy na dostarczanie wartości. Przedstawiona na konferencji Zarządzanie Projektami: Agile w biznesie, organizowanej przez Computerworld, 19-20 czerwca 2012 w Warszawie.
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ń.
Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadcza...PMI Szczecin
Prezentacja Michała Koniewicza z 9. spotkania PMI Szczecin w dn. 22 marca 2016 r., pn. "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie".
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
Prezentacja zawiera podstawowe informacje na temat Agile i głównie frameworka Scrum. Znajdziecie w niej wiadomości dotyczące wartości Scruma, Zespołu Scrumowego, Zdarzeń w Scrumie oraz Artefaktów Scruma. Ponadto dodałem też dodatkowe informacje związane z kilkoma praktykami Agile.
Prezentacja jest okrojoną wersją używanej przeze mnie podczas szkoleń warsztatowych stąd znajdziecie w niej informacje w większości teoretyczne.
Jak prowadzić projekty informatyczne zwinną metodyką SCRUM. Czym ta metodyka różni się od podejścia tradycyjnego. Porównanie zwinnego i niezwinnego prowadzenia projektów informatycznych z przykładami i konsekwencjami.
Scrum Studio - Lukasz Filut@Scrum Experience Day 2020Łukasz Filut
Scrum Studio i wyzwania, które napotyka w czerwonych i pomarańczowych organizacjach. Dzielę się swoimi doświadczeniami i receptami, które w tym przypadku uruchomiły Scruma w niełatwym środowisku.
Prezentacja powstała na potrzeby webinara pt. Praca testera w Scrumie.
Podczas webinara Ola Woszczyk- testerka z testuj.pl, opowiedziała, o tym czym jest SCRUM i jak wygląda praca w zespole Scrumowym. Ponadto wyjaśniła, jaką rolę w Scrumie pełni tester i jakie najczęstsze błędy popełniają członkowie zespołu.
Prezentacja dostępna jest jako kolejny slajd po wyświetlonym filmie.
Prezentacja z wykładu na temat roli analityka IT w zespole stosującym metodyki Agile takich jak SCRUM, XP czy Kanban. Prezentacja pokazuje także jak budować kompetencje zwinnego analityka. Wykład został wygłoszony podczas konferencji beIT 2015 na Politechnice Gdańskiej, a także na spotkaniu gdańskiej grupy SPIN.
Kwartał z Kanbanem #3:Kanban a Teoria OgraniczeńJakub Drzazga
Niewiele osób wie, że Metoda Kanban wywodzi się bezpośrednio z Teorii Ograniczeń (Theory of Constraints). Nie ukrywam, że oba te podejścia są dla mnie źródłem niewyczerpanej inspiracji.
Podczas warsztatów dowiesz się czym jest Teoria Ograniczeń oraz jaki miała i ma wpływ na metodę Kanban. Jednak najważniejsze jest to jak zastosować ją do optymalizacji przepływu. Tak abyśmy mieli większy Przerób (Throughput), krótszy Czas Realizacji (Lead Time) oraz byli bardziej przewidywalni dla naszych klientów.
Last but not least – prymusów zachęcamy do przeczytania książki „Cel” autorstwa Eliyahu M. Goldratta :)
Bio prelegenta:
Jakub Drzazga posiada doświadczenie z najróżniejszych obszarów powiązanych z projektami IT. Obecnie robi to co lubi najbardziej: jest konsultantem i szkoleniowcem.
Od wielu lat pomaga organizacjom począwszy od start upów na korporacjach kończąc rozwiązywać najróżniejsze problemy. Gdy wymaga tego sytuacja dołącza do projektu i pomaga wyprowadzić go z krytycznej sytuacji. Nie akceptuje kosmetycznych zmian i podążania za projektowa modą. Jeżeli pomaga wdrażać w organizacji Kanbana albo Scruma to tylko po to aby wytwarzano lepszy software spełniający oczekiwania i potrzeby użytkowników.
Testy wydajnościowe to nie tylko JMeter. Podobnie jak w przypadku testów automatycznych, liczba frameworków do badania wydajności stale rośnie. Poza wprowadzeniem w tematykę testów wydajnościowych, w trakcie prezentacji przyjrzymy się ich implementacji we frameworku k6. Opowiemy również dlaczego w The Software House postawiliśmy na jego wybór i jak dzięki prostym skryptom testowym zoptymalizowaliśmy kilka naszych projektów.
Wbrew powszechnym opiniom, nie tak prosto jest zrobić dobre Code Review. Robione w pośpiechu, tylko po to by je "odbębnić", często stwarza więcej szkody niż pożytku. Opowiem wam dlaczego code review jest ważne i jak wykorzystać ten proces aby upewnić się, że napisany kod jest najwyższej jakości. Będę nie tylko mówił o tym kto powinien robić code reviews, i dla kogo, jakie informacje są potrzebne do przeprowadzenia skutecznego code review, ale także jak zrobić dobre code review w najkrótszym możliwym czasie.
Prezentacja z pierwszego Jesiennego Wieczoru Scrum organizowanego przez Fluid Circle (fluidcircle.net).
Uwaga: nowsza wersja tej prezentacji pochodzące z Wiosennych Wieczorów ze Scrum znajduje się tutaj: http://www.slideshare.net/FluidCircle/wiosenne-wieczory-ze-scrum-1-rzut-okiem-na-scrum
Scrum - iteracyjna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile.
Prezentacja znaleziona w śmieciach na dysku :) Wykonana w 2004 roku
Prezentacja dotycząca wykorzystania Scruma w procesie reorientacji firmy na dostarczanie wartości. Przedstawiona na konferencji Zarządzanie Projektami: Agile w biznesie, organizowanej przez Computerworld, 19-20 czerwca 2012 w Warszawie.
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ń.
Michał Koniewicz - "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadcza...PMI Szczecin
Prezentacja Michała Koniewicza z 9. spotkania PMI Szczecin w dn. 22 marca 2016 r., pn. "SCRUM - jak ugryźć i nie połamać sobie zębów - doświadczalnie".
Scrum (Polish version) - wprowadzenie do frameworkaalbrzykowski
Prezentacja zawiera podstawowe informacje na temat Agile i głównie frameworka Scrum. Znajdziecie w niej wiadomości dotyczące wartości Scruma, Zespołu Scrumowego, Zdarzeń w Scrumie oraz Artefaktów Scruma. Ponadto dodałem też dodatkowe informacje związane z kilkoma praktykami Agile.
Prezentacja jest okrojoną wersją używanej przeze mnie podczas szkoleń warsztatowych stąd znajdziecie w niej informacje w większości teoretyczne.
Jak prowadzić projekty informatyczne zwinną metodyką SCRUM. Czym ta metodyka różni się od podejścia tradycyjnego. Porównanie zwinnego i niezwinnego prowadzenia projektów informatycznych z przykładami i konsekwencjami.
Scrum Studio - Lukasz Filut@Scrum Experience Day 2020Łukasz Filut
Scrum Studio i wyzwania, które napotyka w czerwonych i pomarańczowych organizacjach. Dzielę się swoimi doświadczeniami i receptami, które w tym przypadku uruchomiły Scruma w niełatwym środowisku.
Prezentacja powstała na potrzeby webinara pt. Praca testera w Scrumie.
Podczas webinara Ola Woszczyk- testerka z testuj.pl, opowiedziała, o tym czym jest SCRUM i jak wygląda praca w zespole Scrumowym. Ponadto wyjaśniła, jaką rolę w Scrumie pełni tester i jakie najczęstsze błędy popełniają członkowie zespołu.
Prezentacja dostępna jest jako kolejny slajd po wyświetlonym filmie.
Prezentacja z wykładu na temat roli analityka IT w zespole stosującym metodyki Agile takich jak SCRUM, XP czy Kanban. Prezentacja pokazuje także jak budować kompetencje zwinnego analityka. Wykład został wygłoszony podczas konferencji beIT 2015 na Politechnice Gdańskiej, a także na spotkaniu gdańskiej grupy SPIN.
Kwartał z Kanbanem #3:Kanban a Teoria OgraniczeńJakub Drzazga
Niewiele osób wie, że Metoda Kanban wywodzi się bezpośrednio z Teorii Ograniczeń (Theory of Constraints). Nie ukrywam, że oba te podejścia są dla mnie źródłem niewyczerpanej inspiracji.
Podczas warsztatów dowiesz się czym jest Teoria Ograniczeń oraz jaki miała i ma wpływ na metodę Kanban. Jednak najważniejsze jest to jak zastosować ją do optymalizacji przepływu. Tak abyśmy mieli większy Przerób (Throughput), krótszy Czas Realizacji (Lead Time) oraz byli bardziej przewidywalni dla naszych klientów.
Last but not least – prymusów zachęcamy do przeczytania książki „Cel” autorstwa Eliyahu M. Goldratta :)
Bio prelegenta:
Jakub Drzazga posiada doświadczenie z najróżniejszych obszarów powiązanych z projektami IT. Obecnie robi to co lubi najbardziej: jest konsultantem i szkoleniowcem.
Od wielu lat pomaga organizacjom począwszy od start upów na korporacjach kończąc rozwiązywać najróżniejsze problemy. Gdy wymaga tego sytuacja dołącza do projektu i pomaga wyprowadzić go z krytycznej sytuacji. Nie akceptuje kosmetycznych zmian i podążania za projektowa modą. Jeżeli pomaga wdrażać w organizacji Kanbana albo Scruma to tylko po to aby wytwarzano lepszy software spełniający oczekiwania i potrzeby użytkowników.
Testy wydajnościowe to nie tylko JMeter. Podobnie jak w przypadku testów automatycznych, liczba frameworków do badania wydajności stale rośnie. Poza wprowadzeniem w tematykę testów wydajnościowych, w trakcie prezentacji przyjrzymy się ich implementacji we frameworku k6. Opowiemy również dlaczego w The Software House postawiliśmy na jego wybór i jak dzięki prostym skryptom testowym zoptymalizowaliśmy kilka naszych projektów.
Wbrew powszechnym opiniom, nie tak prosto jest zrobić dobre Code Review. Robione w pośpiechu, tylko po to by je "odbębnić", często stwarza więcej szkody niż pożytku. Opowiem wam dlaczego code review jest ważne i jak wykorzystać ten proces aby upewnić się, że napisany kod jest najwyższej jakości. Będę nie tylko mówił o tym kto powinien robić code reviews, i dla kogo, jakie informacje są potrzebne do przeprowadzenia skutecznego code review, ale także jak zrobić dobre code review w najkrótszym możliwym czasie.
Podzielę się z Wami zaobserwowanymi praktykami, które są kluczowe dla każdego zespołu dostarczającego produkt w oparciu o moje doświadczenia jako deweloper, system inżynier i leader zespołu.
Prezentacja ze spotkania itSMF Pomorze. Krótko - jak połączyć wymagania modeli Corporate Governance i możliwość zwinnego wytwarzania produktów w SCRUM.
InfoShare 2014: Skok na naderwanym bungee, czyli agile bez automatyzacjiJIT Solutions
Prezentacja z wykładu prowadzonego przez Witka Boła i Bartka Ziębę o automatyzacji procesów wytwórczych w zespołach softwareowych. Prezentacja odbyła się w ramach konferencji InfoShare 2014, 22.05.2014 w Gdańsku.
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.
2. PO CO CHCEMY
SKALOWAĆ?
• BY ROBIĆ WIĘCEJ?
• BY ROBIĆ SZYBCIEJ?
• BY ZDĄŻYĆ NA JAKIŚ TERMIN?
• BO MAMY DUŻO LUDZI I ZAKŁADAMY, ŻE WSZYSCY SĄ POTRZEBNI?
3. ZANIM DODASZ
KOLEJNY ZESPÓŁ…
• WYKORZYSTAĆ REZERWY WYDAJNOŚCI W ISTNIEJĄCYM ZESPOLE.
• PRZEMYŚLEĆ ZAKRES, UNIKAĆ BUDOWANIA RZECZY ZBĘDNYCH (W.G.
BADAŃ JEDEN Z GŁÓWNYCH CZYNNIKÓW MARNOTRAWSTWA).
• BRAĆ POD UWAGĘ, ŻE ZWIĘKSZANIE ZESPOŁÓW NIESIE ZA SOBĄ
PROBLEMY, KTÓRE PRZYRASTAJĄ Z WIELKOŚCIĄ SZYBCIEJ NIŻ
KORZYŚCI. KORZYŚĆ Z KAŻDEJ KOLEJNEJ DODANEJ OSOBY DO JEST
CORAZ MNIEJSZA.
4. 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
11. 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.
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 – MODUŁOWA METODA SKALOWANIA JEFFA
SUTHERLANDA - HTTP://WWW.SCRUMINC.COM/SCRUM-AT-SCALE-
PART-I/
• NEXUS – METODA SKALOWANIA KENA SCHWABERA -
14. 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.
15. 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ę.
16. 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
17. 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.
18. 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).
19. 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
20. 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
21. 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
24. 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
• CAŁOŚĆ DZIAŁA W OPARCIU O STEROWANĄ METRYKAMI PRZEJRZYSTOŚĆ
25. 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ę
26. SCRUM AT SCALE
Pętla procesowa
Zapewniać
koordynację i
komunikację
między zespołami.
Zbierać problemy i je
rozwiązywać
usprawniając proces.
29. 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
30. 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
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?