Bagaimana menjelaskan bahwa sulit memperkirakan waktu yang diperlukan untuk proyek perangkat lunak yang lebih besar?


37

Saya seorang pengembang junior dan saya merasa sulit untuk memperkirakan berapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek perangkat lunak yang lebih besar. Saya tahu cara menyusun arsitektur secara umum, tetapi sulit bagi saya untuk mengetahui detail apa yang harus saya lakukan dan masalah apa yang harus saya pecahkan. Jadi sulit untuk memperkirakan berapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek yang lebih besar, karena saya tidak tahu masalah apa yang harus saya selesaikan dan berapa lama untuk menyelesaikannya.

Bagaimana saya menjelaskan hal ini kepada orang yang bukan pengembang perangkat lunak ?


5
Penasaran: mengapa pekerjaan Anda sebagai pengembang junior menjelaskan hal ini kepada pengembang non-perangkat lunak? Adakah seseorang dalam kelompok kerja atau rantai manajemen Anda yang dapat membantu Anda dengan proses meyakinkan siapa pun yang perlu Anda yakinkan?
Alex Feinman

@ Alex: Tidak, itu bukan orang di perusahaan yang sama. Hanya orang yang punya ide untuk melakukan startup. Dan saya satu-satunya pengembang yang memiliki kontak dengannya.
Jonas



Jawaban:


48

Anda bisa memintanya untuk memperkirakan berapa lama yang dibutuhkan untuk mengakses beberapa lokasi yang jauh di sudut dunia yang tidak berpenghuni. Sebagai contoh ekstrem, mari kita pilih beberapa puncak yang kurang diketahui di Himalaya, di mana sangat sedikit (jika ada) orang yang pernah naik. Dia akan membutuhkan banyak persiapan dan latihan sebelum memulai perjalanan, ditambah banyak izin, yang masing-masing dapat menunda perjalanan selama berbulan-bulan hingga bertahun-tahun ... dan tim pendukung yang baik ... kemudian sekali di atas bukit Kemiringan, dia perlu menunggu dan berdoa untuk cuaca yang baik untuk mulai mendaki ke puncak ... dll. Sebagian besar dari ini sulit untuk diperkirakan, bahkan dengan pengalaman sebelumnya.

Dan intinya adalah: setiap proyek perangkat lunak sedikit seperti mendaki gunung baru, di mana tidak ada yang pernah ada sebelumnya, jadi tidak ada yang memiliki pengalaman langsung sebelumnya. Pengembang berpengalaman mungkin telah mengumpulkan pengalaman pada proyek yang kurang lebih serupa , tetapi akan selalu ada elemen dan kejutan baru - jika tidak, jika proyek perangkat lunak persis seperti beberapa proyek sebelumnya, sama sekali tidak ada gunanya melakukannya .


Semakin banyak hal yang tidak diketahui berarti semakin banyak ketidakpastian.
surfasb

9
Lupakan jauh. Minta mereka untuk memperkirakan - sampai saat ini - kapan mereka akan tiba di rumah dari pekerjaan malam ini. Bagaimana jika lalu lintas berbeda, bagaimana jika hujan mulai turun, bagaimana jika Anda menerima panggilan telepon saat mengemudi, dll. Jika sesuatu yang biasa, dan dilakukan sesering perjalanan pulang, tidak dapat diukur dengan tingkat akurasi apa pun - lalu bagaimana dapatkah kita berharap untuk melakukan estimasi yang lebih baik terhadap waktu yang diperlukan untuk mengimplementasikan beberapa perangkat lunak yang kompleks, yang memiliki variabel yang jauh lebih banyak dan lebih signifikan di dalamnya daripada perjalanan pulang kerja yang sangat sedikit.
quentin-starin

8
@ qes, saya menggunakan transportasi umum, jadi saya bisa tahu dengan akurasi sekitar 10% ketika saya akan tiba di rumah - saya pikir sebagian besar manajer proyek SW akan senang dengan tingkat akurasi ini ;-)
Péter Török

