|
Metodologia projektowa SCRUM
SCRUM to metoda zarządzania projektami IT zgodnie z regułami agile software development. Jej strukturę, framework wyznacza zestaw zasad oraz praktyk wywodzących się z Lean Thinking. W zamyśle jest to prosta struktura rozwiązywania złożonych problemów przy tworzeniu oprogramowania związanych z terminowością oraz wymaganiami klienta, jednak proces jej wdrażania jest trudny i pracochłonny ponieważ wymaga zmiany sposobu myślenia. SCRUM zaliczany jest do empirycznych metodyk zarządzania projektami. Jest to zbiór praktyk oraz sugestii zebrany i spisanych po raz pierwszy w roku 1993 przez Kena Schwabera, Jeffa Sutherlanda oraz Mika Belldlema. Jest często stosowany razem z eXtreme programming.
Struktura SCRUM składa się z:
Praca podzielona jest na sprinty. Sprint to stały okres czasu, w którym tworzone jest oprogramowanie. Na koniec każdego sprintu klient dostaje funkcjonującą część produktu. Dzięki temu może on śledzić postęp i kierunek tworzenia produktu. Przy podejściu typu wizja-eksploracja minimalizowany jest czas, w którym tworzony jest produkt niezgodny z wizją klienta. Możliwość śledzenia postępu prac zespołu daje możliwość na szybkie wprowadzanie korekt do planu projektu (porównując ten czas z tradycyjnymi sposobami zarządzania). Trzy podstawowe role w SCRUM Jak wcześniej zostało wspomniane, SCRUM składa się z 3 podstawowych ról:
Każda z tych ról ma ściśle określone zadania. Wzajemne relacje tych ról można porównać do stada owiec (team), który jest pilnowany przez owczarka (Scrum mastera) przed niebezpieczeństwem – wilkiem (product ownerem) podczas wypasu (Sprintu). Product Owner Jest to właściciel projektu, który odpowiada za budżet projektu. Może być to osoba delegowana przez sponsora projektu. Określa ona wizje i cel projektu, a następnie przedstawia je zespołowi. Właściciel projektu uzupełnia Product Backlog oraz określa kolejność wdrażanych funkcjonalności. Przygotowuje ona wymagania (nie specyfikacje), określa kryteria akceptacji oraz definiuje wartość produktu. Osoba ta odpowiedzialna jest za zyskowność przedsięwzięcia. Product owner akceptuje lub odrzuca rezultaty pracy zespołu. Scrum Master Jest to osoba, która pomaga zespołowi w pokonywaniu przeszkód zapewniając jednocześnie maksymalną produktywność teamu. Pomimo, że Scrum master jest częścią zespołu, nie ma on żadnych praw, jest on osobą, która prowokuje dyskusje i pomaga szukać najlepszych rozwiązań. Nie podejmuje on jednak decyzji - ani biznesowych ani technicznych. Jak wcześniej zostało wspomniane, ochrania on zespół od negatywnych czynników zewnętrznych np. zmieniającymi się w czasie sprintu wymaganiami, dodatkowymi zadaniami czy problemami. Scrum Master odpowiada za postępowanie zgodne z założeniami SCRUM, jest on mistrzem ceremonii. Pełni funkcje mentora, gospodarza. Team Team to interdyscyplinarny, samoorganizujący się, samouczący i samowystarczalny zespół projektowy, który sam sobą zarządza – podejmuje decyzje, które prowadzą do osiągnięcia celu w czasie sprintu. Według przyjętych zasad Team powinien zawierać 5-7 osób. Członkowie zespołu powinni być w stanie zrobić projekt. W czasie projektu skład teamu nie może się zmienić. Trzy podstawowe ceremonie SCRUM Planning - Planownanie Ceremonia ta rozpoczyna Sprint. Podczas jej trwania określony jest cel, do którego zespół będzie dążył. Spotkanie to powinno trwać nie dłużej niż 4 godziny. W jego czasie Team szacuje wielkość zadań z back logu oraz zobowiązuję się do wykonania części z nich. Zadania szacowne są kolejno według ranków – ich kolejności, które stają się częścią sprint backlogu. Zespół szacuje zadania porównuje ich wielkość, złożoność oraz ryzyko do siebie. Takie podejście pozwala po pewnym czasie określić velocity- szybkość tworzenia funkcjonalności wyrażona abstrakcyjną liczbą. Daily Scrum Jest to codzienne spotkanie zespołu, trwające ok. 15 minut i obowiązkowe, podczas którego jego członkowie odpowiadają sobie nawzajem na 3 podstawowe pytania:
Dzięki tym spotkaniom zespół wraz z Scrum masterem mogą śledzić postęp prac oraz szybko reagować na powstające problemy. Sprint review - Przegląd sprintu Sprint review to spotkanie kończące sprint. Podzielone jest ono na dwie części. Pierwsza z nich to User Demo. Zespół prezentuje przed product ownerem oraz innymi osobami zainteresowanymi funkcjonalności, które wykonał podczas sprintu. Na podstawie tej prezentacji product owner wypowiada się, czy funkcjonalność spełnia kryteria akceptacji, które zostały określone przez klienta przed rozpoczęciem pracy nad nim. Druga z nich to retrospektywa. Jej podstawowym celem jest nauka. Team wraz z SCRUM Master analizuje przebieg Sprintu i określa rzeczy, które powinny być poprawione. Wspólnie określone są małe kroki, które zostają wdrożone w kolejnym sprincie celem polepszenia pracy. Trzy podstawowe artefakty SCRUM Product Backlog - Rejestr produktowy Jest to podstawowa lista projektu, która należy do product ownera. Jest to zestaw funkcjonalności do wdrożenia przez Team. Każdy członek zespołu może wpisać zadania/pomysły do rejestru, jednak tylko product owner może zdecydować o ich kolejności wykonania.Zadania spisane w back logu można podzielić na dwie kategorie:
Zadania te poukładane są w backlogu przez product ownera według wartości biznesowej od najbardziej porządanej, do najmniej. Sprint Backlog - Rejestr zadaniowy Po każdym planningu powstaje sprint backlog zespołu. Jest to zestaw zadań, do którego zespół się sam zadeklarował. W czasie trwania sprintu Team na codziennych spotkaniach śledzi postęp prac. W chwili, gdy widoczne są niebezpieczeństwa nie zakończenia wszystkich zadań, ilość nowych funkcjonalność zostaje pomniejszona za porozumieniem z product ownerem, lub sprint jest zakańczany w trybie awaryjnym. Burndown Chart - Wykres spalania Wykres ten powstaje w czasie trwania sprintu i określa postęp prac. Jeżeli jest dobrze prowadzony, może szybko sygnalizować pojawiające się problemy podczas sprintu. Manifest agile Scrum to metodologia, która spełnia system norm i wartości ustanowionych przez Agile Manifesto. Jest to deklaracja zasad wspólnych dla lekkich sposobów zarządzania. Treść manifestu została opracowana w lutym 2001 roku przez przedstawicieli różnych metod lekkiego zarządzania. Treść manifestu brzmi: Ludzie i interakcje ponad procesy i narzędzia Działające oprogramowanie ponad kompleksową dokumentację Współpraca z klientem ponad negocjacje kontraktu Reagowanie na zmiany ponad wypełnienie planu Manifest agile to zebranie podstawowych zasad współpracy w zespole oraz wyznacza sposób współpracy z klientem. Według zasad manifesto najwyższy priorytet to zadowolenie klienta poprzez ciągłe dostarczanie produktu o wysokiej wartości biznesowej. Manifest nie neguje narzędzi, procesów, kompleksowej dokumentacji, negocjacji kontraktu czy wypełnianiu planu. Są to rzeczy ważne, jednak ważniejszym są ludzie i interakcje między nimi, działające oprogramowanie itd. Bardzo często najprostsze sposoby komunikacji są najlepsze. Nie chodzi o to, żeby zrezygnować z komunikacji pisemnej, ale bardzo często wystarczy 10 minut rozmowy zamiast 20 maili. Pomimo, że jest to łatwe, bardzo często biurokracja jest potężniejsza. Dokumentacja, która tworzona jest podczas powstawania projektu, powinna odnosić się do działającego produktu, powinna być instrukcją obsługi, która jest na tyle przygotowana, by klient mógł ją zrozumieć i zastosować. Często projekty kończone są z 1000 stron dokumentacji, której nikt nigdy nie przeczyta. Czas poświęcony na jej pisanie, mógł być spożytkowany na tworzenie programu. Plan, który zakładany jest przed rozpoczęciem projektu rzadko jest na tyle dokładny i zawierający wszystkie szczegóły, by nie był zmieniany, dlatego elastyczność, którą daje SCRUM daje możliwość zespołowi na przystosowanie do zmieniających się wymagań. Przebieg Sprintu Sprint jest to pewien okres czasu, w trakcie którego trwa programowanie nowych funkcjonalności. Długość trwania sprintu określa zespół. Rekomendowany czas to między 14 dni a 30 dni. Okres ten daje z jednej strony możliwość wyprodukowania działającej części systemu, z drugiej strony pozwala na szybką informację od klienta, czy tworzone funkcjonalności spełniają jego oczekiwania. Poniższy rysunek przedstawia przebieg jednego sprintu.
Najważniejszą cechą SCRUM jest to, że po każdym sprincie Team dostarcza gotową, działającą część aplikacji, którą potencjalnie można wdrożyć. W czasie sprintu zespół musi koncentrować się na zadeklarowanych podczas planningu user stories. Codzienne spotkania oraz prowadzony wykres spalania pozwala na śledzenie postępu prac w czasie sprintu. Gdy tylko pojawiają się jakieś niepokojące oznaki, jest to komunikowane product ownerowi. Jeżeli ilość problemów w czasie sprintu może przyczynić się do nie wykonania wszystkich zaplanowanych zadań, klient musi o tym wcześniej wiedzieć. Zespół, za porozumieniem z product ownerem, usuwa z listy zadań user stories, które są najniżej w priorytetach, aby zakończyć sprint sukcesem. Zakończenie sprintu kończy się sukcesem, gdy zadania zadeklarowane przez zespół są nie tylko zakończone, ale przeszły również pozytywnie testy oraz istnieje do nich chociaż szczątkowa dokumentacja umożliwiająca klientowi sprawdzenie wykonanej pracy. Każdy sprint musi się kończyć dostarczeniem klientowi gotowej części rozwiązania, która bez pomocy programistycznej może zostać wdrożona na środowisko produkcyjne. W czasie trwania sprintu wszystkie fazy rozpoczynają się prawie jednocześnie. Pierwsza z nich to faza planowania zadań. Prawie jednocześnie wraz z planowaniem rozpoczynana jest analiza oraz projektowanie. Ważną rzeczą jest to, że nie muszą być zakończone te fazy, aby rozpocząć kodowanie. Dzięki takiemu podejściu bardzo szybko można zobaczyć i przetestować pierwsze nowe funkcjonalności. W każdym zespole powinien znajdować się tester, który na bieżąco weryfikuje poprawność oddawanych zadań. Testy akceptacyjne prowadzone są po zakończeniu całych user stories. Są one wykonywane przez klienta Zastosowanie SCRUM SCRUM jest dobrym sposobem na zarządzanie projektem, gdy klient ma zarys projektu, ale nie jest w stanie od razu zdefiniować dokładnych wymagań. Najlepiej obrazuje to rysunek nr 2. Chaos najlepiej obrazuje początkowe stadium projektu. Zarówno klient jak i zespół pogrążeni są w niepewności działań. Dlatego w początkowej fazie projektu rekomendowane są krótkie okresu sprintu, aby produck owner szybko dostawał działające części. Często na ich podstawie podejmowane są kolejne kroki.
SCRUM działa jak pętla, która po każdym wykonaniu daje klientowi możliwość sprawdzenia postępów. Na podstawie dostarczonej części programu product owner na bieżąco może modyfikować obrany cel. Taka informacja po każdej iteracji pozwala na zachowanie odpowiedniego kierunku rozwijanych funkcjonalności. Zespół jest pewien swojego działania, co z kolei sprzyja dalszej pracy. Product owner wraz z rozwijanym projektem coraz szczegółowiej potrafi określać swoje wymagania i oczekiwania. Elastyczność, jaką daje SCRUM pozwala na szybkie dostosowanie się zespołu do zmieniających się wymagań. Jak już zostało wspomniane, taka informacja zwrotna bardzo ważna jest szczególnie na początku nowego projektu gdzie zarówno klient jak i team pogrążeni są w chaosie. Zmiany to naturalny czynnik tworzenia projektów informatycznych. Ważne jest jednak, by nie były one fundamentalne. Klient w czasie tworzenia projektu może powiedzieć, że chce sortowanie takie, wyświetlanie inne . Może zmienić zakres tworzonego produktu, ale nie może zmienić fundamentu, który został stworzony na początku. Jeżeli będzie nalegał na to, wszystkie funkcjonalności dostarczone we wcześniejszych sprintach mogą wymagać przeróbek, a co za tym idzie, projekt rozpoczyna się od początku – zanim jeszcze został zakończony. Z jednej strony powyższe stwierdzenie jest niepokojące i na pewno może spotkać się z krytyką i pytaniem, czy w takim razie SCRUM to dobre rozwiązanie. Odpowiedź jest prosta – tak, to wciąż oszczędność czasu i pieniędzy. |
|
|
studium przypadku |
|
