Co to jest tablica zadań sprintu

---

Co to jest tablica zadań sprintu?

Sprint task box to czasowy przedział. Każdy sprint ma datę rozpoczęcia i zakończenia, w którym muszą zostać ukończone i potwierdzone wybrane historie użytkownika. Poniższy obraz pokazuje kluczowe elementy sprintu, które obejmują zestaw historii użytkownika, zaangażowanych członków zespołu Scrum, przydziału prac, czasu trwania i daty zakończenia (prawy górny róg).

Na początku sprintu właściciel produktu, interesariusze i zespół rozwojowy spotykają się, aby ustalić priorytety, a następnie wybrać historie użytkownika do ukończenia w ramach sprintu. Ponieważ różne strony mają różne preferencje, rozważania i obawy dotyczące projektu i harmonogramu projektu, celem spotkania jest umożliwienie uczestnikom słuchania i zrozumienia poglądów innych oraz wypracowanie zbioru historii użytkownika, który zostanie zaakceptowany przez wszystkie strony.

Czas trwania sprintu

Szybkie dostarczanie wysokiej jakości pracy to jedna z przyczyn, dla których zespoły programistyczne chcą stosować metodyki agilne w rozwoju oprogramowania. Dlatego mimo że nie ma jednej uniwersalnej odpowiedzi na pytanie o długość sprintu, powszechnie przyjmuje się, że powinna być jak najkrótsza. Ale jak krótka powinna być?

Choć długie trwanie sprintu nie jest preferowane, nieuzasadnionie krótki czas trwania sprintu może osłabić motywację zespołu do ukończenia istotnej pracy, a nawet prowadzić do niskiej jakości dostarczanych produktów.

Dlatego wybór długości sprintu jest wynikiem dyskusji całego zespołu – właściciela produktu, kierownika Scrum i członków zespołu, takich jak projektanci baz danych, programiści, projektanci UX, testerzy, analitycy itd. Ale na końcu ktoś musi podjąć decyzję. W tym momencie kierownik Scrum zazwyczaj jest tym, kto podaje odpowiedź.

Tradycyjnie sprint trwa od trzech tygodni do jednego miesiąca, ale obecnie coraz więcej zespołów osiąga sukces przy sprintsach trwających dwa tygodnie. W końcu nie ma jednej ustalonej długości sprintu. Dobry kierownik Scrum posiada umiejętności współpracy i prowadzenia, które pomagają w ustaleniu długości sprintu, aby zapewnić, że prace będą ukończone zgodnie z oczekiwaniami. Oto niektóre czynniki, które kierownik Scrum może wziąć pod uwagę:

1. Zgoda na harmonogram projektu
2. Dostępność klientów/interesariuszy/właściciela produktu (która może wyjaśnić potencjalne wątpliwości)
3. Kultura pracy klientów
4. Zdolności zespołu Scrum
5. Doświadczenie w Scrumie

Gdy zespół osiągnie porozumienie, wszystkie przyszłe sprints będą trwać tyle samo, bez częstych zmian długości sprintu. Jednak dobrą praktyką dla zespołu Scrum jest stale ocenianie skuteczności sprintu i poszukiwanie optymalnej długości sprintu, która najlepiej pasuje dla wszystkich.

Potwierdzenie prac (historii użytkownika) w sprintie

Działalność rozwojowa ustawia się wokół historii użytkownika po rozpoczęciu sprintu, a im dalej idzie sprint, tym więcej historii użytkownika jest realizowanych. Jednak pełna realizacja historii użytkownika to nie koniec historii. Wciąż pozostaje ważny krok – potwierdzenie.

Potwierdzenie historii użytkownika polega na przetestowaniu zaimplementowanej funkcji i ocenie, czy funkcja została zaimplementowana zgodnie z oczekiwaniami. Ocena powinna opierać się wyłącznie na kryteriach ustalonych podczas szczegółowego opisu historii użytkownika, zapisanych w formie elementów potwierdzenia. Podczas potwierdzania właścicielowi produktu udziela się środowiska testowego lub urządzenia do testowania zaimplementowanej pracy. Właściciel produktu przejdzie po kolei przez elementy potwierdzenia zapisane w historii użytkownika. Jeśli wszystkie elementy zostaną potwierdzone jako ukończone, historia użytkownika jest uznawana za potwierdzoną. Jeśli którykolwiek element zostanie uznany za nieukończony lub nie działający zgodnie z oczekiwaniami, właściciel produktu poprosi zespół rozwojowy o naprawę. Proces naprawy i potwierdzenia powtarza się, aż historia użytkownika zostanie całkowicie potwierdzona.

Kiedy potwierdzić?

Sprint, a w rzeczywistości agilne to ciągły proces dostarczania. Zamiast potwierdzać historie użytkownika na końcu sprintu, potwierdzenie powinno odbywać się od razu po ukończeniu każdej historii użytkownika. Jednak jeśli właściciel produktu nie może uczestniczyć w ciągłym potwierdzaniu, możesz ustalić tygodniowe spotkania trwające 1 do 2 godzin. Podczas spotkania właściciel produktu będzie pracować z zespołem nad potwierdzeniem ukończonych historii użytkownika. Spotkanie obejmuje również sesję dyskusyjną, która wyjaśnia wątpliwości pojawiające się podczas implementacji innych historii zawartych w sprintie.

Potwierdzenie nie jest równoważne testowaniu

Jak wspomniano, celem potwierdzenia jest zapewnienie, że historia użytkownika została poprawnie zaimplementowana. Ocena opiera się wyłącznie na elementach ustalonych jako elementy potwierdzenia podczas szczegółowego opisu historii użytkownika, nic więcej i nic mniej. Skala sprawdzania jest zbyt mała, aby zapewnić, że funkcja jest gotowa do użytkowania produkcyjnego. Kiedy więc wykonać „rzeczywiste testy”?

Różne zespoły mają różne praktyki dotyczące testowania oprogramowania. Niektóre zespoły preferują testy przeprowadzane na końcu każdego sprintu, które obejmują testy integracyjne i testy regresyjne. Inne zespoły preferują ustanowienie sprintu stabilizacyjnego, jak sama nazwa wskazuje, do testowania i usuwania błędów. W tym sprintie nie będą prowadzone żadne nowe działania rozwojowe.

Niezależnie od wybranej metody, pamiętaj, że wybór nie należy do jednej osoby, ale do wszystkich.

Visual Paradigm zapewnia wszystkie narzędzia, które potrzebujesz w rozwój oprogramowania agilnego, które obejmują narzędzie do rysowania diagramów przypadków użycia UML, (agile) historia użytkownika, sprint, karta historii i szkice do projektowania UX, narzędzie do zarządzania zadaniami, itd.