Projektowanie przepływu pracy

Można zaprojektować przepływ pracy dla typu elementu pracy w celu wspierania działalności i procesy w zespole.Przepływ pracy określa logicznym zadań, które będą wykonywane i przez kogo.Definiujemy przepływu pracy, identyfikując pierwszego stanów i prawidłowe przejścia między nimi.WORKFLOW Sekcji definicji dla stanów prawidłowy definiuje typ pozycji roboczej przejścia, powody do przejść i opcjonalne akcje, które będą wykonywane, gdy członek zespołu zmienia stan elementu pracy.Aby uzyskać więcej informacji na temat definicji typu, zobacz Wszystkie odniesienia do elementów XML WITD.

Ogólnie rzecz biorąc skojarzyć z każdego Państwa, z roli członka zespołu oraz zadań, które osoba w tej roli należy wykonać, aby przetworzyć elementu pracy przed zmianą jego stanu.Przejścia zdefiniować prawidłowy progresje i regresji między Państwami.Powody w zidentyfikowaniu członek zespołu zmienia element pracy z jednego stanu do drugiego i automatyzacja obsługi akcje przejścia elementu pracy w punkcie w przepływie pracy.

Ważne
Jeśli dodasz stan typ pozycji roboczej, który pojawia się na stronach zaległości lub Zarząd w Team Web Access, muszą również mapować Państwa, do metastate.Zobacz Dostosowywanie stron zaległości i tablic poprzez konfigurowanie procesów.

Na przykład ustawiono stan New kiedy tester otwiera nowy błąd, który opiera się na podstawie domyślnego szablonu procesu Agile, Team Foundation Server (TFS) zapewnia.Autora zmienia stan, aby Active gdy naprawianie błędów i skoro stały, autora zmienia się jego stanu, aby rozwiązany i ustawia wartość pola powód do stałe.Po sprawdzeniu, poprawki, tester zmienia stan błąd do Closed a w polu powód do Zweryfikowano.Jeżeli tester ustala, że programista nie miał stałe błąd, tester zmieni stan błąd do Active i określanie przyczyny jako Nie ustalono lub Test nie powiódł się.

[!UWAGA]

Można tworzyć i modyfikować definicje typów elementów pracy i inne obiekty, do śledzenia elementów pracy za pomocą edytora procesu, narzędzie zasilania do Visual Studio.To narzędzie nie jest obsługiwana.Aby uzyskać więcej informacji, zobacz następującą stronę w witrynie sieci web firmy Microsoft: Team Foundation Server narzędzia.

W tym temacie

• Wytyczne dotyczące projektowania przepływu pracy

• Diagram przepływu pracy i przykładowy kod

• Określanie liczby i rodzaju Państwa

• Definiowanie przejścia

  • Określanie przyczyny

  • Określanie działania

• Aktualizowanie pola po zmianie stanu

  • Definiowania danego pola, gdy zmienia stan

  • Usuwanie wartości pola

  • Definicji pola, w oparciu o zawartość innego pola

• Przeglądanie Diagram stanu przepływu pracy

Wytyczne dotyczące projektowania przepływu pracy

Jak zaprojektować lub zmodyfikować przepływ pracy, należy wziąć pod uwagę następujące wskazówki:

• Za pomocą STATE element, definiowania stanu unikatowego dla każdej roli członka zespołu, który będzie podjęcia konkretnych działań na elementu pracy.Więcej stanów definiujesz, więcej przejścia, które należy zdefiniować.Niezależnie od kolejności, w której definiujesz stanów, są one wyświetlane w kolejności alfanumerycznej w Państwo listy.

• Za pomocą TRANSITION elementu, zdefiniuj przejścia dla każdego prawidłowy postęp i regresji z jednego Państwa do drugiego.

• Jako minimum należy zdefiniować jedno przejście do każdego Państwa oraz przejście ze stanu wartości null do stanu początkowego.

