Apakah Scrum membuat overhead tambahan untuk proyek-proyek di mana persyaratan tidak berubah?

Saya membaca Scrum - Panduan Saku oleh Gunther Verheyen dan tertulis:

Laporan Chaos 2011 oleh Standish Group menandai titik balik. Penelitian ekstensif dilakukan dalam membandingkan proyek tradisional dengan proyek yang menggunakan metode Agile. Laporan tersebut menunjukkan bahwa pendekatan Agile untuk pengembangan perangkat lunak menghasilkan hasil yang jauh lebih tinggi, bahkan bertentangan dengan harapan lama bahwa perangkat lunak harus dikirimkan tepat waktu, sesuai anggaran dan dengan semua ruang lingkup yang dijanjikan. Laporan tersebut menunjukkan bahwa proyek Agile tiga kali lebih berhasil, dan ada tiga kali lebih sedikit proyek Agile yang gagal dibandingkan dengan proyek tradisional.

Jadi saya berdebat dengan salah satu kolega saya yang mengatakan bahwa untuk beberapa proyek (seperti obat-obatan / militer di mana persyaratannya tidak berubah), Agile (dan, terutama, Scrum) ada di atas kepala dengan semua pertemuan dll dan lebih logis untuk menggunakan air terjun, misalnya.

Pandangan saya adalah Scrum harus diadopsi dalam proyek seperti itu karena itu akan membuat proses lebih transparan dan meningkatkan produktivitas tim. Saya juga berpikir bahwa acara Scrum tidak akan memakan banyak waktu jika tidak diperlukan karena kita tidak perlu duduk selama 8 jam dalam Perencanaan Sprint untuk sprint 1 bulan. Kita dapat menyisihkan 5 menit hanya untuk memastikan bahwa kita semua berada di halaman yang sama dan mulai bekerja.

Jadi, akankah Scrum membuat overhead tambahan untuk proyek di mana persyaratan tidak berubah?

Saya percaya bahwa ini adalah asumsi yang salah untuk mengatakan bahwa ada proyek di mana persyaratannya tidak berubah. Setelah bekerja di industri pertahanan dan industri farmasi membuat perangkat lunak, saya dapat memberi tahu Anda bahwa begitu perangkat lunak berakhir di tangan para ahli masalah (baik internal maupun eksternal), ada umpan balik. Terkadang, umpan balik ini adalah tentang bagaimana persyaratan terpenuhi dan dalam kasus lain itu sebenarnya pada persyaratan itu sendiri salah atau tidak lengkap.

Agility adalah tentang mengurangi siklus umpan balik itu dan mendapatkan perangkat lunak yang bekerja ke tangan seseorang dengan lebih cepat, mendapatkan umpan balik itu, dan memutuskan apa langkah selanjutnya seharusnya memastikan bahwa apa yang disampaikan menambah nilai ketika pelanggan memutuskan untuk menerima perangkat lunak tersebut. Bahkan dalam ranah seperti sistem tertanam dengan perangkat keras khusus (seperti yang mungkin Anda temukan di domain seperti ruang angkasa, otomotif, atau perangkat medis), memberikan irisan fungsi tipis dengan cepat untuk diintegrasikan dan prototipe dengan dapat membantu memastikan bahwa perangkat lunak dan sistem perangkat keras akan bekerja sebagaimana dimaksud dan dengan cara yang akan membantu pengguna akhir.

Pengurangan dalam panjang siklus umpan balik merupakan faktor besar dalam pengurangan risiko. Dari perspektif manajemen proyek, jika Anda mendanai suatu proyek selama 2-4 minggu dan mendapatkan kemajuan visibilitas yang teratur, itu meyakinkan Anda bahwa Anda berada di jalur yang benar. Dengan bisa memberikan irisan fungsionalitas tipis, Anda secara bertahap bekerja menuju status target dan dapat mulai memperkirakan kapan Anda akan sampai di sana. Jika waktu menjadi kendala, Anda dapat menghapus fungsi yang bernilai rendah karena pekerjaan yang dilakukan terlebih dahulu harus berupa fungsi bernilai tinggi atau enabler untuk fungsi bernilai tinggi. Pada titik mana pun, Anda dapat memutuskan apakah perlu terus mendanai upaya atau pergi ke arah yang berbeda dan menghentikan proyek sebelum terlambat.

