Dalam lingkungan pengembangan agil, kejelasan adalah mata uang kesuksesan. Ketika sebuah tim memulai pekerjaan pada fitur baru, dasarnya terletak pada Cerita Pengguna. Namun, Cerita Pengguna hanyalah penanda untuk sebuah percakapan. Untuk mengubah percakapan tersebut menjadi produk yang berfungsi, dua artefak krusial diperlukan: Kriteria Penerimaan dan Definisi Selesai. Konsep-konsep ini berfungsi sebagai batas yang menjamin kualitas, keselarasan, dan kepastian.
Banyak tim kesulitan membedakan antara dua konsep ini. Terkadang keduanya diperlakukan sebagai hal yang sama, menyebabkan kebingungan saat pengujian atau peluncuran. Pada waktu lain, keduanya diabaikan sama sekali, mengakibatkan perluasan cakupan pekerjaan atau fitur yang belum lengkap masuk ke produksi. Panduan ini mengeksplorasi mekanisme, tujuan, dan implementasi Kriteria Penerimaan serta Definisi Selesai untuk membantu tim Anda memberikan nilai secara konsisten.
Apa itu Cerita Pengguna? 📝
Sebelum menganalisis komponen-komponen sebuah cerita, penting untuk mengingat apa sebenarnya yang dimaksud dengan Cerita Pengguna. Dalam kerangka kerja agil, Cerita Pengguna adalah deskripsi singkat dan sederhana dari sebuah fitur yang diceritakan dari sudut pandang orang yang menginginkan kemampuan baru tersebut. Biasanya mengikuti format:
- Sebagai [jenis pengguna],
- Saya ingin [tujuan tertentu],
- Supaya [manfaat tertentu].
Format ini berfokus pada nilaiyang diberikan kepada pengguna, bukan pada implementasi teknis. Namun, format ini sendiri tidak cukup untuk membimbing pengembangan. Format ini tidak menentukan batas pekerjaan atau standar yang diperlukan untuk menyelesaikannya. Di sinilah Kriteria Penerimaan dan Definisi Selesai masuk sebagai solusi.
Kriteria Penerimaan (KP): Persyaratan untuk Penyelesaian ✅
Kriteria Penerimaan adalah serangkaian kondisi yang harus dipenuhi oleh Cerita Pengguna agar dianggap selesai dari sudut pandang pemilik produk. Mereka menentukan batas-batas cerita dan memberikan pemahaman yang jelas tentang seperti apa tampilan produk akhir yang diharapkan.
Tujuan Kriteria Penerimaan
Kriteria Penerimaan memiliki berbagai fungsi dalam siklus pengembangan:
- Penjelasan: Mereka menghilangkan ambiguitas. Jika seorang pengembang bertanya, ‘Apakah tombol harus berubah menjadi hijau atau biru saat dihover?’, maka KP harus menjawab pertanyaan tersebut.
- Pengujian: Mereka berfungsi sebagai kasus pengujian. Insinyur QA menggunakan kondisi-kondisi ini untuk memvalidasi fitur tersebut.
- Persetujuan: Mereka memastikan bahwa pemilik produk dan tim pengembangan sepakat tentang apa yang dianggap ‘selesai’ untuk cerita tertentu ini.
Ciri-ciri Kriteria Penerimaan yang Baik
Kriteria Penerimaan yang efektif bersifat spesifik, dapat diukur, dan tidak ambigu. Hindari istilah samar seperti ‘ramah pengguna’ atau ‘cepat’ tanpa mendefinisikan metriknya. Sebaliknya, tentukan perilaku yang tepat.
- Atomik: Setiap kriteria harus menangani satu persyaratan saja.
- Dapat diuji: Harus memungkinkan untuk memverifikasi kriteria tersebut dengan hasil lulus atau gagal.
- Independen:Kriteria tidak boleh bergantung pada cerita eksternal untuk divalidasi.
- Relevan:Fokus pada nilai pengguna, bukan struktur kode internal.
Contoh Kriteria Penerimaan
Pertimbangkan sebuah cerita tentang menambahkan fitur “Lupa Kata Sandi”. Berikut ini contoh bagaimana AC bisa terlihat:
- Diberikan pengguna berada di halaman login,
Ketika mereka mengklik tautan “Lupa Kata Sandi”,
Maka mereka akan diarahkan ke halaman pemulihan kata sandi. - Diberikan pengguna memasukkan email yang valid,
Ketika mereka mengirimkan formulir,
Maka pesan konfirmasi akan ditampilkan. - Diberikan pengguna memasukkan email yang tidak valid,
Ketika mereka mengirimkan formulir,
Maka pesan kesalahan menunjukkan format email tidak benar.
Contoh-contoh ini mengikuti struktur Diberikan/Ketika/Makastruktur (sering dikaitkan dengan sintaks Gherkin), yang mempromosikan kejelasan dan selaras dengan kerangka kerja pengujian otomatis.
Definisi Selesai (DoD): Gerbang Kualitas 🚧
Sementara Kriteria Penerimaan bersifat spesifik untuk satu Cerita Pengguna, Definisi Selesai adalah standar global yang diterapkan padasemuapekerjaan dalam satu sprint atau rilis. Ini mewakili daftar periksa persyaratan yang harus dipenuhi agar setiap peningkatan pekerjaan dianggap dapat dikirimkan.
Tujuan Definisi Selesai
DoD berfungsi sebagai gerbang kualitas. Ini memastikan bahwa utang teknis tidak menumpuk dan produk tetap dalam keadaan yang dapat dirilis setiap saat. Jika sebuah cerita memenuhi Kriteria Penerimaan tetapi tidak memenuhi Definisi Selesai, maka tidak dapat ditandai sebagai selesai.
Elemen-elemen umum yang ditemukan dalam Definisi Selesai meliputi:
- Ulasan Kode:Semua kode harus direview oleh setidaknya satu rekan.
- Uji Satuan:Uji otomatis harus lulus dengan cakupan 100% untuk logika baru.
- Dokumentasi: Dokumentasi API atau panduan pengguna diperbarui.
- Kinerja: Fitur memenuhi persyaratan waktu muat minimum.
- Aksesibilitas: Fitur sesuai dengan pedoman WCAG.
- Keamanan:Tidak ada kerentanan yang diketahui diperkenalkan.
Mengapa DoD Penting
Tanpa Definisi Selesai, tim sering terjebak dalam perangkap ‘selesai secara teknis tetapi belum benar-benar siap’. Fitur mungkin berfungsi sesuai yang diharapkan berdasarkan Kriteria Penerimaan, tetapi bisa merusak bagian lain dari sistem, kekurangan dokumentasi yang memadai, atau memperkenalkan risiko keamanan. DoD mencegah hal ini dengan menerapkan dasar kualitas di seluruh backlog.
Kriteria Penerimaan vs. Definisi Selesai: Perbedaan Utama 🆚
Kerancuan sering muncul karena kedua konsep ini berurusan dengan ‘kelengkapan’. Namun, cakupan dan kepemilikan keduanya berbeda secara signifikan. Memahami perbedaan ini mencegah ketidakselarasan antara pengembang, pengujicoba, dan pemilik produk.
| Fitur | Kriteria Penerimaan | Definisi Selesai |
|---|---|---|
| Cakupan | Spesifik untuk satu Cerita Pengguna | Global untuk seluruh tim atau proyek |
| Kepemilikan | Pemilik Produk dan Tim Pengembangan | Seluruh Tim Pengembangan |
| Ketangguhan | Berubah-ubah per cerita berdasarkan persyaratan | Stabil, meskipun dapat diperbarui seiring waktu |
| Tujuan | Menentukan persyaratan fungsional | Menentukan standar kualitas dan non-fungsional |
| Verifikasi | Pengujian fungsional terhadap kebutuhan pengguna | Verifikasi teknis dan proses |
Bayangkan Kriteria Penerimaan sebagai tujuan perjalanan tertentu, sementara Definisi Selesai adalah daftar periksa keselamatan yang diperlukan untuk setiap kendaraan di jalan.
Cara Menulis Kriteria Penerimaan yang Efektif 📝
Menulis Kriteria Penerimaan adalah upaya kolaboratif. Ini sebaiknya tidak dilakukan secara terpisah oleh pemilik produk. Praktik terbaik melibatkan konsep “Tiga Teman”, di mana Pemilik Produk, Seorang Pengembang, dan Seorang Pengujicoba berkolaborasi sejak awal proses penyempurnaan.
Langkah 1: Identifikasi Tujuan Pengguna
Mulailah dengan mengulang nilai proposisi. Masalah apa yang sedang diselesaikan pengguna? Ini memastikan kriteria tetap fokus pada pengalaman pengguna daripada detail teknis.
Langkah 2: Tentukan Skenario Positif dan Negatif
Jangan hanya menulis jalur yang menyenangkan. Pertimbangkan apa yang terjadi ketika sesuatu berjalan salah.
- Jalur Bahagia: Pengguna melakukan tindakan persis seperti yang diharapkan.
- Kasus Tepi: Apa yang terjadi dengan karakter khusus, data yang hilang, atau koneksi lambat?
- Jalur Negatif: Bagaimana sistem menangani input yang tidak valid dengan baik?
Langkah 3: Gunakan Bahasa yang Jelas
Hindari istilah teknis jika memungkinkan. Jika istilah teknis diperlukan, pastikan didefinisikan. Gunakan kata kerja aktif. Misalnya, ‘Sistem harus memvalidasi…’ kurang jelas dibandingkan dengan ‘Pengguna menerima pesan kesalahan…’.
Langkah 4: Prioritaskan
Jika sebuah cerita besar, pecah menjadi bagian-bagian kecil. Kriteria penerimaan harus dapat dicapai dalam satu sprint. Jika kriteria mengimplikasikan pekerjaan yang tidak dapat diselesaikan dalam satu sprint, cerita tersebut perlu dibagi.
Cara Membuat Definisi Selesai yang Kuat 🛠️
Definisi Selesai bukan dokumen statis. Ia berkembang seiring dengan pematangan tim dan perubahan teknologi. Harus terlihat oleh semua orang, seringkali ditampilkan di papan fisik atau digital.
Langkah 1: Konsultasikan dengan Tim
DoD dimiliki oleh tim yang melakukan pekerjaan. Pengembang, pengujicoba, dan desainer harus berkontribusi dalam daftar ini. Jika seorang pengembang menambahkan persyaratan, mereka lebih mungkin mematuhinya.
Langkah 2: Kategorikan Persyaratan
Kelompokkan item DoD ke dalam kategori logis agar daftar periksa tetap terkelola dengan baik.
- Kualitas Kode:Linting lulus, tidak ada peringatan, tinjauan rekanan selesai.
- Pengujian: Tes unit ditulis, tes integrasi lulus, pengujian manual telah diverifikasi.
- Penyebaran: Di-deploy ke lingkungan staging, tes asap lulus.
- Dokumentasi: Readme diperbarui, dokumentasi API disinkronkan.
Langkah 3: Jadikan Penahan Keras
Jika sebuah cerita tidak memenuhi DoD, maka tidak dapat ditutup. Ini membutuhkan disiplin. Sangat menggoda untuk berkata, ‘Kami akan memperbaiki dokumentasi nanti,’ tetapi hal ini menciptakan utang teknis. Cerita tetap berada dalam status ‘Sedang Dikerjakan’ hingga DoD terpenuhi.
Langkah 4: Tinjau dan Sempurnakan
Selama retrospektif, tanyakan kepada tim: ‘Apakah DoD kami menangkap masalah apa pun?’ atau ‘Apakah ada persyaratan yang terus kami lewatkan?’ Perbarui DoD berdasarkan wawasan ini.
Kesalahan Umum yang Harus Dihindari ⚠️
Bahkan tim yang berpengalaman terjatuh saat menerapkan praktik-praktik ini. Kesadaran akan jebakan umum dapat menghemat waktu dan frustrasi yang signifikan.
1. Kriteria Penerimaan yang Samar
Menulis kriteria seperti ‘Sistem harus aman’ tidak berguna. Kriteria tersebut tidak dapat diuji. Sebaliknya, tentukan ‘Sistem harus mengharuskan otentikasi multi-faktor untuk akun admin.’
2. DoD sebagai Kegiatan Menandai Kotak
Jika tim menandai kotak DoD tanpa benar-benar melakukan pekerjaan (misalnya, menghindari tinjauan kode), maka DoD kehilangan maknanya. DoD harus dihargai, bukan sekadar dibaca.
3. Memperumit DoD
DoD dengan 50 poin menjadi terlalu berat. Fokuslah pada penghalang kualitas utama. Jika suatu persyaratan jarang dilanggar, mungkin lebih tepat sebagai pedoman daripada poin DoD yang ketat.
4. Mengabaikan Persyaratan Non-Fungsional
Tim sering fokus berlebihan pada AC (fungsional) dan mengabaikan DoD (non-fungsional). Kinerja, keamanan, dan aksesibilitas merupakan bagian dari DoD, bukan AC. Mengabaikan hal-hal ini menghasilkan fitur yang berfungsi tetapi lambat atau tidak aman.
5. Membuat DoD Tanpa Dukungan Tim
Jika Product Owner menetapkan DoD tanpa masukan dari pengembang, tim mungkin akan menolaknya. DoD harus menjadi kesepakatan bersama.
Mengintegrasikan ke Dalam Alur Kerja 🔄
Kriteria Penerimaan dan Definisi Selesai harus diintegrasikan ke setiap tahap siklus pengembangan, bukan hanya di akhir.
Fase Penyempurnaan
Selama penyempurnaan daftar prioritas, Product Owner menyusun Kriteria Penerimaan. Tim meninjau kriteria tersebut untuk memastikan dapat diuji dan layak dilakukan. Pertanyaan diajukan dan dijawab di sini, bukan selama sprint.
Perencanaan Sprint
Saat berkomitmen terhadap cerita, tim memverifikasi bahwa Kriteria Penerimaan jelas. Jika tidak, cerita belum siap untuk sprint.
Fase Pengembangan
Pengembang menulis kode untuk memenuhi AC. Secara bersamaan, mereka memastikan mematuhi DoD (misalnya, menulis tes, meminta tinjauan).
Fase Pengujian
Insinyur QA memverifikasi AC terhadap fitur yang telah dibangun. Mereka juga memverifikasi DoD (misalnya, memeriksa laporan cakupan kode, pemindaian aksesibilitas).
Tinjauan dan Penutupan
Sebelum cerita dipindahkan ke ‘Selesai’, tim memastikan kedua AC dan DoD terpenuhi. Jika tidak, cerita kembali ke antrian.
Mengukur Kepuasan 📊
Bagaimana Anda tahu apakah Kriteria Penerimaan dan Definisi Selesai Anda berfungsi? Lacak metrik dari waktu ke waktu.
- Tingkat Kerusakan:Apakah bug yang ditemukan di produksi menurun? DoD yang kuat seharusnya dapat menangkap masalah sebelum rilis.
- Tingkat Penolakan:Apakah cerita sering ditolak oleh Product Owner? Ini menunjukkan definisi AC yang buruk.
- Stabilitas Kecepatan:Apakah kecepatan tim tetap konsisten? Jika cerita sering dikembalikan karena item DoD yang hilang, kecepatan akan berfluktuasi.
- Frekuensi Deploi:Apakah DoD yang jelas memungkinkan deploi yang lebih lancar dan sering?
Pertanyaan yang Sering Diajukan ❓
Berikut adalah pertanyaan-pertanyaan umum yang diajukan tim saat menerapkan standar ini.
Q: Dapatkah Kriteria Penerimaan berubah selama sprint?
A: Idealnya, tidak. Jika AC berubah secara signifikan, itu bisa menunjukkan bahwa cerita tidak dipahami dengan baik selama penyempurnaan. Perbaikan kecil diperbolehkan, tetapi perubahan besar pada cakupan harus menghasilkan cerita baru atau penyesuaian terhadap cakupan sprint.
Q: Apakah setiap cerita memerlukan Definisi Selesai yang unik?
A: Tidak. DoD bersifat global. Namun, cerita teknis tertentu mungkin memiliki persyaratan tambahan yang ditambahkan ke daftar periksa untuk item tertentu tersebut, tetapi DoD dasar berlaku untuk semua.
Q: Apa yang terjadi jika tim tidak setuju tentang DoD?
A: Fasilitasi diskusi. Tujuannya adalah mencapai kesepakatan bersama. Jika seorang pengembang bersikeras pada persyaratan yang dibantah oleh tester, bahas risikonya. Jika risikonya rendah, abaikan. Jika tinggi, pertahankan.
Q: Seberapa rinci Kriteria Penerimaan harus dibuat?
A: Cukup rinci untuk dapat diuji. Jika insinyur QA dapat menulis kasus uji langsung dari AC, maka sudah cukup rinci. Jika mereka perlu bertanya, maka perlu lebih banyak detail.
Q: Dapatkah pengujian otomatis menggantikan pengujian manual dalam DoD?
A: Tergantung. Untuk logika kritis, ya. Untuk pengalaman pengguna atau elemen visual, validasi manual mungkin masih diperlukan. DoD harus mencerminkan praktik terbaik dalam jaminan kualitas.
Pikiran Akhir tentang Kualitas dan Keselarasan 🌟
Menerapkan Kriteria Penerimaan dan Definisi Selesai bukan tentang birokrasi; ini tentang rasa hormat. Ini adalah rasa hormat terhadap pengguna yang mengharapkan fitur yang berfungsi, rasa hormat terhadap pengembang yang menginginkan persyaratan yang jelas, dan rasa hormat terhadap product owner yang membutuhkan kepercayaan terhadap pengiriman.
Ketika kedua konsep ini digunakan dengan benar, mereka menciptakan bahasa bersama bagi tim. Mereka mengurangi kebutuhan akan rapat klarifikasi terus-menerus. Mereka mencegah akumulasi utang teknis. Dan yang paling penting, mereka memastikan bahwa setiap cerita yang selesai menambah nilai nyata bagi produk.
Mulai kecil. Tentukan DoD dasar. Tulis AC yang jelas untuk cerita berikutnya. Tinjau mereka dalam retrospektif berikutnya. Seiring waktu, praktik-praktik ini akan menjadi hal yang alami, tertanam dalam budaya tim Anda. Hasilnya adalah aliran terus-menerus perangkat lunak berkualitas tinggi yang memenuhi kebutuhan orang-orang yang menggunakannya.