Perencanaan Poker dan pengembang bertele-tele [ditutup]

10

Tim saya terdiri dari 4 pengembang; semua berpengalaman dan terampil. Salah satunya adalah bab bertele-tele, bermaksud baik yang bersikeras mendefinisikan solusi teknis untuk cerita kami sebelum kami meletakkan perkiraan kami dengan Poker Perencanaan. Dia menolak untuk memperkirakan jika dia tidak memiliki gagasan kasar tentang solusi teknis yang disepakati (yang terdengar masuk akal, kan?).

Masalahnya adalah sesi estimasi kami membutuhkan waktu lama untuk selesai !! Dalam pengalaman Anda, bagaimana Anda menghadapi kepribadian seperti ini ketika bermain poker perencanaan?

agile planning

— Pomario
sumber

13

Dia tampaknya menyukai hal-hal yang didefinisikan secara formal, sehingga timer akan menjadi ide yang baik, karena poker perencanaan didefinisikan sebagai telah menetapkan jumlah waktu bagi orang untuk berbicara.

Dia punya ide yang salah tentang estimasi juga, semua orang memperkirakan terhadap cerita dan bukan implementasinya , itulah sebabnya Anda mendapatkan varians seperti itu. Misalnya beberapa orang mungkin tidak tahu tentang kerangka kerja atau solusi rak dan mulai menulis sesuatu dari awal.

— StuperUser
sumber

1

Timer adalah ide bagus. Ini mengingatkan para pembicara untuk bersikap ringkas dan memaksa mereka untuk menyaring apa yang ingin mereka katakan ke poin yang sangat mendasar.

— Shane Wealti

Ini juga membantu jika pekerjaan pendahuluan pada cerita didorong lebih awal, maka pendahuluan desain teknis dapat dilakukan "offline" dari pertemuan itu sendiri. Poker bukanlah tempat untuk membagi solusi, Anda hanya membuang-buang waktu seluruh departemen. Gagasan lain adalah menambahkan "desain barang ini" sebagai sebuah cerita yang menandai kotak waktu awal "mengimplementasikan barang-barang ini." Babak berikutnya mendapatkan estimasi nyata untuk implementasi.

— Patrick Hughes

2

Tidak hanya timer adalah ide yang bagus, saya percaya itu direkomendasikan (mungkin seseorang dengan Agile Planning and Estimation dapat mengkonfirmasi ini). Pemahaman saya adalah bahwa, seperti kebanyakan kegiatan, perencanaan sesi poker harus dibatalkan untuk mencegah situasi seperti apa yang dimaksud dengan pertanyaan.

— Thomas Owens

1

For example some people may be ignorant of a framework or off the shelf solution and start writing things from scratch- Karenanya diskusi. Lalu semua orang tahu tentang itu dan perkiraan lebih baik.

— Izkata

3

Anggota tim Anda membunyikan kepribadian analis. Analis memerlukan banyak informasi untuk membuat keputusan. Gagasan pengatur waktu adalah yang terbaik, tetapi berhati-hatilah, dia akan memperingatkan apa pun yang dia berikan. Bekerjalah dengannya untuk menjelaskan bahwa ini hanyalah perkiraan awal berdasarkan masalah BUKAN solusinya. Jika dia ingin mengajukan pertanyaan, mintalah dia untuk menyelesaikannya, bukan solusinya. Anda mungkin harus memotongnya atau mengganggu dia untuk sementara waktu ketika dia terus melayang ke solusi.

Pastikan Anda memegang orang lain di tim untuk aturan yang sama sehingga dia tidak merasa dikecualikan. Analis adalah kepribadian yang umum dalam pemrograman, jadi Anda mungkin bertemu dengan orang lain seperti dia.

— Bill Leeper
sumber

2

+1, saya adalah seorang analis dan bergumul dengan masalah ini. Saya perhatikan saya jauh lebih teliti dan lengkap dan memiliki lebih sedikit bug daripada rekan-rekan saya tetapi saya dengan mudah menjadi stres dan tidak efektif dalam situasi dengan informasi yang kurang sempurna. Saya berusaha setiap hari untuk mencoba dan menangani hal yang tidak diketahui dengan cara yang tidak terlalu menegangkan.

— maple_shaft

2

Sepertinya kolega Anda tidak memahami perbedaan antara perkiraan dan komitmen atau belum dikomunikasikan kepadanya selama pelatihan. Dan, karena Anda mencoba melampirkan masalah pada kepribadiannya, mungkin saja seluruh tim Anda belum memahaminya. (Tapi jangan khawatir! Sebagian besar industri kita tidak memahaminya. Agile itu sulit!)

Ketika kita mengatakan ukuran cerita adalah X poin, kita sebenarnya berarti distribusi probabilitas. Jika perkiraan kami benar, cerita akan memakan waktu lebih lama 50% dari waktu (dan 50% lainnya akan memakan waktu lebih sedikit). Jika kolega Anda percaya bahwa, ketika X unit waktu telah berlalu, ia akan diminta untuk mendemokan cerita atau yang lain, yang mengubah pendekatannya terhadap estimasi.

