Si ta ktheni një specifikim produkti në një plan implementimi

Pse ka rëndësi ky hap

Një specifikim përshkruan çfarë duhet të bëjë produkti dhe pse duhet ta bëjë.

Një plan implementimi përshkruan se si ekipi do ta dorëzojë atë sjellje në një renditje që mund të rishikohet, testohet dhe realizohet në mënyrë realiste.

Shumë projekte dështojnë në boshllëkun midis këtyre dy dokumenteve.

Specifikimi mund të jetë i mirë, por plani bëhet shumë i paqartë, shumë teknik ose shumë i shkëputur nga rrjedhat e punës së përdoruesit. Në punën e ndihmuar nga AI, kjo ndodh edhe më shpesh sepse kodi i gjeneruar mund ta bëjë të duket sikur planifikimi tashmë ka ndodhur kur në fakt nuk ka ndodhur.

Filloni duke nxjerrë vendimet e produktit

Para se ta ktheni një specifikim në detyra, identifikoni vendimet që e kufizojnë vërtet implementimin.

Kërkoni:

• qëllimin e produktit
• rrjedhën e punës së përdoruesit
• kufijtë e shtrirjes
• rregullat e panegociueshme
• sjelljen rezervë
• kriteret e pranimit

Këto janë pjesët që duhet të mbijetojnë gjatë kalimit nga specifikimi te plani.

Nëse plani i humb këto, zakonisht bëhet një listë teknike detyrash në vend të një plani dorëzimi.

Ndajeni planin në shtresa

Një plan i mirë implementimi zakonisht ka të paktën tri shtresa.

1. Shtresa e rrjedhës së punës

Përshkruani rrjedhën e dukshme për përdoruesin me hapa të shkurtër dhe konkretë.

Shembull:

1. përdoruesi zgjedh një kuti ruajtjeje
2. përdoruesi skanon ose fut një ISBN
3. përdoruesi mund të vazhdojë edhe nëse kërkimi dështon
4. përdoruesi ruan kopjen fizike në vendndodhjen e zgjedhur

Kjo shtresë e mbron rrugëtimin e përdoruesit që të mos groposet nën detyra teknike.

2. Shtresa e sistemit

Përshkruani pjesët e sistemit që duhet ta mbështesin atë rrjedhë pune.

Shembuj:

• ndryshime në modelin e të dhënave
• ekrane ose formularë të ndërfaqes
• rregulla validimi
• sjellje importi/eksporti
• përditësime lokalizimi
• nevoja verifikimi

Kjo shtresë e lidh sjelljen e produktit me punën teknike.

3. Shtresa e dorëzimit

Ndajeni punën e sistemit në një renditje që realisht mund të implementohet dhe rishikohet.

Shembuj:

1. përcaktoni ose përditësoni modelin e domenit
2. implementoni rrjedhën kryesore të ndërfaqes
3. shtoni sjelljen rezervë
4. shtoni validim dhe teste
5. përditësoni dokumentacionin dhe shembujt

Në këtë shtresë plani bëhet i programueshëm.

Mbajeni planin të formuar nga kufizimet

Planet e implementimit shpesh devijojnë kur rishkruhen si hapa të përgjithshëm inxhinierikë.

Për ta shmangur këtë, mbajini të dukshme brenda planit kufizimet kyçe të produktit.

Për punë në stilin Let Books, këto mund të përfshijnë kufizime të tilla si:

• rrjedhat manuale të punës duhet të vazhdojnë të funksionojnë pa AI
• të dhënat e paplota duhet të lejohen
• kopjet fizike duhet të mbeten të ndara nga regjistrat bibliografikë
• lokalizimi nuk mund të trajtohet si zbukurim opsional
• dokumentacioni i gjendjes aktuale duhet të mbetet i ndershëm për atë që ekziston tani

Këto nuk duhet të jetojnë vetëm në specifikimin fillestar. Ato duhet të shfaqen edhe në shënimet e planifikimit dhe kriteret e rishikimit.

Përdorni kriteret e pranimit për të formuar ndarjen e detyrave

Një nga mënyrat më të lehta për ta kthyer një specifikim në plan është të filloni nga kriteret e pranimit.

Për secilin kriter, pyesni:

• cila ndërfaqe ose rrjedhë pune e mbështet këtë
• cilat të dhëna ose cila sjellje e sistemit e mbështet këtë
• cili rast dështimi duhet të ketë përsëri sukses
• si do ta verifikojmë

Kjo metodë e mban planin të lidhur me rezultate të vëzhgueshme në vend të diskutimeve abstrakte për arkitekturën.

Planifikimi me ndihmë nga AI: çfarë të vëzhgoni

AI mund të ndihmojë të prodhohet shpejt një plan implementimi, por shpesh sjell probleme të përsëritura:

• abstraksione shtesë pa nevojë produkti
• detyra të grupuara sipas teknologjisë dhe jo sipas rrjedhës së punës
• lënie optimiste jashtë e sjelljes rezervë
• supozime të fshehta për disponueshmërinë e backend-it ose cilësinë e të dhënave
• plane që duken të plota, por injorojnë dokumentacionin dhe verifikimin

Kur rishikoni një plan implementimi të gjeneruar nga AI, pyesni nëse ai ende pasqyron grupin real të rregullave të produktit.

Një model praktik planifikimi

Përdorni një strukturë si kjo:

1. qëllimi i veçorisë
2. përmbledhje e rrjedhës së punës së përdoruesit
3. kufizime dhe rregulla të panegociueshme
4. copa dorëzimi
5. strategji verifikimi
6. përditësime të nevojshme dokumentacioni

Për shembull, një copë dorëzimi mund të jetë:

• shtoni përzgjedhësin e vendndodhjes së ruajtjes në rrjedhën e regjistrimit
• lejoni ruajtjen edhe pa sukses në kërkimin e metadatave
• ruani kopjen fizike veçmas nga metadatat bibliografike
• përditësoni tekstin udhëzues dhe shënimet e verifikimit

Kjo është shumë më e fortë se një listë e sheshtë si:

• krijo formularin
• shto thirrjen API
• shto testet

Shembull nga Let Books

Depoja tashmë përmban hyrjet bazë për këtë stil planifikimi:

• AGENTS.md për qëllimin e produktit, rrjedhat e punës dhe kriteret e pranimit
• AGENTS-Implementation.md për kufizimet e dorëzimit dhe rregullat e depos
• README.md për pritjet e gjendjes aktuale
• docs/Development.md dhe docs/Deployment.md për kontekstin e validimit dhe dorëzimit

Kjo do të thotë se plani i implementimit nuk ka nevojë të shpikë logjikën e vet. Ai duhet t’i përkthejë këto shtresa në një sekuencë të kufizuar dorëzimi.

Listë kontrolli për rishikim

Përpara se të pranoni një plan implementimi, kontrolloni:

1. A e ruan rrjedhën e punës së përdoruesit nga specifikimi?
2. A i mban të dukshme kufizimet e panegociueshme të produktit?
3. A përfshin sjellje rezervë dhe sjellje në rast dështimi?
4. A përfshin punë për dokumentacion dhe verifikim, jo vetëm detyra kodi?
5. A mund ta implementonte një kontribuues tjetër nga ky plan pa hamendësuar synimin e produktit?

Lexim i mëtejshëm

• ../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/sq/spec-driven-development.md
• ../blog/sq/spec-driven-development-in-let-books.md