1
Sasaran proyek perangkat lunak juga berubah, jadi setelah mereka memperkirakan waktu yang dibutuhkan OP dapat bertanya apakah mereka masih tepat waktu setelah seseorang mengatakan kepada mereka untuk beralih ke puncak ketika mereka setengah jalan di atas yang pertama.
paul

18

Sudahkah Anda menjelaskan hal itu kepada orang tersebut? Anda adalah insinyur perangkat lunak profesional, sehingga orang yang Anda bangun perangkat lunak harus mempertimbangkan pengetahuan dan umpan balik Anda ketika datang ke desain dan implementasi sistem perangkat lunak.

The Cone Ketidakpastian mungkin titik yang baik mulai. Proyek perangkat lunak sulit untuk diperkirakan sampai lebih banyak rincian diketahui, yang terjadi kemudian dalam proyek. Selain itu, perubahan persyaratan juga akan mengubah perkiraan. Perkiraan awal Anda di awal proyek akan memiliki sejumlah besar variabilitas.

Anda mungkin tertarik pada teknik estimasi lain juga. Anda menyebutkan bahwa Anda hanya pengembang junior. Secara umum, pengembang yang lebih berpengalaman memiliki kemampuan yang lebih baik untuk memperkirakan karena mereka telah melihat lebih banyak masalah, menyelesaikannya, dan (mudah-mudahan) melacak perkiraan terhadap waktu aktual. Anda bisa memanfaatkan ini menggunakan teknik estimasi seperti wideband delphi atau perencanaan poker .

Sebagai pengembang junior, mulailah melacak perkiraan dan waktu aktual sekarang. Anda mungkin tertarik membaca tentang Proses Perangkat Lunak Pribadi yang dikembangkan di Institut Rekayasa Perangkat Lunak. Buku-buku PSP inti adalah A Disiplin untuk Rekayasa Perangkat Lunak , PSP: Proses Peningkatan Diri untuk Insinyur Perangkat Lunak , dan Pengantar Proses Perangkat Lunak Pribadi . Saya percaya bahwa Pengantar Proses Perangkat Lunak Pribadi akan mencakup topik yang menurut Anda paling bermanfaat. Saya pikir itu umumnya berlebihan bagi sebagian besar pengembang, tetapi memiliki beberapa ide bagus dan praktik baik yang dapat ditarik dan digunakan untuk meningkatkan produktivitas pribadi dan mengasah berbagai keterampilan (termasuk estimasi) yang akan terus Anda gunakan selama karier Anda.

Jika Anda akan melakukan lebih banyak pekerjaan dalam estimasi, saya akan sangat merekomendasikan dua buku Steve McConnell: Estimasi Perangkat Lunak: Demistifying the Black Art (berfokus pada estimasi sebagai seni dan sains) dan Pengembangan Cepat: Taming Wild Software Schedule (perangkat lunak umum proses rekayasa dan topik manajemen proyek).


7

Lihat literatur. Ada tumpukan material yang kompleks dan sering kali saling bertentangan, yang, sebagaimana dibuktikan oleh praktik (percobaan), tidak berfungsi seperti yang diharapkan. Setidaknya para akademisi terombang-ambing oleh tumpukan buku.

Harus dibaca: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

The Mythical Man-Month: Esai tentang Rekayasa Perangkat Lunak adalah sebuah buku tentang rekayasa perangkat lunak dan manajemen proyek oleh Fred Brooks, yang tema utamanya adalah "menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat membuatnya nanti". Gagasan ini dikenal sebagai hukum Brooks, dan disajikan bersama dengan efek sistem kedua dan advokasi pembuatan prototipe.

