Apakah ada alternatif yang layak untuk metodologi pengembangan gesit?

47

Dua metodologi pengembangan perangkat lunak yang dominan adalah air terjun dan lincah. Ketika membahas keduanya, seringkali ada banyak fokus pada praktik-praktik khusus yang membedakan mereka (pair programming, TDD, dll. Vs. spec fungsional, desain besar di muka, dll.)

Tetapi perbedaan sebenarnya jauh lebih dalam, dalam hal praktik-praktik ini berasal dari filsafat.

Waterfall mengatakan: Perubahan itu mahal, jadi harus diminimalkan.
Agile berkata: Perubahan tidak bisa dihindari, jadi buat perubahan murah.

Pertanyaan saya adalah, terlepas dari apa yang Anda pikirkan tentang TDD atau spesifikasi fungsional, apakah metodologi pengembangan air terjun benar-benar layak?

Adakah yang benar-benar berpikir bahwa meminimalkan perubahan pada perangkat lunak adalah pilihan yang layak bagi mereka yang ingin memberikan perangkat lunak yang berharga? Atau apakah pertanyaannya benar-benar tentang praktik seperti apa yang paling berhasil dalam situasi kita untuk mengelola perubahan yang tak terhindarkan?

agile  development-methodologies  waterfall 
— Eric Wilson
sumber
1
pertanyaan yang menarik. menantikan jawaban.
— DevSolo
1
— Peter Boughton
3
@FarmBoy - Pertanyaan bagus. Saya memandang filosofi lincah sedikit berbeda. Saya akan menuliskannya sebagai "Agile berkata: Perubahan tidak bisa dihindari, jadi buatlah murah untuk menentukan biaya perubahan." Perubahan masih bisa sangat mahal, tetapi dengan gesit Anda bisa mengetahuinya dengan cepat dan murah sehingga kami selalu tahu biaya perubahan. Mengutipnya dengan cara lain membuat orang berpikir bahwa karena mereka melakukan perubahan gesit akan menjadi murah. Beberapa perubahan harganya sangat mahal, apa pun prosesnya.
— Mike Two
1
@Yannis Rizos: mengapa Anda menutup pertanyaan menarik ini sendirian, tanpa satu suara komunitas?
1
@ Pierre303 karena pertanyaan ini yang mana diskusi di sini mengangkat pertanyaan ini.
— Ryathal

Jawaban:

59

Tentu saja air terjun layak. Itu membawa kita ke bulan!

Dan itu adalah pelatih yang gesit berbicara di sini!

Kecuali Anda dapat dengan jelas mengidentifikasi masalah yang terkait dengan cara Anda mengelola proyek Anda, tidak ada alasan yang sah untuk berubah.

Sebagai alternatif metodologi Agile dan Waterfall , saya akan menyarankan metodologi ANDA . Diadaptasi untuk bisnis spesifik Anda, tim spesifik Anda, produk Anda, cara Anda bekerja, budaya perusahaan Anda ... Itu sebabnya Scrum disebut kerangka kerja sederhana alih-alih metodologi.

Ingin menerapkan metodologi karena seseorang di blog yang Anda sukai membicarakannya sama bodohnya dengan membiarkan masalah terjadi tanpa melakukan apa pun.

10
Memberi +1 pada metodologi ANDA, pelatih Agile berikutnya yang memberi tahu saya SCRUM adalah satu-satunya cara mendapatkan booting di bagian belakang;)
— Martijn Verburg
1
@karianna: Saya secara khusus melakukan SCRUM, tetapi kadang-kadang, itu tidak tepat. Di sisi lain, saya juga melihat tim mencoba menjual SCRUM kepada bos mereka dengan berpikir itu akan menyelesaikan masalah mereka. Mereka gagal karena masalahnya bukan bos mereka atau PM mereka. Tidak ada aturan tunggal. Setiap kasus solusinya. Dan ya, sebagian besar masalah organisasi dapat diselesaikan dengan teknik lincah, tetapi lincah bukanlah peluru perak.
5
Bukan hanya bulan. Pesawat ulang-alik memiliki ~ 1M baris kode C dalam sistem yang tertanam. Lebih dari ~ 30 tahun mereka hanya memiliki 2 bug yang membuatnya menjadi build produksi.
— Dan Neely
2
Waterfall juga MEMBUNUH tiga astronot pertama. Desakan untuk menggunakan program Apollo ini sebagai anak poster untuk Waterfall tidak tahu apa-apa. Waterfall juga disebut-sebut bertanggung jawab atas kedua program tersebut sebagai kacamata keuangan lengkap, dan Shuttle menjadi "ferrari ruang" yang over-engineer, rapuh, mahal ketika spek aslinya adalah untuk "truk luar angkasa". Saya cukup yakin SpaceX akan tidak setuju tentang Waterfall.
4
@Dan Benar-benar tingkat kualitas tinggi dari perangkat lunak antar-jemput tidak murah. Rupanya harga itu dalam ukuran $ 1000 per baris kode.
21

