Mengubah alur kerja untuk tipe item kerja

  • Artikel

Azure DevOps Server 2022 - Azure DevOps Server 2019

Anda dapat mengubah alur kerja untuk jenis item kerja (WIT) untuk mendukung proses bisnis dan tim Anda. WIT mendukung pelacakan semua jenis pekerjaan—persyaratan, tugas, cacat kode—untuk mendukung pengembangan perangkat lunak.

Alur kerja menentukan perkembangan logis dan regresi pekerjaan yang akan dilakukan anggota tim. Ini juga menentukan nilai yang muncul di menu drop-down untuk bidang Status dan Alasan. Untuk informasi selengkapnya, lihat Tentang proses dan templat proses.

Alur kerja untuk Item Backlog Produk (templat proses Scrum)

Alur kerja item backlog produk, proses Scrum

Catatan

Artikel ini menjelaskan cara mengkustomisasi status alur kerja. Jika sebaliknya, Anda ingin mengubah Status yang ditetapkan ke item kerja tertentu, lihat salah satu artikel berikut ini: Papan kanban, Lacak pekerjaan yang sedang berlangsung, atau Papan tugas, Perbarui status tugas. Anda juga dapat melakukan pembaruan massal Status untuk banyak item kerja.

Untuk informasi tentang alur kerja build alur, lihat Mulai menggunakan CI/CD.

Memperbarui definisi XML untuk jenis item kerja

Jika Anda baru menggunakan kustomisasi WIT, perhatikan hal berikut:

Untuk mengkustomisasi alur kerja, ikuti dua langkah berikut:

  1. Ubah bagian WORKFLOW definisi WIT seperti yang dijelaskan dalam topik ini.

  2. Ubah konfigurasi proses untuk memetakan status alur kerja baru ke metastate.

    Langkah kedua ini diperlukan saat Anda mengubah alur kerja untuk WIT yang muncul di halaman alat Agile. WIT ini termasuk dalam kategori Persyaratan atau Tugas. Untuk mempelajari selengkapnya tentang kategori status, lihat Status alur kerja dan kategori status.

Panduan desain alur kerja

Anda menentukan alur kerja dengan terlebih dahulu mengidentifikasi status dan transisi yang valid di antara mereka. Bagian WORKFLOW definisi WIT menentukan status, transisi, alasan transisi, dan tindakan opsional yang valid yang akan dilakukan ketika anggota tim mengubah status item kerja.

Secara umum, Anda mengaitkan setiap status dengan peran anggota tim dan tugas yang harus dilakukan seseorang dalam peran tersebut untuk memproses item kerja sebelum mengubah statusnya. Transisi menentukan perkembangan dan regresi yang valid antar status. Alasan mengidentifikasi mengapa anggota tim mengubah item kerja dari satu status ke status lain, dan tindakan mendukung otomatisasi transisi item kerja pada titik dalam alur kerja.

Misalnya, Status diatur ke Baru saat penguji membuka bug baru yang didasarkan pada proses Agile default. Pengembang mengubah Status menjadi Aktif saat memperbaiki bug, dan setelah diperbaiki, pengembang mengubah statusnya menjadi Diselesaikan dan menetapkan nilai bidang Alasan ke Diperbaiki. Setelah memverifikasi perbaikan, penguji mengubah status bug menjadi Tertutup dan bidang Alasan berubah menjadi Diverifikasi. Jika penguji menentukan bahwa pengembang belum memperbaiki bug, penguji akan mengubah status bug menjadi Aktif dan menentukan Alasan sebagai Tidak Diperbaiki atau Pengujian Gagal.

