🕺🏼 🏂🏾 🧑🏾‍🤝‍🧑🏽 Menilai Tugas di Poin Cerita 👨🏼‍🔬 🎪 ⛔️

Hampir setiap orang yang menemukan pengembangan perangkat lunak tahu apa penilaian tugas Story Points (SP), namun, kadang-kadang saya memberi tahu kolega dari departemen lain atau pendatang baru kepada tim yang belum pernah mengalami pendekatan seperti itu, mengapa kami menggunakan SP dan mengapa itu nyaman bagi tim dan efektif bagi perusahaan.

Tujuan dari teks ini adalah untuk menggambarkan apa itu SP, bagaimana menggunakannya untuk mengevaluasi masalah, dan mengapa teknik ini menjadi begitu luas.

Masalah

Menghitung waktu yang dibutuhkan untuk menyelesaikan tugas adalah tugas yang sangat sederhana dan sangat berisiko yang dihadapi oleh tim pengembangan.

Penilaian yang salah menjadi salah satu alasan pertama untuk rincian jadwal atau bahkan kegagalan proyek.
Masalahnya adalah bahwa bisnis melihat penilaian sebagai kewajiban. Pengembang melihat peringkat sebagai asumsi.

Sebagai ilustrasi, saya akan mengutip contoh dialog fiksi dari buku Robert Martin, The Ideal Programmer.

Mike (Manajer): Bagaimana kemungkinan Anda dapat mengelola dalam tiga hari?

Peter (Pengembang): Saya bisa mengatasinya.

Mike: Bisakah Anda menyebutkan nomor?

Peter: Lima puluh atau enam puluh persen.

Mike: Jadi ada kemungkinan yang cukup tinggi bahwa Anda akan membutuhkan empat hari?

Peter: Ya. bahkan lima atau enam mungkin diperlukan, meskipun saya meragukannya.

Mike: Sejauh mana Anda meragukannya?

Peter: Oh, saya tidak tahu ... Saya yakin sembilan puluh lima persen bahwa pekerjaan akan selesai dalam waktu kurang dari enam hari.

Mike: Jadi mungkin tujuh?

Peter:Nah, jika semuanya serba salah ... Sial, jika semuanya serba salah, mungkin sepuluh atau bahkan sebelas hari. Tetapi kemungkinan kebetulan seperti itu sangat kecil, bukan?

Saya pikir dialog di atas terdengar cukup akrab bagi pengembang atau manajer proyek.

Sayangnya, masalah dengan nilai tidak berakhir di sana. Perangkap lain juga harus dipertimbangkan:

Korelasi Grade dan Grade

Peringkat yang diberikan hanya valid jika penulis peringkat akan melaksanakan tugas. Setelah semua, jelas bahwa waktu yang dihabiskan untuk tugas oleh pengembang senior dan magang akan berbeda.

Penilaian ideal di dunia yang tidak sempurna

Rapat yang mendesak, surat kerja, utusan dan manajer tugas yang jatuh semakin memperumit proses pengembangan yang sudah kompleks, yang membuat jam ideal yang kita bayangkan ketika mengevaluasi buruk berguna bagi manajer proyek yang mencoba menyusun grafik Gantt yang cepat menua.

Selanjutnya, kami akan mempertimbangkan pendekatan untuk mengevaluasi tugas-tugas dalam SP dan bagaimana ia mengatasi semua kesulitan yang dijelaskan di atas.

Solusi alternatif

Secara alami, pendekatan menggunakan SP bukanlah upaya pertama untuk menyelesaikan masalah yang disuarakan, meskipun mungkin yang paling populer.

Dalam blok ini saya akan berbicara tentang program lain yang mencakup skema penilaian tugas. Program ini disebut PERT dan terbiasa dengan itu tidak perlu untuk mencapai tujuan dari teks, sehingga Anda dapat melanjutkan ke blok berikutnya dengan aman.

Teknik Evaluasi dan Tinjauan Program

PERT Program Evaluation and Review Technique 50- XX .

:

O: . .

N: .

P: , , .

:

μ = \frac{O + 4 N + P}{6}

$\mu= \cfrac {O+4N+P} {6}$

, :

σ = \frac{P - O}{6}

$\sigma=\cfrac{P−O}{6}$

, :

\frac{1 + 12 + 12}{6} \pm \frac{12 - 1}{6}

$\cfrac{1+12+12}{6} ± \cfrac{12-1}{6}$

, . , , .

