Planning flow¶

Toto je odporúčaný postup pre plannera, ktorý mení validovaný scope špecifikácie na kontrolovateľné plánovacie baseline-y. Použite ho vtedy, keď potrebujete hrubý rozsah úsilia vo vybranej jednotke profilu, confidence, signály pripravenosti, dôkazy faktorov a auditovateľné rozhodnutie pred tým, než začne downstream implementačná práca.

Planning nie je delivery scheduling a nie je to záväzok doručenia. Produkuje plánovacie odporúčanie zo špecifikačných artefaktov, AI-extrahovaných faktorov a estimation profilu vybraného na Plane. Človek stále rozhoduje, či je hodnotenie dosť dôveryhodné na prijatie, prepísanie alebo nahradenie.

Pred začiatkom skontrolujte, že Planning je zapnutý, vaša rola vie otvoriť Plans a cieľová specification už má zmysluplné Epics, Requirements a ideálne aj Use Cases. Test Cases sú voliteľné, ale zlepšujú testovací faktor. Prvý prechod zvyčajne trvá 10 až 20 minút na jeden Planning Scope podľa toho, koľko review vygenerované hodnotenie potrebuje.

Prehľad flowu¶

Overte, že specification je pripravená na planning.
Vytvorte alebo otvorte spec-scoped Plan.
Skontrolujte Scope Coverage pre každý Planning Scope.
Vygenerujte Scope Assessment.
Skontrolujte rozpad Scope Items a assessment drivery.
Prijmite, prepíšte alebo nahraďte assessment.
Vygenerujte a skontrolujte Role Allocation a Specification Allocation.
Vygenerujte a skontrolujte Plan-level Minimum Baseline.
Premietnite prijatý Minimum Baseline do kandidátov na Features.
Skontrolujte Remaining Scope a vytvorte Extensions pre neskoršie pokrytie.
Udržiavajte planning baseline pri zmenách špecifikácie.

Stránky používané v tomto flowe¶

Štartovací kontext: stránka Projects, stránka Project a stránka Plans
Plánovací kontajner: detail Plan
Hodnotenie scope: stránka Planning Scope
Pravidlá odhadu: tab Estimation Profiles na stránke Tenant a tab Delivery Role Profiles na stránke Tenant
Upstream príprava: Flow analytika
Downstream použitie: Flow buildera

1. Overte, že specification je pripravená na planning¶

Použité stránky: stránka Project, stránka Specifications a Flow analytika

Planning závisí od kvality a vzťahov špecifikačných artefaktov. Pred vytvorením alebo prijatím plánovacích odhadov skontrolujte, že cieľový Epic má dosť refinovaného obsahu.

Odporúčaná kvalita vstupov:

Requirements majú byť dosť jasné na klasifikáciu faktorov UI, backend, dáta, integrácia, bezpečnosť a test.
Use Cases majú existovať vždy, keď je to možné. Planning používa Use Cases ako primárne scope items, pretože zvyčajne opisujú súvislé správanie.
Requirements, ktoré nie sú prepojené na žiadny Use Case, sú stále zahrnuté ako fallback riadky, aby z planningu nezmizli.
Test Cases, ak existujú, sa používajú na klasifikáciu testovacieho faktora. Ak nie sú prepojené žiadne Test Cases, Planning odvodí testovací faktor z Use Cases alebo fallback Requirements.

Čo očakávať:

neúplné prepojenia nie vždy blokujú generovanie assessmentu
slabé prepojenia produkujú slabšie dôkazy a nižšiu confidence
chýbajúce Test Cases sú viditeľné ako coverage gapy, nie ako automatické zlyhanie

Ak je scope stále surový, najprv použite Flow analytika. Planning flow je najužitočnejší po tom, čo sú Requirements a Use Cases dosť zrozumiteľné na ľudské review.

2. Vytvorte alebo otvorte spec-scoped Plan¶

Použité stránky: stránka Plans a detail Plan

Otvorte Plans z hornej navigácie alebo zo stránky projektu. Plan je viazaný na jednu Specification a obsahuje jeden Planning Scope pre každý vybraný Epic.

