"We're Agile" ay naging isang respetadong paraan upang tumanggi sa isang petsa. Kailangan pa rin ng programme boards na malaman kung ano ang maaaring ma-ship at hindi bago ang susunod na regulatory window, product launch o capital commit. Tinatanong pa rin ang transformation sponsors para sa mga commitment sa wika na naiintindihan ng mga executive. Ang tapat na galaw ay hindi ang mag-imbento ng isang solong ship date na may tahimik na contingency. Ito ay ang ipalit ang maling katiyakan sa isang malinaw na posibilidad: feature X sa petsa Y na may humigit-kumulang 87 porsyento na kumpiyansa, batay sa kung paano talagang natatapos ng team ang trabaho.
Ang mga organisasyon na sinanay sa Waterfall ay madalas na naririnig ang Agile bilang pahintulot na tumigil sa pag-commit. Ang interpretasyong iyon ay maginhawa at mali. Binabago ng Agile ang unit ng pagpaplano, ang haba ng feedback loop at ang katapatan ng forecast. Hindi nito inaalis ang pangangailangan para sa isang priyorisadong listahan ng mga outcome o para sa isang mapagtatanggol na sagot sa "kailan".
Ano talagang binabago ng Agile (at ano ang hindi)
Ang nagbabago ay ang anyo ng pangako. Itinigil mo ang pagyeyelo sa isang labindalawang buwang work breakdown na nagpapanggap na naalis na ang kawalan ng katiyakan. Nagsisimula kang magtrabaho sa isang ranked backlog. Nag-ship ka ng mga increment nang madalas upang ang product at business ay makapag-steer. Inu-update mo ang forecast habang dumarating ang delivery data.
Ang hindi nagbabago ay ang pananagutan. Mayroon pa ring may-ari ng outcome. Mayroon pa ring nagdedesisyon kung ano ang nasa loob at labas ng scope kapag bumababa ang probabilidad na matumbok ang isang petsa. Naninirahan pa rin sa mga kalendaryo ang mga regulator, board at counterparties. Ang pagtawag sa programa bilang Agile ay hindi ginagawang opsyonal ang mga kalendaryong iyon.
Ang failure mode sa mga bangko at insurance company ay mahuhulaan. Tinatanggap ng leadership ang mga pangalan ng ceremony, pinapanatili ang waterfall governance calendars at pagkatapos ay itinuturing na anti-Agile ang anumang kahilingan para sa petsa. Pinoprotektahan ng delivery teams ang kanilang sarili gamit ang "it depends". Pinupunan ng mga sponsor ang bakante gamit ang Gantt theatre: isang diamond milestone, isang berdeng bar at isang risk register na walang naniniwala. Walang nagsisinungaling sa dramatikong kahulugan. Lahat ay gumagamit ng isang planning language na hindi makapagpahayag ng kawalan ng katiyakan nang hindi mukhang incompetent.
Ang minimum operating system
Tatlong bagay ang hindi mapag-uusapan.
Una, isang priyorisadong listahan ng mga outcome at ang trabahong nagpapatupad sa mga ito. Kung lahat ay P1, wala talagang P1. Ang priority ay isang desisyon ng product at business, hindi isang negosasyon sa pagitan ng mga squad tungkol sa kung sino ang mas malakas ang ticket.
Pangalawa, product at business feedback sa bawat sprint (o katumbas na maikling cadence). Ang mga forecast na walang steering ay nananatiling theatre. Kung ang mga taong makakapag-cut ng scope o makakapagbago ng acceptance criteria ay lumilitaw lamang sa PI boundaries, masusunog mo ang mga sprint sa maling trabaho at pagkatapos ay sisihin ang forecast.
Pangatlo, ipahayag ang posibilidad ayon sa petsa. Ang "We'll do our best" ay hindi isang forecast. Ang "Tapos sa Huwebes na may humigit-kumulang 87 porsyento na kumpiyansa, batay sa kasalukuyang scope at historical throughput" ay isang forecast na maaaring pamahalaan ng isang tao. Ibaba ang kumpiyansa at madalas mong maaaring ilapit ang petsa o palakihin ang scope. Itaas ang kumpiyansa at karaniwang kailangan mo ng mas maraming oras, mas kaunting scope o mas maraming kapasidad. Iyon ay isang management conversation, hindi isang relihiyon.
Mula sa initiative hanggang sa executable work
Ang malalaking programa ay nangangailangan pa rin ng isang coarse planning horizon. Kapaki-pakinabang ang PI planning o big-room planning kapag gumagawa ito ng isang ranked set ng mga outcome para sa humigit-kumulang susunod na tatlong buwan, na may T-shirt sizing na sapat upang maglaan ng kapasidad at maipakita ang mga dependency. Hindi ito kapaki-pakinabang kapag nagyeyelo ito ng isang pseudo-waterfall plan na nakadamit sa Agile vocabulary.
Pagkatapos ng coarse pull, inihahanda ng mga team ang near-term work sa mga story, inilalapat ang story points (o iba pang pare-parehong relative size) at isinasagawa sa mga sprint. Ang predicted kumpara sa actual ay nagiging raw material ng forecasting. Ang punto ng story points sa modelong ito ay hindi mystical precision. Ito ay isang matatag na relative scale upang ang "natapos namin ang 34 points noong nakaraang sprint" ay may kahulugan na maihahambing sa sprint bago nito, basta't may hygiene.
Panatilihing konektado ang coarse plan at ang fine plan. Ang mga outcome na nanalo sa PI slots ay dapat maging backlog items na may mga may-ari. Ang mga dependency na binanggit sa kwarto ay dapat maging tracked constraints, hindi slideware. Kapag nag-diverge ang predicted at actual, ayusin muna ang scope o sequence. Huwag tahimik na baguhin ang kasaysayan upang manatiling berde ang Gantt.
Pagbuo ng teams kumpara sa pag-forecast ng teams
Ang Tuckman ay hindi isang branding exercise. Ang mga team na nasa forming at storming ay wala pa ring stable delivery signal. Nagsisimula nang magkaroon ang norming teams. Ang mga performing team na may ilang buwan ng malinis na throughput (o points na natapos bawat sprint) ay makakapagtanggol ng isang probability statement.
Huwag ibenta ang Bayesian theatre sa unang buwan. Ang isang bagong squad na may rotating membership, hindi malinaw na Definition of Done at isang backlog na patuloy na ginagawa ay maglalabas ng mga numero na mukhang siyentipiko ngunit kaunti ang kahulugan. Itatag muna ang operating system: priority, feedback at consistent completion accounting. Pagkatapos ay mag-forecast.
Ang mga established team ay ibang usapin. Kapag mayroon ka nang run ng katulad na laki ng trabaho na natatapos sa ilalim ng katulad na mga constraint, ang historical throughput ay isang lehitimong prior. Ang Monte Carlo sampling mula sa kasaysayang iyon ay sumasagot sa "kailan" at "magkano" nang mas mahusay kaysa sa isang solong velocity average. Opsyonal na Bayesian updates ay makakapagpaliit ng larawan habang dumarating ang mga bagong sprint, ngunit pagkatapos lamang na tapat ang base data. Hanggang doon, ituring ang mga early forecast bilang directional at sabihin ito.
Pagkuha ng data sa mga team
Kunin kung ano ang natapos, kung kailan ito natapos at sa anong laki (kung gumagamit ka ng points). Kunin ang start at finish dates para sa cycle-time views kung interesado ka sa flow. Kunin ang blocked time at dependency wait kung ang cross-team friction ang totoong kwento. Ang hygiene ay mas mahalaga kaysa sa tooling. Isang spreadsheet na may tapat na done dates ay mas mahusay kaysa sa isang Jira estate na puno ng tickets na inilipat sa Done sa huling araw ng sprint upang protektahan ang velocity optics.
Sumang-ayon kung ano ang ibig sabihin ng "done" at huwag ilipat ang finish line upang mapaganda ang chart. Panatilihing humigit-kumulang maihahambing ang mga laki ng work item o hatiin ang mga outlier. Iwasan ang paglalaro ng points. Ang tooling ay pangalawa: ActionableAgile-style analytics, native Jira charts o isang maikling Python notebook ay lahat gumagana kapag mayroon nang history. Maglaan ng humigit-kumulang isa hanggang dalawang buwan ng malinis na execution bago mo ituring ang forecast bilang board-grade. Hindi iyon pagkaantala para sa sarili nitong kapakanan. Ito ang minimum upang ang sample ay tumigil na maging ingay.
Data-driven forecasting: Monte Carlo (at Bayesian) nang walang mistisismo
Ang Monte Carlo forecasting, sa anyong pinasikat para sa Agile delivery ng mga practitioner tulad ni Daniel Vacanti at ng Actionable Agile tradition, ay hindi mistisismo. Kinukuha mo ang historical throughput (mga item o points na natapos bawat araw o bawat sprint), nag-sample mula sa kasaysayang iyon nang libu-libong beses at tinatanong kung gaano kadalas matatapos ang natitirang trabaho sa isang target na petsa. Ang output ay isang distribution, hindi isang propesiya.
Isang maikling intuition sketch:
# remaining = work still to finish (items or points)
# history = list of past throughputs per period (sprint/day)
# target = number of periods until the date you care about
trials_done = 0
for trial in 1..N: # e.g. N = 10_000
remaining_sim = remaining
for period in 1..target:
remaining_sim -= sample(history) # draw one past throughput
if remaining_sim <= 0:
trials_done += 1
break
P(done by date) ≈ trials_done / NKung humigit-kumulang 8,700 sa 10,000 trials ang natapos ang natitirang scope sa o bago ang Huwebes, sasabihin mo: feature X sa Huwebes na may humigit-kumulang 87 porsyento na kumpiyansa. Iyon ang pangungusap na magagamit ng mga board. Ito rin ang pangungusap na nag-uudyok ng scope conversation kapag ang numero ay 40 porsyento.
Ang cumulative view ay parehong ideya sa isang linya. Hayaang \(T\) ang simulated completion time sa ilalim ng resampling ng historical throughput. Pagkatapos:
P(T \le t_{\text{Thursday}}) \approx \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}[T_i \le t_{\text{Thursday}}]Opsyonal na Bayesian updates ay itinuturing ang pinakabagong sprint bilang bagong ebidensya na nagbabago sa iyong paniniwala tungkol sa throughput. Kapaki-pakinabang kapag stable na ang serye; dekorasyon bago iyon. Mas gusto ang throughput counts kapag kaya: mas kaunti ang drift kaysa sa points at mas malinis na kumokonekta sa Little's Law style flow thinking. Gumagana pa rin ang points kung pare-pareho ang scale ng team at tinatanggihan mo ang inflation. Sa alinmang paraan, ang unit sa history ay dapat tumugma sa unit ng natitirang trabaho.
Ang mga pampublikong tooling write-up (ActionableAgile documentation at kaugnay na practitioner blogs) ay karaniwang nagpapakita ng planning percentiles tulad ng p50, p85 at p95: coin-flip, commit at sleep-at-night. Ang isang ~87 porsyento na halimbawa ay malapit sa commit band na itinuturing ng maraming team bilang board-safe. Ituring ang vendor screenshots at percentile defaults bilang industry practice, hindi bilang isang regulated standard.
Bakit ito ay mas mahusay kaysa sa waterfall planning theatre
Ang waterfall planning theatre ay nagbebenta ng isang solong petsa at itinatago ang contingency sa mga buffer, overtime at tahimik na scope cuts. Kapag nadulas ang petsa, nawawala ang tiwala dahil hindi kailanman inamin ng plano ang kawalan ng katiyakan. Ang Probabilistic Agile ay nagbebenta ng parehong tanong sa kalendaryo na may isang band: narito ang hitsura ng 50 porsyento, narito ang hitsura ng ~87 porsyento, narito ang kailangan mong i-cut o idagdag upang lumipat sa pagitan nila.
Ang pangalawang modelo ay mas mahirap sa kwarto sa loob ng limang minuto at mas madali sa loob ng anim na buwan. Maaaring pumili ng risk ang mga sponsor. Maaaring ipalit ng product ang scope para sa petsa. Maaaring ipakita ng engineering kung aling mga dependency ang nagbabago sa percentile. Ang audit at risk ay nakakakuha ng trail: ang forecast, ang data window, ang mga assumption at ang desisyon. Iyon ay adult governance. Ang isang Gantt na palaging madudulas ay hindi.
Mga caveat
Ang basura na points ay gumagawa ng basura na probabilities. Kung nag-i-inflate ang story points pagkatapos ng bawat planning session, ang iyong Monte Carlo ay magiging confident na mag-forecast ng kalokohan. Ayusin ang scale o lumipat sa item counts.
Ang cross-team dependencies ay nasisira ang naïve forecasts. Ang isang team na natatapos ang sarili nitong mga story sa oras ay maaari pa ring madulas kung ang isang platform squad, isang change window o isang vendor ay nasa critical path. I-modelo nang malinaw ang dependency o palawakin ang confidence band hanggang magawa mo ito.
Ang portfolio roll-up ay hindi "i-sum ang mga confidence". Ang tatlong team na bawat isa ay 87 porsyento sa dependent slices ay hindi nagbibigay ng 87 porsyento na programa. Mahalaga ang correlation at dependency structure. I-roll up gamit ang isang portfolio simulation o gamit ang explicit critical-path honesty, hindi gamit ang arithmetic optimism.
Ang mga ceremony na walang priority ay nabibigo pa rin. Ang perpektong throughput charts sa isang backlog na hindi ranked ay magfo-forecast ng maling trabaho na may kahanga-hangang katumpakan. Ang priority at feedback ay nananatiling operating system; ang Monte Carlo ay ang instrumentation.
Isang pragmatic rollout para sa isang regulated organisation
Pumili ng isang established product team na may tunay na outcome sa kalendaryo, hindi isang bagong transformation squad. I-instrument ang completion sa loob ng apat hanggang walong sprint na may napagkasunduang Done criteria. Panatilihin ang PI o quarterly planning para sa coarse outcomes at T-shirt capacity; itigil ang paggamit nito bilang isang peke na detalyadong schedule. Turuan ang mga sponsor na humingi ng percentile commitments ("anong petsa sa ~85–90 porsyento?") sa halip na isang solong tahimik na petsa.
Ilagay ang forecasting sa tabi ng umiiral na governance sa halip na mag-imbento ng parallel cult. Kailangan pa rin ng risk at change committees ng mga petsa; bigyan sila ng dated probabilities at ang mga scope assumptions sa ilalim nito. Idokumento ang data window, ang sampling method at kung sino ang maaaring magbago ng scope kapag bumababa ang confidence. Para sa mga bagong team, mag-publish lamang ng directional ranges at sabihin kung kailan nagsisimula ang board-grade forecasting. Iwasan ang tool sprawl: isang analytics path, isang definition of Done, isang may-ari para sa forecast hygiene.
Alam na ng mga bangko at insurance company kung paano mag-usap tungkol sa probabilidad sa credit, actuarial at operational risk. Ang delivery forecasting ay parehong intelektwal na galaw na inilapat sa throughput. Ang cultural block ay hindi ang matematika. Ito ay ang ugali ng pagtrato sa isang Gantt diamond bilang mas ligtas kaysa sa isang tapat na band.
Mga agarang susunod na hakbang
Pangalanan ang priyorisadong mga outcome para sa susunod na ~90 araw at patayin ang mga duplicate P1.
Pumili ng isang established team; i-freeze ang Done criteria; kunin ang throughput o points na natapos sa susunod na dalawang buwan nang walang paglalaro.
Palitan ang susunod na board date ask ng isang percentile commitment: scope X sa petsa Y na may ~87 porsyento (o ipakita ang cut na kinakailangan upang makarating doon).
Ipakita ang tatlong pangunahing cross-team dependencies na magpapawalang-bisa sa sample at magtalaga ng mga may-ari.
Pagkatapos lamang nito ay pumili ng tooling; spreadsheet muna ay mabuti.
Tanggihan ang petsa at sanayin mo ang organisasyon na mag-imbento ng isa nang wala ka. Magpeke ng katumpakan at sanayin mo ito na balewalain ka kapag naging pula ang bar. Ang probability commitments ang adult middle path: Binabago ng Agile kung paano ka nagpaplano at nangangako; hindi nito inaalis ang alinman sa dalawa.