Pengamatan Brooks didasarkan pada pengalamannya di IBM sambil mengelola pengembangan OS / 360. Dia telah menambahkan lebih banyak programmer ke sebuah proyek yang tidak sesuai jadwal, sebuah keputusan yang kemudian akan secara kontra-intuitif menyimpulkan untuk menunda proyek lebih jauh. Dia juga membuat kesalahan dengan menyatakan bahwa satu proyek - menulis kompiler ALGOL - akan membutuhkan enam bulan, terlepas dari jumlah pekerja yang terlibat (diperlukan lebih lama). Kecenderungan para manajer untuk mengulangi kesalahan semacam itu dalam pengembangan proyek membuat Brooks menyindir bahwa bukunya disebut "The Bible of Software Engineering", karena "semua orang mengutipnya, beberapa orang membacanya, dan beberapa orang mengikutinya." Buku ini secara luas dianggap sebagai klasik pada elemen manusia dari rekayasa perangkat lunak ...


2

Cari tahu apa yang mereka rencanakan untuk lakukan dengan perkiraan ini. Dalam pikiran mereka, mereka ingin tahu apakah itu akan memakan waktu berbulan-bulan atau bertahun-tahun dan Anda mencoba untuk mendapatkan jam yang tepat (Typical Engineer).

Lihat apakah Anda dapat mengerjakan sepotong proyek dan kemudian mengumpulkan perkiraan yang lebih baik jika diperlukan.

Jika mereka terus mendorong, Anda akan dipaksa untuk merinci sebanyak mungkin tugas yang Anda bisa dan menerapkan kerangka waktu. Beri tahu mereka bahwa Anda akan memberi tahu mereka segera setelah Anda melihat sesuatu yang dapat memengaruhi estimasi dan melakukan penyesuaian. Orang biasanya berusaha menghindari kejutan.


1

Saya telah bertemu orang-orang yang mengklaim mereka dapat memperkirakan perangkat lunak, tetapi saya tidak tahu bagaimana mereka melakukannya. Tak satu pun dari mereka yang bisa menjelaskan bagaimana mereka melakukannya.

Sebagai konsultan, klien saya sering meminta saya untuk bekerja berdasarkan penawaran tetap. Karenanya saya perlu memperkirakan sehingga saya dapat menyiapkan tawaran yang realistis. Saya tidak pernah berhasil dalam hal ini. Orang akan berpikir saya akan menawar sesering yang saya underbid, tapi itu tidak pernah terjadi. Hasilnya adalah saya sering kehilangan banyak uang pada kontrak saya, dan akhirnya mendapatkan penghasilan jauh lebih sedikit daripada yang saya lakukan jika saya bekerja untuk sebuah perusahaan sebagai karyawan tetap.

Saya telah mencari buku yang akan mengajarkan saya cara memperkirakan perangkat lunak selama bertahun-tahun, tetapi saya belum menemukannya.

Adapun menjelaskan hal ini kepada seseorang yang bukan pembuat kode. Anda dapat menunjukkan bahwa tidak ada seorang pun di industri ini yang secara konsisten dapat memenuhi perkiraan mereka. Itu terjadi setiap saat bahwa produk perangkat lunak baru diumumkan sebelumnya, hanya untuk mengirim berbulan-bulan atau bertahun-tahun setelah tanggal yang awalnya diumumkan.

Jika perusahaan besar seperti Microsoft tidak dapat memperkirakan bagaimana memperkirakan waktu yang dibutuhkan untuk memproduksi produknya sendiri, bagaimana saya bisa?

Apakah saya dibayar per jam atau berdasarkan pekerjaan, klien saya selalu mengharapkan saya untuk memberikan perkiraan ini. Saya tidak tahu bagaimana mereka mengharapkan saya untuk memproduksinya ketika estimasi seperti itu tidak diajarkan di mana pun, dan saya tidak punya dasar rasional untuk estimasi saya.