Pertama, saya akan tidak setuju dengan pernyataan Anda:

Waterfall mengatakan: Perubahan itu mahal, jadi harus diminimalkan.
Agile berkata: Perubahan tidak bisa dihindari, jadi buat perubahan murah.

Interpretasi saya adalah:

Waterfall berkata: Pelanggan tahu apa yang mereka inginkan.
Agile berkata: Pelanggan tidak tahu apa yang mereka inginkan sehingga kami harus membuat beberapa versi berbeda.

Implementasi terbaik "air terjun" yang pernah saya lihat adalah proyek integrasi besar dengan pelanggan finansial yang sangat besar dan ada sekitar 40+ sub proyek yang terlibat. Paket desktop dan situs web yang kami sediakan hanyalah 1 dari 40 sub proyek tersebut. Sementara saya pikir mereka meniup uang orang lain agak berlebihan, mereka memiliki barang-barang mereka bersama dan membuat 40+ kapal yang berbeda semuanya bergerak bersama dalam formasi. Proyek ini ditayangkan pada tanggal target (target bergerak sekali selama proyek) dan sementara saya pikir mereka bisa melakukannya dengan lebih hemat dan gesit, itu dilakukan tepat waktu dan spek. Jadwal go-live night adalah sekitar 100 halaman dan sekitar 40 halaman adalah detail kontak panik darurat dari semua jenis orang yang terlibat. Saya sangat terkesan dengan klien ini.

Atau, Anda bisa melakukan apa yang kita lakukan, yang berlari-lari dan melakukan apa laporan pengaduan / bug terbaru adalah, dan panggilan yang tangkas.

— Tangurena
sumber
8
Sesuai Agile Dilbert: is.gd/lDoQgb
— Peter K.
11
Ini lebih seperti "Air terjun berkata: Pelanggan tidak tahu apa yang mereka inginkan jadi mari kita duduk, membicarakannya dan menyetujui apa yang mereka inginkan sebelum kita mulai
— meretasnya
+1: Jawaban yang sangat bagus. Saya pikir komunitas gesit memiliki satu masalah mendasar: gesit baik dalam konteks tertentu untuk kelas proyek dan pelanggan tertentu, tetapi mereka gagal melihat bahwa ada proyek di mana persyaratannya tidak berubah sehingga pendekatan yang lebih cepat dan lebih terstruktur adalah pilihan yang lebih baik. . Saya pikir bahwa komunitas yang gesit harus mencoba untuk secara realistis mengidentifikasi area di mana pendekatan mereka merupakan pilihan yang lebih baik (saya pikir area tersebut ada) dan tidak mencoba mendorongnya sebagai solusi umum, karena tidak.
— Giorgio
6
@scrwtp - dan Agile lebih seperti "Pelanggan saya tidak tahu apa yang mereka inginkan, dan tidak bisa / tidak akan berbicara dan memikirkannya, dan mereka berubah pikiran setiap 5 menit. Saya harus mendorong sesuatu di wajah mereka untuk mendapatkan jawaban yang bermakna ". Wow. Kedengarannya sangat disayangkan ketika saya menuliskannya.
— Michael Kohne
1
@ scrwtp: Saya pikir pertanyaan sejuta dolar adalah: apakah "keyakinan" bahwa Anda dapat "duduk dan membicarakannya dan setuju" layak? Jawabannya adalah: itu tergantung, kan? Itu tergantung pada sejumlah variabel: seberapa besar proyeknya? Apakah kita TAHU seberapa besar itu? Berapa lama pelanggan harus "duduk" bersama kami? Kami telah mencoba selama beberapa dekade untuk menghubungkan pengembangan perangkat lunak dengan konstruksi, yang hampir 100% bersifat preskriptif. Pengembangan perangkat lunak berada di suatu tempat di antara "sepenuhnya reaksioner" dan "100% preskriptif". Di sebagian besar toko, lebih dekat ke "sepenuhnya reaksioner", maka adopsi tangkas.
— Calphool
21

