Di Scrum, siapa yang memverifikasi "Selesai"?


13

Saya seorang manajer QA / Tes di organisasi saya dan sampai hari ini saya memverifikasi kualitas perangkat lunak (tes tertulis dan dijalankan dan bug diperbaiki). Siapa yang akan memverifikasi ini di Scrum? Bagaimana saya tahu bahwa tim menulis dan melaksanakan semua tes yang benar? Di sisi lain saya takut jika saya terus melakukan verifikasi, tim tidak akan merasa cukup berdaya. Tetapi saya perlu beberapa proses verifikasi bahwa "Selesai" memang "Selesai". Apa yang Anda sarankan?


Jawaban:


21

Satu ide utama dalam Scrum adalah bahwa tim harus menyetujui "definisi selesai". Idealnya, ini adalah seperangkat kriteria objektif yang dapat diverifikasi oleh siapa pun dengan memeriksa daftar periksa.

Tetapi untuk mengurangi kemungkinan sesuatu lolos, masuk akal untuk memiliki aturan bahwa memverifikasi "selesai" paling banyak dilakukan oleh orang lain selain orang yang mengimplementasikan item - atau orang QA yang ditunjuk seperti Anda (tetapi itu berisiko membuat Anda kemacetan).

Jika ragu, diskusikan dengan tim dan Master Scrum dan putuskan bersama.


+1 meskipun pemilik produk biasanya tidak dianggap sebagai bagian dari tim - dia biasanya ditarik keluar dari lingkaran tim - namun memiliki (atau seharusnya) mengatakan dalam definisi selesai. Ini adalah satu-satunya cara pemilik produk dapat (diizinkan) memengaruhi cara kerja tim.
Marjan Venema

1
@MarjanVenema Pemilik Produk sangat dianggap sebagai bagian dari Tim Scrum. Bahkan, tanpa Pemilik Produk, Scrum memiliki sedikit atau tidak ada peluang untuk menjadi sukses.
Derek Davidson PST CST

1
@ Derek: Saya pikir Anda memiliki kesalahpahaman berdasarkan terminologi yang tidak jelas. Ada baik "Tim Scrum" dan "Tim Pengembangan", dengan yang terakhir menjadi bagian dari yang sebelumnya, serta Pemilik Produk dan Master Scrum.
Michael Borgwardt

2
@MichaelBorgwardt Itu sebabnya saya sangat jelas dalam jawaban saya bahwa Pemilik Produk adalah bagian dari Tim Scrum . Saya setuju bahwa Pemilik Produk bukan bagian dari Tim Pengembangan tetapi konteksnya tidak menjelaskannya. Saya berharap untuk menghilangkan kebingungan. Sepertinya saya mungkin secara tidak sengaja membuat beberapa :)
Derek Davidson PST CST

6

Saya pikir ada asumsi implisit dalam pertanyaan itu. Ada perbedaan antara "diterima", ketika Pemilik Produk mendeklarasikan item jaminan atau tugas telah memuaskan Pemilik Produk, dan "selesai" yang berarti semua pekerjaan yang terkait dengan item jaminan selesai.

Namun, ada lebih banyak tugas daripada yang terlihat oleh Pemilik Produk, biasanya seseorang yang semi teknis, termasuk pengujian, dokumentasi, dan tinjauan (otomatis dan manual). Pemilik Produk jarang berada dalam posisi untuk mengetahui aspek teknis, apalagi apakah sudah selesai.

Oleh karena itu, pada akhirnya timlah yang menentukan apa yang berarti "selesai". Organisasi mungkin memiliki standar dan pemangku kepentingan yang berbeda akan memiliki persyaratan sendiri. Master scrum atau manajer yang relevan biasanya bertanggung jawab untuk menyusun dan menegakkan daftar.

Dalam contoh Anda, sebagai manajer QA / Tes, Anda adalah orang yang mengatakan apakah tes selesai. Namun, Anda mungkin bukan orang terbaik untuk mengatakan apakah kode telah ditinjau, persyaratan keamanan terpenuhi, produk diinternasionalisasi, dokumentasi lengkap atau apa pun yang merupakan "selesai".


4

Satu-satunya konsep "selesai" adalah apakah cerita secara keseluruhan selesai atau tidak. Tim seharusnya membuat definisi yang dilakukan yang mengatakan ketika mereka merasa cerita selesai atau tidak. Ini biasanya akan mencakup hal-hal seperti "kode telah ditinjau", "tes malam telah dijalankan", "semua kriteria penerimaan telah dipenuhi", dll. Ketika hal-hal ini telah diselesaikan, tim dapat merasa yakin bahwa mereka telah melakukan segalanya diharapkan dari mereka untuk menyelesaikan sebuah cerita.