Poin cerita

Apa itu Poin Cerita, dan bagaimana mereka membantu mengevaluasi tugas? Mike Cohn, Evileist Agile dan CEO Mountain Goat Software, berbicara tentang teknik ini dengan sangat singkat dan jelas.

Bagaimana jika, alih-alih mengevaluasi waktu yang diperlukan untuk menyelesaikan tugas, kami akan mengevaluasi upaya yang diperlukan untuk menyelesaikan masalah ini? Untuk melakukan ini, kami akan mengambil skala peringkat dan menjalankan tugas-tugas yang memerlukan evaluasi.

Pada saat yang sama, semua faktor yang dapat memengaruhinya harus dimasukkan dalam penilaian upaya:

Jumlah pekerjaan yang dibutuhkan;
Kompleksitas teknis tugas;
Kemungkinan risiko dan ketidakpastian dalam persyaratan;

Kedengarannya tidak mudah, tetapi jangan lupa bahwa kita tidak perlu memberikan peringkat yang jelas kepada setiap tugas, kita hanya perlu menemukan tempatnya pada skala peringkat di antara tugas-tugas lain yang akan dievaluasi.

Saya ingin menekankan dua aspek penting dari metode Story Points yang memungkinkannya untuk menyelesaikan masalah yang kita bahas di halaman sebelumnya:

Penilaian Relatif

Tugas-tugas tersebut dievaluasi relatif satu sama lain, sehingga muncul skala penilaian universal yang tidak tergantung pada pengalaman evaluator. Bahkan jika tugas digantikan oleh yang bertanggung jawab - penilaiannya akan tetap tidak berubah, mengevaluasi tugas yang relatif baru relatif terhadap skala ini.

Mengganti jam tangan dengan poin abstrak

Jadi kami menghapus dari evaluator kebutuhan untuk mengevaluasi tugas dalam hitungan jam. Sebagai gantinya, ia mengevaluasinya dalam poin, jadi kami menghapus kontradiksi dalam persepsi evaluasi oleh pengembang dan manajer. Selain itu, sekarang gangguan dan keadaan force majeure tidak akan memengaruhi penilaian dengan cara apa pun, karena mereka tidak mengubah upaya yang diperlukan untuk menyelesaikan masalah!

Angka Fibonacci, T-shirt dan anjing

Ya, T-shirt dan anjing. Anda dapat menggunakan skala apa pun untuk mengevaluasi tugas. Yang paling umum adalah angka Fibonacci, ini adalah nilai numerik yang jelas dan juga dengan bonus yang bagus: elemen-elemen dari urutan ini mencerminkan dengan baik pertumbuhan ketidakpastian yang muncul dengan kompleksitas masalah yang diperkirakan.

Namun, beberapa tim menggunakan skala peringkat alternatif. Yang paling umum adalah penilaian pada T-shirt dan anjing, ketika kompleksitas tugas ditunjukkan dalam ukuran T-shirt (S, M, L, XL) atau pada jenis anjing (Chihuahua, Pug, Dog). Dengan demikian, tim bahkan lebih abstrak dari representasi numerik penilaian, yang dalam beberapa kasus bahkan merusak transfer ke penilaian sementara.

Skor tim

Apa perbedaan antara penilaian tim dan penilaian individu?
Mengapa penting melibatkan seluruh tim dalam penilaian?

Salah satu kesalahan terbesar yang dapat dilakukan ketika mengevaluasi tugas adalah membuatnya sendiri dan tidak meminta pendapat anggota tim. Mungkin mereka punya pendapat tentang ini? Ingin menambahkan dukungan browser baru? Apa yang QA pikirkan tentang ini?

Orang adalah sumber evaluasi yang paling penting. Mereka dapat melihat apa yang tidak Anda lihat.

Tetapi bagaimana cara melakukan penilaian tim? Hanya meneriakkan nilai tidak terlalu efektif, selain itu, setelah mendengar nilai Anda, anggota tim yang lain mungkin berubah pikiran dan tidak akan menyuarakan pendapatnya sendiri.

Perencanaan poker

Pada tahun 2002, James Granning menggambarkan metode yang kemudian menjadi sangat populer sehingga sekarang Anda bahkan dapat membeli setumpuk kartu nyata untuk perencanaan poker. Atau gunakan salah satu layanan online untuk sesi ini;

