Story Point: Cara Menganggar Kerja Agile (Dengan Contoh)

Story point mengelirukan hampir setiap pasukan pada kali pertama mereka menggunakannya. Ia bukan jam. Ia bukan hari. Namun pasukan menggunakannya untuk meramal penghantaran, merancang sprint, dan menentukan sama ada sesuatu ciri akan dilancarkan suku tahun ini atau suku tahun depan.

Jika anda seorang pengurus atau pengarah yang cuba membawa kebolehramalan kepada aliran kerja agile, memahami story point adalah satu keperluan. Panduan ini menerangkan apa itu story point, mengapa ia berkesan, cara menjalankan sesi anggaran, dan perkara yang perlu dielakkan.

Apakah itu story point?

Story point ialah unit relatif yang digunakan untuk mengukur keseluruhan usaha yang diperlukan untuk melaksanakan sesuatu kerja. "Usaha" di sini merangkumi tiga dimensi: kerumitan (sejauh mana sukarnya kerja ini?), saiz (berapa banyak kerja yang terlibat?), dan ketidakpastian (berapa banyak yang masih belum kita ketahui?).

Kata kunci di sini ialah relatif. Sesuatu story yang bernilai 3 mata bukan bermaksud "3 jam kerja." Ia bermaksud pasukan percaya kerja tersebut memerlukan kira-kira tiga kali lebih usaha berbanding story 1 mata, dan kira-kira separuh usaha berbanding story 8 mata. Nombor itu adalah perbandingan, bukan ukuran.

Perbezaan ini penting. Manusia terkenal lemah dalam menganggar tempoh masa mutlak ("ini akan mengambil masa 4 jam") tetapi agak baik dalam membuat perbandingan relatif ("tugas ini kira-kira dua kali lebih sukar daripada yang itu"). Story point memanfaatkan kelebihan kognitif ini.

Fakta Utama: Story Point dan Anggaran Agile

• Pasukan yang menggunakan anggaran relatif (story point atau kaedah serupa) melaporkan penghantaran sprint yang lebih konsisten berbanding pasukan yang menganggar dalam jam, menurut kajian Scrum.org mengenai kebolehramalan sprint.
• Laporan State of Agile ke-17 (digital.ai, 2023) mendapati 88% pengamal agile menggunakan Scrum atau hibrid Scrum, menjadikan anggaran story point hampir universal dalam industri ini.
• Menurut siri Laporan CHAOS oleh Standish Group, anggaran yang tidak tepat dan keperluan yang tidak jelas sentiasa menjadi antara tiga punca utama projek melebihi anggaran, menegaskan mengapa kaedah anggaran berstruktur seperti story point amat penting.
• Satu cara memahami konsep ini: "Story point mengukur usaha pasukan, bukan kalendar. Ciri yang sama mungkin bernilai 5 mata untuk pasukan kanan dan 13 mata untuk pasukan junior, dan kedua-dua jawapan itu betul mengikut konteks masing-masing."

Story point vs jam

Pasukan yang baru menggunakan agile sering bertanya mengapa mereka tidak boleh terus menganggar dalam jam. Berikut ialah perbandingan yang jujur:

Jam kelihatan tepat tetapi sebenarnya tidak. Apabila seorang pembangun berkata "itu empat jam," sebenarnya mereka bermaksud "jika tiada apa-apa yang salah, jika saya tidak diganggu, jika saya sudah biasa dengan kod tersebut, dan jika keperluan tidak berubah." Story point mengakui kewujudan ketidakjelasan, bukannya menyembunyikannya.

Namun begitu, jam masih ada tempatnya. Kontrak harga tetap, audit pematuhan, dan pengebilan pelanggan semuanya memerlukan anggaran berasaskan masa. Kuncinya ialah mengetahui alat mana yang sesuai untuk konteks yang mana.

Mengapa pasukan menggunakan story point (kelebihan)

Sesi anggaran yang lebih pantas. Berdebat sama ada sesuatu itu 6 atau 8 jam amat menyusahkan. Berdebat sama ada ia 5 atau 8 (pada skala Fibonacci) jauh lebih pantas kerana jurang antara nilai-nilai itu sengaja dibuat besar.

Pemilikan bersama terhadap anggaran. Apabila seluruh pasukan menyukat kerja bersama-sama, semua orang memahami skopnya. Pembangun dapat mengesan butiran pelaksanaan yang mungkin terlepas pandang oleh pemilik produk. Pasukan QA dapat mengenal pasti kes tepi lebih awal. Anggaran itu menjadi satu kontrak yang dibuat oleh pasukan dengan dirinya sendiri.

