Praca ze Scrumem

Historia użytkownika

Historie użytkowników są skutecznym sposobem określania wymagań dla oprogramowania w fazie rozwoju. Takie historie zawierają krótkie porady w imieniu użytkownika oprogramowania.

Ponieważ w metodologii Scrum wyznaczanie celów jest zwykle prerogatywą klienta lub właściciela oprogramowania, są one uważane za główny sposób wpływania na proces wytwarzania. Każda User Story ma ograniczenia w ilości tekstu i złożoności prezentacji. Historię najczęściej zapisuje się na małej kartce, co samo w sobie ogranicza objętość.

Dzięki historiom użytkowników możesz dokumentować życzenia klienta i szybko reagować na potrzeby rynku.

Historyjkę użytkownika należy traktować jako uproszczoną miarę wymagań, ponieważ nie obejmuje ona procedury testów akceptacyjnych. Kompilacja historii użytkownika musi być zgodna z procedurą dopuszczającą. Dzięki temu User Story osiągnie swój cel.

Struktura opowieści wygląda następująco: „Jako użytkownik <typ użytkownika> chcę wykonać <akcję>, aby uzyskać <wynik>” (Jako właściciel produktu chcę…). Taka struktura jest nie tylko prosta, ale także zrozumiała dla każdego.

Korzyści z używania User Stories:

• Historie są małe i łatwe do tworzenia.
• Pomóż wszystkim interesariuszom omówić prace nad projektem i jego wsparcie.
• Nie wymagają stałej konserwacji.
• Istotne tylko wtedy, gdy jest używane.
• Popraw interakcję z klientem.
• Dzięki nim możesz podzielić projekt na małe etapy.
• Ułatwienie pracy nad projektami o słabo poznanych wymaganiach.
• Uprość ocenę zadań.

Wady historii użytkowników:

• Bez uprzedniej zgody procedury mogą utrudniać wykorzystanie ich jako podstawy do zawarcia umowy.
• Ich użycie wymaga bliskiego kontaktu z klientem przez cały czas trwania projektu, co czasem utrudnia pracę.
• Mają wady przy skalowaniu w dużych projektach.
• Bezpośrednio związany z poziomem zawodowym programistów.
• Używane do rozpoczynania dyskusji, ale nie mogą jej kończyć i nie są używane do dokumentacji systemu.

Zaległości

Backlog produktu to bieżące zadania w formie listy, zestawione w kolejności priorytetów. Lista jest tworzona na podstawie mapy drogowej (mapy drogowej) projektu i określonych w niej punktów. Najważniejsze zadania są zwykle na górze listy. Jest to konieczne, aby zrozumieć, którą pracę należy wykonać jako pierwszą.

Zespół programistów dobiera szybkość realizacji zadań backlogowych niezależnie od życzeń klienta, ale w oparciu o jego kwalifikacje i doświadczenie z poprzednich sprintów. Niezwykle niepożądane jest „dopasowywanie” programistów. Zespół sam wybiera zadania z backlogu według własnych uwarunkowań i możliwości. Wykonanie odbywa się bez przerwy (Kanban) lub kilku iteracji (Scrum).

Dwa ważne warunki zaległości

Rdzeń rejestru produktu składa się z planu działania, propozycji i warunków wykonania. Epiki zawierają warunki i Historię użytkownika. Przyjrzyjmy się bliżej typowemu przykładowi mapy drogowej.

Stworzenie serwisu „Teams in Space” to pierwsza propozycja z mapy drogowej. Należy go podzielić na epopeje (na rysunku są one pokazane w kolorach zielonym, niebieskim i turkusowym) oraz Historię użytkownika dla każdej epopei.

Klient oprogramowania tworzy jedną listę z kilku Historii Użytkownika. W razie potrzeby może zmienić kolejność rozgrywania się historii, tak aby deweloperzy najpierw zajęli się jedną z najważniejszych eposów (po lewej) lub sprawdzili, jak działa rezerwacja biletów ze zniżką. Aby to zrobić, musisz zaimplementować historie z eposów (po prawej). Obie opcje można zobaczyć poniżej.

W oparciu o jakie czynniki klient powinien nadać priorytet?

