Kriteria Penerimaan

Dalam Agile, kriteria penerimaan mengacu pada serangkaian persyaratan yang telah ditentukan sebelumnya yang harus dipenuhi untuk menilai riwayat pengguna secara lengkap.

Kriteria Penerimaan

Dalam Agile, kriteria penerimaan mengacu pada serangkaian persyaratan yang telah ditentukan sebelumnya yang harus dipenuhi untuk menilai riwayat pengguna secara lengkap.
398  
       

Apa itu Kriteria Penerimaan?

Dalam Agile, kriteria penerimaan mengacu pada serangkaian persyaratan yang telah ditentukan sebelumnya yang harus dipenuhi untuk menilai riwayat pengguna secara lengkap. Kriteria pengguna juga kadang – kadang disebut “definisi selesai” karena menentukan jangkauan dan persyaratan yang harus dijalankan oleh developers untuk mempertimbangkan cerita pengguna selesai.

Sebagai manajer produk atau pemilik produk, Anda mungkin bertanggung jawab untuk menulis kriteria penerimaan untuk cerita dalam backlog produk Anda. Dalam artikel ini, kita akan menentukan kriteria penerimaan, lihat beberapa contoh, dan jelajahi beberapa praktik terbaik untuk menulisnya.

Dalam metologi Agile, kriteria penerimaan mengacu pada serangkaian persyaratan yang telah ditentukan sebelumnya yang harus dipenuhi untuk menilai riwayat pengguna secara lengkap. Mereka adalah bentuk dokumentasi persyaratan Agile. Seperti kebanyakan Agile, ada berbagai definisi kriteria peneriamaan.

  • Kriteria Penerimaan Definisi 1: “Kondisi yang harus dipenuhi oleh software agar dapat diterima sebagai pengguna, pelanggan, atau pemangku kepentingan lainnya.’ (via Microsoft Press)
  • Kriteria Penerimaan Definisi 2: “Standar atau persyaratan yang telah ditetapkan sebelumnya yang harus dipenuhi oleh produk atau proyek.” (via Google)

Kriteria pengguna juga kadang – kadang disebut “definisi selesai” karena menentukan jangkauan dan persyaratan riwayat pengguna. Mereka memberikan konteks yang dibutuhkan oleh developers untuk mengeksekusi riwayat pengguna. Tonton video penjelasan singkat di bawah ini.

What is acceptance criteria? | Definition and Best Practices

Apa sajakah Ciri – Ciri Kriteria Penerimaan yang Efektif?

  • Kriteria penerimaan harus diuji. Karena persyaratan ini membantu merumuskan “definisi selesai” untuk teknisi Anda, persyaratan tersebut harus mudah diuji. Dan hasil dari tes ini tidak boleh menyisakan ruang untuk interpretasi. Tes harus menunjukkan hasil langsung Ya / Tidak atau lulus / gagal.
  • Kriteria harus jelas dan ringkas. Anda jangan menulis dokumentasi komprehensif di sini. Pertahankan kriteria Anda sesederhana dan semudah mungkin.
  • Setiap orang harus memahami kriteria penerimaan Anda. Kriteria Anda tidak berguna jika developers Anda tidak dapat memahaminya. Jika Anda tidak yakin apakah ada sesuatu yang jelas, luangkan waktu untuk bertanya dan buat penyesuaian sampai semuanya jelas.
  • Kriteria Penerimaan harus memberikan perspektif pengguna. Kriteria penerimaan adalah cara untuk melihat masalah yang dihadapu dari sudut pandang pelanggan. Ini harus ditulis dalam konteks pengalaman pengguna yang sebenarnya.

Mengapa Anda Membutuhkan Kriteria penerimaan Riwayat Pengguna?

Kriteria penerimaan memiliki beberapa tujuan untuk tim lintas fungsi.

Mari selami lebih dalam lagi tentang manfaat kriteria penerimaan.

