Scrum dan mengerumuni tugas yang tidak dapat diparalelkan

8

Master scrum saya saat ini adalah orang percaya sejati yang tidak mau mengalah pada bentuk scrum resmi. Saya tidak ingin ini terdengar ranty, saya benar-benar bertanya tentang solusi ortodoks untuk masalah ini karena saya telah berhasil menyelesaikan masalah dengannya di masa lalu dengan menyusun kembali hal-hal dalam istilah resmi.

Contoh terkini dari masalah berulang yang kami miliki adalah bahwa ada beberapa ketergantungan pemesanan antara beberapa cerita kami. (Secara khusus, bagian dari pengembangan menggunakan program pihak ketiga yang kami hanya memiliki lisensi kursi tunggal.) Ada beberapa tugas pengaturan yang diperlukan yang terkait dengan ini yang telah dikumpulkan menjadi "Cerita Pengaturan" dan kemudian kami memiliki 6 tugas yang bisa diikuti dalam urutan apa pun.

Masalahnya adalah bahwa untuk sprint saat ini kami menarik dalam Setup Story dan salah satu tindak lanjut dari cerita, di mana saya mengatakan bahwa kami tidak dapat mengambil cerita lagi dalam grup ini, meskipun sprint kami kurang dari setengah penuh. Ada cerita yang tidak berhubungan di backlog yang diprioritaskan lebih rendah dari grup ini yang saya sarankan untuk kita bawa ke dalam sprint. Namun, semua ini diprioritaskan di bawah cerita di grup ini. Pada titik ini master scrum menyatakan bahwa kita harus mengerumuni "Setup Task" dan menyelesaikannya lebih cepat, ini adalah konflik yang pernah kita alami sebelumnya dan dia telah menggali tumitnya.

Jadi, untuk paruh pertama dari sprint ini, dua pengembang dan sumber daya pengujian mengawasi saya bekerja melalui situs web konfigurasi vendor eksternal, mengunduh sumber daya, dan menyeret sertifikat di sekitar. Sementara itu saya tahu bahwa kami memiliki rilis yang muncul dalam tiga sprint dan kami bisa mendapatkan hampir seluruh tumpukan yang ingin dilakukan PO, tapi kami tidak akan melakukannya karena tidak ada pekerjaan yang dilakukan pada tugas-tugas itu sementara semua orang duduk menonton (er, swarms) tugas pengaturan untuk cerita prioritas tertinggi.

Master scrum saya mengatakan bahwa satu-satunya masalah kami adalah menyelesaikan cerita yang kami terima untuk sprint. Yang saya mengerti, tetapi saya merasa seperti kita gagal organisasi yang lebih besar dengan tidak mengkomunikasikan "kemasan sampah yang buruk" yang menyebabkan prioritas yang kami terima dari pemilik produk.

Jadi, seberapa resmi masalah ketergantungan antara cerita dan cerita serial yang ditangani oleh metodologi?

agile scrum scrum-master

— Ukko
sumber

Batasan lisensi pihak ketiga ini adalah fakta kehidupan dan harus digunakan sebagai alasan untuk memprioritaskan kembali cerita dan membatalkan sprint ini dan memulai yang baru. Sebanyak semua orang ingin fitur / cerita tertentu dilakukan terlebih dahulu, itu tidak akan terjadi dan tidak masuk akal jika semuanya menunggu. Berkerumun adalah salah satu solusi yang disarankan oleh Scrum Master, tetapi tim harus memutuskan apakah akan melakukannya atau tidak. Saya tidak berpikir ada sesuatu dalam hukum Scrum yang akan mencegah hal ini.

— JeffO

@ Jeffe Kami mencoba untuk sedikit mundur dan pada dasarnya mendapat ceramah tentang mengabaikan keinginan pemilik produk. Ada beberapa pembicaraan tentang menggunakan Scrumban di beberapa titik di masa lalu dan master scrum saya sangat menentang itu karena PO tidak memiliki kontrol. Ini adalah bagian dari disfungsi khusus kami yang menunjukkan bahwa berkerumun tidak tepat dalam situasi ini dijawab dengan mengerumuni lebih banyak orang.

— Ukko

Mengapa tester tidak mengerjakan tes dan / atau rencana pengujian mereka? Pengujian adalah salah satu kegiatan yang harus dimulai sebelum kode siap.

