Saya pikir itu benar, di beberapa lingkungan Agile digunakan sebagai alasan untuk tidak disiplin. Masalah sebenarnya adalah kita tidak tahu mengapa kita memiliki metodologi. Secara pribadi, saya merasa metodologi adalah masalah arsitektur dalam arti bahwa arsitektur sistem seharusnya menangani non-fungsional, atribut kualitas, metodologi harus mengatasi beberapa atribut yang sama (rawatan, pengembangan produktivitas, transfer pengetahuan, et al.)
Melihat metodologi sebagai kontrol untuk atribut proses menyiratkan beberapa hal: 1) tanpa metrik kita tidak dapat membandingkan efektivitas satu metodologi dengan yang lain, 2) keputusan aktif perlu dibuat tentang atribut apa yang penting (waktu pengiriman vs kode transfer kualitas vs pengetahuan).
Tanpa memiliki metrik dan tujuan nyata, kami hanya memilih metodologi sebagai "bulu ajaib" kami yang jika kami pegang teguh, kami akan dapat memberikan perangkat lunak.
Sekarang nay-sayers dari Agile, XP, Scrum, dll berbicara tentang kerapuhan dari kategori metodologi tertentu. Argumennya adalah: mengapa menggunakan metodologi yang dapat disabotase oleh satu orang yang kurang disiplin untuk mengikuti semua aturan? Pertanyaannya adalah yang valid; Namun, itu adalah gejalanya, bukan penyebabnya. Jika set metrik proses yang akurat dan bermakna (itulah bagian yang sulit) didefinisikan, diuji, dan umpan balik tepat waktu diberikan, saya pikir kita akan menemukan metodologi tertentu tidak ada hubungannya dengan kesuksesan. (Berbicara secara anekdot, saya telah melihat proyek yang sukses menggunakan banyak metodologi dan dua kali lebih banyak gagal menggunakan metodologi yang sama)
Jadi apa metriknya? Mereka berbeda dari proyek ke proyek, tim ke tim, dan waktu ke waktu. Berguna untuk ketika jadwal pengiriman penting, yang saya pribadi gunakan adalah keterampilan estimasi dan kualitas. Sebagian besar pengembang dapat secara akurat memperkirakan tugas yang panjang satu minggu atau kurang. Jadi satu pendekatan adalah untuk membagi proyek menjadi tugas satu minggu pengembang dan melacak siapa yang membuat estimasi. Seiring berjalannya proyek, mereka dapat mengubah estimasi mereka. Setelah tugas selesai, jika dimatikan lebih dari 10% (1/2 hari) kami memperlakukan ini sama seperti bug - kami mengidentifikasi mengapa perkiraannya tidak aktif (yaitu tabel basis data tidak dipertimbangkan), identifikasi tindakan korektif (yaitu melibatkan DBA dalam estimasi), dan kemudian melanjutkan. Dengan menggunakan informasi ini, kami dapat membuat metrik seperti # bug estimasi per minggu, # bug per pengembang,
Terus? Saat itulah metodologi muncul - jika Anda memiliki model prediktif yang gagal memenuhi kualitas proses, Anda dapat memilih untuk menambah atau menghapus beberapa aspek metodologi dan melihat bagaimana itu mempengaruhi model Anda. Memang, tidak ada yang mau bermain dengan proses pengembangan karena takut gagal, tapi kami sudah gagal pada tingkat yang tinggi dan dapat diprediksi secara konsisten. Dengan membuat perubahan individu dan mengukur hasilnya, Anda mungkin menemukan bahwa Agile adalah metodologi yang sempurna untuk tim Anda, tetapi Anda bisa dengan mudah menemukan RUP, air terjun, atau sekadar kumpulan praktik terbaik untuk menjadi ideal.
Jadi saran saya mari kita berhenti khawatir tentang apa yang kita sebut proses, melakukan pemeriksaan yang relevan dengan tujuan proses pengembangan kami, dan bereksperimen dengan berbagai teknik untuk meningkatkan proses itu.