Mengapa kami menggunakan poin cerita sebagai ganti hari kerja ketika memperkirakan cerita pengguna?


132

Dalam metodologi tangkas (misalnya SCRUM), kompleksitas / upaya yang diperlukan untuk cerita pengguna diukur dalam poin Cerita. Poin cerita digunakan untuk menghitung berapa banyak cerita pengguna yang dapat diambil oleh tim dalam iterasi.

Apa keuntungan dari memperkenalkan konsep abstrak (poin cerita), di mana kita bisa menggunakan pengukuran konkret, seperti perkiraan hari kerja? Kami juga dapat menghitung kecepatan, memperkirakan cakupan iterasi, dll. Menggunakan perkiraan hari kerja.

Sebaliknya, poin cerita lebih sulit digunakan (karena konsepnya abstrak), dan juga lebih sulit untuk dijelaskan kepada pemangku kepentingan. Keuntungan apa yang ditawarkannya?


16
mengapa Anda menganggap hari manusia lebih konkret daripada titik cerita, itu tidak.
Ryathal

4
Apakah lebih mudah untuk menjelaskan bahwa perkiraan Anda 5 hari-man berarti perlu waktu 1 bulan untuk menyelesaikan karena kecepatan Anda adalah 0,25 hari-man / hari-kalender?
Patrick

3
@Izkata itu hanya benar jika kecepatan Anda selalu tepat 1
Patrick

4
@ Patrick Ketika menggunakan man-days (lihat man-jam di Wikipedia), tidak ada konsep kecepatan. Itu hal yang tangkas / scrum.
Izkata

3
Hal yang menarik adalah bahwa begitu kecepatan stabil, titik cerita cenderung diidentifikasi dengan jumlah jam atau hari tertentu. Misalnya, 1 titik cerita = 1 hari. Jika saya pikir itu akan memakan waktu 2 hari, saya akan memperkirakan 2 poin cerita.
Giorgio

Jawaban:


126

Saya pikir salah satu keuntungan utama adalah bahwa manusia dan pengembang secara khusus sebenarnya sangat buruk dalam memperkirakan waktu. Pikirkan sifat pengembangan juga - ini bukan kemajuan linier dari awal hingga akhir. Sering kali "tulis 90% dari kode dalam 10 menit dan kemudian sobek debugging rambut Anda selama 17 jam." Itu cukup sulit untuk diperkirakan dalam arti pengaturan waktu jam.

Tetapi menggunakan abstraksi menghilangkan fokus dari waktu aktual dalam jam atau hari dan bukannya menempatkan fokus pada menggambarkan biaya relatif dan kompleksitas tugas dibandingkan dengan tugas lain. Manusia / pengembang lebih baik dalam hal itu. Dan kemudian, setelah Anda bersenandung dengan perkiraan titik dan beberapa kemajuan aktual, Anda dapat mulai melihat waktu secara lebih empiris.

Saya menduga bahwa ada juga efek pengamat yang terjadi dengan perkiraan waktu yang tidak akan terjadi dengan estimasi titik. Misalnya, insentif untuk melakukan estimasi dan memberikan cara "lebih cepat dari jadwal" akan dibungkam dengan tipuan dalam sistem berbasis poin.


28
+1 untuk fokus pada kompleksitas , bukan waktu. Menerjemahkan ke jam mentah akan mudah setelah Anda memiliki cukup sprint di bawah ikat pinggang Anda. Saya menemukan bahwa variabilitas antar cerita terhapus seiring waktu.
Kristo

14
Jadi sebenarnya, poin kompleksitas mungkin merupakan istilah yang lebih jelas daripada poin cerita, dan tugas apa pun dengan terlalu banyak poin kompleksitas terlalu kompleks dan mungkin melibatkan terlalu banyak risiko dan tidak diketahui untuk ditangani dengan semua dalam satu waktu. Kompleksitas memiliki biaya eksponensial, dan tanah miskin yang terjebak dengan tugas itu akan menggali lubang begitu dalam sehingga ia tidak akan terlihat lagi selama berminggu-minggu atau berbulan-bulan. Lebih baik membuat tugas yang lebih sederhana untuk memahami tugas yang kompleks terlebih dahulu, dan membaginya menjadi tugas yang lebih kecil dengan kompleksitas yang kurang berisiko dan lebih dipahami.
Supr

4
Waktu dan biaya adalah efek, kompleksitas adalah penyebabnya, dan Anda tidak dapat memahami waktu tanpa memahami kompleksitas.
Supr

8
Poin cerita = Poin kompleksitas - 2 suku kata. :-D
Kristo

5
Adakah yang pernah mempertimbangkan menyebut poin cerita sebagai "biaya casting?" => nerd
Aaron Gibralter

