Apakah benar untuk menilai anggota Scrum sesuai dengan jumlah kisah pengguna yang berhasil diselesaikan?

Ketika Manajer saya memberi tahu tim bahwa " sekarang cerita pengguna yang berhasil dan selanjutnya akan dipertimbangkan untuk penilaian! "

Kami duduk di sana untuk sementara kaget dan itu adalah salah satu dari beberapa momen yang dia berikan kepada kami :-)

Kami merasa itu adalah ide yang bodoh, karena ini akan merusak semua konsep dan tujuan metodologi pengembangan tangkas.

Biarkan saya tahu apa yang kalian pikirkan? dan bagaimana kita bisa meyakinkannya?

Sandy, sayangnya pernyataan manajer Anda adalah kesalahpahaman klasik tentang scrum pada khususnya dan lincah secara umum.

Pendekatan yang diusulkan membunuh kolaborasi dan melawan prinsip kepemilikan kode kolektif . Cerita pengguna gesit (jika itu gesit nyata) jarang diselesaikan sebelum disentuh oleh banyak orang. Juga, Anda akan memiliki cerita pengguna dari waktu ke waktu yang perlu dikerumuni agar selesai dalam iterasi. Bagaimana Anda akan mendapatkan semua itu ketika insentif individu disejajarkan 180 derajat ke arah yang berlawanan?

Insting tim Anda benar. Sumber apa yang akan saya sarankan dalam jangka pendek agar Anda baca ketika Anda melakukan brainstorming terhadap respons manajer Anda? Lihatlah blog para pakar tangkas terkenal seperti Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby dan beberapa lainnya dan cari artikel tentang organisasi tim tangkas.

Keberatan utama saya terhadap metode penilaian ini adalah bahwa hal itu dapat menjadi hambatan untuk kerjasama antara pengembang. Saya pikir bagian penting dari produktivitas tim pengembang adalah kesediaan anggota tim untuk saling membantu. Ketika saya memahami skema yang disarankan, itu bisa menyebabkan pengembang bertahan dengan tugas yang ditugaskan sendiri dan mengabaikan anggota tim lain yang macet dan dengan mudah bisa dilepaskan oleh sedikit bantuan.

Kami selalu mencari kontribusi programmer untuk tim dan bisnis.

Ini setara dengan mengukur garis kode, atau jumlah bug - tetapi sedikit lebih canggih.

Pada pandangan pertama tidak ada yang salah dengan pengukuran, tetapi ketika Anda memikirkannya, Anda mulai mengajukan keberatan:

• bagaimana dengan cerita yang lebih rumit?

adalah yang paling jelas yang muncul dalam pikiran - saya yakin ada orang lain.

Manajer Anda jelas berpikir ini adalah ide yang bagus, jadi Anda harus berhati-hati bahwa ketika Anda mengajukan keberatan, Anda juga dapat memberikan solusi. Solusi ini mungkin harus merupakan modifikasi pada rencananya daripada skema baru.

Jadi misalnya Anda mungkin ingin menunjukkan bahwa seseorang yang hanya mengerjakan cerita "mudah" akan menyelesaikan lebih dari seseorang yang bekerja pada yang lebih "sulit" dan ini mungkin mengarah pada konsentrasi pada aspek-aspek yang kurang penting dari perkembangan. Jadi salah satu solusinya mungkin dengan mempertimbangkan jumlah poin cerita daripada hanya jumlah cerita.

Saya setuju dengan ChrisF bahwa ini kembali ke masalah yang sama dengan pengukuran apa pun. Apa yang Anda puji adalah apa yang Anda dapatkan. Akan selalu ada orang yang memainkan sistem, apa pun sistem itu.

Satu-satunya metode efektif nyata yang saya temukan untuk memberi penghargaan kepada programmer adalah dengan tiga langkah.

1. Lead mengetahui dan memahami kemampuan orang-orang di tim mereka.
2. Manajer mendengarkan rekomendasi lead untuk anggota tim yang tidak menarik perhatian mereka.
3. Tim dipuji sebagai keseluruhan untuk sprint yang sukses.

Seluruh kunci adalah bahwa programmer bukan roda penggerak dalam mesin yang dapat 'disetel' dengan melihat statistik. Orang-orang nyata perlu diperiksa dan ditingkatkan secara keseluruhan dan tim harus dapat saling mengandalkan dalam koperasi, dan bukan dengan cara kompetitif.

Orang-orang yang berkinerja buruk dalam tim diberikan setiap kesempatan untuk perbaikan dan pengayaan sebelum mereka dianggap dilepaskan. Pada akhirnya, programmer yang baik akan berkembang di lingkungan ini dan programmer yang buruk, yang menolak untuk ditingkatkan, akan dilepaskan.

Sebagian besar waktu, Cerita Pengguna diselesaikan dalam upaya kolektif. Ini membuatnya hampir mustahil untuk mendasarkan penilaian individu pada metrik ini.

Metrik itu sendiri dapat dengan mudah dimanipulasi karena proses perencanaan juga merupakan upaya tim dan bahkan lebih cepat dari itu, seluruh sistem akan dicurangi. Yang pasti Anda tidak inginkan dalam proses yang berfokus pada orang.

Saya pikir kinerja yang baik harus dikenali oleh semacam sistem bonus berdasarkan kesuksesan tim, tetapi Cerita Pengguna bukan indikator keberhasilan yang baik.