Coroid använder specifikationsdriven utveckling: specifikationen följer ett arbete från planering genom testning och granskning, så att varje steg utgår från samma definition av vad som räknas som lyckat.
I stället för att börja med en mening och fatta besluten under tiden koden skrivs omvandlar Coroid förfrågan till en tydlig omfattning, avgränsningar och acceptanskriterier. Dokumentet blir den gemensamma källan för planen, implementationen, testerna och den slutliga granskningen.
Vad är specifikationsdriven utveckling?
Specifikationsdriven utveckling är ett sätt att bygga programvara utifrån en överenskommen, testbar beskrivning av resultatet. Specifikationen beskriver vad som ska ändras, vad som inte ska ändras, vilka begränsningar som gäller och hur en granskare kan avgöra om arbetet lyckades.
Det skiljer två beslut åt som annars lätt blandas ihop:
- Specifikationen specifikation definierar vad som räknas som lyckat.
- Implementationsplanen implementationsplan definierar hur det ska uppnås.
Den uppdelningen gör att du kan korrigera omfattningen innan det finns någon kod, utan att bestämma implementationen för tidigt. I Coroid kan du också aktivera det valfria SDLC-arbetsflödet när du vill godkänna intentionen och specifikationen innan planeringen börjar.
Så fungerar arbetsflödet i Coroid
- Beskriv resultatet. Ge Coroid det resultat du behöver, relevant kontext och eventuella begränsningar eller sådant som inte ingår.
- Granska specifikationen. Kontrollera omfattningen, avgränsningarna och acceptanskriterierna på uppgiftens Specification -flik.
- Godkänn planen. Arkitekten omvandlar det överenskomna resultatet till ordnade implementeringssteg.
- Bygg och verifiera. Utvecklar- och QA-agenter använder samma kriterier för att implementera ändringen och bevisa varje utlovat beteende.
- Granska pull request. Den levererade ändringen tar med planen, testresultaten, fynden och bevisen tillbaka till den ursprungliga specifikationen.
Resultatet är spårbarhet från produktintentionen till den kod och de bevis som en mänsklig granskare ser. Se Så blir en uppgift till en pull request för hela körningsflödet.
Specifikation
- Omfattning
- Cachelagra lyckade användaruppslagningar per id i 60 sekunder.
- Utanför omfattningen
- Ändra inte den publika signaturen för getUser.
- Acceptanskriterier
- Två uppslagningar inom 60 sekunder anropar datakällan en gång.
ArkitektPlanerar hur den ska uppfyllas
UtvecklareBygger utifrån den
QAVerifierar varje kriterium
GranskareJämför pull request med den
Varför det extra steget behövs
En instruktion som "lägg till cachning i användarsökningen" har minst fyra rimliga implementationer och ingen definition av när arbetet är klart. En agent väljer en. Om den väljer din är en lyckträff.
Specifikationen gör det valet tydligt innan implementationen börjar, när det kostar minst att ändra sig.
Den ger också verifieringen något att testa mot. Utan acceptanskriterier reduceras frågan "fungerade det här?" till "går testerna fortfarande igenom?", vilket är en mycket svagare fråga.
Vad en specifikation innehåller
| Del | Vilken fråga den besvarar |
|---|---|
| Omfattning | Vad som ska ändras |
| Ingår inte | Vad som medvetet inte ska ändras, så att ändringen inte sväller |
| Acceptanskriterier | Hur vem som helst kan avgöra att det fungerade |
| Kontext | Tillämpliga begränsningar, konventioner och tidigare beslut |
Du kan läsa och redigera den på uppgiftens Specification fliken innan körningen börjar. För arbetsbeskrivningen och den kompletterande kontext som ingår i processen, se Beskriv vad du behöver.
Exempel: från kort beskrivning till testbar specifikation
Anta att den ursprungliga uppdragsbeskrivningen är:
Add caching to the user lookup so repeated requests are faster.Det beskriver det önskade resultatet, men lämnar viktiga val obesvarade. En användbar specifikation omvandlar dessa val till avgränsningar och kontroller:
Scope
- Cache successful user lookups by user id for 60 seconds.
- Invalidate the cached entry when the user record is updated.
Out of scope
- Do not cache failed lookups.
- Do not change the public signature of getUser.
Acceptance criteria
- Two lookups for the same user id within 60 seconds call the data source once.
- Updating that user invalidates the existing cache entry.
- A cache miss preserves the current result and error behavior.Nu kan planen välja en implementation, QA omvandla kriterierna till tester och granskaren jämföra pull request med det utlovade beteendet.
Dokumenterat exempel: Chrono City
I Coroids uppgift för Chrono City krävde acceptanskriterium 3 att 1985 års era skulle visas när den valdes. Den första versionen ändrade årtalet i etiketten men lämnade scenen som ett tomt lila fält. QA återskapade felet tre gånger i en webbläsare där appen kördes och skickade tillbaka uppgiften. I den andra cykeln verifierade QA stadssiluetten både med reglaget och med tangenten 3. Uppgiften nådde inte en pull request förrän alla 11 kriterier var uppfyllda. Läs om Chrono City-körningen för skärmbilderna, körsekvensen, den förflutna tiden och modellkostnaden.
Vad kännetecknar bra acceptanskriterier?
De måste kunna kontrolleras av någon som inte deltog i samtalet.
Svagt:
Caching works correctly and performance is improved.Starkt:
- Repeated lookups for the same user id within 60s hit the cache, verified
by a test asserting the data source is called once across two lookups.
- Cache entries are invalidated when the user record is updated.
- A cache miss behaves identically to today, including error handling.
- No change to the public signature of `getUser`.Den andra versionen talar om för utvecklingsagenten vad som ska byggas, för QA-agenten vad som ska testas och för dig vad du ska kontrollera i pull request. Den första lämnar alla dessa beslut öppna.
Avgränsningar är lika viktiga som kriterier
Den vanligaste orsaken till ett för omfattande pull request är inte att en agent går utanför sin uppdragsbeskrivning – utan att specifikationen aldrig angav var uppdraget slutade.
Om du inte vill att den omgivande modulen refaktoreras medan agenten arbetar där, ska du ange det. ”Ändra inte anropsställena” är en legitim och användbar avgränsning.
Vanliga misstag i specifikationer
| Misstag | Bättre tillvägagångssätt |
|---|---|
| Beskriva implementationen i stället för resultatet | Ange beteendet och begränsningarna och låt sedan planen välja implementationen |
| Använda ord som ”snabb”, ”säker” eller ”fungerar korrekt” | Ersätt dem med ett observerbart tröskelvärde, beteende eller test |
| Utelämna mål som inte ingår | Nämn angränsande kod, gränssnitt eller beteenden som måste förbli oförändrade |
| Kombinera orelaterade resultat | Dela upp arbetet så att en uppgift resulterar i ett enda granskningsbart pull request |
| Kopiera ett ärende utan att kontrollera antagandena | Lägg till den kontext och de beslut som repositoryt inte kan visa |
När du inte håller med om den
Redigera den. Specifikationen är ett arbetsdokument fram tills körningen börjar, och det är mycket billigare att korrigera den än att korrigera koden som annars skulle ha skapats utifrån den.
Om specifikationen visar att arbetet egentligen består av två delar, delar du upp det i två uppgifter. En uppgift bör resultera i ett enda pull request som en person kan granska vid ett och samma tillfälle.
Vad händer sedan?
För allt som är mer än en liten ändring blir specifikationen en plan. Se Uppgifter, planer, sprintar och körfält, som förklarar hur arbetet delas upp och godkänns innan koden skrivs.
Vanliga frågor
Är en specifikation samma sak som en teknisk design?
Nej. En specifikation definierar det resultat och de avgränsningar som krävs. En teknisk design eller implementationsplan förklarar arkitekturen och stegen som används för att nå resultatet.
Behöver varje ändring en lång specifikation?
Nej. En liten och entydig ändring kan behöva bara några avgränsningsrader och acceptanskriterier. Specifikationen ska undanröja meningsfull osäkerhet, inte skapa mer administration.
Vem ska godkänna specifikationen?
Den person som ansvarar för resultatet bör bekräfta att omfattningen och kriterierna motsvarar teamets behov. Tekniska granskare samt säkerhets- eller regelefterlevnadsansvariga kan delta när deras begränsningar påverkar resultatet.
Kan en specifikation ändras efter att arbetet har börjat?
Det går, men ändringen bör skapa en ny version och utlösa en granskning av den beroende planen och det pågående arbetet. Tysta scope-ändringar bryter beviskedjan mellan förfrågan och det levererade pull request.