Di Scrum, haruskah Anda membagi backlog dalam backlog fungsional dan backlog teknis atau tidak?

Dalam tim Scrum kami, kami menggunakan jaminan simpanan, yang sebagian besar berisi topik fungsional, tetapi juga terkadang berisi topik teknis. Keuntungan memiliki 1 backlog adalah menjadi mudah untuk memilih topik untuk sprint berikutnya, tetapi saya memiliki beberapa pertanyaan:

• Pertama, bagi saya tampaknya lebih logis untuk memiliki jaminan teknis yang terpisah, di mana pengembang sendiri dapat menambahkan item teknis murni, seperti: kita dapat meningkatkan kinerja dalam metode ini, kelas ini tidak memiliki beberapa dokumentasi teknis, ... Dengan memiliki satu jaminan, semua pengembang selalu harus melewati pemilik produk agar topik mereka ditambahkan ke backlog, yang tampaknya merupakan pekerjaan tambahan yang tidak perlu bagi pemilik produk.
• Kedua, jika Anda memiliki pemilik produk yang hanya berfokus pada item fungsional murni, item teknis murni (seperti dokumentasi teknis yang hilang, kode yang mengikis dan harus di refactored, kelas yang selalu memberikan masalah selama debugging karena mereka tidak memiliki fondasi yang stabil dan harus di refactored, ...) selalu berakhir di akhir daftar karena "mereka tidak melayani pelanggan secara langsung". Dengan memiliki jaminan teknis yang terpisah, dan waktu yang disediakan dalam setiap sprint untuk item teknis murni ini, kami dapat meningkatkan aplikasi secara fungsional, tetapi juga menjaga mereka tetap sehat di dalamnya.

Apa pendekatan terbaik? Satu atau dua tumpukan?

Saya bukan ahli tetapi saya akan mengatakan Anda hanya dapat memiliki satu jaminan simpanan per tim. Tim perlu memutuskan masalah mana yang mendesak dan mana yang bisa ditunda. Jika Anda memisahkan masalah ke dalam tipe tumpukan yang berbeda, Anda akan menentang gagasan inti yang merupakan inti dari scrum, yaitu bahwa ada kumpulan masalah dan masing-masing berlari tim bekerja pada yang paling mendesak dari mereka. Jika Anda (sub) membagi tim, Anda mungkin dapat membagi jenis tugas yang relevan bagi mereka, tetapi pada dasarnya Anda akan menyiapkan tim yang bekerja secara paralel. Urgensi / keharusan adalah penentu nomor satu dalam hal merencanakan sprint berikutnya. Anda dapat mengategorikan tugas, tetapi ini seharusnya tidak menghalangi proses keputusan Anda.

Saya ingin menambahkan suara saya kepada mereka yang merekomendasikan satu jaminan simpanan per produk. Membuat backlog lain adalah respons rasional, tetapi sebenarnya hanya menghindari masalah inti: Mengapa Pemilik Produk tidak akan memprioritaskan item teknis daripada item fitur? Anda harus fokus pada pemecahan ini daripada menyelesaikannya. Anda dapat menggunakan teknik 5 Whys , misalnya, untuk mencoba memahami hal-hal dasar.

Mungkin ada banyak alasan mengapa PO tidak memprioritaskan masalah teknis. Misalnya, mungkin tim teknologi tidak menjelaskan biaya jangka panjang (dalam $$$) karena tidak menangani hutang teknis. Mungkin itu sesuatu yang lain sama sekali. Ada peluang bagus untuk masalah komunikasi, dan solusi jangka panjang adalah mengatasinya dan mengatasinya - hilangkan rintangannya.

Selain itu, saya punya pertanyaan lain untuk Anda pikirkan: Mengapa utang teknis muncul sejak awal? Idealnya pekerjaan seperti refactoring dll harus terjadi dalam cerita fungsional dan diselesaikan dalam sprint. Mereka seharusnya tidak menjadi cerita tambahan dengan hak mereka sendiri jika tidak, Anda tidak memiliki kode yang berpotensi dapat dikirim.

Apa yang Anda maksud adalah yang biasa disebut 'utang teknis'. Kadang-kadang bisa sulit untuk melihat bagaimana utang teknis cocok dengan proses scrum, dengan cara yang sama seperti cacat.

Apa yang Anda usulkan mirip dengan menyarankan bahwa ada 'backlog cacat' yang terpisah juga, membagi backlog menjadi 3.

Secara pribadi, saya tidak akan menganjurkan pemisahan jaminan produk sama sekali. Ide backlog produk adalah untuk mewakili item pekerjaan yang beredar . Dari perspektif itu, satu-satunya perbedaan antara fitur dan item utang teknis adalah bahwa persyaratan berasal dari tim pengembangan, bukan dari pelanggan. Itu masih item pekerjaan dan masih perlu dikelola, termasuk memprioritaskannya terhadap item pekerjaan lain. Ini terutama benar jika item hutang teknis memerlukan pengujian, dalam hal ini item tersebut harus melalui proses QA yang persis sama dengan fitur reguler.

