Haruskah kemampuan individu dipertimbangkan dalam poin cerita?

Pemahaman saya tentang estimasi cerita adalah bahwa seseorang harus memperkirakan ukuran sebuah cerita seperti untuk pengembang imajiner rata-rata - sedikit seperti konsep hukum "pengamat yang masuk akal" dalam hukum. Artinya, Anda tidak boleh memperkirakan ukuran cerita dengan asumsi Anda harus melakukannya .

Sebagai contoh: dalam pekerjaan saya sebelumnya, saya adalah bagian dari sebuah tim di mana saya adalah pengembang Ruby yang paling percaya diri. Rekan satu tim saya akan secara rutin memperkirakan cerita yang berhubungan dengan Ruby jauh lebih besar daripada saya, dengan argumen seperti, "Yah saya tidak tahu bagaimana X bekerja di Ruby, jadi ini akan membuat saya perlu waktu lama untuk melakukannya."

Argumen saya terhadap ini berasal dari fakta bahwa perencanaan sprint adalah di mana kapasitas tim berperan. Itu adalah forum yang tepat untuk mengatakan, "Kapasitas kami sprint ini akan sedikit lebih rendah dari biasanya karena sebagian besar tugas berbasis Ruby, dan kami hanya memiliki satu pengembang Ruby yang kuat." Mempertimbangkan hal ini selama estimasi akan menggandakan aspek ini.

Saya menghargai referensi otoritatif dalam jawaban, tetapi pendapat sederhana juga bagus.

Poin cerita adalah estimasi relatif. Jadi dua kali poin berarti dua kali tingkat usaha. Perkiraan relatif kurang tergantung pada variasi tingkat keterampilan. Pertanyaannya bukan berapa banyak waktu yang Anda ambil untuk 1 poin, tetapi 2 poin itu membutuhkan usaha potensial 2 kali lebih banyak. Tingkat keterampilan bisa lebih penting jika Anda akan mengambil hari-hari yang ideal alih-alih poin cerita, karena Anda mengasumsikan tingkat produktivitas individu.

Estimasi relatif lebih kuat. Selain itu, evaluasi poin cerita tidak boleh dilakukan oleh seorang individu, tetapi hasil dari upaya tim kolektif . Untuk cerita yang tidak terlalu rumit, biasanya ada kesepakatan cepat. Untuk cerita yang lebih menantang, tim akan datang dengan hasil yang disetujui sebagian besar anggota, dan oleh karena itu secara implisit memperhitungkan tingkat keterampilan kolektif tim.

Akhirnya, evaluasi cerita dilakukan pada saat tugas-tugas dalam tim belum tentu diputuskan. Ini adalah satu argumen lagi untuk tidak memperhitungkan tingkat keahlian individu. Untuk perencanaan sprint, Anda akan mengambil kapasitas poin cerita tim, yang merupakan angka yang akan berkembang berdasarkan angka kinerja aktual, sehingga akan menyesuaikan diri dengan tingkat keterampilan global tim Anda.

Kesimpulannya, kemampuan individu tidak harus diperhitungkan dalam estimasi. Tetapi bahkan jika itu akan dilakukan, karena perkiraan kolektif, dan kekokohan pendekatan relatif, itu tidak masalah.

Jawaban kanonik adalah bahwa Anda tidak boleh mengubah taksiran per pengembang. Itu berarti Anda mendapatkan lebih banyak poin per sprint daripada rekan-rekan Anda, dan itu bagus karena poin mengukur kecepatan tim , bukan pengembang. Bisnis dapat memperkirakan berapa banyak tim akan menghasilkan untuk mendapatkan ekspektasi kasar pengiriman, dan semuanya hebat.

Namun itu menyebabkan segala macam masalah dalam praktik. Apa yang terjadi jika Anda berlibur minggu itu? Apa yang terjadi ketika waktu peninjauan tiba dan Anda sadar Anda menghasilkan 200% poin cerita rata-rata untuk 110% gaji rata-rata? Apa yang terjadi ketika bisnis mulai berpikir bahwa kecepatan tim yang dibagi oleh orang-orang sebenarnya merupakan perkiraan yang akurat? Apa yang terjadi ketika bisnis menyadari bahwa Anda menghasilkan lebih banyak bug daripada rekan-rekan Anda (sementara mengabaikan Anda menghasilkan lebih banyak fungsionalitas)? Apa yang merupakan cerita "ukuran gigitan" ketika orang memiliki gigitan yang beragam?