Riwayat pengguna sendiri menyisakan banyak ruang untuk interpretasi. Kriteria penerimaan menjelaskan hasil yang diharapkan dari riwayat pengguna secara konkret. Ini juga memberikan cara yang jelas kepada developers dan QA untuk menentukan apakah sebuah cerita sudah “selesai”.

 

Definisi Penyelesaian : Apa yang Perlu Diketahui Manajer Produk

 

Anda ingin memasukkan persyaratan ini ke dalam proses Anda karena berbagai alasan. Pertama, ketika Anda menentukan hasil yang Anda inginkan sebelum pengembangan dimulai, Anda membantu mempromosikan keselarasan dan pemahaman bersama. Pemahaman ini membantu mengurangi kemungkinan kejutan di masa mendatang.

Selain membantu orang – orang produk menetapkan dan mengelola ekspektasi, kriteria penerimaan juga berguna bagi developers. Konteks tambahan tidak hanya mengurangi ambiguitas, tetapi juga menciptakan pertahan yang bagus terhadap creep scope. Jika persyaratan tidak ditentukan dan ditetapkan di awal sprint, akan lebih sulit untuk menyelinap di tengah jalan. Terakhir, kriteria penerimaan sering kali mendefinisikan pengujian gagal / lulus tes yang dilakukan untuk menentukan riwayat pengguna secara lengkap.

Siapa yang Bertanggung Jawab untuk Menulis Kriteria Penerimaan?

Hampir semua orang di tim lintas fungsi dapat menulis kriteria penerimaan untuk riwayat pengguna. Biasanya pemilik atau manajer produklah yang bertanggung jawab untuk menulis kriteria penerimaan, atau setidaknya memfasilitasi diskusi tersebut. Ide dibaliknya adalah untuk memastikan bahwa persyaratan ditulis dengan mempertimbangkan kebutuhan pelanggan, dan siapa yang lebih memahami kebutuhan pelanggan daripada orang produk? Karena itu, sangat disarankan untuk membuat kriteria penerimaan penulisan sebagai aktivitas kelompok yang mencakup perwakilan developers dan QA.

Melibatkan developers dan QA saat Anda menentukan kriteria penerimaan, memiliki beberapa keuntungan. Pertama, memberi Anda kesempatan lain untuk berkomunikasi dengan developers tentang strategi dan visi produk. Kedua, developers dan staf QA dapat membantu menunjukkan bagian yang hilang atau mengindentifikasi dependensi yang mungkin sebelumnya belum jelas. Terkahir, diskusi ini dapat membantu Anda sebagai pemilik produk untuk lebih memahami seperti apa riwayat pengguna Anda dari sudut pandang developers. Jadi apabila memungkinkan, pendefinisian dilakukan bersama.

Kapan Kriteria Penerimaan Riwayat Pengguna Harus Ditulis?

Banyak manajer produk dan pemilik produk memilih menulis kriteria penerimaan selama sesi perawatan backlog. Mereka kemudian membawa kriteria ini ke rapat perencanaan sprint untuk didiskusikan dengan developers dan menyempurnakannya berdasarkan feedback mereka.tetapi tidak ada aturan khusus kapan harus menuliskan persyaratan ini.

Paling lambat, kriteria penerimaan harus ditetapkan sebelum pengembangan dimulai. Jika tidak, Anda akan kehilangan banyak keuntungan memilikinya sejak awal. Perlu juga dicatat bahwa menulis kriteria penerimaan terlalu cepat juga bisa menjadi bumerang. Ingat, metologi Agile mendorong reprioritization berdasarkan temuan baru. Dan itu berarti Anda dapat memprioritaskan ulang riwayat pengguna dari sprint ke sprint.

Salah satu cara untuk menyeimbangkan ketidakpastian ini adalah dengan hanya menuliskan persyaratan penerimaan saat Anda memutuskan untuk memindahkan sesuatu ke dalam sprint backlog. Dengan cara ini Anda tidak menghabiskan waktu menulis spesifikasi untuk riwayat pengguna yang pada akhirnya akan diturunkan prioritasnya. Setelah Anda memindahkan riwayat pengguna ke dalam sprint backlog, bisa dipastikan bahwa riwayat itu berikutnya. Jadi, Anda dapat melanjutkan dan secara bebas menentukan persyaratan penerimaan dan kemudian mendiskusikan serta menyelesaikannya selama rapat perencanaan sprint.

