SCRUM DLA OPORNYCH. porady, tricki i dobre praktyki

Transkrypt

1 SCRUM DLA OPORNYCH porady, tricki i dobre praktyki

2 Spis treści Wstęp Zwinny Scrum Scalony zespół Wydajny Sprint Praktyki techniczne Używaj Scruma, bo warto! Czym jest Scrum? Tradycyjna metoda pracy wobec zwinnej Wartości to podstawa! 3 filary Scruma Zespół scrumowy Role w zespole Zadanie zespołu Backlog produktu Zdarzenia w Scrumie Planowanie Sprintu Przebieg Sprintu Retrospekcja Sprintu Test Driven Development Pair Programming Domain-Driven Design Słowo od eksperta

3 Używaj Scruma, bo warto! Scrum to zwinna metoda zarządzania projektami. Jej filozofia i wartości, na których jest zbudowana, rewolucjonizują współczesną praktykę menedżerską. Jeśli chcesz przeprowadzić z sukcesem projekt - sięgnij po Scruma. Dlaczego warto? Wyjątkowo lekki Łatwy do zrozumienia Uniwersalny do zastosowania Pamiętaj! Scrum jest dla wszystkich, ale nie każdy potrafi z niego skorzystać. Pokażemy Ci, jak to zrobić najlepiej!

4 Zwinny Scrum 1

5 Czym jest Scrum? W Polsce coraz więcej firm IT wprowadza zwinne metodyki zarządzania (ang. agile), które mają pomóc w dostarczeniu rozwiązań w taki sposób, aby zmaksymalizować wartość dla klienta. Czym jest Scrum? Jego autorzy, Ken Schwaber i Jeff Sutherland, podają definicję w swoim przewodniku Scrum Guide, 2016: Ramy postępowania (ang. framework), dzięki którym ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości. Dla kogo jest Scrum? Każdy zespół mający do wykonania projekt może skorzystać ze zwinnych metod działania. Ale uwaga! Stosowanie Scruma natychmiast uwidacznia problemy i anomalie projektu i organizacji. Scrum promuje kooperację, przejrzystość i ciągłe doskonalenie. Stawia na ludzi i interakcje między nimi, umożliwia szybkie reagowanie na zmiany i regularne dostarczanie wartościowych produktów. Czy wiesz, że? Poza Scrumem powstał cały szereg innych zwinnych metodyk (Feature-Driven Development, Crystal, APM, itp.) Jednak to Scrum ze względu na swoją prostotę stał się najbardziej popularny. Warto jednak zaglądać do praktyk proponowanych przez inne metodyki.

6 Tradycyjna metoda pracy wobec zwinnej Scrum zapobiega głównym problemom, występującym zwykle w zarządzaniu projektami. Tradycyjna metoda Ryzyko niezrozumienia wymagań produktu. Konieczność podejmowania decyzji na początku projektu. Finalizowanie produktu przed pokazaniem klientowi. Niewiele informacji zwrotnych w trakcie trwania projektu. Ryzyko przekroczenia terminu i budżetu. A B Deadline Zwrot do klienta C Zwinna metoda Dostarczanie produktu najbliższego oczekiwaniom klienta. Możliwość odłożenia decyzji w czasie (ang. last responsible moment). Pozostawia miejsce na zmiany i feedback. Płynna produktywność i oszczędność energii. Pozwala na elastyczność budżetową. A 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 B Sprint Dzięki realizacji projektu w kolejności od najbardziej wartościowych funkcjonalności (oraz najbardziej ryzykownych biznesowo), do dodatkowych opcji nice to have, pozostawiamy klientowi decyzję, kiedy projekt jest wystarczająco dobry i spełnia jego potrzeby.

