AGILE SOFTWARE HOUSE SCRUM PRAKTYCZNIE SCRUM BOOK

Transkrypt

1 AGILE SOFTWARE HOUSE SCRUM PRAKTYCZNIE SCRUM BOOK

2 10 LAT DOŚWIADCZENIA W SCRUMIE 40 OSÓB W ZESPOLE 100 WDROŻONYCH PROJEKTÓW 6 TECHNOLOGII OPEN SOURCE MACOPEDIA.COM

3 BUSINESS VALUE PRODUCT OWNER PROXY PRODUCT OWNER BUSINESS VALUE DEPLOY NEW VERSION THINK ABOUT NEXT VALUES? SPRINT DEMO STAKEHOLDERS BACKLOG WORKSHOPS USER STORIES SPRINT RETROSPECTIVE KNOWLEDGE TRANSFER SCRUM MASTER DAILY MEETING & GROOMING SPRINT TEAM SPRINT PLANNING * SCRUM TEORETYCZNIE PRAKTYCZNIE

4 BUSINESS VALUE BUSSINESS VALUE Potrzeba biznesowa, przynosząca wartość dla klienta. MVP Minimalny zakres produktu, który przynosi klientowi zysk lub ma wartość biznesową. Jego określenie i jak najszybsze dostarczenie jest kluczowe (daje przewagę konkurencyjną klientowi). PRODUCT OWNER Właściciel biznesowy projektu, po stronie klienta. Podejmuje decyzje, co ma być zrobione oraz zapewnia dostęp do kluczowych osób i informacji. Ma bezpośredni kontakt z całym zespołem projektowym Macopedii. PROXY PRODUCT OWNER Odpowiednik Project Managera. Ma za zadanie wspierać Product Ownera, dla którego proces scrumowy albo technologia mogą być nowe. W Macopedii jest też odpowiedzialny za rozliczenia finansowe. STAKEHOLDERS Sponsorzy projektu, zarząd firmy oraz menedżerowie poszczególnych działów, na co dzień reprezentowani przez Product Ownera. Zapewniają wiedzę ekspercką lub/i budżet dla projektu. SCRUM MASTER Osoba, która dba o cały proces, pomaga przy rozwiązywaniu problemów oraz wspiera zespół. Często też pełni rolę Proxy Product Ownera.

5 ZESPÓŁ SCRUMOWY W zależności od potrzeb, mogą być w nim różne osoby. W Macopedii są to zazwyczaj: Scrum Master, ew. Proxy Product Owner, UX Designer, Frontend i Backend Developerzy. BACKLOG WORKSHOPS Warsztaty kreatywne Macopedii, przeprowadzane z zespołem klienta. Ich rezultatem jest backlog (lista user stories) oraz wstępne oszacowanie budżetu i harmonogramu projektu. BACKLOG Lista user stories, uporządkowana według priorytetu. Zadania na szczycie backlogu powinny być bardziej szczegółowe, natomiast dalsze mogą być bardziej ogólne. USER STORY Opis funkcjonalności tworzonej aplikacji, która z perspektywy klienta wnosi wartość biznesową, jest zrozumiała i spełnia zasadę INVEST. ZASADA INVEST Opowieści użytkownika muszą być: niezależne od siebie, negocjowalne (w sposobie rozwiązania), przynoszące mierzalną wartość dla klienta, możliwe do oszacowania i przetestowania oraz nieduże (ang. Independent, Negotiable, Valuable, Estimable, Small oraz Testable). SPRINT 2-tygodniowa iteracja (przyrost) w projekcie, nastawiona na dostarczenie kolejnej działającej wersji aplikacji. SPRINT PLANNING Spotkanie klienta z zespołem Macopedii, na którym ustalamy zakres kolejnego sprintu oraz priorytety.