— Bryan Oakley

@BryanOakley Jawaban yang diberikan scrum master saya adalah karena mereka mungkin punya ide bagus dan pelatihan silang. Secara pribadi, saya melihatnya sebagai pemborosan, master scrum saya merasa kita harus menghindari skill silo. Pikiran saya adalah kami adalah ahli di bidang kami, tetapi dia mengatakan tujuannya adalah agar kami dapat melompat dan saling membantu.

— Ukko

1

@ Ikko: itu sebenarnya jawaban yang OK. Tujuan utamanya adalah memastikan mereka tidak benar-benar hanya tidak melakukan apa-apa. Selama mereka adalah bagian dari proses dari awal sprint hingga akhir, hanya itu yang penting. Terlalu sering pengujian dibiarkan hingga akhir sprint.

— Bryan Oakley

6

Jadi, seberapa resmi masalah ketergantungan antara cerita dan cerita serial yang ditangani oleh metodologi?

Seperti hal lain dalam Agile: Individuals and interactions over processes and tools

Jika proses Anda tidak melayani Anda, maka Anda mencetaknya menjadi sesuatu yang bermanfaat. Untuk ini, saya akan menarik cerita dengan prioritas lebih rendah (atau hutang teknis / pertumbuhan pribadi yang mungkin tidak terlihat dalam jaminan) sampai prasyarat dihapus. Dengan asumsi tentu saja Anda telah melakukan uji tuntas Anda dan itu benar - benar prasyarat yang sulit dan cepat. Untuk banyak hal, antarmuka dan tiruan dapat membuka blokir pekerjaan hingga yang asli siap.

— Telastyn
sumber

Saya benar-benar akan menunjukkan Individu dan interaksi atas proses dan alat . Saya benar-benar mendukung untuk menarik pekerjaan, tetapi itu sangat tidak disukai, lagi-lagi karena kita menentang prioritas PO. Yang lucu adalah itu tampaknya menjadi tema yang muncul saat saya menggambarkan ini.

— Ukko

2

@Ukko - prioritas adalah prioritas, bukan antrian.

— Telastyn

1

@Ukko: Cara resmi Scrum untuk mengatasi masalah itu adalah dengan berbicara dengan PO jika mereka ingin memprioritaskan kembali beberapa pekerjaan untuk menyelesaikan simpanan lengkap lebih cepat. Saya masih harus menemui PO yang tidak mau bekerja dengan tim sedemikian rupa.

— Bart van Ingen Schenau

@ BartvanIngenSchenau menyebutkan PO berdering. Itu adalah satu hal yang tidak didefinisikan dengan baik di sini. Kami tidak memiliki peran PO yang baik dalam organisasi, ada sekelompok BA yang memainkan peran PO tetapi mereka bukan PO yang sebenarnya. Dalam hal ini BA mendapatkan banyak tekanan dari manajemen tentang fungsi spesifik ini, dan dia agak takut membuat kami menyentuh cerita "prioritas rendah".

— Ukko

3

Salah satu fitur kanban, yang saya yakini masuk ke scrum, adalah bahwa proses secara keseluruhan mengoptimalkan tim , bukan individu. Dengan kata lain, tidak ada dosa jika seseorang dalam tim idle untuk bagian dari sprint.

Jika tim secara keseluruhan memilih poin X cerita, itu benar-benar tidak masalah (kepada para pemangku kepentingan) apakah satu orang melakukan semua pekerjaan atau jika pekerjaan itu dibagi sama rata. Jadi, jika pemilik produk senang dengan jumlah poin yang dibawa ke sprint (dan ini adalah panggilan pemilik produk, bukan master scrum!) Maka itu yang terpenting.

Tentu saja, itu dikatakan, jika beberapa anggota tim tidak terlibat langsung dalam cerita pertama, mereka bisa sibuk menulis tes, atau melakukan apa pun yang mereka bisa pada cerita lain.

Sebagai catatan terakhir, master scrum memiliki bisnis kecil "menggali tumitnya". Master scrum harus bekerja agar Anda menghilangkan hambatan produktivitas, bukan mengatur hambatan. Jika tim secara keseluruhan merasa mereka dapat menarik cerita prioritas lain yang lebih rendah, itu adalah keputusan yang harus dibuat oleh tim; master scrum tidak memiliki keputusan akhir dalam masalah ini.