59

Jika Anda menggunakan angka Fibonacci (atau yang serupa), itu membatasi jumlah opsi saat memperkirakan sebuah cerita. Saya bekerja dengan grup yang hanya menggunakan angka rendah: 1, 2, 3, 5, 8, dan 13. Kami memiliki cerita referensi yang merupakan 5. Ini memungkinkan kami untuk dengan mudah membuat keputusan cepat pada kompleksitas cerita saat melakukan Perencanaan Poker . Efek samping lainnya adalah bahwa apa pun yang diberi peringkat 13 mungkin memiliki informasi yang tidak memadai dan perlu dirinci lebih lanjut. Saya benar-benar ragu itu akan mudah dan langsung jika kita menggunakan jam mentah.

Pemilik Produk Anda berbicara dalam bahasa pemangku kepentingan Anda dan harus dapat menerjemahkan antara poin cerita dan jam kerja (atau unit lainnya) sesuai kebutuhan. Selama menjadi PO, saya memiliki beberapa data keras bahwa 1 titik cerita = 4 jam kerja, tetapi jelas setiap tim berbeda.

Sunting:

Dengan pengetahuan bahwa 1 poin = 4 jam, Anda secara teoritis dapat mengubah deck Poker Perencanaan Anda menjadi 4, 8, 12, 20, 32, dan 52. Tetapi angka-angka itu terasa lebih sulit untuk ditangani. Saya pikir saya akan secara mental mengabstraksi nilai-nilai kembali ke sesuatu yang sederhana, misalnya, "kurang dari sehari", "lebih dari seminggu", dll. Dan jika saya akan melakukan itu, saya mungkin juga tetap dengan unit abstrak poin cerita -less.


Kami menggunakan metode yang sama ini, dan dek perencanaan kami memiliki angka yang lebih tinggi tetapi kami telah mendefinisikan 20 sebagai artinya perlu dipecah atau didefinisikan lebih baik. Bagi kami, 13 adalah tugas terbesar kami dan biasanya ini adalah tugas yang berakhir hingga seminggu.
Bill Leeper

"Efek samping lainnya adalah segala sesuatu yang diberi peringkat 13 mungkin memiliki informasi yang tidak memadai dan perlu dirinci lebih lanjut." Dan saya berasumsi jika itu dipecah lebih lanjut, itu akan dipecah menjadi bagian-bagian Fibonacci yang setara?
Joe Z.

@ JoZeng, ya, yang sering menjadi 8 + 5 atau 5 + 5 + 3. Ini pengukuran abstrak, jadi jika cerita baru cukup dekat, maka saya tidak terlalu khawatir. Tim biasanya dapat menyerap 13 menjadi dua 8 atau tiga 5, tetapi tiga 8 berarti saya perlu melakukan pembicaraan klarifikasi dengan para pemangku kepentingan. Idealnya, kami memperkirakan sebelumnya cukup jauh sehingga tidak akan mempengaruhi sprint saat ini.
Kristo

1
Belum tentu. Kami memiliki asumsi tentang cerita menjadi 5 poin, dan jumlah yang lebih rinci, rinciannya ada di kisaran 15 poin. Itu terjadi.
ashes999

24

Ini untuk memungkinkan estimasi menjadi lebih baik dari waktu ke waktu, tanpa penaksir semua harus menyesuaikan estimasi mereka.

Daripada semua orang yang terlibat dalam perkiraan harus berpikir seperti "OK .. terlihat seperti 2 hari kerja .. tapi sprint terakhir kami meremehkan semuanya, jadi mungkin ini benar-benar 2,5 hari kerja. Atau 3?", Mereka melakukan hal yang sama seperti biasanya. "5 poin cerita!"

Kemudian, Anda menyesuaikan estimasi Anda tentang berapa banyak poin cerita yang tim dapat lewati dalam sprint, berdasarkan pada pencapaian aktual yang diukur dalam sprint sebelumnya. "Kami telah melakukan poin cerita 90-110 per sprint sebelumnya!"

Saya akan mengatakan teori di balik ini adalah bahwa pengembang lebih baik dalam memperkirakan kompleksitas relatif dari tugas-tugas dev yang berbeda daripada mereka dalam memperkirakan absolut . Terutama jika banyak orang memperkirakan tugas yang dapat dilakukan oleh salah satu dari mereka (dan tidak semua orang bekerja dengan kecepatan yang sama seperti orang lain).

