Modificați fluxurile de lucru pentru tipurile de articole de lucru (WIT) pentru a sprijini procesele de afaceri și procesele de comandă. WITs suportă urmărirea tuturor tipurilor de posturi - cerințe, sarcini, defecte de cod - pentru a sprijini dezvoltarea de software cu Team Foundation Server (TFS).
Fluxul de lucru determină progresul logic și regresia muncii pe care o vor realiza membrii echipei. În plus, setează valorile afișate în meniurile derulante în câmpurile Stare și Cauză.
Flux de lucru pentru un element de lucru nefinalizat asupra produsului (șablon de proces Scrum
Șabloanele implicite în procesul implicit al unui flux de lucru de revizuire, care oferă TFS, a se vedea. Lucrul cu artefacte proiect echipa selecție șablon de proces. Pentru mai multe informații despre construirea unei definiții a fluxului de lucru, consultați Configurarea șablonului procesului de asamblare.
Determinați fluxul de lucru identificând mai întâi stările și tranzițiile reale dintre ele. definiție Secțiunea WORKFLOW WIT se referă la o tranziții de stare valide provoacă tranziții și acțiuni opționale care urmează să fie efectuate atunci când un membru al echipei schimbă starea elementului de lucru.
În general, fiecare stat este asociat cu rolul membrului echipei și sarcina pe care această persoană trebuie să o îndeplinească pentru a procesa elementul de lucru înainte de a-și schimba starea. Tranzițiile determină progresele și regresiile reale dintre state. Motivele determină de ce un membru al echipei traduce un element de lucru dintr-o stare în alta și acțiunile care susțin automatizarea tranziției elementului de lucru la punctul din fluxul de lucru.
De exemplu, statul este setat la Nou. când testerul a detectat o nouă eroare care se bazează pe șablonul de proces Agile implicit pe care Team Foundation Server (TFS) îl oferă. Dezvoltatorul schimba starea la Active. când se rezolvă o eroare, iar după ce a stabilit dezvoltatorul modifică starea la Solved și stabilește valoarea Cause la Fixed. După verificarea patch-ului, testerul schimbă starea de eroare la închis. iar câmpul Cauză este schimbat la Verificat. În cazul în care testerul stabilește că dezvoltatorul nu a corecta eroarea, se va schimba starea de eroare cu privire la activitatea și indică motivul pentru care nu este fixă sau nu efectueze testul.
Atunci când proiectați sau modificați un flux de lucru, trebuie luate în considerare următoarele prevederi.
Folosind elementul STATE, puteți defini o stare unică pentru fiecare rol al membrului echipei care va efectua o singură acțiune cu elementul de lucru. Cu cât sunt determinate mai multe stări, cu atât mai multe tranziții trebuie definite. Indiferent de ordinea în care definiți stările, ele sunt listate în ordine alfanumerică din meniul derulant al câmpului Stare.
Dacă adăugați o stare la tipul de articol de lucru în paginile lucrărilor sau plăcilor nefinalizate din Team Web Access, trebuie de asemenea să traduceți starea în meta-stare. Vedeți referința pentru Elementele de configurare a procesului XML.
Folosind elementul TRANSITION, puteți defini o tranziție pentru fiecare progresie sau regresie de la o stare la alta.
Cel puțin trebuie să definiți o tranziție pentru fiecare stat, precum și o tranziție de la o stare nulă la o stare primară.
Puteți defini numai o tranziție de la o stare neasignată (zero) la o stare primară. Când salvați un nou articol de lucru, îi este asignată automat o stare primară.
Atunci când un membru al unei comenzi modifică starea elementului de lucru care modifică declanșatoarele de tranziție și acțiunile definite ca fiind necesare pentru a rula atunci când sunt selectate starea și tranziția. Utilizatorii pot specifica numai acele stări care sunt valide pe baza tranzițiilor definite pentru starea curentă. În plus, elementul ACTION. care este copilul TRANZIȚIEI. poate schimba starea elementului de lucru.
Pentru fiecare tranziție, trebuie să determinați motivul implicit utilizând elementul DEFAULTREASON. Puteți determina cât mai multe cauze posibile de care aveți nevoie, utilizând elementul REASON. Aceste valori sunt afișate în meniul derulant al câmpului Cauză.
Puteți defini regulile care vor fi aplicate atunci când modificările elementului de lucru sunt indicate atunci când efectuează o tranziție sau când utilizatorul selectează un anumit motiv. Multe dintre aceste reguli completează regulile de condiții care pot fi aplicate la definirea câmpurilor în secțiunea FIELDS sub definiția WORKITEMTYPE. Pentru informații suplimentare, consultați Actualizarea câmpurilor în timp ce modificați fluxul de lucru mai târziu în această secțiune.
Numele care sunt atribuite unor state și motive sunt necunoscute în registru.
Următorul exemplu de cod arată WORKFLOW pentru definirea erorilor WIT în șablonul proces Agile. În acest exemplu, sunt definite trei state și cinci tranziții. Elementele STATE determină starea "activ", "rezolvat" și "închis". Toate combinațiile posibile pentru progresia și regresia tranzițiilor sunt definite pentru trei stări, cu excepția unuia. Trecerea de la starea închisă la rezolvată nu este definită. Prin urmare, membrii echipei nu pot rezolva articolul de lucru de acest tip dacă lucrarea este în starea închisă.
Exemplul nu conține elementele pentru DEFAULTREASON. MOTIVUL. ACȚIUNE. și FIELD.
Când un membru al echipei schimbă câmpul de stare, acesta poate lăsa cauza implicită pentru această tranziție sau poate specifica un alt motiv dacă specificați alte opțiuni. Trebuie să utilizați elementul DEFAULTREASON pentru a determina implicit un singur motiv. Trebuie să specificați motive suplimentare doar dacă acestea ajută echipa să urmărească datele sau să o organizeze în rapoarte.
De exemplu, un dezvoltator poate specifica una dintre următoarele motive pentru rezolvarea erorii: „învechit“ „Fixed“ (implicit) „Delayed“, „duplicat“, „nici o vină“, „nu poate juca“ sau Fiecare motiv indică o acțiune specifică pentru tester în ceea ce privește eroarea.
Toate cauzele apar în ordine alfabetică în lista din formularul de lucru pentru un articol de lucru de un anumit tip, indiferent de secvența în care sunt definite elementele REASON.
Următorul exemplu prezintă elementele care determină motivele pentru care un membru al echipei poate remedia o eroare.
Puteți defini reguli care vor actualiza câmpurile ori de câte ori apar următoarele evenimente:
Atribuiți o regulă de câmp la STATE. dacă este necesar ca regula să fie aplicată pentru toate tranzițiile la această stare și motivele pentru intrarea în această stare.
Atribuiți o regulă de câmp la TRANSITION. dacă este necesar, să se aplice regula pentru această tranziție și pentru toate motivele tranziției.
Atribuiți o regulă de câmp la DEFAULTREASON sau REASON. dacă este necesar ca regulile să fie aplicate numai din acest motiv special.
Puteți încerca să minimalizați numărul de condiții care sunt definite pentru orice tip de articol de lucru. Cu fiecare regulă de condiție adăugată, complexitatea procesului de verificare crește, care este efectuată de fiecare dată când membrul echipei salvează articolul de lucru. Seturile de reguli complexe pot mări timpul necesar pentru a salva un element de lucru.
Atunci când câmpul Stare la un element de lucru este setat la modul activ și un element de lucru este salvat, câmpurile activate de () și atribuiți (a) este atribuit în mod automat numele utilizatorului curent Utilizatorul trebuie să fie membru al unui utilizator valid Team Foundation Server. Valoarea câmpului Data activării este, de asemenea, setată automat. Următorul exemplu prezintă elementele care implementează această regulă.