Anda mulai dengan mengatakan:

Dua filosofi pengembangan perangkat lunak yang dominan adalah air terjun dan lincah.

Ini salah. Dikotomi ini dibangun oleh komunitas yang gesit untuk menciptakan lawan yang dapat memposisikan diri. Sebelum tangkas dalam mode, orang-orang biasa berbicara tentang berbagai pendekatan berbeda untuk membangun perangkat lunak. Mereka masih ada sampai sekarang, tetapi entah bagaimana mereka sering disatukan menjadi kekacauan besar yang disebut "air terjun" oleh para pendukung lincah.

Saya telah menggunakan OPEN / Metis dan variannya selama lebih dari 10 tahun dengan sukses besar. Jelas tidak gesit, dan jelas bukan air terjun. Ribuan pengembang membuat perangkat lunak yang sangat kompleks untuk pesawat terbang, sistem kritis kehidupan, perbankan, dll. Menggunakan metode yang tidak gesit setiap hari.

Jadi ya, tentu saja ada alternatif untuk gesit.

— CesarGon
sumber
6
Saya tidak dapat dengan cepat memahami apa OPEN / Metis dari tautan itu. (Biasanya Anda tidak perlu mengunduh metodologi.) Pertanyaan saya adalah: apakah filosofi itu, khususnya dalam menghadapi perubahan? Apakah ia berupaya meminimalkan perubahan, atau mengurangi biaya perubahan? Ingatlah bahwa pertanyaan saya adalah tentang filsafat lincah, bukan tentang praktik lincah.
— Eric Wilson
OPEN / Metis memiliki siklus hidup berulang yang membangun sistem secara bertahap. Perubahan diakui sebagai sesuatu yang tidak hanya terjadi, tetapi sesuatu yang hebat ketika itu terjadi, karena tujuan utama pengembangan sistem informasi adalah untuk melakukan beberapa perubahan. Namun, biaya perubahan dikendalikan dan dikelola melalui siklus hidup yang sesuai dan praktik terkait.
— CesarGon
1
Mengenai komentar Anda tentang "mengunduh metodologi", well ... Anda tidak mengunduh metodologi, saya setuju. Anda mengunduh dokumen yang menjelaskan metodologi. Kalau tidak, bagaimana Anda belajar tentang mereka? Lihatlah berjuta buku yang menggambarkan XP, Scrum, dll.
— CesarGon
1
10

Ya, berbagai teknik pengembangan perangkat lunak semuanya layak tergantung pada domain masalah Anda. Ini "Kuda untuk Kursus".

Misalnya, Anda sedang menulis perangkat lunak untuk mengendalikan pembangkit listrik tenaga nuklir atau untuk menggerakkan pesawat ulang-alik NASA. Jenis domain masalah ini mungkin lebih cocok untuk pendekatan air terjun (atau bahkan lebih ketat), Anda ingin menyelesaikan semua masalah di depan jika memungkinkan (atau BOOM!).

Membangun web term marketing 2.0 / 3.0 / buzzy terbaru dari UI? Agile adalah cara yang jauh lebih baik (Anda membutuhkan umpan balik dan perubahan cepat).

Ada apa yang saya sebut prinsip-prinsip pengerjaan perangkat lunak yang masih bisa diterapkan tidak peduli apakah metodologi itu misalnya:

  • Kontrol sumber
  • membangun dan CI
  • pemrograman pasangan
  • TDD
  • Saya memberi ^% $$ &

dan lainnya.

Apa pun yang Anda lakukan, jangan dengarkan para fanatik di kedua sisi persamaan, lakukan apa yang tepat untuk Anda, tim Anda, dan domain masalah Anda.