Alternatif sinis: Saya pernah melihatnya mengatakan bahwa pengembang tidak pernah datang di bawah perkiraan waktu. Jika sesuatu membutuhkan waktu lebih lama dari yang diperkirakan, Anda telah melakukannya. Tetapi jika sesuatu membutuhkan waktu lebih sedikit dari yang diperkirakan, pengembang mungkin mengotak-atiknya, menimbun, atau hanya memperlambat dan tenang karena mereka telah diberi tugas yang mudah. Mengambil satuan waktu nyata dari perkiraan dapat mengekang kecenderungan ini. Akhiri alternatif sinis.


13
Itu bahkan tidak sinis. Ini prinsip "cepat atau murah atau bagus". Saya dapat memberi Anda versi FizzBuzz yang sebagian besar stabil dan berfungsi yang akan memberi Anda apa yang biasanya Anda inginkan dalam beberapa menit, tetapi jika Anda ingin interaksi pengguna, itu akan memakan waktu lebih lama, dan jika Anda ingin pengujian regresi, itu akan memakan waktu. lebih lama, dan jika Anda ingin itu tidak gagal ketika Anda menekan MAX_INT, itu akan memakan waktu lebih lama. Katakan padaku untuk memprioritaskan kecepatan, dan aku akan mulai membuang req. Katakan padaku untuk memprioritaskan yang lainnya, dan aku akan menggunakan semua waktu yang diberikan.
deworde

17

Man days atau man hour adalah seperti yang Anda katakan nyata. Jadi ketika tugas diperkirakan 5 jam dan memakan waktu 6 sekarang tugas yang terlambat.

Ketika Anda memiliki cerita yang merupakan 3 poin dan butuh 6 jam, butuh 6 jam, ini belum terlambat, hanya butuh enam jam. Pengukuran kecepatan daripada lebih merupakan faktor berapa banyak poin yang Anda lakukan dalam sprint, dan angka itu dapat berfluktuasi, karena itu tidak konkret. Anda juga tidak mengukur setiap tugas, tetapi total semua tugas. Ketika Anda memiliki jam untuk setiap tugas, godaan ada untuk mengukur setiap tugas. Ketika itu terjadi, Anda tidak mendapatkan keuntungan dari sprint untuk menyelesaikan di bawah waktu dan itu adalah konsekuensi untuk menyelesaikan dari waktu ke waktu setiap tugas yang diberikan.

Ini bisa menjadi transisi ke pemikiran dalam hal poin. Satu tempat saya bekerja bahkan sebelum kami memperkenalkan ukuran t-shirt lincah hanya untuk mendapatkan ide pada tingkat usaha. Poin hanyalah perpanjangan dari itu.

Itu bukan untuk mengatakan tidak ada kontroversi, atau tugas sewenang-wenang ke poin. Kami memiliki anggota tim kami yang hampir selalu memilih jumlah terendah, dan mengeluh ketika mereka berpikir tugas adalah 1 dan kami pikir itu adalah 3 bahwa kita menderita inflasi titik.


13

Abstraksi adalah semacam intinya. Menggunakan 'hari kerja' sebagai ukuran memiliki sejumlah jebakan, termasuk:

  1. Jika tim tidak terbiasa dengan teknologi yang akan mereka gunakan, maka akan sangat sulit untuk memberikan perkiraan waktu sebenarnya tentang berapa lama tugas mungkin diperlukan. Mereka jauh lebih mungkin untuk dapat memberikan perkiraan relatif yang baik - misalnya "tugas A mungkin akan memakan waktu dua kali lipat tugas B".
  2. Orang yang berbeda bekerja dengan kecepatan yang berbeda! Jika Anda menggunakan 'hari kerja', Anda harus mengubah taksiran waktu ketika suatu tugas dialihkan dari satu pengembang ke pengembang lainnya. Lagi pula, siapa yang mendefinisikan berapa banyak pekerjaan yang merupakan 'hari kerja'?

Jika Anda ingin memperkirakan hari kerja, ini adalah perhitungan sederhana:

user points in story / average user points per developer per day = estimated man days

Mengenai poin 2: bagaimana poin cerita menyelesaikan ini? Anda memperkirakan sebuah cerita sebagai 4 poin cerita. Anda memberikannya kepada pemrogram yang lebih cepat dan membutuhkan 4 hari. Anda memberikannya kepada programmer yang lambat dan butuh 8 hari. Tampaknya bagi saya bahwa masalahnya tidak terpecahkan tetapi hanya berpindah-pindah.
Giorgio