Saat Anda mendesain atau mengubah alur kerja, pertimbangkan panduan berikut:

  • STATE Gunakan elemen untuk menentukan status unik untuk setiap peran anggota tim yang akan mengambil tindakan tertentu pada item kerja. Semakin banyak status yang Anda tentukan, semakin banyak transisi yang harus Anda tentukan. Terlepas dari urutan di mana Anda menentukan status, mereka tercantum dalam urutan alfanumerik di menu drop-down untuk bidang Status .

    Jika Anda menambahkan status ke jenis item kerja yang muncul di halaman backlog atau papan di portal web, Anda juga harus memetakan status ke kategori status. Untuk mempelajari lebih lanjut, tinjau Status alur kerja dan kategori status.

  • TRANSITION Gunakan elemen untuk menentukan transisi untuk setiap perkembangan dan regresi yang valid dari satu status ke status lainnya.

    Minimal, Anda harus menentukan satu transisi untuk setiap status, dan transisi dari status null ke status awal.

    Anda hanya dapat menentukan satu transisi dari yang tidak ditetapkan (null) ke status awal. Saat Anda menyimpan item kerja baru, item tersebut secara otomatis ditetapkan ke status awal.

    Saat anggota tim mengubah status item kerja, perubahan tersebut memicu transisi dan tindakan yang Anda tentukan untuk dilakukan untuk status yang dipilih dan transisi. Pengguna hanya dapat menentukan status yang valid berdasarkan transisi yang Anda tentukan untuk status saat ini. Selain itu, ACTION elemen, yang merupakan elemen turunan dari TRANSITION, dapat mengubah status item kerja.

  • Untuk setiap transisi, Anda menentukan alasan default dengan menggunakan DEFAULTREASON elemen . Anda dapat menentukan alasan opsional sebanyak yang Anda inginkan dengan menggunakan REASON elemen . Nilai-nilai ini muncul di menu drop-down bidang Alasan .

  • Anda dapat menentukan aturan yang akan diterapkan saat item kerja berubah status, saat transisi, atau saat pengguna memilih alasan tertentu. Banyak dari aturan ini melengkapi aturan bersyarah yang dapat Anda terapkan saat Anda menentukan bidang di bagian FIELDS di bawah WORKITEMTYPE definisi. Untuk informasi selengkapnya, lihat Memperbarui bidang selama perubahan alur kerja nanti dalam topik ini.

  • Nama yang Anda tetapkan ke status dan alasan tidak peka huruf besar/kecil.

    Menu drop-down untuk bidang Status dan Alasan dalam formulir item kerja atau editor kueri menampilkan nilai yang ditetapkan di bagian WORKFLOW tipe item kerja.

Diagram alur kerja dan contoh kode

Contoh kode berikut menunjukkan WORKFLOW untuk definisi BUG WIT untuk templat proses Agile. Contoh ini mendefinisikan tiga status dan lima transisi. Elemen STATE menentukan status Aktif, Diselesaikan, dan Ditutup. Semua kemungkinan kombinasi untuk transisi perkembangan dan regresi didefinisikan untuk tiga status, kecuali satu. Transisi dari Tertutup ke Diselesaikan tidak ditentukan. Oleh karena itu, anggota tim tidak dapat menyelesaikan item kerja jenis ini jika item kerja ditutup.

Contoh ini tidak mencantumkan semua elemen untuk DEFAULTREASON, , REASON, ACTIONdan FIELD.

Contoh Diagram Status Alur Kerja — Agile Bug WIT

Status alur kerja bug, templat proses 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>

Menentukan jumlah dan jenis status

Anda menentukan jumlah dan jenis status yang valid berdasarkan jumlah status logis yang berbeda di mana Anda ingin item kerja dari jenis tersebut ada. Selain itu, jika anggota tim yang berbeda melakukan tindakan yang berbeda, maka Anda dapat mempertimbangkan untuk menentukan status berdasarkan peran anggota. Setiap status sesuai dengan tindakan yang harus dilakukan anggota tim pada item kerja untuk memindahkannya ke status berikutnya. Untuk setiap status, Anda harus menentukan tindakan tertentu dan anggota tim yang diizinkan untuk melakukan tindakan tersebut.

