Dimentica un momento della "parola d'ordine BDD" e parliamo di ciò che abbiamo chiamato negli ultimi decenni: specifiche funzionali . Se pensi che le specifiche che ottieni dal tuo PO non siano abbastanza dettagliate, scrivi le parti mancanti da solo. Questo ti dà un sacco di spazio per la discussione creativa, prima di iniziare effettivamente a programmare, ma ti aiuterà anche a ricordare quali decisioni hai preso, ad esempio, una settimana fa. Può anche aiutarti a pianificare quali test dovrai scrivere. Questo ti lascia anche spazio per correggere errori o incongruenze che potresti rilevare nelle tue "specifiche dettagliate" quando stai implementando le funzionalità correlate (magari con alcuni prototipi prima). Quindi il fatto che stai scrivendo alcune cose prima di iniziare a scrivere il codice non ha nulla a che fare con nessun "modello a cascata".
Fai attenzione a manti pragmatico e non immergerti più nei dettagli perché la tua squadra ha bisogno di lavorare in modo efficace. Per trovare il giusto equilibrio, probabilmente dovrai raccogliere un po 'di esperienza facendolo. E se pensi che il "tipo BDD" della scrittura spec è lo strumento giusto per te e il tuo team, provalo. Ma attenzione, BDD è un modo un po 'formale di scrivere specifiche, che ha un alto rischio di diventare non pragmatico. Se hai l'impressione che ostacolerà la tua creatività, non usarla.
Joel Spolsky ha scritto una serie in quattro parti sulle specifiche del software, perché ne hai bisogno e come scriverle in modo indolore, qui è il link alla prima parte , troverai anche link alle altre parti. Sebbene abbia più di 10 anni (molto più vecchio del termine BDD), consiglio vivamente di leggerlo.