Ubah hasil yang diinginkan menjadi inisiatif

Jelaskan hasil sebelum langkah

Layanan peralatan fiktif memerlukan layanan mandiri karyawan. Permintaan yang berguna menyatakan hasil: “Karyawan terautentikasi dapat membuat permintaan dan hanya melihat permintaannya sendiri.”

Jelaskan alasannya: saat ini manajer memasukkan permintaan untuk karyawan. Tentukan cakupan: pembuatan permintaan, tampilan status, pemeriksaan akses, dan bukti untuk perilaku tersebut. Kecualikan pembelian otomatis dan perubahan aturan persetujuan manajer.

Jangan menentukan pengeditan file sebelum repositori diperiksa. Inisiatif merekam maksud; perencanaan terperinci mengubah maksud itu menjadi langkah implementasi.

Tinjau hasil permintaan

Taiga menggunakan permintaan dan konteks produk untuk membuat inisiatif atau kumpulan inisiatif berurutan. Pekerjaan baru masuk ke Backlog. Permintaan yang lebih besar mungkin memerlukan beberapa perubahan yang dapat ditinjau secara independen.

Baca kondisi akhir, Why, dan Scope yang dihasilkan. Periksa bahwa perilaku wajib dipertahankan dan pengecualian dipatuhi. Jika inisiatif yang sudah ada mencakup permintaan, Taiga dapat menunjukkannya alih-alih membuat duplikat.

Permintaan yang diblokir kebijakan terpublikasi memerlukan jalur keputusan yang ditentukan kebijakan tersebut. Baca penjelasan dan selesaikan pertentangan melalui jalur itu. Jangan menulis ulang permintaan hanya untuk menyembunyikan tindakan yang dilarang.

Perlakukan papan sebagai urutan eksekusi

Taiga mengerjakan satu inisiatif pada satu waktu per produk, termasuk perencanaan. Taiga memulai inisiatif berikutnya dalam antrean setelah pull request saat ini di-merge. Taiga tidak otomatis memindahkan item dari Backlog atau Todo ke Queue.

Penempatan dalam antrean penting. Penempatan ini mengesampingkan penantian dependensi yang belum selesai. Sebelum mengantrekan layanan mandiri karyawan, konfirmasikan bahwa fondasi identitas sudah ada atau cakupan yang dipilih membangunnya dengan benar.

Periksa rencana terperinci

Perencana membaca repositori, dokumen produk, kebijakan, instruksi, dan konteks deployment. Periksa rencana terhadap hasil pengguna dan lingkungan yang sebenarnya.

Untuk layanan peralatan, verifikasi tiga kasus akses. Karyawan melihat permintaannya. Karyawan lain tidak dapat melihatnya. Manajer tetap memiliki akses peninjauan yang dimaksud. Sertakan migrasi data dan dampak operasi jika implementasi mengubahnya.

Jika Build on its own by default nonaktif, rencana yang selesai menunggu keputusan Anda. Approve memulai build atas nama orang yang menyetujui, sesuai izinnya. Reject menggunakan umpan balik Anda untuk merencanakan ulang. Inisiatif dapat memiliki pengaturan sendiri.

Gunakan catatan yang tepat untuk keputusan berikutnya

Rencana memiliki versi. Eksekusi mencatat rencana yang dijalankannya. Jika pendekatan yang dimaksud berubah, tinjau inisiatif dan tindakan perencanaan ulang yang sesuai. Gunakan catatan eksekusi untuk memeriksa percobaan sebelumnya.

Build, pull request yang sudah di-merge, dan rilis produksi merupakan status berbeda. Jaga bukti penerimaan dan tanggung jawab deployment tetap terlihat saat pekerjaan berlanjut. Lanjutkan ke pengaturan otonomi.