Mengenai poin 1. Idenya adalah bahwa jika tim menjadi lebih akrab dengan teknologi yang dibutuhkan untuk proyek, kecepatan mereka akan meningkat dan ukuran relatif dari cerita, diukur dalam poin cerita akan tetap sama. Tetapi bagaimana jika dua cerita pengguna membutuhkan pengetahuan yang berbeda? Misalnya Anda memiliki kisah pengguna front-end untuk dilakukan dalam Javascript / HTML dan kisah pengguna back-end untuk dilakukan di Jawa. Ketika tim belajar lebih banyak tentang Javascript, HTML dan Java, mereka mengetahui bahwa bagian ujung depan jauh lebih mudah daripada bagian ujung belakang dan perkiraan relatif dari cerita itu salah lagi.
Giorgio

@Giorgio Re. poin 2: Programmer Anda yang lebih cepat memiliki tingkat kerja 1 poin cerita / hari, dan programmer yang lebih lambat Anda memiliki tingkat kerja 0,5 poin poin / hari. Jika Anda melakukannya dalam hitungan jam, baik programmer yang lebih cepat akan bekerja sendiri sampai mati, atau programmer yang lebih lambat Anda perlu dipecat. Jawaban Bill Leeper menunjukkan hal ini dengan sangat baik.
vaughandroid

1
Kembali. poin 1: Untuk uang saya, jika Anda berbicara tentang 2 set teknologi yang berbeda dan 2 area produk yang berbeda, Anda punya dua tim.
vaughandroid

Selanjutnya kembali. Poin 2: Cerita pengguna dikembangkan oleh tim , bukan pengembang individu. Tingkat kerja timlah yang merupakan bagian penting. Ingatlah bahwa saat mengimplementasikan cerita pengguna Anda harus memecahnya menjadi tugas pertama. Beri pengembang tugas lebih cepat lebih banyak!
vaughandroid

6

Seperti yang telah disebutkan, poin cerita adalah ukuran relatif dari kompleksitas. Seseorang dapat menggunakan kekuatan 2 seri (1,2,4,8,16 ...) atau skala Fibonacci (1,2,3,5,8,13,20 ...) untuk estimasi. Sebagai pengembang yang didukung cukup mahir mengatakan sesuatu seperti ini:

Fitur A hampir dua kali lebih keras dari Fitur B

Tetapi sangat sulit untuk mengatakan 'berapa lama' fitur ini untuk implementasi. Anda membiarkan itu diimbangi dengan kecepatan. Jadi, jika sesuatu diperkirakan 5 tetapi ternyata 13, kecepatan yang lebih lambat akan menormalkan itu untuk iterasi (atau Anda bisa memperkirakan kembali).

Sekarang, ada alternatif lain, itu disebut 'hari ideal' (beberapa yang mirip dengan hari-manusia tetapi saya tidak yakin apakah itu yang Anda maksud) dan saya tahu beberapa tim yang lebih suka itu. Hari-hari yang ideal harus ditafsirkan sebagai:

Jika hanya itu yang saya lakukan setelah datang ke kantor dan hanya mengambil istirahat yang diperlukan, tidak ada gangguan dan akan memiliki semua yang saya butuhkan untuk 'mengimplementasikan cerita' yaitu tidak ada kegiatan tambahan seperti rapat, menanggapi surat dll,

Mike Cohn, salah satu dari banyak penginjil gesit yang terkenal memberikan perbandingan berikut ini antara poin cerita dan hari-hari ideal

Poin cerita

  • Membantu mendorong perilaku lintas fungsional, yaitu tim memperkirakan cerita dengan kompleksitas implementasi total mulai dari UI hingga DB dan kembali.
  • Perkiraan SP tidak membusuk yaitu beberapa bulan dari sekarang cerita 5 poin masih cenderung menjadi 5 poin, tetapi perkiraan hari ideal dapat berubah tergantung pada keterampilan pengembangan yang didapat / kecepatan programmer tertentu
  • SP adalah ukuran murni dari ukuran yaitu hanya mereka dan hanya mencerminkan kompleksitas ukuran. Titik. Tidak ada durasi dll, melemparkannya. Itu pekerjaan kecepatan. Namun tidak demikian dengan hari-hari ideal. Bahkan dengan hari-hari ideal ada kecenderungan untuk mengacaukannya dengan hari kalender. Menjaga agar tetap abstrak saat SPs melawan godaan untuk dibandingkan dengan kenyataan. Hanya ukuran ukuran. Bukan omong kosong.
  • Biasanya lebih cepat dari hari-hari ideal. Mungkin sulit untuk beberapa cerita pertama, tetapi begitu Anda bisa menguasainya, itu lebih cepat.
  • Pengembang yang berbeda dapat memiliki pandangan berbeda tentang perkiraan hari ideal mereka untuk menyelesaikan sebuah cerita. Saya bisa melakukan hal yang sama dalam 3 dan Anda bisa dalam 5. SP kurang lebih seragam di seluruh papan. Mereka meratakan lapangan bermain sehingga untuk berbicara.