Nový Plan použite vtedy, keď:

specification ešte nebola plánovaná
potrebujete samostatný plánovací kontajner pre nový planning cyklus
predchádzajúci Plan zámerne nahrádzate namiesto toho, aby ste ho ďalej upravovali

Existujúci Plan použite vtedy, keď:

pokračujete v review pre rovnakú Specification a rovnaký scope set
potrebujete pozrieť prijaté baseline-y, históriu assessmentov alebo timeline aktivitu
potrebujete pridať chýbajúci Epic ako ďalší Scope

Čo očakávať:

Plans sa dajú upravovať v ľubovoľnom lifecycle stave; úprava accepted alebo superseded Plan ho znovu otvorí ako draft
legacy Plans viazané priamo na Epic sú v novom spec-scoped detaile Plan iba na čítanie
rodičovský Plan nie je plne accepted, kým každý aktívny Scope nemá prijatý baseline

3. Skontrolujte Scope Coverage¶

Použitá stránka: stránka Planning Scope

Otvorte Planning Scope z detailu Plan a začnite v Overview. Najprv skontrolujte context tree, aby bolo jasné, ktorý Project, Plan, Scope a zdrojový Epic hodnotíte.

V Scope Coverage skontrolujte:

zdrojový Epic
popis Scope
súhrn prijatého baseline, ak už existuje
počet plánovacích položiek
coverage Requirements a Use Cases
fallback Requirements neprepojené na Use Cases
dôkazy z Test Cases

Použite Refresh Coverage, keď sa zmenili linky alebo zdrojové artefakty a súhrn pokrytia treba prepočítať.

Usmernenie pre rozhodnutie:

Ak sa zobrazuje nesprávny Epic alebo Scope, vráťte sa na Plan pred generovaním assessmentu.
Ak príliš veľa Requirements vystupuje ako fallback riadky, zlepšite upstream prepojenia Requirements na Use Cases.
Ak nie sú prepojené žiadne Test Cases, rozhodnite, či je odvodená testová klasifikácia pre tento odhad akceptovateľná.

4. Vygenerujte Scope Assessment¶

Použitá stránka: stránka Planning Scope

Otvorte tab Assessment a použite Generate. Generovanie beží na pozadí. Ak sa stránka neaktualizuje okamžite, kliknite na logo AIKOZO v hornej lište a v Background jobs skontrolujte, či je úloha queued, running, completed alebo failed.

Generovanie vytvorí:

samostatné analýzy Full Scope a Active Scope, každú s readiness, confidence, drivermi, chýbajúcimi informáciami a rozsahom min/most-likely/max
nulový Active Scope odhad, keď sú odložené všetky Scope Items
klasifikácie všetkých Scope Items vrátane odložených
kanonické deterministické rozdelenie úsilia s presným zosúladením
key, verziu a snapshot estimation profile, ak sú dostupné

Generovanie neprijme odhad automaticky. Vygenerovaný assessment je kandidát na review, kým ho Planner alebo Admin neprijme.

5. Skontrolujte Scope Items a assessment drivery¶

Použitá stránka: stránka Planning Scope

Tab Scope Items použite na odpoveď: "Na čo je tento scope rozložený?"

Každý riadok reprezentuje buď:

primárny Use Case, alebo
fallback Requirement, keď daná Requirement nie je prepojená na žiadny Use Case

Pri každom riadku skontrolujte:

úrovne faktorov UI, backend, dáta, integrácia, bezpečnosť a test
evidence text vysvetľujúci, prečo boli faktorové úrovne priradené
faktorové pills, kde môžu Admini a Planneri kliknúť na ľavú polovicu pre zníženie úrovne faktora alebo na pravú polovicu pre jej zvýšenie
kombinovaný detail Decision s pôvodom rozhodnutia a dôvodom
kombinovaný detail Effort s kanonickými Full aj Active príspevkami
akciu Defer alebo Restore, keď má položka Scope odísť z aktívneho plánovacieho scope alebo sa doň vrátiť bez úpravy zdrojového artefaktu; obe akcie vyžadujú dôvod