Velocity sebagai alat ramalan. Sebaik sahaja pasukan menyelesaikan beberapa sprint, purata velocity mereka (jumlah story point yang diselesaikan setiap sprint) menjadi peramal yang boleh dipercayai. Jika pasukan anda mencapai purata 40 mata setiap sprint, backlog sebanyak 200 mata akan mengambil masa kira-kira lima sprint untuk disiapkan. Itulah roadmap anda.

Mengurangkan kesan jangkar. Apabila seorang jurutera kanan berkata "ini kerja dua hari" sebelum sesi anggaran bermula, semua orang lain akan menyesuaikan diri ke arah nombor itu. Story point, terutamanya apabila didedahkan secara serentak dalam planning poker, menghalang satu suara daripada mendominasi.

Perbualan yang lebih baik, bukan sekadar nombor. Apabila dua orang memilih nilai mata yang berbeza, percanggahan itu mendedahkan kerumitan yang tersembunyi. Bahagian paling bernilai dalam anggaran bukanlah nombor yang akhirnya dipilih, tetapi perbualan yang membawa pasukan ke situ.

Kesilapan biasa dan batasan

Menganggap mata sebagai jam. Ini ialah mod kegagalan yang paling biasa. Sebaik sahaja seorang pengurus bertanya "jadi 1 mata bersamaan berapa jam?", keseluruhan sistem mula runtuh. Mata bukan unit masa.

Membandingkan velocity antara pasukan. Pasukan A mencapai purata 50 mata setiap sprint dan Pasukan B mencapai 30 mata. Itu tidak bermaksud Pasukan A lebih pantas. Pasukan yang berbeza menentukur skala mereka secara berbeza. Membandingkan velocity merentas pasukan adalah seperti membandingkan harga dalam mata wang berbeza tanpa mengetahui kadar pertukarannya.

Menambah anggaran demi perlindungan diri. Apabila pasukan menyedari bahawa anggaran yang meleset membawa kepada tuduhan, mereka mula menambah anggaran. Story 3 mata menjadi 5 mata "untuk berjaga-jaga." Ini menggelembungkan velocity dan merosakkan ketepatan ramalan dari semasa ke semasa. Budaya yang selamat untuk gagal menghasilkan anggaran yang lebih baik.

Berpegang kepada skala sprint sebelumnya. Pasukan berubah dari semasa ke semasa. Apa yang dahulunya story 3 mata mungkin kini sebenarnya 5 mata kerana pangkalan kod telah berkembang. Penentukuran semula secara berkala mengekalkan kejujuran skala tersebut.

Menggunakan mata untuk mengukur produktiviti individu. Story point adalah kepunyaan pasukan. Menjejaki berapa banyak mata yang "dihasilkan" oleh setiap pembangun mengubah alat ramalan menjadi metrik prestasi, dan ini merosakkan kedua-duanya.

Menganggar dengan terlalu terperinci pada peringkat terlalu awal. Story yang dijadualkan untuk suku tahun akan datang tidak memerlukan ketepatan 3 mata. Penyaizan T-shirt yang kasar (S/M/L/XL) sudah memadai sehingga sesuatu story hampir dipilih dalam satu atau dua sprint akan datang.

Cara menganggar dengan story point (langkah demi langkah)

Langkah 1: Sepakati story rujukan anda

Sebelum sesi anggaran pertama anda, pilih satu story sebenar yang difahami oleh seluruh pasukan. Ini menjadi garis dasar anda. Berikan story itu 3 mata (atau apa sahaja yang dirasakan seperti usaha sederhana). Setiap story akan datang dianggarkan secara relatif berbanding story ini.

Garis dasar yang baik ialah sesuatu yang melibatkan ketiga-tiga dimensi anggaran pada tahap sederhana: sedikit kerumitan, jumlah kod yang munasabah untuk ditulis, dan sedikit (tetapi tidak keterlaluan) ketidakpastian.

Langkah 2: Gunakan turutan Fibonacci

Skala story point yang paling biasa ialah turutan Fibonacci yang diubah suai: 1, 2, 3, 5, 8, 13, 21. Sesetengah pasukan menambah 0 (remeh), 40, dan 100 untuk kerja peringkat epik.

