Siapa yang harus berpartisipasi dalam estimasi waktu?

Dalam proyek TI:

1. Siapa yang harus berpartisipasi dalam estimasi waktu? Pengembang, pemimpin tim, master scrum, dll?
2. Siapa suara harus dihitung paling?

Ini bukan tentang orang-orang yang terlibat, melainkan keterampilan yang harus ada:

• Pemahaman yang baik tentang domain masalah - ini sangat penting ketika persyaratannya ambigu atau tingkat tinggi. Sebagai seorang programmer yang tidak pernah bekerja dalam perjalanan untuk memperkirakan pekerjaan mengenai kelas tiket di pesawat dan mereka akan berasumsi bahwa ada 3 atau 4 (ekonomi, bisnis, pertama dll.) Tetapi jika Anda telah bekerja dalam perjalanan Anda akan tahu bahwa ada lusinan. Ini mungkin berarti bahwa seorang Analis Bisnis atau pengguna ahli terlibat, meskipun seiring waktu pengembang sendiri akan membangun pengetahuan semacam ini.

• Pemahaman tentang teknologi dan pekerjaan yang akan terlibat - biasanya pengembang melalui manajer dengan pengalaman baru-baru ini yang memiliki kepercayaan tim sering dapat melakukan pekerjaan itu. Idealnya, Anda mendapatkan orang yang benar-benar akan melakukan pekerjaan seperti yang mereka terima dalam perkiraan.

• Pemahaman tentang proses estimasi - ini adalah kunci. Perlu ada pemahaman tentang bagaimana melakukan estimasi yang layak, bagaimana memastikannya benar, memeriksa tingkat kontingensi yang sesuai, memeriksa penghitungan ganda atau terlalu banyak bantalan. Biasanya seorang PM, manajer pengembangan atau pengembang senior akan membawa ini, meskipun dalam beberapa proses templat estimasi yang solid dapat memberikan panduan yang diperlukan.

Keterampilan itu bisa dalam satu orang, meskipun kadang-kadang mereka membutuhkan tiga atau lebih, tetapi kuncinya adalah memastikan bahwa keterampilan itu ada, bukan orang-orang tertentu yang hadir.

Yang mengatakan, secara umum meskipun saya akan mencari lebih dari dua orang karena Anda ingin jaminan tambahan bahwa dua orang atau lebih memeriksa satu sama lain bekerja.

Dalam hal suara siapa yang paling dihitung, itu tidak berfungsi seperti itu. Ini diskusi dan negosiasi. Jika seorang manajer berpikir estimasi pengembang terlalu tinggi, ia perlu menjelaskan mengapa dan menantang (bukan menekan) pengembang untuk membenarkannya dan mereka perlu mencapai konsensus. Jika Anda tidak dapat mencapai kesepakatan itu, saya akan mengatakan dua hal dari pengalaman:

(A) Jangan pergi dengan nomor yang Anda "inginkan", itu hanya meminta masalah dan apa yang Anda inginkan tidak berdampak material pada seberapa cepat pekerjaan dapat dilakukan.

(B) Dalam hampir setiap kasus saya telah melihat di mana seorang pengembang telah lebih dari memerintah pada perkiraan, angka terakhir telah keluar lebih dekat dengan apa yang dipikirkan pengembang daripada siapa pun yang lebih berkuasa atas mereka - terutama karena mereka mengabaikan poin (a) atas.

(Itu mengatakan lincah saya percaya, dan tentu saja di XP, aturannya adalah bahwa pengembang mengontrol perkiraan dan itu final. Jika pengguna ingin menurunkan perkiraan mereka harus mengubah persyaratan untuk sesuatu yang lebih sederhana.)

Saya tidak tahu apakah ada jawaban satu ukuran untuk semua pertanyaan ini. Di tempat saya bekerja, biasanya ada dua insinyur dari tim yang akan mengimplementasikan fitur / perbaikan yang memberikan perkiraan. Jadi, masing-masing dua insinyur masing-masing memberikan taksiran "min", "max" dan "diharapkan". Kami biasanya mengharapkan kedua perkiraan tersebut cukup konsisten, jadi jika keduanya sangat berbeda, maka diskusi lebih lanjut mungkin diperlukan (mungkin satu insinyur telah membuat asumsi bahwa yang lain tidak, dll).

