Memperkirakan tugas dan cerita perangkat lunak: Hindari perkiraan berbasis waktu

07 Juni 2023 [Programming, Tech]

Baru-baru ini saya ditanya apa yang saya pikirkan menggunakan perkiraan berbasis waktu ketika melacak tugas perangkat lunak.

TLDR: Saya pikir itu adalah ide yang mengerikan yang dapat melukai perangkat lunak Anda dengan memperkenalkan bug dan membakar pengembang.

Saya pikir menggunakan perkiraan berbasis waktu cukup beracun. Hal ini menyebabkan orang -orang “dimintai pertanggungjawaban” yaitu ditekan dan/atau diharapkan bekerja berjam -jam untuk memenuhi “perkiraan”, yang secara ajaib berubah menjadi a target. Ini membuat pengembang terburu -buru, menyebabkan bug dan tes yang terlewatkan dan tugas -tugas kebersihan, yang selalu kembali menggigit Anda, dan selalu lebih awal dari yang Anda harapkan. Itu juga membuat pengembang stres dan lelah, yang membuat mereka menulis kode yang lebih buruk.

Masalah -masalah ini hampir tidak mungkin untuk dihindari, bahkan jika manajer sengaja tidak pernah menyebutkan perkiraan! Ini hanya sifat manusia untuk merasa Anda harus tetap berpegang pada perkiraan Anda.

Sebaliknya, saya menganjurkan unit relatif (misalnya “poin cerita”). Ini dapat digunakan untuk prediksi karena Anda dapat melihat pekerjaan masa lalu untuk melihat berapa lama poin cerita rata -rata, tetapi mereka tidak datang dengan bagasi bahwa prediksi Anda akan tepat.

Catatan: Untuk bootstrap proses ini, Anda perlu membandingkan pekerjaan baru dengan hal -hal yang telah Anda lakukan. Rasakan betapa rumitnya tugas lama, dan pilih jumlah yang sewenang -wenang untuk tugas itu. Sekarang perkirakan tugas -tugas baru dengan mengatakan misalnya “terasa sekitar dua kali lebih kompleks dari X”. Ini juga memungkinkan Anda untuk melakukan bootstrap proses prediksi Anda karena Anda dapat melihat berapa lama tugas lama itu selesai.

Dalam kedua kasus tersebut, saya juga mengadvokasi a perkiraan jarak jauh (rendah-tinggi). Saat memprediksi, saya selalu mengambil yang tinggi.

Ini juga sangat penting untuk bekerja sebagai tim untuk memperkirakan, tidak melakukannya secara individual.

Aturan lain: Hanya orang yang menerapkan tugas yang melakukan estimasi. Ini mencegah dua antipattern: 1. Seseorang yang tidak memiliki kulit dalam permainan berpikir itu akan mudah tanpa benar -benar terlibat dengan masalah, dan 2. Seorang manajer atau orang yang berwenang yang ingin mencoba dan membuatnya berjalan lebih cepat dengan memperkirakan rendah. Ini tidak pernah berhasil, dan sebaliknya membuat pengembang Anda stres.

Jika ada ketidaksepakatan atau jangkauannya luas, baik buat saja tinggi (jika ceritanya tidak akan segera selesai), atau luangkan waktu untuk mencari tahu mengapa orang tidak setuju atau tidak pasti. Ini selalu membuahkan hasil, dan itu berarti mengambil high end ketika Anda memprediksi tidak menghasilkan estimasi yang meningkat.

Bacaan Lebih Lanjut: Martin Fowler: Tujuan Estimasi