Každá položka Scope používa dvojriadkovú skupinu. Názov položky a Action prechádzajú cez oba riadky; prvý riadok obsahuje Decision, Effort a Evidence, zatiaľ čo druhý zobrazuje všetkých šesť faktorov v jednej zlúčenej bunke. Počty prepojených Requirements a Test Cases sú vynechané, aby sa údaje zamerané na rozhodovanie zmestili bez horizontálneho posúvania.

Zmena ľubovoľného faktora položky prepočíta jej kanonický Full a Active effort príspevok a premietne rozdiel do odhadov Scope. Príspevky ostatných položiek Scope zostanú nezmenené; úsilie sa neprerozdeľuje tak, aby zachovalo pôvodný celkový odhad. Nastavenie faktora na none preto odstráni kalibrovaný príspevok daného faktora z položky. Existujúce allocations a nadväzujúce Minimum Baselines sa pre audit označia ako stale. Zostávajú použiteľné, ale nemusia zohľadňovať zmenené hodnoty faktorov.

Potom sa vráťte do Assessment a skontrolujte readiness, effort, confidence, effort drivers, risk drivers a missing information.

Odloženie Scope Itemu je iba rozhodnutie v plánovacej doméne. Uloží trvalý overlay na Planning Scope, Requirements, Use Cases a Test Cases nechá bez zmeny a označí prijaté plánovacie výstupy ako stale. Tieto výstupy zostávajú použiteľné; upozornenie na aktuálnosť vysvetľuje, že nemusia zohľadňovať najnovšie rozhodnutie. UI netvrdí okamžitú úsporu, kým sa Active Scope odhad nepregeneruje a neskontroluje.

Usmernenie pre rozhodnutie:

vysoký effort so slabými dôkazmi treba pred prijatím skontrolovať opatrne
missing information je plánovacie riziko, nie iba poznámka
nízka confidence je signál na zlepšenie zdrojových artefaktov alebo doplnenie review note
Scope Items sú klasifikačné dôkazy, nie výstup Effort Allocation

6. Prijmite, prepíšte alebo nahraďte assessment¶

Použitá stránka: stránka Planning Scope

Review akcie používajte až po kontrole vygenerovaného assessmentu a dôkazov v Scope Items.

Dostupné rozhodnutia:

Review: pridá review note bez toho, aby sa assessment stal baseline.
Accept: spraví z assessmentu aktuálny planning baseline pre Scope.
Override: nahradí jeden alebo oba odhady Full/Active s jedným povinným zdôvodnením. Active min/likely/max nesmie prekročiť Full.
Supersede: vyradí assessment, keď už nemá byť považovaný za aktuálny.
Ak je najnovší assessment už superseded, ale stále existuje prijatý baseline, Supersede cieli na tento prijatý baseline, aby Scope už neblokoval zmenu jednotky na Plane.

Čo očakávať po prijatí:

prijatý assessment sa stane baseline Scope
predchádzajúce prijaté assessmenty pre rovnaký Scope sa označia ako superseded
prepočíta sa rollup rodičovského Plan
upozornenia na aktuálnosť sa zobrazia po zmene vstupov; sú informačné a neblokujú plánovacie akcie
assessment zostáva auditovateľný v histórii a filtrovateľných detailoch timeline

Prijmite iba odhad, ktorý je dôveryhodný pre planning. Override použite iba vtedy, keď je ľudská korekcia zámerná a jej zdôvodnenie bude dávať zmysel aj neskoršiemu reviewerovi.

7. Vygenerujte a skontrolujte Role Allocation a Specification Allocation¶

Použitá stránka: stránka Planning Scope

Tab Roles otvorte až po prijatí assessmentu na vygenerovanie a kontrolu role splitu. Dovtedy stránka zobrazuje Accept an assessment before role allocation. Tab Allocation použite pre rozdelenie podľa špecifikačných artefaktov; kým assessment nie je prijatý, zobrazuje Accept an assessment before allocation.

