Apakah metodologi pengembangan perangkat lunak Waterfall masih layak?

14

Dalam pengalaman saya, sepertinya model Waterfall telah terbukti terlalu tidak fleksibel dan tidak responsif terhadap perubahan persyaratan untuk dianggap sebagai metode yang layak di dunia modern pengembangan perangkat lunak. Pertumbuhan dan rekam jejak yang terbukti lebih gesit, metode berulang tampaknya menunjukkan bahwa tidak ada alasan mengapa seseorang harus mengikuti proses blok kaku yang mengasumsikan sedikit atau tidak ada perubahan dari awal proyek ke pengiriman produk.

Apakah metodologi pengembangan air terjun masih layak untuk memberikan sistem perangkat lunak, sehubungan dengan waktu, biaya, dan kualitas?

development-methodologies waterfall

— CFL_Jeff
sumber

3

Jadi, jika Anda belum mengalaminya, dan tidak ingin mengalaminya, itu membuatnya mati? Bukannya saya menganjurkan untuk itu, tapi itu sepertinya premis yang aneh.

— thursdaysgeek

9

Itu belum mati. Hanya saja bukan tren / tren saat ini / "dapat diterima"

— Paul

2

@GrandmasterB Dengan "mati" yang saya maksudkan "cukup terbukti bukan cara terbaik"

— CFL_Jeff

3

@Rachel Tolong jangan terus membaca tag pengembangan perangkat lunak. Ini adalah tag meta yang dijadwalkan untuk dibersihkan di masa mendatang .

— Thomas Owens

3

Itu tidak mati, itu hanya istirahat. Pining for fjords. ;)

— FrustratedWithFormsDesigner

20

Model air terjun yang Anda maksud tidak pernah dimaksudkan sebagai model proses yang digunakan pada proyek nyata. Alih-alih, itu adalah stroberi. Ini mengidentifikasi fase kunci dan kegiatan yang ada dalam proyek perangkat lunak dan aliran paling mendasar di antara mereka. Penyederhanaan yang berlebihan tentang cara mengembangkan perangkat lunak adalah cacat, dan bahkan disajikan demikian.

Dari artikel Wikipedia:

Deskripsi formal pertama dari model air terjun sering dikutip sebagai artikel tahun 1970 oleh Winston W. Royce, meskipun Royce tidak menggunakan istilah "air terjun" dalam artikel ini. Royce menyajikan model ini sebagai contoh model cacat yang tidak bekerja.

Makalah yang dibahas berjudul Mengelola Pengembangan Sistem Perangkat Lunak Besar . Di dalamnya, Royce menghadirkan model itu di halaman kedua. Namun, teks tepat di bawah representasi bergambar melanjutkan dengan membaca:

Saya percaya pada konsep ini, tetapi implementasi yang dijelaskan di atas berisiko dan mengundang kegagalan.

Dia mengikuti ini dengan diskusi tentang masalah dengan pengujian setelah "penyelesaian" dari fase pengembangan, dan bagaimana kegagalan di sini dapat menyebabkan redesain utama dan perubahan kode, dan bagaimana ini dapat menyebabkan overruns besar dalam biaya dan jadwal. Di seluruh makalah, ia menyaring model asli menjadi model yang memang layak untuk sebuah proyek. Pada akhirnya, ia berakhir dengan model yang memperkenalkan prototipe, interaksi pelanggan, dan penyempurnaan artefak - ide yang akhirnya akan menjadi penting bagi gerakan gesit yang dimulai pada akhir 1990-an dan awal 2000-an.

Untuk menjawab pertanyaan Anda: Air Terjun yang Anda tanyakan bukanlah, dan tidak pernah, metode yang layak untuk mengirimkan proyek perangkat lunak dengan kualitas yang masuk akal dalam waktu dan anggaran. Namun, ada metodologi lain yang digerakkan oleh rencana yang bertolak belakang dengan kelincahan yang dapat dan bekerja pada proyek.

— Thomas Owens
sumber

Banyak artikel tentang gesit menggunakan "metode tradisional" untuk menyebutkan air terjun, dan air terjun tersirat itu digunakan pada abad ke-20 sepanjang waktu. Sekarang saya tahu saya salah.

— Ming-Tang

@ThomasOwens Bisakah Anda mengutip beberapa dari ini other plan-driven methodologies that lie opposite of agile that can and do work on project?

— Laiv