Tabel berikut ini menyediakan contoh empat status yang ditentukan untuk melacak kemajuan fitur dan pengguna valid yang harus melakukan tindakan yang ditunjukkan:

Status Pengguna yang valid Tindakan yang harus dilakukan
Diusulkan Manajer Proyek Siapa pun dapat membuat item kerja fitur. Namun, hanya manajer proyek yang dapat menyetujui atau tidak menyetujui item kerja. Jika manajer proyek menyetujui fitur, manajer proyek mengubah status item kerja menjadi Aktif; jika tidak, anggota tim menutupnya.
Aktif Prospek pengembangan Prospek pengembangan mengawasi pengembangan fitur. Setelah fitur selesai, prospek pengembangan mengubah status item kerja fitur menjadi Tinjauan.
Tinjauan Manajer Proyek Manajer proyek meninjau fitur yang diterapkan tim dan mengubah status item kerja menjadi Ditutup jika implementasinya memuaskan.
Tutup Manajer Proyek Tidak ada tindakan tambahan yang diharapkan terjadi pada item kerja yang ditutup. Item ini tetap berada dalam database untuk tujuan pengarsipan dan pelaporan.

Catatan

Semua status muncul dalam urutan alfabet dalam daftar pada formulir untuk item kerja dari jenis tertentu, terlepas dari urutan di mana Anda menentukannya.

Menentukan transisi

Anda mengontrol status ke dan dari mana anggota tim dapat mengubah item kerja jika Anda menentukan perkembangan dan regresi status yang valid. Jika Anda tidak menentukan transisi dari satu status ke status lain, anggota tim tidak dapat mengubah item kerja dari jenis tertentu dari status tertentu ke status tertentu lainnya.

Tabel berikut menentukan transisi yang valid untuk masing-masing dari empat status yang dijelaskan sebelumnya dalam topik ini, bersama dengan alasan default untuk masing-masing status.

Status Transisi ke status Alasan default
Diusulkan Aktif (perkembangan) Disetujui untuk pengembangan
Tertutup (perkembangan) Tidak disetujui
Aktif Tinjauan (perkembangan) Kriteria penerimaan terpenuhi
Tinjauan Tertutup (perkembangan) Fitur selesai
Aktif (regresi) Tidak memenuhi persyaratan
Tutup Diusulkan (regresi) Pertimbangkan kembali untuk persetujuan
Aktif (regresi) Kesalahan ditutup

Anda dapat membatasi siapa yang diizinkan untuk melakukan transisi dari satu status ke status lainnya dengan menggunakan atribut TRANSITION untuk dan bukan elemen. Seperti yang ditunjukkan oleh contoh berikut, penguji dapat membuka kembali bug tetapi pengembang tidak dapat.

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

Tentukan alasannya

Saat anggota tim mengubah bidang Status, pengguna tersebut dapat mempertahankan alasan default untuk transisi tersebut atau menentukan alasan yang berbeda jika Anda menentukan opsi tambahan. Anda harus menggunakan DEFAULTREASON elemen untuk menentukan satu dan hanya satu alasan default. Anda harus menentukan alasan tambahan hanya jika membantu tim melacak atau melaporkan data.

Misalnya, pengembang dapat menentukan salah satu alasan berikut saat menyelesaikan bug: Tetap (Default), Ditangguhkan, Duplikat, Sesuai Desain, Tidak Dapat Mereproduksi, atau Usang. Setiap alasan menentukan tindakan tertentu bagi penguji untuk dilakukan sehubungan dengan bug.

Catatan

Semua alasan muncul dalam urutan alfabet dalam daftar pada formulir kerja untuk item kerja dari jenis tertentu, terlepas dari urutan di mana Anda menentukan REASON elemen.

Contoh berikut menunjukkan elemen yang menentukan alasan mengapa anggota tim mungkin menyelesaikan bug:

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

Tentukan tindakan