Jawaban yang sangat singkat adalah bahwa ya, Scrum adalah dengan merancang pendekatan yang lebih mahal, tetapi jika Anda menyebutnya proyek, hampir pasti tidak masalah dan pada akhirnya hampir pasti akan selalu menghasilkan ROI yang lebih baik.

Jawaban yang lebih lengkap adalah ini:

Secara umum ada tiga bentuk kontrol proses: Kontrol Proses Yang Ditentukan, Kontrol Proses Statistik, dan Kontrol Proses Emperikal. Sejauh ini, Kontrol Proses yang Ditentukan adalah yang termurah. Hal ini dimungkinkan dengan pekerjaan yang sering dapat diulang telah disempurnakan dari waktu ke waktu untuk menemukan cara "terbaik" untuk melakukan pekerjaan. CI / CD dalam pengembangan perangkat lunak termasuk dalam kategori ini. Anda tidak ingin variasi dalam proses pembuatan Anda sehingga Anda membakukan prosesnya, menyesuaikan sampai Anda puas dengannya, lalu mengotomatiskannya. Proses otomatis itu jelas jauh lebih murah untuk dijalankan daripada bertarung secara manual melalui penyebaran.

Pengendalian Proses Statistik adalah yang paling murah berikutnya, tetapi menyumbang variasi dalam proses yang diketahui. Prosedur medis yang berjalan sesuai rencana termasuk dalam kategori ini. Saya tidak ingin menemukan kembali operasi bypass setiap kali. Saya mengikuti proses dasar dan menyesuaikan variasi. Ini memiliki beban kognitif yang relatif rendah dan tingkat keberhasilan yang cukup tinggi.

Berikutnya adalah Kontrol Proses Empiris, yang sejauh ini paling mahal karena Anda harus menemukan proses saat Anda pergi. Belajar itu luar biasa tinggi, tetapi dengan harga produktivitas dan efisiensi. Namun, hampir semua pekerjaan proyek memerlukan ini karena beberapa proyek telah dilakukan sebelumnya. Tentu saja ada pengecualian. Menyiapkan lingkungan direktori aktif yang besar lebih bersifat Statistik karena Anda bekerja dari beberapa instruksi yang coba-dan-benar yang sedikit menyimpang dari kondisi yang diperlukan. Tetapi kecuali Anda proyek adalah untuk melakukan pekerjaan persis yang telah dilakukan sebelumnya, itu hampir pasti membutuhkan Kontrol Proses Emperikal.

Untuk mengembalikannya ke Scrum, Scrum dirancang untuk menyelesaikan masalah dengan kontrol Proses Emperical. Karenanya, ya, ia memiliki lebih banyak overhead daripada pendekatan lain. Namun, karena sebagian besar proyek memerlukan pendekatan ini, ini merupakan argumen yang bisa diperdebatkan.

Untuk tandingan tentang obat-obatan dan proyek-proyek militer, kedengarannya seperti logika yang cacat. Jika Anda memenuhi pesanan untuk 500 pesawat terbang, maka ya, Anda membuat ulang sesuatu dengan tepat dan Scrum mungkin tidak menguntungkan. Jika Anda membangun pesawat baru dan persyaratan Anda tidak pernah berubah, saya tidak akan menerbangkan pesawat itu.

Tentu, jika Anda memiliki proyek di mana Anda memiliki persyaratan yang sangat jelas di depan, maka Anda dapat dengan mudah membuangnya di depan pengembang dan kembali dua tahun kemudian untuk memenuhi perangkat lunak impian Anda.

Tetapi sebagian besar proyek perangkat lunak tidak seperti ini.