Pengecualian dapat dibuat jika tim masih muda dan masih belajar scrum, tetapi jika tim sudah matang, inti dari scrum adalah untuk memberdayakan tim daripada manajer.

— Bryan Oakley
sumber

1

Cara saya melihat ini, Anda punya dua masalah berbeda:

Cara mengoptimalkan produktivitas tim Anda.
Cara memesan produk dan sprint backlog berdasarkan dependensi.

Untuk produktivitas tim Anda , saya dapat bersimpati dengan Master Scrum Anda: Saya telah menemukan, karena sifat manusia, bahwa kebanyakan orang ingin membuat semua orang sibuk, daripada mengoptimalkan seluruh tim. Menjadi sibuk tidak sama dengan produktivitas. Pemalasan mungkin merupakan hal terbaik bagi anggota tim untuk dilakukan pada waktu tertentu.

Pada masalah spesifik tugas pengaturan: ini terdengar seperti sesuatu yang harus diotomatisasi. Mengingat artikel Anda, jika saya bekerja dengan tim Anda, saya ingin meluangkan waktu mencari tahu apa yang terjadi dengan proses pengaturan ini yang menghabiskan waktu dan memblokir, karena kedengarannya seperti kandidat utama untuk meningkatkan efektivitas tim.

Saya juga berharap, paling tidak, bahwa Anda bukan satu-satunya orang di tim yang dapat melakukan ini. Jika Anda memiliki hari libur, saya berharap tim memiliki orang lain yang dapat menangani proses bottleneck ini. Berkerumun mungkin menjadi kesempatan untuk memastikan bahwa banyak orang belajar bagaimana melakukan ini.

Dengan asumsi bahwa Anda memiliki ketergantungan yang tak terhindarkan antara Product Backlog Items (PBI), saya akan menganggap semua PBI yang tergantung sebagai diblokir sampai ketergantungan pemblokiran ditangani. Secara umum, ini berarti membiarkan PBI yang diblokir keluar dari Sprint. Karena Anda memiliki kendali atas dependensi pemblokiran, saya bisa melihat membawa PBI dependen ke dalam sprint, tapi itu sepertinya langkah yang berisiko. Dalam Perencanaan Sprint, saya biasanya hanya akan mempertimbangkan PBI yang tidak diblokir.

Namun, intinya adalah menemukan yang terbaik untuk memberikan perangkat lunak yang berharga, teruji, dan bekerja seefektif mungkin.

— Dane
sumber

0

Aturan nomor 1 untuk membangun sprint backlog Anda (menambahkan item backlog produk Anda, atau PBI) harus mengikuti prinsip INVEST dasar:

Independen: PBI harus mandiri, dengan cara yang tidak ada ketergantungan yang melekat pada PBI lain.
Dapat dinegosiasikan: PBI, sampai mereka merupakan bagian dari iterasi, selalu dapat diubah dan ditulis ulang.
Berharga: PBI harus memberikan nilai kepada para pemangku kepentingan.
Diperkirakan: Anda harus selalu dapat memperkirakan ukuran PBI.
Kecil: PBI seharusnya tidak sebesar sehingga tidak mungkin untuk merencanakan / tugas / memprioritaskan dengan tingkat kepastian tertentu.
Dapat diuji: PBI atau deskripsi terkait harus memberikan informasi yang diperlukan untuk memungkinkan pengembangan pengujian

Sepertinya Scrum Master Anda memaksa tim untuk melanggar aturan pertama, semua cerita dalam sprint harus independen - apa yang Anda lakukan jika Anda diblokir pada satu cerita yang perlu Anda selesaikan untuk menutup cerita lain? Anda mungkin akan gagal menjalankan sprint dalam kasus ini.

Saya setuju bahwa pemrograman swarming / pair adalah cara yang baik untuk berkolaborasi dan berbagi pengetahuan dalam tim - tetapi jika tidak perlu mengerumuni sesuatu seperti ini, maka saya akan tetap berpegang pada senjata Anda dan mengutip INVESTASI :)

Disalin dari Wikipedia: https://en.wikipedia.org/wiki/INVEST_(mnemonic)

— skir2000
sumber