Saya terkejut bahwa tidak ada yang menyebutkan teknik estimasi gaya PERT yang dijelaskan dalam The Clean Coder karya Robert Martin . Dalam metode itu, Anda memperkirakan berapa lama untuk 3 skenario: optimis ( O
), nominal ( N
), dan pesimistis ( P
). Maka durasi yang diharapkan = (O+4N+P)/6
dan Anda mendapatkan standar deviasi (P-O)/6
.
Ini sepertinya bekerja dengan cukup baik, dan saya telah menggunakannya beberapa kali ketika manajemen benar-benar peduli tentang berapa lama sesuatu akan terjadi.
Seperti yang telah dikomentari orang lain, saya juga membuat perkiraan dengan memeriksa data historis ("Berapa lama waktu yang diperlukan untuk melakukan hal serupa ini?").
Tetapi metode favorit saya adalah tidak melakukan estimasi waktu sama sekali, dan hanya melakukan estimasi titik dan mendapatkan kecepatan lebih dari iterasi. Jika sebuah tim cukup konsisten dalam mengukur dan menyelesaikan pekerjaan (cerita pengguna), maka Anda menghemat banyak waktu dengan tidak bertanya berapa lama setiap hal akan memakan waktu.
Perkiraan jam sangat sulit untuk mendapatkan yang benar, dan mereka membutuhkan banyak pekerjaan untuk memecah hal-hal menjadi potongan cukup kecil untuk secara efektif mengukur. Dan meskipun itu jarang benar karena ada terlalu banyak variabel dan kita lupa untuk memperhitungkan hal-hal seperti penyakit, liburan, atau bahkan gangguan.
Jika saya harus melakukan estimasi jam, saya mencoba hanya melakukannya untuk tugas-tugas kecil dalam iterasi. Saya mengukur semuanya dalam taksiran setengah hari (4, 8, 12 jam) kecuali saya tahu itu bisa kurang. Tapi saya jarang memperkirakan apapun kurang dari 1 jam.