Sviluppo guidato dalle specifiche in Jira
Sviluppo basato sulle specifiche significa redigere una specifica strutturata prima che un agente proceda a sviluppare, in modo che realizzi ciò che è corretto invece di una supposizione plausibile. In Jira, quella determinata specifica si trova nel ticket su cui stai già lavorando, quando contiene un intento reale: risultati, ambito, vincoli e criteri di accettazione. Un ticket può contenere la specifica completa per un task oppure una parte della specifica di una funzionalità più ampia suddivisa in più ticket.
Questa guida illustra cosa rende una specifica pronta per l'agente, perché è giusto che si trovi in un ticket e come scrivere la prima specifica. In breve, lo sviluppo guidato dalle specifiche in Jira ti offre tre vantaggi:
Un'unica origine di riferimento da cui l'agente attinge e rispetto a cui la persona addetta alla revisione esegue la verifica
Criteri di accettazione che definiscono il completamento sia per l'agente sia per la persona
Un minor numero di rilavorazioni, perché l'intento è definito prima che l'agente scriva una riga di codice
Che cos'è lo sviluppo guidato dalle specifiche?
Lo sviluppo guidato dalle specifiche è una pratica in cui viene redatta una specifica strutturata che definisce cosa creare e come viene misurato il successo, e l'agente la implementa, invece di procedere con supposizioni, a partire da un prompt di una sola riga.
La specifica diventa l'origine di riferimento. Guida il piano, lo sviluppo e il controllo, e in Jira tutti e tre avvengono nello stesso ticket. L'idea è precedente all'IA, perché è nata dalla progettazione delle API e dalle pratiche dei metodi formali, in cui viene definito il comportamento prima dello sviluppo.
La definizione continua a cambiare man mano che gli strumenti maturano, quindi considerala una pratica, non un formato di specifica fisso. Quello che rimane costante è il cambiamento fondamentale: definire il ticket prima che l'agente lo crei.
La differenza dipende da quando risolvi l'ambiguità. Il vibe coding la risolve dopo che il codice è stato scritto, lo sviluppo guidato dalle specifiche lo risolve prima.
Vibe coding: guidi l'agente attraverso i prompt e accetti ciò che restituisce, quindi l'ambito, i vincoli e i casi limite che presuppone emergono dopo lo sviluppo del codice.
Sviluppo guidato dalle specifiche: prima definisci l'intento, i vincoli e i criteri di accettazione, così l'agente si basa su una definizione invece che un'intuizione e la revisione effettua verifiche rispetto alla stessa definizione nel ticket in cui si trova.
Per il codice che deve resistere in una base di codice reale, un agente senza un contesto consolidato rischia di risolvere il ticket in modo troppo letterale e non cogliere il vincolo importante. È qui che inizia la rilavorazione.
Ci sono due aspetti che i prompt tendono a confondere: la specifica è ciò che crei, il piano è il modo in cui viene creato. Lo sviluppo guidato dalle specifiche definisce prima il cosa, poi lo usa come punto di partenza per costruire il come. È il passaggio che la modalità di pianificazione negli strumenti di codifica basati sull'IA spesso salta: definisce il come direttamente da un prompt, di solito senza alcuna specifica concordata alla base.
La modalità di pianificazione può fungere da specifica leggera, ma elabora il come a partire da un prompt sul momento, non da una specifica concordata che rimane associata al ticket.
Perché le specifiche sono importanti per la programmazione basata sull'IA
Quando la generazione di codice diventa economica, la parte difficile non è più scrivere codice, ma definire la cosa giusta da sviluppare. Per questo motivo è la specifica, e non il prompt, l'artefatto di maggiore impatto che produci.
Un prompt one-shot lascia le lacune all'agente, che le colma con supposizioni e produce codice che sembra corretto ma risolve il problema sbagliato. Una specifica si occupa prima di colmare queste lacune, così l'agente procede verso una definizione invece che verso un'ipotesi. In Jira, quella specifica è il ticket che il tuo team già pianifica, assegna e revisiona.
Cosa include una specifica che un agente usa come base?
Una specifica pronta per l'agente risponde alle domande che un buon ingegnere porrebbe prima di iniziare. In Jira, si trovano nel riepilogo, nella descrizione, nei requisiti collegati e nei criteri di accettazione del ticket. Gli elementi importanti sono sei:
Risultati: cosa deve ottenere la modifica, in termini verificabili da un revisore.
Ambito: cosa è incluso e, aspetto altrettanto importante, cosa è escluso.
Vincoli: i limiti da rispettare in termini di architettura, sicurezza e prestazioni.
Decisioni precedenti: il contesto è già stato definito, quindi l'agente non lo rimette in discussione.
Suddivisione del task: il ticket suddiviso in passaggi abbastanza piccoli da poter essere verificati.
Criteri di accettazione: la definizione verificabile di completato che viene usata come base dall'agente e per la revisione. In Jira risiedono nel ticket e una revisione del codice basata sull'IA può usarli per verificare la modifica prima che arrivi a una persona.
Come il ticket diventa la specifica in Jira
Un ticket ben strutturato può fungere da specifica di base per lo sviluppo e la revisione dell'agente. La specifica può anche trovarsi in un documento collegato, come succede in molti strumenti SDD. Jira la mantiene semplicemente dove il ticket è già in esecuzione. Il "livello di specifica" si ha in presenza dei sei elementi descritti sopra. Un ticket di una riga di correzione del bug di accesso non contiene questi sei elementi.
Mantenere la specifica nel ticket ha un vantaggio strutturale: si trova dove è già il ticket, quindi è più difficile da abbandonare rispetto a un file markdown in un repository che nessuno riapre. Questo non la rende in grado di gestirsi da sola, ma significa semplicemente che la specifica e il ticket si trovano sempre insieme.
Tutto procede insieme: riepilogo, descrizione, requisiti di Confluence collegati e criteri di accettazione si trovano in un'unica posizione che viene letta dall'agente e dal revisore.
Un file di repository, invece, è separato dal punto in cui i ticket vengono monitorati, revisionati e chiusi, quindi diventa obsoleto nel momento stesso in cui il piano cambia.
Lo stesso ticket diventa l'area di revisione al termine del lavoro dell'agente, il luogo in cui il tuo team si allinea su requisiti e domande aperte.
Jira definisce i piani con stime, task e requisiti chiari integrati.
Come Pianificatore Jira genera una specifica strutturata
Nella sezione precedente abbiamo illustrato le basi: trasformare un ticket in una specifica in autonomia. Pianificatore Jira è pensato per iniziative complesse che coinvolgono più team, in cui scrivere ogni specifica a mano non è una soluzione attuabile. Parte dall'iniziativa e la suddivide in ticket strutturati, ognuno con le proprie specifiche.
Pianificatore Jira è ciò che accelera il lavoro, non la base. Il metodo SDD base include un ticket ben strutturato e criteri di accettazione, e ogni team può adottarlo fin da subito. Pianificatore Jira accelera la parte più difficile del ticket: trasformare una richiesta complessa e ambigua in una specifica strutturata.
Per i progetti complessi, Pianificatore Jira si basa su Teamwork Graph, sulla base di codice, sulla cronologia di Jira e Confluence e sul contesto del team per definire i requisiti e generare una specifica tecnica strutturata in Confluence, pronta come base di partenza per uno sviluppatore o un agente di codifica. Un piano, tanti destinatari: leggibile da una persona, utile a un agente.
Che cosa fa:
Fornisce uno spazio condiviso su cui tu e il tuo team potete collaborare, allineandovi prima dell'esecuzione di un agente.
Recupera il contesto da tutti i tuoi ticket, così la specifica parte da ciò che il tuo team sa già, invece che da un prompt vuoto.
Produce una specifica che una persona può leggere chiaramente e un agente può analizzare con facilità, così lo stesso artefatto può essere usato per la revisione e l'esecuzione.
Mantiene la specifica in Confluence, collegata al ticket, così intenzioni e decisioni restano registrate.
Pianificatore Jira trasforma le idee approssimative in specifiche strutturate e pronte per gli agenti
Pianificatore Jira è disponibile in anteprima. Mettiti in lista d'attesa
Come scrivere la prima specifica pronta per gli agenti in Jira
Prendi un ticket e trasformalo manualmente in una specifica pronta per l'agente usando i sei elementi come checklist.
Inizia da un ticket. Registra il risultato e definisci i limiti e i vincoli nella descrizione, non solo un titolo.
Trasforma l'intento in una specifica strutturata. Questo è il vero ticket SDD. Trasforma il contesto precedente in risultati, ambito e vincoli per il ticket, così l'agente eredita una definizione.
Scrivi criteri di accettazione verificabili. Si tratta dei contratti usati come base per il lavoro dell'agente e per le verifiche del revisore. Spesso, la maggior parte dei criteri richiede alcuni passaggi prima di essere verificabile.
Assegnalo a un agente di codifica. Un ticket di livello di specifica fornisce all'agente informazioni sufficienti per implementare e aprire una richiesta pull collegata.
Rivedi la richiesta pull in base ai criteri, poi perfezionala. Migliora la precisione della specifica nei punti in cui l'agente ha fatto supposizioni e riutilizza il modello nel ticket successivo.
Domande frequenti sullo sviluppo guidato dalle specifiche
Per lo sviluppo guidato dalle specifiche serve Pianificatore Jira?
No. La base è un ticket ben strutturato con criteri di accettazione, che qualsiasi team può scrivere oggi. Per i ticket complessi, Pianificatore Jira aiuta ad accelerare il processo partendo da un piano di alto livello e un'iniziativa e suddividendo in ticket Jira strutturati, ciascuno con la propria specifica già inclusa così non devi scriverli tutti a mano.
Qual è la differenza tra una specifica e i criteri di accettazione?
La specifica definisce l'intera modifica: risultati, ambito, vincoli e contesto. I criteri di accettazione rappresentano una parte, cioè la definizione verificabile di completato che viene usata come base per lo sviluppo dall'agente e per la verifica dal revisore.
È sufficiente un prompt molto efficace?
Per ticket piccoli e reversibili, spesso sì. Per tutto ciò che è complesso o difficile da annullare, un prompt fa sì che l'agente formuli ipotesi su ciò che hai omesso. Una specifica elimina ogni dubbio.
Le specifiche devono trovarsi in un file del repository o in un ticket Jira?
Un ticket mantiene la specifica nel punto in cui il ticket viene monitorato, revisionato e chiuso. In questo modo è meno probabile che si allontani rispetto a un file markdown in un repository che nessuno riapre.
Lo sviluppo guidato dalle specifiche rallenta i team?
Aggiunge lavoro iniziale ed evita di doverlo ripetere in seguito. Nei ticket complessi, è un vantaggio netto. Per le correzioni banali, salta la specifica e vai direttamente al prompt.
Quando devo scrivere e quando devo saltare una specifica?
Scrivi una specifica per i ticket complessi, ad alto impatto o difficili da annullare, o per qualsiasi cosa presenti vincoli architetturali o di sicurezza reali. Saltala per le correzioni piccole e reversibili, dove è più veloce un prompt rapido.