Share via

Zmienianie przepływu pracy dla typu elementu roboczego

  • Artykuł

Azure DevOps Server 2022 — Azure DevOps Server 2019

Możesz zmienić przepływ pracy dla typu elementu roboczego (WIT), aby obsługiwać procesy biznesowe i zespołowe. Sieci WITs obsługują śledzenie wszystkich typów pracy — wymagań, zadań, wad kodu — w celu obsługi tworzenia oprogramowania.

Przepływ pracy określa logiczny postęp i regresję pracy, którą będą wykonywać członkowie zespołu. Określa również wartości wyświetlane w menu rozwijanych dla pól Stan i Przyczyna. Aby uzyskać więcej informacji, zobacz About processes and process templates (Informacje o procesach i szablonach procesów).

Przepływ pracy elementu listy prac produktu (szablon procesu Scrum)

Przepływ pracy elementu listy prac produktu, proces Scrum

Uwaga

W tym artykule opisano sposób dostosowywania stanu przepływu pracy. Jeśli zamiast tego chcesz zmienić stan przypisany do określonego elementu roboczego, zobacz jeden z następujących artykułów: Tablica Kanban, Śledzenie pracy w toku lub Tablica zadań, Aktualizowanie stanu zadania. Można również wykonać zbiorczą aktualizację stanu dla wielu elementów roboczych.

Aby uzyskać informacje na temat przepływów pracy potoku kompilacji, zobacz Wprowadzenie do ciągłej integracji/ciągłego wdrażania.

Aktualizowanie definicji XML dla typu elementu roboczego

Jeśli dopiero zaczynasz dostosowywanie funkcji WIT, zwróć uwagę na następujące kwestie:

Aby dostosować przepływ pracy, wykonaj następujące dwa kroki:

  1. Zmodyfikuj sekcję WORKFLOW definicji funkcji WIT zgodnie z opisem w tym temacie.

  2. Zmodyfikuj konfigurację procesu, aby zamapować nowe stany przepływu pracy na metastany.

    Ten drugi krok jest wymagany w przypadku zmiany przepływu pracy dla elementu WIT wyświetlanego na stronie narzędzia Agile. Te sieci WIT należą do kategorii Wymaganie lub Zadanie. Aby dowiedzieć się więcej na temat kategorii stanów, zobacz Kategorie stanów i stanów przepływu pracy.

Wskazówki dotyczące projektowania przepływu pracy

Przepływ pracy należy zdefiniować, identyfikując najpierw stany i prawidłowe przejścia między nimi. Sekcja WORKFLOW definicji funkcji WIT określa prawidłowe stany, przejścia, przyczyny przejścia i opcjonalne akcje, które będą wykonywane, gdy członek zespołu zmieni stan elementu roboczego.

Ogólnie rzecz biorąc, każdy stan należy skojarzyć z rolą członka zespołu i zadaniem, które osoba w tej roli musi wykonać w celu przetworzenia elementu roboczego przed zmianą jego stanu. Przejścia definiują prawidłowe progresje i regresje między stanami. Powody, dla których członek zespołu zmienia element roboczy z jednego stanu na inny, a akcje obsługują automatyzację przejścia elementu roboczego w punkcie przepływu pracy.

Na przykład stan jest ustawiony na Nowy , gdy tester otworzy nową usterkę opartą na domyślnym procesie Agile. Deweloper zmienia stan na Aktywny podczas naprawiania usterki, a po naprawieniu deweloper zmienia jego stan na Rozwiązane i ustawia wartość pola Przyczyna na Naprawiono. Po zweryfikowaniu poprawki tester zmienia stan usterki na Zamknięte , a pole Przyczyna zmieni się na Zweryfikowano. Jeśli tester ustali, że deweloper nie usunął usterki, tester zmieni stan usterki na Aktywny i określ przyczynę jako Nie naprawiono lub Test niepowodzenie.

