W obecnie funkcjonującym świecie IT, wymagane jest coraz częściej zwinne podejście w procesie wytwarzania oprogramowania. Oznacza to, że projekty, w których z góry zakładaliśmy budżet, harmonogram, czy zasoby na realizację produktu stają się coraz mniej aktualne, a od firm technologicznych wymaga się coraz częściej podejścia zwinnego (agile). Dlatego koniecznością w wytwarzaniu produktów w branży IT stało się podejście, które zakłada zmiany w trakcie developmentu. Zmiany te dotyczą najczęściej zakresu wdrożenia, harmonogramu czy rotacji w zespole scrumowym. Scrum wprowadzenie to pierwszy z cyklu artykułów o zwinnej metodyce wytwarzania oprogramowania w IT.
Scrum w projektach IT wprowadzenie
Scrum jest to metodyka zarządzania o charakterze iteracyjnym oraz przyrostowym. Iteracjami są poszczególne sprinty trwające w zależności od projektu od 2 do 6 tygodni. (Dla małych i średnich projektów są to najczęściej 2 tygodnie). Natomiast poszczególnymi przyrostami definiujemy release, czyli wydania pewnych elementów w projekcie. Na wydanie składa się część projektu. Np. strona główna, czy nagłówek serwisu internetowego.
Scrum opiera się silnie na samoistnie tworzących się relacjach zespołu i zakłada, że zespół będzie dokonywał samoorganizacji w celu skuteczniejszej realizacji projektu.
Role członków zespołów scrumowych:
Scrum master — osoba dbająca o realizację scruma jako procesu. Dbająca o punktualność poszczególnych części (planning, stand-upy, retrospektywa).
Product Owner— osoba decydująca o tym, co ma być zrobione przez zespół w danym sprincie. Na początku sprintu przekazująca informacje produktowe na końcu sprintu odbierająca wykonaną pracę.
The team — członkowie zespołu, deweloperzy, devopsi, testerzy. Członkowie zespołu decydują, ile są w stanie zrealizować w danym sprincie oraz jaką metodyką. Product Owner, Scrum Master, czy pozostałe osoby niezaangażowane bezpośrednio w wytwarzanie produktu nie decydują o wyborze metodyk, czy wykonywanych części. O tym decyduje zawsze zespół scrumowy.
User Story
Przed rozpoczęciem realizacji projektu tworzy się User Story. Jest to zbiór wszystkich funkcjonalności produktu. Do user story zalicza się np. opisanie działania feature’a, wdrożenie w pełni funkcjonalnej strony itp..
User story tworzone jest najczęściej przez product ownera oraz definiowane, aż do momentu, w którym zespół uzna, że mają pełny obraz zadania, który jest spójny. Na końcu user story estymowane jest przez zespół.
Ważnym krokiem jest dokonanie estymacji całego User Story przez zespół. Estymacja nie musi być precyzyjna, natomiast kluczem jest, aby dokonał ją zespół, a nie zlecający czy właściciel produktu. Pozwala to wstępnie zaplanować zasoby oraz podzielić odpowiedzialność za estymację na cały zespół. Natomiast bardziej dokładną estymację dokonuje się zawsze na początku sprintu.
Story Point
Jednostką miary trudności zadania jest story point. Jest to abstrakcyjna jednostka, która nie definiuje ilości godzin na wykonanie zadania, a bardziej stopień trudności / złożoności, jaki należy włożyć, aby zrealizować zadanie.
Wartości story pointów to najczęściej ciąg Fibonacciego:
0, 1, 2, 3, 5, 8, 13, 21, 34…
Epic
Epic jest zbiorem User Story, które łączy się do jednej, wspólnej funkcjonalności. Oznacza to, że wiele User Stories składa się na jeden byt o nazwie Epic. Inaczej mówiąc Epic to duży zbiór pracy, które można podzielić na kilka mniejszych zadań zwanych Stories.
Epic w Metodyce Scrum można zdefiniować jako dużą część pracy, mającą jeden wspólny cel. Może to być funkcja, żądanie klienta lub wymagania biznesowe. Mówi zwięźle o ostatecznym wyniku potrzeb użytkowników. Na jego podstawie łatwiej jest planować strategię długofalową, czyli release. Epic nie powinien zawierać wszystkich szczegółów, nad którymi zespół musi pracować, te szczegóły są zdefiniowane w historyjkach użytkowników (User Stories). Epic zazwyczaj wymaga więcej niż jednego sprintu i może się składać nawet z kilkunastu historyjek użytkowników (User Stories).
Podstawową jednostką pracy zdefiniowaną w Scrumie jest historyjka użytkownika (user story). Jednak bardzo często ta sama historyjka użytkownika (user story) rozszerza się tak bardzo, że nie mieści się ani w ciągu tygodnia, ani w czasie sprintu. W takim wypadku taką historyjkę użytkownika (user story) warto uznać za Epica i zacząć ją dzielić na mniejsze historyjki użytkowników (user stories). W ten sposób zespoły Agile uzyskują mniejsze, ale konkretne wyniki w pojedynczym sprincie.
Product backlog i release
Backlog produktu – pojęcie związane z metodą scrum. Jest to spriorytetyzowana lista wszystkich zadań, jakie powinny być wykonane, aby otrzymać produkt. W dosłownym tłumaczeniu jest to rejestr produkt. Rejestr ten rozpoczyna cały cykl scrum. Jest to jedyne źródło wymagań dla wszelkich zmian, które należy wprowadzić do produktu. Stanowi podstawę wymagań klienta wobec ostatecznego kształtu oczekiwanego produktu.
Główną osobą odpowiedzialną za backlog produktu jest Product owner. Zakres ten obejmuje zawartość backlogu, jego dostępność oraz zamawianie. Składa się on przede wszystkim z funkcji, wymagań, proponowanych ulepszeń, które należy wprowadzić w przyszłych wydaniach produktu. Oprócz tego backlog zawiera tak zwane atrybuty opisu, porządku, szacunku i wartości. Elementy backlogu często zawierają opisy testów, które potwierdzają jego kompletność po wykonaniu zadania. Backlog produktu przybiera coraz większe rozmiary, kiedy produkt jest używany i zaczyna nabierać wartości, a użytkownicy produktu dostarczają informacji zwrotnej.
Release — wydanie produktu lub jego elementów, które zostały zaplanowane w danym sprincie.
Backlog — miejsce, w którym zbierane są wszystkie zadania przed rozpoczęciem sprintu. Na planningu zespół scrumowy wybiera zadania z backlogu i dokonuje estymacji.
Podsumowanie
W powyższym wpisie omówiliśmy nazewnictwo kluczowych elementów scruma. W kolejnym artykule skupimy się na przebiegu sprintu oraz użyciu wprowadzonej nomenklatury do zarządzania projektami. Więcej o Scrumie dowiesz się na stronie Wikipedii oraz dostawcy oprogramowania do zarządzania projektami Atlassian.
Zobacz inne artykuły w kategorii: Project Management