Bisakah Scrum menggunakan spesifikasi teknis dalam Product Backlog daripada cerita pengguna?

Di perusahaan saya saat ini bekerja untuk kami mulai melakukan proyek Scrum. Tidak terlalu sulit untuk meyakinkan para manajer untuk pindah dari air terjun ke Scrum. Kami sedang melakukan proyek di mana kami membangun kembali platform kami dari awal. Jadi fungsionalitas (sebagian besar) diketahui dan sebagian besar perbaikannya agak teknis.

Dalam hal ini dapat dibenarkan untuk memiliki tugas teknis daripada cerita pengguna. Tunggakan kami memiliki semua jenis tugas teknis seperti:

• Tulis ulang kelas DB dari MySQL ke PostgreSQL.
• Terapkan pencatatan sistem.
• Tulis ulang cache objek.

Hal-hal yang muncul selama stand-up termasuk yang panjang "tugas penelitian" yang diinginkan, tetapi mereka tidak pernah dilakukan. Juga, anggota tim mengklaim di tengah sprint bahwa tugas yang tidak direncanakan perlu ditambahkan.

Bagaimana seharusnya seorang Guru Scrum menangani ini? Mungkinkah itu untuk proyek semacam ini, Scrum BUKAN jalan untuk pergi?

TL; DR

Scrum tidak mengamanatkan penggunaan cerita pengguna; mereka hanya praktik tangkas yang bermanfaat. Meskipun Pemilik Produk tentu dapat menggunakan spesifikasi teknis alih-alih cerita pengguna untuk membangun Product Backlog, sebagian besar masalah proses Anda yang lain berasal dari kegagalan untuk merangkul Scrum dan praktik tangkas yang efektif.

Berbagai Masalah dengan Proses Anda

Scrum Anda tampaknya rusak dengan berbagai cara, termasuk:

1. Spesifikasi Anda tidak memiliki sudut pandang eksplisit atau proposisi nilai.
2. Item tunggakan Anda tidak terikat dengan Sprint Goals.
3. Proses Perawatan Backlog Anda hilang sama sekali atau gagal membuat lonjakan cerita untuk Product Backlog.
4. Proses Perencanaan Sprint Anda tidak cukup membusuk item Product Backlog menjadi item Sprint Backlog.
5. Tim Anda tidak dengan benar memasukkan ketidakpastian tentang item jaminan simpanan dalam perkiraan Perencanaan Sprint-nya.
6. Tim Anda tidak menghormati dasar-dasar tinju waktu atau integritas Sprint.

Walaupun Scrum tidak selalu sesuai untuk setiap proyek, dalam hal ini akan lebih akurat untuk mengatakan bahwa Scrum tidak berfungsi karena tim tidak benar-benar melakukan Scrum. Pertanyaan Anda tentang cerita pengguna hanya sebagian kecil dari masalah proses yang lebih besar yang dihadapi tim Anda.

Mengapa Programmer Agile Merangkul Cerita Pengguna

Spesifikasi teknis adalah cara yang rusak secara mendasar untuk mengkomunikasikan persyaratan. Persyaratan yang tidak ditambatkan dari sudut pandang tidak memberikan panduan yang berguna bagi pengembang. Menggunakan contoh yang Anda kirim:

• Tulis ulang cache objek. Mengapa? Apa tujuannya? Siapa yang menerima manfaat? Siapa yang dapat memberikan klarifikasi tentang tugas tersebut? Jika ini terkait dengan persyaratan non-fungsional, tujuan proyek apa yang dituju oleh alamat ini?
• Terapkan pencatatan sistem. Mengapa? Siapa yang akan membaca log? Informasi apa yang perlu dimasukkan oleh log? Bagaimana Anda tahu jika format log atau data log berguna?

Dari sudut pandang pengembang, tidak mampu menjawab pertanyaan-pertanyaan semacam ini mengarah pada jenis masalah proses yang Anda jelaskan. Itulah yang dilakukan oleh cerita pengguna: mereka memberikan konteks yang sangat dibutuhkan dan bertindak sebagai penampung untuk percakapan tambahan dengan pemangku kepentingan atau pengguna akhir tentang fitur tertentu.

Anda tidak boleh menggunakan cerita pengguna karena Anda pikir itu persyaratan kerangka kerja, atau karena itu adalah praktik tangkas yang diterima secara luas. Sebaliknya, Anda harus bekerja membuat dan menggunakannya secara efektif karena membuat tugas pemrograman lebih mudah dan profesi pemrograman lebih menyenangkan. Jarak tempuh Anda mungkin berbeda, tentu saja.

Saya tidak berpikir masalahnya di sini adalah Scrum, saya pikir masalahnya adalah tidak ada proyek yang dapat disampaikan dengan jelas dan (saya sudah sering mengalami ini) tidak ada arah yang jelas.

Saya pikir tugas teknis Anda baik-baik saja, mungkin di sisi besar tetapi dapat diukur dan didefinisikan sehingga sangat baik untuk sebuah cerita.

