Udostępnij za pośrednictwem

Działania związane z końcem przebiegu

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Na koniec przebiegu zespoły mogą chcieć uczestniczyć w kilku zadaniach w celu zachowania higieny zaległości. Ogólnie rzecz biorąc, niepełna praca nigdy nie powinna być przypisana do przebiegu przeszłości. Zespoły muszą określić, jak chcą obsługiwać pracę, która nie została ukończona w przebiegu, i podjąć odpowiednie działania.

Uwaga

Nie ma automatycznego sposobu przenoszenia niekompletnych elementów roboczych przypisanych do jednego przebiegu do innego. Nie jest to również automatyczna metoda wyzerowania pozostałej pracy.

Na końcu każdego przebiegu każdy zespół powinien określić i podjąć działania, aby rozwiązać następujące pytania:

  • Jak powinniśmy radzić sobie z scenariuszami użytkowników i zadaniami, które są wykonywane tylko częściowo na końcu przebiegu?
  • Jaki jest prawidłowy sposób zarządzania częściowo wykonaną pracą na końcu, tak aby metryki przebiegu i szybkość zostały prawidłowo uwzględnione?
  • Co powinniśmy przejrzeć i w jakiej kolejności?

Ogólnie rzecz biorąc, działania zakończenia przebiegu powinny być wykonywane przed lub po spotkaniu przeglądu przebiegu i przed retrospektywą przebiegu. Głównym elementem, który należy wziąć pod uwagę, jest utrzymanie widoków i metryk, aby wspierać zespół w swoich przeglądach przebiegu, retrospektywach i planowaniu przebiegu.

Cele dotyczące działań zakończonych przebiegami

Każdy przebieg reprezentuje okres programowania, do którego przypisano pracę. Zapoznaj się z poniższą listą kontrolną, aby mieć na uwadze cele podczas wykonywania działań zakończonych przebiegami.

  • Zachowaj higienę listy prac, w której nie przypisano niekompletnej pracy do przebiegu, którego data zakończenia przypada w przeszłości
  • Zarządzanie stanami elementów roboczych i przypisaniami przebiegu w celu obsługi monitorowania postępu i szybkości zespołu
  • Ciągłe działania zespołu pomocy technicznej
  • Zespół pomocy technicznej koncentruje się na wysyłaniu oprogramowania i osiąganiu celów przebiegu
  • Minimalizowanie wysiłków śledzenia pracy, które nie mają żadnej wartości

Napiwek

Szybkość zespołu nie jest miarą produktywności zespołu i powinna być używana tylko jako metryka do planowania przyszłych przebiegów. Praca jest ukończona na końcu przebiegu lub nie jest. Jeśli tak się dzieje, zlicza się. Jeśli tak nie jest, zostanie ponownie rozpatrzona na przyszły przebieg, a nie bieżący przebieg. Szybkość ma tendencję do wyrównania się bez względu na to, jakie wybory dokonujesz. Jednak biorąc pod uwagę tylko wykonane prace, pracujesz w kierunku bardziej realistycznej wartości i znacznie lepszego źródła danych historycznych, aby przyszłe prognozy.

Wybieranie preferencji zespołu

