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

12

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?

agile development-process

— InformedA
sumber

2

@randomA: sebenarnya, IMHO Anda tidak boleh mencoba air terjun murni hanya jika Anda ingin membuat produk yang berfungsi yang membutuhkan lebih dari upaya satu minggu.

— Doc Brown

10

Tolong beri saya klien Anda

— razethestray

7

Saya akan memberikan 2x lebih untuk klien Anda daripada @razethestray

— Euphoric

2

Jika klien Anda tidak ingin "diganggu setiap hari", pelajari cara melakukan komunikasi yang efektif dengannya. Misalnya, alih-alih membuat asumsi (mungkin salah) tentang poin yang tidak jelas, kumpulkan pertanyaan dalam daftar dan kirim klien Anda daftar secara berkala. Bahkan lebih baik: mengatur pertemuan untuk membahas poin-poin. Jika persyaratannya sangat jelas sehingga daftar tetap kosong: tidak ada pertemuan (tapi saya kira tidak akan). Jika Anda mulai menerapkan asumsi yang salah ke dalam perangkat lunak Anda, Anda akan memiliki banyak usaha untuk mengubahnya nanti.

— Doc Brown

3

@randomA: Anda dapat membuat klien Anda senang untuk beberapa waktu dengan tidak meminta apa pun, dan kemudian, ketika Anda memberikan hal terakhir, membuatnya sangat tidak senang karena ternyata Anda melewatkan persyaratan begitu banyak sehingga Anda dapat membuang program Anda dan memulai dari awal (di mana klien tidak akan mau membayar). Atau Anda membuatnya sedikit tetapi tidak senang mondar-mandir beberapa waktu dengan memintanya cukup di antara untuk membangun program yang benar, tetapi sangat senang pada akhirnya ketika program benar-benar akan melakukan apa yang diinginkannya dan ia mendapatkan apa yang telah ia bayar. Pilih pilihan Anda.

— Doc Brown

16

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).

— Doc Brown
sumber

3

Melakukan "air terjun" dengan benar tidak berarti "merencanakan segalanya", itu tidak berarti tidak menganalisis hal-hal.

— Giorgio

1

@Iorgio: melakukan "air terjun" dengan benar berarti tidak menerapkannya ketika persyaratan "sedikit kabur" dan "perangkat lunaknya cukup rumit sehingga ada detail, masalah yang tidak akan saya kenali sampai saya benar-benar menghadapinya" (mengutip dari pertanyaan asli).

— Doc Brown

6

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.

— SendokNZ
sumber

Saya tidak mengerti bagaimana A) memecahkan masalah yang Anda sebutkan di awal jawaban Anda: bagaimana Anda tahu jika beberapa cerita terakhir akan memakan waktu beberapa hari atau dua tahun? Anda hanya benar-benar tahu kapan Anda benar-benar melakukannya, bukan?

— Giorgio

1

Anda benar, tetapi perbedaannya adalah Anda memiliki produk yang dapat dirilis dalam kondisi saat ini, daripada 90% perangkat lunak kereta yang tidak dapat dirilis. Anda juga memiliki bukti empiris tentang berapa lama waktu yang Anda perlukan untuk menghadirkan fitur-fitur yang dapat dirilis, dan perkiraan Anda tentang pekerjaan yang tersisa yang cenderung memberikan lebih banyak kepercayaan diri bahwa tidak ada bukti bahwa apa pun yang telah Anda lakukan benar-benar berfungsi.

— SendokNZ

Itu tergantung: jika semua fitur yang direncanakan adalah penting, maka produk dengan fitur 90% tidak dapat digunakan / tidak dapat dilepaskan: hanya dapat digunakan untuk memberikan demo tentang apa yang sudah ada. Dalam pengalaman saya tangkas tidak disukai dalam semua situasi: ada proyek yang tangkas lebih cocok (mengubah persyaratan, kecil, mandiri dan fitur independen) dan proyek yang tidak (persyaratan stabil, kompleks dan / atau misi penting fitur).

— Giorgio

Saya setuju - kurang memberikan dalam kedua kasus tersebut, tetapi sebagai pemangku kepentingan, Anda dapat mempercayai tim yang memproduksi versi perangkat lunak Anda yang berfungsi penuh untuk bermain dengan tempat semuanya berfungsi tetapi beberapa fitur tidak ada, atau tim yang memberi Anda bug tumpukan tumpukan kode sumber yang secara teoritis memiliki semua fitur Anda tetapi banyak crash dan memiliki banyak perilaku yang tidak terduga? Saya tahu mana yang lebih saya percayai.

— SendokNZ

Tentu saja saya akan mempercayai tim pertama, tetapi saya tidak setuju bahwa menggunakan metode non-gesit Anda selalu berakhir dengan "tumpukan kode sumber bug yang secara teoritis memiliki semua fitur Anda tetapi banyak crash dan memiliki banyak perilaku tak terduga" . Setidaknya, ini belum pengalaman saya sampai sekarang.

— Giorgio

3

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.

— Bart van Ingen Schenau
sumber

1

Saya sering bertanya-tanya apakah klien yang tidak ingin terlibat terlalu banyak memiliki kebutuhan bisnis yang nyata. Saya sering melihat ini terjadi dalam proyek-proyek di mana aplikasi yang ada 'diterjemahkan' ke teknologi baru. Anda dapat memeriksa kode jika Anda memiliki pertanyaan apa yang mereka katakan kepada Anda. Tidak ada yang menunggu remake.

— user99561

@ user99561: Anda benar, tetapi dalam situasi seperti itu persyaratannya sebagian besar tidak kabur, mereka sangat jelas - selama program baru akan berperilaku persis seperti yang lama. Dalam situasi seperti itu pendekatan "gesit" memang tidak diperlukan. Pendekatan iteratif, berbasis batu-mil (tanpa banyak interaksi pelanggan) akan cukup.

— Doc Brown

Jelas? Semoga berhasil mengetahui apa sebenarnya perilaku itu dan apa pengecualiannya. Sebagian besar waktu bahkan pebisnis tidak mengerti apa yang terjadi dalam aplikasi. Saran saya: lari secepat mungkin dari proyek-proyek ini. Karena Anda tahu kapan proyek dimulai, tetapi Anda tidak tahu kapan bug terakhir diposting karena aplikasi berperilaku berbeda akan diperbaiki.

— user99561

0

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.

— Silviu Burcea
sumber

Saya baru saja menambahkan hasil edit untuk menjelaskan. Klien menunjukkan masalah dengan detail yang cukup dan daftar keinginan yang jelas dan ingin tidak bermasalah lebih lanjut. Jadi asumsikan, tidak ada umpan balik klien hingga mendekati akhir saat Anda dapat demo prototipe yang berfungsi.

— InformedA