• Znaczenie dla użytkowników.
• Obecność informacji zwrotnej.
• Złożoność rozwoju.
• Relacja między zadaniami (aby wykonać „B”, musisz najpierw wykonać „A”).

Priorytety w pracy są ustalane przez klienta, ale inne strony mogą wyrazić swoją opinię na ten temat. Sukces backlogu zależy między innymi od opinii klientów i programistów. Razem mogą osiągnąć lepsze wyniki i zapewnić terminową dostawę gotowego produktu.

Jak zachować zaległości

Jeśli backlog został już utworzony, to potem musisz go okresowo zmieniać w trakcie dalszej pracy. Klient oprogramowania powinien upewnić się, że backlog jest poprawnie skompilowany przed planowaniem każdej nowej iteracji. Pomoże to doprecyzować priorytety lub coś zmienić po analizie ostatniej iteracji. Korekta zaległości w Agile jest czasami nazywana „uwodzeniem”, „udoskonalaniem” lub „utrzymaniem zaległości”.

Jeśli backlog jest już stosunkowo duży, klient musi pogrupować zadania według realizacji krótko- i długoterminowej. Zlecenia krótkoterminowe należy dokładnie przeanalizować, zanim otrzymają ten status. Będziesz musiał skomponować User Story, poznać wszystkie niuanse w zespole.

Jeśli chodzi o zadania długoterminowe, wysoce pożądane jest, aby programiści wystawili im swoją ocenę. Ułatwi to ustalanie priorytetów. Być może coś się zmieni, ale zespół lepiej zrozumie zadania i szybciej wykona zadanie.

Backlog jest ważnym elementem między klientem a zespołem programistycznym. Klient zawsze może zmienić priorytety w oparciu o opinie klientów, prognozy lub nowe wymagania.

Zaleca się unikanie dokonywania zmian bezpośrednio podczas eksploatacji. Ma to zły wpływ na przebieg pracy i stan emocjonalny programistów.

Sprint

Sprint to krótki okres, w którym musi zostać wykonana wcześniej ustalona ilość pracy. Sprinty oparte są na metodykach Scrum i Agile. Wybór odpowiednich sprintów pomaga zwinnemu zespołowi opracować wysokiej jakości oprogramowanie.

„Korzystając ze Scruma, możesz rozwijać produkt w kilku iteracjach o jasno określonym czasie trwania – sprintach. Pomaga podzielić duże projekty na mniejsze zadania” — mówi Megan Cook, Jira Lead w firmie Atlassian.

Jak Scrum planuje i realizuje sprinty?

Według autorów metodyki Scrum, aby zaplanować przyszły sprint, każdy musi spotkać się na osobnym spotkaniu. Podczas tego wydarzenia członkowie zespołu muszą znaleźć odpowiedzi na dwa główne pytania: co należy zrobić w tym sprincie i jak najlepiej to zrobić?

Klient oprogramowania, Scrum master i programiści są zaangażowani w ustalanie listy zadań roboczych. Klient wyjaśnia cel sprintu i zadania z backlogu.

Następnie zespół opracowuje plan, według którego zadania w sprincie zostaną zrealizowane. Ten plan, wraz z wybranymi elementami pracy, jest nazywany rejestrem sprintu. Po spotkaniu planistycznym zespół zabiera się do pracy. Deweloperzy wybierają zadania z backlogu, gdy praca jest zakończona, status każdego zadania zmienia się z „W toku” na „Gotowe”.

Podczas sprintu zespół odbywa codzienne spotkania Scrumowe (stand-upy) w celu omówienia bieżących problemów i postępów. Takie spotkania są potrzebne do zidentyfikowania trudności, które mogą wpłynąć na zakończenie sprintu.

Jeżeli sprint zostanie zakończony, wówczas zespół prezentuje wyniki swojej pracy na przeglądzie wyników (demo). Każdy uczestnik projektu może zapoznać się z wynikami. Zapoznanie należy przeprowadzić przed włączeniem gotowego kodu do środowiska produkcyjnego.

Retrospektywa zamyka cykl sprintów. Na nim zespół identyfikuje obszary, które należy poprawić w przyszłym sprincie.

Na co zwrócić uwagę, a czego nie robić

Większość młodych zespołów ma trudności z wprowadzeniem sprintów do swojego przepływu pracy po raz pierwszy. Aby uniknąć problemów, zalecamy przejrzenie listy działań, które wymagają priorytetowego działania.