Hari yang Ideal

  • Lebih mudah dijelaskan di luar tim; untuk alasan yang jelas :)
  • Lebih mudah memperkirakan pada awalnya seperti yang disebutkan di atas. Tapi begitu Anda memahami SP, itu datang secara alami

Sekarang, mana yang harus dipilih terserah tim. Namun, karena sebagian besar jawaban di sini dan pengalaman pribadi saya, saya lebih suka poin cerita. Hari-hari yang ideal tidak benar-benar memiliki banyak manfaat daripada SP (dan Mike Cohn juga menganjurkan SP bersama dengan banyak penginjil lincah lainnya).


Angka Fibonacci berikutnya adalah 21, bukan 20.
Joe Z.

4
21 atau 20 tidak masalah saat memperkirakan. SP mengakhiri angka fibonacci berikutnya untuk menghilangkan rasa ketepatan yang salah. Angka berikutnya dalam urutan bukan 34 tetapi 40 (dua kali lipat dari 20) dan kemudian 100. Angka-angka tersebut mewakili 'ketidakpastian' dalam kompleksitas dan bukan presisi. Itu hanya perkiraan.
PhD

1
Itu benar, saya hanya mengambil telur kutu (dan bercanda).
Joe Z.

1
@ Phd: "Perkiraan SP tidak membusuk yaitu beberapa bulan dari sekarang cerita 5 poin masih cenderung menjadi 5 poin, tetapi perkiraan hari ideal dapat berubah tergantung pada keterampilan pengembangan yang didapat / kecepatan programmer tertentu": Ini secara implisit mengasumsikan bahwa tim akan meningkatkan keterampilannya secara seragam di semua bidang proyek. Saya tidak melihat mengapa ini harus selalu menjadi kasus: beberapa bagian dari proyek (dan teknologi yang diperlukan untuk mereka) mungkin berubah menjadi lebih sulit daripada yang lain, membuat perkiraan awal kompleksitas relatif dalam poin cerita tidak valid.
Giorgio

3

Poin cerita juga membantu Anda mengukur peningkatan kinerja tim dari waktu ke waktu. Selain itu, Anda tidak perlu memperkirakan kembali semuanya karena kinerja membaik.

Ambil contoh ini yang menggunakan hari kerja:

Tim memperkirakan tugas yang berbeda dengan hari kerja. Ini berfungsi untuk sementara, tetapi setelah beberapa waktu Anda melihat bahwa tim dilakukan lebih cepat dengan banyak tugas daripada yang diperkirakan. Jadi tim memperkirakan ulang tugas. Ini berfungsi beberapa saat, dan setelah beberapa waktu Anda melihat lagi hal yang sama: Tim dilakukan lebih cepat dengan banyak tugas lagi. Jadi Anda memperkirakan kembali lagi, dan cerita ini berulang lagi, dan lagi dan lagi ...

Mengapa? Karena kinerja tim Anda meningkat. Tetapi Anda tidak tahu tentang itu.

Contoh yang sama dengan poin cerita:

Tim memperkirakan ukuran cerita pengguna. Setelah beberapa sprint, Anda melihat bahwa tim dapat melakukan sekitar 60 poin cerita per sprint. Kemudian, Anda melihat bahwa tim telah mencapai lebih dari 60 poin, mungkin 70. Dan tim terus seperti itu dan menarik lebih banyak cerita pengguna untuk sprint berikutnya dan mengirimkannya.

Mengapa? Karena kinerjanya telah meningkat. Dan Anda bisa mengukurnya. Dan Anda tidak perlu memperkirakan kembali semuanya setelah kinerja tim Anda meningkat.


3
"Mengapa? Karena kinerja tim Anda meningkat.": Penjelasan alternatif adalah bahwa setelah beberapa saat tim mulai memberikan perkiraan waktu yang lebih akurat / realistis (karena mereka terlambat dengan beberapa tugas dalam sprint sebelumnya, mereka mulai menetapkan lebih banyak waktu ketika memperkirakan cerita untuk sprint selanjutnya).
Giorgio

2

Pertama, orang lebih baik pada estimasi relatif daripada estimasi absolut. Babylonians memetakan dan memberi peringkat kecerahan relatif bintang adalah contoh yang bagus. Mereka tidak mendapatkan angka absolut dengan benar, tetapi urutannya kebanyakan tepat bahkan untuk intensitas yang sangat mirip.

Keuntungan kedua adalah bahwa alasan utama untuk melakukan latihan ini adalah untuk mendorong percakapan .. Jika Anda mulai berdiskusi di hari yang tepat, percakapan dapat dengan cepat tergelincir.

Seperti yang dikatakan Napoleon: rencana itu tidak berharga, perencanaan tidak ternilai.