Dalam situasi kami, "suara" tidak ada yang dihitung seperti itu. Kami biasanya rata-rata hanya dua perkiraan (ingat, jika mereka belum berada di stadion baseball yang sama, maka kami menolak keduanya dan mulai dengan diskusi lagi, jadi mengambil rata-rata bukan lompatan besar). Toh estimasi itu hanya perkiraan, jadi tidak perlu tepat .

Dalam pengalaman saya, estimasi cenderung dilakukan oleh orang yang kemungkinan besar akan melakukan tugas itu sendiri. Tim SCRUM harus berusaha menjadi lintas fungsi, tetapi setelah beberapa saat, jenis tugas tertentu biasanya dilakukan oleh orang yang sama.

Yang sangat penting adalah mendapatkan penerimaan dari tim atas semua perkiraan. Jika pengembang merasa mereka memiliki taksiran, mereka akan berusaha memenuhi perkiraan tersebut. Jika pengembang mendapatkan perkiraan bahwa mereka tidak melakukan sendiri dan tidak memiliki input atau pengaruh, mereka tidak akan merasakan tingkat tanggung jawab yang sama dengannya dan cerukan akan dijelaskan dengan "Saya bilang Anda akan membutuhkan waktu lebih lama".

Sebuah proyek memiliki persyaratan bisnis dan tenggat waktu yang datang dari atas ke bawah. Itu adalah "diberikan estimasi" untuk iterasi pertama.

Persyaratan ini harus dipartisi ke tugas-tugas terbesar yang memiliki biaya 100% diketahui (seperti "aktifkan pencatatan" = 2 jam = "unduh log4j / SLF4J dan pasang").

Estimasi harus dilakukan pada tingkat setinggi mungkin yang sudah memiliki keahlian teknis yang cukup untuk melakukannya.

Perkiraan yang dikoreksi harus melakukan perjalanan kembali dalam bentuk "fitur yang terlihat oleh bisnis" = "jumlah waktu ini" hingga mencapai pemilik bisnis pada tingkat yang sesuai, dapat membatalkan / mengubah persyaratan atau mengendurkan tenggat waktu. Kemudian kembali. Sampai konvergensi akhir. Dalam praktiknya, orang cenderung mengabaikan fase ini atau menyederhanakannya, yang pada gilirannya dapat menciptakan risiko yang terkait dengan tenggat waktu dan peluang yang terlewat.

Siapa atau siapa yang harus berpartisipasi dalam estimasi waktu? Pengembang, pemimpin tim, master scrum, dll?

Saya lebih suka semua ada di sana dalam estimasi waktu dan kami melakukan hal yang sama di sini

Siapa atau siapa yang suaranya paling banyak dihitung?

Pengembang tetapi semuanya tentang kerja tim lagi

THE DEVELOPERS CHARGED DENGAN MELAKSANAKAN PROYEK! TIDAK ADA ORANG LAIN!

Para pengembang melakukan pekerjaan nyata dan pemimpin tim pengembangan adalah satu-satunya yang mampu memperkirakan dengan tepat berapa banyak waktu yang dibutuhkan. Hanya pemrogram yang akrab dengan basis kode yang sebenarnya yang dapat memahami kesulitan dan jebakan potensial yang mungkin dihadapi dalam proses pengembangan. Semua orang adalah 'penonton'.

Selain itu, satu-satunya cara pengembang dapat dipercaya untuk memberikan perkiraan yang akurat adalah ketika pebisnis mempercayai mereka dan mengandalkan keahlian mereka sehingga pengembang tahu mereka tidak akan dihukum jika perkiraan mereka tidak memenuhi harapan bisnis.

Rule of thumb: akan memakan waktu setidaknya 3 kali selama estimasi manajer proyek atau pebisnis tidak akrab dengan tantangan pengembangan tangan dan basis kode yang bersangkutan.

Sebagai seseorang yang telah bekerja sebagai pengembang langsung, baik sebagai pekerja lepas maupun sebagai karyawan di perusahaan besar selama hampir 20 tahun, saya mengatakan ini dengan sangat pasti dan manfaat dari banyak pengalaman pahit.