7 Wartości to podstawa! Scrum jest łatwy do zrozumienia, ale wymagający przy wdrożeniu. Powodzenie w jego wykorzystaniu zależy od biegłości postępowania zgodnie z pięcioma poniższymi wartościami. W nowej wersji przewodnika z 2016 r. Ken Schwaber i Jeff Sutherland zidentyfikowali 5 podstawowych wartości, na których opiera się Scrum: 1 Zaangażowanie 2 Odwaga 3 Koncentracja 4 Otwartość 5 Szacunek Czy wiesz, że już w 1999 te same wartości wyraził i opisał Kent Beck jako podstawę metodyki Extreme Programming? Lepiej późno niż wcale, Scrumie! Praktyki Zasady Wartości Codzienne praktyki (ang. pratices) wynikają z wdrożenia zasad (principales), a te z kolei opierają się na wspólnych wartościach (values). Scrum składa się zaledwie z kilkunastu elementów podzielonych na role, wydarzenia, narzędzia i reguły.

8 3 filary Scruma Jeżeli wdrożyliśmy 5 podstawowych wartości, na których opiera się Scrum, to zrobiliśmy tym samym miejsce na wprowadzenie 3 filarów Scruma. 1 Przejrzystość 2 Inspekcja 3 Adaptacja Wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Muszą być tak opisane, aby wszyscy tak samo je rozumieli i mogli posługiwać się wspólnym nazewnictwem. Np. osoby wykonujące pracę i osoby akceptujące wyniki tej pracy muszą posługiwać się wspólną definicją ukończonej pracy. Przejrzystość pozwala wszystkim poznać rzeczywisty stan projektu. Wszyscy korzystający ze Scruma muszą poddawać częstej inspekcji postępy w realizacji celu, żeby wykrywać niepożądane rozbieżności. Analiza tego, co się dzieje w zespole, produkcie czy organizacji, pozwala szybko zauważyć problemy, np. wolny czas odpowiedzi systemu, ale również możliwości, np. pojawia się nowa fukcjonalność otwierająca nowe rynki. Inspekcje nie powinny być zbyt częste, inaczej będą przeszkodą w wykonywaniu pracy. Jeżeli osoba dokonująca inspekcji ustali, że jeden lub więcej aspektów procesu wykracza poza przyjęte limity oraz że wytwarzany w ten sposób produkt nie będzie akceptowalny, proces lub przetwarzany materiał muszą zostać skorygowane. Korekta musi być wykonana jak najszybciej, by ograniczyć dalsze odstępstwa. Może to być na przykład zmiana zakresu, technologii czy zmiana sposobu działania zespołu.

9 Słowo od eksperta Scrum znakomicie zwiększa przejrzystość procesu. Wszelkie problemy szybko wychodzą na jaw. Scrum pozwala zauważać i poprawiać nieefektywności w zarządzaniu czy w praktykach technicznych. Dzięki temu zespoły dostarczają zrealizowane funkcjonalności regularnie i mogą dostosowywać kierunek prac do feedbacku ze strony użytkowników. Krzysztof Jelski Head of Trainings, Pragmatists Obserwuję, że wiele firm wdraża Scruma i myśli, że to załatwia całą sprawę prowadzenia projektu. To duży błąd. Scrum jest tylko lekkim zestawem reguł postępowania, które trzeba uzupełnić o działania zarządcze i praktyki techniczne. Pułapką jest luzowanie reguł Scruma, gdy zespół nie jest w stanie dostarczać działającego produktu co 1-2 tygodnie. Wtedy tracimy główne korzyści płynące z agile - szybszy feedback, szybszy time-to-market, możliwość adaptacji.

10 Scalony zespół 2

