Zmiana przepływu pracy dla typu elementu pracy

Możesz zmienić przepływu pracy dla typu elementu roboczego (ZEZWÓ) do obsługi procesów zespołu i firmowych. Pomoc techniczna wITs śledzenia wszystkich typów work─requirements, zadania, kod defects─to obsługuje przy użyciu rozwoju oprogramowania Team Foundation Server (TFS).

Przepływ pracy określa postęp logicznych i regresji pracy, który będzie wykonywać członków zespołu. Określa on również wartości, które są widoczne w menu rozwijanych w polach Stan i przyczyna.

Przepływ pracy dla elementu zaległego produktu (szablonu procesu Scrum

Przegląd domyślna Stany przepływu pracy obsługiwane w szablonach proces domyślny udostępnia TFS, zobacz Wybieranie szablonu procesu, praca z artefaktami projektu zespołowego. Uzyskać informacje o przepływie pracy definicji kompilacji, zobacz Dostosowywanie szablonu procesu kompilacji.

Wytyczne dotyczące projektowania przepływu pracy

Przepływ pracy można zdefiniować identyfikując pierwszy stanów i prawidłowe przejścia między nimi. WORKFLOW Sekcja definicji ZEZWÓ określa stany prawidłowe, przejścia, przyczyny przejścia i opcjonalne akcje, które będą wykonywane w przypadku członka zespołu zmienia stan elementu roboczego.

Ogólnie rzecz biorąc możesz skojarzyć każdy stan z roli członka zespołu i osoby w tej roli musi wykonać przetwarzania elementu roboczego przed zmianą stanu zadania. Przejścia definiowania progressions prawidłowe i strat między stany. Ze względów identyfikujący przyczynę członek zespołu zmiana elementu pracy z jednego stanu do drugiego i automatyzacja pomocy technicznej akcje przejścia elementów roboczych w punkcie w przepływie pracy.

Na przykład, jest ustawiany Nowy po testerem otwiera nowe usterkę, która jest oparta na domyślny szablon procesu elastyczne który Team Foundation Server udostępnia (TFS). Projektant zmienia stan na Active przy ustalaniu usterkę, a po rozwiązaniu, deweloper zmiany stanu, tak aby rozwiązany i ustawia wartość pola Przyczyna do Stała. Po sprawdzeniu rozwiązać, tester zmianą stanu usterkę w celu zamknięte i pola Przyczyna zweryfikowanego. Tester ustalić, czy deweloper nie ustalonej usterkę, tester zmienią stan usterkę w celu Active i określ przyczynę jako nie usunięty lub Test nie powiódł się.

Jak zaprojektować lub zmodyfikowania przepływu pracy, należy wziąć pod uwagę poniższe wskazówki:

• Użyj STATE element, aby zdefiniować stan unikatowy dla każdego roli członka zespołu, którego instalacja trwa od określonej akcji dla elementu pracy. Więcej stanów definiujemy, więcej przejścia, które należy zdefiniować. Bez względu na kolejności, w której definiujesz stanach, są wyświetlane w porządku alfanumerycznym w menu rozwijanym dla stanu pola.

  Po dodaniu do typu elementu roboczego, który pojawi się na stronach zaległości i tablicy w stanie Team Web Access, należy również mapować stanu do metastate. Zobacz Odwołanie elementu XML konfiguracji procesu.

• Użyj TRANSITION elementu do definiowania przejścia dla każdego postęp prawidłowe i regresji z jednego stanu do drugiego.

  Co najmniej należy zdefiniować co przejścia dla każdego stanu i przejście ze stanu null do stanu początkowego.

  Można określić tylko jeden przejście od nieprzypisane (null) do stanu początkowego. Po zapisaniu nowy element roboczy jest automatycznie przypisywany do stanu początkowego.

  Członek zespołu zmianie stanu elementu roboczego, że zmiana wyzwala przejścia i akcji zdefiniowanych przez użytkownika jest wykonywana dla wybranego stanu i przejścia. Użytkownicy mogą określać tylko Stany, które są prawidłowe, w oparciu o przejścia, które definiują dla bieżącego stanu. Ponadto ACTION element, który jest element podrzędny elementu TRANSITION, można zmienić stan elementu roboczego.

• Dla każdego przejścia definiujemy z powodu domyślne przy użyciu DEFAULTREASON elementu. Można określić dowolną liczbę przyczyn opcjonalne przy użyciu REASON elementu. Te wartości są wyświetlane w menu rozwijanym z Przyczyna pola.

• Można określić zasady, które zostaną zastosowane, gdy element roboczy zmienia stan, gdy go przechodzi lub gdy użytkownik wybierze opcję określonej przyczyny. Wiele z tych zasad w systemach warunkowych reguł, które można stosować podczas definiowania pól w FIELDS sekcji poniżej WORKITEMTYPE definicji. Aby uzyskać więcej informacji, zobacz Aktualizacja pól podczas zmiany przepływu pracy poniżej w tym temacie.

• Nazwy, które można przypisywać stany przyczyny są bez uwzględniania wielkości liter.

  Menu rozwijane dla pól Stan i przyczyna w edytorze formularza lub kwerendy elementu roboczego wyświetlane wartości przypisane w WORKFLOW sekcji typu elementu roboczego.

Przykład kodu i diagramu przepływu pracy

Następujące kodu pokazano w przykładzie WORKFLOW definicji usterek z szablonu procesu elastyczne. W tym przykładzie definiuje trzy stany i pięciu przejścia. STATE Elementy określić stany aktywny, rozwiązany i zamknięty. Wszystkie możliwe kombinacje dla postępu i regresji przejścia są definiowane dla trójstanowy, z wyjątkiem jednej. Nie zdefiniowano przejście z zamknięty na rozwiązany. Członkowie zespołu nie można rozpoznać elementu pracy tego typu, jeśli element roboczy jest zamknięty.

Wszystkie elementy na liście nie w tym przykładzie DEFAULTREASON, REASON, ACTION, i FIELD.

<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>

Stan przepływu pracy przykład diagramu — usterki spojrzenia ZEZWÓ

Określenia liczby i typów stanów

Należy określić liczbę i typy prawidłowe stany na podstawie liczby różne stany logicznych, w których chcesz pozycje robocze tego typu istnieć. Ponadto jeśli członków zespołu różnych wykonujące różne akcje, następnie można rozważyć definiowania stan, w zależności od roli elementu członkowskiego. Każdy stan odnosi się do akcji, że członek zespołu musi wykonać od elementu pracy, aby przenieść ją na następny stan. Dla każdego stanu należy zdefiniować określonych akcji i członków zespołu, którzy będą mogli wykonywać te czynności.

W poniższej tabeli przedstawiono przykład czterech stanów zdefiniowanych w celu śledzenia postępu funkcji i prawidłowe użytkowników, którzy musi wykonać wskazanego działania:

Stan	Prawidłowa nazwa użytkownika	Akcja do wykonania
Proponowane	Menedżer projektów	Może utworzyć każdy element roboczy funkcji. Jednak tylko menedżerów projektów można zatwierdzić lub odrzucić elementu pracy. Jeżeli Menedżer projektu zatwierdza funkcji, Menedżer projektu zmienia stan elementu roboczego jako aktywny; w przeciwnym razie członka zespołu powoduje zamknięcie go.
Aktywne	Rozwoju główny	Realizacji rozwoju nadzoruje rozwój tę funkcję. Po zakończeniu funkcją realizacji rozwoju zmienia stan elementu roboczego funkcji do przeglądu.
Przegląd	Menedżer projektów	Menedżer projektów analizuje funkcji zaimplementowana i zmienia stan elementu roboczego na zamknięte, jeśli implementacja jest zaspokojeniem zespołu.
Zamknięte	Menedżer projektów	Żadne dodatkowe działania oczekiwanego na elementów pracy, które są zamknięte. Te elementy znajdują się w bazie danych na potrzeby archiwizacji i raportowania.

Uwaga

Wszystkie stany są wyświetlane w porządku alfabetycznym na liście w formularzu dla elementu roboczego określonego typu, niezależnie od ich Określ sekwencji.

Zdefiniuj przejścia

Możesz kontrolować stany do i z których zespół elementów członkowskich można zmienić elementu pracy po zdefiniowaniu progressions prawidłowego stanu i strat. Jeśli nie zostanie zdefiniowana przejście z jednego stanu do innego Państwa, członkowie zespołu nie można zmienić określonego typu elementu roboczego z określonym stanie innym określonym stanie.

W poniższej tabeli opisano prawidłowy przejścia dla każdego z czterech stanów, które zostały opisane wcześniej w tym temacie, wraz z programem Przyczyna domyślny dla każdego z nich.

Stan	Przejście do stanu	Przyczyna domyślne
Proponowane	Aktywność (postęp)	Zatwierdzone do tworzenia aplikacji
	Zamknięte (postęp)	Nie zatwierdzone
Aktywne	Przegląd (postęp)	Spełnione kryteriów akceptacji
Przegląd	Zamknięte (postęp)	Funkcja zakończona
	Aktywność (regresji)	Nie spełnia wymagań
Zamknięte	Proponowana (regresji)	Rozważenia do zatwierdzenia
	Aktywność (regresji)	Zamknięty błąd

Można ograniczyć, który może wprowadzać przejście z jednego stanu do innego przy użyciu dla i nie atrybuty TRANSITION elementu. Jak w poniższym przykładzie pokazano, testerów można ponownie otworzyć usterkę, ale nie deweloperów.

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

Określ powody

Podczas członka zespołu zmienia pola stanu, użytkownik może zachować domyślny przyczynę przejścia tego lub różne przyczyny po zdefiniowaniu dodatkowe opcje. Należy użyć DEFAULTREASON Określ przyczynę domyślny jeden i tylko jeden element. Dodatkowe przyczyny należy określić tylko wtedy, gdy pomagają zespołu, śledzenie i raportów z danymi.

Na przykład dewelopera można określić jedną z następujących przyczyn podczas rozpoznawania usterkę: stałych (domyślnie), opóźniony, duplikat, jako zaprojektowany, nie można odtworzyć lub przestarzały. Każdy powód określa określonej akcji dla tester do wykonania w odniesieniu do błędu.

Uwaga

Wszystkich powodów są wyświetlane w kolejności alfabetycznej na liście w formularzu pracy dla elementów roboczych określonego typu, bez względu na to sekwencji, w którym można określić REASON elementów.

W poniższym przykładzie przedstawiono elementów, które określają przyczyny, dlaczego członek zespołu może zostać rozwiązana 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śl akcje

Ogólnie rzecz biorąc, członkowie zespołu zmiany stanu elementu roboczego określając różne wartości dla stanu pola, a następnie zapisać elementu pracy. Jednak można również zdefiniować ACTION element, który automatycznie zmienia stan elementu roboczego po wystąpieniu tego przejścia. Jak pokazano w poniższym przykładzie, można określić, czy elementy robocze usterkę powinno być rozwiązane automatycznie, jeśli są one skojarzone z plików, które deweloperem sprawdza, czy do kontroli wersji:

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

Można użyć ACTION elementu, aby automatycznie zmienić stan elementów roboczych określonego typu po wystąpieniu zdarzeń na innym miejscu zarządzania cyklem życia aplikacji programu Visual Studio firmy Microsoft, jak i poza Visual Studio Application Lifecycle Management (na przykład z narzędziem śledzi wywołania). Aby uzyskać więcej informacji, zobacz Automatyzacja zadań pól na podstawie stanu, przejścia lub powodu.

Aktualizacja pola podczas zmiany przepływu pracy

Można zdefiniować reguły, które aktualizują pola zawsze, gdy zachodzą następujące zdarzenia:

• Przypisz reguły pole w obszarze STATE zużycia reguł do zastosowania do wszystkich przejść do i przyczyn do wprowadzania informacjami o stanie.

• Przypisz reguły pole w obszarze TRANSITION zużycia reguł do zastosowania tego przejścia wszystkie ze względu na i wprowadzania tego przejścia.

• Przypisz reguły pole w obszarze DEFAULTREASON lub REASON zasady, które mają zastosowanie tylko w przypadku dlatego określonych zużycia.

Jeśli pole powinien zawsze zawierają tę samą wartość, zdefiniuj reguły w obszarze FIELD element, który definiuje tego pola. Aby dowiedzieć się więcej o korzystaniu z reguły, zobacz Zastosowanie reguły do pola elementu roboczego.

Należy starać się ograniczyć liczbę warunków zdefiniowanych przez użytkownika dla każdego typu elementu roboczego. Z każdej reguły warunkowej dodawanymi zwiększamy złożoności procesu weryfikacji, który występuje za każdym razem, czy członka zespołu zapisuje elementu pracy. Zestawy złożonych reguł może zwiększyć czas, który jest wymagane do zapisania elementu pracy.

Poniższe przykłady pokazują niektóre reguły, które są stosowane do pól systemu w szablonie procesu dla struktury MSF Zwinne Wytwarzanie oprogramowania.

Zmień wartość pola po zmianie stanu

Po wartości stanu pola dla elementu roboczego ma ustawioną wartość aktywny i element roboczy jest zapisywany, wartości uaktywniony przez i przypisany do pola automatycznie są ustawiane na nazwę bieżącego użytkownika. Ten użytkownik musi być członkiem Team Foundation Server Prawidłowi użytkownicy grupy. Wartość aktywowany data jest również zestawu pól automatycznie. W poniższym przykładzie pokazano elementy, które wymusić tej reguły:

<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 po zmianie wartości innego pola

Gdy wartość stanu pola dla elementu roboczego jest ustawiona na aktywny i element roboczy jest zapisywany, pola Data zamknięcia i zamknięty przez automatycznie są ustawiane na wartości null, a następnie przekształcona tylko do odczytu, jeśli używasz EMPTY elementu, jak w poniższym przykładzie przedstawiono.

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

Zdefiniuj pole w innym polu zawartości

Po wartość stanu pól dla elementu roboczego zmienia się na rozwiązany i element roboczy jest zapisany, wartość rozpoznać Przyczyna pole jest ustawione na wartość określonej przez użytkownika w Przyczyna pola. W poniższym przykładzie pokazano elementy, które wymusić tej reguły:

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

Pytania i odpowiedzi

Pyt.: to narzędzie umożliwia zmianę przepływu pracy lub Wyświetl diagramów stan przepływu pracy?

A: Yes. Można zmienić przepływu pracy lub wyświetl diagram stanu przepływu pracy, który jest definiowana za pomocą edytora procesu, narzędzie power dla Visual Studio. Aby uzyskać więcej informacji, zobacz następujące strony w witrynie sieci web firmy Microsoft: Team Foundation Server zaawansowanych narzędzi.

Pyt gdzie mogę uzyskać zapoznać się z omówieniem elementy XML definicji ZEZWÓ?

ODP zobacz Wszystkie elementy WITD XML — Odwołanie.