• Dla każdego przejścia trzeba określić przyczyny domyślne za pomocą DEFAULTREASON element.Można zdefiniować tyle powodów opcjonalne, jak chcesz za pomocą REASON element.

• Menu rozwijanych dla pól Stan i przyczyna w edytorze lub kwerendzie formularza elementu pracy wyświetlane wartości przypisane w WORKFLOW sekcji Typ pozycji roboczej.

• Można zdefiniować tylko jedno przejście od nieprzypisane (null) do stanu początkowego.Gdy zapisujesz nowy element pracy, następuje automatyczne przypisanie do stanu początkowego.

• Kiedy członek zespołu zmienia stan elementu pracy, że zmiana wywołuje przejścia i akcji, zdefiniowanych przez użytkownika ma być wykonana nad stanu i przechodzenia.Użytkownicy mogą określać tylko te województwa, które są dozwolone w oparciu o przejścia, zdefiniowanych przez użytkownika dla bieżącego stanu.Dodatkowo ACTION element, który jest elementem podrzędnym elementu z TRANSITION, można zmienić stan elementu pracy.

• Można zdefiniować reguły warunkowe do dowolnego pola, która będzie stosowana, gdy element pracy zmieni stan, gdy to przejście lub gdy użytkownik zaznaczy konkretnego powodu.Wiele z tych reguł uzupełnienia zasady warunkowe, które można stosować podczas definiowania pól w FIELDS działu pod WORKITEMTYPE definicji.Aby uzyskać więcej informacji, zobacz Aktualizacji pól podczas zmiany stanu dalszej części tego tematu.

• Należy próbować zminimalizować liczbę warunków, które można zdefiniować dla każdego typu elementu pracy.Z każdą regułą warunkowe, którą dodano zwiększa się złożoność procesu sprawdzania poprawności, który występuje za każdym razem, że członek zespołu zapisuje elementu pracy.Zestawy reguł złożonych może wydłużyć czas wymagany do zapisania elementu pracy.

• Nazwy, które można przypisać do Państwa i powodach jest rozróżniana.

Powrót do początku

Diagram przepływu pracy i przykładowy kod

W poniższej tabeli przedstawiono WORKFLOW sekcji definicja typ pozycji roboczej, umożliwiający śledzenie wady kodu oraz diagram stanu przepływu pracy, który definiuje.W tym przykładzie definiuje trzy stany, przejścia sześciu i dziewięciu powodów.STATE Elementy określić Państwa aktywne, rozwiązany i zamknięty.Wszystkie możliwe kombinacje dla przejścia postęp i regresji są zdefiniowane dla trzech państw, z wyjątkiem jednego.Nie zdefiniowano przejścia z zamknięty na rozwiązany.Członkowie zespołu nie można rozpoznać elementu pracy tego typu, jeśli element pracy jest zamknięty.

[!UWAGA]

Przykład nie są wyświetlane elementy dla DEFAULTREASON, REASON, ACTION, i FIELD.

<WORKFLOW> <STATES>   <STATE value="Active">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Resolved">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Closed" /> </STATES> <TRANSITIONS>   <TRANSITION from="" to="Active">     <REASONS>       <DEFAULTREASON value="New" />     </REASONS>     <FIELDS> . . . </FIELDS>   </TRANSITION>   <TRANSITION from="Active" to="Resolved">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Closed">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Active" to="Closed ">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Closed" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> </TRANSITIONS> </WORKFLOW>

Diagram stanu przepływu pracy przykład

Określanie liczby i rodzaju Państwa

Można określić liczbę i typy prawidłowy państw na podstawie liczby oddzielne Państwa logicznych, w których chcesz pozycje robocze tego typu istnieje.Ponadto jeśli inni członkowie zespołów wykonywać różne działania, następnie można rozważyć określające państwo, na podstawie roli Państwa.Każde Państwo odpowiada akcję, że członek zespołu musi wykonać na element pracy, aby przenieść ją do następnego stanu.Dla każdego Państwa należy zdefiniować konkretne działania i członków zespołu, którzy mają zezwolenie na wykonywanie tych czynności.

