Pembuatan vs Pengembangan Perangkat Lunak [ditutup]

Sering dikatakan bahwa industri perangkat lunak belum matang dibandingkan dengan manufaktur. Khususnya berkaitan dengan proses yang didorong.

Pertanyaan : Bisakah kita sebagai pengembang belajar dari proses industri manufaktur? Bisakah mengadopsi proses mereka meningkatkan tingkat keberhasilan pengembangan perangkat lunak?

Pandangan saya : Dalam pembuatan, penciptaan suatu produk sangat didorong oleh proses. Anda mungkin memiliki pabrik tempat setiap orang memiliki serangkaian tugas spesifik yang mereka ikuti. Seorang pekerja (atau robot) dapat mengencangkan sekrup sepanjang hari. Kemudian tugas selanjutnya dalam proses dilakukan oleh spesialis berikutnya. Para pekerja (dan robot) tidak menghalangi proses atau membuat sesuatu "dengan cepat". Bagian-bagian berputar melalui proses, dan output adalah produk jadi. Ini bekerja dengan baik dan perusahaan mencapai 99,99966% produk bebas cacat. Perusahaan mengatasi ketidakefisienan dari waktu ke waktu. Ini mengesankan dan sangat baik mungkin merupakan tanda industri yang matang.

Dalam pembuatan proses yang didefinisikan secara harfiah dapat menciptakan produk jadi. Saya tidak berpikir ini terjadi pada perangkat lunak. Kami mungkin memiliki proses untuk kontrol sumber, tinjauan kode, lembar periksa, pengumpulan persyaratan, SDLC, dll. Tetapi menjalankan proses-proses itu tidak dengan sendirinya menciptakan produk jadi. Proses-proses ini mungkin bermanfaat, tetapi bersifat ortogonal bagi ciptaan yang sebenarnya.

Misalkan perusahaan Anda dikontrak untuk membuat perangkat lunak yang akan mencari jutaan gambar untuk menemukan wajah seorang penjahat. Terlepas dari proses yang didorong oleh lingkungan yang berat, pengembang harus terlibat dalam menciptakan hal-hal "dengan cepat". Melakukan hal-hal dengan cepat bertentangan dengan semangat manufaktur. Proses pembuatan yang baik dapat dijalankan tanpa dipikirkan oleh robot.

Untuk penciptaan algoritma kompleks yang belum dapat dipahami dalam pikiran manusia, adalah suatu keharusan untuk menciptakan sesuatu dengan cepat. Pengembangan perangkat lunak bukanlah proses berikut, tetapi penciptaan proses yang akan dilakukan oleh komputer. Itu adalah perbedaan mendasar. Tidak peduli berapa banyak proses ortogonal yang kita lakukan di sekitar pengembangan, kita akan selalu menggunakan untuk melakukannya "dengan cepat" ketika datang ke penciptaan.

Semua orang yang saya ajak bicara tampaknya setuju dengan pola pikir manufaktur. Apakah saya sendirian dalam pikiran saya?

Perbedaan mendasar antara pengembangan perangkat lunak dan manufaktur adalah bahwa untuk perangkat lunak, fase desain praktis adalah semuanya. Produksi aktual (bagian jalur perakitan dalam pembuatan tradisional) adalah masalah menyalin beberapa file di sekitar. Dalam perangkat lunak, desain produk adalah produk.

Jadi ya, kita dapat belajar dari proses manufaktur, tetapi hanya jika kita ingat bahwa kita harus melihat fase desain, bukan fase produksi, dan bahwa banyak proses manufaktur dibangun untuk mengatasi keterbatasan spesifik dari rantai produksi yang mahal , yang sama sekali tidak berlaku untuk perangkat lunak.

Salah satu contoh model proses yang bekerja sangat baik dalam perangkat lunak, tetapi seringkali gagal dalam desain produk, adalah desain berulang - Anda mulai dengan prototipe minimal, dan menambahkan fitur dengan setiap iterasi. Membangun mobil prototipe untuk melihat seperti apa desain knob jendela belakang yang baru itu konyol, tetapi dalam perangkat lunak, masuk akal (tekan saja F5 dan tunggu beberapa detik - voila, siap untuk menguji drive).

