Apa pendapat Anda tentang "Perencanaan Poker"? [Tutup]

Perencanaan Poker

Ringkasan, jika Anda tidak ingin membaca artikel wiki:

1. Dapatkan daftar tugas yang ingin Anda lakukan untuk iterasi mendatang
2. Untuk setiap tugas:
   2.1 Diskusikan dengan kelompok tentang apa yang diperlukan
   2.2. Setiap orang menulis / memilih perkiraan berapa banyak upaya yang diperlukan untuk tugas tersebut
   2.3 Semua orang mengungkapkan estimasi mereka
   2.4 Pencilan tertinggi dan terendah menjelaskan alasan mereka
   2.5 Ulangi sampai konsensus tercapai

Biasanya sesuatu yang mirip dengan angka-angka dari deret Fibonacci seperti 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 adalah nilai yang diperbolehkan, jadi Anda tidak mendapatkan argumen panjang tentang nilai penutupan seperti 23 vs 27.

Lebih lanjut, angka-angka tersebut mewakili nilai usaha yang lebih kecil, yang nilainya ditentukan oleh tugas dasar yang disetujui semua orang sama dengan angka 1, dan yang lainnya relatif terhadap itu.

Pada akhirnya, tujuannya adalah untuk mendapatkan perasaan yang baik untuk "kecepatan" tim tertentu, yang merupakan jumlah poin-poin ini yang dapat diselesaikan dalam iterasi yang diberikan. Dengan itu, dimungkinkan untuk membuat perkiraan yang cukup akurat tentang berapa lama fitur yang diberikan akan memakan waktu.

Kami melakukan ini pada pertemuan perencanaan iterasi di satu perusahaan tempat saya bekerja, dan saya pikir itu adalah salah satu dari sedikit hal baik tentang perusahaan itu. Jadi, yang saya ingin tanyakan adalah, adakah yang menggunakan ini? Apakah Anda pikir itu alat yang berguna untuk estimasi? Apakah itu berfungsi dalam semua situasi, atau apakah itu cocok untuk tim, proyek, dll?

Kami menggunakannya di perusahaan kami untuk proyek yang saya ikuti. Beberapa catatan tentang perencanaan poker diungkapkan dalam posting blog saya baru-baru ini , dan inilah daftar yang lebih besar mengapa itu keren:

1. Itu membuat semua orang setuju . Orang tidak dipaksa untuk menerima hasil apa pun; alih-alih mereka dipaksa membuat estimasi sendiri! Waktu untuk mempertahankan perkiraan mereka sendiri juga dialokasikan, jika perlu.

2. Itu membuat semua orang sibuk . Anda tidak dapat mengendur saat rapat, saat mencoba menunjukkan bahwa Anda sangat terlibat. Juga, keharusan menggerakkan tangan Anda merupakan latihan fisik yang baik untuk membuat Anda tidak tidur.

   Namun, kerugian dari hal ini adalah bahwa kadang-kadang Anda perlu melakukan sesuatu yang lain (misalnya, membuat beberapa catatan dan menuliskan rincian perjanjian yang baru saja Anda capai).

3. Itu membuat rapat lebih cepat . Tidak perlu keterlibatan pemimpin rapat yang konstan untuk menjaga segalanya berjalan cepat. Gim dengan aturan yang jelas jauh lebih baik untuk itu. Ya, Anda perlu melakukan beberapa langkah ekstra untuk meletakkan kartu, mengungkapnya, dan lain-lain, tetapi ini harus dibayar.

4. Banyak orang hanya suka bermain kartu , terutama poker :-) Ini meningkatkan motivasi.

Sebuah perusahaan yang menjual setumpuk kartu semacam itu menemani situs mereka dengan artikel tentang Poker Perencanaan , yang juga layak dibaca.

Kami menggunakannya secara luas. Saya menemukan itu memiliki beberapa keunggulan dibandingkan metode tradisional:

1. Tim mengambil kepemilikan estimasi yang lebih besar
2. Seringkali programmer arketipe menyukai introvert - metode ini mendorong mereka untuk berkontribusi di mana mereka mungkin tunduk pada kepribadian yang lebih ekstrover
3. Ketika fitur memiliki distribusi perkiraan yang luas, itu merupakan indikator risiko yang baik
4. Hanya dengan melakukan estimasi Anda belajar lebih banyak tentang tugas
5. Tidak ada yang mengalahkan menempatkan orang di ruangan berkomunikasi secara efektif

Saya setuju dengan poin Pavel. Ada juga satu hal lain yang berharga. Ini tingkat lapangan bermain untuk diskusi. Seringkali orang pendiam ditenggelamkan oleh lebih banyak orang verbal dalam diskusi kelompok. Perencanaan poker memberi setiap orang kesempatan untuk membuat keputusan sebelum diskusi aktif dimulai. Dan jika itu adalah orang pendiam yang memberikan pendapat "outlier", mereka memiliki tahap penuh untuk menyajikan kasus mereka. Karenanya teknik ini memberdayakan kontributor yang lebih tenang, dan memastikan partisipasi penuh tim.

Setelah menggunakan poker perencanaan untuk beberapa sprint, manajemen akhirnya menyadari apa yang diketahui semua pengembang selama berbulan-bulan, kami tidak akan selesai tepat waktu.

Perencanaan poker, atau lebih tepatnya, estimasi berdasarkan poin cerita, jauh lebih akurat daripada praktik estimasi tradisional karena menggabungkan cara mudah untuk memperkirakan kompleksitas gabungan dari seluruh fitur yang ditetapkan dengan pengukuran aktual kapasitas aktual tim.

Ada banyak jawaban bagus di sini - saya hanya ingin menunjukkan satu fitur lainnya.

Ketika Anda menggunakan poker perencanaan, Anda mendapatkan ukuran instan seberapa besar perbedaan pendapat tentang ukuran pekerjaan. Jika saya pikir itu 2, dan Anda pikir itu 3, kita bisa menyebutnya 3 dan terus maju. Tetapi jika saya pikir itu 1 dan Anda pikir 5, lebih baik kita diskusikan.

Itu membuat semua orang berbicara dan berpikir tentang apa yang sedang dilakukan. Bahkan jika saya tidak akan mengerjakannya, saya harus memperhatikan perkiraan. Itu membantu saya ketika 2 bulan dari sekarang saya perlu mengerjakan sesuatu yang menyentuh area itu.

Ini juga mudah dipahami. Tunjukkan pada orang-orang suatu struktur gangguan kerja dan mata mereka berkaca-kaca dan mereka mulai ngiler di saat tidur. Tunjukkan pada mereka daftar tugas untuk 2-4 minggu ke depan dan mereka dapat memahaminya.

Hal baik lainnya: Diskusi tentang apakah tugas X adalah '3' atau '8' membantu tim menentukan dengan tepat ruang lingkupnya - jadi nanti, tidak ada perbedaan tentang tugas yang disyaratkan X.

Saya suka poin Pavel dan ingin menambahkan bahwa itu sangat membantu pengembang junior atau noobs belajar jauh lebih cepat. Mereka tidak bisa hanya duduk dan membiarkan para pengembang senior berkuasa. Pilihan mereka sama pentingnya dan jika mereka benar-benar fokus untuk membuat perkiraan mereka akurat, mereka akan belajar banyak dari pengembang senior.

Saya tidak suka di tim saya saat ini, terutama karena kami memiliki orang-orang yang pada dasarnya tidak setuju. Kami menghabiskan sebagian besar sesi perawatan untuk memperdebatkan apakah penunjukan itu bermanfaat, dan pemilik produk kami tidak pernah merinci epos, jadi kami biasanya berakhir dengan perkiraan kilter atau cerita di mana poin-poinnya menunjukkan bahwa benda itu hanya perlu dipecah. .

Tidak ada yang seperti memiliki 40 dan dua 20 dalam satu sprint!