Poniższa tabela zawiera przykład czterech stanów, które są zdefiniowane w celu śledzenia postępu funkcją i uprawnieni użytkownicy, którzy muszą wykonywać akcje wskazane:

Państwo	Prawidłowego użytkownika	Akcję do wykonania
Proponowane	Menedżer projektu	Każdy może tworzyć elementu pracy funkcji.Jednak tylko menedżerowie projektów mogą zatwierdzić lub odrzucić element pracy.Jeżeli Menedżer projektu zatwierdza funkcją, Menedżer projektu zmienia stan elementu pracy na aktywny; w przeciwnym razie członek zespołu zamyka go.
Aktywne	Rozwój potencjalnego klienta	Realizacji rozwoju nadzoruje rozwój funkcji.Po zakończeniu funkcji ołowiu rozwoju zmienia stan elementu pracy funkcji do przeglądu.
Przegląd	Menedżer projektu	Menedżer projektu przegląda funkcji, że zespół wdrożone i zmienia stan elementu pracy na zamknięte, jeśli wprowadzanie jest zadowalające.
Zamknięte	Menedżer projektu	Wykonywanie innych czynności nie oczekuje się na pozycje robocze, które są zamknięte.Te elementy pozostają w bazie danych dla celów archiwizacji i raportowania.

[!UWAGA]

Wszystkie Państwa są wyświetlane w kolejności alfabetycznej na liście w formularzu dla elementu pracy określonego typu, niezależnie od kolejności, w której określone.

Powrót do początku

Definiowanie przejścia

Możesz kontrolować Państwa do i z sumowany członków można zmienić elementu pracy w przypadku zdefiniowania stanie ' prawidłowy ' progresje i regresji.Jeżeli nie zdefiniujesz przejście z jednego stanu do innego Państwa, członkowie zespołu nie można zmienić do innego Państwa określonego elementu pracy określonego typu z określonym stanie.

W poniższej tabeli zdefiniowano prawidłowy przejść dla każdego z czterech stanów, które zostały opisane wcześniej w tym temacie, wraz z powodami domyślne dla każdego.

Państwo	Przejść do stanu	Przyczyny domyślne
Proponowane	Aktywne (postęp)	Zatwierdzone do rozwoju
	Zamknięte (postęp)	Nie zatwierdzone
Aktywne	Przegląd (postęp)	Spełnione kryteria akceptacji
Przegląd	Zamknięte (postęp)	Zakończenie opracowywania funkcji
	Aktywne (regresji)	Nie spełnia wymagań
Zamknięte	Proponowane (regresji)	Ponowne rozpatrzenie do zatwierdzenia
	Aktywne (regresji)	Zamknięte omyłkowo

Można ograniczyć, kto może dokonać przejścia z jednego Państwa do drugiego za pomocą dla i nie atrybuty TRANSITION element.Jak pokazano na poniższym przykładzie, testerzy można ponownie otworzyć błąd, ale nie może deweloperów.

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

Powrót do początku

Określanie przyczyny

Podczas członek zespołu zmienia pola stanu, danego użytkownika można zachować domyślny przyczynę tego przejścia lub inny powód w przypadku zdefiniowania dodatkowych opcji.Należy użyć DEFAULTREASON element, aby określić tylko jeden powód domyślne.Należy określić dodatkowe przyczyny, tylko wtedy, gdy one pomóc zespołowi śledzić lub danych raportu.

Na przykład, deweloper można określić jedną z następujących powodów podczas rozpoznawania błąd: stała (ustawienie domyślne), odłożony, duplikat, zgodnie z projektem, nie można odtworzyć lub nieaktualne.Każdy powód określa określonej akcji dla tester do wykonywania w odniesieniu do błędów.

[!UWAGA]