— Martijn Verburg
sumber
Air terjun berfungsi jika Anda mampu membelinya. Seseorang di atas mengklaim bahwa biaya perangkat lunak proyek bulan NASA kira-kira $ 1000 per baris kode. Kebanyakan toko membutuhkan sekitar $ 1–10 per baris kode dan lincah lebih baik untuk situasi seperti itu. Namun, saya tidak berpura-pura bahwa gesit memberikan kualitas yang lebih baik secara keseluruhan. Pada dasarnya bermuara pada Anda dapat membayar banyak uang untuk memastikan perangkat lunak benar atau lebih murah untuk mengetahui solusinya setelah Anda mengetahui bahwa perangkat lunak tidak benar.
— Mikko Rantalainen
2

Masalahnya berasal dari kompleksitas perangkat lunak. Air terjun sangat cocok untuk hal-hal seperti pembangunan jembatan dan pengaspalan karena fisika tidak pernah berubah. Tentu, pada titik tertentu kami akan mengembangkan aspal baru tetapi tidak akan merevolusi cara jalan dibangun. Baja dalam suspensi jembatan adalah ukuran yang tepat, atau tidak. Anda tidak dapat membatalkan atau mematikan proyek konstruksi nyata seperti yang Anda bisa lakukan dengan perangkat lunak.

Perubahan perangkat lunak. Perangkat lunak berubah dengan cepat. Hukum Moore menyatakan bahwa jumlah transistor pada sebuah chip berlipat ganda setiap 18-24 bulan. Secara wajar, jumlah baris kode dalam suatu program juga berlipat ganda. Kompleksitas di antara baris-baris kode karenanya meningkat dengan bigO sesuatu seperti 2 ^ (2t).

Perangkat lunak berubah dengan cepat, dan kompleksitas meningkat secara eksponensial dengannya.

Saat mengendalikan biaya perangkat lunak, Anda ingin mengendalikan faktor eksponensial , bukan hanya multiplikatif atau tambahan. Mengubah kode meningkatkan kompleksitas (dan menjadi kompleks secara eksponensial saat proyek berjalan) dengan cara yang eksponensial.

Perubahan tidak bisa dihindari. Sifat pemrograman memperluas bahasa dengan kelas dan metode kustom, sehingga mengubah bahasa itu sendiri. Anda tidak dapat melakukan itu dalam disiplin teknik apa pun (seperti membangun jalan. Anda tidak menciptakan trotoar baru hanya untuk membuka jalan di kansas di atas california).

Metode agile juga memberi Anda platform untuk menangani rilis dan perbaikan bug di masa mendatang. Anda telah memiliki alat manajemen, proses, karyawan terlatih, untuk mengembangkan perangkat lunak berversi. Dengan metode air terjun, Anda perlu melatih kembali tim Anda untuk menangani perbaikan bug kecil sekalipun.

Lagi pula, 2 sen saya.

— Stephen Furlani
sumber
2
Ada banyak aspek desain perangkat lunak yang sama absolutnya dengan hukum fisika. Agile adalah alat seperti air terjun atau metodologi lainnya, dan seperti yang diposkan orang lain, ada banyak kasus bisnis yang tidak masuk akal. Saya akan terkejut jika saya melihat Anda dalam antrean untuk naik pesawat di mana Boeing mengatakan mereka berada di tengah-tengah proses tangkas pada perangkat lunak kontrol penerbangan dan mereka membutuhkan pelanggan untuk beralih pada apakah pesawat tidak terbang di udara tanpa alasan.
— Hounshell
Dan untuk membuat lebih banyak lubang dalam argumen Anda, ada desain jalan yang sedang direkayasa saat ini yang akan sesuai untuk jalan antara Kansas dan California, tetapi tidak antara New York dan Boston. Dan teknik baru untuk menangani aspal keluar setiap saat.
— Hounshell
2
Dan terakhir, Anda berkata, "Dengan metode air terjun, Anda perlu melatih kembali tim Anda untuk menangani bahkan perbaikan bug kecil." Itu sama sekali tidak tahu bagaimana proses air terjun bekerja. Anda harus mencoba toko air terjun yang baik sebelum Anda mengetahui bagaimana itu tidak pantas untuk setiap skenario pengembangan perangkat lunak.
— Hounshell
1
Hai Stephan, tidak semua persyaratan perangkat lunak terus berubah.
— Paul Nathan
1
Bisnis selalu berubah ; bisnis yang tidak berubah dan beradaptasi adalah bisnis yang sekarat. Waktu adalah konstan , yang tidak berinteraksi dengan perubahan dengan baik. Sebuah sistem yang memiliki filosofi yang mengakui Perubahan diharapkan dapat mengakomodasi perubahan, jika tidak, Waktu harus mengakomodasi perubahan, dan itu adalah konstanta yang tidak sesuai!
2

