Зміна робочих процесів для типів робочих елементів (WIT) для підтримки бізнес-процесів і командних процесів. WITs підтримують відстеження всіх типів робіт - вимог, завдань, дефектів коду - для підтримки розробки ПЗ за допомогою Team Foundation Server (TFS).
Робочий процес визначає логічну прогресію і регресію роботи, яку члени команди будуть виконувати. Крім того, він задає значення, які відображаються в меню, що розкриваються в полях «Стан» і «Причина».
Робочий процес для елемента невиконаної роботи по продукту (шаблон процесу Scrum
Для огляду станів робочого процесу за замовчуванням в шаблонах процесу за замовчуванням, які надає TFS, див. Робота з артефактами командного проекту, вибір шаблону процесу. Додаткову інформацію про побудову визначення робочого процесу, див. Налаштування шаблону процесу складання.
Визначення робочого процесу шляхом першого ідентифікації станів і дійсних переходів між ними. Розділ WORKFLOW визначення WIT вказує на дійсні стану, переходи, причини переходів і необов'язкові дії, які будуть виконані, коли член команди змінить стан робочого елемента.
Загалом, кожне стан асоціюється з роллю члена команди і завданням, яку ця людина з цією роллю повинен виконати для обробки робочого елемента перед зміною його стану. Переходи визначають дійсні прогресії і регресії між станами. Причини визначають, чому член команди переводить робочий елемент з одного стану в інший, і дії, що підтримують автоматизацію переходу робочого елемента на точку в робочому процесі.
Наприклад, стан встановлюється на Новий. коли тестувальник виявив нову помилку, яка заснована на шаблоні процесу Agile за замовчуванням, який надає Team Foundation Server (TFS). Розробник змінює стан на Активний. коли виправляє помилку, і після виправлення розробник змінює стан на Вирішений і встановлює значення Причини на Виправлено. Після перевірки виправлення тестувальник змінює стан помилки на Закрито. а поле Причина змінюється на Перевірено. Якщо тестувальник визначив, що розробник не виправив помилку, то він змінить стан помилки на Активний і вкаже Причину Чи не виправлено або Чи не вдалося виконати тест.
Проектуючи або модифікуючи робочий процес, необхідно взяти до уваги наступні положення.
За допомогою елемента STATE можна визначити унікальне стан для кожної ролі члена команди, який виконає будь-яке окреме дію з робочим елементом. Чим більше станів буде визначено, тим більше необхідно визначити переходів. Незалежно від послідовності, в якій ви визначаєте стану, вони перераховуються в буквено-цифровому порядку в спадному меню поля Стан.
Якщо додати стан до типу робочого елемента на сторінках невиконаної роботи або дощок в Team Web Access, необхідно також перевести стан в мета-. Див. Розділ Довідник по XML-елементів конфігурації процесу.
За допомогою елемента TRANSITION можна визначити перехід для кожної прогресії або регресії з одного стану в інший.
Як мінімум, необхідно визначити один перехід для кожного стану, а також перехід з нульового стану до первинного стану.
Можна визначити тільки один перехід з не обраного (нульового) в первинний стан. При збереженні нового робочого елемента йому автоматично призначається первинне стан.
Коли член команди змінює стан робочого елемента, яке змінює тригери переходу і дії, визначені як необхідні для виконання при обраному стані і переході. Користувачі можуть вказувати тільки ті стану, які є дійсними на основі переходів, які визначаються для поточного стану. Крім того, елемент ACTION. який є дочірнім елементом TRANSITION. може змінити стан робочого елемента.
Для кожного переходу необхідно визначити причину за замовчуванням за допомогою елемента DEFAULTREASON. Можна визначити стільки можливих причин, скільки буде потрібно, за допомогою елемента REASON. Ці значення відображаються в спадному меню поля Причина.
Можна визначити правила, які будуть застосовуватися, коли робочий елемент змінює стан, коли він здійснює перехід або коли користувач вибирає особливу причину. Багато з цих правил доповнюють правила умов, які можна застосувати при визначенні полів в секції FIELDS під визначенням WORKITEMTYPE. Додаткову інформацію див. В розділі Оновлення полів під час зміни робочого процесу далі в цьому розділі.
Імена, які присвоюються станів і причин, нечутливі до регістру.
Наступний приклад коду показує WORKFLOW для визначення помилок WIT в шаблоні процесу Agile. В даному прикладі визначено три стану і п'ять переходів. Елементи STATE визначають стан «Активний», «Вирішений» і «Закритий». Всі можливі комбінації для прогресії і регресії переходів визначені для трьох станів за винятком одного. Перехід зі стану Закритий в Вирішений не визначений. Тому члени команди не можуть вирішити робочий елемент даного типу, якщо робочий елемент має стан Закритий.
Приклад не перераховує елементи для DEFAULTREASON. REASON. ACTION. і FIELD.
Коли член команди змінює поле стану, цей користувач може залишити причину за замовчуванням для даного переходу або вказати іншу причину, якщо ви визначите інші варіанти. Необхідно використовувати елемент DEFAULTREASON для визначення однієї і тільки однієї причини за замовчуванням. Необхідно вказувати додаткові причини, тільки якщо вони допомагають команді відстежувати дані або організовувати їх в звіти.
Наприклад, розробник може вказати одну з наступних причин при вирішенні помилки: «Виправлено» (за замовчуванням), «Відкладено», «дублює», «Не помилка», «Не вдається відтворити» або «Застаріла». Кожна причина вказує на певну дію для тестувальника щодо помилки.
Всі причини з'являються в алфавітному порядку в списку в робочій формі для робочого елемента певного типу, незалежно від послідовності, в якій визначаються елементи REASON.
У наступному прикладі показані елементи, які визначають причини, чому член команди може виправити помилку.
Можна визначити правила, які оновлять поля, коли б не трапилися такі події:
Призначте правило поля для STATE. якщо необхідно, щоб правило застосовувалося для всіх переходів в даний стан і причин для входу в даний стан.
Призначте правило поля для TRANSITION. якщо необхідно, щоб правило застосовувалося для цього переходу і для всіх причин для здійснення переходу.
Призначте правило поля для DEFAULTREASON або REASON. якщо необхідно, щоб правила застосовувалися тільки для цієї конкретної причини.
Можна спробувати мінімізувати кількість умов, які визначаються для будь-якого типу робочого елемента. З кожним додаються правилом умови збільшується складність процесу перевірки, яка здійснюється кожен раз, коли член команди зберігає робочий елемент. Набори складних правил можуть збільшити час, необхідний для збереження робочого елемента.
Коли значення поля Стан для робочого елемента встановлено в режим Активний і робочий елемент збережений, полях Активоване (ким) і Призначено (кому) автоматично присвоюється ім'я поточного користувача Цей користувач повинен бути членом групи Дійсних користувачів Team Foundation Server. Значення поля Дата активації також встановлюється автоматично. У наступному прикладі показані елементи, які здійснюють це правило.