Jumlah pekerjaan rutin dalam pengembangan perangkat lunak dan pengaruhnya terhadap estimasi

Saya yakin bahwa jumlah pekerjaan rutin dalam pengembangan perangkat lunak adalah - dan seharusnya - relatif kecil, jika tidak dapat diabaikan, dan bahwa ini adalah masalah mendasar dari estimasi perangkat lunak.

Izinkan saya menjelaskan bagaimana saya sampai pada kesimpulan ini dan beri tahu saya jika argumentasi tersebut memiliki kelemahan serius:

1. Semua yang dapat diperkirakan dengan akurasi tinggi adalah pekerjaan rutin, artinya hal-hal yang telah dilakukan sebelumnya. Semua jenis pekerjaan lain yang melibatkan penelitian dan kreativitas tidak dapat benar-benar diperkirakan, setidaknya tidak dengan akurasi, katakanlah, +/- 20 persen.

2. Pengembangan perangkat lunak adalah tentang menghindari tugas yang berulang. Salah satu prinsip dasarnya adalah KERING (jangan ulangi sendiri). Setiap kali seorang programmer menemukan dirinya melakukan hal-hal yang berulang, saatnya untuk menemukan abstraksi yang menghindari pengulangan ini. Abstraksi-abstraksi ini dapat berupa hal-hal sederhana seperti mengekstraksi kode yang diulang menjadi suatu fungsi atau meletakkannya dalam satu lingkaran. Mereka juga bisa lebih kompleks seperti membuat bahasa khusus domain. Bagaimanapun, mengimplementasikannya akan melibatkan penelitian (adakah yang pernah melakukan ini sebelumnya?) Atau kreativitas.

Dari dua poin ini saya menarik kesimpulan di atas.

Sebenarnya saya sudah lama bertanya-tanya mengapa hubungan ini tidak disebutkan dalam setiap diskusi, posting blog atau artikel lain tentang estimasi perangkat lunak. Apakah ini terlalu teoretis? Apakah asumsi saya salah? Atau itu terlalu sepele - tetapi kemudian, mengapa sebagian besar pengembang yang saya tahu percaya bahwa mereka dapat melakukan estimasi dengan akurasi +/- 20 persen atau lebih baik?

Pada setiap proyek tertentu ini mungkin benar. Namun jika Anda bekerja pada banyak, proyek serupa untuk perusahaan yang berbeda selama bertahun-tahun Anda mungkin menemukan diri Anda 'memecahkan' pada dasarnya masalah yang sama berkali-kali dengan hanya sedikit variasi.

Sebagai contoh saya sudah menulis layer akses data berkali-kali sekarang saya lebih suka melakukannya 'long hand' daripada menggunakan ORM populer bulan ini. Ini lebih cepat dan lebih mudah bagi saya untuk berurusan dengan 'masalah rutin' dengan solusi yang diketahui daripada menemukan dan memecahkan kebiasaan baru dalam komponen pihak ke-3.

Jelas saya bisa menulis ORM saya sendiri untuk menyederhanakan kode berulang tanpa menambahkan kebiasaan yang tidak diketahui dalam sistem orang lain, tetapi kode ini akan menjadi milik perusahaan tempat saya bekerja saat itu, dan pengembang lain akan merasa sama nyentriknya dengan ORM pihak ke-3 lainnya.

Demikian pula, dalam pengalaman saya, kebanyakan pemrograman adalah otomatisasi proses bisnis dan meskipun masing-masing bisnis suka berpikir bahwa proses mereka unik untuk mereka; Pada kenyataannya mereka tidak.

Bukan untuk mengatakan bahwa estimasi itu mudah! Itu lebih mudah, tetapi saya menemukan bahwa hari ini masalah estimasi adalah karena kurangnya persyaratan daripada waktu yang dihabiskan untuk pengkodean.

Persyaratan cenderung masuk dalam tiga kategori:

1. Samar-samar, detail diserahkan kepada pengembang.

"Buatkan saya situs web, itu harus keren dan jual widget saya"

Ini cenderung yang paling mudah untuk diperkirakan, karena ketika masalah sulit yang tidak terduga terjadi, Anda dapat dengan mudah mengubah persyaratan menjadi sesuatu yang secara fungsional setara dan menghindari masalah.

2. Sangat spesifik

"Buat warna latar belakang tajuk # ff1100"

Sangat cepat dilakukan dan, sekali lagi, mudah diperkirakan. Tapi! persyaratannya pasti akan berubah. "Hmm tidak pada pikiran kedua, coba ini merah lainnya" atau "Tunggu! Maksudku hanya pada satu halaman itu!" jadi rentang waktu sebenarnya dari "berapa lama sampai saya puas dengan warna header" tidak ada hubungannya dengan perkiraan pengkodean

3. Tidak jelas, rinciannya diasumsikan

"Jadikan aku situs web, (sama seperti facebook)"

Di sini, banyak asumsi yang tidak dinyatakan, "tentu saja Anda menginginkan logo yang berbeda", "seharusnya memiliki pengguliran tak terbatas", "harus dapat diskalakan ke 1 miliar pengguna!" secara efektif mengendalikan estimasi. Entah dev memikirkan segalanya dan mendorong perkiraan melebihi harapan "1 jam kerja", atau mereka memikirkan / menganggap hanya fitur dasar yang diperlukan dan memberikan estimasi terlalu rendah. "oh satu atau dua minggu, saya anggap kamu hanya ingin meletakkan facebook di iframe kan?"

Dengan pengalaman, pengkodean sangat cepat, tetapi mendesain persyaratan (biasanya) sedikit sulit, dan ini semakin didorong kembali ke non-coders. Dengan metodologi gesit, meningkatkan kecepatan pengkodean dengan memindahkan tanggung jawab ini ke 'bisnis' daripada pengembang.

mengapa sebagian besar pengembang yang saya tahu percaya bahwa mereka dapat melakukan perkiraan dengan akurasi +/- 20 persen atau lebih baik?

Karena kami memperkirakan kesabaran kami dengan masalah jauh lebih dari masalah yang sebenarnya.

Jika saya akan menghidupkan bola yang memantul, saya bisa menghabiskan waktu sehari, seminggu, sebulan, atau setahun dan masih memiliki animasi bola memantul. Mudah-mudahan itu akan terlihat lebih baik semakin banyak waktu yang saya habiskan untuk itu tetapi pada titik tertentu saya menjadi konyol.

Berapa banyak upaya yang saya lakukan untuk membuat bola memantul adalah fungsi dari waktu yang masuk akal untuk dihabiskan untuk itu. Jika level skill saya tidak memotongnya, saya mungkin berakhir dengan bola yang hanya ada di sana. Tetapi ketika tenggat waktu datang haruskah saya membiarkan tenggat waktu lewat atau setidaknya mendapatkan bola di layar? Waterfall bersikeras bola memantul dan sehingga jadwal tergelincir. Agile mengatakan bawa bolanya ke sana. Setidaknya kita akan mengetahui seberapa besar perhatian orang terhadap pantulan. Jadi kualitasnya tergelincir.

Saya mencoba untuk memastikan bola saya memantul tetapi ketika batas waktu datang lebih baik untuk menghasilkan bola statis daripada tidak sama sekali. Jadi saya memperkirakan waktu berdasarkan apa yang tampaknya cukup banyak waktu untuk dihabiskan pada masalah sebelum berbicara tentang alternatif. Terkadang bola tidak akan memantul. Terkadang tidak masalah. Menghilang selama sebulan tidak OK.