Kako pretvoriti specifikaciju proizvoda u plan implementacije

Zašto je ovaj korak važan

Specifikacija opisuje šta proizvod treba raditi i zašto to treba raditi.

Plan implementacije opisuje kako će tim isporučiti to ponašanje u slijedu koji je pregledljiv, testabilan i realističan.

Mnogi projekti zapnu upravo u prostoru između ta dva dokumenta.

Specifikacija može biti dobra, ali plan postane previše neodređen, previše tehnički ili previše odvojen od korisničkih tokova rada. U radu uz podršku AI-ja to je još češće jer generisani kod može stvoriti utisak da se planiranje već dogodilo, iako zapravo nije.

Počnite izdvajanjem odluka o proizvodu

Prije nego što specifikaciju pretvorite u zadatke, prepoznajte odluke koje zaista ograničavaju implementaciju.

Tražite:

• svrhu proizvoda
• korisnički tok rada
• granice opsega
• pravila o kojima nema pregovora
• rezervno ponašanje
• kriterije prihvatanja

To su dijelovi koji trebaju preživjeti prelaz iz specifikacije u plan.

Ako ih plan izgubi, obično se svede na tehnički popis obaveza umjesto na plan isporuke.

Podijelite plan na slojeve

Dobar plan implementacije obično ima barem tri sloja.

1. Sloj toka rada

Opišite korisniku vidljiv tok u kratkim konkretnim koracima.

Primjer:

1. korisnik bira kutiju za pohranu
2. korisnik skenira ili unosi ISBN
3. korisnik i dalje može nastaviti ako pretraga ne uspije
4. korisnik sprema fizički primjerak na odabranu lokaciju

Ovaj sloj štiti korisničko putovanje od toga da bude zatrpano tehničkim zadacima.

2. Sistemski sloj

Opišite dijelove sistema koji moraju podržati taj tok rada.

Primjeri:

• promjene modela podataka
• UI ekrani ili forme
• validacijska pravila
• ponašanje importa/eksporta
• ažuriranja lokalizacije
• potrebe provjere

Ovaj sloj povezuje ponašanje proizvoda s tehničkim radom.

3. Sloj isporuke

Razlomite sistemski rad u slijed koji se zaista može implementirati i pregledati.

Primjeri:

1. definisati ili ažurirati model domene
2. implementirati osnovni UI tok
3. dodati rezervno ponašanje
4. dodati validaciju i testove
5. ažurirati dokumentaciju i primjere

To je sloj u kojem plan postaje rasporediv.

Neka plan oblikuju ograničenja

Planovi implementacije često skrenu s pravog puta kada se prepišu u generičke inženjerske korake.

Da biste to izbjegli, ključna ograničenja proizvoda držite vidljivima unutar plana.

Za rad u stilu Let Books to može uključivati ograničenja kao što su:

• ručni tokovi rada i dalje moraju funkcionisati bez AI-ja
• nepotpuni podaci moraju biti dozvoljeni
• fizički primjerci moraju ostati odvojeni od bibliografskih zapisa
• lokalizacija se ne smije tretirati kao opcionalni završni sloj
• dokumentacija trenutnog stanja mora ostati poštena o onome što sada postoji

Ta ograničenja ne bi trebala živjeti samo u izvornoj specifikaciji. Trebaju se pojavljivati i u bilješkama planiranja i kriterijima pregleda.

Koristite kriterije prihvatanja za oblikovanje razrade zadataka

Jedan od najlakših načina da specifikaciju pretvorite u plan jeste da krenete od kriterija prihvatanja.

Za svaki kriterij pitajte:

• koji UI ili tok rada to podržava
• koje podatkovno ili sistemsko ponašanje to podržava
• koji slučaj neuspjeha i dalje mora uspjeti
• kako ćemo to provjeriti

Ta metoda drži plan vezanim za opažljive ishode umjesto za apstraktne rasprave o arhitekturi.

Planiranje uz podršku AI-ja: na šta paziti

AI može pomoći da se plan implementacije proizvede brzo, ali često uvodi ponavljajuće probleme:

• dodatne apstrakcije bez potrebe proizvoda
• zadatke grupisane po tehnologiji umjesto po toku rada
• optimistično izostavljanje rezervnog ponašanja
• skrivene pretpostavke o dostupnosti backenda ili kvalitetu podataka
• planove koji izgledaju potpuno, ali zanemaruju dokumentaciju i provjeru

Kada pregledate plan implementacije koji je generisao AI, pitajte odražava li on i dalje stvarni skup pravila proizvoda.

Praktičan predložak planiranja

Koristite strukturu poput ove:

1. cilj funkcionalnosti
2. sažetak korisničkog toka rada
3. ograničenja i pravila o kojima nema pregovora
4. isporučivi segmenti
5. strategija provjere
6. potrebna ažuriranja dokumentacije

Na primjer, isporučivi segment mogao bi biti:

• dodati izbor lokacije pohrane u tok unosa
• dozvoliti spremanje bez uspješnog pretraživanja metapodataka
• pohraniti fizički primjerak odvojeno od bibliografskih metapodataka
• ažurirati tekst vodiča i bilješke za provjeru

To je mnogo jače od ravne liste poput:

• napraviti formu
• dodati API poziv
• dodati testove

Primjer iz Let Books

Repozitorij već sadrži sirove ulaze za ovakav stil planiranja:

• AGENTS.md za svrhu proizvoda, tokove rada i kriterije prihvatanja
• AGENTS-Implementation.md za ograničenja isporuke i pravila repozitorija
• README.md za očekivanja trenutnog stanja
• docs/Development.md i docs/Deployment.md za kontekst validacije i isporuke

To znači da plan implementacije ne mora izmišljati vlastitu logiku. On treba te slojeve prevesti u ograničen slijed isporuke.

Kontrolna lista za pregled

Prije prihvatanja plana implementacije provjerite:

1. Čuva li korisnički tok rada iz specifikacije?
2. Drži li vidljivima pravila proizvoda o kojima nema pregovora?
3. Uključuje li rezervno i neuspješno ponašanje?
4. Uključuje li dokumentaciju i provjeru, a ne samo zadatke koda?
5. Može li drugi saradnik implementirati prema ovom planu bez nagađanja o namjeri proizvoda?

Dodatno čitanje

• ../spec-driven-content-program.md
• how-to-write-a-spec-that-ai-can-follow.md
• how-to-keep-spec-docs-demo-and-code-aligned.md
• ../wiki/bs/spec-driven-development.md
• ../blog/bs/spec-driven-development-in-let-books.md