Pengembangan tangkas

"Hai, Amigo!"

"Hai, Bilaabo!"

"Hari ini saya akan memberi tahu Anda tentang bagaimana program biasanya dikembangkan."

"Pada abad ke-20, ketika TI modern masih dalam masa pertumbuhan, semua orang sepertinya berpikir bahwa pemrograman itu seperti konstruksi atau manufaktur."

"Hal-hal biasanya berjalan seperti ini:"

" Pelanggan akan menjelaskan jenis program yang dia butuhkan — apa yang harus dilakukan dan bagaimana melakukannya."

" Analis bisnis akan mendengarkannya dan membuat daftar lengkap persyaratan program berdasarkan apa yang dia katakan."

"Kemudian manajer proyek akan membagi persyaratan ini menjadi tugas, dan juga akan menentukan programmer mana yang akan melakukan tugas apa dan dalam urutan apa."

"Kemudian para programmer akan mulai bekerja. Kadang-kadang mereka akan bekerja beberapa tahun(!."

"Setelah selesai, program diberikan kepada penguji."

" Para penguji akan melalui setiap persyaratan program untuk memverifikasi bahwa mereka telah diterapkan dan bahwa program tersebut bekerja sebagaimana mestinya."

"Jika terjadi kesalahan, penguji akan mencatat bug dan mengirimkannya ke pemrogram."

"Kemudian pemrogram akan memperbaiki bug dan mengirim kembali program yang sudah diperbaiki ke penguji. Dan siklusnya akan berulang."

"Saat bug utama diperbaiki, program diberikan kepada pelanggan."

"Benarkah begitu?"

"Yah, tentu saja, aku sudah banyak menyederhanakannya, tapi itu cukup mirip dengan bagaimana hal itu dilakukan."

"Dan sebuah proyek benar-benar membutuhkan waktu satu setengah tahun hingga dua tahun untuk menyelesaikannya?"

"Terkadang jika pengembangan proyek sangat panjang, mereka akan memecahnya menjadi rilis terpisah. Setiap 3-6 bulan, pengembang harus membuat bagian tertentu dari fungsionalitas program, mengujinya, memperbaiki semua bugnya, dan menunjukkannya ke pelanggan."

"Pertama, agar dia bisa membagikan kesannya. Dan kedua, dan yang lebih penting, agar dia terus membayar untuk pengembangan program."

"Terus bayar?"

"Dulu, pengembangan sering memakan waktu 2-3 kali lebih lama dari yang direncanakan. Dan karena programmer sering dibayar per jam, program menjadi 2-3 kali lebih mahal. Terlebih lagi, manfaatnya juga berkurang. Lagi pula, apa yang diinginkan pelanggan hari ini sebesar $100.000 mungkin tidak diperlukan dalam 3 tahun — terutama dengan harga tiga kali lipat."

"Apakah pelanggan sering menolak untuk membayar?"

"Ya. Mereka kemudian mulai menambahkan penalti pada kontrak, tetapi ini tidak memperbaiki situasi. Pengembangan perangkat lunak berlarut-larut. Dan tidak ada yang bisa berbuat apa-apa bahkan jika mereka mau."

"Tapi kenapa?"

"Yah, pertama, terlalu sedikit yang diketahui selama tahap perencanaan. Sering kali, pada awalnya, tidak ada yang bisa memprediksi masalah yang akan dihadapi para pemrogram."

"Tapi pemrogram berpengalaman seharusnya bisa meramalkan segalanya, kan?"

"Dapatkah Anda melihat bahwa pemrograman adalah profesi yang unik."

"Seorang pekerja biasa sering melakukan pekerjaan yang sama berulang kali. Pembuat jam membuat jam tangan, juru masak memasak, guru mengajar, dokter mengobati, dll."

"Masing-masing profesional ini pada dasarnya melakukan hal yang sama setiap hari. Akibatnya, mereka mulai menjadi lebih baik dan lebih baik dalam pekerjaan mereka."

"Dalam pemrograman, pendekatannya berbeda. Segera setelah seorang programmer menghadapi tugas yang sama setiap hari, dia menulis sebuah fungsi, modul, atau program untuk menjalankannya, dan tidak pernah kembali lagi."

"Setiap programmer biasanya menyelesaikan setiap tugas sekali seumur hidupnya."

"Sesuatu seperti ilmuwan atau insinyur desain yang menemukan sesuatu."

"Ah. Nah, peran apa yang paling penting dalam sebuah proyek?"

"Hmm, bagaimana aku harus menjawabnya. Mudah mengatakan mana yang paling penting, tapi mengidentifikasi yang paling tidak penting itu sulit."

" Pekerjaan utama seorang penguji ( Q uality  A ssurance, QA )  adalah memantau status program dan segera melaporkan bug. Semakin cepat seorang penguji menemukan bug, semakin banyak yang dapat diperbaiki.  Penguji yang baik lebih memengaruhi kualitas produk daripada seorang programmer yang baik melakukannya ."