Podczas projektowania lub modyfikowania przepływu pracy należy wziąć pod uwagę następujące wskazówki:

  • STATE Użyj elementu , aby zdefiniować unikatowy stan dla każdej roli członka zespołu, która podejmie określoną akcję dla elementu roboczego. Tym więcej stanów definiujesz, tym więcej przejść należy zdefiniować. Niezależnie od sekwencji, w której definiujesz stany, są one wymienione w kolejności alfanumerycznej w menu rozwijanym dla pola Stan .

    Jeśli dodasz stan do typu elementu roboczego, który pojawi się na stronach listy prac lub tablicy w portalu internetowym, musisz również zamapować stan na kategorię stanu. Aby dowiedzieć się więcej, zapoznaj się z tematem Stany przepływu pracy i kategorie stanów.

  • TRANSITION Użyj elementu , aby zdefiniować przejście dla każdego prawidłowego postępu i regresji z jednego stanu na inny.

    Co najmniej należy zdefiniować jedno przejście dla każdego stanu, a przejście ze stanu null do stanu początkowego.

    Można zdefiniować tylko jedno przejście z nieprzypisanego (null) do stanu początkowego. Podczas zapisywania nowego elementu roboczego jest on automatycznie przypisywany do stanu początkowego.

    Gdy członek zespołu zmieni stan elementu roboczego, spowoduje to wyzwolenie przejścia i akcji zdefiniowanych do wykonania dla wybranego stanu i przejścia. Użytkownicy mogą określić tylko te stany, które są prawidłowe na podstawie przejść zdefiniowanych dla bieżącego stanu. Ponadto ACTION element, który jest elementem TRANSITIONpodrzędnym elementu , może zmienić stan elementu roboczego.

  • Dla każdego przejścia należy zdefiniować domyślną przyczynę przy użyciu DEFAULTREASON elementu . Możesz zdefiniować dowolną liczbę opcjonalnych przyczyn, używając REASON elementu . Te wartości są wyświetlane w menu rozwijanym pola Przyczyna .

  • Możesz określić reguły, które będą stosowane, gdy element roboczy zmieni stan, przejście lub gdy użytkownik wybierze określony powód. Wiele z tych reguł uzupełnia reguły warunkowe, które można zastosować podczas definiowania pól w FIELDS sekcji w WORKITEMTYPE definicji. Aby uzyskać więcej informacji, zobacz Aktualizowanie pól podczas zmiany przepływu pracy w dalszej części tego tematu.

  • Nazwy przypisywane do stanów i przyczyn są bez uwzględniania wielkości liter.

    Menu rozwijane pól State and Reason w formularzu elementu roboczego lub edytorze zapytań wyświetlają wartości przypisane w WORKFLOW sekcji typu elementu roboczego.

Przykładowy diagram przepływu pracy i kod

Poniższy przykład kodu przedstawia WORKFLOW definicję usterki WIT dla szablonu procesu Agile. W tym przykładzie zdefiniowano trzy stany i pięć przejść. STATE Elementy określają stany Aktywne, Rozwiązane i Zamknięte. Wszystkie możliwe kombinacje przejść progresji i regresji są definiowane dla trzech stanów, z wyjątkiem jednej. Przejście z Zamknięte na Rozwiązane nie jest zdefiniowane. W związku z tym członkowie zespołu nie mogą rozpoznać elementu roboczego tego typu, jeśli element roboczy jest zamknięty.

W tym przykładzie nie wymieniono wszystkich elementów dla elementów DEFAULTREASON, REASON, ACTIONi FIELD.

Przykładowy diagram stanu przepływu pracy — agile bug WIT

Stany przepływu pracy błędów, szablon procesu Agile

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

Określanie liczby i typów stanów

Określasz liczbę i typy prawidłowych stanów na podstawie liczby odrębnych stanów logicznych, w których mają istnieć elementy robocze tego typu. Ponadto jeśli różni członkowie zespołu wykonują różne akcje, możesz rozważyć zdefiniowanie stanu na podstawie roli członka. Każdy stan odpowiada akcji, którą członek zespołu musi wykonać na elemencie roboczym, aby przenieść go do następnego stanu. Dla każdego stanu należy zdefiniować określone akcje i członków zespołu, którzy mogą wykonywać te akcje.

