Bagaimana mengoordinasikan waktu pengembang antara dua proyek berbeda di Scrum?

Saya menjadi master scrum dari tim yang baru dibentuk, yang bertanggung jawab untuk membuat perangkat lunak DAN memelihara aplikasi yang digunakan lainnya. Jadi pada dasarnya setiap anggota tim memiliki tugas pengembangan & operasi.

Saya telah mengamati bagaimana mereka bekerja beberapa minggu terakhir dan saya perhatikan bahwa tim mengalami kesulitan dalam mengoordinasikan tugas-tugas ini. ketika seorang pengembang berkonsentrasi pada pengkodean, ia terganggu untuk memperbaiki masalah yang muncul dalam produksi, dan sulit baginya untuk fokus lagi pada tugas sebelumnya.

Saya telah mencoba mengalokasikan% dari waktu pengembang untuk pekerjaan operasi tetapi tampaknya ini tidak menyelesaikan masalah. Saya tertarik untuk mendengar dari master scrum yang menemukan situasi ini sebelumnya, bagaimana Anda mengelolanya dan apa rekomendasi Anda?

Masalah ini setua scrum. Ada solusi, tetapi Anda tidak akan menyukainya.

• Letakkan tugas baru di backlog.
• Jangan mengganggu pengembang.
• Tunggu sprint berikutnya.

Meletakkan devs Anda di lebih dari satu scrum, memiliki dua backlog yang terpisah atau hanya menetapkan persentase waktu mereka untuk sprint, semuanya bekerja sesuai dengan scrum yang ingin dicapai, yaitu aliran konsisten tugas yang diselesaikan.

Jika Anda mencoba hal-hal semacam itu pada dasarnya Anda kembali ke metodologi pengembangan 'chaos' atau 'JFDI' dengan semua masalah yang menyertainya misalnya

• Pengembang memiliki sepuluh tugas saat bepergian dalam satu waktu. Tidak ada yang tahu apa yang sedang mereka kerjakan atau kapan akan selesai.
• Waktu tidak diketahui untuk menyelesaikan proyek, karena itu tergantung pada apa proyek lain yang terjadi pada saat yang sama
• Tidak ada pandangan yang konsisten tentang prioritas proyek. Manajer lain mengalihkan pengembang ke proyek kesayangan mereka.

Tentu saja tanggapan yang biasa terhadap saran ini adalah "Tapi saya tidak bisa melakukan itu! Bisnis ini membutuhkan bug produksi untuk diperbaiki secepatnya!"

Tetapi itu tidak sepenuhnya benar.

Jika Anda benar-benar memiliki banyak bug aktual yang memengaruhi bisnis sejauh ini, maka Anda perlu menjadi profesional dan meningkatkan pengujian Anda. Kerjakan bug dan tes otomatis sampai Anda memperbaiki semuanya. Pekerjakan tim QA dan uji semua rilis baru.

Apa yang lebih mungkin terjadi adalah salah satu dari yang berikut:

• Bugnya adalah masalah operasional, kehabisan ruang disk, tidak ada DR, tidak ada Cadangan, tidak ada kegagalan dll. Dapatkan tim OPS.

• Bugnya adalah pengguna tidak mengerti bagaimana sistem seharusnya bekerja "Ini terjadi! Apakah itu bug?". Dapatkan helpdesk dan latih pengguna Anda, tulis dokumentasi.

• Takut akan kembalikan. Anda meluncurkan fitur baru dan merusak sesuatu, jangan coba-coba memperbaiki. Putar kembali ke versi sebelumnya dan letakkan bug di backlog.

Hanya mencoba berpikir di luar kotak di sini.

Karena mungkin tidak mungkin untuk membuat pemilik produk melihat sesuatu dengan cara Anda. Mungkin masih ada kesalahan kritis yang tidak bisa menunggu, bertemu dengan klien di mana bantuan pengembang diperlukan dll. Di mana Anda perlu mengeluarkan satu pengembang dari sprint untuk sementara waktu.

Mengapa tidak mencoba mengantisipasi ini dan menggunakannya untuk keuntungan Anda?

Anda mungkin memerlukan tim yang terdiri dari 5+ orang untuk menjadi realistis.

Tapi mengapa tidak mengambil satu pengembang setiap sprint (berputar di antara pengembang, masing-masing mendapat giliran mereka).

Karena kemungkinan besar tidak ada cukup kesalahan untuk menggunakan pengembang penuh untuk koreksi, ada masalah atau tugas lain yang dapat dilakukan.

• Menjalankan tes untuk mengidentifikasi hambatan kinerja atau masalah skalabilitas
• Mempertahankan sistem pembangunan
• Pertemuan dengan klien
• Meneliti kerangka kerja / perpustakaan baru
• Menjelajahi fitur bahasa yang ingin Anda gunakan
• Membaca tentang masalah keamanan
• Pemeliharaan basis data
• Pemeliharaan server

Kecepatan tim mungkin naik, stres mungkin turun, konflik dengan manajemen mungkin turun, Anda benar-benar mendapatkan waktu untuk meningkatkan pengetahuan Anda.

Solusi efektif untuk mengelola upaya pengembang untuk masalah-masalah produksi yang benar-benar penting yang saya gunakan adalah "pendekatan Batman".

Aspek mahal dari tanggung jawab dukungan produksi sambil mengembangkan fungsionalitas baru adalah pengalihan konteks, jadi Anda harus membatasi itu.

Dengan pembelian tim, buat daftar anggota tim dan siklus melalui itu, sehingga setiap hari, orang baru dinyatakan "Batman" pada pertemuan berdiri dan akan menanggapi masalah produksi penting pada hari itu. Sisa tim dapat tetap fokus pada pengembangan tanpa harus mengubah konteks dan semua orang memiliki rasa sakit yang cukup terhadap dukungan. Dengan tim yang terdiri dari 5 orang, itu adalah satu hari dalam seminggu di mana pengembang mungkin terganggu dan 4 hari tidak terputus, waktu pengembangan yang dapat diprediksi.

Ini memiliki manfaat pengetahuan / pengalaman yang dibagikan di antara tim, sehingga Anda tidak memiliki satu orang yang bertanggung jawab untuk memperbaiki masalah tertentu dan menjadi satu titik kegagalan dan pembagian masalah dukungan yang adil.