Działania związane z końcem sprintu
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Na koniec sprintu zespoły mogą chcieć zająć się kilkoma zadaniami w celu porządkowania backlogu. Ogólnie rzecz biorąc, niepełna praca nigdy nie powinna być przypisana do poprzedniego sprintu. Zespoły muszą określić, jak chcą postępować z pracą, która nie została ukończona podczas sprintu, i podjąć odpowiednie działania.
Uwaga
Nie ma automatycznego sposobu przenoszenia niekompletnych elementów roboczych przypisanych do jednego sprintu do innego. Nie jest to również automatyczna metoda wyzerowania Remaining Work.
Na końcu każdego sprintu każdy zespół powinien określić i podjąć działania, aby odpowiedzieć na następujące pytania:
- Jak powinniśmy zajmować się historyjkami użytkowników i ich zadaniami, które są tylko częściowo ukończone na końcu sprintu?
- Jaki jest prawidłowy sposób zarządzania częściowo wykonaną pracą pod koniec, aby metryki sprintu i prędkość zostały poprawnie uwzględnione?
- Co należy przejrzeć i w jakiej kolejności?
Ogólnie rzecz biorąc, działania związane z zakończeniem sprintu powinny być wykonywane przed lub po spotkaniu przeglądowym sprintu i przed retrospektywą sprintu . Głównym elementem, który należy wziąć pod uwagę, jest utrzymanie widoków i metryk, aby wspierać zespół w przeglądach sprintu, retrospektywach i planowaniu sprintu.
Cele dla czynności końcowych sprintu
Każdy sprint reprezentuje okres czasowy rozwoju, do którego przydzielono pracę. Zapoznaj się z poniższą listą kontrolną, aby mieć na uwadze cele, które należy mieć na uwadze podczas wykonywania działań związanych z zakończeniem sprintu.
- Zachowuj porządek w backlogu, w którym żadna niekompletna praca nie jest przypisana do sprintu, którego data zakończenia wypada w przeszłości.
- Zarządzanie stanami elementów roboczych i przypisaniami sprintów w celu obsługi monitorowania postępu i prędkości pracy zespołu
- Ciągłe działania doskonalące zespołu wsparcia
- Zespół wsparcia koncentruje się na wysyłaniu oprogramowania i osiąganiu celów sprintu
- Minimalizowanie wysiłków śledzenia pracy, które nie mają żadnej wartości
Wskazówka
Szybkość zespołu nie jest miarą produktywności zespołu i powinna być używana tylko jako wskaźnik do planowania przyszłych sprintów. Praca jest ukończona na końcu sprintu lub nie jest. Jeśli już jest zrobione, to się liczy. Jeśli tak nie jest, jest ponownie rozpatrywany na przyszłą iterację, a nie na bieżącą. Szybkość ma tendencję do wyrównania się bez względu na to, jakie wybory dokonujesz. Jednak biorąc pod uwagę tylko wykonane prace, dążysz do bardziej realistycznej wartości i znacznie lepszego źródła danych historycznych do tworzenia przyszłych prognoz.
Wybieranie preferencji zespołu
Poniższe sugestie przedstawiają główne końcowe działania sprintu, które zespoły powinny rozważyć wykonanie. Zazwyczaj te działania należy wykonać w ostatnim dniu sprintu lub po spotkaniu przeglądu sprintu .
Przejrzyj backlog sprintu dla niekompletnych historii użytkownika, elementów backlogu i zadań. Można dokonać przeglądu, przeglądając rejestr sprintu lub taskboard sprintu.
Przypisz ponownie historie użytkowników, elementy listy prac i zadania, które nie zostały rozpoczęte, do listy prac produktu lub następnej iteracji. Korzystając z okienka planowania , możesz ponownie przypisać zadania do backlogu zespołu lub przyszłego sprintu. Po ponownym przypisaniu elementów roboczych można je ponownie oszacować i ustalić ich priorytety.
Określ, jak obsługiwać niekompletne historyjki użytkownika, elementy listy prac lub zadania. Należy pamiętać, że celem jest dostarczenie działającego oprogramowania. Oto dwie opcje:
- Podziel historię na dwie części, aby przedstawić pracę ukończoną w bieżącym sprincie i pracę, która jeszcze musi zostać wykonana. Aby uzyskać więcej informacji, zapoznaj się z Kopiowanie lub klonowanie scenariuszy, zadań i innych elementów roboczych.
- Ponownie przypisz historię do następnego sprintu, w którym można wykonać prace. Wszystkie niedokończone historie w bieżącym sprincie nie są wliczane do prędkości sprintu.
Określ sposób obsługi pozostałej pracy dla ukończonych zadań. Jeśli zadania są ukończone, to niezerowa wartość Remaining Work nie ma większego sensu. Zespoły powinny zdecydować, w jaki sposób chcą obsługiwać te przypadki, i rozważyć ustawienie wartości Remaining Work na zero dla ukończonych zadań.
Przejrzyj backlog sprintu pod kątem niekompletnych zadań
Aby określić niekompletną pracę, przejrzyj backlog sprintu dla zadań, które pozostają w stanie zatwierdzonym, aktywnym lub w toku.
Przenieś niekompletne historyjki i zadania użytkowników do przyszłego sprintu.
Z backlogu Sprintu wybierz Widok opcji 
i wybierz Planowanie . Przeciągnij i upuść elementy robocze, które są niedokończone, do następnego sprintu lub z powrotem do backlogu zespołu.
Jak pokazano na poniższej ilustracji, listy prac zespołu firmy Fabrikam odpowiada domyślnej ścieżki iteracji ustawionej dla zespołu. Należy pamiętać, że jeśli wartość domyślna jest ustawiona na makro @CurrentIteration, to zaznaczenie nie spowoduje zmiany Ścieżki Iteracji aż do rozpoczęcia następnego sprintu.
Archiwizowanie poprzednich sprintów
W miarę upływu czasu liczba sprintów zdefiniowanych dla projektu lub przypisana do zespołu może wzrosnąć. Aby zminimalizować menu rozwijane dla ścieżek iteracyjnych, administratorzy projektu mogą wybrać przeniesienie zakończonych sprintów do obszaru archiwum. Utrzymując przypisanie do sprintu, ale przenosząc je pod innym węzłem sprintu, wszystkie dane zadań są zachowywane. Wszystkie wykresy sprintu i widżety nadal działają.
Jak pokazano na poniższej ilustracji, sprinty z 2012 i 2013 r. zostały przeniesione pod węzłem Poprzednie Sprinty.
Wskazówka
Wszystkie dane przechowywane w elementach roboczych są utrzymywane przez usługę Azure DevOps do momentu trwałego usunięcia elementów roboczych.
Porady dotyczące higieny sprintu
Backlog sprintu automatycznie wskazuje bieżący sprint jako aktywny na podstawie dat rozpoczęcia i zakończenia. Jeśli bieżąca data wypada w trakcie sprintu, to odpowiedni sprint jest bieżącym sprintem. ** Aby kolejny sprint stał się aktywnym sprintem bieżącym, nie jest wymagana żadna dodatkowa akcja.
Jako administrator projektu lub zespołu, upewnij się, że spełniasz poniższe wytyczne dotyczące zarządzania sprintami.
- Daty rozpoczęcia i zakończenia zdefiniowane dla sprintów projektu nie powinny się nakładać.
- Wszystkie sprinty istotne dla zespołu powinny być wybrane dla konfiguracji tego zespołu.
- W projekcie należy zdefiniować kilka przyszłych sprintów i wybrać je dla swoich zespołów.
Aby uzyskać więcej informacji, zobacz Definiowanie ścieżek iteracji (sprintów) i konfigurowanie iteracji zespołu.