W poniższej tabeli przedstawiono przykład czterech stanów zdefiniowanych w celu śledzenia postępu funkcji oraz prawidłowych użytkowników, którzy muszą wykonywać wskazane akcje:

Stan Prawidłowy użytkownik Action to perform
Zaproponowano Menedżer projektu Każdy może utworzyć element roboczy funkcji. Jednak tylko menedżerowie projektów mogą zatwierdzać lub odrzucać element roboczy. Jeśli menedżer projektu zatwierdzi funkcję, menedżer projektu zmieni stan elementu roboczego na Aktywny; w przeciwnym razie członek zespołu go zamknie.
Aktywne Główny lider programowania Lider rozwoju nadzoruje rozwój funkcji. Po zakończeniu działania funkcji główny lider programowania zmienia stan elementu roboczego funkcji na Przegląd.
Wykonaj przegląd Menedżer projektu Menedżer projektu przegląda funkcję zaimplementowaną przez zespół i zmienia stan elementu roboczego na Zamknięty, jeśli implementacja jest zadowalająca.
Zamknięcie Menedżer projektu Nie ma żadnych dodatkowych akcji w przypadku zamkniętych elementów roboczych. Te elementy pozostają w bazie danych na potrzeby archiwizacji i raportowania.

Uwaga

Wszystkie stany są wyświetlane w kolejności alfabetycznej na liście w formularzu dla elementu roboczego określonego typu, niezależnie od sekwencji, w której je określisz.

Definiowanie przejść

Możesz kontrolować stany do i z których członkowie zespołu mogą zmienić element roboczy, jeśli zdefiniujesz prawidłowe progresje stanu i regresje. Jeśli nie zdefiniujesz przejścia z jednego stanu na inny, członkowie zespołu nie mogą zmienić elementu roboczego określonego typu z określonego stanu na inny stan.

W poniższej tabeli zdefiniowano prawidłowe przejścia dla każdego z czterech stanów opisanych wcześniej w tym temacie wraz z domyślną przyczyną każdego z nich.

Stan Przejście do stanu Przyczyna domyślna
Zaproponowano Aktywne (progresja) Zatwierdzone do programowania
Zamknięte (progresja) Niezatwierdzona
Aktywne Przegląd (progresja) Spełnione kryteria akceptacji
Wykonaj przegląd Zamknięte (progresja) Ukończono funkcję
Aktywne (regresja) Nie spełnia wymagań
Zamknięcie Proponowane (regresja) Ponowne rozważenie zatwierdzenia
Aktywne (regresja) Zamknięte w błędzie

Można ograniczyć, kto może przejść z jednego stanu na inny, używając atrybutów for i nie elementu TRANSITION . Jak pokazano w poniższym przykładzie, testerzy mogą ponownie otworzyć usterkę, ale deweloperzy nie mogą.

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>

Określ przyczyny

Gdy członek zespołu zmieni pole Stan, ten użytkownik może zachować domyślną przyczynę tego przejścia lub określić inny powód, jeśli zdefiniujesz dodatkowe opcje. Należy użyć DEFAULTREASON elementu , aby określić jedną i tylko jedną przyczynę domyślną. Należy określić dodatkowe przyczyny tylko wtedy, gdy pomogą zespołowi śledzić lub zgłaszać dane.

Na przykład deweloper może określić jedną z następujących przyczyn, gdy rozwiążą usterkę: Naprawiono (ustawienie domyślne), Odroczone, Zduplikowane, Zaprojektowane, Nie można odtworzyć lub przestarzałe. Każda przyczyna określa konkretną akcję, która ma być wykonywana przez testera w odniesieniu do usterki.

Uwaga

Wszystkie przyczyny są wyświetlane w kolejności alfabetycznej na liście w formularzu roboczym dla elementów roboczych określonego typu, niezależnie od sekwencji, w której określisz REASON elementy.

W poniższym przykładzie przedstawiono elementy definiujące przyczyny, dla których członek zespołu może usunąć usterkę:

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>

