Tim saya yang terdiri dari 4 pengembang berpengalaman bekerja pada aplikasi Windows modular yang besar (sekitar 200 KLoC). Saya telah fokus pada basis kode inti sejak awal proyek (3 tahun yang lalu) dan secara bertahap telah bergeser ke posisi pengembang semi-lead, meskipun saya bukan manajer tim.
Iterasi kami saat ini adalah refresh UI prioritas tinggi yang diminta oleh manajemen atas, yang melibatkan sekitar 15 perubahan pada basis kode inti. Ketika ditanya oleh manajer, saya memperkirakan bahwa masing-masing dari 15 perubahan akan memakan waktu kurang dari empat jam untuk saya selesaikan , totalnya kurang dari 7 hari kerja. Saya kemudian mengajukan diri untuk melakukan pekerjaan itu. Sebagai gantinya, manajer memutuskan untuk membagi 15 tugas secara merata ke keempat pengembang.
Dalam tiga hari sejak kami mulai bekerja, saya telah mengamati dua hal:
Anggota tim yang tidak berpengalaman lainnya menyelesaikan masing-masing sekitar 1 atau kurang tugas.
Hukum Brook dalam tindakan: Saya menghabiskan sekitar setengah dari waktu saya untuk memberikan bantuan (berusaha melatih mereka dalam menggunakan komponen). Akibatnya, saya hanya menyelesaikan 2 tugas sendiri, daripada yang diharapkan 5 atau 6.
Saya mendekati manajer saya dengan kekhawatiran bahwa kami terlambat dan sekali lagi menyarankan agar saya menyelesaikan tugas yang tersisa. Permintaan saya ditolak, dan alasan yang disebutkan untuk membagi beban secara merata ada dua:
- Batasi faktor truk / bus - tingkatkan pengembang lain pada keterampilan ini sekarang, sehingga di masa depan pekerjaan apa pun dapat diberikan kepada siapa pun, bukan hanya saya.
- Untuk menghilangkan "bottleneck" (saya) dan menyelesaikan pekerjaan lebih cepat.
Supaya jelas, saya tidak punya masalah dengan: a) menginvestasikan waktu mengajar, b) orang menyentuh kode saya, atau c) keamanan pekerjaan. Bahkan, saya secara teratur menyarankan kepada ketua tim agar saya melatih para dev lain tentang aspek-aspek tertentu dari basis kode inti untuk mengurangi risiko.
Dalam iterasi ini kami juga memiliki banyak koleksi perbaikan bug berprioritas tinggi yang ditargetkan, sehingga tampaknya akan ada lebih banyak kemajuan yang dapat dilakukan jika beban kerja didistribusikan kembali.
Dalam Mythical-Man-Month, Brooks 'menyarankan " Tim Bedah " di mana setiap tim terdiri dari pemimpin + sub-pemimpin (manajer dan saya), dan beberapa peran kecil. Saya merasa seolah-olah kita secara alami jatuh ke dalam organisasi ini, tetapi manajer saya berusaha menentangnya. Saya merasa bahwa faktor bus sudah diurus (manajer pandai dalam kode inti), dan bahwa bottleneck sebenarnya tidak ada (melibatkan lebih banyak pengembang tidak akan membuat pekerjaan berjalan lebih cepat). Saya pikir dalam hal ini, Tim Bedah adalah Hal yang Baik.
Ini adalah perasaan saya, tetapi saya bukan manajer yang berpengalaman, kami juga tidak harus berurusan dengan faktor bus (mengetuk kayu). Apakah Brooks benar? Pernahkah Anda bekerja di "Tim Bedah" di mana faktor bus ikut bermain? Apakah ada teknik yang lebih baik untuk mengelola keahlian mendistribusikan?
Pertanyaan serupa: