Pendahuluan
Apa itu DoR
Mengapa Anda membutuhkan DoR?
Tempat menggunakan DoR
Kapan harus menggunakan DoR
INVEST model
Kesimpulan
Referensi
Pendahuluan
Tentunya Anda telah mendengar lebih dari sekali, Anda mungkin bahkan menggunakan artefak Scrum - Definisi Selesai dengan tim, selanjutnya - DoD. Mungkin menggunakannya tanpa menyadarinya. Banyak artikel berbahasa Rusia telah ditulis tentang DoD. Mereka berbicara tentang dia di konferensi dan pelatihan. Memahami mengapa artefak ini diperlukan dan menemukan contoh tidak sulit. DoD mendefinisikan kriteria dimana setiap anggota tim memahami bahwa tugas ditutup. Tujuan terdalam adalah untuk menyinkronkan konsep Selesai antara masing-masing anggota tim. Di atas kriteria ini, seringkali, tim bekerja selama retrospektif. Ada artefak serupa tentang yang karena alasan tertentu tidak ada menyebutkan Scrum dalam sumber daya berbahasa Rusia, dan di mana artefak ini disebutkan, tidak ada penjelasan diberikan apa itu, mengapa itu diperlukan, dan bagaimana menggunakannya.
Kemungkinan besar, frasa seperti milik Anda terdengar di tim Anda: "Kami gagal tujuan karena kami salah mengevaluasi tugas", atau "PO kami kembali dengan tugas tanpa deskripsi yang tepat". Di tim saya, "sinyal" seperti itu muncul lebih dari sekali, dan untuk waktu yang lama saya mencari cara untuk menyelesaikan masalah ini.
Definisi Ready, yang selanjutnya disebut DoR, saya secara kebetulan menemukan dalam obrolan profil yang didedikasikan untuk Agile. Mencoba mencari informasi, saya tidak menemukan satu pun penyebutan dalam RuNet tentang topik ini. Karena itu, saya pergi membaca dan menerjemahkan artikel berbahasa Inggris. Sekarang saya membagikan hasilnya dengan Anda, saya harap ini membantu membuat tim Anda lebih keren dan lebih produktif.
Apa itu DoR
Jadi, apa itu DoR? Penerjemah Google akan memberi tahu Anda bahwa ini adalah "definisi kesiapan." Jika DoD termasuk kriteria untuk menyelesaikan tugas, maka DoR - kriteria untuk kesiapan tugas yang akan diambil untuk bekerja. Artinya, jika suatu tugas memenuhi kriteria dari DoR, tim dapat membawanya ke perencanaan kerja. Tampaknya sederhana, Anda mungkin sudah mulai memikirkan bagaimana, akhirnya, bersama-sama dengan tim, membuat seluruh daftar persyaratan untuk PO Anda sehingga mulai menulis satu ton dokumentasi, dan anggota tim lainnya dapat dengan tenang duduk di depan komputer mereka dan menulis kode tanpa suara. Ini hanya permulaan, dan DoR tidak seperti yang terlihat pada pandangan pertama.
Mengapa Anda membutuhkan DoR?
Pertama, kami menjawab pertanyaan: mengapa artefak ini diperlukan? Apa manfaat yang akan dia bawa ke tim? DoR akan membantu tim:
- Hindari mulai bekerja pada fitur yang tidak memiliki definisi kriteria penyelesaian yang jelas. Tim akan memahami kapan Kisah Pengguna dianggap lengkap, dan apa yang perlu dilakukan untuk melakukan ini.
- Jangan buang banyak waktu dengan sia-sia untuk diskusi panjang, tugas-tugas yang dipikirkan dengan buruk. Tugas yang sudah diproses sebelumnya akan menghemat waktu seluruh tim. Hitung berapa banyak waktu yang diperlukan untuk membahas tugas "buruk", untuk satu orang. Sekarang kalikan dengan jumlah orang dalam tim. Dan sekarang untuk jumlah tugas seperti itu.
- Fokuskan waktu dan energi pada hal-hal yang seaman mungkin. Salah satu demotivator paling kuat adalah fungsi yang dilemparkan ke tempat sampah.
- Libatkan setiap peserta dalam diskusi tugas. Pertama, ini memotivasi tim. Kedua, membantu mengungkapkan setiap anggota tim sebagai spesialis. Ketiga, pengembang akan menawarkan visi mereka sendiri tentang masalah tersebut. Selama diskusi, solusi lain mungkin muncul yang akan sangat berbeda dari ide asli.
Mari kita lihat daftar masalah yang secara tidak langsung atau langsung diakibatkan oleh kurangnya DoR:
- Perbedaan dalam memahami masalah muncul secara teratur di antara anggota tim. Pada akhir sprint, ketidaksesuaian meningkat, yang mengarah pada insiden ketika perubahan terjadi dalam proses pembangunan, yang alami. Tetapi mengingat fakta bahwa momen-momen ini tidak direkam, hanya orang yang secara langsung mengalami hal ini yang tahu tentang mereka.
- Persyaratan fungsional berubah lebih cepat daripada yang dikelola tim untuk memahaminya. Karena tugas memasuki sprint, dengan ketidakpastian tinggi, pada saat bagian sudah siap dan "fondasi" diletakkan, informasi baru muncul yang akan memerlukan pengembalian ke awal. Semakin buruk tugas diselesaikan, semakin sering situasi seperti itu muncul dalam sprint. Pada akhirnya, ini akan mengarah ke fakap.
- Seringkali ada masalah dengan mengevaluasi hasil yang diperoleh dari fungsional, tim tidak tahu bagaimana mengumpulkan metrik, atau bahkan lebih buruk, melupakannya. Scrum terutama tentang manfaat bagi pelanggan, pengguna atau pembeli. Jika tim tidak mengevaluasi manfaat dari tugas tersebut, tim tidak menerima umpan balik dan kemampuan untuk menyesuaikan arah pengembangan produk. Ini dapat menyebabkan kegagalan total.
- Juga, kurangnya DoR memiliki dampak besar pada pengujian, dan alih-alih ekspektasi pengujian QA pada Story Pengguna, itu akan menguji ekspektasi pengembang. Kode dapat bekerja dengan sempurna, uji otomatis akan bekerja seperti jarum jam, tetapi fungsi tidak akan berfungsi pada Produksi.
Pada akhirnya, ini mengarah pada pelepasan produk yang tidak berfungsi, tidak berguna, tidak menyelesaikan masalah utama. Dan ini adalah buang-buang waktu yang semua orang ingin habiskan untuk hal-hal penting. Di salah satu artikel, saya menemukan pepatah yang bagus: "Sampah masuk, sampah keluar."
Tempat menggunakan DoR
DoR digunakan pada Perbaikan Backlog Produk yang selanjutnya disebut PBR atau nama artefak yang lebih akrab: Perawatan. Selama kegiatan ini, Cerita Pengguna menjadi Siap - Siap. Ini berarti bahwa hasil acara, dalam jaminan produk, adalah Ready US. DoR diperlukan untuk menggambarkan keadaan di mana AS dapat dibahas tentang perencanaan. Ini disebut Takin diterima oleh AS.
Untuk melangkah lebih jauh, saya memperhatikan bagaimana Jeff Sutherland, salah satu pendiri manifestasi Scrum dan Agile, berbicara tentang DoR dan DoD dalam videonya. Sutherland memperkenalkan konsep Selesai-Selesai, dan Siap-Siap. Ketika seorang anggota tim mengatakan bahwa suatu tugas sudah siap atau selesai, dipahami bahwa tugas tersebut memenuhi kriteria yang ditentukan oleh tim masing-masing dalam DoD dan DoR. Ini adalah aspek penting, setiap anggota tim harus memahaminya, dan jangan lupa. Kalau tidak, situasi lucu muncul ketika Petya akan memberi tahu Harian bahwa tugasnya telah selesai, dan kemudian ternyata tes perlu ditambahkan di sana, dan akan menyenangkan untuk memperbaiki kode, dan Peninjauan Kode belum berlalu.
Dengan demikian, sampai AS mencapai status Siap-Siap, itu tidak ada, dan tidak dibahas dalam perencanaan. Bagian atas tumpukan harus hanya AS, dengan status Siap-Siap. Cara terbaik untuk mencapai ini adalah bekerja di AS bersama tim. Ini akan memungkinkan kita untuk melihat masalah dari sudut yang berbeda, melibatkan setiap anggota tim dalam proses, dan kemudian mengembangkan tanggung jawab kolektif untuk fungsionalitas yang dirilis. Pengembang akan bertanggung jawab atas hasil dan kualitas diri mereka sendiri jika mereka menyadari bahwa ini adalah buah dari kerja sama "mereka".
Kapan harus menggunakan DoR
Ketika tim memahami selama PBR bahwa tugas tersebut tidak sesuai dengan DoR, dan membawa terlalu banyak ketidakpastian, buat daftar pertanyaan, pilih peneliti, dan tunda tugas sampai PBR berikutnya. Di tim saya, itu disebut Research, tetapi kemudian kami beralih ke Spike dari XP, karena kami pikir itu membawa lebih banyak hasil dan kejelasan tentang hasil penelitian. Pastikan untuk membatasi studi berdasarkan waktu, dan tentukan hasil yang ingin Anda dapatkan pada akhir. Selama Spike, peneliti dapat menarik bantuan dari luar, misalnya, anggota tim lain, ahli metodologi, PO, arsitek ... secara umum, siapa pun yang merasa cocok. Hasil - jawaban atas pertanyaan, data baru, prototipe. Jika ada banyak Cerita Pengguna seperti itu, Anda dapat mengambil 1-2 Spike di setiap sprint untuk iterasi berikutnya, sehingga memastikan alur tugas Ready yang konstan.
Seperti disebutkan di atas, DoR adalah seperangkat kriteria. Tim dapat mencoba membuat kriteria ini sendiri. Bekerja melalui "sinyal" yang dilacak dalam iterasi. Diskusikan dalam retrospeksi poin-poin ini, temukan akar masalahnya. Jika Anda tidak ingin menghabiskan retrospektif berikutnya untuk hal ini, gunakan solusi yang sudah jadi.
Banyak artikel menggambarkan model INVEST, yang mirip dengan SMART, tetapi lebih cocok untuk Cerita Pengguna. Selain artikel, model ini juga direkomendasikan dalam literatur Agile. Misalnya, Roman Pichler dalam buku "Manajemen Produk dalam Scrum" atau Mike Cohn - "Kisah Pengguna. Pengembangan perangkat lunak yang fleksibel. "
INVEST model
- Independensi independen - Cobalah untuk menghindari menciptakan AS yang bergantung satu sama lain .Ketergantungan tersebut menyebabkan masalah dalam memprioritaskan dan merencanakan. Pelanggan dapat memilih AS dengan prioritas tinggi, yang tergantung pada tugas dengan prioritas lebih rendah. US Dependent harus digabung, dipisah secara berbeda atau spike.
- Negosiasi yang dapat dinegosiasikan - AS bukan kewajiban atau persyaratan kontrak formal. AS bukan tugas teknis. Selama sprint, mereka dapat dan harus dibahas dan diubah. Kartu dengan riwayat, dalam bentuk apa pun itu ada, adalah deskripsi singkat tentang fungsi, yang detailnya harus diklarifikasi selama pekerjaan. Tinggalkan catatan pada kartu untuk menghasilkan diskusi ketika tugas akan selesai. Penting untuk menemukan jalan tengah di sini, karena kelebihan catatan, tim akan menganggapnya sebagai informasi yang lengkap, dan tidak akan ada diskusi sama sekali. Tim saya menemukan ini dengan sangat cepat. Rincian yang dibahas menjadi tes yang dapat ditulis di bagian belakang kertas, atau dalam komentar pada kartu elektronik. Tes penerimaan sederhana dan jelas untuk semua orang.
- Nilai yang berharga bagi pengguna atau pelanggan - “Setiap cerita harus memiliki nilai tertentu bagi pengguna” - pernyataan yang tidak benar. Paling sering melupakan pembeli. Fokus, tergantung pada perusahaan Anda: B2C, B2B, B2G. Hal utama adalah menghindari cerita yang hanya berharga bagi pengembang. Cerita-cerita seperti itu harus dirumuskan ulang sehingga manfaatnya menjadi jelas dan pelanggan dapat menetapkan prioritas. Tidak perlu membuang tugas arsitektur di tempat sampah, jelaskan kepada pelanggan apa manfaat yang akan diberikan oleh tugas seperti itu, dan ulangi lagi.
- Penilaian yang diperkirakan - pengembang harus dapat memperkirakan ukuran AS, yaitu, perkiraan waktu yang diperlukan untuk mengimplementasikan. Ada tiga alasan utama mengapa intensitas kerja mungkin tidak dapat diukur:
- Tim tidak memiliki pengetahuan subjek
- Tim tidak memiliki pengalaman teknis
- Ceritanya terlalu besar
Dalam kasus pertama dan kedua, spike akan membantu Anda. Yang ketiga, AS perlu diurai menjadi yang lebih kecil. - Kekompakan kecil - banyak tergantung pada ukuran AS, terlalu besar dan terlalu kecil AS sulit untuk dievaluasi. Epik sulit untuk dikerjakan, karena terdiri dari beberapa orang AS. Epik dapat dibagi menjadi dua jenis:
- Senyawa. Semuanya sederhana di sini - kami membusuk. Pertimbangkan sisa poin, hal pertama yang kemungkinan tim akan sarankan: membagi AS dengan jenis lapisan arsitektur: oleh AS ke dalam database, backend, frontend, dan sebagainya.
- Rumit. Ukuran besar AS adalah karena esensi mereka, mereka tidak terdekomposisi, atau sangat sulit. Dalam hal ini, kami menggunakan spike.
- Testabilitas yang dapat diuji - konfirmasi bahwa AS telah berhasil dikembangkan, berfungsi sebagai tes yang berhasil. Jika AS tidak dapat diuji, tim tidak akan tahu kapan pembuatannya selesai, atau akan muncul dengan kriteria sendiri. Apalagi masing-masing anggota tim mereka akan berbeda.
Kesimpulan
Kesimpulannya: menggunakan DoR, Anda tidak akan menyingkirkan celah yang akan meresap ke dalam sprint. Ini juga tidak berarti bahwa selama sprint tidak diperlukan kontak konstan antara PO dan pengembang. Catat hasil diskusi secara konstan dalam bentuk tes penerimaan, sehingga tidak ada tim yang akan kehilangan pemahaman tentang status tugas. Menganalisis dan berdiskusi dengan tim tentang masalah saat ini, mungkin mereka terkait dengan kurangnya DoR.
DoR adalah artefak yang akan memungkinkan tim untuk memikirkan AS dengan lebih baik, yang pada akhirnya akan mengurangi risiko, dan akan memungkinkan setiap anggota tim untuk terus-menerus mendiskusikan tugas. Anda akan menemukan banyak informasi terperinci tentang INVEST, dan Kisah Pengguna di buku "Kisah Pengguna". Saya sarankan agar setiap anggota tim membaca buku ini, atau setidaknya membacanya sendiri dan berbagi informasi dengan mereka.
Tulis di komentar yang DoD dan DoR digunakan dalam tim Anda.
Referensi
1) Roman Pichler “Manajemen Produk dalam Scrum”
2) Mike Cohn “Cerita Kustom. Pengembangan perangkat lunak yang fleksibel ”
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com