Untuk menjawab pertanyaan, apakah ada alternatif yang layak, untuk perangkat lunak mungkin tidak - atau belum, setidaknya dalam kasus umum. Saya pikir itu turun ke sifat perangkat lunak. Perangkat lunak, sebagai informasi, dapat digandakan secara gratis. Berbeda dengan jembatan atau rumah. Ini berarti, dengan latihan, saya bisa menjadi ahli dalam membangun rumah dan beroperasi dalam domain yang relatif sederhana. Pada titik mana mengapa tidak menggunakan pendekatan sekali pakai?

Tetapi karena perangkat lunak tidak memiliki biaya duplikasi, mengapa Anda melakukan hal yang sama dua kali? Perangkat lunak cenderung menjauh dari manufaktur. Jadi, jika semua perangkat lunak adalah pembuatan produk baru maka kami selalu beroperasi di domain yang kompleks di mana, sampai batas tertentu, kami tidak tahu apa yang kami lakukan. Atau mahal untuk diketahui di muka dan lebih murah untuk mencari tahu dengan melakukan. Dalam domain yang kompleks dan berisiko, saya ingin mencoba eksperimen, peningkatan, dan iterasi.

Pembangkit listrik tenaga nuklir dan sistem fly-by wire sering diberikan sebagai contoh perangkat lunak yang ingin Anda lakukan terjun. Tapi bukankah sistem avionik pesawat ulang-alik dikembangkan secara iteratif? Seperti apakah sistem kontrol lalu lintas udara Kanada dan AS?

Dan jika OPEN / Metis iteratif dan tambahan maka, bagi saya, sepertinya memiliki filosofi lincah bahkan jika itu tidak mengaitkan dirinya dengan praktik lincah umum lainnya.

— AlanMJackson
sumber
2
Jadi sekarang lincah mencoba untuk mengambil kredit untuk iteratif dan tambahan? Tidak peduli bahwa iteratif dan bertahap telah menjadi bagian INTI pengembangan air terjun sejak saya memulai pengembangan di '92.
— Dunk
1

Metode Waterfall tentu saja layak dan secara filosofis terdengar seperti pendekatan lain. Ingat bahwa Waterfall telah ada jauh lebih lama daripada Agile, tetapi perhatikan bahwa ini bukan argumen untuk menyatakan apakah satu metodologi lebih baik dari yang lain.

Anda menggunakan metode Waterfall ketika memiliki pemahaman yang sangat jelas tentang seluruh domain masalah dan apa yang ingin dicapai pelanggan dalam paket perangkat lunak. Anda mungkin telah mengutip harga tetap ketika mengambil kontrak, dan pelanggan Anda memahami bahwa mereka tidak dapat menyimpang dari persyaratan yang disepakati. Proses Anda secara ketat adalah proses yang mengalir melalui serangkaian proses sign-off antara berbagai tahap pengembangan, dan sering kali setiap tahap diselesaikan oleh tim yang berbeda - terkadang bahkan perusahaan yang berbeda - yang masing-masing mungkin belum tentu dalam kontak dengan yang lain. Anda sering melihat Air Terjun diterapkan dengan efek yang baik dalam proyek militer dan pemerintah ketika mereka ditenderkan kepada kontraktor luar. Di mana Waterfall dan pendekatan serupa lainnya mendapatkan reputasi buruk adalah ketika pengembang mengalami masalah, seperti estimasi yang buruk, jadwal yang direncanakan tanpa waktu darurat, atau pemahaman domain masalah yang buruk atau tidak lengkap. Masalahnya tidak pernah benar-benar kesalahan metodologi, tetapi dalam penerapannya.

Perbandingan antara Agile dan metodologi apa pun adalah salah. Agile bukanlah metodologi, ini adalah filosofi, atau mungkin akan lebih baik untuk mengatakan bahwa itu adalah istilah umum yang mewakili cara berbeda untuk melihat bagaimana Anda mengembangkan perangkat lunak. Metodologi hanyalah alat, dan karena itu nilainya akan selalu kurang dari individu dan interaksi yang merupakan inti dari apa artinya menjadi Agile .