Ketiga, manajer proyek tidak perlu mengedit semua perkiraan, hanya karena ternyata estimasi itu dimatikan oleh faktor, misalnya, 130%.


0

Story Points mencerminkan kompleksitas masalah, dan karenanya, mencerminkan kepercayaan (atau risiko) tentang seberapa akurat perkiraan itu.

Sebuah Cerita dengan poin cerita yang tinggi memberi tahu saya bahwa ada banyak hal yang terjadi dengan cerita pengguna yang tidak konkret.

Idenya adalah untuk melihat keseimbangan yang baik dari berbagai titik cerita. Jika saya ditunjukkan rencana iterasi dengan cerita-cerita dengan semua poin cerita tinggi, ini memberi saya sedikit kepercayaan bahwa iterasi akan dieksekusi seperti yang diharapkan dan bahwa kita perlu melihat cerita lain untuk iterasi atau mulai memecah cerita.

Saat berkomunikasi dengan manajer atau Pemilik Produk, poin cerita tinggi berarti bahwa akan sangat kabur kapan mereka akan mendapatkan fitur tertentu. Salah satu solusi untuk ini adalah memecah cerita dan mudah-mudahan Anda akan memiliki kombinasi poin cerita rendah dan tinggi untuk dikerjakan sehingga Anda dapat secara iteratif menunjukkan kemajuan kepada Pemilik Produk.


0

Man days memperkirakan waktu yang diperlukan untuk melakukan sesuatu. Mereka paling baik digunakan ketika item yang Anda perkirakan sangat tepat dan terukur. Tugas spesifik, terkenal, berulang dapat diperkirakan dalam man days.

Misalnya, jika seorang tenaga penjualan dapat melakukan 20 panggilan pelanggan per hari, rata-rata, kami dapat menghitung berapa lama setiap panggilan dan dari itu kami dapat memperkirakan berapa hari yang dibutuhkan untuk melakukan 1.000 panggilan.

Dalam contoh ini orang dapat secara konkret berpikir dalam istilah statistik tentang panjang rata-rata panggilan karena semua panggilan dapat dianggap secara efektif adalah hal yang sama.

Poin cerita menentukan kombinasi cerita mana yang dapat dilakukan dalam iterasi. Mereka digunakan untuk menggabungkan tujuan heterogen dengan batas fuzzy dan untuk mengukur berapa banyak yang dapat dilakukan dalam kerangka waktu yang tetap. Mereka memperkirakan kerumitan potongan pekerjaan dibandingkan satu sama lain sehingga dapat menambahkannya bersama.

Misalnya, tim Anda mengembangkan 5 cerita dengan total 23 poin di iterasi 1, dan 8 cerita untuk 20 poin di iterasi 2. Dari sini Anda dapat memperkirakan bahwa dalam iterasi dua tim Anda akan membuat beberapa cerita yang totalnya sekitar 20 poin dalam iterasi 3.

Perhatikan bahwa kita tidak perlu menentukan ukuran satu titik dan khususnya tidak ada asumsi sama sekali bahwa setiap cerita dengan ukuran yang sama akan membutuhkan waktu yang sama untuk dikembangkan! Kami hanya bekerja pada jumlah dan poin per iterasi. Saya bahkan tidak menyebutkan berapa lama iterasi itu.


0

Jika Anda berjalan ke manusia di jalan dan bertanya "Seberapa besar T-rex?" jawabannya akan berfluktuasi meskipun mayoritas manusia tahu apa itu T-rex, seberapa besar jenisnya, tetapi tidak ada yang benar-benar tahu pasti - karena kita tidak memiliki skala relatif dari awal.

Itulah perilaku kognitif yang Anda coba cari tahu dengan peramalan dan banyak metodologi memutar siklus dengan " Saya mengerti! Saya punya rahasia untuk peramalan yang akurat! " Minyak ular ke massa. Ketika Anda benar-benar memperkirakan Anda benar-benar mengatakan lebih keras dari " Saya akan MENGIZINKAN x hari / jam / poin untuk itu untuk menyelesaikan " - itu dalam arti menciptakan "kotak waktu" untuk acara yang akan dilakukan dalam.