@Laiv Model Spiral cenderung lebih didorong oleh rencana daripada pendekatan gesit - Anda melakukan lebih banyak perencanaan dan analisis sebelum mengembangkan perangkat lunak yang berfungsi. Cap Gemini SDM adalah contoh lain, meskipun revisi kemudian menambahkan siklus rencana-lakukan-periksa-tindakan, tetapi sekali lagi ia memiliki sejumlah perencanaan awal dan analisis yang memadai yang dimasukkan ke dalam proses. Banyak yang kemungkinan merupakan variasi dari air terjun, tetapi dengan semacam umpan balik bawaan. Jika Anda memiliki pemahaman domain yang kuat dan persyaratan yang relatif stabil, Anda mungkin tidak memerlukan loop umpan balik ketat dari metode tangkas dan dapat merencanakan dengan lebih baik.

— Thomas Owens

9

Orang tidak menggunakan model air terjun buku teks dan mungkin tidak pernah melakukannya.

Ini adalah konstruksi teoretis ideal yang bertujuan agar Anda memikirkan langkah-langkah dalam pengembangan sistem. Poin utamanya adalah Anda ingin perubahan besar terjadi sedini mungkin, karena Anda tidak akan pernah punya waktu atau uang untuk membuat perubahan besar begitu ada banyak kode yang dibuat.

Terlepas dari kenyataan bahwa itu lebih merupakan cara berpikir daripada proses, masih sangat banyak cara - mungkin sebagian besar organisasi pergi tentang membangun perangkat lunak (atau rumah, atau kapal selam, atau apa pun ...).

Di dunia nyata, Anda tidak memiliki cut-off yang benar-benar ketat antara fase, dan Anda kadang-kadang kembali ke fase sebelumnya untuk sub-proyek kecil. Apa yang metodologi katakan kepada Anda bukanlah bahwa "hal-hal ini tidak diperbolehkan". Apa yang dikatakannya adalah "hal-hal ini menghabiskan uang dan / atau waktu" - jadi cobalah untuk menghindarinya di masa depan.

Semuanya baik dan bagus untuk Agile Snobs (TM) untuk melihat ke bawah ke arah pengembang "kuno" dan metodologi air terjun mereka yang aneh dan tidak bisa dijalankan, tetapi faktanya adalah bahwa Agile juga bukan obat mujarab. Beberapa proyek tidak dapat dibangun menggunakan Agile dan banyak tim yang berpikir bahwa mereka Agile sebenarnya hanya ceroboh dan tidak terorganisir.

Metodologi bukan itu intinya. Intinya adalah untuk berpikir tentang apa yang Anda lakukan dan mengapa Anda melakukannya dengan cara itu - dan untuk mendapatkan nilai maksimal kepada pelanggan dalam waktu singkat yang masuk akal.

— Joel Brown
sumber

Anda jelas memiliki pengalaman "orang" yang sangat berbeda dengan saya. Selama 30 tahun terakhir, saya telah bekerja dalam suksesi perusahaan yang semuanya menggunakan (dan masih menggunakan) metode air terjun buku teks. Tidak mengherankan, itu tidak berhasil.

— David Arno

@ DavidArno Yang paling dekat yang pernah saya lihat "di alam liar" dengan buku teks Waterfall dalam konteks perangkat lunak adalah dalam perangkat lunak pembangunan perusahaan yang mengendalikan perpindahan kereta. Motivasi di sana adalah tidak ada seseorang yang benar-benar mati akibat bug. Saya membayangkan itu bisa juga terjadi di tempat-tempat melakukan pemrograman tertanam di mana Anda tidak ingin membangun jutaan sesuatu hanya untuk mengetahui itu gagal karena bug. Saya cenderung berpikir bahwa bahkan dalam kasus-kasus ini, Waterfall lebih dari ideal daripada praktik yang dicapai dengan sempurna. Seperti yang Anda tunjukkan - hasilnya pasti gagal pada tingkat tertentu.

— Joel Brown

8

Proses air terjun mitos yang paling sering dibandingkan dengan gesit tidak pernah ada dan karena itu tidak dapat dianggap mati. Proses air terjun nyata masih hidup dan sehat, dan unggul dalam memberikan tepat waktu dengan perangkat lunak anggaran yang memenuhi harapan pengguna.

— Ryathal
sumber

5

Tidak yakin apa perbedaannya antara proses air terjun "mitos" dan yang "nyata". Bisakah Anda jelaskan ini?

— CFL_Jeff

6

Seringkali proses Waterfall dijelaskan oleh para pendukung Agile adalah strawman en.wikipedia.org/wiki/Straw_man

— jfrankcarr

11

Ini akan menjadi jawaban yang lebih baik jika Anda menjelaskan dalam jawaban Anda bagaimana pendukung Agile membuat proses manusia jerami yang tidak akan berhasil, tetapi tidak benar-benar Air Terjun.