Perencanaan poker memperkenalkan kesalahan lain: alih-alih mencoba menjabarkan X, kami mencocokkannya dengan skala diskrit, skala Fibonacci (1, 2, 3, 5, 8, dll.) Menjadi yang paling populer. Dikatakan apa ukurannya tidak sebanyak apa itu. Ketika kita mengatakan ukuran cerita adalah 3 poin, kita benar-benar mengatakan "itu X plus-minus beberapa varian dan X lebih dekat ke 3 daripada ke 2 atau 5."

Tim Anda bisa mendapat manfaat dari memahami betapa tidak tepatnya latihan ini dan bagaimana perkiraan berbeda dari komitmen. Jika Anda ingin / perlu mempelajari konsep-konsep ini secara mendalam, buku ini memilikinya.

— azheglov
sumber

Ketika merencanakan jika menurut Anda sebuah cerita membutuhkan waktu 3 hari dan satu jam, Anda harus menggunakan 5 hari itu, bukan membulatkannya . Terserah pengembang untuk tetap disiplin dan membuat estimasi terhadap tugas, bukan membuat rencana untuk tugas sesuai dengan estimasi.

— StuperUser

10

"Sepertinya kolega Anda tidak mengerti perbedaan antara estimasi dan komitmen." Saya benar-benar dapat memahami hal ini karena banyak manajer SELALU akan mengambil estimasi awal Anda dan mengubahnya menjadi komitmen . Beberapa dari kita seperti saya sangat gugup memberikan perkiraan kasar karena manajer telah menahan kami untuk mereka dan kemudian mengharapkan kami untuk bekerja di akhir pekan yang panjang tanpa tidur untuk menyelesaikannya sesuai tenggat waktu sprint.

— maple_shaft

1

@maple_shaft: Anda memang benar, perkiraan / komitmen adalah salah satu kesalahpahaman terbesar dalam industri kami dan kesalahpahaman ini adalah salah satu hambatan terbesarnya. "Kegugupan" Anda, "akhir pekan yang panjang", "tidak tidur" dll. Adalah di antara konsekuensinya. Anda dapat menyelesaikan masalah ini hanya jika Anda menyertakan semua orang, seluruh tim Anda, manajer Anda, dll. Inilah sebabnya mengapa transisi yang gesit sangat sulit. Mengambil setumpuk kartu tanpa memahami konsep-konsep ini mudah.

— azheglov

1

@azheglov, kadang-kadang transisi Agile sulit karena manajemen berpikir bahwa mereka menginginkan Agile ketika dalam kenyataannya mereka megalomaniak yang mengelola mikro dengan kompleks inferioritas yang mengerikan dan keinginan kuat untuk TIDAK PERNAH menyesuaikan jadwal sprint ketika perubahan persyaratan atau informasi baru ditemukan. Dengan kata lain, mereka tidak benar-benar menginginkan Agile karena Agile sejati sangat bertentangan dengan semua yang mereka ketahui.

— maple_shaft

@maple_shaft, Anda juga benar! Saya tidak akan membahas semua alasan mengapa lincah sulit dalam komentar saya ;-)

— azheglov

1

Saya bisa melihat dari mana anggota tim Anda berasal, tetapi dia jelas belum sepenuhnya memahami konsep Agile dan Perencanaan Poker. Anda harus mulai dengan memastikan semua orang memahami konsep dan alasan di baliknya, dan kemudian mereka harus melakukannya sendiri.

— AJC
sumber

1

Untuk tim tempat saya bekerja, pada awal setiap sesi perencanaan, saya menetapkan timer pasir 3 menit di atas meja. Saya membiarkan seluruh tim tahu bahwa jika pada suatu saat mereka merasa percakapan itu menjadi penyelaman yang mendalam, atau tidak relevan, atau dengan cara lain melampaui apa yang mereka rasa diperlukan untuk memperkirakan cerita dalam poin cerita, maka siapa pun dalam tim dapat membalik timer. Begitu pasir habis, maka tim langsung memperkirakan.

Metode ini memberdayakan setiap individu dalam tim untuk membatasi percakapan, ketika mereka merasa percakapan tidak lagi berguna untuk memperkirakan cerita yang sedang dibahas. Pada saat yang sama, itu tidak langsung memotong pembicaraan, tetapi memberikan semua orang indikasi visual bahwa percakapan mereka perlu diselesaikan dalam beberapa menit ke depan, karena kita kemudian akan memilih.

Alat lain yang saya gunakan untuk membantu agar sesi perencanaan tetap fokus, adalah untuk memastikan bahwa semua orang di tim telah mengkaji cerita di bagian atas tumpukan paling tidak beberapa hari sebelum perencanaan. Idenya adalah bahwa jika Anda memiliki daftar pertanyaan segera setelah membaca cerita, Anda dapat memberi tahu pemilik produk tentang pertanyaan potensial beberapa hari sebelumnya, sehingga mereka dapat mengklarifikasi cerita atau kriteria penerimaan untuk mudah-mudahan membatasi diskusi nanti. Ini juga memungkinkan orang untuk mulai berpikir tentang potensi desain cerita, sebelum perencanaan (dan mencoba merancang selama perencanaan).

— Shawn S
sumber