Bagaimana Seharusnya Anda Memformat Kriteria Penerimaan Riwayat Pengguna?

Tidak ada cara yang benar atau salah untuk menulis kriteria penerimaan untuk riwayat pengguna. Pada akhirnya, Anda perlu menetapkan format dan prosedur untuk membuat kriteria penerimaan yang bekerja secara konsisten untuk tim Anda. Diharapkan melakukan sedikit uji coba, jika Anda baru dalam hal ini. Sebagian organisasi Agile, menggunakan salah satu dari dua format untuk kriteria penerimaan mereka:

  1. Diberikan / Kapan / Kemudian Kriteria Penerimaan

Gaya persyaratan riwayat pengguna Diberikan / Kapan / Kemudian serupa dengan pemformatan tradisional untuk riwayat pengguna itu sendiri. Cerita pengguna standar mengikuti template: “Sebagai (pengguna yang dituju), saya ingin (tindakan yang diinginkan), sehingga (sasaran / hasil tindakan). “Kriteria penerimaan pengguna dalam format tertentu/ ketika / kemudian mengikuti template: “ Skenario: (jelaskan skenario). Diberikan (bagaimana segala sesuatunya dimulai), kapan (tindakan diambil), lalu (hasil dari mengambil tindakan).”

Kelihatannya agak membingungkan sampai Anda melihat contoh realistis dari riwayat pengguna yang dipasangkan dengan kriteria penerimaan yang diberikan / saat itu. Inilah contohnya.

Contoh Kriteria Penerimaan – Diberikan / Kapan / Kemudian

Kisah Pengguna :

Sebagai manajer produk.

Saya ingin mencetak ide – ide potensial.

Sehingga saya dapat memutuskan apa yang akan disertakan dalam peta jalan produk saya.

Kriteria penerimaan untuk cerita pengguna tersebut bisa jadi :

Skenario : Manajer produk menambahkan ide potensial dan memberi peringkat ide terbaik berdasarkan manfaat versus biaya.

Mengingat bahwa saya telah menambahkan dua atau lebih gagasan dan memberi skor menggunakan model penilaian Manfaat vs Biaya

Saat saya menekan tombol peringkat

Kemudian ide – ide diurutkan dengan ide – ide dengan skor tertinggi di atas.

  1. Daftar Verifikasi Kriteria Penerimaan

Memformat persyaratan riwayat pengguna Anda sebagai daftar periksa adalah opsi lain yang layak. Ini juga sangat mudah. Anda cukup bekerja sebagai tim untuk menentukan daftar pernyataan lulus / gagal yang harus dipenuhi agar dapat ditandai selesai.

Pada akhirnya, format kriteria penerimaan Anda tidak sepenting kepraktisannya. Jika tim Anda memahaminya dan mampu mengerjakannya, Anda telah berhasil membuat kriteria penerimaan yang efektif. Tidak peduli seperti apa formatnya.

Garis bawah:

Kriteria penerimaan adalah komponen penting dari setiap riwayat pengguna yang dikerjakan oleh tim yang gesit. Ini dengan jelas mendefinisikan jangkauan, hasil yang diinginkan, dan kriteria pengujian untuk bagian fungsionalitas yang sedang dikerjakan oleh tim pengiriman. Proses membuat dan menyetujui kriteria penerimaan itu sendiri juga merupakan peluang komunikasi yan tak ternilai antara developers dan produk.

Tonton webinar tentang mengelola persyaratan kompleks di dunia Agile untuk terus belajar lebih banyak.

Sumber : https://www.productplan.com/glossary/acceptance-criteria/

 

 

 

 

One Response to “Kriteria Penerimaan”

Leave a Reply to Definisi Penyelesaian

Klik di sini untuk membatalkan balasan.

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>