— Robert Harvey

4

-1 untuk pernyataan, "Mereka unggul dalam pengiriman ..." Yang benar adalah bahwa itu adalah pembasuhan. Seperti semua metodologi perangkat lunak, kadang-kadang berfungsi, kadang tidak. Saya telah melihat keduanya dalam hal metode air terjun sejati.

— riwalk

2

Saya harus mengatakan, [rujukan?] Pada jawaban ini. Dan -1 sampai ini disediakan. Terutama "unggul dalam memberikan tepat waktu pada perangkat lunak anggaran yang memenuhi harapan pengguna" Laporan CHAOS tidak setuju dengan Anda.

— Malfist

5

Mungkin cara yang lebih baik untuk menanyakan apa yang Anda maksudkan adalah, "kapan kurang iteratif dan lebih formal lebih baik?"

Ada situasi di mana hal ini terjadi:

Ketika persyaratan tidak akan berubah.
Ketika memenuhi persyaratan baru kurang penting daripada memukul 100% dari yang asli.
Ketika semua komponen teknologi sudah matang dan dipahami dengan baik.

Dalam arti tertentu Anda dapat mengambil kebalikan dari apa yang mungkin mendorong Anda untuk menjadi gesit.

Sangat sedikit teknik yang berlaku di mana-mana. Sangat sedikit yang tidak digunakan.

— MathAttack
sumber

1

Apa yang ada di dunia "kurang menarik" atau "lebih buruk"?

— Aaronaught

1

@Aaronaught - "kurang iteratif" dan "lebih formal" diketik dengan jempol tebal pada iPhone. :-)

— MathAttack

1

Saya belum pernah bekerja di proyek yang memenuhi salah satu dari prasyarat ini. :)

— Theodor

3

Ya itu sangat hidup, meskipun hari ini " model V " yang lebih umum digunakan.

Dalam kedua kasus tersebut, masalah yang dimiliki Agile adalah bahwa solusinya hampir tidak pernah berakhir, pelanggan dapat terus meminta perubahan dan pengembangan akan terus menyelesaikannya secara iteratif. Untuk proyek yang didasarkan pada biaya waktu dan bahan, ini bekerja dengan sangat baik. Untuk proyek yang memiliki biaya tetap, tidak.

Untuk proyek-proyek dengan biaya tetap ini, pelanggan hampir selalu mengharapkan tonggak yang telah ditentukan untuk menunjukkan kemajuan, namun, ini lebih merupakan variasi tertulis formal daripada kode kerja. Untuk pelanggan seperti ini, spesifikasi tertulis menjadi proyek, di mana pengembangan perangkat lunak adalah pertimbangan sekunder (karena mereka menganggap, jika Anda memiliki proyek yang terdefinisi dengan baik, perangkat lunak harus mudah dikembangkan). Perusahaan-perusahaan ini juga merupakan perusahaan yang banyak menggunakan sumber daya pengembangan murah dan outsourcing.

Jadi, jika Anda memiliki pot uang atau waktu yang tetap, jangan berharap persyaratan untuk berubah atau tidak diizinkan untuk mengubah persyaratan apa pun, dan diharapkan untuk menyediakan serangkaian dokumentasi tertulis yang kuat, maka model air terjun adalah satu-satunya yang masuk akal.

Agile dapat diperkenalkan di tengah-tengah proyek ini untuk melakukan pengembangan, tetapi Anda masih memiliki fase ramp-up di mana spesifikasi dibuat dari persyaratan, dan fase ramp down di mana perangkat lunak diinstal dan diuji di tempat. Agile tidak menanggapi dengan baik kasus-kasus ini.

— gbjbaanb
sumber

Agile dapat bekerja dengan sangat baik dengan pot uang atau waktu yang tetap, asalkan ruang lingkupnya juga tidak tetap. Poin lainnya adalah bahwa pelanggan / kontraktor dapat memilih jenis kontrak (T&M, biaya tetap, atau sesuatu di antaranya) agar konsisten dengan metodologi pengembangan tertentu (gesit atau air terjun) - tidak ditentukan sebelumnya.

— DNA

1

Untuk siapa? Sebagian besar manajer yang pernah saya tangani masih menggunakan Proses Pengembangan Perangkat Lunak Waterfall untuk penjadwalan, dan tingkat atas sepertinya menyukainya karena mudah penjadwalan.

Secara praktis, sangat sedikit pengembang yang saya tahu percaya ini berfungsi atau bahkan valid.

— jerny
sumber