Poniższe sugestie przejdą przez główne zespoły działań typu end-of-sprint powinny rozważyć wykonanie. Zazwyczaj te działania należy wykonać w ostatnim dniu przebiegu lub po spotkaniu przeglądu przebiegu.

  • Przejrzyj listę prac przebiegu pod kątem niekompletnych historii użytkownika, elementów listy prac i zadań. Przegląd można wykonać, przeglądając listę prac przebiegu lub tablicę zadań przebiegu.

  • Ponowne przypisywanie historii użytkowników, elementów listy prac i zadań, które nie zostały uruchomione do listy prac produktu lub następnego przebiegu. Korzystając z okienka Planowanie, możesz ponownie przypisać listę prac zespołu lub przyszły przebieg. Ponowne przypisanie elementów roboczych można ponownie oszacować i ustalić priorytety.

  • Określ, jak obsługiwać niekompletne scenariusze 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, aby przedstawić pracę ukończoną w bieżącym przebiegu i wykonać jeszcze pracę. Aby uzyskać więcej informacji, zobacz Kopiowanie lub klonowanie scenariuszy, problemów i innych elementów roboczych.
    • Ponownie przypisz historię do następnego przebiegu, w którym można wykonać pracę. Wszystkie niedokończone historie w bieżącym przebiegu stanowią zero do prędkości przebiegu.

  • Określ sposób obsługi pracy pozostałej dla ukończonych zadań. Jeśli zadania zostaną ukończone, wówczas wartość niezerowa dla pozostałej pracy nie ma sensu. Zespoły powinny zdecydować, w jaki sposób chcą obsługiwać te przypadki, i rozważyć ustawienie wartości Pozostała praca na zero dla ukończonych zadań.

Przejrzyj listę prac przebiegu pod kątem niekompletnej pracy

Aby określić niekompletną pracę, przejrzyj listę prac przebiegu dla pracy, która jest nadal w stanie zatwierdzonym, aktywnym i w toku. Zrzut ekranu przedstawiający listę prac przebiegu na końcu przebiegu.

Ponowne przypisywanie niekompletnych scenariuszy i zadań użytkownika do przyszłego przebiegu

Z listy prac przebiegu wybierz pozycję Wyświetl opcje i wybierz pozycję Planowanie. Przeciągnij i upuść elementy robocze, które są niekompletne do następnego przebiegu lub z powrotem do listy prac zespołu.

Jak pokazano na poniższej ilustracji, zaległości zespołu Fabrikam odpowiadają domyślnej ścieżce iteracji ustawionej dla zespołu. Należy pamiętać, że jeśli wartość domyślna jest ustawiona na makro @CurrentIteration , zaznaczenie to nie spowoduje zmiany ścieżki iteracji do momentu rozpoczęcia następnego przebiegu.

Zrzut ekranu przedstawiający listę prac przebiegu z włączonym okienkiem planowania.

Archiwizowanie poprzednich przebiegów

W miarę upływu czasu liczba przebiegów zdefiniowanych dla projektu lub przypisana do zespołu może wzrosnąć. Aby zminimalizować menu rozwijane dla ścieżek iteracji, administratorzy programu Project Administracja mogą wybrać przejście przeszłości przebiegów do obszaru archiwum. Utrzymując przypisanie przebiegu, ale przenosząc je w innym węźle przebiegu, wszystkie dane elementów roboczych są zachowywane. Wszystkie wykresy przebiegu i widżety nadal działają.

Jak pokazano na poniższej ilustracji, przebiegi z 2012 i 2013 r. zostały przeniesione w węźle Poprzednie przebiegi .

Zrzut ekranu przedstawiający zarchiwizowane ścieżki iteracji w węźle Poprzednie przebiegi.

Napiwek

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 przebiegu

Lista prac przebiegu automatycznie wskazuje bieżący przebieg jako aktywny przebieg na podstawie dat rozpoczęcia i zakończenia. Jeśli bieżąca data przypada w okresie przebiegu, odpowiedni przebieg jest bieżącym przebiegiem. Do następnego przebiegu aktywnego bieżącego przebiegu nie jest wymagana żadna dalsza akcja.

Jako administrator projektu lub zespołu zapoznaj się z poniższymi wskazówkami dotyczącymi zarządzania przebiegami.

  • Daty rozpoczęcia i zakończenia zdefiniowane dla przebiegów projektu nie powinny się nakładać.
  • Wszystkie przebiegi interesujące dla zespołu powinny być wybrane dla konfiguracji tego zespołu.
  • Dla projektu należy zdefiniować kilka przyszłych przebiegów i wybrać je dla zespołów.

Aby uzyskać więcej informacji, zobacz Definiowanie ścieżek iteracji (przebiegów) i konfigurowanie iteracji zespołu.