Apakah ada keuntungan untuk praktik lincah selain memiliki build yang bekerja di antara sprint?

Saya baru-baru ini tertarik pada praktik lincah dalam pengembangan perangkat lunak dan sejak itu saya telah melihat banyak artikel menunjukkan bahwa praktik ini memungkinkan untuk mengurangi biaya keseluruhan.

Logika di balik itu biasanya seperti ini: jika kebutuhan Anda berubah, Anda dapat mencerminkan perubahan ini di sprint backlog berikutnya dan ini akan menyebabkan pengurangan biaya, karena merancang fitur baru dan mengimplementasikannya berdekatan dalam hal waktu, sehingga biaya turun, menurut aturan terkenal bahwa nanti Anda perlu melakukan perubahan pada kebutuhan Anda semakin mahal untuk memenuhi persyaratan itu.

Tetapi proyek perangkat lunak menengah hingga besar itu rumit. Perubahan mendadak pada persyaratan tidak berarti Anda tidak perlu menyentuh bagian lain dari sistem Anda untuk memenuhi persyaratan itu. Dalam banyak kasus, arsitektur perlu dimodifikasi secara signifikan, yang juga berarti Anda harus mengimplementasikan kembali semua fitur yang bergantung pada arsitektur yang lebih lama. Jadi inti dari pengurangan biaya agak hilang di sini. Tentu saja jika persyaratan baru memerlukan bagian independen baru dari sistem, itu bukan masalah, arsitektur lama hanya tumbuh, tidak perlu dipikirkan kembali dan diterapkan kembali.

Dan sebaliknya. Jika Anda menggunakan air terjun dan tiba-tiba Anda menyadari bahwa persyaratan baru harus diperkenalkan, Anda dapat pergi dan mengubah desain Anda. Jika mengharuskan arsitektur yang ada diubah, Anda mendesain ulangnya. Jika tidak benar-benar mengacaukannya tetapi hanya memperkenalkan bagian baru dari sistem, maka Anda pergi dan melakukan semua pekerjaan, tidak ada masalah di sini.

Dengan itu, menurut saya sepertinya satu-satunya keuntungan pengembangan tangkas adalah fitur kerja yang lengkap dibangun di antara sprint, dan bagi banyak orang dan prjects ini tidak kritis. Selain itu, agile sepertinya menghasilkan arsitektur perangkat lunak yang buruk secara keseluruhan, karena fitur-fitur agak saling menampar satu sama lain, tim tangkas hanya peduli bahwa suatu fitur berfungsi, bukan bagaimana kerjanya. Ini tampak seperti itu ketika sistem tumbuh dalam kompleksitas dengan waktu, praktik pengembangan lincah sebenarnya meningkatkan kekacauan dalam arsitektur produk secara keseluruhan, sehingga akhirnya menghasilkan biaya yang lebih tinggi, karena akan semakin sulit untuk memperkenalkan perubahan, sedangkan air terjun memungkinkan Anda untuk menyempurnakan arsitektur Anda sebelum Anda melepaskan apa pun.

Dapatkah seseorang tolong tunjukkan saya di mana saya salah di sini, karena jelas banyak orang menggunakan gesit dalam lingkungan produksi, jadi saya pasti salah di suatu tempat.

Pertama-tama, model "air terjun" selalu menjadi tukang jerami yang menggambarkan bagaimana TIDAK menjalankan proyek pengembangan perangkat lunak. Lihat itu.

Bagaimanapun, sebagian besar proyek "air terjun" SDLC memerlukan proses "Manajemen Perubahan", karena ketika orang menemukan bahwa asumsi yang ditulis dalam spesifikasi tidak lagi valid (dan ini selalu terjadi pada proyek kompleks besar). Sayangnya, proses manajemen perubahan dibangun sebagai tindakan penanganan pengecualian, dan sangat mahal, berarti proyek akan berakhir terlambat, atau berkualitas buruk.

Gagasan di balik metodologi Agile adalah bahwa perubahan diberikan - itu akan terjadi. Oleh karena itu, Anda harus membuat operasi standar "manajemen perubahan" daripada penanganan pengecualian. Ini tidak mudah, tetapi orang-orang telah menemukan bahwa jika Anda menggunakan banyak praktik desain yang baik, Anda dapat melakukannya.

Masalah utama lainnya dengan desain front load adalah bahwa (paling sering) begitu banyak waktu dihabiskan dalam pengumpulan persyaratan dan desain, pengembangan dan waktu pengujian menderita. Juga, jika pengujian adalah tahap terakhir, dan masalah serius ditemukan, sangat tidak mungkin untuk diperbaiki dalam kerangka waktu Anda.

Mungkin salah satu fitur terbaik dari pendekatan Agile adalah bahwa ia menuntut interaksi yang berkelanjutan (yaitu, komunikasi nyata) antara tim yang mengembangkan solusi, dan pelanggan yang membutuhkannya. Prioritas dibuat, sehingga item prioritas tertinggi dilakukan terlebih dahulu (dan jika waktu habis, item prioritas rendah yang terpotong). Umpan balik datang dengan cepat.