Biasanya, pelanggan tidak tahu apa yang mereka butuhkan. Mereka tidak dapat memberikan persyaratan lengkap dan spesifik. Pendekatan berulang membantu di sini: membangun hal kecil, kemudian meminta umpan balik pelanggan. Ya, ini "membuang" waktu untuk demo dan merencanakan iterasi berikutnya. Tetapi membangun hal yang salah untuk satu sprint dan kemudian dengan cepat memperbaiki persyaratan adalah jauh lebih baik daripada membangun hal yang salah untuk keseluruhan proyek. Yaitu, sementara persyaratan di muka memungkinkan pengembangan yang lebih efisien , pendekatan berulang akan lebih efektif .

Pengembang harus memahami persyaratan dengan benar jika mereka ingin membangun perangkat lunak yang bermanfaat. Apa cara yang baik untuk menemukan kesalahpahaman sebelum terlambat? Sekali lagi, pendekatan berulang dapat membantu. Tetapi penting juga bahwa pengembang sendiri berkolaborasi dengan pelanggan alih-alih hanya mendapatkan informasi yang difilter melalui penulis dokumen persyaratan.

Akhirnya, dunia tidak diam selama proyek. Sistem eksternal berubah, prioritas berubah, orang berubah. Berpura-pura bahwa persyaratan proyek perangkat lunak tidak akan berubah adalah ide yang buruk, kecuali untuk proyek pendek.

Semua manfaat tingkat proses ini kehilangan keuntungan besar dari pendekatan tangkas: jika dilakukan dengan benar, tangkas membuat semua orang lebih bahagia. Salah satu yang terbesar adalah bahwa teknik gesit fokus pada penyediaan nilai nyata dalam jangka waktu singkat. Itu membawa visibilitas ke dalam proses pembangunan, memberikan para pemangku kepentingan tingkat kontrol yang wajar atas proyek, dan jauh lebih memotivasi daripada bekerja menuju tujuan yang jauh. Terkait dengan ini adalah gagasan bahwa tim tangkas akan mengatur diri sendiri. Merasa memegang kendali atas pekerjaan mereka sehari-hari membuat orang merasa dihargai, dan karenanya lebih cenderung memberikan yang terbaik.

Rekan Anda tidak salah bahwa proyek-proyek gaya air terjun dapat memiliki tempat mereka. Dan Anda tidak salah bahwa beberapa praktik lincah bisa menjadi ritual yang membuang-buang waktu. Tapi itu benar-benar bodoh untuk mengabaikan manfaat dari pendekatan lincah dan berulang, terutama manajemen risiko yang lebih baik dan rasa hormat kepada individu. Ini adalah hal yang Anda inginkan dalam setiap proyek. Jika perlu, sebuah tim dapat mencoba mengimplementasikan beberapa dari ini secara internal, tetapi proses bekerja lebih baik ketika semua orang ada di dalamnya.

Saya pikir ini mungkin parafrase apa yang dikatakan @Cort Ammon, tapi inilah yang saya ambil:

Persyaratan eksternal (menggambarkan "hasil") bukan satu-satunya persyaratan dalam proyek. Bahkan jika persyaratan eksternal tidak berubah, persyaratan "internal" akan berubah, atau perlu diizinkan untuk berubah, saat Anda bekerja. Pengembang akan menemukan hambatan atau masalah dengan suatu pendekatan, dan ini akan memengaruhi pekerjaan orang lain dalam tim. Stand-up harian akan membuat semua orang up to date dengan perubahan internal ini.

Pertimbangkan itu:

• Bahkan dengan persyaratan fungsional tetap, Anda perlu menerjemahkannya ke dalam persyaratan teknis. Dan ini mungkin lebih baik dilakukan dengan iterasi. Anda dapat menemukan cara yang lebih baik untuk menyelesaikan masalah di tengah proyek.

• Beberapa persyaratan mungkin terlalu umum atau ambigu: "mudah digunakan", "aman". Sulit untuk menganalisis keamanan atau kegunaan suatu sistem yang belum selesai. Beberapa mungkin memiliki implikasi tersembunyi atau mungkin tidak dipahami dengan baik.