Co mamy robić:

• Sprawdź, czy zespół rozumie cel sprintu i sposób, w jaki zakończy się sukcesem. Jest to konieczne, aby wszyscy razem dążyli do pomyślnego wyniku.
• Powinieneś mieć jasne i zrozumiałe zaległości. Jeśli zaległości nie były utrzymywane prawidłowo, może to stać się problemem, który może uszkodzić przepływ pracy.
• Upewnij się, że Twoje oszacowanie tempa pracy jest prawidłowe, biorąc pod uwagę wakacje i inne czynniki.
• Aktywny udział w planowaniu sprintu. Zachęć członków zespołu do rozszerzenia planu o historie, błędy i zadania.
• Odrzuć zadania, podczas których programiści nie będą w stanie rozwiązać problemów z zależnościami.
• Po zatwierdzeniu planu wyznacz pracownika, który będzie odpowiedzialny za wprowadzanie danych do programu do zarządzania projektami (karty Jira itp.).

Czego unikać:

• Nie nadużywaj dużej ilości historii, trzeźwo oceniaj tempo pracy i nie wyznaczaj zadań, które będą trudne do wykonania w sprincie.
• Pamiętaj o jakości swojej pracy. Sprawdź, czy masz wystarczająco dużo czasu na kontrolę jakości i poprawianie błędów w kodzie.
• Upewnij się, że wszyscy członkowie zespołu jasno rozumieją treść sprintu. Nie goń za prędkością. Cały zespół musi poruszać się razem.
• Nie obciążaj programistów dodatkową pracą. Wkrótce kolejny sprint.
• Jeśli zespół wyraża zaniepokojenie obciążeniem pracą lub terminem, należy wziąć pod uwagę jego opinię. Rozwiązuj problemy i popraw je, jeśli to konieczne.

tablica scrumowa

Tablica Scrumowa to narzędzie, które pokazuje, jak przebiega praca Zespołu Scrumowego. Możesz wyświetlać informacje na takiej tablicy na papierze, na ścianie lub w formie elektronicznej (JIRA, Trello).

Tablica Scruma ma co najmniej trzy kolumny: Do zrobienia, W toku i Gotowe. Oto przykładowa tablica:

Tablica Scrum zawiera wszystkie informacje z backlogu, które zostały wcześniej zatwierdzone do planowania. Z reguły karty zadań biznesowych są przypinane do tablicy według priorytetu od góry do dołu. Można je podzielić na konkretne rodzaje prac (praca nad kodem, projektowaniem i inne).

Po zakończeniu części pracy karta jest przesuwana po planszy do następnej kolumny. Aby pokazać widoczność postępu prac zespołu, pomaga „pozostała praca” w ciągu dnia na wykresie wypalania.

Możesz również skorzystać z tablicy typu flipchart. Na nim nazwy prac są zapisane na papierowych naklejkach i przymocowane do planszy. Po zakończeniu pracy naklejki są przenoszone do innej kolumny.

wykres spalania

Wykres wypalania pokazuje ilość wykonanej pracy i ilość pozostałej pracy. Jest aktualizowana codziennie i dostępna dla wszystkich zainteresowanych. Wykres jest potrzebny do pokazania postępu prac nad sprintem.

Istnieją dwa rodzaje wykresów:

• Wykres wypalania obrazujący postęp prac w sprincie.
• Wykres wypalania pokazujący postęp prac do momentu wydania produktu (dane są podsumowane z kilku sprintów).

Przykład wykresu:

Ten przykład wykorzystuje psychologię: wykres nie pokazuje liczby ukończonych zadań, ale liczbę pozostałych (niewykonanych).

Oznacza to, że jeśli zespół wykonał 90 zadań na 100, może pojawić się fałszywe wrażenie, że wszystko jest gotowe. W końcu postęp od 90 do 100 zadań tak naprawdę niczego nie zmienia.

Jeśli wyświetlisz liczbę pozostałych zadań, nie możesz nie zauważyć, jak za każdym razem stają się one coraz mniejsze. To podświadomie skłania uczestników projektu do szybszego osiągnięcia celu – na tablicy nie powinno być żadnych niedokończonych zadań.