Jika kita melihat proses desain produk, industri terbaik untuk melihat jatuh ke dalam dua kategori:

• yang di mana produksi dapat direalisasikan pada tingkat komoditas; mis. industri rekaman (1% atau kurang dari harga untuk CD adalah memanggang dan mencetak), media grafis, dll.
• yang jumlahnya sangat rendah sehingga fase desain adalah faktor biaya yang paling menonjol (barang mewah, produk yang sangat disesuaikan, pasar khusus ...)

Ini adalah kesalahan mendasar untuk mencoba dan menerapkan proses dari manufaktur fisik ke pengembangan perangkat lunak: pengembangan perangkat lunak tidak berulang (jika ada di pekerjaan Anda, cari pekerjaan lain), itu hanya dapat diprediksi sebagian, hanya ada sedikit keterbatasan fisik ( kecepatan perangkat keras menjadi satu), dan baik pendekatan yang diambil maupun hasilnya bisa sangat pribadi. Menerapkan filosofi jalur perakitan pada apa yang pada dasarnya merupakan masalah pemikiran analitik dan kreatif dapat (dan sering kali demikian) memiliki efek yang menghancurkan.

Jika Anda ingin menulis perangkat lunak yang persis sama berulang-ulang (bukan hanya menyalinnya), Anda dapat melakukannya dengan sangat efisien melalui jalur perakitan.

Tetapi pembuatan perangkat lunak bukanlah tugas yang berulang, masing-masing modul adalah unik. Itu sebabnya perbandingan untuk manufaktur tidak valid.

Saya pikir jawaban yang Anda cari berlaku atau realistis di sini. Apa yang saya rasa ingin Anda ketahui adalah bagaimana kami dapat mengatur proses kami menjadi lebih seperti industri manufaktur. Alih-alih, saya pikir pertanyaan sesungguhnya menjadi "Mengetahui apa yang manufaktur dan industri lain lakukan untuk membangun produk berkualitas apa yang bisa kita pelajari?" atau "Apa yang dapat dilakukan industri perangkat lunak untuk meningkatkan kualitas?"

Sayangnya jawaban untuk ini tidak jelas karena industri perangkat lunak itu sendiri masih tidak tahu jawabannya. Untuk dapat menjawab ini, industri perangkat lunak perlu melakukan penelitian tentang apa yang berhasil dan mengapa? Misalnya ada penelitian yang menunjukkan bahwa Test Drive Design (TDD) mengarah pada peningkatan kualitas. Meskipun masalah produktivitas tampaknya masih belum terjawab atau setidaknya belum sepenuhnya dipahami. Sejauh apa bukti menunjukkan sejauh ini:

• Ulasan kode sangat bagus, dan terbukti menemukan bug terbanyak, tetapi efektivitas tinjauan turun cukup tajam setelah satu jam pertama tinjauan. Mengingat bahwa rata-rata orang hanya dapat membaca beberapa ratus baris kode per jam, ini menunjukkan bahwa pengembang harus memecah perubahan menjadi potongan-potongan kecil.
• Semakin lama waktu yang dibutuhkan untuk menemukan bug semakin mahal (waktu dan uang) untuk memperbaikinya. Jadi, jika pengembang menemukannya saat menulis kode, kami katakan biayanya adalah 1. Jika yang belum menemukannya menemukannya nanti biayanya 10, jika EVT menemukannya biayanya 100 dan seterusnya.
• Ada beberapa bukti yang menunjukkan semakin kompleks persyaratannya semakin kompleks solusinya dan semakin kompleks solusinya, semakin besar kemungkinan akan ada bug.

Ada seorang pria bernama Greg Wilson yang memberikan ceramah yang bagus tentang hal ini beberapa tahun yang lalu. Berikut ini tautan ke ceramah: Greg Wilson Talk

Selain itu, saya akan mengatakan melihat kembali pada karya Anda sendiri dan menemukan tema dengan jenis kesalahan yang Anda perkenalkan serta bagian mana yang Anda perjuangkan. Kompilasi hasil ini dan kemudian buat daftar periksa untuk dimasukkan ke dalam proses Anda di tempat yang berbeda untuk membantu Anda melakukan pekerjaan yang lebih baik. Secara pribadi saya telah melihat kembali beberapa tahun terakhir dari pekerjaan saya dan menemukan bahwa ada beberapa tema umum untuk masalah yang saya perkenalkan. Secara khusus saya telah menemukan itu