Określanie akcji

Ogólnie rzecz biorąc, członkowie zespołu zmieniają stan elementu roboczego, określając inną wartość pola Stan , a następnie zapisując element roboczy. Można jednak również zdefiniować ACTION element, który automatycznie zmienia stan elementu roboczego w momencie przejścia. Jak pokazano w poniższym przykładzie, można określić, że elementy robocze błędów powinny zostać rozwiązane automatycznie, jeśli są skojarzone z plikami, które deweloper sprawdza w kontroli wersji:

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>

Za pomocą ACTION elementu można automatycznie zmieniać stan elementów roboczych określonego typu, gdy zdarzenia występują w innym miejscu zarządzania cyklem życia aplikacji programu Microsoft Visual Studio lub poza zarządzanie cyklem życia aplikacji programu Visual Studio (na przykład za pomocą narzędzia śledzącego wywołania). Aby uzyskać więcej informacji, zobacz AKCJA.

Aktualizowanie pola podczas zmiany przepływu pracy

Możesz zdefiniować reguły aktualizujące pola za każdym razem, gdy wystąpią następujące zdarzenia:

  • Przypisz regułę pola w obszarze STATE , gdy chcesz, aby reguła dotyczyła wszystkich przejść do i przyczyn wprowadzenia tego stanu.

  • Przypisz regułę pola w obszarze TRANSITION , gdy chcesz, aby reguła miała zostać zastosowana do tego przejścia i wszystkie przyczyny dokonania tego przejścia.

  • Przypisz regułę pola w obszarze DEFAULTREASON lub REASON , jeśli chcesz, aby reguły miały zastosowanie tylko z tego konkretnego powodu.

    Jeśli pole powinno zawsze zawierać tę samą wartość, należy zdefiniować regułę w ramach elementu definiującego FIELD to pole. Aby dowiedzieć się więcej na temat użycia reguł, zobacz Reguły i ocena reguł.

    Należy spróbować zminimalizować liczbę warunków zdefiniowanych dla dowolnego typu elementu roboczego. W przypadku każdej dodawanej reguły warunkowej zwiększa się złożoność procesu weryfikacji, który występuje za każdym razem, gdy członek zespołu zapisuje element roboczy. Złożone zestawy reguł mogą zwiększyć czas wymagany do zapisania elementu roboczego.

    W poniższych przykładach przedstawiono niektóre reguły stosowane do pól systemowych w szablonie procesu dla programu MSF Agile Software Development.

Zmienianie wartości pola po zmianie stanu

Gdy wartość pola Stan dla elementu roboczego jest ustawiona na Wartość Aktywna, a element roboczy jest zapisywany, wartości pól Aktywowane przez i Przypisane do są automatycznie ustawiane na nazwę bieżącego użytkownika. Ten użytkownik musi być członkiem grupy Team Foundation Server Valid Users. Wartość pola Aktywowana data jest również ustawiana automatycznie. W poniższym przykładzie przedstawiono elementy wymuszające tę regułę:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>

Wyczyść wartość pola, gdy wartość innego pola ulegnie zmianie

Gdy wartość pola Stan dla elementu roboczego jest ustawiona na Wartość Aktywna, a element roboczy jest zapisywany, pola Data zamknięta i Zamknięte według są automatycznie ustawiane na wartość null i wykonywane tylko do odczytu, jeśli używasz EMPTY elementu, jak pokazano w poniższym przykładzie.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>

Definiowanie pola na podstawie zawartości innego pola

Gdy wartość pola Stan dla elementu roboczego zmieni się na Rozwiązane, a element roboczy zostanie zapisany, wartość pola Rozpoznana przyczyna jest ustawiona na wartość określoną przez użytkownika w polu Przyczyna. W poniższym przykładzie przedstawiono elementy wymuszające tę regułę:

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>

Obsługa narzędzi

Możesz wspierać użytkowników w celu wizualizacji przepływu pracy, instalując rozszerzenie Wizualizacja modelu stanu z witryny Visual Studio Marketplace.