Apa yang saya temukan selama karier saya adalah bahwa sebagian besar tidak masalah. Proses ada untuk melayani Anda, bukan sebaliknya. Jika org Anda perlu mengukur apakah devs kelebihan beban, maka poin cerita per-dev adalah solusi yang baik. Jika org Anda perlu mengukur kecepatan tim, maka poin cerita dev-agnostik akan memberikan gambaran yang lebih jelas. Namun mereka selalu merupakan perkiraan, dan akan selalu disalahgunakan dan disalahtafsirkan.

Pada akhirnya, mereka dibuat poin untuk proses pembuatan yang Anda butuhkan untuk beradaptasi dengan lingkungan Anda .

TL; DR
Kita harus selalu berasumsi bahwa hanya pengembang yang kompeten yang akan ditugaskan ke cerita tertentu.

Kompetensi (atau ketiadaan) bukanlah penghinaan. Ini hanyalah ukuran yang wajar dari keterampilan pengembang yang tidak tertinggal atau berpengalaman luar biasa.

Ini bisa jadi masalah pendekatan perusahaan tertentu. Saya telah melihat perkiraan perusahaan yang disesuaikan untuk pengembang tertentu. Saya juga melihat perusahaan yang menerapkan sistem di mana tiga pengembang yang dipilih secara acak membuat perkiraan cerita sebelum hampir secara acak menugaskan pengembang (bukan salah satu dari tiga awal) untuk tugas tersebut.

Setiap sistem dapat bekerja, setiap sistem dapat gagal. Pertanyaannya bukan pada sistem mana yang lebih baik, tetapi kelemahan mana yang dapat / mau dihadapi perusahaan .

Pada prinsipnya, waktu belajar untuk menguasai bahasa / kerangka kerja sebaiknya tidak dimasukkan. Garis singgung minor: meskipun mereka seharusnya tidak ada di dunia yang ideal, waktu belajar untuk hambatan spesifik proyek atau cerita harus dimasukkan.

Ada banyak pembenaran untuk melakukannya, tetapi saya percaya pendekatan ini umumnya merupakan pilihan yang lebih baik, karena tetap setia pada niat memperkirakan beban kerja. Ini mungkin hanya masalah pendapat saya, daripada objektifitas. Saya tidak bisa mengatakan dengan pasti.

Waktu belajar bersifat pribadi . Ini dalam ruang lingkup untuk pengembang tertentu yang perlu bekerja pada teknologi tertentu. Itu tidak relevan ketika menilai beban kerja cerita pengguna, karena cerita pengguna hanya dalam ruang lingkup aplikasi (dan teknologi yang digunakannya).

Waktu belajar umumnya tidak menumpuk. Katakanlah bahwa pemula kami hanya tahu sedikit tentang C #, dan kami memperkirakan bahwa ia membutuhkan tiga hari ekstra untuk mencari tahu lingkungan sebelum ia dapat melakukan pekerjaan. Seperti yang biasa terjadi di banyak perusahaan tempat saya bekerja, kami sekarang sedang rapat dimana kami diharapkan memperkirakan beberapa cerita pengguna (secara individu). Sebagai contoh, katakanlah kita memiliki tiga cerita untuk diatasi.

• Apakah kita menambahkan tiga hari untuk setiap cerita? Jika ketiga cerita memiliki fokus teknis yang sama, itu berarti bahwa pemula tidak akan benar-benar membutuhkan waktu tambahan pada cerita kedua dan ketiga. Kami sudah melebih-lebihkan pekerjaan dalam enam hari.
• Apakah kita menambahkan satu hari ke setiap cerita? Ini juga tidak benar. Jika kita hanya menugaskan rookie ke salah satu dari tiga cerita, maka kita telah mempersingkat dia dua hari yang dibutuhkan waktu belajar; dan kami telah memberikan dua hari waktu belajar yang tidak perlu kepada pengembang lain.
• Apakah kita menambahkan tiga hari ke satu cerita? Bagaimana kita bisa menjamin bahwa cerita ini akan ditangani sebelum dua lainnya? Inti dari membuat cerita pengguna yang terpisah adalah bahwa cerita biasanya dapat ditangani secara independen satu sama lain. Ketepatan estimasi kami sekarang bergantung pada kedua asumsi bahwa pemula kami akan melakukan pekerjaan, ditambah urutan di mana ia ditugaskan tugas-tugas (jika itu penting, misalnya jika beban kerja gabungan melampaui sprint tunggal).