• Saya tidak sering ingat untuk membangun semua varian yang menyebabkan saya melanggar build.
• Sering kali saya tidak memikirkan hal berikut untuk setiap perubahan. Kasus bagus, kasus buruk dan kasus luar biasa.
• Semua skenario yang mungkin terjadi mungkin terjadi. Perhatikan bahwa ini sangat sulit karena ada banyak dari mereka.

Karena saya telah menemukan beberapa tema untuk kesalahan saya, saya telah membuat daftar periksa yang saya gunakan secara otomatis, karena memasukkan mereka ke dalam skrip saya, yang membantu saya mengatasi masalah ini. Ada sebuah buku yang ditulis tentang panggilan ini "Manifesto Daftar Periksa" yang merinci bagaimana mereka dapat dimanfaatkan dengan baik. Secara pribadi saya merasa sangat berwawasan luas.

Ini bukan tentang mengadopsi proses "mereka". Ini tentang mengadopsi proses "beberapa", yang tidak memiliki kerugian biasa dan dihargai menggunakan proses jalur perakitan untuk upaya kreatif. Hal yang paling penting untuk diperhatikan di sini adalah gagasan bahwa kualitas proses diterjemahkan langsung ke kualitas produk.

Proses terbaik, atau produk dalam hal ini, adalah yang sesuai dengan skenario penggunaan yang dimaksud seperti tangan dalam sarung tangan. Yang perlu dipikirkan adalah bahwa bagian penulisan kode sebenarnya adalah satu-satunya yang, setidaknya pada tingkat makroskopik, tidak berulang. Semua aspek lainnya, seperti kontrol versi, pelacakan bug, perencanaan, estimasi, pengukuran, dll. Adalah, dan penggunaan standar, proses yang disesuaikan dan terbukti dapat membantu Anda setidaknya di bidang ini.

Jadi tidak, proses pengembangan perangkat lunak tidak dapat disamakan dengan produksi jalur perakitan dan karena itu "prosesnya" tidak OK, tetapi fase desain desain / desain produk dari produk dalam industri manufaktur dapat menjadi sumber inspirasi.

Pertanyaan: Bisakah kita sebagai pengembang belajar dari proses industri manufaktur? Bisakah mengadopsi proses mereka meningkatkan tingkat keberhasilan pengembangan perangkat lunak?

Jawab: Ya tentu saja. Ada banyak pelajaran yang dapat dipelajari oleh para pengembang perangkat lunak dari manufaktur meskipun fakta bahwa pengembangan perangkat lunak adalah proses kreatif. Pengembangan perangkat lunak itu sendiri adalah suatu proses, dan itu mencakup banyak proses lainnya. Semakin baik Anda dapat mendefinisikan dan mengontrol proses-proses tersebut, semakin baik Anda dapat mengontrol proses pengembangan perangkat lunak secara keseluruhan. Itu tidak berarti bahwa Anda harus meresepkan setiap penekanan tombol yang dibuat pengembang; itu hanya berarti bahwa sebagai pengembang, Anda secara alami melakukan tugas-tugas dalam urutan tertentu, dan tugas-tugas itu seringkali dapat dikelola. Berikut ini beberapa contohnya:

• pelacakan cacat: Ketika bug diamati atau dilaporkan, apa yang terjadi padanya? Apakah Anda menuliskannya pada secarik kertas dan menempelkannya pada lonjakan 'investigasi'? Apakah nanti Anda menghapus memo itu satu per satu, selidiki, dan akhirnya memindahkannya ke lonjakan 'yang diselesaikan'? Jika Anda melakukannya tanpa gagal setiap kali Anda mendapatkan laporan bug, Anda memiliki proses yang terdefinisi dengan baik, terukur, dan Anda mungkin jauh lebih baik daripada seseorang yang memiliki sistem pelacakan cacat yang canggih dan berteknologi tinggi yang sangat memberatkan bahwa beberapa anggota tim melacak bug dengan cara lain, atau tidak sama sekali.

