Pertanyaan mengelola bug dalam produksi telah menjadi fitur besar dalam pikiran saya akhir-akhir ini. Sprint tidak dimaksudkan untuk memiliki item yang ditambahkan ke dalamnya, tetapi untuk bug kritis , ini tidak dapat dihindari.
Bagaimana cara mengelola break ini di sprint? Apakah Anda hanya memberikan persentase "kelonggaran" sprint waktu, sehingga hanya mengisi mengatakan 80% dari jadwal dengan item sprint "berjaga-jaga"?
Jika ini penting , Anda harus menanganinya.
Untuk mengukur dampaknya pada sprint, Anda harus mencatatnya.
Lihatlah radiator informasi ini:
Ada bagian yang disebut " Item yang tidak direncanakan ". Letakkan bug kritis Anda di sana. Seperti yang Anda lihat ada kebalikan dengan bagian " Next " di mana Anda menempatkan lebih banyak cerita pengguna daripada yang direncanakan jika Anda menyelesaikan sprint lebih cepat.
Anda akan membicarakannya di ulasan sprint dan / atau retrospektif . Tujuannya adalah untuk menemukan cara membatasi mereka, dan juga menyesuaikan kecepatan Anda .
Jika Anda menggunakan kecepatan sebagai indikator 'kelonggaran' berdasarkan cuaca kemarin, ia akan secara otomatis menyesuaikan sejumlah rata-rata pekerjaan tambahan yang memotong sprint.
Jika masalah produksi disebabkan oleh bug yang dibuat pada sprint sebelumnya, tidak apa-apa untuk memperbaiki pekerjaan memotong kecepatan sprint saat ini. Dengan cara ini kecepatan tim 'dikompensasi' untuk poin yang seharusnya tidak mereka dapatkan sebelumnya.
Kadang-kadang Anda tidak membuat semua tujuan sprint Anda, lupakan saja ;-) Kecepatan akan rata-rata ke angka yang lebih rendah jika itu sering terjadi.
Segala hal yang tidak penting lainnya hanya dapat dimasukkan pada backlog untuk dimasukkan secara normal dalam sprint. Saya lebih suka memberikan prioritas utama pada bug dan tidak membuatnya menghitung kecepatan.
Semua waktu yang diperlukan untuk memperbaiki dan mengatasi masalah produksi secara otomatis dimasukkan ke dalam kecepatan tim. Hanya butuh waktu untuk rata-rata, tidak benar-benar membutuhkan uang saku terpisah.
sumber
Saya bekerja di tim yang sebagian besar melakukan pengembangan, tetapi juga bertanggung jawab untuk sistem kompleks yang ada. Kami juga memiliki masalah ini.
Pada dasarnya, kami memperkirakan poin kami berdasarkan sprint terakhir dan kemudian menyimpan sejumlah poin untuk pekerjaan pemeliharaan yang diharapkan. Jika terjadi tugas pemeliharaan yang melebihi ini secara signifikan, seperti pemadaman besar, kami menambahkannya sebagai cerita pengguna dan menghapus yang sudah ada yang belum dimulai, untuk menjaga sprint dengan ukuran yang sama. Jika masalah besar muncul yang kurang mendesak, kami memindahkannya ke sprint berikutnya.
Ya, ini secara teknis tidak mengikuti scrum. Tetapi fleksibilitas telah bekerja dengan baik untuk kami.
Kami telah menyempurnakan waktu yang disediakan ini dengan bertanya kepada tim di setiap pertemuan perencanaan apakah mereka melihat alasan untuk menyimpang dari reservasi standar. Kami memperkenalkan ini setelah melakukan perpindahan kantor yang membutuhkan waktu lebih banyak dari yang kami perkirakan, yang menyebabkan banyak cerita tidak selesai.
Namun, jangan hanya terpaku pada bagaimana tim saya atau tim lain melakukannya. Pilih sesuatu, dan lakukan saja. Tidak ada cara untuk memastikan itu akan bekerja dengan baik untuk tim Anda. Coba, dan evaluasi dalam retrospektif. Jika tim tidak bahagia, coba sesuatu yang berbeda dan evaluasi lagi. Semua tim berbeda, dan kebutuhan serta keterbatasan mereka juga berbeda.
sumber
Jika ini merupakan masalah produksi kritis, maka Anda harus dapat mengatasinya secara langsung, metodologi pengembangan yang dipilih tidak relevan. Perbaikan terbaru tidak terkait dengan siklus rilis reguler (spints atau sebaliknya).
Saya sarankan memperbaikinya dalam branche 'fix', berdasarkan pada kode yang saat ini dalam produksi.
sumber