Kembali ke pertanyaan tentang perubahan dramatis - Anda benar-benar perlu menggunakan metode yang mengurangi perubahan. Kepala sekolah SOLID OO yang baik dapat memainkan bagian yang baik dari ini, karena dapat membangun suite tes otomatis yang solid sehingga Anda dapat menguji perangkat lunak Anda. Anda harus melakukan hal-hal ini terlepas dari metodologi Anda, tetapi mereka menjadi sangat penting jika Anda mencoba untuk menjadi gesit.

Nah, ada beberapa keuntungan. Yang pertama adalah bahwa pelanggan tidak membaca dokumen spesifikasi. Pernah. Waterfall berasumsi bahwa semua orang akan setuju dengan spesifikasi pada permulaan dan kemudian ketika perangkat lunak dikirimkan kepada pelanggan setahun kemudian dengan spesifikasi yang cocok, mereka akan senang. Dalam praktiknya, pelanggan hanya menemukan semua hal yang benar-benar mereka butuhkan, benar-benar tidak perlu, dan benar-benar perlu menjadi sesuatu yang berbeda ketika mereka secara aktif bermain dengan perangkat lunak itu sendiri. Agile mendapatkan prototipe yang berfungsi di tangan pelanggan, sehingga pemutusan ini langsung tertangkap. Agile bukan hanya tentang bereaksi terhadap perubahan persyaratan. Ini juga tentang memiliki persyaratan perubahan yang terjadi lebih awal, ketika biaya perubahan rendah, bukan pada akhirnya, ketika biaya perubahan tinggi.

Keuntungan kedua adalah bahwa karena Agile sering memberikan hasil yang sangat terlihat, proyek cenderung tidak keluar jalur. Dengan proyek Air Terjun yang besar, terlalu mudah untuk mendapatkan jalan di belakang tanpa menyadarinya. Waterfall menghasilkan pawai kematian multimonth di akhir proyek. Dengan Agile, karena Anda mengirim ke pelanggan setiap beberapa minggu, semua orang tahu persis di mana proyek itu dan slip ditangkap (dan disesuaikan dengan) dengan cepat. Dalam pengalaman saya, Waterfall menghasilkan minggu atau bulan 100 jam minggu pada akhirnya. Agile berarti Anda mungkin harus menggunakan pasangan selama 12 jam di akhir sprint.

Keuntungan ketiga adalah bahwa proyek Agile cenderung lebih memotivasi. Sangat sulit bagi orang untuk memiliki rasa berkendara dalam proyek setahun. Tenggat waktu tampaknya begitu jauh dan kurangnya kedekatan berarti bahwa orang cenderung menunda-nunda, desain yang terlalu terpoles dan sebaliknya tidak bekerja dengan sangat produktif. Ini terutama benar karena bulan-bulan awal dihabiskan untuk hal-hal yang orang tidak suka lakukan, seperti dokumen spesifikasi. Karena Agile selalu memiliki tenggat waktu yang sangat segera dan konkret dalam waktu dekat, orang cenderung lebih termotivasi. Jauh lebih sulit untuk menunda-nunda dengan tenggat waktu yang konkret untuk serangkaian tugas tetap yang akan dijadwalkan minggu depan.

Menanggapi kutipan dari pertanyaan, yang merupakan kesalahpahaman mendasar dari lawan anti-gesit

"... sedangkan air terjun memungkinkanmu untuk menyempurnakan arsitekturmu sebelum melepaskan apapun." adalah kesalahan, biarkan saya memperbaikinya untuk Anda; "... sedangkan air terjun memungkinkan kamu untuk menyempurnakan arsitekturmu sehingga kamu tidak pernah melepaskan apapun. "

Implikasi bahwa Waterfall bagaimana memberikan arsitektur kualitas yang lebih tinggi pada dasarnya salah dan sepenuhnya dibantah oleh bukti sejarah empiris.

Jika Facebook dirancang dengan cara air terjun dengan 500 juta pengguna sebagai persyaratan keras dan cepat dan tidak dirilis sampai arsitektur untuk mendukung yang disempurnakan tidak ada yang akan pernah mendengarnya hari ini.

Sama dengan YouTube, Twitter, dan banyak perusahaan lain.

Mereka mendapatkan sesuatu yang dapat disentuh oleh pelanggan dan merespons untuk bekerja dan merilisnya secepat mungkin. Mereka mendapat umpan balik dan memperbaikinya dan merilisnya lagi; pengulangan. Ini adalah bagaimana dalam tiga contoh ini, mereka merespons dengan hanya fitur yang diterima dan diinginkan pelanggan dan membuang waktu sesedikit mungkin pada hal-hal yang pelanggan temukan nilainya sedikit atau tidak sama sekali.

Siapa pun dengan pengalaman pengembangan perangkat lunak yang signifikan selama bertahun-tahun akan setuju bahwa tidak ada arsitektur yang disempurnakan . Hanya satu yang dimulai lebih jauh dari entropi dan bola lumpur besar daripada alternatif lainnya. Agile mengakui hal ini dan memperhitungkannya. Membangun ke dalam proses, ini sebagai hutang teknis, prioritas ulang yang cepat dan refactoring.