Inti dari metode ini adalah sebagai berikut: semua peserta tim diberikan kartu dengan angka dari skala penilaian. Kemudian tugas dipilih dan persyaratannya dibahas. Setelah diskusi, moderator meminta semua anggota tim untuk memilih kartu dan meletakkannya secara terbalik. Kemudian moderator memberikan sinyal untuk menunjukkan kartu.

Jika peringkat peserta konsisten, peringkat itu ditetapkan, jika tidak, kartu dikembalikan ke tangan, dan anggota tim terus mendiskusikan masalahnya. Merupakan ide yang bagus untuk bertanya kepada mereka yang memiliki nilai berbeda: "Kesulitan apa yang Anda lihat dalam tugas ini?" atau "Mengapa Anda berpikir bahwa selama implementasi tidak akan ada masalah?".

Perlu dicatat bahwa persetujuan tidak harus mutlak. Anda dapat menyetujui bahwa serangkaian peringkat tetangga juga dianggap sebagai persetujuan.

Alternatif

Seperti metode evaluasi itu sendiri, perencanaan poker memiliki alternatif. Saya akan berbicara singkat tentang salah satu dari mereka.

Anda dapat melewati blok ini dan langsung ke halaman berikutnya.

Peringkat affine

« . , . , . — . , , , .

, . , . .

, , .

, „“ .

Perencanaan proyek

Berapa jam yang ada di Story Point'e dan bagaimana cara membuat bagan Gantt?

Jadi, kami menghargai simpanan tugas kami, tetapi Anda tidak dapat membangun rencana proyek di Story Point'ah. Seringkali manajer proyek memiliki pertanyaan: "Bagaimana menerjemahkan SP ke dalam jam?".

Jawaban singkat untuk pertanyaan ini adalah: "Tidak mungkin."

Tentu saja, Anda dapat mengikuti pengembang dengan stopwatch dan mencatat waktu yang dibutuhkan untuk menyelesaikan masalah, dan kemudian menampilkan informasi ini dalam grafik. Kemudian Anda mendapatkan "bel" klasik, seperti pada contoh di blok di bawah ini. Seperti yang kita lihat pada gambar pertama, beberapa tugas membutuhkan waktu lebih sedikit, beberapa sedikit lebih sedikit, tetapi secara umum, seluruh nilai akan sesuai dengan beberapa distribusi normal.

Hal yang sama berlaku untuk tugas dalam 2 SP dan ini ditunjukkan pada gambar kedua. Pernahkah Anda memperhatikan bahwa "ekor" grafik berpotongan? Ya, beberapa tugas dengan peringkat 1 SP mungkin memerlukan lebih banyak upaya daripada tugas paling sederhana yang dinilai pada 2 SP. Pada akhirnya, belum ada tim yang belajar untuk mengevaluasi dengan sempurna. Selain itu, menerjemahkan SP ke dalam jam, kami kembali ke penggaruk lama, berapa lama waktu yang diperlukan pengembang untuk menyelesaikan masalah tertentu sangat bergantung pada pengembang.

Tetapi apa yang harus dilakukan, kita tidak dapat sepenuhnya meninggalkan perencanaan. Untungnya, untuk ini kita tidak perlu menerjemahkan setiap Story Point ke dalam jam. Yang paling penting adalah seberapa banyak SP yang bisa “ditutup” oleh tim pengembangan untuk sprint (iterasi, rilis).

Dengan mengumpulkan data tentang kecepatan tim, Anda bisa mendapatkan data yang cukup akurat untuk perencanaan proyek jangka panjang. Selain itu, jangan lupa tentang hukum angka besar, kesalahan estimasi saling dikompensasi, ini berlaku untuk kedua tugas dan iterasi. Perlu dicatat bahwa ini sedikit optimis, karena ketidakakuratan biasanya dikaitkan dengan perkiraan yang rendah dan bukan penilaian kembali. Tapi tidak ada yang sempurna.

Kecepatan (atau Kecepatan) adalah alat perencanaan yang kuat dan metrik utama dari tim pengembangan. Tim harus bekerja pada peningkatan berkelanjutan untuk meningkatkan kecepatan mereka. Jangan lupa bahwa kecepatan adalah turunan dari SP dan karenanya juga relatif. Anda tidak dapat membandingkan dua tim satu sama lain, tim bersaing dengan dirinya sendiri.

gambar

Praktek

Nuansa apa yang perlu Anda ketahui?
Kesalahan apa yang bisa dihindari?

