Perlu kombinasi yang masuk akal dari semua jawaban sejauh ini. Pada akhirnya, ketika Anda berbicara tentang sekelompok orang pintar (pengembang), Anda harus memberi mereka alasan mengapa perilaku itu penting dan memberi mereka cukup kontrol atas bagaimana perilaku itu diterapkan sehingga mereka berinvestasi untuk melakukannya dengan benar. Mandat dari atas umumnya longgar dengan orang-orang pintar, karena jika mereka tidak setuju bahwa masalahnya adalah masalah, maka mereka cenderung menghabiskan lebih banyak waktu untuk bekerja di sekitar mandat daripada mengikuti aturan.
Inilah beberapa taktik saya:
Melakukan Perubahan:
Pertama, tim perlu menyepakati kapan komitmen dan apa yang harus dilakukan. Sangat penting adalah pengaturan bangunan yang masuk akal, sehingga orang tidak menunda hanya karena mereka tidak tahu di mana harus meletakkan sesuatu. Dan konsensus tentang kapan / seberapa sering untuk check-in. "Jangan merusak gedung" adalah aturan yang jelas, tetapi bagaimana itu diperiksa, dan siapa yang diberitahu tentang hal itu? Baseline lain adalah "tidak dilakukan jika tidak dicentang".
Sebagian besar pengembang yang saya kenal lebih dari senang untuk memeriksa kode JIKA:
- Proses check-in mudah
- Proses sinkronisasi itu mudah (memperhitungkan perubahan dari pengembang lain)
- Melihat perubahan dan berpindah antar versi itu mudah
Satu hal yang saya perhatikan baru-baru ini adalah bahwa checkin menjadi lebih sering dan tidak terlalu menyakitkan ketika kita beralih ke alat CM baru. Tim kami memelopori Konser Tim Rasional yang sebelumnya menggunakan Clearcase. Saya tidak bermaksud mengiklankan alat, tetapi gelombang baru (untuk saya) streaming checkin dengan banyak penggabungan kecil dan cepat membuatnya jauh lebih menarik untuk checkin lebih awal dan sering.
Membiarkan pengembang bertanggung jawab menghilangkan rasa sakit CM umumnya meningkatkan jumlah checkin yang terjadi.
Mengikuti Arsitektur - Tidak Menulis Masalah Model dalam Tampilan dan Pengontrol
Saya menempatkan bahwa dalam rumpun umum "melakukan arsitektur dengan benar". Saya setuju dengan siapa pun yang mengatakan ulasan sejawat - tekanan sejawat sangat bagus untuk ini. Salah satu cara saya biasanya melihat orang masuk ke flip untuk praktik terbaik di bidang ini adalah ketika rekan-rekan mereka bertanya kepada mereka mengapa mereka melakukannya dengan cara lain (cara yang tidak begitu benar). Secara umum pertanyaan "mengapa" akan membawa orang ke jalan untuk menyadari mengapa mereka harus melakukannya secara berbeda. Ketika orang memiliki alasan yang dipahami dengan baik untuk praktik terbaik, akan lebih mudah untuk mematuhinya.
Juga, jika ada beberapa formalitas yang menghubungkan seseorang dengan suatu keputusan, maka akan lebih mudah untuk menetapkan bug di area itu ... jadi jika seseorang bertanggung jawab untuk memperbaiki bug di area desain yang salah, kebutuhan untuk mendapatkan sesuatu tepat sebelum mereka dapat beralih ke sesuatu yang baru dan menarik dapat menjadi motivator besar.
Hindari Hardcoding
Saya akan mulai dengan standar pengkodean yang jelas dan mengintegrasikan tinjauan standar pengkodean dalam ulasan sejawat. Hard coding adalah salah satu hal yang dapat dengan mudah menjadi kotak centang pada agenda peer review.
Saya khawatir hal semacam ini adalah satu-satunya hal di mana saya melihatnya menjadi peran pemimpin tim untuk menegakkan aturan. Di tim yang saya jalankan, kami biasanya tidak akan membiarkan seseorang pindah sampai mereka telah memperbaiki komentar dari ulasan rekan kode mereka. Dan "no hard coding" adalah komentar peer review yang sering.
Secara umum
Dengan hampir semua latihan terbaik, saya pikir Anda harus memilih pertempuran Anda. Tidak ada tim yang akan menjadi sempurna sempurna. Tetapi Anda bisa mengawasi titik-titik rasa sakit utama Anda dan mulai mengatasinya secara berkelompok. Saya pikir itu menjadi peran pemimpin untuk benar-benar tahu apa yang menjadi titik sakit bagi tim vs kekhasan yang mengganggu dari individu tertentu.
Jika tim Anda tidak melakukan praktik terbaik tertentu, saya pikir pertanyaan pertama adalah "berapa banyak kerusakan yang diakibatkan ini?" jika jawabannya "minimal", maka itu mungkin tidak sepadan dengan waktunya. Beberapa praktik terbaik paling relevan dengan jenis sistem tertentu - meskipun secara keseluruhan baik, mereka mungkin tidak sebanding dengan perjuangan untuk sistem di mana praktik tersebut tidak sering terjadi atau bagian utama dari sistem.
Jika jawaban untuk "berapa banyak damange?" adalah "ALOT !!!", maka Anda dapat mulai membangun sebuah kasus untuk menunjukkan kepada tim bahwa semua rasa sakit dan penderitaan ini dapat dihilangkan dengan memperbaiki satu titik kendur ini dalam praktik terbaik. Kebanyakan orang senang menghindari rasa sakit dan penderitaan dan itu mengubah dialog dari "lakukan ini karena saya katakan kepada Anda", menjadi "kami memutuskan untuk melakukan ini karena itu lebih baik".