6 SPRINT DEMO Spotkanie, na którym zespół Macopedii prezentuje rezultaty sprintu. SPRINT RETROSPECTIVE BURNDOWN CHART Wykres, pokazujący postęp prac w sprincie, sprawdzany podczas daily. KNOWLEDGE TRANSFER DEPLOYMENT Klient otrzymuje produkt, wraz z nowo dodanymi funkcjonalnościami. Stakeholders powinni w nim uczestniczyć. Warto wykonać po każdym sprincie - zespół zastanawia się, jakie zmiany usprawniające proces i współpracę wdrożyć w kolejnej iteracji. Regularny feedback oraz wymiana wiedzy znacząco zwiększają efektywność działań i wpływają na kolejne decyzje. Jest to możliwe, dzięki częstym interakcjom developerów Macopedii z zespołem klienta. Wdrożenie, które oznacza wydanie nowej wersji aplikacji, czyli wartości biznesowej dla klienta. DAILY Codzienne spotkanie zespołu Macopedii, podczas którego jest omawiany postęp prac. Programiści odpowiadają na 3 pytania: co robiłem wczoraj, jaki mam plan na dziś i jutro oraz czy jest jakiś problem do rozwiązania. Klient może uczestniczyć w daily. GROOMING / REFINEMENT Spotkanie z klientem, podczas którego poszczególne zadania z backlogu są omawiane, zgodnie z zasadą INVEST. Nadrzędnym celem groomingu jest odblokowywanie zadań.

7 MITY SCRUMA 1 2 W SCRUMIE NIE DA SIĘ ZAPLANOWAĆ BUDŻETU Backlog, stworzony na podstawie warsztatów z klientem, pozwala nam określić zarówno koszt projektu, jak i czas jego trwania. W trakcie wdrożenia, w czasie rzeczywistym kontrolujemy zarówno wykorzystanie budżetu, tempo dostarczania poszczególnych funkcjonalności, jak i przewidywany termin zakończenia projektu. W SCRUMIE NIE MA DEADLINE U PROJEKTU Termin ukończenia jest istotnym elementym każdego projektu. Z naszego doświadczenia wynika, że kluczowe jest ustalenie, które funkcjonalności stanowią wersję MVP projektu, a które są dodatkami. Obserwujemy, że dodatki to często aż 50% projektu! Określenie MVP pozwala skupić się przede wszystkim na rzeczach istotnych dla projektu, a mniej ważne zostawić na później. Takie podejście pozwala dostarczyć projekt w gwarantowanym czasie. Im szybciej projekt ujrzy światło dzienne, tym prędzej zacznie przynosić korzyści dla klienta. 3 SCRUM SPRAWDZA SIĘ TYLKO W IT Scrum stosowany jest najczęściej podczas tworzenia i rozwijania oprogramowania, jednak nie jest ograniczony tylko do tej dziedziny. Należy zastanowić się, co dla danego projektu jest ważne i czy w danej sytuacji sprawdzi się lepiej metoda przyrostowa czy kaskadowa. Coraz częściej, sprawdza się metoda przyrostowa ze względu na szybsze

8 reagowanie na zmiany. Są oczywiście wyjątki tzn. projekty, w których wdrażanie zmian jest bardzo drogie np. w budownictwie zburzenie całego piętra. 4 5 SCRUM TO DUŻO SPOTKAŃ, MAŁO PRACY Osoby mające pierwszy raz kontakt ze Scrumem, mogą mieć na początku takie poczucie. Liczne spotkania zapewniają transfer wiedzy, który pozwala nam dużo lepiej poznać i realizować potrzeby klienta. Czas poświęcony na spotkania, consulting i planowanie w Scrumie (około 10%) nie jest wcale większy niż w tradycyjnych waterfall owych projektach. W Scrumie czas ten jest bardziej rozłożony na poszczególne iteracje, dzięki czemu nie podejmujemy większości decyzji na samym starcie projektu, kiedy mamy najmniejszą wiedzę, a klientowi jest ciężko doprecyzować wszystkie wymagania, w jeszcze nieistniejącym produkcie. Dlatego zamiast analiz przedwdrożeniowych, preferujemy ustalanie szczegółów kolejnych iteracji na bieżąco. W SCRUMIE NIE MA DYSCYPLINY Dzięki temu, że projekty są prowadzone transparentnie, a wykonane zadania są prezentowane na regularnych spotkaniach, wszyscy czują odpowiedzialność za swoją pracę. Zainteresowani szybko uzyskują informacje o postępach w projekcie i mogą od razu reagować. Ich feedback jest bardzo ważny dla zespołu, ponieważ dzięki temu wiadomo, czy projekt idzie we właściwym kierunku. W Scrumie dyscyplina zespołu i jego samoorganizacja to proces naturalny, a nie wymuszony.

