Senin, 11 Desember 2023

Model air terjun mungkin adalah metodologi paling dibenci dalam rekayasa perangkat lunak. Metodologi ini pertama kali dijelaskan dalam makalah tahun 1970 oleh Dr. Winston Royce. Meskipun makalah ini tidak menyebutnya sebagai “air terjun” atau memberikan dukungan pada teknik tersebut, namun makalah ini berisi wawasan yang baik dan menimbulkan beberapa pertanyaan menarik. Mari kita lihat beberapa di antaranya.

Langkah Penting dalam Pengembangan Perangkat Lunak

Royce mengatakan ada dua langkah penting dalam semua pemrograman: analisis dan pengkodean. Meskipun tidak dijelaskan apa yang termasuk dalam analisis, kita dapat dengan aman mengasumsikan bahwa itu termasuk pemikiran tentang masalah dan cara memecahkannya. Dalam program yang sangat kecil, mungkin itulah yang Anda butuhkan, meskipun kemungkinan Anda tidak melakukannya secara berurutan.

Langkah-langkah lain yang terlibat untuk program yang lebih besar adalah persyaratan, desain program, pengujian, dan operasi.

Satu hal menarik di sini adalah bahwa saya pikir semua langkah ini dilakukan pada semua ukuran perangkat lunak, hanya saja tidak dilakukan secara eksplisit dan terpisah. Misalnya, Anda menulis program kecil, seperti solusi untuk masalah Advent of Code. Untuk ini, Anda perlu mendapatkan persyaratan dari deskripsi masalah, melakukan analisis, merancang program Anda, menulisnya, menguji, dan kemudian menjalankannya untuk mendapatkan jawaban. Tetapi semua langkah ini terjadi bersamaan, dan kode/uji/operasi digabungkan, dan persyaratan/analisis/desain juga digabungkan—keduanya tercampur juga. Mereka tidak dilakukan berurutan satu demi satu, tetapi masing-masing dilakukan pada suatu titik.

Apa yang benar-benar langkah penting dalam pengembangan perangkat lunak? Saya tidak yakin. Saya pikir pembagian kegiatan yang disebutkan dalam makalah ini menarik dan merupakan cara bagus untuk memikirkan kegiatan yang kita lakukan, dan saya tidak bisa benar-benar melampaui itu pada saat ini.

Peran Manajemen

Salah satu poin yang dibuat oleh Royce cukup menarik:

“Fungsi utama manajemen adalah untuk menjual konsep-konsep ini [pengujian, dokumentasi, analisis, dll.] kepada kedua kelompok [pengembang dan pelanggan] dan kemudian menegakkan kepatuhan dari pihak personel pengembangan.”

Dia melanjutkan ini kemudian:

“Aturan pertama dalam mengelola pengembangan perangkat lunak adalah penegakan tanpa ampun dari persyaratan dokumentasi.”

Dan kutipan ini diikuti dengan mengatakan bahwa jika dokumentasinya tidak cukup baik, maka gantilah manajemennya.

Jadi, ini membuat jelas pandangan Royce tentang peran manajemen: menegakkan aturan dan praktik pengembangan yang benar. Jika mereka tidak dengan tanpa ampun menegakkan proses dokumentasi, maka mereka akan dipecat. Dan mereka harus memastikan pengembang melakukan pengujian, analisis, dan desain juga.

Bagi saya, peran manajemen bukan sebagai penegak yang tanpa ampun, tetapi sebagai fasilitator. Rekayasa perangkat lunak lebih matang sebagai bidang daripada 53 tahun yang lalu, dan kita memiliki beberapa praktik terbaik yang telah mapan. Sebagai praktisi, kita bangga dengan pekerjaan kita dan kita mendorong pengujian, analisis, semua hal yang baik. Dan peran manajemen adalah memastikan bahwa semuanya seimbang antara kedalaman teknis dan kebutuhan bisnis, dan memastikan bahwa proses yang ada memfasilitasi keseimbangan itu.

Apa yang Kita Optimalkan?

Royce menyatakan awal bahwa “[Tahap pengembangan yang terpisah] harus direncanakan dan diisi dengan cara yang berbeda untuk penggunaan terbaik sumber daya program.” Ini menggambarkan dunia di mana kita memiliki staf yang ditunjuk untuk mengumpulkan persyaratan, staf yang berbeda untuk merancang program, lebih banyak staf untuk menulisnya, tim lain untuk mengujinya, dan seseorang yang malang harus menempatkannya ke produksi.