1
Buku Steve McConnell's Estimasi Perangkat Lunak: Demistifying the Black Art benar-benar bagus untuk menjelaskan bagaimana perkiraan insinyur perangkat lunak. Anda dapat mempelajari teknik dan alat, tetapi satu-satunya cara untuk menjadi ahli dalam estimasi adalah dengan terus-menerus memperkirakan, belajar dari perkiraan Anda, dan mengulanginya. Adapun tidak ada yang secara konsisten dapat memenuhi perkiraan, ada organisasi yang secara konsisten datang dalam beberapa poin persentase pada perkiraan mereka - buku McConnell berbicara tentang organisasi (seringkali CMMI Level 4 atau 5, dengan peningkatan berkelanjutan dan pelacakan terperinci) yang mencapai ini secara konsisten.
Thomas Owens

Adapun masalah Anda dengan perkiraan buruk. Apakah Anda melacak perkiraan Anda vs waktu aktual untuk menyelesaikan? Jika ya, tentukan dengan faktor apa Anda meremehkan dan melipatgandakan semua perkiraan Anda dengan angka itu.
kubi


0

Perkiraan waktu keseluruhan proyek biasanya dilakukan oleh manajer proyek, bukan programmer.

Anda dapat membangun argumen berdasarkan fakta bahwa manajer proyek memiliki daftar lengkap tugas yang diperlukan. Tanpa daftar ini, estimasi apa pun akan menjadi tebakan 'buruk'.

Juga, waktu tergantung pada banyak faktor seperti berapa banyak orang yang tersedia dan ruang lingkup persyaratan, yang Anda tidak katakan Anda miliki. Arsitektur saja tidak cukup.


Bergantung pada metodologi manajemen proyek, PM mungkin bahkan tidak memiliki daftar tugas lengkap. Dalam sesuatu seperti manajemen proyek gelombang bergulir, sering ada ember samar yang menggambarkan tingkat tugas yang sangat tinggi yang umumnya terlalu besar untuk diperkirakan dengan tingkat kepercayaan yang layak. Ketika tugas-tugas sebelumnya selesai, tugas-tugas bagian dari ember lebih didefinisikan dengan baik dan dapat diperkirakan. Dalam metode tangkas, tugas sering ditambahkan, dihapus, atau diprioritaskan ulang di berbagai titik, sekali lagi membuatnya lebih sulit untuk memperkirakan tonggak jangka panjang di luar beberapa iterasi.
Thomas Owens

0

Poin lain yang bisa Anda sampaikan adalah bahwa rekayasa perangkat lunak masih dalam masa pertumbuhan dibandingkan dengan bidang teknik lainnya, dan belum cukup matang untuk muncul teknik pengembangan yang dapat diperkirakan.

Rekayasa perangkat lunak juga terus menerus berubah. Pada saat suatu teknologi telah cukup sekitar untuk dianggap matang, sering ditinggalkan demi beberapa teknologi baru. Itu mencegah siapa pun mendapatkan pengalaman yang cukup dengan teknologi apa pun untuk dapat menghasilkan perkiraan yang andal.

Bandingkan ini dengan estimasi konstruksi. Itu masalah yang sangat dipahami, bukan hanya karena kontrak diberikan berdasarkan tawaran, tetapi karena manusia telah membangun sesuatu sejak awal peradaban.


1
Rekayasa perangkat lunak masih lebih muda (sejauh ini) daripada sebagian besar disiplin ilmu teknik lainnya pada usia 42 tahun. Namun, ada sejumlah teknik dan alat estimasi matang. Wideband delphi (dikembangkan pada 1970-an, dipopulerkan oleh Barry Boehm's Software Engineering Economics pada 1981), poin-poin fungsi (1979), SEER-SEM (root pada 1960-an), estimasi berbasis proxy (digunakan dalam PSP, dikembangkan pada 1994 di SEI), dan COCOMO (1981) dan COCOMO II (1997). Dalam bidang yang baru 42 tahun, sudah ada hampir 40 tahun kerja yang dilakukan dalam estimasi proyek.
Thomas Owens
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.