• kontrol versi: Ada kemungkinan besar bahwa Anda menggunakan kontrol versi di mana Anda bekerja, dan kontrol versi jelas jauh lebih berguna ketika semua orang menggunakannya dengan cara yang sama.

• desain produk: Apakah Anda memutuskan fitur mana yang akan diterapkan dengan melemparkan anak panah ke dinding yang ditutupi dengan kertas tempel? Jika demikian, Anda punya proses. Saya tidak berpikir siapa pun akan berpendapat bahwa ini adalah proses yang hebat, tetapi setidaknya itu adalah titik awal. Jika Anda mengubah proses, bagaimana Anda bisa tahu dengan pasti bahwa perubahan Anda sebenarnya merupakan peningkatan kecuali jika Anda mengukur sebelum dan sesudah? Kamu tidak bisa

• ulasan kode: Apakah tinjauan kode bermanfaat jika proses pengkajian dan kriteria pengkodean berubah untuk setiap tinjauan? Tentu saja tidak.

• siklus hidup pengembangan perangkat lunak: Seluruh analisis -> desain -> implementasi -> tes -> siklus pemeliharaan adalah proses yang harus didefinisikan dengan jelas.

Dalam setiap kasus ini, memiliki proses yang ada memungkinkan Anda mengukur input dan output dan menentukan apakah perubahan yang Anda buat memiliki efek yang diinginkan. Tidak memiliki proses berarti bahwa Anda hanya menebak ketika Anda mencoba meningkatkan cara Anda bekerja. Ini benar-benar tentang manufaktur, dan masuk akal untuk meminjam alat pemurnian berturut-turut jika sesuai.

Ada seluruh bidang yang dikhususkan untuk mendefinisikan dan meningkatkan proses yang digunakan untuk membuat dan memelihara perangkat lunak; itu disebut rekayasa perangkat lunak . Tidak mengherankan bahwa Anda memiliki pertanyaan tentang proses pengembangan saat membaca tentang CMMI - CMMI adalah produk dari Institut Rekayasa Perangkat Lunak .

Pengembangan perangkat lunak telah mengadopsi banyak konsep manufaktur:

• Sulit untuk tidak melihat pengaruh suku cadang Eli Whitney yang dapat dipertukarkan pada pengembangan OOP dan berbasis komponen .

• Teknik manajemen proyek yang digunakan dalam pengembangan perangkat lunak tidak jauh berbeda dari yang dikembangkan untuk pembuatan. Sebagai hanya dua contoh, dunia perangkat lunak baru saja mengadopsi konsep Kanban yang dikembangkan beberapa dekade yang lalu di Toyota, dan grafik Gantt digunakan dalam pembuatan jauh sebelum komputer elektronik pertama dibangun.

• Metodologi manajemen kualitas seperti Six Sigma yang dikembangkan untuk manufaktur telah disesuaikan dengan pengembangan perangkat lunak.

Terlepas dari proses yang didorong oleh lingkungan yang berat, pengembang harus terlibat dalam menciptakan hal-hal "dengan cepat".

Apakah Anda memberi tahu saya bahwa seseorang akan memutuskan sendiri untuk menambahkan tambalan ke paket pengenalan wajah, dan mereka akan menambahkannya ke dalam pembuatan produksi tanpa terlebih dahulu menciptakan masalah dalam sistem pelacakan, setelah desain ditinjau, memeriksa kode ke dalam kontrol versi, atau meminta orang pengujian melihatnya terlebih dahulu? Proses kami membutuhkan hal-hal itu untuk beberapa alasan yang sangat bagus. Jika dengan "on the fly" yang Anda maksudkan "di luar proses," itu tidak dapat diterima.

Melakukan hal-hal dengan cepat bertentangan dengan semangat manufaktur.

Sekali lagi, jika "on the fly" berarti "di luar proses," Anda benar. Tetapi jika Anda berpikir bahwa manufaktur tidak memerlukan pemikiran cepat dan mengembangkan solusi kreatif untuk masalah, Anda salah. Semua jenis masalah muncul dalam proses pembuatan - cupcake tidak memiliki cukup krim mengisi, permukaan yang dicat tiba-tiba berhenti melewati uji awal QA, 20% dari bagian jadi hilang cincin penahan penting, sistem adonan pencampur bagian penting ...