Saya setuju dengan Onno karena seharusnya hanya ada satu jaminan tunggal per proyek. Kalau tidak, tim pada dasarnya mengambil di tangan mereka sendiri beberapa keputusan yang seharusnya menjadi milik pemilik produk.

Bahkan item "murni teknis" harus memiliki nilai praktis bagi pengguna (dan karenanya bagi pemilik produk) untuk memenuhi syarat untuk sprint backlog. Adalah tugas Anda untuk menjelaskan manfaat ini kepada pemilik produk, dan untuk meyakinkannya tentang nilai tambah yang membenarkan biaya. Dan proses ini memaksa Anda sendiri untuk memikirkan masalah-masalah ini dan memilih perubahan teknis yang membawa nilai paling besar ke proyek dengan sedikit usaha.

Saya setuju dengan semua jawaban di atas. Dalam panasnya realitas komersial, PO akan terus memprioritaskan cerita fungsional daripada yang teknis. Seringkali membuat frustrasi tim. Tim harus menahan diri dari cerita teknis tanpa nilai pengguna (siapa yang peduli dengan optimasi, jika kecepatan bukan masalah?) Dan belajar untuk melihat tugas teknis tertentu lainnya sebagaimana tersirat oleh cerita fungsional. "Definisi selesai" juga memainkan peran besar. Kisah-kisah fungsional yang tersisa masuk pada backlog untuk diprioritaskan PO.

Contoh: Dokumentasi Teknis: Ketersediaan dokumentasi teknis (jika ada) adalah barang tipikal yang dimiliki oleh DOD dan karenanya, memperbaruinya DITERAPKAN dengan setiap cerita fungsional.

Misalnya kode Refactoring: harus dilakukan ketika bermanfaat bagi pengembangan produk. Tidak lebih awal (tim tidak boleh berasumsi ke arah mana produk akan berevolusi) dan tidak lebih lambat ketika sudah berubah menjadi utang teknis. Setelah desain ditinjau juga bisa menjadi bagian dari Departemen Pertahanan.

Saya setuju dengan MelR. Jika ada sesuatu yang 'teknis', kita perlu melihat mengapa kita melakukannya - atau bahkan apa sebab dan akibat jangka pendek dan jangka panjang (kepada pengguna) ?.

Saya telah melihat banyak tumpukan di mana yang disebut 'tugas teknis' dapat dengan mudah ditulis dalam bentuk nilai bisnis.

Tugas teknis juga sering merupakan hasil dari cerita-cerita besar yang dipecah karena dapat menjadi cara yang lebih mudah untuk memecah hal-hal. Tetapi ini dapat menyebabkan iterasi yang lebih lambat dari nilai tambah yang sebenarnya (atau peluang umpan balik) atau bahkan lebih buruk lagi dari kegagalan sprint.

Berkenaan dengan "kode yang mengikis dan harus di refactored" seperti yang Patrick katakan, saya yakin kita perlu bertanya - bidang fungsi sistem manakah yang mempengaruhi kode itu? dan apa efek jangka panjangnya pada pengguna jika kami tidak melakukan refactor sekarang?

Lalu ada subjek "meninggalkan hal-hal sedikit lebih baik daripada bagaimana kita menemukannya" untuk mengurangi hutang teknis jangka panjang dan dan dapatkah ini dilakukan sebagai bagian dari cerita kecil di setiap sprint tanpa terlalu banyak berdampak pada proyek yang lebih luas?

Pada akhirnya saya tidak melihat perlunya dua jaminan simpanan ini membuka peluang untuk memperlambat kebutuhan yang diprioritaskan dengan benar - tetapi ada kebutuhan bagi pemilik produk yang dididik mengenai dampak teknis dan memiliki kemampuan yang kuat untuk mengidentifikasi nilai sebenarnya sehingga untuk memecah cerita secara vertikal - Adobe menawarkan penjelasan yang baik tentang pengirisan vertikal .

Tidak, Anda tidak boleh membuat cerita teknis. Ini adalah kesalahan umum. Cerita Anda harus mencerminkan persyaratan bisnis. Hal-hal teknis tidak pernah benar-benar dari persyaratan bisnis. Ini adalah peran master scrum dan tim untuk mengevaluasi semua tugas teknis yang harus mereka lakukan untuk mencapai tujuan atau cerita.

Jika cerita Anda tentang membuat layar masuk misalnya, Anda harus mempertimbangkan pembuatan database juga jika belum dibuat.

Saya tidak melihat masalah untuk dibuat, dengan PO, tugas di mana tim TI adalah pengguna. Jika tugas dapat dipahami oleh PO dan dapat dievaluasi dalam hal nilai bisnis maka ya Anda punya cara untuk membuat semacam cerita teknis. Anda cukup menggunakan sistem.