SCRUM jak pracować wydajniej i scalić zespół
Spis treści 1 Wstęp Używaj Scruma, bo warto! 2 3 Zwinny Scrum Scalony zespół Czym jest Scrum? Zespół scrumowy Zdarzenia w Scrumie Test Driven Development Tradycyjna metoda pracy wobec zwinnej Role w zespole Planowanie sprintu Pair Programming Zadanie zespołu Przebieg sprintu Domain-Driven Design Backlog produktu Retrospekcja sprintu Wartości to podstawa! 3 filary Scruma Słowo od eksperta Wydajny Sprint 4 Praktyki techniczne
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 Główne koncepty Backlog produktu lista pożądanych oczekiwań, wymagań i funkcjonalności produktu, udoskonalana podczas całego projektu. Sprint inaczej iteracja to okres, kiedy zespół tworzy zdefiniowany przyrost produktu. Sprint trwa od 1 do 2 tygodni. Inspekcja regularne sprawdzanie, czy wszystko idzie zgodnie z planem, w celu reagowania na problemy lub nowe możliwości. Ewentualne problemy Trudny do wdrożenia Wymaga systematyczności Obnaża słabości zespołu Pamiętaj! Scrum jest dla wszystkich, ale nie każdy potrafi z niego skorzystać. Pokażemy Ci, jak to zrobić najlepiej!
Zwinny Scrum 1
Czym jest Scrum? W Polsce coraz więcej firm IT wprowadza zwinne metodyki zarządzania (ang. agile), które mają pomóc w dostarczaniu rozwiązań w taki sposób, aby zmaksymalizować wartość dla klienta. Czym jest Scrum? 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.
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 Zwrot do klienta C Deadline 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 2 3 4 5 6 Sprint Sprint Sprint Sprint Sprint 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. B
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 Lorem ipsum 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 Czy wiesz, że już w 1999 r. 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. Szacunek
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ść 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. 2 Inspekcja 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. 3 Adaptacja 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.
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. 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. Krzysztof Jelski Head of Trainings, Pragmatists 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.
Scalony zespół 2
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. Zespół scrumowy - 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. Architect Iteracje pozwalają zespołowi osiągnąć definicję zrobionego w każdym sprincie oraz, ostatecznie, produktu finalnego. Tester Developer Scrum Master GUI Developer Product Owner
Role w zespole Product Owner Scrum Master Jest nosicielem i strażnikiem wizji produktu. Mistrz Scruma, który dba o jego prawidłowe wdrażanie. Opowiada za budżet projektu. Pracuje zarówno z zespołem, Product Ownerem jak i całą organizacją. Pracuje w ścisłej łączności z zespołem dostarcza feedback, zarządza zmianami, podejmuje decyzje. Upewnia się, że zespół jest optymalnie produktywny. Odpowiada na pytania zespołu podczas całego projektu. Przyjmuje rolę zarządzającego w stylu partypacyjnym, a nie szefa projektu. Odpowiada za backlog produktu (ang. product backlog) i historie użytkowników (ang. user stories). Chroni zespół przed zewnętrznymi czynnikami i usuwa przeszkody stojące na jego drodze. Koncentruje się na maksymalizacji zysku z inwestycji. Pokazuje im narzędzia pomocne w ich pracy. Jest klientem zespołu skupiającym się na stronie biznesowej przedsięwzięcia.
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. Członkowie zespołu deweloperskiego mogą posiadać wyspecjalizowane umiejętności, ale odpowiedzialność za pracę ponosi zawsze cały zespół. Architect Tester Senior Developer Tester Junior Developer GUI Developer
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. 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.
Wydajny sprint 3
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 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. 4 Retrospekcja sprintu 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.
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.
Codzienny Scrum Codzienny Scrum (ang. 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.
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. szymon.pruszyński@pragmatists.pl start 1 2 SPRINT 3 4 5 max. od 1 do 2 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. koniec
Retrospekcja 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. Retrospekcja sprintu odbywa się po zakończeniu przeglądu i wstęp na nią ma jedynie zespół scrumowy. Retrospekcję moderuje Scrum Master 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
Praktyki techniczne 4
Sam Scrum nie wystarczy Scrum jest dobry dla ludzi, ale nie definiuje, jak kodować. Do tego potrzebujesz praktyk technicznych. 1 Test-Driven Development Obniżenie odsetka błędów. Kod tańszy w utrzymaniu. Stabilny rozwój produktu. 2 Pair Programming Jeszcze niższy odsetek błędów. Prostota rozwiązań. Większa produktywność. 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. 3 Domain-Driven Design Trwałe podstawy pracy. Jednolite rozumienie domeny. Lepsze rozumienie wymagań biznesowych.
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 +1 Udana refaktoryzacja 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. +1 Implementacja spełniająca test
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!
Domain-Driven Design Zespół modeluje rozwiązanie z udziałem ekspertów domenowych. Następnie za pomocą sprawdzonych wzorców DDD wyraża je w kodzie. Kod odzwierciedla ekspercką wiedzę z dziedziny Wszyscy używają jednolitego języka 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. Dobrze podzielony projekt łatwo testować i rozwijać
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, jak rozwijają oprogramowanie najlepsi programiści. Wzmocnisz to, co służy częstemu dostarczaniu wartości klientom. Zobaczysz efektywny transfer wiedzy, dzięki pracy 1 na 1. Dowiesz się, co jest potrzebne, żeby szybko dostarczać działające funkcjonalności. Zbudujesz z nami nawyk ciągłego doskonalenia umiejętności. Wyposażysz zespół w nowe umiejętności do zastosowania natychmiast w praktyce. Zapłacisz za samą esencję wiedzy. www.szkolenia.pragmatists.pl Zadbasz o długofalowe efekty.
Potrzebujesz dalszych wskazówek? Skontaktuj się z nami: +48 668 189 795 szymon.pruszyński@pragmatists.pl www.szkolenia.pragmatists.pl