Adakah yang benar-benar berpikir bahwa meminimalkan perubahan pada perangkat lunak adalah pilihan yang layak bagi mereka yang ingin memberikan perangkat lunak yang berharga?

Setiap peluang untuk meminimalkan perubahan bermanfaat bagi pengembang dan pelanggan. Perubahan dapat menyebabkan jadwal untuk tergelincir, atau fitur yang ditinggalkan untuk memenuhi jadwal. Begitulah cara Anda mengelola efek perubahan yang berdampak pada nilai proyek Anda.

Atau apakah pertanyaannya benar-benar tentang praktik seperti apa yang paling berhasil dalam situasi kita untuk mengelola perubahan yang tak terhindarkan?

Praktik Anda dapat membantu dalam manajemen perubahan, atau mereka dapat mengabaikan perubahan sepenuhnya. Yang penting adalah kombinasi dari praktik pengembangan Anda, dan pengelolaan hubungan Anda dengan pelanggan Anda, dan apakah hal-hal ini bekerja bersama secara efektif untuk semua pihak yang terlibat.

Kita semua yang untuk semua maksud dan tujuan Agile mengerti bahwa Anda memilih metode yang cocok untuk Anda. Jika Anda menyukai pendekatan tertentu, ikuti itu. Jika tidak sesuai dengan kebutuhan Anda, ubahlah. Bagaimana Anda membuat perangkat lunak benar-benar bermuara pada upaya untuk memanfaatkan sumber daya yang Anda miliki sebaik mungkin, dan meminimalkan praktik-praktik yang dapat mengarahkan proyek Anda menuju kegagalan, dan Anda sering menemukan bahwa Anda perlu mengubah metode Anda agar sesuai dengan proyek tertentu yang sedang dihadapi.

Ini benar-benar satu hal untuk mengatakan "Ok, jadi sekarang kita Agile", dan benar-benar lain untuk benar-benar hidup dan bekerja dengan filosofi Agile. Apakah Anda menggunakan Waterfall, Incremental, Spiral, SCRUM, XP, FDD, atau metode lainnya, pada dasarnya Anda Agile tempat Anda menghargai:

  • Individu dan interaksi atas proses dan alat
  • Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif
  • Kolaborasi pelanggan atas negosiasi kontrak
  • Menanggapi perubahan setelah mengikuti rencana

dan di mana Anda membawa alat, metode, dan pengalaman Anda bersama-sama untuk menerapkan nilai-nilai ini dengan sukses.

— S.Robins
sumber
2
Wow. Ada begitu banyak hal aneh di sini. Air terjun layak karena berada di sekitar lebih lama? Waterfall dibenarkan atas dasar penggunaan dalam kontrak pertahanan? Apakah setiap peluang untuk meminimalkan perubahan benar-benar dalam kepentingan terbaik pelanggan, atau apakah itu mengarah pada memberikan apa yang menurutnya diinginkan daripada apa yang sebenarnya diinginkannya? Karena Anda tampaknya peduli dengan ini, saya sudah mencoba memahami dari mana Anda berasal, tetapi saya kehilangan sesuatu.
— Eric Wilson
1
@EricWilson Waterfall telah ada lebih lama dan digunakan dengan sukses jauh sebelum filsafat Agile dibahas. Itu layak karena ada dan ketika diterapkan dengan benar bekerja untuk mereka yang ingin menggunakannya. Saya tidak membenarkan penggunaannya, tetapi hanya menunjuk ke sebuah contoh di mana saya memiliki pengalaman pribadi di mana saya melihatnya bekerja, dan ya, saya telah melihat beberapa kegagalan yang spektakuler juga. Anda tidak mencari peluang untuk meminimalkan perubahan, Anda ingin peluang untuk memperkenalkan perubahan, tetapi Anda harus melakukannya dengan bijaksana, jika tidak pelanggan Anda mendapatkan lebih sedikit dari yang mereka inginkan atau tenggat waktu yang terpeleset.
— S.Robins
0

Ya, Waterfall, Spiral, Iterative, dan model proses hybrid lainnya semuanya layak, tetapi perubahan tidak bisa dihindari. Proses lebih dari sekedar bagaimana menangani perubahan, dan (saya mengklaim itu) penentu terbesar adalah seberapa baik Anda mengetahui / memahami masalah, dan seberapa akurat Anda dapat merencanakan dan memprediksi.