Stránka Planning Scope má dva allocation pohľady:

Role Allocation najprv rozdelí príspevok každej aktívnej položky Scope medzi jej šesť faktorov odlišných od none a potom rozdelí každý faktorový bucket iba medzi roly oprávnené pre daný faktor. Váhy a faktorové úpravy z Delivery Role Profile určujú rozdelenie vnútri bucketu. Faktor none neprispieva žiadnym úsilím; ak sú napríklad všetky test faktory none, rola Tester sa nealokuje. Key, verzia, snapshot profilu, faktorové rozdelenie a faktorové reconciliation sa ukladajú pre audit.
Specification Allocation používa Full alebo Active základ (predvolene Active). Full zahŕňa celú lineage a Active vynechá odloženú lineage. Ide o voliteľný pohľad, nie podmienku Minimum Baseline.

Použite Generate Allocation na tabe Roles, keď potrebujete role split pre planning a review. Použite Generate Allocation na tabe Allocation, keď potrebujete traceable effort guidance podľa špecifikačného artefaktu. Obe cesty sa zosúlaďujú späť na prijatý odhad Scope, takže súčet alokovaného effortu rolí zodpovedá súčtu alokovaného effortu špecifikačných artefaktov pre rovnaký prijatý assessment.

Skontrolujte:

prijatý odhad assessmentu a Delivery Role Profile priradený k Planu
faktorovo proporcionálne podiely rolí, rozsahy effortu, faktorové zdôvodnenie, confidence, maticu úsilia faktorov a rolí a podľa potreby CSV export. Riadky matice sú koše úsilia faktorov, stĺpce sú delivery roly a CSV obsahuje rovnaké hodnoty košov a príspevkov rolí. Po umiestnení kurzora nad názov riadka alebo počty úrovní sa zobrazí vysvetlenie, že ide o počty aktívnych položiek Scope na jednotlivých úrovniach faktora a ich úsilie sa zdieľa medzi oprávnené roly. Odložené položky Scope sa do týchto počtov nezahŕňajú. Kompaktné hlavičky matice používajú BE Developer a FE Developer
allocation target: automatic, Use Cases, Requirements alebo Test Cases
allocation method: factor weighted alebo equal
total allocated effort
reconciliation status
riadky prepojených artefaktov, final text, váhy položiek, koše úsilia faktorov a podľa potreby CSV export

Čo očakávať:

ak role allocation ešte neexistuje, stránka hovorí No role allocation generated yet.
ak allocation ešte neexistuje, stránka hovorí No allocation generated yet.
vygenerované role allocation aj specification allocation totals sa majú zhodovať s prijatým odhadom
Factor-weighted Specification Allocation a Role Allocation používajú rovnaký kanonický výpočet košov úsilia faktorov. Generovanie sa explicitne zastaví, ak aktívnej položke Scope chýbajú platné faktory, všetkých šesť faktorov je none pri nenulovom úsilí, alebo kanonické úsilie položiek nesedí s Active Scope; equal fallback sa nepoužíva
malé rozdiely zo zaokrúhlenia sa pridajú poslednej položke
každá položka zobrazuje koše úsilia faktorov UI, backend, dáta, integrácia, bezpečnosť a test; klasifikácie low/medium/high prerozdelia allocation položky a zachovajú jej celkový súčet
prijaté allocations sú plánovacie usmernenie, nie delivery commitments

8. Vygenerujte a skontrolujte Minimum Baseline¶

Použitá stránka: detail Plan

Keď má každý aktívny Scope aktuálne prijaté dvojité hodnotenie, vráťte sa na detail Plan a otvorte Minimum Baseline. Specification Allocation nie je podmienkou. Použite Generate na vytvorenie nemennej deterministickej revízie z prijatých hodnotení a kanonických rozdelení Scope Items. Akcia nevolá AI a nevymazáva ani nemení Requirements, Use Cases, Test Cases, Scope Assessments ani allocations. Uloží snapshot, takže neskoršie zmeny zdrojov neprepíšu historické baseline-y.

Klasifikácie:

