Manajemen jamur

Manajemen jamur

   Juga dikenal sebagai Pseudo-Analisis dan Pengembangan Blind, Manajemen jamur sering digambarkan oleh frasa ini: ". Perlu pengembang Anda dalam gelap dan memberi mereka makan pupuk"

   Seorang arsitek sistem yang berpengalaman baru ini menyatakan, "Jangan biarkan pengembang perangkat lunak berbicara dengan pengguna akhir." Selanjutnya, tanpa partisipasi pengguna akhir, "Risiko adalah bahwa Anda berakhir membangun sistem yang salah."

Antipattern Masalah

   Dalam beberapa kalangan arsitektur dan manajemen, ada kebijakan yang jelas untuk mengisolasi pengembang sistem dari pengguna akhir sistem. Persyaratan yang lulus kedua tangan melalui perantara, termasuk arsitek, manajer, atau persyaratan analis. Manajemen jamur mengasumsikan bahwa persyaratan dipahami dengan baik oleh kedua pengguna akhir dan proyek perangkat lunak di awal proyek. Hal ini diasumsikan bahwa persyaratan stabil.

Ada beberapa asumsi keliru dalam Manajemen Jamur:

Pada kenyataannya, kebutuhan sering berubah dan drive sekitar 30 persen dari biaya pembangunan. Dalam proyek Manajemen Jamur, perubahan ini tidak ditemukan sampai pengiriman sistem. Penerimaan pengguna selalu ada risiko yang signifikan, yang menjadi penting dalam Manajemen jamur.

Implikasi dokumen persyaratan jarang dipahami oleh pengguna akhir, yang dapat lebih mudah memvisualisasikan arti dari persyaratan ketika mereka mengalami antarmuka pengguna prototipe. Prototipe memungkinkan pengguna akhir untuk mengartikulasikan kebutuhan mereka berbeda dengan karakteristik prototipe.

   Ketika pengembang tidak memahami persyaratan keseluruhan produk, mereka jarang memahami komponen interaksi yang diperlukan dan interface yang diperlukan. Karena itu, keputusan desain yang buruk dibuat dan sering mengakibatkan komponen cerobong asap dengan antarmuka yang lemah yang tidak memenuhi persyaratan fungsional.

Manajemen jamur mempengaruhi pengembang dengan menciptakan lingkungan ketidakpastian. Seringkali, persyaratan didokumentasikan tidak cukup rinci, dan tidak ada cara yang efektif untuk mendapatkan klarifikasi.

Dalam rangka untuk melakukan pekerjaan mereka, pengembang harus membuat asumsi, yang dapat menyebabkan pseudo-analisis, yaitu, analisis berorientasi objek yang terjadi tanpa partisipasi pengguna akhir. Beberapa proyek Manajemen Mushroom menghilangkan analisis sama sekali dan langsung melanjutkan dari persyaratan tingkat tinggi untuk merancang dan coding.

Solusi refactored

   Pengembangan risiko-didorong adalah proses pengembangan spiral berdasarkan prototyping dan umpan balik pengguna. Pengembangan risiko-didorong adalah spesialisasi dari proses pembangunan berulang-tambahan (lihat Analisis Paralysis antipattern). Dalam hal ini, setiap kenaikan adalah iterasi eksternal.

   Dengan kata lain, setiap peningkatan proyek termasuk ekstensi untuk fungsi user-interface. Kenaikan termasuk percobaan user-interface, termasuk pengalaman tangan-on. Percobaan menilai penerimaan dan kegunaan masing-masing ekstensi, dan hasil percobaan mempengaruhi arah proyek melalui pemilihan iterasi berikutnya.

Karena proyek sering menilai penerimaan pengguna, dan menggunakan masukan ini untuk mempengaruhi perangkat lunak, risiko pengguna penolakan diminimalkan.

Pengembangan risiko-driven yang paling berlaku untuk aplikasi, yang-user-interface intensif dan memerlukan dukungan infrastruktur yang relatif sederhana. Aplikasi komputer pribadi yang tergantung pada file lokal untuk infrastruktur storage adalah kandidat kuat untuk pengembangan risiko-driven.

Variasi

   Termasuk ahli domain pada tim pengembangan adalah cara yang sangat efektif untuk memiliki masukan domain pada keputusan proyek. Setiap kali ada pertanyaan-domain tertentu, anggota tim memiliki keahlian di tangan. Risiko penting dalam pendekatan ini, bagaimanapun, adalah bahwa ahli domain hanya mewakili satu pendapat dari komunitas domain."