Catatan :
Ada kasus-kasus lain di mana waktu belajar tidak menumpuk, misalnya jika tiga cerita berada di topik yang sangat berbeda dan memerlukan keterampilan yang berbeda.
Tetapi untuk mengetahui apakah ini masalahnya atau tidak, kita perlu melihat ketiga cerita secara bersamaan, yang perlahan-lahan mulai melanggar prinsip memiliki cerita pengguna yang independen . Jika kami telah menangani perkiraan ini dalam pertemuan terpisah, mungkin dengan pengembang yang berbeda hadir; kami tidak akan dapat secara akurat mengukur tumpang tindih antara cerita.

Karena kami tidak dapat menjamin cerita mana yang benar-benar akan berakhir (pelanggan mungkin menolak estimasi besar), dan siapa yang akan ditugaskan kepadanya, mencoba menghitung pengembang tertentu untuk ditugaskan ke cerita tertentu itu sia-sia. Itu hanya berakhir mengotori air.

Sebagai gantinya, kita harus membuat estimasi beban kerja dengan asumsi pemula telah dipercepat (dan karena itu merupakan pengembang yang setara dengan rekan kerjanya).
Perkiraan seperti itu adalah agnostik-pengembang, dan kebenaran estimasi itu tidak berfluktuasi tergantung pada pengembang mana yang akhirnya ditugaskan untuk cerita tersebut.

Catatan
Masih relevan untuk mengakui bahwa pengembang tertentu mungkin perlu waktu ekstra untuk belajar sebelum dapat menangani cerita tertentu. Itu masih pertimbangan yang sangat relevan. Tetapi pertimbangan ini tidak harus dilampirkan pada cerita , melainkan penugasan pengembang khusus ini untuk cerita khusus ini.

Tetapi, ketika saya mulai dengan, ini dapat bervariasi dari perusahaan ke perusahaan. Beberapa perusahaan mungkin tidak terlalu peduli tentang waktu belajar (mis. Jika pengembang mau tidak mau harus belajar untuk menggunakan teknologi pula). Orang lain mungkin sangat bergantung pada keakuratan estimasi ini, karena memengaruhi penagihan kepada pelanggan.

Pada akhirnya, ini masalah memetik racun Anda. Tidak satu pun dari pendekatan ini dijamin lebih akurat daripada yang lain.

Ini adalah topik yang kompleks, dan sering ada perdebatan tentang topik tersebut. Saya tidak suka konsep opini "kanonik" tentang ini: ada berbagai pendapat dengan nilai. Tetapi ada nilai-nilai pendukung, prinsip dan praktik yang harus memandu pendekatan ini.

Berikut ini berdasarkan pendapat saya sendiri yang bekerja dengan tim scrum selama lebih dari 10 tahun. Tapi itu hanya pendapatKU.

