Bagikan melalui

Mengubah alur kerja untuk tipe item kerja

Azure DevOps Server | Azure DevOps Server 2022

Ubah 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 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. Untuk mengubah Status yang ditetapkan ke item kerja tertentu, lihat salah satu artikel berikut ini: Papan, Lacak pekerjaan yang sedang berlangsung, atau Papan tugas, Perbarui status tugas. Anda juga dapat melakukan pembaruan massal untuk Status dari banyak item kerja.

Untuk informasi tentang alur kerja pipeline build, 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 informasi selengkapnya tentang kategori status, lihat Status alur kerja dan kategori status.

Panduan desain alur kerja

Tentukan 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 berjalan saat anggota tim mengubah status item kerja.

Secara umum, kaitkan 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, atur Status 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 tidak memperbaiki bug, penguji 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 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, status muncul 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 tersebut ke kategori status. Untuk informasi selengkapnya, lihat 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, tentukan 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, proses secara otomatis menetapkannya 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, tentukan 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 berlaku saat item kerja berubah status, saat transisi, atau saat pengguna memilih alasan tertentu. Banyak dari aturan ini melengkapi aturan bersyarat yang dapat Anda terapkan saat Anda mendefinisikan bidang di bagian FIELDS di dalam definisi WORKITEMTYPE. Untuk informasi selengkapnya, lihat di bagian Memperbarui bidang selama perubahan alur kerja nanti dalam topik ini.

  • Nama yang Anda tetapkan ke status dan alasan tidak sensitif terhadap 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 keadaan

Tentukan 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, pertimbangkan 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, tentukan tindakan tertentu dan anggota tim yang diizinkan untuk melakukan tindakan tersebut.

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

Keadaan 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 Pimpinan Pengembangan Pemimpin 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.
Ditutup 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 dengan 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.

Keadaan Transisi ke status Alasan default
Diusulkan Aktif (perkembangan) Disetujui untuk pengembangan
Ditutup (progres) Tidak disetujui
Aktif Tinjauan (kemajuan) Kriteria penerimaan terpenuhi
Tinjauan Tertutup (kemajuan) Fitur selesai
Aktif (regresi) Tidak memenuhi persyaratan
Ditutup Diusulkan (regresi) Pertimbangkan kembali untuk persetujuan
Aktif (regresi) Ditutup karena kesalahan

Anda dapat membatasi siapa yang diizinkan untuk melakukan transisi dari satu status ke status lainnya dengan menggunakan atribut "untuk" dan "tidak" dari elemen TRANSITION. 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, mereka dapat menyimpan alasan default untuk transisi tersebut atau menentukan alasan yang berbeda jika Anda menentukan opsi tambahan. DEFAULTREASON Gunakan elemen untuk menentukan satu dan hanya satu alasan default. Tambahkan alasan tambahan hanya jika mereka 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 elemen REASON yang Anda tentukan.

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 dalam kontrol versi:

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

ACTION Gunakan elemen untuk secara otomatis mengubah status item kerja dari jenis tertentu ketika peristiwa terjadi di tempat lain dalam Manajemen Siklus Hidup Aplikasi Microsoft Visual Studio atau di luar Visual Studio Application Lifecycle Management (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 lapangan di bawah STATE ketika Anda ingin aturan berlaku untuk semua transisi ke dan alasan memasuki 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, tentukan aturan di bawah elemen yang menentukan bidang tersebut FIELD . Untuk informasi selengkapnya tentang penggunaan aturan, lihat Aturan dan evaluasi aturan.

    Minimalkan jumlah kondisi yang Anda tentukan untuk satu jenis item kerja. Setiap aturan bersyariah menambah kompleksitas pada 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 Anda mengatur nilai bidang Status untuk item kerja ke Aktif dan menyimpan item kerja, 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 Anda mengatur nilai bidang Status untuk item kerja ke Aktif dan menyimpan item kerja, EMPTY elemen secara otomatis mengatur bidang Tanggal Ditutup dan Ditutup Oleh menjadi null dan membuatnya hanya baca, 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 Anda mengubah nilai bidang Status untuk item kerja menjadi Diselesaikan dan menyimpan item kerja, 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>

Konten terkait

Dukungan alat

Untuk membantu pengguna Anda memvisualisasikan alur kerja, instal ekstensi Visualisasi Model Status dari Visual Studio Marketplace.

  • Last updated on