included: existuje mandatory alebo core dôkaz, napríklad high alebo critical priorita, prijatý/final core workflow, security, audit, compliance alebo explicitný required jazyk.
required dependency: artefakt podporuje included položku cez Requirement, Use Case, Test Case alebo schválené dependency graph linky.
Deferred from this Minimum Baseline: existuje explicitný optional, nice-to-have, secondary, reporting alebo advanced-filtering dôkaz a neexistuje mandatory ani dependency dôkaz.
excluded: existuje explicitný out-of-scope, obsolete, deprecated alebo cancelled dôkaz.
decision needed: chýba allocation alebo assessment, dôkazy sú v konflikte, existuje compliance/security nejasnosť alebo dôkazy nestačia. Ticho samo o sebe položku neodkladá.

Zosúladenie platí pre min, most-likely aj max:

Full Scope = Active Scope + explicitne odložené plánovačom
Active Scope = Minimum Baseline + baseline-deferred + excluded + decision-needed
Plánované zníženie zahŕňa explicitne odložené, baseline-deferred a excluded úsilie; nikdy nezahŕňa decision-needed
neúplné náklady alebo nenulový residual blokujú prijatie

Štyri kompaktné súhrnné karty zobrazujú Full Scope, aktuálny Active Scope, aktuálny cieľ Minimum Baseline a plánované zníženie s výrazným rozsahom a samostatnou najpravdepodobnejšou hodnotou.

Časť Zosúladenie Scope oddeľuje rozdelenie úsilia od aritmetiky. Päť kompaktných dlaždíc zobrazuje úsilie a počet položiek v Minimum Baseline a potom úsilie presunuté odkladmi plánovača, navrhnutými alebo prijatými odkladmi, vylúčeniami a nevyriešenými rozhodnutiami. Podporné auditné informácie sú zoskupené pod Detaily baseline, aby sa dali hlavné odhady a rozhodnutia rýchlo prečítať. Po rozbalení sa zobrazia zdrojové hodnotenia, počty klasifikácií, poznámky ku kontrole a samostatné kontroly Vyváženie Full Scope a Vyváženie Active Scope, ktoré zobrazia zelený stav Vyvážené, keď je príslušný zvyšok nulový; nenulový zvyšok sa zvýrazní ako odchýlka na kontrolu. Nevyriešené úsilie tak zostáva viditeľné bez toho, aby sa prezentovalo ako plánované zníženie.

Navrhnuté na neskôr a Vylúčené používajú nemennú revíziu Minimum Baseline. Odložené plánovačom používa aktuálne rozhodnutia Scope Items a sčíta ich kanonické Full Scope príspevky. Aktuálny Active Scope, odhad Minimum Baseline, plánované zníženie a karta V Minimum Baseline sa projektujú z týchto aktuálnych odkladov. Vyžaduje rozhodnutie používa otvorené Savings Opportunities, ktorých backend validácia je decision_needed, a sčíta dostupné orientačné rozsahy. Pomocný text uvádza, koľko opportunities má kvantifikované úsilie. Aplikované opportunities opustia túto skupinu a zobrazia sa cez výsledné odložené rozhodnutia Scope. Kontroly vyváženia naďalej používajú nemenné súčty revízie.

Prijatie s decision-needed effort je možné iba po potvrdení upozornenia. Vygenerované, skontrolované a prijaté revízie sú nemenné. Zmena rozhodnutí alebo coverage ich pre audit označí ako stale, ale pred pokračovaním nevyžaduje novú revíziu. Novú revíziu vygenerujte, keď potrebujete zohľadniť najnovšie vstupy.

Kanonická jednotka je person_days alebo person_hours. Každá skupina zosúladenia zachováva jednotku estimation profile; UI ju zobrazuje ako person-days alebo person-hours bez vzájomného prepočtu.

Použite Review, keď je vygenerovaný baseline skontrolovaný, Accept, keď ho chcete prijať ako aktuálny Minimum Baseline pre Plan, a Supersede, keď už baseline nemá byť aktuálny. Prijatie nového Minimum Baseline nahradí predtým prijatý Minimum Baseline pre rovnaký Plan. Supersede nie je vymazanie; staré baseline-y zostávajú audit records.