Selama sprint, jika Anda mencoba menentukan apakah salah satu item dalam definisi selesai telah selesai, tanyakan saja. Scrum dan lincah adalah tentang komunikasi terbuka. Jika Anda adalah bagian dari tim, tanyakan kepada rekan setim Anda apakah ada yang telah menulis tes, atau menjalankannya, atau menciptakan pekerjaan malam hari, dll. Jika Anda adalah pemangku kepentingan, tanyakan master scrum.

Jika Anda duduk di luar tim tetapi masih harus meninjau tes, minta tim menambahkan "tes harus ditinjau oleh pengguna user3251930" sebagai bagian dari definisi selesai. Jika itu yang diperlukan untuk menyelesaikan sebuah cerita, jujurlah tentang hal itu dan menjadikannya bagian dari proses. Inti dari "definisi selesai" adalah agar tim dapat mengetahui dengan pasti bahwa mereka telah melakukan apa yang diperlukan untuk memberikan perangkat lunak berkualitas. Jika bagian dari itu adalah tinjauan eksternal, biarlah.

Pada akhirnya, itu adalah pemilik produk yang menandatangani pada cerita tertentu, sehingga pada akhirnya ia memiliki keputusan akhir, apakah sebuah cerita secara keseluruhan dilakukan atau tidak.


Saya perlu meninjau tes, kalau tidak saya tidak akan tahu apakah tes yang benar ditulis. Definisi "Selesai" tidak termasuk tes pasti yang harus ditulis.
Eugene

@ user3251930: mengapa Anda perlu memeriksanya? Apakah Anda tidak mempercayai tim Anda? Padahal, jika Anda benar-benar perlu meninjaunya, buatlah bagian dari definisi selesai karena "tes telah ditinjau oleh user3251930".
Bryan Oakley

Jika pelanggan mendapatkan sesuatu yang tidak sepenuhnya diuji, itu akan sangat sangat buruk. Mungkin pada waktunya saya akan bisa mempercayai tim, saya harap begitu.
Eugene

1

Pertanyaan pertama, Anda harus bertanya pada diri sendiri

Apakah Anda Master Scrum ? jika ya.

Dalam proses scrum dikendalikan dan dikelola oleh Master Scrum.

Bagaimana Anda melakukannya:

Pada fase persyaratan Anda dapat menggunakan cerita pengguna untuk masing-masing ada tes yang perlu diverifikasi.

Di setiap Sprint, item pekerjaan ditarik dari jaminan produk dan diarahkan oleh pemilik produk. Setiap item akan memiliki kriteria verifikasi juga.

Sekarang dalam persyaratan Scrum jangan berubah setelah sprint dimulai. Di akhir Sprint Anda dapat menganalisis verifikasi sesuai dengan kriteria untuk setiap item yang dilakukan.

Jika dilakukan hanya dapat ditemukan oleh respons pemilik Produk.

Ingat di Agile Anda "merangkul perubahan" bahkan terlambat ke fase pengembangan


0

Tim memutuskan. Saya menggunakan daftar periksa, untuk apa yang dianggap 'Selesai'. Apa itu 'Selesai' per cerita, per sprint, per rilis.

Seperti yang telah disebutkan orang lain, pada akhirnya keputusan ada pada pemilik produk.


Apakah ini hanya pendapat pribadi Anda atau Anda dapat mendukungnya?
nyamuk

-1

Setuju bahwa ini adalah sesuatu yang perlu ditentukan oleh tim pengembangan / pengujian, tergantung pada praktik Anda sendiri. Beberapa proyek berjalan sangat gesit sehingga mereka mau mengambil risiko melepaskan bug ke aliran alpha mereka; beberapa orang menganggap bug apa pun yang terjadi di luar grup pengembangan merupakan kegagalan proses.

Proyek yang saya kerjakan memerlukan tinjauan sejawat atas perubahan kode, dan mengharuskan siapa pun yang menulis kode memberikan / memperbarui tes regresi atau menjelaskan mengapa itu tidak mungkin dilakukan. (Mereka dan pengulasnya juga harus menyatakan bahwa mereka telah memeriksa praktik buruk yang diketahui. Kita umumnya jauh lebih bahagia jika mereka dapat menunjukkan bahwa mereka menjalankan test suite penuh dan mendapatkan hasil bersih (atau modulo bersih diketahui paling tidak masalah terbuka) Kode kemudian harus bertahan dari unit otomatis yang intensif dan pengujian fungsional pada beberapa platform untuk menunjukkan bahwa itu tidak menyebabkan regresi terhadap hal itu, dan itu akan diperiksa lebih lanjut untuk antipatterns yang umum dengan sistem analisis kode otomatis. lalu kita menerimanya ke aliran pengembangan utama dan menandai item pekerjaan selesai.

Itu jelas tidak menjamin bahwa tidak ada yang menemukan cara baru untuk gagal, tetapi itu mengurangi risiko ke tingkat yang dapat diterima tanpa sangat menghambat kecepatan pembangunan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.