Tugas penelitian adalah bendera merah besar bagi saya di Scrum karena mereka memberikan sedikit manfaat yang terlihat dan dapat membuat ruang lingkup yang sangat besar. Saya menganjurkan membatasi ini dimuka dalam sprint, mereka tidak boleh ditambahkan dan mereka tentu tidak boleh ditambahkan dengan mengorbankan tujuan yang berkomitmen. Jika mereka perlu menyelesaikan tugas sprint yang disepakati maka ketergantungan itu harus jelas dalam perencanaan (jika tidak, apa yang mereka perkirakan?).

Dalam pengalaman saya, proyek dengan banyak "lonjakan investigasi" adalah kedok bagi pengembang yang tidak benar-benar melakukan banyak hal dan ingin menghabiskan waktu mencari tahu tentang hal keren baru yang mengilap daripada menciptakan nilai bisnis. Saya tidak menyarankan tim Anda melakukan ini, tetapi sebuah proyek membutuhkan tujuan yang jelas dan jika pengembang diberi kebebasan untuk "meneliti" maka mereka akan melakukannya, dan terus melakukannya, selama Anda mengizinkannya.

Scrum mengatakan bahwa Anda sebaiknya memiliki produk yang dapat dikirimkan ke pelanggan Anda. Namun, intinya di sini adalah, itu tidak menentukan produk yang dapat dikirim dan pelanggan .

Dengan kata lain, dalam kasus spesifik Anda, Anda mungkin mendefinisikan produk yang dapat dikirim sebagai peningkatan kode, perubahan platform, penulisan ulang dan pendesainan ulang, dll., Dan menganggap manajer teknis Anda sebagai pelanggan Anda.

Itu masuk akal 100% bagi saya. Anda membuat jaminan yang menceritakan kisah pengguna produk Anda, dan siapa pengguna itu? Manajer teknis. Jadi barang-barang seperti:

1. Sebagai manajer teknis, saya ingin database saya berubah dari MySQL ke X, sehingga saya dapat meningkatkan skalabilitas
2. Sebagai pengembang, saya ingin sistem logging yang komprehensif, sehingga saya dapat mendiagnosis lebih efisien

Dan apa yang Anda kirim ke pelanggan Anda (manajer teknis) adalah sistem pencatatan.

Namun, mengenai tugas-tugas R&D yang Anda bicarakan, saya sarankan Anda membaca tentang lonjakan di Scrum. Mereka pada dasarnya adalah tugas-tugas kecil yang membantu Anda menentukan waktu yang dibutuhkan untuk melakukan tugas-tugas asing yang lebih besar.

Sebagai Scrum Master, Anda mungkin ingin mempertimbangkan sprint yang lebih panjang karena sifat pekerjaan. Ini akan memberi Anda sedikit lebih banyak penyangga untuk tugas "penelitian". Namun, saya pikir Anda perlu memastikan tugas menghasilkan semacam produk kerja / bukti konsep dalam kode. Apa yang Anda harapkan dilakukan oleh seorang programmer? Minta mereka untuk mengerjakan sesuatu dan menggunakan informasi ini untuk menentukan apakah A: itu melakukan apa yang kita inginkan B: berkinerja lebih baik C: Berapa lama untuk mendapatkan lebih banyak kecepatan dan mulai mendapatkan ide berapa lama ambil untuk membuat sesuatu.

Jika Anda menemukan Anda tidak tahu sebanyak yang Anda pikirkan tentang penulisan ulang saat ini, Anda dapat pergi ke siklus sprint yang lebih pendek. Jangan takut untuk menyesuaikannya saat Anda melanjutkan; inilah yang dimaksud dengan gesit. Setelah penelitian Anda, Anda juga dapat memutuskan untuk pergi dengan teknologi baru. Ini bisa menjadi alasan lain untuk mempersingkat sprint sebelum terlalu jauh dari kendali. Anda mungkin menemukan di tengah sprint hal-hal baru tidak akan berfungsi. Hentikan sprint dan sesuaikan dengan teknologi lama. Lagipula, pengembang Anda seharusnya dapat membandingkan dan membedakan metode lama dan baru.

Anda menyulap kebutuhan pengembang Anda dan dalam hal ini membuat aplikasi ditulis ulang. Saya menduga ada Pemilik Produk yang ingin proyek ini selesai lebih cepat daripada nanti dan tidak akan menerima kebutuhan untuk "penelitian" sebagai alasan jangka panjang.

Beberapa strategi di bawah ini dapat membantu,

1. Ya, Anda dapat memiliki backlog dengan cerita teknis .

   Seperti kisah pengguna, ini juga harus Kisah Teknis, dengan fokus pada manfaat yang akan dibawanya kepada pengguna akhir. Berikut ini beberapa tips menulisnya. Ini adalah cerita yang akan membawa nilai intrinsik ke produk seperti Anda ingin pindah ke back-end yang lebih baik dll.

2. Untuk Investigasi (Penelitian) Tugas Gunakan Spike

   Spike adalah eksperimen yang memungkinkan pengembang untuk belajar cukup banyak tentang sesuatu yang tidak diketahui dalam cerita pengguna, misalnya teknologi baru, untuk dapat memperkirakan cerita pengguna itu. Lonjakan harus kotak waktu. Ini menentukan waktu maksimum yang akan dihabiskan untuk belajar dan memperbaiki perkiraan lonjakan.