Otvorte Design verification a použite Generate v sekcii Design-informed Confidence, keď existuje final Implementation Design a chcete overiť, či je Minimum Baseline stále dôveryhodný voči architektúre. Review číta persistované fragmenty Implementation Designu a Patterns vybrané alebo povolené týmto Designom. Nečíta Flow Designs, Features, Execution Targets, Action Packs, Instruction Sets, Build Runs, JIRA tasks ani implementation tasks a nemení záznamy Design ani Pattern.

Výsledok Design-informed Confidence ukladá architecture fit, Pattern fit, reuse evidence, architektonické effort a risk drivery, chýbajúce architektonické informácie, poznámky k realizmu baseline, referencované Design fragments, referencované Patterns, odporúčanú confidence a to, či sa confidence má zvýšiť, znížiť alebo zostať bez zmeny. Odporúčaná confidence je usmernenie pre ľudské planning review; neprepočítava effort, neprepisuje prijaté Scope Assessments, neprepisuje prijaté allocations a nemení prijatý Minimum Baseline. Roly Planner a Admin môžu tieto reviews generovať, skontrolovať, prijať, nahradiť alebo obnoviť. Prijaté reviews vytvárajú auditovateľný confidence checkpoint pred neskoršou fázou Feature Projection.

Generovanie Design-informed Confidence beží ako background job. V Background jobs cez logo AIKOZO skontrolujete, či je Design Confidence job queued, running, completed alebo failed. Keď job dobehne a review sa ešte neaktualizovala, obnovte tab Design verification.

Tab Minimum Baseline vie pre existujúci Minimum Baseline vygenerovať aj Savings Opportunities. Sú to AI-asistované návrhy, ktoré odpovedajú, kde môže Plan znížiť implementačný effort a stále zachovať required scope. Nenahrádzajú deterministické generovanie baseline: AI iba navrhuje kandidátov a backend validuje referencie artefaktov, ochranu mandatory scope, ochranu dependencies, bezpečnosť klasifikácie, tenant/project scope a všetky výpočty úspor pred tým, ako sa návrh zobrazí.

Použite Generate, aby sa AI prompt zaradil ako background job. Počas štartovania jobu tlačidlo zobrazuje Generating.... V Background jobs cez logo AIKOZO skontrolujete, či je Minimum Baseline savings job queued, running, completed alebo failed. Keď job dobehne a tabuľka sa ešte neaktualizovala, obnovte tab Minimum Baseline.

Savings Opportunities používajú tieto typy návrhov:

defer: presunúť jasne optional scope mimo Minimum Baseline.
reduce: zúžiť jasne optional scope pri zachovaní required správania.
split later: ponechať required správanie teraz a secondary správanie presunúť neskôr.
decision required: zvýrazniť nejasnosť, ktorú musí Planner alebo Admin vyriešiť pred tým, ako sa môže počítať ako úspora.

Každá príležitosť je naviazaná na artefakty, ktoré už sú v Minimum Baseline alebo prijatých allocations. Úspory sa počítajú iba z existujúcich allocation item odhadov a zobrazujú sa ako Indicative saving. Ak je artefakt mandatory, security/compliance/audit critical, required dependency, časť prijatého core workflow alebo je nejasný, backend môže stále zobraziť orientačný effort naviazaný na affected artifact a príležitosť označiť ako decision needed. Ak artefakt nemá allocation estimate, nie je čo zobraziť ako orientačnú úsporu. Návrhy príležitostí nevymazávajú, neodkladajú ani nemenia Specification artefakty; kontrola Planner/Admin zostáva povinná.

Keď sa affected artifacts jednoznačne mapujú na Planning Scope Items, Defer all zapíše rozhodnutia a označí príležitosť ako applied. Zdrojový Minimum Baseline nikdy neprepisuje. Stale prijatý baseline možno naďalej použiť pre nové Savings, Design Confidence, Feature Projection a Extension generation/apply akcie. UI ponechá upozornenie na aktuálnosť viditeľné, pretože tieto výstupy môžu používať staršie vstupy.