1. Poin Cerita sebagai metode Peramalan Maksud asli dari poin cerita adalah untuk menemukan metode cepat untuk memperkirakan upaya dengan tujuan memperkirakan apa yang dapat diselesaikan oleh suatu tim selama periode waktu tertentu. Beberapa "tokoh" menyatakan bahwa poin hanya digunakan untuk meramalkan ruang lingkup jangka panjang (lebih dari rilis, misalnya), dan tidak menentukan kapasitas pada tingkat sprint. Selain itu, konsepnya adalah bahwa tim menerapkan "ukuran relatif" berdasarkan nilai historis (Upaya X mirip dengan Upaya B, yang merupakan 3 poin). Ini mempercepat proses estimasi sehingga tim tidak perlu memecah pekerjaan masa depan ke dalam paket kerja yang terperinci dan menerapkan jam untuk semua tugas. Tim berkinerja tinggi berusaha untuk menumbuhkan semua pekerja teknis menjadi anggota yang sangat kompeten dari tingkat keterampilan yang sama. (Konsep ini akan dieksplorasi lebih lanjut di poin # 4) Ketika ini tercapai, maka tingkat keterampilan individu benar-benar bukan variabel dalam ukuran. TETAPI: Biasanya butuh waktu yang cukup lama dan upaya bersama untuk mencapai tujuan itu. JADI ... apa yang kita lakukan sebelum sampai di sana?

2. Jam kerja menentukan kapasitas sprint: Menurut "tokoh-tokoh" yang sama yang menyatakan bahwa poin digunakan untuk peramalan jangka panjang, mereka juga mengusulkan bahwa Jam Tugas digunakan untuk menentukan kapasitas sprint, bukan poin. Menurut pendapat saya, itu baik-baik saja, tetapi saya akan mengatakan bahwa ketika saya telah membantu melatih tim untuk "Berperforma Tinggi", keterampilan mereka yang rata-rata keluar di mana mereka dapat secara akurat menentukan apa yang bisa mereka selesaikan dalam sprint menggunakan Story Points saja. . Sekali lagi, itu bisa menjadi tujuan yang kami perjuangkan, tetapi tim yang lebih baru belum siap untuk itu. Karenanya, Anda dapat menemukan dalam satu sprint Story dengan 2 poin yang memiliki 12 jam tugas, dan yang lain dengan 25 jam upaya. Jadi apa yang kamu lakukan? Beberapa orang yang saya sebut "agile-purist" akan menyatakan bahwa ukuran Story (dalam poin) harus agnostik terhadap durasi. Yang lain tidak setuju. Baca logika pada item # 3 dan lihat apa yang Anda pikirkan.

3. Menunjuk Cerita berdasarkan konsensus: Menerapkan Volume, Tidak Diketahui, Kompleksitas, Pengetahuan

Jadi tim melihat karya dan perlu menyepakati poin yang akan menjadi proksi untuk Level Upaya. Baik? Dengan asumsi bahwa semua keterampilan sama, maka konsensus mudah dicapai. Tetapi sering tim memiliki seorang pria yang adalah guru Jawa, yang lain tidak begitu hebat di Jawa (mungkin dia adalah seorang C # atau .Net atau orang Cobol dan sedang belajar Java). Jadi tugas X untuk Bob sangat sederhana. Bagi Jane, ini lebih sulit.

Tim tangkas mencoba mempromosikan kepemilikan kode kolektif, dan menumbuhkan / memperluas keahlian. Jadi kami biasanya tidak memberikan cerita kepada orang-orang berdasarkan keahlian mereka: kami lebih suka tim secara kolektif mengerjakan cerita dan belajar bersama. Ini selaras dengan konsep "melambat untuk mempercepat": jika kita meluangkan waktu untuk memberi Jane pengalaman dengan Java, sementara ini mungkin memperlambat kita pada awalnya, kemudian kita akan memiliki pengembang Java yang lebih kompeten. Faktanya, jika kita hanya memiliki SATU pakar Java, dan semua orang bekerja berdasarkan bidang keahliannya masing-masing, kita menciptakan situasi dengan beberapa "titik kegagalan" potensial. Apa yang terjadi dalam sprint ketika 90% pekerjaannya adalah Java, tetapi Bob (pakar Java kami) sedang sakit atau sedang berlibur? Dengan mengembangkan keterampilan, kami menghilangkan potensi kemacetan dan mengurangi risiko. Dengan mengingat hal itu: Ketika tim melihat sebuah cerita, mereka harus memiliki beberapa konsep dalam pikiran ketika mengukur. Anda bisa memikirkan akronim VUCK untuk mengingat ini.

Volume: Beberapa upaya cukup sederhana, tetapi membutuhkan banyak tugas yang berulang. (Saya mempunyai seorang pria yang harus menyalin dan memformat ulang 50 + tabel yang mengatakan itu adalah 1 poin karena sederhana. Tetapi setelah refleksi tim menyadari bahwa sementara itu mudah, itu memakan waktu dan ada sejumlah besar tabel untuk dipindahkan dan dioptimalkan. Jadi kami harus menyesuaikan kembali poin karena volume pekerjaan)

Tidak Dikenal: Terkadang kami BERPIKIR kami tahu apa yang harus dilakukan, tetapi kami juga mengidentifikasi beberapa yang tidak diketahui - ini mewakili RISIKO . Dan ini menyiratkan bahwa kita mungkin mengalami masalah tak terduga yang harus kita selesaikan, desain ulang, atau coba solusi yang berbeda.

Kompleksitas: Yang ini cukup jelas. Beberapa solusi rumit secara teknis. Kami tahu persis apa yang harus dilakukan, tetapi membutuhkan keahlian teknis. Kompleksitas juga mengandung risiko, bukan? Jadi, bahkan jika kita semua memiliki keterampilan yang sama, kompleksitas teknis menyiratkan kita mungkin mengalami tantangan yang tidak terduga. Jadi kita bisa membuat cerita ini lebih besar.

Pengetahuan: Apakah kita BENAR-BENAR tahu apa yang sedang kita selesaikan? Terkadang pelanggan tidak sepenuhnya jelas tentang solusi yang mereka inginkan, dan kami bereksperimen sedikit. Atau mungkin tidak ada yang pernah mengimplementasikan solusi ini (teknologi baru yang tidak pernah digunakan sebelumnya) sehingga kami tidak tahu apa yang tidak kami ketahui.

Menurut pendapat saya, setiap pertimbangan ini sebenarnya adalah proksi untuk durasi yang diperpanjang. Cerita mudah, banyak volumenya? Itu akan memakan waktu lebih lama, atau kita perlu membagi cerita. Tidak dikenal Risiko tambahan, penelitian, eksperimen, mungkin butuh waktu lebih lama atau kita perlu membagi cerita. Kompleks? Risiko tambahan, perlu memperbaiki bug, mendesain ulang dll. Sehingga mungkin membutuhkan waktu lebih lama. Tidak tahu apakah kami memiliki Pengetahuan yang diperlukan? Kami memiliki risiko tambahan, mungkin perlu bereksperimen, dll, sehingga mungkin perlu waktu lebih lama ...

Lihat kemana ini? Jadi, sementara konsep poin cerita mencegah kita untuk berpikir tentang durasi saat memperkirakan, di sisi lain itu tidak masuk akal untuk memiliki cerita 1 poin yang dapat kita selesaikan dalam 4 jam dan cerita 1 poin lainnya yang sederhana tetapi akan mengambil 2 minggu.

4. Tim berkinerja tinggi menghilangkan Silo & Bottlenecks: Karena tim mencoba untuk menaikkan level semua anggota, mereka terkadang memiliki anggota yang kurang berpengalaman mengambil tantangan baru, atau akan memasangkan kode untuk berbagi pengetahuan untuk meningkatkan sebagai tim. Seperti yang disebutkan sebelumnya, ini adalah syarat jika tim akan pernah mencapai level Performa Tinggi yang benar.

Jadi, jika Jane secara sukarela melakukan upaya Jawa itu dan itu akan membuat upaya itu 2x atau 3x durasi dari upaya yang sama jika Bob melakukannya, apa yang Anda lakukan? Seiring waktu, tim saya menentukan ukuran cerita berdasarkan tingkat upaya (LOE) / VUCK untuk orang-orang yang bekerja. Tidak masuk akal bagi Bob, tim Guru, untuk mengatakan "itu angka 1" padahal bagi Jane itu tidak mudah dan membutuhkan waktu seminggu untuk menyelesaikannya, ditambah memerlukan waktu Bob untuk pengkodean pasangan dan peninjauan kode. Oleh karena itu, kami mengumpulkan poin-poin tersebut untuk mencerminkan LOE yang sebenarnya. Kali berikutnya cerita yang sama datang, apa yang 8 bagi Jane sebelumnya menjadi 5. Akhirnya, semua orang setuju itu mudah 3. Pada saat itu, kami tahu kami tumbuh sebagai sebuah tim.

TLDR

Tidak, tapi mungkin bukan karena alasan Anda.

Versi Panjang

Banyak jawaban lain telah menjelaskan bahwa Poin Cerita harus dihitung murni sehubungan dengan karya lain. Ini mutlak benar. Karena Story Points memperkirakan jumlah pekerjaan daripada waktu yang dibutuhkan untuk menyelesaikannya, maka tidak masuk akal untuk memberikan Story Points berdasarkan individu.

Misalnya (salah satu favorit saya), pertimbangkan tugas Anda "Gali lubang". Anda dapat memperkirakan ini berdasarkan jumlah bumi yang akan dihapus atau waktu yang Anda perlukan untuk menghapus bumi. Teman saya menggali keseluruhan dengan kecepatan 3 meter per jam, saya memiliki penggali mekanik besar sehingga saya bisa mengelola 100! Satu-satunya yang konstan adalah jumlah bumi - oleh karena itu itulah yang kami gunakan sebagai unit estimasi kami.

Namun, alasan kedua (dan dalam pandangan saya lebih penting) untuk mendiskontokan kemampuan pengembang untuk memperkirakan cerita pengguna adalah kenyataan bahwa hampir setiap cerita pengguna kemungkinan akan dikerjakan oleh banyak orang.

Anda mungkin memiliki arsitek, pengembang, penguji, mungkin pengembang kedua untuk melakukan UI. Sebelum cerita pengguna Anda ditandai sebagai Selesai (dikerahkan dan dilakukan secara ideal), banyak orang yang berbeda akan mengerjakannya. Tiba-tiba ide estimasi berdasarkan pengembang yang bersangkutan tidak masuk akal, satu-satunya cara untuk memperkirakan secara akurat berapa banyak upaya yang akan dilakukan dari tim adalah dengan mengukur kecepatan tim dan memperkirakan pekerjaan yang harus diselesaikan oleh tim.

Tidak ada "aku" dalam tim dan sama sekali tidak aku dalam perencanaan lincah!