Mengapa Fibonacci? Kerana jurang antara nilai-nilai bertambah besar apabila nombor meningkat. Story 5 mata dan story 8 mata terasa berbeza secara ketara. Story 5 mata dan 6 mata mungkin tidak. Skala ini memaksa pasukan membuat perbezaan yang sebenar tanpa berpura-pura memiliki ketepatan yang tidak wujud.

Story yang dianggarkan pada 13 atau lebih tinggi merupakan calon kuat untuk dipecahkan. Anggaran yang besar biasanya menandakan skopnya belum difahami dengan baik.

Langkah 3: Jalankan sesi planning poker

Planning poker ialah teknik standard untuk anggaran secara kolaboratif:

1. Pemilik produk membacakan user story dengan kuat dan menjawab soalan penjelasan.
2. Setiap ahli pasukan memilih kad mata secara sulit (atau nombor dalam alat digital).
3. Semua orang mendedahkan anggaran mereka secara serentak.
4. Jika anggaran berbeza lebih daripada satu langkah (contohnya, seorang memilih 3, seorang lagi memilih 13), pihak yang menyimpang menerangkan sebab mereka.
5. Pasukan berbincang, kemudian menganggar semula sehingga mencapai kata sepakat.

Pendedahan serentak adalah kritikal. Ia menghalang kesan jangkar dan memastikan setiap suara didengar sebelum kata sepakat terbentuk.

Langkah 4: Tentukur melalui velocity

Selepas beberapa sprint pertama anda, kira velocity pasukan anda: jumlah story point yang diselesaikan dalam satu sprint. Jangan kira story yang dibawa dari sprint sebelumnya sebagai "selesai."

Selepas 4-6 sprint, anda akan mempunyai julat velocity yang boleh dipercayai. Gunakan hujung bawah julat itu untuk ramalan yang berhati-hati, dan purata untuk perancangan biasa.

Velocity akan menyesuaikan diri secara semula jadi apabila kemahiran pasukan, kebiasaan dengan pangkalan kod, dan tabiat anggaran semakin matang. Jangan cuba menggelembungkannya dengan memanipulasi anggaran.

Langkah 5: Tentukur semula secara berkala

Sekurang-kurangnya sekali setiap suku tahun, semak semula story rujukan anda. Adakah pemahaman pasukan tentang "usaha sederhana" telah berubah? Jika ya, laraskan. Matlamatnya ialah konsistensi dalam pasukan dari semasa ke semasa, bukan konsistensi dengan sebarang piawaian luaran.

Contoh story point

Berikut ialah cara sebuah pasukan agile mungkin menganggar beberapa item backlog untuk sebuah produk SaaS B2B, berserta sebab dan bagaimana velocity mereka berkembang.

Jika pasukan ini menyelesaikan story 1, 2, 3, 5, dan 8 mata dalam Sprint 1, velocity mereka ialah 19 mata. Selepas beberapa sprint, andaikan purata velocity mereka stabil pada 22 mata. Backlog sebanyak 110 story point memberikan mereka ramalan 5 sprint, atau kira-kira 10 minggu pada sprint dua minggu.

Story gerbang pembayaran 13 mata itu merupakan calon untuk dipecahkan. "Kaji pilihan penyedia pembayaran dan dokumenkan pendekatan integrasi" mungkin bernilai 5, dan "laksana dan uji integrasi" bernilai 8 atau 13. Pemecahan ini menjadikan kemajuan lebih jelas dan mengurangkan risiko sprint.

Amalan terbaik

Lakukan:

• Sukat story sebagai pasukan, bukan secara individu
• Pecahkan mana-mana story melebihi 13 mata sebelum menjadualkannya ke dalam sprint
• Jejaki velocity mengikut tetingkap bergerak 4-6 sprint, bukan sprint tunggal
• Pastikan story garis dasar mudah diakses semasa sesi anggaran
• Biarkan pembangun memiliki anggaran; pemilik produk memiliki keutamaan
• Gunakan user story sebagai unit anggaran utama anda supaya skop berasaskan nilai pengguna

Jangan:

• Tukar mata kepada jam dalam sebarang komunikasi rasmi
• Bandingkan velocity antara pasukan atau gunakannya sebagai isyarat pengambilan pekerja atau prestasi
• Biarkan satu suara mendominasi anggaran sebelum kad didedahkan
• Buka semula anggaran di tengah-tengah sprint untuk menampung perluasan skop; catatkan sebagai story baharu sebaliknya
• Langkau anggaran untuk story "ringkas"; perbualan 10 minit dapat mengelakkan kejutan 2 hari

