Pertanyaan ini benar-benar mengandung dua pertanyaan, yang perlu ditangani secara terpisah:
Mengapa beberapa tim memiliki proses pengembangan yang ketat?
Jawaban sederhananya adalah karena jika tidak, kesalahan akan terjadi. Kesalahan mahal. Ini berlaku untuk pengembangan dan juga berlaku untuk bidang TI lainnya (sysadmin, DBA, dll.).
Ini sangat sulit untuk dipahami oleh banyak pengembang dan pekerja TI karena sebagian besar dari kita hanya pernah bekerja di salah satu "ekstrem" - baik perusahaan besar, gaya Fortune dengan setidaknya selusin pengembang dan proses ketat untuk diikuti, atau kecil, micro-ISVs atau bahkan pekerjaan lepas di mana orang tidak mengacau dengan buruk, atau biaya untuk mengacaukannya rendah.
Tetapi jika Anda pernah melihat perusahaan di antara fase-fase ini - bahkan perusahaan dengan staf TI yang cerdas dan berbakat - Anda akan memahami bahaya tidak memiliki proses atau memiliki proses setengah-setengah. Soalnya, komunikasi di antara staf mengalami masalah Ledakan Kombinatorial ; begitu Anda mencapai level sekitar 6-10 pengembang dalam satu tim, penyebab utama cacat utama atau kritis bukanlah kurangnya bakat atau keterampilan, melainkan kurangnya komunikasi.
Alice bertanya pada hari Senin pagi dan memutuskan tidak apa-apa untuk melakukan operasi rekonstruksi di bagasi karena tidak ada orang lain yang mengerjakan bagian itu. Bob tiba satu jam kemudian, kembali dari liburannya dan penuh energi dan memutuskan dia akan mengimplementasikan fitur utama baru di bidang yang sama persis, dan mengapa repot-repot dengan cabang karena tidak ada yang pernah menyentuh kode itu? Jadi Alice melunasi "hutang teknis" itu, Bob mengimplementasikan fitur pembunuh yang telah ada di back-burner selama 6 bulan, dan ketika mereka akhirnya memeriksa kode mereka (tepat sebelum waktu tutup pada hari Jumat, tentu saja!), Seluruh tim harus tetap tinggal dan mencoba untuk bekerja melalui neraka konflik yang mengerikan yang terus hidup sebagai bug dan regresi selama beberapa minggu ke depan.
Alice dan Bob Keduanya melakukan pekerjaan yang baik pada tugas pengkodean, tetapi mereka berdua memulai dengan keputusan yang buruk ("apa hal terburuk yang bisa terjadi?"). Pemimpin tim atau manajer proyek membawa mereka melalui bedah mayat, dan memalu daftar periksa untuk mencegah hal ini terjadi lagi:
- Check-in harus dilakukan setiap hari untuk meminimalkan dampak konflik;
- Perubahan yang akan memakan waktu lebih dari 1 hari secara signifikan harus dilakukan di cabang;
- Semua tugas penting (termasuk pekerjaan non-fitur seperti refactoring) harus dilacak dengan benar dan ditetapkan dalam pelacak bug.
Saya berani bertaruh bahwa, bagi banyak dari kita, "proses" ini sepertinya masuk akal. Ini topi tua. Tapi tahukah Anda bahwa banyak tim yang lebih kecil tidak melakukan ini? Tim dua orang mungkin bahkan tidak peduli dengan kontrol sumber sama sekali. Siapa peduli? Sejujurnya itu tidak perlu. Masalah hanya mulai terjadi ketika tim tumbuh tetapi prosesnya tidak.
Tentu saja, optimasi proses seperti optimasi kinerja; ini mengikuti kurva eksponensial terbalik. Daftar periksa di atas dapat menghilangkan 80% dari cacat, tetapi setelah Anda menerapkannya, Anda menemukan bahwa beberapa hal lain menyumbang 80% dari cacat yang tersisa . Dalam contoh fiktif tapi akrab kita mungkin membangun kesalahan karena memiliki lingkungan build yang berbeda, yang pada gilirannya karena fakta bahwa tidak ada perangkat keras standar dan pengembang menggunakan perpustakaan open-source yang diperbarui setiap 2 minggu.
Jadi Anda memiliki tiga pilihan: (a) menstandardisasi perangkat keras dan sangat membatasi penggunaan perpustakaan pihak ketiga, yang mahal dan dapat mengurangi produktivitas secara signifikan, atau (b) menyiapkan server bangun, yang membutuhkan kerja sama dari kelompok sysadmin dan pengembang penuh waktu untuk mempertahankannya, atau (c) membiarkan pengembang melakukan ini sendiri dengan mendistribusikan mesin virtual standar dan memberi tahu pengembang untuk membangunnya. Jelas (b) adalah solusi jangka panjang terbaik tetapi (c) memiliki keseimbangan keandalan dan kemanfaatan jangka pendek yang lebih baik.
Siklusnya terus menerus. Setiap "kebijakan" yang Anda lihat umumnya telah dilembagakan untuk menyelesaikan masalah nyata. Seperti yang ditulis Joel Spolsky sepanjang tahun 2000 (dengan topik yang sama sekali berbeda dari Anda, tetapi tetap relevan):
Ketika Anda pergi ke sebuah restoran dan Anda melihat sebuah tanda yang bertuliskan "No Dogs Diizinkan," Anda mungkin berpikir bahwa tanda itu murni proskriptif: Mr. Restaurant tidak suka anjing di sekitar, jadi ketika dia membangun restoran dia memasang tanda itu.
Jika itu semua yang sedang terjadi, ada juga akan menjadi "Tidak ada Ular" tanda; lagipula, tidak ada yang suka ular. Dan sebuah tanda "No Elephants", karena mereka mematahkan kursi ketika mereka duduk.
The nyata Alasan bahwa tanda adalah ada sejarah: itu adalah penanda sejarah yang menunjukkan bahwa orang-orang digunakan untuk mencoba untuk membawa anjing mereka ke restoran.
Itu sama di sebagian besar (saya tidak akan mengatakan semua) tim perangkat lunak: Kebijakan seperti "Anda perlu menambahkan kasus uji untuk setiap perbaikan bug" hampir selalu menunjukkan bahwa tim secara historis memiliki masalah dengan regresi. Regresi adalah salah satu masalah yang paling sering disebabkan oleh gangguan komunikasi daripada ketidakmampuan. Selama Anda memahami kebijakannya, Anda mungkin dapat mengambil jalan pintas yang sah (mis. Saya harus memperbaiki 6 bug kecil tetapi semuanya ada dalam fitur yang sama, jadi saya sebenarnya bisa hanya menulis satu test case untuk kesembilannya).
Itu menjelaskan mengapa prosesnya ada, tapi itu bukan keseluruhan cerita. Setengah lainnya adalah:
Mengapa proses ini sangat sulit untuk diikuti?
Ini sebenarnya adalah pertanyaan yang lebih sederhana untuk dijawab: Itu karena tim (atau manajemennya) berfokus pada hasil berulang dan meminimalkan cacat (seperti di atas) tetapi belum memberikan perhatian yang cukup untuk optimasi dan otomatisasi proses itu.
Misalnya, dalam pertanyaan awal, saya melihat beberapa masalah:
Sistem kontrol revisi (CVS) adalah warisan dari standar saat ini. Untuk proyek - proyek baru , telah digantikan hampir seluruhnya oleh subversi (SVN), yang dengan cepat menjadi gerhana oleh sistem terdistribusi seperti Mercurial (Hg). Beralih ke Hg akan membuat percabangan dan penggabungan menjadi jauh lebih sederhana, dan bahkan dalam contoh hipotetis saya di atas, persyaratan komitmen harian akan menjadi jauh lebih tidak menyakitkan. Kode bahkan tidak perlu dikompilasi, karena repositori adalah lokal; - pada kenyataannya, pengembang yang lebih malas bahkan dapat mengotomatiskan langkah ini jika mereka mau, membuat skrip logoff untuk secara otomatis melakukan perubahan pada repositori lokal.
Tidak ada waktu yang dihabiskan untuk mengotomatisasi proses Mesin Virtual. Seluruh proses untuk memperoleh, mengonfigurasi, dan mengunduh sumber / pustaka ke mesin virtual bisa 100% otomatis. Ini bisa menjadi proses tanpa pengawasan yang Anda jalankan di server pusat di suatu tempat saat Anda mengerjakan perbaikan bug di mesin lokal Anda (dan hanya menggunakan VM untuk memastikan bangunan yang bersih).
Di sisi lain, pada skala tertentu solusi VM-per-pengembang mulai menjadi konyol dan Anda seharusnya hanya memiliki server Integrasi Berkelanjutan. Di situlah manfaat produktivitas nyata masuk, karena (kebanyakan) membebaskan pengembang individu dari tidak perlu khawatir tentang pembangunan sama sekali. Tidak perlu khawatir tentang menyiapkan mesin virtual bersih karena server build selalu bersih.
Kata-kata dari pertanyaan ("uji kasus dengan semua langkah") menyiratkan bahwa ada beberapa pengujian manual yang terjadi. Ini, sekali lagi, dapat bekerja untuk tim kecil dengan beban kerja yang relatif rendah, tetapi tidak masuk akal sama sekali pada skala yang lebih besar. Tes regresi dapat dan harus otomatis; tidak ada "langkah", hanya kelas atau metode yang ditambahkan ke unit / test suite integrasi.
Tak perlu dikatakan, pindah dari Bugzilla ke sistem pelacakan bug yang lebih baru (lebih baik) akan membuat bagian pengalaman itu jauh lebih tidak menyakitkan.
Perusahaan tidak harus murah atau bodoh hanya karena mereka belum menyelesaikan masalah ini. Yang mereka tahu adalah bahwa proses saat ini bekerja , dan dalam beberapa kasus mereka menolak risiko dan enggan mengubah apa pun tentang hal itu. Tapi sebenarnya mereka hanya perlu diyakinkan tentang manfaatnya .
Jika pengembang menghabiskan seminggu melacak waktu mereka pada semua tugas non-coding, maka Anda dapat dengan mudah menambahkannya, tunjukkan kepada manajemen bahwa (misalnya) investasi nol modal, 100 orang per jam dalam peningkatan ke Mercurial akan menghilangkan hingga 10 jam kerja per minggu untuk menyelesaikan konflik gabungan, maka itu adalah hadiah 10 minggu dan mereka hampir pasti akan menyetujuinya. Gagasan yang sama dengan build server (CI) atau pelacakan bug yang lebih baik.
Untuk merangkum: Tim belum melakukan hal-hal ini karena tidak ada yang meyakinkan manajemen bahwa itu cukup penting untuk dilakukan hari ini . Jadi, ambil inisiatif dan ubah menjadi persamaan biaya-manfaat; cari tahu berapa banyak waktu yang dihabiskan untuk tugas-tugas yang dapat disederhanakan / otomatis dengan risiko minimal, dan menghitung titik impas dan hasil akhirnya dari alat atau teknik baru. Jika mereka masih tidak mendengarkan, maka Anda sudah tahu apa pilihan Anda yang tersisa.
Jika pengembang menghabiskan seminggu melacak waktu mereka pada semua tugas non-coding, maka Anda dapat dengan mudah menambahkannya, menunjukkan manajemen ... dan mengubahnya menjadi persamaan biaya-manfaat dll ...
Bagian atas terlihat perlu dikembangkan lebih lanjut.
Saya dapat mengkonfirmasi bahwa itu berfungsi. Pemrogram menggunakannya beberapa kali dalam salah satu proyek yang saya kerjakan dan setiap kali menyebabkan perubahan yang diinginkan.
Kesan keseluruhan saya adalah bahwa jika dilakukan dengan benar, trik ini dapat menghapus ketidaktahuan dan inersia manajemen yang cukup berat.
Saya ingin mencatat bahwa perusahaan tempat kami (pengembang) harus menggunakan pendekatan DIY semacam ini sangat tidak dewasa dalam hal IT. Di vendor perangkat lunak yang lebih berpengalaman saya melihat hal-hal seperti itu kebanyakan dilakukan oleh manajer sendiri. Dan sebagai aturan mereka lebih produktif daripada programmer. Jauh lebih produktif.