Wszystkich powodów są wyświetlane w kolejności alfabetycznej na liście w formularzu pracy dla elementów pracy określonego typu, niezależnie od kolejności, w której zostanie określone REASON elementy.

Elementów, które określają powody, dlaczego członek zespołu może rozwiązać błąd można znaleźć w poniższym przykładzie:

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

Powrót do początku

Określanie działania

Ogólnie rzecz biorąc, członkowie zespołu zmienić stan elementu pracy, określając inną wartość dla Państwo pole, a następnie zapisać element pracy.Jednakże można także zdefiniować ACTION element, który automatycznie zmienia stan elementu pracy po wystąpieniu tego przejścia.Jak pokazano na poniższym przykładzie, można określić, że pozycje robocze błędów powinny zostać rozwiązane automatycznie, jeśli są one skojarzone z plikami, które projektant sprawdza, czy do kontroli wersji:

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

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

Powrót do początku

Aktualizowanie pola

Można zdefiniować reguły, które zaktualizować pola w każdym przypadku, gdy wystąpią następujące zdarzenia:

• Przypisz reguły pole w obszarze STATE kiedy chcesz zastosować do wszystkich przejść do i powody, dla których to Państwo regułę.

• Przypisz reguły pole w obszarze TRANSITION kiedy chcesz zastosować dla tego przejścia i wszystkich przyczyn dokonania tego przejścia regułę.

• Przypisz reguły pole w obszarze DEFAULTREASON lub REASON kiedy chcesz zasady mające zastosowanie tylko dla tego konkretnego powodu.

Jeśli pole ma zawsze zawierać tę samą wartość, aby zdefiniować reguły w obszarze FIELD element, który definiuje tego pola.Aby uzyskać więcej informacji, zobacz Ustawianie warunków pola elementu pracy.

Następujące przykłady przedstawiają niektóre reguły, które są stosowane do pól systemowych w szablonie procesu na v5.0 MSF Agile Software Development.

• Zmiana wartości pola po zmianie stanu

• Usuwanie wartości pola po zmianie wartości innego pola

• Definicji pola, w oparciu o zawartość innego pola

Powrót do początku

Zmiana wartości pola po zmianie stanu

Gdy wartość Państwo pola dla elementu pracy jest ustawiona na aktywny i element pracy jest zapisywany, wartości Aktywowany przez i Przydzielone do pól są automatycznie ustawiane na nazwę bieżącego użytkownika.Użytkownik musi być członkiem Team Foundation Server grupy uprawnieni użytkownicy.Wartość Aktywowany Data pole również jest ustawiana automatycznie.Elementy, które wymuszają tej reguły można znaleźć w poniższym przykładzie:

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

Powrót do początku

Usuwanie wartości pola po zmianie wartości innego pola

Gdy wartość Państwo pola dla elementu pracy jest ustawiona na aktywny i zapisać elementu pracy, w polach Data zamknięte i zamknięte przez są automatycznie ustawiane na wartości null i wykonane tylko do odczytu klienci korzystający z EMPTY element, jak pokazano w następującym przykładzie.

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

Powrót do początku

Definicji pola, w oparciu o zawartość innego pola

Gdy wartość Państwo dla elementu pracy zmienia się na rozwiązany i element pracy jest zapisany, wartość w polu Rozwiązany powód pole jest ustawione na wartość, określonej przez użytkownika w przyczyny pole.Elementy, które wymuszają tej reguły można znaleźć w poniższym przykładzie:

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

Powrót do początku

Przeglądanie Diagram stanu przepływu pracy

Można przeglądać diagram stanu przepływu pracy, które są definiowane za pomocą edytora procesu, narzędzie zasilania do Visual Studio.To narzędzie nie jest obsługiwana.Aby uzyskać więcej informacji, zobacz następującą stronę w witrynie sieci web firmy Microsoft: Team Foundation Server narzędzia.

Powrót do początku

Zobacz też

Inne zasoby

Definiowanie i dostosowywanie przepływu pracy elementu pracy