Satu catatan mengenai perancangan sprint: anggaran story point adalah input utama untuk menentukan berapa banyak kerja yang perlu ditarik masuk ke dalam sprint. Terlebih komited sebanyak 20% adalah perkara biasa bagi pasukan baharu. Apabila velocity stabil, ketepatan perancangan bertambah baik dengan ketara.

Soalan lazim

Mengapa gunakan nombor Fibonacci berbanding 1, 2, 3, 4, 5?

Turutan Fibonacci mempunyai jurang yang semakin membesar antara nilai-nilai (1, 2, 3, 5, 8, 13...) manakala skala linear tidak. Apabila anda menganggar story 5 mata berbanding story 6 mata, anda mungkin sekadar berbalah tentang perkara remeh. Dengan Fibonacci, lonjakan daripada 5 kepada 8 memaksa perbualan yang sebenar: adakah story ini mempunyai kerumitan tambahan yang mencukupi untuk mewajarkan nombor yang lebih besar? Geseran itu menghasilkan keputusan yang lebih baik.

Berapa jamkah satu story point?

Tiadanya. Story point sengaja tidak dipetakan kepada jam. Jika velocity pasukan anda ialah 20 mata setiap sprint 2 minggu dan anda bekerja 80 jam-pasukan setiap sprint, anda boleh membahagi dan mendapat 4 jam setiap mata, tetapi pengiraan itu akan runtuh serta-merta apabila saiz pasukan berubah, kerumitan berbeza, atau anda mempunyai sprint dengan gangguan yang luar biasa tinggi atau rendah. Gunakan velocity untuk ramalan masa, bukan pengiraan jam setiap mata.

Story point vs penyaizan T-shirt (S/M/L/XL)?

Penyaizan T-shirt ialah kaedah anggaran relatif yang lebih pantas dan kurang tepat, sering digunakan untuk perancangan peringkat roadmap. Ia sesuai untuk ciri yang masih tiga suku tahun atau lebih jauh lagi. Story point lebih sesuai untuk kerja peringkat sprint kerana ia menyokong pengiraan velocity. Ramai pasukan menggunakan kedua-duanya: saiz T-shirt untuk penghalusan backlog pada peringkat roadmap, kemudian menukar kepada mata apabila sesuatu ciri hampir dibangunkan dalam satu atau dua sprint.

Bolehkah story point digunakan di luar pembangunan perisian?

Ya. Pasukan pemasaran, pasukan kandungan, dan pasukan operasi semuanya menggunakan story point atau teknik anggaran relatif yang serupa. Skala Fibonacci dan planning poker berfungsi untuk sebarang kerja yang melibatkan kerumitan dan ketidakpastian, bukan hanya kod. Penentukuran hanya mengambil masa lebih lama dalam bidang tanpa garis dasar yang sedia ada.

Apa yang berlaku apabila sesuatu story mengambil masa lebih lama daripada yang dianggarkan?

Tiada apa-apa, secara ideal. Anggaran adalah ramalan, bukan komitmen. Apabila story 3 mata mengambil masa dua kali ganda daripada yang dijangka, tindak balas yang betul ialah perbualan pasukan: adakah anggaran itu salah, atau adakah skop berubah? Kemudian kemas kini prosesnya, bukan orangnya. Anggaran yang sentiasa terlalu rendah dalam sesuatu kategori (misalnya, semua story integrasi API mengambil masa lebih lama) merupakan isyarat untuk melaraskan skala anda atau memecahkan story tersebut dengan lebih agresif.

Ke mana harus anda pergi seterusnya

Story point hanyalah satu lapisan daripada sistem anggaran dan perancangan agile yang lebih luas. Sebaik sahaja pasukan anda mempunyai velocity yang stabil, gandingkan anggaran story point dengan perancangan sprint untuk menetapkan matlamat sprint yang realistik dan dengan carta burndown untuk menjejaki kemajuan secara masa nyata.

Jika pasukan anda baru bermula dengan agile, manifesto agile dan apakah itu metodologi agile memberikan konteks berguna mengenai kenapa anggaran relatif ini wujud pada asalnya. Bagi pasukan yang sudah menjalankan sprint, retrospektif sprint ialah mekanisme untuk meningkatkan ketepatan anggaran anda dari semasa ke semasa.

Bacaan berkaitan

• Apakah itu Scrum
• Planning Poker: Cara Menjalankan Sesi Anggaran
• User Story: Cara Menulisnya Dengan Baik
• Panduan Perancangan Sprint
• Carta Burndown: Membaca dan Menggunakannya
• Scrum vs Kanban