Sebagai kesimpulan, saya ingin mengumpulkan beberapa tips untuk mereka yang pertama kali memutuskan untuk mencoba teknik yang dijelaskan dalam pekerjaan mereka.

Di mana untuk memulai

Ini adalah perencanaan poker pertama Anda dan tim tidak mengerti apa yang harus mengevaluasi tugas baru. Kumpulkan beberapa tugas yang sudah selesai, idealnya familier atau tipikal, dan evaluasi kompleksitasnya satu sama lain. Gunakan tugas-tugas ini untuk mengevaluasi yang baru.

Apakah Anda memiliki proyek baru dan tidak ada tugas yang selesai? Coba gunakan peringkat affine yang dijelaskan di atas dan tetapkan tugas ke skala peringkat.

Jangan peringkat rata-rata

Terkadang, ketika dua anggota tim telah mengevaluasi tugas secara berbeda, tergoda untuk menetapkan skor rata-rata untuk tugas tersebut dan melanjutkan. Jangan menyerah pada godaan ini, diskusi adalah elemen penting dari evaluasi, di mana tim dapat mengungkapkan fitur yang sebelumnya tidak diketahui dalam pelaksanaan tugas.

Tetapi, seperti yang disebutkan di atas, Anda selalu dapat menyetujui bahwa perkiraan yang dekat satu sama lain tidak akan menjadi alasan untuk diskusi lebih lanjut.

Jangan mengubah peringkat,

bahkan jika selama implementasi Anda menyadari bahwa Anda membuat kesalahan selama perencanaan, biarkan peringkat tidak berubah. Anda akan salah di masa depan, dan di kedua arah. Biarkan kesalahan-kesalahan ini saling mengimbangi, jangan mengganggu proses.

Peringkat bug

Saya menemukan berbagai pendekatan untuk mengevaluasi bug. Beberapa tim mengevaluasi semua bug kecuali yang muncul selama implementasi tugas baru dalam iterasi. Beberapa tidak mengevaluasi bug, membenarkan hal ini dengan fakta bahwa kecepatan tim harus menunjukkan nilai baru yang ditambahkan ke produk, dan memperbaiki bug seharusnya tidak mempengaruhi pertumbuhan indikator ini.

Apapun pendekatan yang Anda pilih, tetaplah konsisten. Informasi tentang kecepatan historis tim tidak boleh dipengaruhi oleh penggunaan berbagai pendekatan penilaian.

Nol peringkat

Pertanyaan lain yang tidak memiliki jawaban yang jelas. Seseorang percaya bahwa tidak ada tugas yang tidak membutuhkan usaha. Yang lain menjawab mereka bahwa memberikan poin ke tugas-tugas sederhana mengarah pada peningkatan yang tidak masuk akal pada grafik kecepatan tim.

Anda dapat memasukkan skor 1/2 poin untuk tugas-tugas tersebut dan memantau secara retrospektif apakah proporsi tugas-tugas tersebut melebihi batas yang wajar. Tapi saran utamanya sama, tetap konsisten dalam keputusan Anda.

Menilai kembali tugas yang belum selesai di antara iterasi

Tidak selalu mungkin untuk menyelesaikan tugas dalam satu iterasi, bahkan jika itu awalnya direncanakan. Namun demikian, Anda tidak boleh mengubah penilaiannya saat merencanakan iterasi berikutnya berdasarkan jumlah pekerjaan yang tersisa. Ingatlah hal ini saat merencanakan, tetapi biarkan perkiraannya tidak berubah untuk cerita tersebut.

Peringkat retrospektif

Jika Anda belum melakukan retrospektif - sekarang saatnya untuk memulai! Ini adalah alat tim yang hebat untuk meningkatkan kecepatan dan koherensi tim. Namun, ini masalah tersendiri.

Dalam perjalanan retrospektif Anda, periksalah perkiraan yang dibuat selama perencanaan iterasi dan diskusikan apakah ada penyimpangan besar antara harapan dan kenyataan.

Anda juga bisa mendapatkan beberapa masalah dari sejarah dengan peringkat yang sama dan mendiskusikan apakah semua cerita ini benar-benar membutuhkan upaya yang sama.

Catat semuanya.Jika

sistem manajemen tugas Anda tidak mendukung peringkat dan tidak secara otomatis menghitung kecepatan tim, maka Anda harus melakukannya secara manual. Seperti yang mungkin sudah Anda tebak, data historis adalah alat penting untuk meningkatkan nilai Anda.

Menilai Tugas di Poin Cerita