Siapa yang harus berpartisipasi dalam estimasi waktu?


9

Dalam proyek TI:

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

2
Jika Anda melakukan Scrum : (a) tidak ada pemimpin tim. (B) tim harus memperkirakan secara kolektif menggunakan Poker Perencanaan. (C) dan orang yang kemungkinan akan melakukan tugas harus diikuti. Tim Scrum adalah lintas fungsional, dan tugas tidak ditugaskan, tetapi jika orang yang menguasai DB mengatakan itu harus 3 hari. Mungkin perlu 3 hari.

1
Anda harus menyadari bahwa perkiraan bukanlah keputusan, tetapi prediksi (seringkali sulit). Tidak ada hirarki. Tidak ada suara.
user281377

@ammoQ Masalahnya adalah bahwa banyak pemimpin proyek memiliki itu sebagai keputusan!
Amir Rezaei

2
Ya, itu kesalahpahaman mental yang umum. Tentu saja Anda dapat membuat jangka waktu keputusan, tetapi kemudian Anda harus memperkirakan (yaitu memprediksi) kualitas dan kelengkapan yang dapat diterima sebagai gantinya.
user281377

@ user281377 Saya suka apa yang Anda lakukan: Prinsip ketidakpastian Heisenberg untuk pengembangan perangkat lunak.
K.Steff

Jawaban:


8

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


+1 untuk nomor yang Anda "inginkan". Lihat di sini .
Spencer Rathbun

1
Sesuatu yang lebih menyeluruh pada 'angka yang saya inginkan': Estimation Games
K.Steff

2

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 .


1

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


0

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.


1
"Sebuah proyek memiliki persyaratan bisnis + tenggat waktu yang datang dari atas ke bawah. Itu adalah" diberikan estimasi "untuk iterasi pertama." - Sayangnya benar dan bertanggung jawab untuk jenis tekanan yang membuat orang lain memberikan perkiraan yang tidak akurat ketika mereka mencoba untuk tetap dalam tenggat waktu ini terlepas dari apa yang tahu berapa lama waktu yang dibutuhkan.
Jon Hopkins

@ Jon Hopkins - +1, titik adil, tapi saya menggambarkan proses yang ideal, pada kenyataannya, seperti yang Anda katakan, manajer teknis kadang-kadang lebih suka berkomitmen untuk apriori jadwal yang tidak realistis dan menemukan "pembenaran" untuk keterlambatan seiring berjalannya proyek
bobah

Saya tidak mengkritik jawaban Anda - hanya mengatakan bahwa elemen khusus ini adalah sesuatu yang harus diwaspadai dan bahwa estimasi tersebut harus jika mungkin pada awalnya tidak diberitahu tentang tenggat waktu ini karena takut mereka dipengaruhi oleh mereka.
Jon Hopkins

1
"Sebuah proyek memiliki persyaratan bisnis dan tenggat waktu yang datang dari atas ke bawah." - Kecuali orang-orang di atas adalah pengembang sendiri dengan pengalaman 'di parit', ini adalah resep untuk BENCANA.
Vektor

Pernah perhatikan bagaimana tim MLB selalu memiliki mantan pemain sebagai manajer mereka di ruang istirahat? Itu karena hanya seorang mantan pemain yang mengerti apa yang diperlukan untuk menyelesaikan pekerjaan dan memiliki kepercayaan diri para pemain yang ikut serta.
Vektor

-1

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


-2

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.


2
Harap perbaiki jawaban ini.
K.Steff
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.