Story point sa pag-develop — ano ito, mga iskala ng pagtatasa at aplikasyon
Story point — ay mga relatibong yunit ng pagsukat ng pagiging kumplikado ng mga gawain sa mga maliksi na metodolohiya ng pag-develop. Hindi tulad ng mga oras, isinasaalang-alang ng story point hindi lamang ang oras, kundi pati na rin ang pagiging kumplikado, mga panganib at kawalan ng katiyakan ng gawain. Ayon sa Scrum.org, 2023, ang mga team na gumagamit ng relatibong pagtatasa sa story point ay 25% na mas madalas na hindi sumasablay sa mga deadline ng sprint kumpara sa mga team na nagtatasa sa oras.
Mga Pangunahing Punto
- Story point — mga relatibong yunit ng pagiging kumplikado ng gawain, hindi nakatali sa oras.
- Mga pangunahing iskala — Fibonacci (1, 2, 3, 5, 8, 13, 21) at linear (1, 2, 3, 4, 5).
- Velocity — bilang ng story point na natatapos ng team sa isang sprint, ginagamit para sa pagtataya.
- Pangunahing bentahe — ang story point ay hindi nakadepende sa partikular na developer at sumasalamin sa pagiging kumplikado para sa team.
- Pangunahing patakaran — ang gawaing sanggunian ay tumutukoy sa iskala: nagkakasundo ang team kung ano ang 1 story point.
Ano ang story point?
Story point — ay isang metrik ng pagiging kumplikado ng gawain na ginagamit sa Scrum at iba pang Agile na metodolohiya. Tinatasa ng team ang bawat gawain hindi sa oras, kundi sa mga relatibong yunit: “ang gawaing ito ay dalawang beses na mas kumplikado kaysa sa sanggunian”. Ang pamamaraang ito ay nagpapawalang-bisa sa pagkakaiba ng bilis ng iba't ibang developer at nakatuon sa pagiging kumplikado.
Pinagmulan ng termino
Ang konsepto ng story point ay lumitaw noong unang bahagi ng 2000s kasabay ng pagpapasikat ng Scrum. Isa sa mga unang naglarawan ng pamamaraan ay si Ron Jeffries sa loob ng Extreme Programming (XP). Ang ideya ay lumayo mula sa pagtatasa sa “oras-tao” na palaging hindi tumpak, tungo sa relatibong pagiging kumplikado na sama-samang tinutukoy ng team. Ngayon ang story point ay pamantayan ng industriya para sa mga Agile team.
Mga salik na isinasaalang-alang sa story point
Sa pagtatasa gamit ang story point, isinasaalang-alang ng team ang tatlong salik: dami ng trabaho (dami ng code, screen, lohika), pagiging kumplikado (mga teknikal na hamon, bagong teknolohiya) at kawalan ng katiyakan (hindi malinaw na mga kinakailangan, panganib). Ang isang story point ay maaaring mangahulugang “simpleng gawain na walang panganib”, at 8 — “komplikadong gawain na may mataas na kawalan ng katiyakan”.
Mga iskala ng story point: paano pumili
Ang pagpili ng iskala ng story point ay nakakaapekto sa katumpakan ng pagtatasa at kaginhawahan ng pagpaplano. Ang pinakasikat na iskala ay ang Fibonacci sequence, ngunit mayroon ding mga alternatibo.
| Iskala | Mga Halaga | Mga Bentahe | Mga Kahinaan |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Natural na pagtaas ng pagkalat sa malalaking gawain | Mahirap para sa mga bagong team |
| Linear | 1, 2, 3, 4, 5 | Simple at madaling maunawaan | Walang pagkalat para sa malalaking gawain |
| Eksponensyal | 1, 2, 4, 8, 16, 32 | Mataas na pagkalat para sa malalaking gawain | Mahirap pag-ibahin ang malalaking gawain |
| T-Shirt | S, M, L, XL | Mabilis na magaspang na pagtatasa | Hindi tumpak, nangangailangan ng conversion |
Bakit Fibonacci? Sikolohiya ng iskala
Ang Fibonacci sequence ay hindi pinili nang nagkataon. Ang pagkakaiba sa pagitan ng 1 at 2 ay minimal (50%), ngunit sa pagitan ng 13 at 21 — makabuluhan (62%). Ito ay sumasalamin sa katotohanan: ang maliliit na gawain ay tinatasa nang mas tumpak, ang malalaki — na may mas malaking pagkalat. Kapag ang isang gawain ay tinasa sa 21 story point, nauunawaan ng team: “hindi namin alam kung gaano ito katagal, ngunit tiyak na higit sa 13”. Pinipigilan ng iskala ng Fibonacci ang maling katumpakan.
Gawaing sanggunian — batayan ng iskala
Upang gumana ang iskala, nagkakasundo ang team tungkol sa sanggunian: “gawain X — 1 story point”. Karaniwan ang sanggunian ay isang simple at kilalang gawain: “magdagdag ng text field sa screen” o “ayusin ang bug na uri ng typo”. Ang lahat ng iba pang gawain ay tinatasa kaugnay ng sanggunian. Kung walang sanggunian, ang story point ay nawawalan ng saysay — bawat isa ay nauunawaan ang yunit nang magkakaiba.
Velocity ng team at pagtataya
Velocity (bilis ng team) — average na bilang ng story point na natatapos ng team sa isang sprint. Ito ang pangunahing metrik para sa pagtataya ng mga deadline ng proyekto.
Paano kinakalkula ang velocity
Velocity ay kinakalkula batay sa mga natapos na gawain: ang story point ng lahat ng gawain na natapos ng team (natupad ang definition of done) ay pinagsama-sama. Ang mga hindi natapos na gawain ay hindi isinasaalang-alang. Para sa katumpakan, kinukuha ang average ng huling 3-5 sprint. Halimbawa, kung natapos ng team ang 20, 22, 18 at 24 story point sa huling 4 na sprint, velocity = 21 sp.
Pagtataya sa pamamagitan ng velocity
Sa pamamagitan ng pag-alam ng velocity at kabuuang dami ng backlog sa story point, maaaring mataya ang bilang ng sprint hanggang sa release. Halimbawa, kung may 210 story point sa backlog at velocity = 21, kailangan ng 10 sprint. Ito ay isang magaspang na pagtataya na pino- refine habang nagtatrabaho. Mahalaga: ang velocity ay average, hindi obligasyon. Magplano ayon sa mababang hangganan (18 sp), hindi average.
Paano pataasin ang velocity
Velocity ay hindi maaaring dagdagan sa pamamagitan ng utos — ito ay sintomas ng kalusugan ng mga proseso. Ang matatag na pagtaas ng velocity ay nakakamit sa pamamagitan ng: pagbawas ng teknikal na utang, pagpapabuti ng mga proseso ng code review, pagbawas ng paglipat ng konteksto, automation ng pagsubok at CI/CD. Mahalaga: ang velocity ng iba't ibang team ay hindi maihahambing — bawat team ay tumutukoy ng story point sa sarili nitong paraan.
Story point vs oras: ano at kailan gagamitin
Ang story point at oras ay may magkaibang layunin, at ang pagpili sa pagitan ng mga ito ay nakadepende sa konteksto. Ang mga may karanasang team ay gumagamit ng parehong pamamaraan para sa iba't ibang gawain.
Kailan mas gumagana ang story point
Story point ay mahalaga para sa pagpaplano ng sprint: hindi sila nakadepende kung sino ang gagawa ng gawain. Ang junior ay maaaring gumawa ng 2 sp bawat araw, senior — 4 sp, ngunit ang pagtatasa ng gawain ay nananatiling 2 sp para sa pareho. Pinapayagan ng story point ang pagsubaybay ng produktibidad ng team nang hindi inihahambing ang mga developer. Ito ay nagbabawas ng politikal na presyon at nagpapabuti ng kapaligiran ng team.
Kailan kailangan ang oras
Oras ay kinakailangan para sa panlabas na obligasyon: kontrata, tantiya, ulat para sa kliyente. Gusto ng kliyente na malaman hindi “8 story point”, kundi “3 linggo”. Para sa conversion ng story point sa oras, ginagamit ang historical conversion rate: alam ng team na ang 1 sp = humigit-kumulang 4 na oras ng trabaho. Ang conversion ay dapat na transparent at batay sa datos, hindi sa mga palagay.
Pinagsamang pamamaraan
Maraming team ang gumagamit ng pinagsamang pamamaraan: ang mga gawain ay tinatasa sa story point para sa pagpaplano ng sprint, pagkatapos ay kino-convert ng manager ang mga ito sa oras/araw para sa panlabas na pag-uulat. Mahalagang huwag paghaluin ang dalawang sistema sa isang proseso: alinman sa tinatasa mo sa story point at kukunin ang oras mula sa velocity, o direktang tinatasa sa oras.
Mga karaniwang pagkakamali sa paggawa gamit ang story point
Ang pagpapatupad ng story point ay madalas na sinasamahan ng mga pagkakamali na nagpapawalang-bisa sa mga bentahe ng relatibong pagtatasa. Narito ang mga pinakakaraniwan.
Pagkakatali ng story point sa oras
Pinakakaraniwang pagkakamali — nagkakasundo ang team: “1 sp = 4 na oras”. Sa kasong ito, nawawalan ng saysay ang story point at nagiging oras sa ilalim ng ibang pangalan. Ang story point ay dapat na relatibo, hindi nakatali sa oras. Kung ang gawain A ay dalawang beses na mas kumplikado kaysa gawain B, ito ay makakakuha ng 2 sp, kahit gaano karaming oras ang kailanganin.
Pagtatasa post-factum
Kapag ang isang gawain ay tinatasa pagkatapos nitong makumpleto — ito ay hindi pagtatasa, kundi pagpapatunay ng katotohanan. Ang story point ay dapat italaga bago magsimula ang trabaho, sa sandali ng pinakamataas na kawalan ng katiyakan. Pinapangit ng pagtatasa post-factum ang velocity at hindi nagbibigay ng pakinabang para sa pagpaplano. Higit pa rito, lumilikha ito ng maling pakiramdam ng katumpakan.
Paghahambing ng velocity ng iba't ibang team
Paghahambing ng velocity ng team A at team B — walang saysay na ehersisyo. Bawat team ay tumutukoy ng sanggunian at iskala sa sarili nitong paraan. Para sa isang team, ang 1 sp ay simpleng isang oras na gawain, para sa iba — isang araw na gawain. Tanging ang velocity ng parehong team sa dinamika ang maihahambing: tumataas o bumababa ito.
Hindi pare-parehong iskala
Kapag ang magkaibang gawain na may parehong pagiging kumplikado ay tumatanggap ng magkaibang story point, at ang mas kumplikado — mas kaunti, nasisira ang iskala. Dapat na regular na i-calibrate ng team ang iskala: tuwing 3-6 sprint suriin nang retrospektibo kung gaano katugma ang mga pagtatasa sa tunay na pagiging kumplikado. Ito ay nagpapabuti ng pagkakapare-pareho ng mga pagtatasa.
Mga Madalas Itanong
Ilang oras sa isang story point?
Ang story point ay walang nakapirming katumbas sa oras. Ito ay relatibong yunit: 1 sp = pagiging kumplikado ng gawaing sanggunian. Para sa conversion sa oras, gamitin ang historical conversion rate ng inyong team: hatiin ang average na bilang ng mga oras na nagtrabaho sa isang sprint sa velocity. Karaniwan ang 1 sp = 4-8 na oras, ngunit ito ay indibidwal para sa bawat team.
Maaari bang gamitin ang story point sa Kanban?
Oo, ang story point ay maaaring gamitin sa Kanban, ngunit may mga kondisyon. Sa Kanban walang nakapirming sprint, kaya ang velocity ay kinakalkula hindi bawat sprint, kundi bawat linggo o buwan. Ang mga Kanban team ay madalas na gumagamit sa halip ng story point ng Cycle Time — oras ng pagdaan ng gawain mula simula hanggang katapusan. Ang pagpili ay nakadepende sa espesipiko ng team.
Ano ang gagawin kung hindi magkasundo ang team sa pagtatasa?
Kung ang mga pagtatasa ay magkaiba (ang isa ay nagbibigay ng 3 sp, ang isa naman ay 13), ito ay senyales na ang gawain ay hindi lubos na nauunawaan. I-decompose ang gawain sa mas maliliit na bahagi. Talakayin ang mga panganib at kawalan ng katiyakan na nakikita ng iba't ibang developer. Kung malaki ang gawain — tasahin ito bilang Spike (pagsasaliksik ng 2-4 na araw) sa halip ng story point.
Paano huminto sa pagtatasa sa oras at lumipat sa story point?
Ang paglipat ay tumatagal ng 3-6 sprint. Magsimula sa pagpili ng iskala (Fibonacci — safest choice) at pagtukoy ng gawaing sanggunian. Magsagawa ng 2-3 sesyon ng Planning Poker. Pagkatapos ng bawat sprint, kalkulahin ang velocity. Huwag i-convert ang story point sa oras — hayaan ang team na masanay sa bagong sistema. Pagkatapos ng 3 sprint, makikita mo kung gaano bumuti ang pagpaplano.
Nagbabago ba ang pagtatasa ng gawain sa story point pagkatapos makumpleto?
Hindi, ang pagtatasa ay hindi nagbabago. Ang story point ay paunang pagtatasa ng pagiging kumplikado na ginawa bago magsimula ang trabaho. Pagkatapos makumpleto ang gawain, ang pagtatasa ay nananatiling pareho, kahit na ang aktwal na pagsisikap ay naiiba. Ang pagbabago ng pagtatasa post-factum ay pumipihit ng estadistika at ginagawang walang saysay ang pagtataya. Suriin ang mga pagkakaiba sa retrospektibo, ngunit huwag baguhin ang pagtatasa pagkatapos ng pangyayari.
Buod
- Story point — mga relatibong yunit ng pagiging kumplikado, hindi nakatali sa oras, batayan ng pagtatasa ng Agile.
- Mga pangunahing iskala — Fibonacci (inirerekomenda), linear, eksponensyal, T-Shirt sizing.
- Velocity — bilang ng story point bawat sprint; pangunahing metrik para sa pagtataya ng deadline.
- Story point vs oras — story point para sa pagpaplano ng sprint, oras para sa panlabas na obligasyon.
- Mga karaniwang pagkakamali — pagkakatali sa oras, pagtatasa post-factum, paghahambing ng team, hindi pare-parehong iskala.
- Gawaing sanggunian — batayan ng iskala; kung wala ito, nawawalan ng saysay ang story point.
- Pangunahing bentahe — ang story point ay hindi nakadepende sa gumaganap at nagpapahintulot ng pokus sa produktibidad ng team.
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din