Scrum dengan sendirinya tidak menentukan praktik teknis apa pun karena itu adalah kerangka umum.

Pengembangan perangkat lunak yang gesit membutuhkan keunggulan teknis dari tim. Ini berasal dari mengikuti praktik teknis dari XP (pemrograman ekstrim). Misalnya, Anda harus belajar tentang refactoring, tdd, seluruh tim, pemrograman pasangan, desain tambahan, ci, kolaborasi dll.

Melakukannya seperti itu memungkinkan untuk menangani perubahan dengan cepat dan aman, yang juga merupakan alasan utama untuk menggunakan pengembangan lincah di tempat pertama.

Satu ukuran gesit yang penting adalah jika Anda secara teratur (mingguan, dua mingguan) berhasil merilis perangkat lunak yang berharga dan berfungsi untuk pelanggan Anda. Bisakah kamu melakukan itu? Maka Anda lincah dalam buku saya.

Bagi saya, manfaat utama gesit adalah mengurangi risiko dalam proyek.

Dengan mengirimkannya secara berulang dan mendapatkan banyak umpan balik dari basis pengguna Anda, Anda meningkatkan peluang bahwa Anda akan memberikan sesuatu yang benar-benar mereka inginkan, dan Anda akan melakukannya dengan secara pragmatis memberikan fitur paling penting bagi mereka sedini mungkin. Secara teori, ini akan dilakukan dengan perkiraan dan perencanaan yang lebih baik. Ini jelas sangat menarik dari perspektif bisnis - jauh lebih dari sekadar bangunan yang dapat dirilis.

Anda bisa berargumen bahwa perubahan yang konstan ini membahayakan sistem Anda dan mengurangi kualitas, tetapi saya akan mengatakan dua hal. 1) Perubahan ini tetap terjadi pada proyek-proyek pengiriman perangkat lunak yang lebih tradisional - itu hanya tidak terhitung dan terjadi kemudian dalam proyek yang ketika, seperti yang Anda tunjukkan, hal-hal lebih sulit dan lebih mahal untuk berubah. 2) Agile banyak bicara tentang berurusan dengan perubahan ini dalam hal menggunakan orang-orang yang termotivasi dan praktik seperti TDD, pairing dan review kode. Tanpa perubahan pola pikir menuju peningkatan kualitas dan terus-menerus, saya menerima bahwa perubahan yang sering dilakukan yang tangkas dapat mulai menyebabkan masalah.

Dalam banyak kasus, arsitektur perlu dimodifikasi secara signifikan, yang juga berarti Anda harus mengimplementasikan kembali semua fitur yang bergantung pada arsitektur yang lebih lama.

Jika arsitektur Anda perlu dimodifikasi secara signifikan sebagai akibat dari perubahan persyaratan, Anda memiliki arsitektur yang buruk atau persyaratan yang buruk. Arsitektur yang baik memungkinkan Anda untuk menunda sebanyak mungkin keputusan dan memisahkan komponen-komponen sistem Anda. Persyaratan (pengguna) yang baik bukanlah hal-hal seperti "gunakan database yang berbeda".

Jadi, mari kita beroperasi dengan asumsi bahwa kita memiliki arsitektur kerja yang baik. Jika itu masalahnya, maka metodologi pengembangan yang tangkas kehilangan "pencucian" ini dengan metodologi desain besar-muka. Setelah semua, fitur inti dari metodologi pengembangan gesit adalah praktik seperti TDD yang mempromosikan kode kopling longgar, yang memungkinkan proyek untuk melanjutkan dengan kecepatan tinggi apakah itu dekat awal atau sangat matang.

Dalam banyak kasus, arsitektur perlu dimodifikasi secara signifikan, yang juga berarti Anda harus mengimplementasikan kembali semua fitur yang bergantung pada arsitektur yang lebih lama. Jadi inti dari pengurangan biaya agak hilang di sini.

Mengikuti proses yang gesit, ada peluang yang lebih baik untuk menangkap persyaratan ini sebelum terlalu banyak perangkat lunak dikembangkan (Dan perlu diubah.). Ketika Anda pergi beberapa bulan tanpa bekerja dengan klien dan memberi mereka sesuatu untuk dilihat, Anda menangkap masalah arsitektur utama ini hanya setelah Anda "berpikir" Anda siap untuk memberikan.

Saya lebih suka mencoba menerapkan perubahan ini dalam aplikasi yang berfungsi yang memiliki cakupan uji daripada tumpukan kode besar yang bahkan tidak dapat dikompilasi. Saat menjadi kepala dukungan teknis, saya diberikan CD aplikasi yang telah berbulan-bulan pengembangan dan bahkan tidak akan menginstal. Kami bisa menemukan masalah itu pada minggu pertama, tetapi sebaliknya sudah waktunya untuk memesan makan malam karena itu adalah malam yang panjang.