Bagi saya, Poin hanya menggeser batas, pada akhir hari kecuali jika Anda berada di tim yang senang mengatakan " * Yah kita punya 3 minggu per sprint, dan jempol payah ... saya pikir kita harus menembak untuk 30 poin untuk diselesaikan dalam siklus itu! Siapa yang bersama saya! * "Dan itu sedalam Anda pergi dalam pemodelan perkiraan - baiklah! ..sebagai realistis Anda hanya menetapkan anggaran arbiter dan hanya itu. Anda juga kemudian dalam retrospektif melihat pekerjaan yang dilengkapi dengan rasa "omong kosong, kami melakukan 33print itu, itu cukup keren" dan tidak banyak yang bisa dilakukan tentang itu. Anda dapat menggunakan kecepatan untuk menentukan sprint tengah yang Anda dapatkan untuk uang Anda dengan bertanya, " Apakah kita sudah mencapai 15 poin? Akankah kita""tetapi bahayanya di sini adalah Anda sekarang menggunakan Velocity untuk mengukur produktivitas bukan kapasitas yang dari apa yang saya pahami menendang Reactive Release Management (poin cerita) di kepala ..

Sistem poin hampir terlalu pintar untuk tidak melihat bahwa Anda masih melampirkan waktu relatif untuk persamaan, semuanya dari "siklus sprint" yang Anda setujui untuk standup harian di mana Anda memberlakukan beberapa aturan tersembunyi di sekitar durasi + kompleksitas = " Max butuh waktu lama dengan tugas itu "kode tim bawaan bawaan perasaan saat merah?

Otak manusia tidak dapat meramalkan karena melibatkan banyak memori kerja yang dicampur dengan ingatan jangka panjang / pendek, jadi itu seperti meminta siswa matematika pemula untuk melakukan pecahan di kepala mereka bukan di atas kertas. Itu sebabnya industri lain tidak pernah menyetujui perkiraan dan terus memvalidasi prakiraan dalam waktu relatif (misalnya geolog tidak pernah menghentikan pemodelan prakiraan sampai meter kubik telah digali keluar dari tanah dan kemudian "selesai").

Saya akan mengatakan sistem Point berfungsi jika Anda tidak memperkirakan . Anda menyetujui sebagian pekerjaan yang didasarkan pada algoritma sub-chunking tapi itu benar-benar pendekatan terdekat Anda untuk meramalkan mungkin. Bahkan Anda akan merilis manajemen akan mencari jeda alami dalam antrian "backlog" yang sesuai dengan tema (yaitu di Silverlight we. Manajer Produk akan menunggu sampai setelah mereka menyelesaikan jaminan simpanan dan menyatukan tema-tema yang awalnya kami tetapkan. Kami tidak pernah tahu apa yang dilakukan tim teknik secara khusus kami hanya memiliki garis besar dasar. Kami kemudian akan mengambil tubuh kerja itu dan membangun acara pemasaran kami di sekitarnya (Microsoft Mix))

Ketika Anda mulai mengunci ekspektasi kecepatan di dalam siklus sprint yang mengandalkan kecepatan + waktu, Anda kembali ke perkiraan perkiraan lagi hanya kali ini Anda lebih buruk karena Anda memainkan "itu tergantung permainan" ... Lebih penting lagi Anda Juga membunuh potensi pertumbuhan tim / pertumbuhan karier.

Pajak yang Anda bayar untuk Poin vs Waktu adalah dengan poin yang Anda butuhkan untuk mencari formula pengukuran alternatif untuk melacak pengembangan / pembinaan keterampilan kerja sama atau perilaku pengembang.

Karena Anda masih perlu melihat "pengembang median" sebagai orang ideal Anda untuk melampirkan keterampilan / upaya, Anda kemudian dapat membuat baseline pengembang lain dengan orang itu untuk menentukan bagaimana mereka adil dalam pertumbuhan berkelanjutan mereka dalam tim Anda. Ini juga menyoroti situasi di mana pengembang "cepat" mengangkut sebagian besar air tetapi menjadi bosan atau lebih buruk mereka bekerja berjam-jam dan tidak ada pengakuan / penghargaan karena tenggat waktu yang bersaing dll. Standup tidak menggali ini dalam kenyataan, mereka benar-benar di sana untuk mendeteksi bau busuk di dalam tim, katakanlah, seperti dalam "orang itu sedang berjuang, mari kita bantu"

Berikutnya juga datang cerita "carry over", cerita yang tidak terpotong ke dalam siklus sprint tetapi kemudian tumpah ke siklus sprint berikutnya. Yang kemudian dapat dengan mudah membuat efek knock-on jika Anda memfaktorkan dalam waktu, tetapi saat Anda melakukan faktor dalam waktu relatif..lagi, Anda hanya mundur kembali ke "perkiraan / estimasi berdasarkan waktu" dan lagi-lagi sistem poin hanya mengeruhkan air.

Jika Anda pergi poin Anda telah mengabaikan waktu sepenuhnya dan maksud saya sepenuhnya sebagai saat Anda membiarkan waktu merayap di Anda game ide / metodologi.