11 Zespół scrumowy W skład zespołu scrumowego wchodzą: właściciel produktu (ang. Product Owner), zespół deweloperski (ang. Development Team) oraz Scrum Master. Zespoły scrumowe są samoorganizujące się i międzyfunkcjonalne. Mają swobodę decyzyjną w zakresie niezbędnym do wytworzenia wysokiej jakości produktu, w tym wyboru stosowanych procedur i narzędzi i nie są w żaden sposób kierowane przez osoby spoza zespołu. Development Scrum - różne role, jeden cel! Dostarczają produkty iteracyjnie, czyli powtarzalnie oraz przyrostowo (ang. increment), zwiększając szanse na wczesne uzyskanie informacji zwrotnej. Klient bądź jego reprezentant biorą aktywny udział w procesie wytwórczym. Iteracje pozwalają zespołowi osiągnąć definicję zrobionego w każdym sprincie oraz, ostatecznie, produktu finalnego. Architect Tester Developer Scrum Master GUI Developer Product Owner

12 Role w zespole Product Owner Jest nosicielem i strażnikiem wizji produktu. Opowiada za budżet projektu. Pracuje w ścisłej łączności z zespołem - dostarcza feedback, zarządza zmianami, podejmuje decyzje. Odpowiada na pytania zespołu podczas całego projektu. Odpowiada za backlog produktu i user stories (historie użytkowników). Koncentruje się na maksymalizacji zysku z inwestycji. Product Owner jest klientem zespołu skupiającym się na stronie biznesowej przedsięwzięcia. Scrum Master Mistrz Scruma, który dba o jego prawidłowe wdrażanie. Pracuje zarówno z zespołem, Product Ownerem jak i całą organizacją. Upewnia się, że zespół jest optymalnie produktywny. Przyjmuje rolę zarządzającego w stylu partypacyjnym, a nie szefa projektu. Chroni zespół przed zewnętrznymi czynnikami i usuwa przeszkody stojące na jego drodze. Pokazuje im narzędzia pomocne w ich pracy.

13 Zadanie zespołu Mimo zróżnicowanych ról zespół ma wspólny cel, który spaja jego członków i pozwala na produktywną pracę. Zespół ma za zadanie przekształcić potrzeby wyrażone przez właściciela produktu w użyteczne funkcjonalności. Zespół deweloperski Zespół jest multidyscyplinarny (deweloperzy, graficy), złożony z profesjonalistów, których zadaniem jest dostarczenie na zakończenie każdego sprintu, gotowego do potencjalnego wydania przyrostu produktu. Dąży do wytworzenia ducha zespołowego (wszyscy jesteśmy na tej samej łódce). scrum nie uznaje podzespołów w zespole deweloperskim. Architect Tester Senior Developer Tester Junior Developer GUI Developer Członkowie zespołu deweloperskiego mogą posiadać wyspecjalizowane umiejętności, ale odpowiedzialność za pracę ponosi zawsze cały zespół.

14 Backlog produktu Właściciel produktu jest odpowiedzialny za maksymalizację wartości produktu i pracy zespołu deweloperskiego. Odpowiada za backlog produktu. Właściciel produktu jest jedyną osobą zarządzającą backlogiem produktu (ang. Product Backlog). Aby właściciel produktu mógł odnieść sukces, cała organizacja musi respektować jego decyzje, które są odzwierciedlone w treści i kolejności elementów backlogu produktu. Właściciel produktu to pojedyncza osoba, nie komitet. Może reprezentować interesy grupy osób, lecz osoby chcące zmienić priorytet elementu backlogu produktu, muszą zwrócić się do właściciela produktu. Backlog produktu Formalizuje wizję produktu, który chcemy zrealizować. Opisuje główne cele użytkowników, do których chcemy dotrzeć. Działa jak przewodnik i scala członków projektu. Pozwala priorytetyzować te wymagania, które dostarczają największej wartości (albo największego ROI) interesariuszowi. Może ewoluować w ciągu trwania projektu.

15 Wydajny sprint 3