Sebaliknya, sebagian besar tim saat ini mengambil pendekatan yang jauh lebih multidisiplin. Beberapa melibatkan semua orang untuk melakukan segala sesuatu. Sebagian besar berada di tengah-tengah: staf pengujian yang ditunjuk hadir, tetapi semua orang melakukan beberapa pengujian; manajer produk bertanggung jawab atas persyaratan, tetapi semua orang membantu; arsitek melakukan banyak desain, tetapi setiap insinyur melakukan beberapa arsitektur.

Hal kunci di sini adalah bagian terakhir: “untuk penggunaan terbaik sumber daya program.” Di sini, “program” merujuk pada proyek dan stafnya, bukan perangkat lunak. Dan itulah masalahnya, dia mengoptimalkan penggunaan waktu masing-masing individu dan menghemat uang untuk personil.

Sebaliknya, pengembangan perangkat lunak modern memprioritaskan hal-hal lain daripada penggunaan sumber daya langsung. Waktu pemasaran, validasi cepat, semua hal untuk memastikan kita bergerak ke arah yang benar. Kita melambat sedikit dan menyia-nyiakan sedikit waktu setiap orang, tetapi kita memiliki lebih sedikit penarikan kembali.

Saya bisa melihat peran terpisah masuk akal dalam situasi di mana Anda memiliki persyaratan yang jauh lebih jelas. Apakah sesuatu seperti itu ada? Pertanyaan yang bagus. Tetapi jika ada, peran terpisah mungkin masuk akal (saya belum sepenuhnya yakin, tapi mungkin). Untuk segala sesuatu yang lain, memprioritaskan mencari tahu apa yang kita lakukan membuat lebih banyak akal daripada mengoptimalkan penggunaan penuh waktu.

Tulis Dua Kali!

Salah satu saran terbaik dalam makalah

ini (bukan bahwa saya memihak, karena menulis sesuatu yang serupa) adalah menulisnya dua kali. Versi pertama harus menjadi versi cepat untuk mempelajari apa yang kita lakukan dan mendapatkan wawasan dunia nyata. Kemudian versi kedua adalah draf akhir yang disampaikan kepada pelanggan dan harus memenuhi persyaratan.

Ini bagus, karena menyoroti apa yang sering kita temui: kita tidak tahu apakah solusi kita berhasil sampai kita mencobanya. Kita tidak benar-benar tahu apa masalahnya sampai kita mencoba memecahkannya. Memiliki beberapa iterasi adalah cara fantastis untuk mencoba hal-hal, mempelajari pelajaran sulit itu, dan masih memiliki waktu dalam jadwal untuk memperbaiki semuanya.

Rekomendasi untuk melakukannya dua kali, sepenuhnya, menurut saya menarik dan merupakan sesuatu yang patut dicontoh. Lebih mudah untuk mendorong iterasi kecil dan prototipe yang bisa dibuang, dan itu sangat berharga. Jika Anda tidak membawa pulang apa pun dari makalah ini, coba lakukan versi buang-buang pertama.

Bahasa yang Bersifat Gender

Selalu sedikit mengejutkan kembali dan membaca makalah dari tahun 70-an. Setiap kata ganti tunggal adalah “dia” atau “miliknya,” dan itu benar-benar mengganggu. Tidak setiap orang dalam proyek teknologi adalah laki-laki, Anda tahu.

Norma di dunia teknologi sudah cukup bergeser sejauh yang saya lihat. Masih banyak seksisme yang beredar, tetapi setidaknya tidak ada lagi bahasa yang bersifat gender secara terang-terangan. Kami masih memiliki jalan panjang, dan terkadang membaca makalah dari masa lalu bagus untuk mengingatkan kita betapa norma telah berubah.

Mari kita biarkan ini mengingatkan kita bahwa perubahan memungkinkan. Secara kolektif, kita beralih dari kata ganti default “dia” untuk orang yang anonim. Kita dapat terus membuat dunia yang lebih adil. Ini akan memakan waktu, itu akan menyakitkan, dan itu layak untuk diperjuangkan ❤️.

Sebagai artefak historis, makalah Royce memberikan wawasan yang menarik. Sangat menarik melihat beberapa hal yang dibahas di sini sepenuhnya diwujudkan, dan melihat cara lain di mana bidang kita telah melampaui apa yang terjadi pada tahun 70-an.

Sumber:

• Insights and questions from the original waterfall paper

Sebagai penanda sejarah, makalah Royce memberikan wawasan yang menarik. Sangat menarik melihat beberapa hal yang dibahas di sini sepenuhnya diwujudkan, dan melihat cara lain di mana bidang kita telah melampaui apa yang terjadi pada tahun 70-an.