Setelah berkeliling dunia sebagai Penginjil, saya melihat banyak tim bersumpah pada apa pun yang mereka sayangi bahwa mereka telah memecahkan kode Agile Forecast ... tapi saya selalu mengklik lidah saya, tersenyum dan berjalan pergi dengan pikiran " yeah ... Anda hampir melakukannya, tetapi nyonya yang kita sebut 'waktu' ... dia hanya kejam ... "


-1

Buku Mike Cohn "Agile Estimating and Planning" menggambarkan kelebihan dan kekurangan dari estimasi dengan "hari-hari ideal" atau poin cerita, jadi jawaban cepat untuk pertanyaan Anda adalah bahwa Anda tidak perlu memperkirakan dengan poin cerita. Jika lebih alami untuk memperkirakan dalam hari-hari ideal, silakan saja.


1
Ini tidak selalu menjawab pertanyaan; itu hanya menyediakan referensi buku saja. Anda bisa memperkuat jawaban Anda dengan memberikan ringkasan tentang kelebihan dan kekurangannya.

-1

Saya pikir metode Story Point memiliki setidaknya dua keunggulan penting dibandingkan metode Man-day: Pertama, lebih mudah untuk memperkirakan dalam SP. SP relatif dan manusia seperti kita relatif lebih baik daripada estimasi absolut seperti metode hari manusia.

Kedua, ketika Anda memperkirakan dalam SP, Anda mendapatkan "Tim SP" bukan "Manday Individual". Ketika Anda bertanya "Berapa lama tugas ini akan berlangsung?", Senior dev dapat memberi Anda 1 hari tetapi 5 hari untuk Junior. Hari-Man terserah siapa yang akan mengambil tugas itu untuk dilakukan. Jika pemilik dipaksa untuk berubah (dan itu akan!) Anda harus menjadwalkan ulang semuanya. Dengan SP, tetap sama siapa pun yang mengambil tugas.


-1

Saya terkejut belum ada yang menyebutkan Hukum Parkinson .

Pekerjaan mengembang untuk mengisi waktu yang tersedia untuk penyelesaiannya.

Pada dasarnya jika Anda memperkirakan dalam unit waktu apa pun untuk tugas-tugas besar, pengembang akan cenderung mengambil waktu yang mereka perkirakan untuk menyelesaikannya atau pergi. Ketika Anda memperkirakan dalam waktu yang samar-samar seperti Story Points atau Ukuran Kaos Anda menghindari perangkap ini.


1
"Ketika Anda memperkirakan dalam waktu yang tidak jelas seperti Story Points atau Ukuran Shirt Anda menghindari jebakan ini.": Tidak juga: jika untuk sprint 2 minggu saya telah diberi dua cerita pengguna dengan total 10 poin cerita, saya dapat mengambil keseluruhan dua minggu dan atur kecepatan menjadi 5 poin cerita per minggu. Saya pikir peningkatan produktivitas lebih berkaitan dengan motivasi tim dan kondisi kerja daripada dengan unit yang digunakan untuk mengukur kompleksitas tugas.
Giorgio

Saya tidak merujuk pada peningkatan produktivitas, lebih pada fakta bahwa jika perkiraan untuk sebuah cerita keluar menjadi 3 hari. Pengembang lebih mungkin membutuhkan waktu 3 hari atau lebih untuk menyelesaikannya, daripada masuk di bawah perkiraan.
Vadim

Apakah ada bukti bagus untuk hukum Parkinson? Halaman Wikipedia tampaknya tidak menyebutkan apa pun.
bdsl

-2

Estimasi titik cerita mengikuti seri fibonacci 1,2,3,5,8,13,21 ...

Otak manusia dapat dengan mudah memetakan hal-hal berdasarkan ukuran. Sebagai contoh: Kami memiliki kartu pos dan menetapkannya sebagai poin cerita 2 dan tiga ukuran kartu posting itu berarti 2 * 3 = 6 poin cerita.

Story Point 6 berada di antara deret Fibonacci nomor 5 dan 8 dengan 5 sebagai angka yang lebih dekat dan karenanya titik penyimpanan akan menjadi 5.


1
Kami tidak memetakan hal-hal berdasarkan ukuran, kami benar-benar menggunakan memori yang berfungsi untuk memperlakukan ini sebagai "skema" untuk bekerja. Jenis seperti otak kita memiliki jumlah RAM yang pendek yang ketika kita masukkan ke dalam pola-pola kecil yang dapat dilihat (Fibonacci, A000079, ukuran kaos, dll.) Ini dapat menarik daya kognitif intrinsik kita untuk kemudian membantu memproyeksikan dalam kasus ini - sebuah jawaban. yang merupakan model "perkiraan relatif".
Scott Barnes
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.