Di Scrum, bagaimana menangani pertengkaran / beban kerja di akhir sprint

Tim saya mulai menggunakan Scrum beberapa sprint yang lalu. Proyek kami melibatkan pembuatan perangkat lunak yang berinteraksi dengan perangkat fisik (robot dan sensor) dan jaminan simpanan Produk kami biasanya mewakili penambahan perangkat kontrol ke seluruh sistem.

Kami membagi tugas dekat dengan contoh di sini . Setiap fitur integrasi perangkat dipecah menjadi kode, tes, tes integrasi, ulasan sejawat, dll. Jelas, ada urutan yang melekat pada setiap Item Product Backlog. Biasanya, sprint kami berlangsung 2 minggu dan tim memiliki antara 4 hingga 6 anggota.

Kami mengalami 2 masalah di akhir sprint:

• Yang pertama adalah membuat semua orang sibuk di akhir sprint.
• Yang kedua (terkait) adalah pertikaian tentang sistem. Kami cukup banyak berintegrasi selama beberapa hari terakhir sprint. Kami hanya memiliki satu sistem integrasi, sehingga orang-orang sering diblokir untuk terus mengerjakan tugas mereka karena mereka tidak dapat mengakses sistem. Karena ini adalah akhir dari sprint, tidak ada banyak pekerjaan yang harus dilakukan dalam sprint backlog. Apa yang harus mereka kerjakan? Mengambil barang dari bagian atas tumpukan produk tidak diterima dengan baik dari pemilik produk, karena barang saat ini tidak dilakukan. Mengerjakan utang teknis akan membantu proyek secara keseluruhan tetapi tidak akan membantu menyelesaikan sprint.

Apakah ada praktik terbaik untuk menyusun sprint untuk menghindari masalah ini? Kiat bernegosiasi dengan pemilik produk?

dalam beberapa hal itu baik bahwa Anda lambat pada akhir sprint, itu berarti Anda memperkirakan dengan baik dan tidak terlalu berkomitmen, sejauh tetap sibuk, pada tim scrum saya telah bekerja pada kami selalu menambahkan tugas penelitian untuk apa yang akan terjadi selanjutnya lari cepat.

Ini bisa berupa pembuktian konsep untuk hal-hal yang akan muncul, atau melihat di mana faktor ulang kode yang ada, bekerja untuk mendapatkan cakupan pengujian yang lebih baik pada kode Anda, dll.

Anda harus memperbaiki sistem integrasi Anda sehingga tim Anda dapat mengintegrasikan pekerjaan mereka segera setelah setiap tugas selesai, daripada menunggu big bang di akhir sprint.

Saya sarankan bekerja dengan cerita pengguna yang cukup singkat untuk diselesaikan dalam beberapa hari. Selesai di sini berarti kode lengkap, teruji, dan terintegrasi.

Mengingat bahwa itu adalah tanggung jawab seluruh tim untuk memberikan, bukan anggota individu, per se , apakah mungkin untuk memiliki semua empat-ke-enam anggota bekerja pada tugas masing-masing BERSAMA - mendorong masing-masing melalui proses dan langkah ke depan. Ini mungkin terdengar tidak efisien pada awalnya, tetapi jika hambatan yang Anda lihat seburuk itu, itu mungkin pilihan yang valid.

Juga, Anda mungkin ingin melihat teori kendala (Goldratt's The Goal ), dan melihat bagaimana Anda dapat menganalisis mengapa dan di mana Anda memiliki hambatan integrasi ini.

Kami telah mengatasinya dengan mengadopsi pendekatan Kanban.

Kami memiliki antrian di perangkat lunak pelacakan kami (Jira) dengan minimum dan maksimum.

Kami mempersiapkan 'sesuai kebutuhan'. Mungkin seminggu sekali, mungkin 3 kali, tergantung pada batas dan pekerjaan yang dilakukan.

Ini akan membantu Anda dalam membuat pemilik produk fokus pada menjaga antrian Anda dengan banyak hal yang harus dilakukan dan dapat mengurangi manajemen mikro tiket individu. Ingatlah bahwa perubahan biasa akan memakan waktu.

Kami masih melakukan demo setiap dua minggu dan kami merilis setiap minggu.

Wow, jika Anda tidak mengatakan robot, saya akan menganggap Anda berada di tim saya sekarang. Kami punya yang tepatset masalah yang sama. Setelah bekerja pada banyak proyek lincah dengan berbagai tingkat kesetiaan terhadap manifesto dan berbagai tingkat keberhasilan, analisis saya adalah bahwa masalah kita adalah sprint yang terlalu pendek. Kami sedang melakukan sprint dua minggu yang menyebabkan beberapa masalah. Salah satunya adalah bahwa kita akhirnya menjadi terlalu berhati-hati dalam perencanaan dan sering berakhir dengan hari-hari mati pada akhirnya. Yang kedua adalah pemeriksaan yang sangat banyak, retrospektif dan perencanaan yang memakan waktu 1-2 hari setiap dua minggu. Yang lain, seperti yang Anda katakan, harus berintegrasi pada menit terakhir dan sering gagal beberapa jam sebelum peninjauan. Proyek gesit pertama dan paling sukses saya memiliki sprint empat minggu, yang saya kumpulkan cukup besar menurut standar industri, tetapi itu berhasil bagi kami.

EDIT: Teringat satu hal lagi dari proyek pertama itu adalah anugerah. Kami selalu memiliki jaminan produk yang sepenuhnya diprioritaskan dan memberi pengembang kebebasan untuk mengambil tugas darinya jika tugas sprint mereka selesai dan tidak ada tugas sprint lain yang tersedia.

Masalah kedua mungkin merupakan konsekuensi dari mencoba memperbaiki non-masalah # 1. Anda harus membuat orang yang tidak sibuk, untuk membantu rekan-rekan mereka; alih-alih bekerja pada tugas non-sprint, yang menyebabkan pertikaian pada integrasi terbatas.

Selain itu, Anda tidak boleh berintegrasi di akhir sprint, tetapi terus menerus.

Anda baru memulai. Beri tim kesempatan untuk mengatasi masalah ini sendiri melalui proses retrospektif mereka.

Kedua, pemilik produk Anda harus mempercayai tim untuk mengetahui cara mengatur dan mengoptimalkan diri mereka sendiri. Sebagai imbalannya, tim mempercayai PO untuk mengetahui apa yang dibutuhkan pelanggan.

Ini adalah tantangan yang sangat umum dengan tim tangkas baru. Sangat menyenangkan untuk melihat ketika sebuah tim mulai menghancurkan silo mereka sendiri dan tumbuh.