• Beberapa persyaratan dapat ditingkatkan. Menanggapi dalam 200 ms mungkin baik tetapi 100 mungkin lebih baik. Anda dapat menargetkan hasil terbaik tetapi berkorban jika diperlukan selama proyek.

• Anda mungkin menemukan beberapa permintaan tersembunyi yang tidak akan ditulis dalam kontrak tetapi dapat mengubah proyek dari kegagalan menjadi sukses. Bahkan jika Anda mengirimkan proyek, klien mungkin tidak bahagia. Mungkin mereka bahkan perlu mengubah kontrak untuk menambah (dan membebankan biaya) untuk fitur-fitur baru yang mungkin Anda rancang dalam proyek lebih murah pada tahap awal.

• Anda mungkin menemukan bahwa Anda tidak dapat memenuhi persyaratan Anda dalam waktu yang ditentukan. Bukankah proyek perangkat lunak tidak pernah terlambat. Jadi memberikan nilai terbaik akan memungkinkan Anda untuk membatalkan fitur apa yang akan dibuang.

• Memberikan sesuatu lebih cepat akan membantu integrasi dan akan menunjukkan bahwa proyek ini dapat memberikan hasil.

Seseorang dapat membuat argumen bahwa jika semua persyaratan ditata dengan sempurna, maka ada pendekatan top-down yang mencapai persyaratan tersebut secepat mungkin. Namun, jika ini adalah persyaratan yang baik, mereka memberi tahu Anda apa yang harus dibuat, bukan bagaimana membuatnya. Jika mereka memberi tahu Anda cara membuatnya, saya akan memilih untuk menyebutnya "instruksi kerja" daripada "persyaratan" dan kami akan membahas berbagai jenis masalah.

Dengan demikian, selalu ada proses pengembangan "bagaimana" yang internal untuk perusahaan atau tim yang menerapkan persyaratan. Berbicara secara empiris, kami sangat bergantung pada pendekatan hierarkis di mana tim perancang merancang sistem tingkat tinggi untuk memenuhi persyaratan tersebut, dan kemudian menggunakan spesifikasi sistem tingkat tinggi itu untuk memberikan "persyaratan" kepada tim yang lebih kecil yang menyempurnakan detail kami.

Dalam proses air terjun, ini dapat dilihat pada panah satu arah antara desain dan implementasi. Namun, persyaratan ini tidak ditetapkan, seperti yang disediakan pelanggan. Ini didefinisikan secara internal dan memiliki ruang untuk proses berulang. Dalam praktiknya, kami menemukan desainer baik menempatkan margin yang cukup besar dalam proses untuk memperhitungkan kurangnya iterasi atau mencari proses berulang.

SCRUM, dan banyak metode lincah terkait lainnya, cukup menyediakan kerangka kerja yang ketat di mana untuk melakukan proses berulang ini. Sebuah merek dagang dari pendekatan tangkas adalah bahwa mereka mempertimbangkan untuk mengoptimalkan pola berulang ini menjadi inti dari proses, daripada berfokus pada lapisan luar dari persyaratan keras. Seperti yang disebutkan orang lain, persyaratan tetap aktual jarang, tetapi bahkan di hadapan mereka, SCRUM menggunakan pendekatan iteratif sebagai metodologi untuk mengendalikan pendekatan kontraktual yang cocok di dalamnya.

Apakah itu berhasil melakukan ini adalah masalah debat terbuka. Lainnya telah memberikan banyak metrik untuk tujuan ini. Saya hanya akan mencatat bahwa itu tergantung pada kekuatan kepemimpinan untuk memastikan iterasi yang terjadi di bawahnya cocok dengan benar ke dalam sistem kontrak di atas. Ini benar dengan pendekatan apa pun terhadap pembangunan, tetapi lebih terlihat dalam pendekatan lincah karena kita dibesarkan untuk menganggap bahwa pendekatan yang lebih top-down adalah "normal" dan para pemimpin yang terlatih demikian.