9 6 W SCRUMIE NIE TRZEBA PLANOWAĆ Planowanie pracy stanowi stały element każdej iteracji, bez względu na jej długość. Przed rozpoczęciem zadań, dokładnie omawiamy je z Product Ownerem, tak aby zespół wiedział, co jest celem Sprintu i jakie są oczekiwania klienta. To właśnie dzięki planowaniu pracy, jesteśmy w stanie określić termin realizacji projektu. 7 SCRUM ROZWIĄZUJE WSZYSTKIE PROBLEMY Scrum nie rozwiązuje problemów, ale szybciej je uwidacznia, przez co jesteśmy ich świadomi i możemy na nie reagować. Scrum nie jest gotowym rozwiązaniem, a zbiorem dobrych praktyk, które warto stosować, aby zminimalizować ryzyko niepowodzeń. Przykładowo przeprowadzanie wspólnie z klientem procesu retroperspektywy, pozwala zidentyfikować nieefektywne elementy projektu i znaleźć nowe rozwiązania. 8 W SCRUMIE NIE MA DOKUMENTACJI W tradycyjnym podejściu dokumentacja stanowi oddzielną fazę projektu, podczas gdy w Scrumie jest to naturalny proces, który dzieje się w tle. W Scrumie skupiamy się na opracowywaniu rozwiązań na wcześniejszym etapie procesu, ale to nie oznacza, że dokumenty w ogóle nie istnieją. Wspólnie podejmujemy decyzję o tym, co i jak dokumentujemy. Dzięki temu dokumentacja dostarcza taką wiedzę, która faktycznie jest potrzebna, bez przedrażania projektu.

10 DEFINE ANALIZA PRZED- WDROŻENIOWA NEGOTIATE NEGOCJACJE NASZ SCRUM VS WATERFALL BUILD WYTWARZANIE RELEASE ODBIÓR I WYDANIE 14 dni FEEDBACK PRODUKT KOŃCOWY 7 dni FEEDBACK PRODUKT czas BUILD [miesiące] KOŃCOWY NEGOTIATE DEFINE NEGOCJACJE BUDŻETU I ZAKRESU DEFINE WARSZTATY BACKLOGOWE RELEASE W SCRUMIE OSZCZĘDZASZ DWA I PÓŁ MIESIĄCA CZASU! ZAŁOŻENIE: * PRACOCHŁONNOŚĆ PROJEKTU - 3 MIESIĄCE ROBOCZE ZESPOŁU SPRINT SCRUM WATERFALL

11 SCRUM VS WATERFALL W metodyce Waterfall definiowanie zakresu zadań oraz negocjacje budżetu trwają bardzo długo. Dzieje się tak ze względu na konieczność uwzględniania wszystkich szczegółów projektu w całościowej specyfikacji tzw. analizie przedwdrożeniowej. Dodatkowo odbiór i wydanie następuje dopiero wtedy, gdy cały system jest gotowy (a nie częściowo po poszczególnych iteracjach). W efekcie mija dużo czasu zanim klient może zapoznać się z działającą wersją aplikacji i zgłosić potencjalne uwagi. Dlatego Scrum jest lepszym rozwiązaniem! ZALETY SCRUMA: SZYBKA I EFEKTYWNA ANALIZA BACKLOGU KRÓTSZY CZAS PROJEKTU NIŻSZE KOSZTY PIERWSZA DZIAŁAJĄCA WERSJA APLIKACJI JUŻ PO 2 TYGODNIACH TRANSFER WIEDZY MIĘDZY MACOPEDIĄ, A KLIENTEM BEZPOŚREDNI KONTAKT Z DEVELOPERAMI DUŻA TRANSPARENTNOŚĆ PROJEKTU MINIMUM FORMALNOŚCI

12 ul. Matejki 11A Poznań macopedia.com MADE IN POLAND SCRUM PRAKTYCZNIE SCRUM BOOK