Secara umum, anggota tim mengubah status item kerja dengan menentukan nilai yang berbeda untuk bidang Status lalu menyimpan item kerja. Namun, Anda juga dapat menentukan ACTION elemen yang secara otomatis mengubah status item kerja saat transisi tersebut terjadi. Seperti yang ditunjukkan contoh berikut, Anda dapat menentukan bahwa item kerja bug harus diselesaikan secara otomatis jika terkait dengan file yang diperiksa pengembang ke kontrol versi:

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

Anda dapat menggunakan ACTION elemen untuk secara otomatis mengubah status item kerja dari jenis tertentu saat peristiwa terjadi di tempat lain dalam Manajemen Siklus Hidup Aplikasi Microsoft Visual Studio atau di luar Manajemen Siklus Hidup Aplikasi Visual Studio (misalnya, dari alat yang melacak panggilan). Untuk informasi selengkapnya, lihat TINDAKAN.

Memperbarui bidang selama perubahan alur kerja

Anda dapat menentukan aturan yang memperbarui bidang setiap kali peristiwa berikut terjadi:

  • Tetapkan aturan bidang di bawah STATE saat Anda ingin aturan diterapkan untuk semua transisi ke dan alasan untuk memasukkan status tersebut.

  • Tetapkan aturan bidang di bawah TRANSITION saat Anda ingin aturan diterapkan untuk transisi tersebut dan semua alasan untuk melakukan transisi tersebut.

  • Tetapkan aturan bidang di bawah DEFAULTREASON atau REASON saat Anda ingin aturan diterapkan hanya karena alasan tertentu tersebut.

    Jika bidang harus selalu berisi nilai yang sama, Anda menentukan aturan di bawah elemen yang menentukan bidang tersebut FIELD . Untuk mempelajari selengkapnya tentang penggunaan aturan, lihat Aturan dan evaluasi aturan.

    Anda harus mencoba meminimalkan jumlah kondisi yang Anda tentukan untuk salah satu jenis item kerja. Dengan setiap aturan bersyariah yang Anda tambahkan, Anda meningkatkan kompleksitas proses validasi yang terjadi setiap kali anggota tim menyimpan item kerja. Seperangkat aturan kompleks dapat meningkatkan waktu yang diperlukan untuk menyimpan item kerja.

    Contoh berikut menunjukkan beberapa aturan yang diterapkan ke bidang sistem dalam templat proses untuk MSF Agile Software Development.

Mengubah nilai bidang saat status berubah

Saat nilai bidang Status untuk item kerja diatur ke Aktif dan item kerja disimpan, nilai bidang Diaktifkan Oleh dan Ditetapkan Ke secara otomatis diatur ke nama pengguna saat ini. Pengguna tersebut harus menjadi anggota grup Pengguna Valid Server Team Foundation. Nilai bidang Tanggal Diaktifkan juga diatur secara otomatis. Contoh berikut menunjukkan elemen yang memberlakukan aturan ini:

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

Menghapus nilai bidang saat nilai bidang lain berubah

Saat nilai bidang Status untuk item kerja diatur ke Aktif dan item kerja disimpan, bidang Tanggal Tertutup dan Ditutup Menurut secara otomatis diatur ke null dan dibuat baca-saja jika Anda menggunakan EMPTY elemen , seperti yang ditunjukkan contoh berikut.

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

Tentukan bidang berdasarkan konten bidang lain

Saat nilai bidang Status untuk item kerja berubah menjadi Diselesaikan dan item kerja disimpan, nilai bidang Alasan Terselesaikan diatur ke nilai yang ditentukan pengguna di bidang Alasan . Contoh berikut menunjukkan elemen yang memberlakukan aturan ini:

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

Dukungan alat

Anda dapat mendukung pengguna untuk memvisualisasikan alur kerja dengan menginstal ekstensi Visualisasi Model Status dari Visual Studio Marketplace.