Jumlah pekerjaan rutin dalam pengembangan perangkat lunak dan pengaruhnya terhadap estimasi

11

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?

Frank Puffer
sumber
7
99% dari semua pengembangan perangkat lunak di luar area seperti kernel telah dilakukan ribuan kali sebelumnya. Terlalu banyak pengembang yang hanya ingin melakukan segalanya dengan cara baru yang mewah, menciptakan kembali masalah lama yang sama berulang-ulang.
Bent
@Bent: Jadi Anda mengatakan bahwa pengembangan perangkat lunak sebagian besar copy-and-paste? Saya tahu bahwa banyak pengembang bekerja seperti itu dan sering menemukan bahwa itu mengarah pada kode yang tidak dapat dipertahankan. Tapi itu cerita yang berbeda. Bahkan jika seseorang bekerja seperti itu, dia harus mencari tahu apa yang harus disalin dan dari mana. Ini adalah sesuatu yang juga akan saya pertimbangkan sebagai pekerjaan penelitian.
Frank Puffer
1
@ rwong: Tentu saja masuk akal untuk menggunakan perpustakaan. Tetapi menemukan fungsi yang tepat di perpustakaan dan cara yang tepat untuk menggunakannya adalah pekerjaan penelitian (jika lib kompas dan / atau Anda tidak mengetahuinya dengan baik) atau sepele (jika Anda tahu fungsi itu). Apa yang Anda sebut 'kode lem' dalam pengalaman saya sering kali rumit. Menerapkannya bukanlah pekerjaan rutin yang perlu.
Frank Puffer
1
@ JohnR.Strohm: Saya tidak membaca buku-buku spesifik ini tetapi saya akrab dengan dasar-dasar COCOMO - tidak pernah menggunakannya dalam praktiknya. Saya juga telah membaca dua atau tiga buku lain oleh DeMarco. Bisakah Anda memberi petunjuk tentang konten spesifik apa yang terkait dengan pertanyaan saya?
Frank Puffer
2
@FrankPuffer, "Ekonomi Rekayasa Perangkat Lunak" Boehm diperlukan bacaan untuk estimasi perangkat lunak. Buku Demarco tidak jauh di belakang. Jawaban singkatnya adalah ini: Jika Anda cukup familiar dengan apa yang harus dilakukan oleh perangkat lunak untuk memperkirakannya, Anda cukup akrab untuk menganggapnya relatif rutin.
John R. Strohm

Jawaban:

11

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.

  1. 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

  1. 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.

Ewan
sumber
Saya sangat setuju dengan apa yang Anda tulis tentang persyaratan yang tidak memadai, tapi itu cerita yang berbeda. Pada bagian pertama dari jawaban Anda, Anda mengatakan bahwa Anda sering terus menggunakan teknik-teknik terkenal sehingga sebagian besar pekerjaan Anda menjadi rutin. Anda sengaja melakukannya tanpa abstraksi tambahan. Ini mungkin bekerja dengan baik untuk waktu yang singkat, mungkin 2-5 tahun, tergantung pada teknologi yang Anda gunakan. Tetapi kemudian Anda mungkin memperhatikan bahwa Anda belum meningkatkan proses Anda sebanyak pesaing Anda. Selain itu, pengembang lain yang akan mempertahankan kode Anda nanti mungkin mengalami masalah.
Frank Puffer
Jelas tidak seperti saya tidak pernah menggunakan barang pihak ke-3. Intinya adalah jika Anda tahu bagaimana melakukan sesuatu dengan alat X, perkiraannya mudah
Ewan
Tidak hanya estimasi tetapi juga implementasinya menjadi mudah dalam hal ini. Jika seluruh proyek Anda seperti ini, Anda beruntung. Tetapi dalam pengalaman saya ini hanya terjadi pada proyek-proyek kecil. Semua proyek yang lebih besar (> 10 hari) saya terlibat dalam membutuhkan beberapa konsep atau teknologi baru dan itulah yang menyebabkan sebagian besar pekerjaan, membuat upaya untuk hal-hal standar diabaikan.
Frank Puffer
Mari kita tidak masuk ke perang api 'siapa programmer terbaik'. Semua yang saya katakan adalah lebih banyak hal yang telah Anda lakukan sebelum lebih sedikit barang baru yang ada. Jika semua proyek Anda mengamanatkan penggunaan teknologi baru untuk sebagian besar fitur ... Tampaknya aneh
Ewan
@Wan "konsep atau teknologi". Bagi saya yang pertama cenderung berhubungan dengan aturan bisnis dan / atau apa yang diinginkan desainer. Ini bukan hanya tentang teknologi baru.
Izkata
6

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.

candied_orange
sumber
Poin bagus, jadi pada dasarnya Anda mengatakan bahwa perkiraan tersebut harus didasarkan pada nilai apa yang dimiliki fitur tertentu untuk pelanggan (atau pemilik produk). Secara pribadi saya suka pendekatan ini tetapi dalam pengalaman saya ini bukan bagaimana estimasi perangkat lunak umumnya dipahami, bahkan dalam pengaturan yang gesit. Salah satu kelemahannya adalah sering kali Anda tidak memiliki informasi tentang nilai pelanggan dari suatu fitur. Kelemahan lainnya adalah tidak dapat menangani paket kerja yang tidak secara langsung menghasilkan fitur yang terlihat oleh pelanggan.
Frank Puffer
@ Frankpuffer Saya tidak setuju bahwa metode gesit tidak membuat ini jelas. SCRUM pada khususnya bahkan tidak meminta pengembang untuk memperkirakan sampai nilai fitur sangat tinggi sehingga sebenarnya dijadwalkan untuk dilakukan, yaitu, hanya dalam estimasi waktu. Metode lincah sangat cocok untuk ini: pertama mengidentifikasi fitur dengan nilai bisnis tertinggi, kemudian memperkirakannya, kemudian MELAKUKANNYA, dan melihat berapa lama sebenarnya. Bilas ulangi bilas. Setelah beberapa siklus ini, Anda akan memiliki ide yang sangat bagus dari perkiraan vs waktu dev yang sebenarnya.
RibaldEddie