Menyatakan bahwa "dua metodologi utama pengembangan perangkat lunak adalah air terjun dan lincah" tidak jujur, karena ada spektrum proses pengembangan perangkat lunak, dan banyak perusahaan mensintesis versi mereka sendiri dari model proses, sering berubah untuk proyek tertentu. Ada lebih dari dua pendekatan yang layak untuk pengembangan perangkat lunak. Meskipun Waterfall dan Agile cenderung jatuh pada ujung yang berlawanan dari spektrum "perubahan", masuk akal untuk menentukan metodologi yang bersaing ini sebagai,

Waterfall mengatakan: Perubahan itu mahal, jadi harus diminimalkan.

Agile berkata: Perubahan tidak bisa dihindari, jadi buat perubahan murah.

Tapi itu bukan keseluruhan cerita. Bisnis perlu dapat merencanakan dan memprediksi, tetapi perangkat lunak adalah proses kreatif, dan perkiraan seringkali salah. Ingat segitiga bagus - cepat - murah? Tambahkan dimensi keempat, proses, dan Anda menemukan bahwa upaya mengurangi proses juga dapat menekan jadwal, ketika perkiraan ternyata salah dan proyek berada dalam bahaya keterlambatan. Perangkat lunak adalah proses yang sepadan (dapat berubah), dan Agile, Iterative, Spiral semuanya menawarkan kemampuan untuk memberikan fungsionalitas tambahan dalam interval yang lebih pendek.

Waterfall dan model proses lainnya yang digerakkan oleh persyaratan memiliki kontrol untuk menangani perubahan, sehingga tidak akurat untuk mengatakan bahwa Waterfall meminimalkan perubahan, lebih tepat untuk mengatakan bahwa Waterfall mengenali dan mengelola perubahan, dan mengkomunikasikan dampak dari perubahan itu (karena perubahan menyebabkan dampak jadwal ketika Anda memiliki persyaratan dan desain di muka). Saat Anda sedang membangun produk, atau perlu mendefinisikan persyaratan (fungsionalitas) sepenuhnya, Anda akan diarahkan ke salah satu model hibrid.

Dan ketika perkiraan salah, seringkali proses (kaki keempat dari segitiga besi) dikorbankan untuk memenuhi jadwal.

— ChuckCottrill
sumber
Saya tidak jujur. Setelah lima tahun berkembang di berbagai perusahaan, saya hanya menemui dua, dan satu hanya dinamai perjoratif. Spiral? Tidak pernah mendengar hal tersebut.
— Eric Wilson
— ChuckCottrill
Maksud saya, saya belum pernah bertemu mereka di dunia nyata. Segala macam hal ada di luar sana pada jalinan, tetapi saya tidak akan mulai memburu mereka sekarang hanya karena saya kebetulan mengajukan pertanyaan kembali pada tahun 2010.
— Eric Wilson
-1

Pendekatan tangkas dan air terjun yang matang tidak dapat dibedakan satu sama lain. Asumsi Anda tentang tujuan pendekatan air terjun salah. Mereka berdua memiliki tujuan untuk menghasilkan perangkat lunak yang berkualitas. Ketika Anda tidak memiliki pendekatan pengembangan yang solid untuk perusahaan secara keseluruhan, Anda perlu melihat pendekatan mana yang akan memberikan gesekan paling sedikit untuk adopsi. Pada akhirnya siklus pengembangan singkat, tim QA yang solid, dan bisnis yang mendorong pengembangan adalah apa yang paling penting untuk memproduksi perangkat lunak kedudukan tertinggi.

— Charles Lambert
sumber
1
Saya akan memberikan peringatan untuk komentar Anda. Air terjun membutuhkan orang-orang berbakat atau itu akan jatuh datar di wajahnya. Belajar merancang dengan baik itu sulit. Mempelajari kode relatif mudah. IMO, itulah alasan utama kebanyakan pengembang lebih suka gesit.
— Dunk
4
Saya bisa mengatakan hal yang sama gesit. Pengembang Jr. tanpa panduan dapat membuat kekacauan lincah dengan cepat.
— Charles Lambert
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.