16 Zdarzenia w Scrumie Zdarzenia opisane w Scrumie są używane do wprowadzenia regularności i przejrzystości procesu. Wszystkie zdarzenia są ograniczone czasowo, co oznacza, że maksymalny czas ich trwania jest ustalony z góry. 1 Planowanie sprintu 2 Codzienny Scrum 3 Przegląd sprintu 4 Retrospekcja sprintu Każde ze zdarzeń w Scrumie, oprócz sprintu, który zawiera w sobie pozostałe zdarzenia, jest okazją do przeprowadzenia inspekcji i dokonania adaptacji. Zdarzenia te są specjalnie zaprojektowane w taki sposób, aby zapewnić przejrzystość i umożliwić inspekcję. Nieuwzględnienie któregokolwiek z nich redukuje przejrzystość i zaprzepaszcza szansę na dokonanie inspekcji i adaptacji. Czas trwania sprintu jest ustalany w chwili jego rozpoczęcia i nie może być skracany ani wydłużany. Pozostałe zdarzenia mogą się kończyć, kiedy tylko ich cel zostanie osiągnięty, co umożliwia wykorzystanie odpowiedniej ilości czasu i zabezpiecza przed jego marnotrawieniem.

17 Planowanie sprintu W planowaniu sprintu biorą udział wszyscy członkowie zespołu scrumowego. Sprint Backlog Zespół robi estymację czasu dla każdej czynności, która pozwoli przełożyć wymagania na funkcjonalności na koniec sprintu. Idealnie jest podzielić projekt na relatywnie krótkie odcinki, mniejsze lub równe 2 dniom roboczym. Działania, które są do zrealizowania w ciągu jednego sprintu są zcentralizowane w backlogu sprintu. Chodzi o oszacowanie, a nie o twarde zobowiązanie. Pozwala zespołowi na jasną wizję tego, co jest do zrobienia Uwaga! Agile nie musi mieć iteracji. Zwinne metodyki opierające się na systemie Kanban zamieniają regularność i przewidywalność czasową sprintu na minimalizację czasu niezbędnego do realizacji pojedynczej funkcjonalności oraz maksymalizację przepływu realizowanych funkcjonalności.

18 Codzienny Scrum Codzienny Scrum (stand up) jest zdarzeniem dla zespołu deweloperskiego, ograniczonym czasowo do piętnastu minut, podczas którego bieżące działania są synchronizowane i powstaje plan na najbliższe dwadzieścia cztery godziny. Co zrobiłem od ostatniego spotkania? Co zrobię w następnym kroku? Jakie trudności napotkałem lub jakich się spodziewam? Codzienna synchronizacja max 15 min.

19 Przegląd sprintu Przegląd sprintu to spotkanie organizowane na zakończenie sprintu w celu przeprowadzenia inspekcji przyrostu i, jeśli zajdzie taka potrzeba, dostosowania backlogu produktu. max 15 min. start koniec SPRINT max. od 2 do 4 tygodni stały feedback od klienta Zespół koncentruje się na wypełnianiu zadań z backlogu sprintu Uwaga! Najtrudniejszą do zrealizowania, a najprostszą do zarzucenia praktyką jest faktyczne dostarczanie na koniec każdego sprintu gotowego do potencjalnego wydania przyrostu produktu. W naszej ocenie to właśnie dotrzymywanie tej praktyki określa stopień zwinności procesu. Wszystkie inne praktyki można dostosowywać w zależności od dojrzałości zespołu, rodzaju projektu, szczególnego kontekstu itp.

20 Retrospektywa sprintu Tutaj każda osoba z zespołu wypowiada się : z czego jest zadowolona, co poszło nie tak, co można usprawnić? Umożliwia to szybkie wyłapanie błędów w procesie i reakcję na nie. Retrospektywę moderuje Scrum Master Retrospektywa sprintu odbywa się po zakończeniu przeglądu i wstęp na nią ma jedynie zespół scrumowy. Następuje również identyfikacja dobrych praktyk, które powinny być stosowane w następnych iteracjach i ustalenie planu, w jaki sposób będą one wdrażane w codziennej praktyce zespołu. Najważniejsze ustalenia 1 godzina na każdy tydzień trwania sprintu Punkty dodatnie i punkty ujemne Jak się doskonalić? Feedback od klienta Przygotowanie kolejnego sprintu