"Mengapa programmer tidak dapat menguji program mereka sendiri. Lagi pula, bukankah mereka lebih tahu daripada penguji apa yang berhasil dan tidak?"

"Seorang programmer yang baik tidak mampu menjadi penguji yang baik. Seorang programmer tahu bagaimana program bekerja dengan sangat baik, jadi dia selalu menggunakannya dengan cara tertentu. Berbeda dengan pengguna biasa yang menggunakan program sesuka mereka. "

"Selain itu, penguji tidak menguji apa yang belum bekerja. Penguji menguji fungsionalitas atau bagian dari program yang menurut pemrogram sudah bekerja hampir sempurna."

"Dan ketika penguji menemukan banyak sekali bug dalam fungsi itu, dan pemrogram memperbaikinya, maka produk tersebut benar-benar mendekati kesempurnaan."

" Tugas utama programmer ( S oftware  D eveloper  Engineer ,  D eveloper ,  SDE ) adalah mengimplementasikan fungsionalitas baru. Atau, lebih sederhananya, untuk melakukan tugas yang diberikan kepadanya. Saat programmer diberi tugas dengan fitur baru , mereka menjalankannya. Saat diberi bug, mereka memperbaiki bug."

"Tapi terkadang ada tugas yang lebih menantang, misalnya, membuat arsitektur untuk program atau bagian darinya. Semakin baik arsitektur yang diusulkan, semakin mudah menyelesaikan sesuatu di masa depan."

"Masalahnya adalah bahwa arsitektur perlu dipilih sejak awal, tetapi baru setelah Anda berada di tengah pengembangan, jelas apakah Anda memilih arsitektur yang tepat."

"Selain itu, jika arsitekturnya berhasil dan programnya menjadi hebat, maka pelanggan mungkin ingin menggunakannya sebagai dasar untuk versi baru dari program tersebut."

"Inilah yang saya maksud."

"Apa pun arsitektur yang Anda pilih, akan selalu ada banyak perubahan, penambahan, dan fitur baru yang tidak diperhitungkan oleh arsitektur."

"Ini contoh yang bagus."

"Seorang pelanggan meminta Anda membangun gedung 5 lantai, jadi Anda mendesain arsitektur dan membangun rumah."

"Kemudian pelanggan meminta untuk menambahkan cerita lain, lalu cerita lain, dan seterusnya."

"Tapi dinding lantai pertama tidak dirancang untuk beban sebanyak itu, begitu pula fondasinya. Jadi semuanya harus diperbaiki."

"Tapi setelah gedung 5 lantai selesai, bagaimana jika pelanggan langsung memutuskan dia menginginkan gedung 50 lantai?"

"Akan lebih mudah untuk menghancurkan struktur yang ada dan membangun kembali semuanya dari awal..."

"Tapi saya punya satu saran untuk Anda tentang arsitektur."

"Arsitektur aplikasi harus, pertama dan terutama, fleksibel, yang berarti Anda tidak perlu memulai dari awal jika Anda memutuskan untuk mengulang setengah dari aplikasi. Jenis arsitektur ini biasanya disebut fleksibel dan modular . "

" Pekerjaan utama manajer proyek adalah membuat keputusan. Manajer proyek adalah orang yang melihat gambaran besar dan membuat keputusan berdasarkan perspektif tersebut."

"Misalkan selama pengembangan menjadi jelas bahwa tugas tertentu tidak akan selesai seperti yang direncanakan. Manajer proyek kemudian dapat:"

" a)  mencoba bernegosiasi dengan pelanggan untuk mengubah tugas"

" b)  mengalokasikan lebih banyak waktu untuk tugas"

" c)  mendatangkan pemrogram yang lebih berpengalaman dari proyek lain."

"Dan masih banyak kemungkinan lainnya."

"Setiap opsi mengharuskan Anda untuk mengorbankan sesuatu, dan tugas manajer adalah meminimalkan total kerugian dari pengorbanan tersebut. "

"Misalnya, misalkan pesaing mencuri programmer utama dengan menawarinya uang dua kali lebih banyak."

"Manajer proyek dapat:"

" a)  tidak melakukan apa-apa. Pemrogram akan pergi, dan proyek kemungkinan besar akan tertinggal dan terkena penalti."

" b)  menggandakan gajinya. Kemudian semua orang dalam tim juga akan menginginkan kenaikan gaji. Jika Anda memberikan lebih banyak uang kepada mereka semua, maka biaya proyek akan meningkat dan mungkin menjadi tidak menguntungkan."

" c)  beberapa opsi lain yang Anda pikirkan."

"Jadi begitu."

"Dengan manajer proyek yang buruk, tim yang baik biasanya memperpanjang proyek, tapi tidak selalu."

"Manajer yang baik dengan tim pemrogram rata-rata hampir selalu menyelesaikan proyek lebih cepat daripada manajer yang buruk dengan tim pemrogram yang hebat."

"Jadi begitu."

"Oke, mari kita istirahat sejenak, lalu kita lanjutkan."