Bagaimana SCRUM mengelola lingkungan tempat anggota tim dibagikan?

Nah, pertanyaannya sendiri. Di tempat kerja saya kasus-kasus itu terjadi, tetapi juga, banyak buku Agile mempromosikan bekerja di tempat kerja yang sama dan terkonsentrasi dalam proyek saat ini untuk menjadi lebih cepat dalam kecepatan pekerjaan.

Mungkin aku tidak begitu tahu tentang topik itu, mungkin tidak seketat itu, tapi itu sebabnya aku ingin tahu apa yang Agile usulkan dalam kasus-kasus seperti itu.

Siapa saja?

Dalam metodologi Scrum itu hanya mempengaruhi estimasi.

Anda akan menetapkan faktor fokus untuk orang itu berdasarkan alokasi waktu mereka untuk setiap proyek.

Jadi, jika saya mengerjakan Proyek A dan Proyek B secara setara, Proyek A akan menghitung sumber daya seperti:

Proyek A - Faktor fokus tim 70%
Sam - 10 hari, alokasi 100% (7 setelah faktor fokus)
Joe - 10 hari, alokasi 100% (7 setelah faktor fokus)
Me - 10 hari, alokasi 50% (3,5 setelah faktor fokus )
Total: 25 hari * 70% faktor fokus = 17,5 kecepatan yang diproyeksikan

Anda juga dapat menghitung faktor fokus secara terpisah untuk anggota tim penuh waktu dan untuk anggota tim paruh waktu daripada satu kali untuk seluruh tim, karena berkurangnya efisiensi dari pemisahan proyek. Dalam hal ini, Anda akan menggunakan faktor fokus proyek saya 50% dan mengalikannya dengan alokasi pribadi 50% untuk 25%, atau kecepatan proyeksi 2,5 hari .

Seberapa baik ini bekerja dalam praktek, akan menjadi faktor seberapa baik Anda tahu sebelumnya berapa banyak waktu yang akan dihabiskan sumber daya bersama untuk setiap proyek, dan seberapa baik Scrum bekerja untuk Anda dengan cara lain.

Dalam pengalaman saya di Scrum, kecepatan hanya dapat diprediksi jika proyek & tim tetap sama dan berdedikasi. Jika salah satu dari hal-hal ini berubah, maka Anda tidak dapat benar-benar menggunakan perhitungan kecepatan dari sprint sebelumnya untuk melakukan estimasi Anda. Anda dapat mencoba, tetapi Anda akan jauh lebih banyak daripada biasanya.

Secara umum, Anda pasti harus mencoba untuk menjaga tim tetap sama & berdedikasi di LEAST sepanjang sprint, lebih jika Anda bisa.

Menurut pendapat saya ini akan sangat mempengaruhi semua proyek. Ini bukan hanya masalah estimasi atau perencanaan. Ya, Anda dapat mengatakan bahwa jika anggota tim dialokasikan ke tiga proyek dan mereka memiliki alokasi 33% untuk setiap proyek, Anda tahu semua yang Anda butuhkan dan Anda selesai tetapi itu tidak benar.

Pergantian konteks sangat mahal. Juga mempertahankan komitmen penuh untuk beberapa proyek paralel tidak mungkin sehingga 33% persen waktu pengembang jauh dari 33% ketika pengembang ditugaskan untuk hanya satu proyek.

Tempat lain di mana ini benar-benar gagal adalah komunikasi. Apa yang terjadi jika seorang anggota tim yang saat ini mengerjakan proyek A harus mengkomunikasikan sesuatu dengan anggota tim yang mengerjakan proyek A kemarin tetapi saat ini mengerjakan proyek B? Itu adalah hambatan bagi mereka berdua karena yang pertama membutuhkan informasi tetapi yang kedua terkonsentrasi pada proyek yang sama sekali berbeda dan setiap pertanyaan untuk proyek A hanya mengganggunya. Scrum master dari proyek A ingin pengembangnya mendapatkan informasi secepat mungkin dan master Scrum dari proyek B tidak ingin anggota timnya terganggu oleh apa pun yang tidak terkait dengan proyek B. Jika Anda ingin menghindari ini, Anda harus merencanakan semua pengembang dari tim untuk mengerjakan proyek yang sama dalam beberapa hari yang sama - itu adalah komplikasi besar untuk keseluruhan proses perencanaan dan sesuatu yang harus dihindari sepenuhnya.

