Apakah salah menggunakan Agile ketika persyaratan klien tidak berubah sama sekali?

Saya telah melihat banyak posting baru-baru ini mengatakan bahwa salah satu alasan utama mengapa Agile digunakan adalah karena klien sering mengubah persyaratan.

Namun, misalkan klien tidak sering mengubah persyaratan . Sebenarnya, klien memiliki persyaratan yang tegas meskipun mungkin agak kabur (tapi tidak ada yang tidak masuk akal), tapi saya tetap menggunakan Agile.

Alasan mengapa saya menggunakan Agile adalah karena perangkat lunaknya cukup rumit sehingga ada detail, masalah yang tidak akan saya kenali sampai saya benar-benar menghadapinya. Saya bisa melakukan pendekatan perencanaan berat skala penuh seperti air terjun, tetapi kemudian akan butuh beberapa bulan untuk menyelesaikan semua desain tingkat tinggi dan tanda tangan pengkodean tingkat rendah. Ada desain arsitektur tetap yang sangat spesifik untuk sistem ini.

Pertanyaan saya adalah: Apakah ini dianggap buruk, pengkodean koboi, anti-pola, dll.? Haruskah kita menggunakan air terjun dan merencanakan sebanyak mungkin dengan sangat rinci sebelum kita mulai mengkode ketika persyaratan stabil alih-alih mentalitas 'mari kita lakukan' di Agile?

EDIT: Poin utama di sini adalah: kita TIDAK BISA menyalahkan klien untuk mengubah persyaratan. Asumsikan klien mengarahkan kami ke masalah yang sangat konkret, beri kami daftar keinginan dalam perincian yang sangat masuk akal dan tinggalkan kami sendiri (yaitu klien memiliki hal-hal produktif sendiri untuk dilakukan, jangan mengganggunya lagi. Hanya demo kepada mereka di dekat berakhir ketika Anda memiliki prototipe kerja minimum). Apakah salah menggunakan Agile dalam skenario ini?

Apakah ini dianggap sebagai buruk, pengkodean koboi, anti-pola.

Jawaban singkat: tidak. Melakukan "gesit" dengan benar tidak berarti "tidak ada perencanaan", tetapi tidak berarti terlalu banyak menganalisis sesuatu.

salah satu alasan utama mengapa Agile digunakan adalah karena klien sering mengubah persyaratan.

Itu pernyataan yang terlalu menyederhanakan. "Mengubah persyaratan" juga tentang bagaimana pemahaman tim tentang persyaratan berubah. Dan ini tentang bagaimana prioritas pelanggan tentang perubahan persyaratan ketika dia benar-benar melihat beberapa rilis perangkat lunak.

Bahkan, "gesit" bekerja IMHO terbaik tepat dalam situasi yang Anda jelaskan - klien memiliki pengetahuan yang baik tentang persyaratan keseluruhannya, Anda dapat menulis rencana umum darinya, mengisi simpanan Anda dengan banyak "cerita pengguna", dan sudah memiliki informasi yang cukup untuk memilih arsitektur sistem yang tepat. Iterasi singkat dari strategi pengembangan tangkas kemudian akan membantu untuk membuat "persyaratan samar" lebih tepat, dengan banyak umpan balik jika Anda masih menuju ke arah yang benar. Ini juga akan memberi Anda umpan balik awal tentang upaya dan biaya nyata (yang merupakan sesuatu yang Anda masih bisa gagal dalam pendekatan air terjun, bahkan jika Anda tahu setiap bit persyaratan secara rinci).

Menggunakan lincah dalam situasi ini masih merupakan ide yang sangat bagus. Ada banyak manfaat untuk gesit, hanya satu di antaranya adalah umpan balik teratur dari pelanggan dan kemampuan untuk menanggapi perubahan persyaratan seperti yang Anda sebutkan.

Salah satu alasan utama mengapa proyek air terjun terkenal karena kegagalan adalah masalah 'hampir selesai' - pengujian menghasilkan tumpukan bug pada akhirnya, meninggalkan produk yang tidak dapat dihapus dan tidak tahu apakah perlu dua hari atau dua tahun lagi untuk memperbaiki bug yang beredar. Agile menghilangkan risiko ini sepenuhnya. Jika proyek tangkas berjalan berlebihan, Anda masih bisa memberikan versi yang berfungsi:

A) Membuktikan kepada pelanggan Anda sebenarnya hampir sampai di sana melalui demo ("Semua cerita ini selesai, kita bisa melakukan beberapa yang terakhir jika Anda mau") dan lebih banyak waktu akan mendapatkan apa yang mereka inginkan.

B) Berpotensi cukup baik bagi mereka untuk tetap bahagia dan bebas.

Bagi saya, menghilangkan risiko kegagalan total ini adalah alasan yang cukup bagi sebuah bisnis untuk beralih ke proses pengembangan yang gesit, kemampuan untuk membangun perangkat lunak yang lebih baik daripada yang direncanakan semula adalah sangat berguna. Seperti disebutkan dalam jawaban lain, persyaratan 'kongkrit' itu sering kali masih dapat ditempa secara mengejutkan.

Agile sangat ideal jika Anda perlu sering menerima umpan balik dengan klien. Ini bisa jadi karena persyaratan sering berubah, tetapi bisa juga karena alasan lain.

Di sisi lain, Agile dapat bekerja sama baiknya jika persyaratannya sepenuhnya stabil dan klien hanya mengharapkan pengiriman big-bang tunggal, tetapi Anda mungkin harus menyesuaikan hal-hal sedikit untuk jumlah keterlibatan yang diharapkan klien selama proyek. Ini berarti bahwa peran Pemilik Produk harus diisi dari dalam organisasi Anda sendiri dan orang itu harus memiliki cukup mandat dari pelanggan untuk membuat keputusan.

Anda selalu dapat membagi rilis besar menjadi rilis kecil (sprint) dan meminta umpan balik dari klien Anda. Dengan cara ini Anda yakin bahwa Anda melakukan hal yang benar dan klien dapat melacak kemajuan Anda.

Jika ada sesuatu yang salah, Anda dapat menawarkan klien Anda kesempatan untuk mengoreksi Anda lebih awal, yang sangat bagus. Lebih baik untuk memperbaiki kesalahan Anda sesegera mungkin, daripada menunjukkan omong kosong pada akhirnya dan mencoba memperbaikinya ketika Anda bahkan tidak tahu harus mulai dari mana.