Saya akan mencoba mengilustrasikan beberapa aspek yang belum ditangani oleh jawaban lain dan itu, IMO, penting.
Masalah mendasarnya adalah ini: Beberapa pengembang terutama dimotivasi oleh kegembiraan karena mengambil bagian dari pekerjaan yang sulit, memikirkan desain, memikirkan masalah potensial, kemudian memecahkan masalah sepotong demi sepotong, dengan hanya interaksi minimal dengan yang lain, selama perpanjangan periode waktu. Mereka umumnya menyelesaikan pekerjaan dengan tingkat kualitas tinggi dan tepat waktu; pekerjaan mereka dapat dipelihara dan cocok dengan arsitektur keseluruhan.
Pengembang semacam ini mungkin merasa sulit untuk beradaptasi dengan lingkungan yang gesit dan sikap mereka sering dianggap sebagai "keengganan untuk berubah", mungkin terkait dengan ego atau menjadi kuno.
Apa yang sering diabaikan adalah bahwa untuk menyelesaikan masalah yang kompleks seseorang perlu menangani banyak informasi, dan bahwa ini mungkin memerlukan banyak analisis, berpikir, mencoba, membuat sketsa solusi, membuangnya, mencoba yang lain. Masalah yang sedemikian rumit mungkin memerlukan beberapa jam hingga beberapa minggu kerja fokus hingga Anda memiliki solusi tuntas.
Salah satu pendekatan adalah bahwa pengembang mengambil spesifikasi masalah, pergi ke kamarnya, dan kembali dua / tiga minggu kemudian dengan solusi. Kapan saja (bila diperlukan), pengembang dapat memulai beberapa interaksi dengan anggota tim lain atau dengan pemangku kepentingan (mengajukan pertanyaan tentang masalah tertentu) tetapi sebagian besar pekerjaan dilakukan oleh pengembang yang ditugaskan tugas.
Apa yang terjadi dalam skenario lincah? Tim memecah masalah menjadi potongan-potongan kecil (cerita pengguna) setelah analisis cepat (perawatan). Harapannya adalah bahwa cerita pengguna tidak tergantung satu sama lain tetapi sering kali ini tidak terjadi: untuk memecah masalah yang kompleks menjadi bongkahan yang benar-benar independen, Anda akan membutuhkan pengetahuan yang biasanya Anda dapatkan setelah mengerjakannya selama beberapa hari. Dengan kata lain, jika Anda dapat memecah masalah yang rumit menjadi bagian-bagian kecil yang mandiri, itu berarti Anda pada dasarnya sudah menyelesaikannya dan Anda hanya memiliki pekerjaan tekun yang tersisa. Untuk masalah yang membutuhkan, katakanlah, tiga minggu kerja, ini mungkin akan menjadi kasus selama minggu kedua, tidak setelah beberapa jam perawatan dilakukan pada awal sprint.
Jadi, setelah sprint telah direncanakan, tim bekerja pada potongan masalah yang berbeda yang mungkin memiliki ketergantungan satu sama lain. Ini menghasilkan banyak overhead komunikasi yang mencoba mengintegrasikan solusi yang berbeda yang mungkin sama-sama baik tetapi berbeda satu sama lain. Pada dasarnya, pekerjaan trial-and-error didistribusikan ke semua anggota tim yang terlibat, dengan overhead komunikasi tambahan (meningkat secara kuadratik). Saya pikir beberapa masalah ini diilustrasikan dengan sangat baik dalam artikel ini oleh Paul Graham, khususnya poin 7.
Tentu saja, berbagi pekerjaan antara anggota tim mengurangi risiko yang terkait dengan satu anggota tim yang meninggalkan proyek. Di sisi lain, pengetahuan tentang kode dapat dikomunikasikan dengan cara lain, misalnya menggunakan ulasan kode atau memberikan presentasi teknis kepada rekan kerja. Dalam hal ini, saya tidak berpikir ada peluru perak yang berlaku untuk semua situasi: kepemilikan kode bersama dan pemrograman pasangan bukan satu-satunya pilihan.
Selanjutnya, "pengiriman fungsionalitas kerja dalam interval yang lebih pendek" menghasilkan gangguan pada alur kerja. Ini mungkin OK jika potongan fungsi adalah "tambahkan tombol batal di halaman login" yang dapat diselesaikan pada akhir sprint, tetapi ketika Anda mengerjakan tugas yang kompleks Anda tidak ingin gangguan seperti itu: seperti mencoba mengendarai mobil 100 km secepat yang Anda bisa dan berhenti setiap 5 menit untuk memeriksa seberapa jauh yang Anda dapatkan. Ini hanya akan memperlambat Anda.
Tentu saja, memiliki pos-pos pemeriksaan yang sering dimaksudkan untuk membuat proyek lebih dapat diprediksi, tetapi dalam beberapa kasus gangguan bisa sangat membuat frustasi: orang hampir tidak dapat memperoleh kecepatan bahwa sudah waktunya untuk berhenti dan menyajikan sesuatu.
Jadi, saya tidak berpikir bahwa sikap yang dijelaskan dalam pertanyaan hanya terkait dengan ego atau penolakan terhadap perubahan. Mungkin juga beberapa pengembang menganggap pendekatan penyelesaian masalah yang dijelaskan di atas lebih efektif karena memungkinkan mereka untuk memiliki pemahaman yang lebih baik tentang masalah yang mereka selesaikan dan tentang kode yang mereka tulis. Memaksa pengembang seperti itu untuk bekerja dengan cara yang berbeda dapat mengakibatkan pengurangan produktivitas mereka.
Juga, saya tidak berpikir bahwa memiliki beberapa anggota tim bekerja secara terpisah pada masalah yang spesifik dan sulit bertentangan dengan nilai-nilai lincah. Bagaimanapun, tim harus mengatur diri sendiri dan menggunakan proses yang mereka temukan sebagai yang paling efektif selama bertahun-tahun.
Hanya 2 sen saya.
There’s a great story of a manager of a Coca-Cola plant whose numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice.
Anda tidak melakukan kelincahan sampai Anda mengerti mengapa Anda melakukannya.