21 Praktyki techniczne 4

22 Sam Scrum nie wystarczy Scrum jest dobry dla ludzi, ale nie definiuje, jak kodować. Do tego potrzebujesz praktyk technicznych. 1 Test-Driven Development 2 Pair Programming 3 Domain Driven Design Obniżenie odsetka błędów. Kod tańszy w utrzymaniu. Stabilny rozwój produktu. Jeszcze niższy odsetek błędów. Prostota rozwiązań. Większa produktywność. Trwałe podstawy pracy. Jednolite rozumienie domeny. Lepsze rozumienie wymagań biznesowych. Czy wiesz, że? Większość zwinnych praktyk programistycznych pochodzi z metodyki Extreme Programming. Najlepsze zespoły scrumowe są często w realizacji procesu dużo bliższe XP niż scrumowi: stosują 1-tygodniowe iteracje, korzystają z pomocy coach'a zamiast Scrum Mastera, stosują praktykę codziennych release ów (albo wręcz continuous delivery), pracują w parach i automatyzują wszystko, co się da.

23 Test Driven Development TDD to sprawdzona metoda działania, pozwalająca na ciągłe dbanie o jakość, na każdym etapie projektu. +1 Nieprzechodzący test Test driven development Udana refaktoryzacja Implementacja spełniająca test Czy wiesz, że? Rozpoczynanie prac od testów stosowali inżynierowie Projeku Mercury w NASA we wczesnych latach 60. Przy okazji: pracowali w półdniowych iteracjach. Agile i TDD to coś nowego? Raczej nie.

24 Pair programming Dwie osoby pracują razem przy jednym komputerze, nad tym samym zadaniem. Co dwie głowy, to nie jedna. Ciągła komunikacja prowadzi do najlepszych projektów. Intensywny kontakt z równym sobie partnerem prowadzi do wzrostu produktywności. Czy wiesz, że? Autorzy książki Pair Programming Illuminated, Laurie Williams i Robert Kessler, przytaczają wiele wyników badań naukowych dotyczących tej pratyki. Wynika z nich, że to bardzo efektywny sposób pracy!

25 Domain-Driven Design Zespół modeluje rozwiązanie z udziałem ekspertów domenowych. Następnie za pomocą sprawdzonych wzorców DDD wyraża Kod odzwierciedla ekspercką wiedzę z dziedziny Wszyscy używają jednolitego języka Dobrze podzielony projekt łatwo testować i rozwijać Czy wiesz, że? Domain-Driven Design definiuje zarówno przydatne wzorce programistyczne, jak również sposoby prowadzenia warsztatów z modelowania z udziałem ekspertów domenowych. Większość korzyści osiąganych dzięki wprowadzaniu popularnej architektury mikroserwisów odniesiesz stosując wzorzec DDD o nazwie Bounded Context.

26 Szkolenia Pragmatists Przez 7 lat pracy mentorskiej pomogliśmy wielu zespołom zmienić sposób, w jaki pracują i współdziałają. Uczymy tego, co sami stosujemy. 1 Trening przy biurku 2 Trwałe podstawy 3 Wspomagany rozwój Twoi ludzie pozostaną przy prowadzonych projektach. Zobaczysz efektywny transfer wiedzy, dzięki pracy 1 na 1. Wyposażysz zespół w nowe umiejętności do zastosowania natychmiast w praktyce. Zobaczysz, jak rozwijają oprogramowanie najlepsi programiści. Dowiesz się, co jest potrzebne, żeby szybko dostarczać działające funkcjonalności. Zapłacisz za samą esencję wiedzy. Wzmocnisz to, co służy częstemu dostarczaniu wartości klientom. Zbudujesz z nami nawyk ciągłego doskonalenia umiejętności. Zadbasz o długofalowe efekty.

27 Potrzebujesz dalszych wskazówek? Skontaktuj się z nami: szymon.pruszyński@pragmatists.pl