Bagaimana membuat model persiapan cerita untuk isu-isu yang ditangani di beberapa proyek

Di perusahaan kami beberapa tim akan mengerjakan komponen yang berbeda dari beberapa proyek secara bersamaan. Misalnya, satu tim mungkin membuat jenis perangkat lunak (atau perangkat keras) tertentu untuk beberapa proyek, tim lain jenis perangkat lunak tertentu. Kami menggunakan proyek Jira untuk menjadi tuan rumah masalah untuk proyek tertentu dan papan Jira untuk sprint untuk tim yang berbeda.

Kami menghadapi masalah menghindari duplikasi kode di seluruh proyek, dan telah mengembangkan satu set perpustakaan inti yang kami gunakan dalam proyek-proyek tersebut. Saat bekerja pada suatu proyek, beberapa pengembang akan menyadari bahwa sepotong kode yang mereka tulis lebih menarik dan harus diekstraksi ke perpustakaan inti, atau bahwa beberapa kode inti yang mereka gunakan memiliki bug, memerlukan lebih banyak parametrization, atau fitur baru ... sebut saja.

Jadi mereka membuat masalah perpustakaan inti yang masuk ke dalam simpanan proyek inti. Semua masalah ini ditinjau, diprioritaskan, dan diperkirakan dalam pertemuan perpustakaan inti (sekali seminggu), dan akan ditangani sesuai dengan prioritas mereka (di samping masalah spesifik proyek) dalam beberapa sprint mendatang.

Prioritas dilakukan dengan mengurutkan masalah, dan kami memberi sortedlabel pada masalah yang diurutkan (sehingga kami dapat mencari yang tidak diurutkan). Kemudian kami secara manual menempatkan satu masalah per komponen inti ke bagian atas jaminan agar dapat ditangani terlebih dahulu. Ketika beberapa tim memasukkan masalah semacam itu ke dalam sprint mereka, mereka harus menyeret item lain secara manual ke bagian atas backlog.

Ini cukup rawan kesalahan. Pada dasarnya, yang kita miliki adalah status masalah tambahan "diurutkan" dan "diperkirakan" antara "terbuka" dan "dalam proses". Mencerminkan ini melalui sortedlabel dan posisi mereka di papan tulis agak rumit dan rawan kesalahan. (Misalnya, jika seseorang memindahkan masalah dalam beberapa sprint atas dan ke bawah, ini akan tercermin di papan inti, diam-diam mengacak urutan masalah yang mungkin telah diputuskan tim dalam diskusi ekstensif beberapa minggu sebelumnya.)

Jadi apa cara yang lebih baik untuk mengimplementasikan ini?

Jika Anda ingin melacak ini di JIRA saya akan mengikutinya seolah-olah itu adalah tugas baru.

Jadi misalnya:

Katakanlah Anda memiliki kisah CORE-75: Foo the Bar .

Setelah diputuskan tim mana yang akan mengambil tugas, mereka kemudian dapat membuat tugas baru: DUKUNGAN-123: Foo the Bar in Core .

Anda kemudian dapat memblokir CORE-75 dengan SUPPORT-123 . Setelah SUPPORT-123 selesai, Anda dapat kembali ke CORE-75 . Anda dapat menggabungkan ulasan, atau meninjau kode dua kali (satu kali oleh tim yang ditunjuk, satu kali oleh tim yang lebih spesifik untuk inti).

Ini benar-benar apa yang Anda lakukan: Pertimbangkan perpustakaan inti sebagai produk / pelanggan sendiri, jangan setengah jalan.

Salah satu pendekatan adalah bagi tim untuk membuat masalah baru untuk sprint mereka yang menghubungkan kembali ke masalah perpustakaan inti. Sepertinya Anda membuat sub tugas untuk suatu tugas, tetapi di seluruh papan / backlog.

Pendekatan lain adalah hanya melacak ini secara terpisah di luar JIRA. Ekspor backlog yang ada sebagai CSV atau spreadsheet dan atur itu.

Dengan memisahkan masalah dari JIRA, Anda memiliki fleksibilitas untuk menentukan prioritas dalam rapat perencanaan dan tidak perlu khawatir tentang algoritma penyortiran JIRA di papan dan Anda tidak perlu menggunakan label juga.

Dalam pertemuan perencanaan prioritas untuk perpustakaan inti Anda dapat membuat daftar tugas yang harus diselesaikan untuk perpustakaan inti dan siapa pun yang bertanggung jawab / bertanggung jawab untuk perpustakaan inti dapat memastikan tugas-tugas ini dimulai oleh tim proyek yang berbeda dan diselesaikan.

Ada pandangan bahwa Core Libraries yang merangkum banyak kesamaan, tetapi fungsionalitas yang tidak berhubungan adalah 'hal buruk' (tm)

ada beberapa alasan untuk ini

• Mereka menarik dependensi dan kode yang tidak Anda butuhkan
• Mengubahnya menyebabkan perubahan pada semua aplikasi
• Tidak ada 'pemilik' tunggal

Dalam kasus Anda, saya pikir pembagian tugas Anda oleh aplikasi perubahan akan dibuat menjadi akar masalahnya. Semacam membalikkan hukum Conway.

Saya pikir solusi terbaik bagi Anda adalah dengan pindah dari memiliki 'Perpustakaan Inti' Perpustakaan harus memiliki satu set spesifik (kecil) fungsionalitas yang dikelompokkan secara logis. Seharusnya mungkin untuk menyelesaikannya. yaitu JsonParser, LogWriter dll. Jarang masuk akal untuk menambahkan fitur baru.

Namun, dengan asumsi ini akan menjadi tugas yang panjang dan sulit, sebagai solusi sekunder saya hanya akan menjaga tugas perpustakaan inti dengan tim yang membutuhkan fungsionalitas. yaitu.

Tugas: tambahkan fitur X ke produk Y

Dev: hmm beberapa kode untuk fitur X harus ada di corelibrary .. Saya akan meletakkannya di sana sebagai bagian dari tugas ini