9. Premietnite Feature Candidates¶

Použitá stránka: detail Plan

Po prijatí Minimum Baseline otvorte Feature Candidates. Tento tab odpovedá, ktoré Implementation Features majú vzniknúť z prijatého baseline. Generate zaradí background AI job, ktorý vytvorí Feature Projection Proposal z prijatého Minimum Baseline, Baseline Items, prepojených Requirements, Use Cases, Test Cases, prijatej Specification Allocation, dôkazov Role Allocation, keď sú dostupné, prijatého výsledku Design verification, fragmentov Implementation Designu a Patterns vybraných alebo povolených týmto Designom. Job sledujte v Background jobs; tab sa obnoví po dokončení jobu.

Feature Candidates nie sú Flow Designs, Action Packs, Instruction Sets, delivery tasks, execution routing ani code. Sú to kontrolovateľné hranice implementation feature s traceability späť na Plan, Minimum Baseline, proposal, candidate, Baseline Items, Scopes, Requirements, Use Cases, Test Cases, Design fragments a Patterns.

Tab zobrazuje stav proposal, coverage summary, nepriradené Baseline Items, prevzatý effort a zoznam vygenerovaných Feature Candidates. Upozornenia sú zoskupené v predvolene zbalenej časti s viditeľným počtom; rozbaľte ju na kontrolu problémov s validáciou a vysledovateľnosťou. Otvorte kandidáta, ak chcete skontrolovať detail Feature Candidate. Jeho taby oddeľujú Risks and decisions, Included in scope, Required dependencies a Design fragments. Detail zároveň zobrazuje doplnkovú traceability na Requirements, Use Cases a Test Cases, Patterns a linky na vytvorené Features po aplikovaní. Nepriradené Baseline Items sú položky prijatého baseline, ktoré sú oprávnené na projekciu, ale neboli zaradené do Feature Candidate; skontrolujte ich pred prijatím proposal.

Roly Planner a Admin môžu Feature Projection Proposals generovať, kontrolovať, prijímať a nahrádzať. Apply je v aktuálnom UI/API obmedzené na Admin. Apply funguje iba v dvoch bezpečných režimoch:

vytvoriť novú Implementation a vytvoriť Features v nej
použiť existujúcu Implementation iba vtedy, keď nemá žiadne Features

Feature Projection chráni naplnené Implementations. Ak vybraná Implementation už obsahuje Features, apply sa zamietne, nevytvorí sa žiadna Feature a existujúce Features sa neprepíšu ani nezlúčia. Aplikovanie proposal nikdy nemení prijatý Minimum Baseline, Specification artifacts, Design artifacts, Pattern definitions, Flow Designs, Action Packs, Instruction Sets ani execution artifacts.

10. Skontrolujte Remaining Scope a Extensions¶

Použitá stránka: detail Plan

Po aplikovaní Feature Projection otvorte Remaining Scope. Tab porovnáva lineage Plan Scope s traceability vytvorených Implementation Features a ukazuje, čo už bolo premietnuté a čo zostáva mimo projected Implementation. Coverage sa počíta z aplikovaných source referencií Features, nie z manuálnych checkboxov.

Dashboard zobrazuje premietnuté Requirements, Use Cases, Test Cases a effort, keď sú dostupné allocation odhady. Effort coverage používa uložené planning allocation a baseline estimates; keď niektorým artefaktom chýba číselný effort, tab stále zobrazí count coverage a pridá warning namiesto vymysleného odhadu.

Stavy artefaktov znamenajú:

projected: už pokryté vytvorenými Features z aplikovaných projections
remaining: oprávnené na neskoršiu Extension
deferred: zámerne odložené v planningu
decision_needed: blokované, kým planner nezapíše rozhodnutie
excluded: explicitne vylúčené z aktuálneho baseline
blocked: chýba traceability, allocation alebo iný prerequisite