Anda juga harus merencanakan semua rapat untuk tidak bertabrakan. Anda juga harus memahami bahwa rapat itu benar-benar sia-sia dan karena itu harus ada jumlah minimum rapat yang diharuskan sesingkat mungkin untuk tetap mengendalikan prosesnya. Tetapi jika Anda memiliki anggota tim yang mengerjakan tiga proyek, ia harus berpartisipasi dalam semua pertemuan untuk tiga proyek tersebut => tiga kali lebih banyak pertemuan di mana pengembang tidak menghasilkan nilai bisnis apa pun.

Sebagai kesimpulan tangkas juga tentang mengurangi limbah (ya itu dari pendekatan Lean) dan berbagi anggota tim di antara tim adalah salah satu kegagalan terburuk dalam hal memperkenalkan limbah dan mengurangi produktivitas. Saya kira nilai bisnis yang dikirim untuk alokasi 33% ke satu proyek akan sama dengan nilai bisnis yang diberikan dari 10-16% dari alokasi waktu penuh. Itu berarti bahwa pengembang tidak hanya akan berpartisipasi 1/3 kali pada proyek tetapi selama waktu itu produktivitasnya akan antara 1/3 hingga 1/2.

SCRUM didasarkan pada memiliki tim yang berkomitmen tanpa anggota bersama, oleh karena itu Anda mungkin juga bertanya:

Mengingat kita telah diberitahu kita harus membuat true == false, bagaimana kita melakukannya x

Jika bukan SCRUM, jangan menyebutnya SCRUM!

Pertanyaan kuncinya adalah tentang komitmen anggota tim terhadap proyek. Idealnya, seorang anggota tim harus benar-benar berkomitmen untuk keberhasilan proyek. Ini tidak berarti bahwa waktunya benar-benar didedikasikan untuk proyek, tetapi bahwa ia dapat melakukan tugas apa pun yang diperlukan untuk proyek ketika sedang mengerjakan proyek.

Seringkali dengan personil yang hanya paruh waktu pada suatu proyek, mereka hanya terlibat untuk lingkup komitmen yang terbatas. Misalnya, Anda mungkin memiliki orang yang hanya melakukan pengoptimalan basis data.

Dalam hal itu, seringkali lebih baik memperlakukan orang itu sebagai "sumber daya" daripada sebagai anggota tim. Tim memutuskan berapa banyak sumber daya yang mereka inginkan dalam Sprint tertentu, dan memberi mereka satu set tugas yang sangat spesifik untuk diselesaikan untuk Sprint. Terkadang lebih baik jika Tim memiliki anggota tim tertentu yang bertanggung jawab atas sumber daya itu, dan mereka akan melakukan pembaruan status dan pelaporan hambatan untuk sumber daya itu dalam Scrum harian.

Saya percaya salah satu aspek inti dari Scrum adalah menjaga agar tim fokus pada satu hal pada satu waktu (satu proyek, satu cerita, satu tugas ...)

Anda bertanya "apa yang Agile usulkan" dalam situasi di mana Anda tidak dapat mengalokasikan sumber daya untuk satu proyek ... Anda mungkin mempertimbangkan untuk mencoba salah satu dari:

• Simpan papan Kanban besar yang membentang beberapa proyek. Karena sebuah proyek memiliki kebutuhan, proyek itu ditambahkan ke papan tulis, karena orang memiliki kapasitas, mereka menarik cerita-cerita kunci. Masalahnya adalah bahwa semua proyek dikelola bersama yang mengurangi prediktabilitas keseluruhan untuk satu proyek. Konon, cerita individu / elemen Kanban akan ditarik dan dikembangkan oleh orang atau tim yang fokus. (Anda mungkin mencoba membuat tim 4-5 orang yang lebih kecil untuk menarik dari papan Kanban
• Hanya berikan sumber daya yang berkomitmen. Simpan kumpulan sumber daya khusus untuk suatu proyek. Ini dilindungi sebagai tim dan interupsi dijaga mendekati nol. Juga simpan "tim respons cepat" yang tidak memiliki jaminan simpanan dan tidak memiliki fokus proyek / produk. Ketika interupsi muncul, tim respons cepat berurusan dengan interupsi. Ketika mereka tidak memiliki gangguan, mereka dapat fokus pada peningkatan sistem build, menambah kerangka uji otomatisasi, dll. Juga, mereka dapat membantu dengan ulasan kode / ulasan desain dan pemecahan masalah bug yang rumit / jahat yang muncul. Kelola pengembangan seolah-olah tim ini tidak ada. Yang bisa mereka lakukan adalah menarik pengiriman. Putar orang melalui tim ini untuk "tetap segar" (orang tampaknya suka / benci berada di tim respons cepat ...)

semoga ini membantu!