Roly Planner a Admin môžu vybrať artefakty so stavom remaining alebo deferred a vytvoriť Extension. Extension items si uchovávajú source Scope, baseline item, keď je dostupný, allocation estimate a snapshot pôvodného artefaktu. Už premietnuté artefakty nemožno vybrať znova a backend zamietne artefakty mimo lineage Planu.

Prijatá Extension môže vygenerovať vlastný Feature Projection Proposal cez ten istý mechanizmus Feature Candidates ako Minimum Baseline, ale so source_type uloženým ako extension. Extension projection zachováva traceability na Plan, Extension, Extension Items, source baseline items, keď sú dostupné, Scopes, Requirements, Use Cases, Test Cases, Design fragments a Patterns. Nevytvára Flow Designs, Action Packs, Instruction Sets, execution artifacts ani implementation tasks.

Aplikovanie Extension sa líši od aplikovania Minimum Baseline. Baseline projection sa stále dá aplikovať iba do novej Implementation alebo do existujúcej Implementation bez Features. Extension projection sa môže aplikovať aj do existujúcej naplnenej Implementation iba vtedy, keď každá existujúca Feature má traceability na predchádzajúce prijaté alebo aplikované Feature Projections z toho istého Planu. Backend atomicky zamietne unrelated, mixed, untraceable alebo duplicate artifact targety.

11. Udržiavajte baseline pri zmenách scope¶

Použité stránky: detail Plan, stránka Planning Scope, tab Estimation Profiles na stránke Tenant a tab Delivery Role Profiles na stránke Tenant

Planning je baseline, nie jednorazový export súboru. K Planu sa vráťte vtedy, keď sa podkladová specification materiálne zmení.

Pregenerujte alebo znovu skontrolujte assessment, keď:

Requirements alebo Use Cases pribudli, zmizli alebo boli výrazne prepísané
zmenili sa linky medzi Requirements, Use Cases a Test Cases
missing information bolo vyriešené
risk alebo effort drivers už nezodpovedajú aktuálnemu pochopeniu
nový prijatý baseline má nahradiť starý
prijatý Minimum Baseline už nezodpovedá aktuálnym prijatým dôkazom Scope

Použite Assessment history, Timeline na Planning Scope a Versions na Plane na spätné zistenie, čo sa zmenilo a prečo. Aktuálne Planning panely predvolene skrývajú superseded assessments, allocations a Minimum Baselines, aby vyradení kandidáti nerušili aktívny workflow. Estimation Profiles na stránke Tenant použite vtedy, keď potrebujete pozrieť, ktorá deterministická verzia profilu je priradená k Planu pre budúce assessmenty. Zmena predvoleného profilu pre tenant mení iba predvýber profilu pre nové Plany; neprepisuje existujúce odkazy na profily v Planoch. Delivery Role Profiles na stránke Tenant použite na kontrolu alebo správu deterministických váh rolí dostupných pre Plany. Zmena predvoleného profilu pre tenant mení iba predvýber delivery role profilu pre nové Plany; existujúce Plany a Role Allocations si zachovajú uložené odkazy na profily a snapshoty.

Kontrolný zoznam dokončenia¶

Planning flow je hotový vtedy, keď:

každý aktívny Scope v Plane má skontrolované coverage
každý aktívny Scope, ktorý treba plánovať, má prijatý assessment baseline
override-y, ak existujú, majú jasné zdôvodnenie
dôkazy v Scope Items boli skontrolované na slabé alebo prekvapivé klasifikácie
Role Allocation alebo Specification Allocation bolo vygenerované a prijaté, keď treba dané allocation guidance
Plan-level Minimum Baseline bol vygenerovaný a prijatý, keď treba minimum scope optimization guidance
Design-informed Confidence bolo vygenerované a skontrolované, keď má final Implementation Design ovplyvniť planning confidence pred Feature Projection
Remaining Scope bol skontrolovaný po aplikovaní Feature Projection, keď tím potrebuje cestu od Minimum Baseline k širšiemu pokrytiu
tím chápe, že výstup je plánovacie usmernenie, nie delivery commitment