BDD basato su requisiti di 1-liner

4

Nel nostro team, il proprietario del prodotto ci fornisce solo un riepilogo 1-liner. Gli sviluppatori quindi presentano un PoC , che il proprietario del prodotto esamina e ripete il ciclo.

La sfida qui è di 2 volte:

  1. Ora: dobbiamo creare i PoC al più presto, in modo che possano essere rivisti
  2. Gli sviluppatori stanno effettivamente definendo l'aspetto e il funzionamento del prodotto: un sacco di UI PoC e lo sviluppo di alcuni controller per eseguirne il backup. Ma il BDD non si inserisce nel processo "creativo" di previsione del prodotto. In genere, BDD richiede di prendere una specifica del prodotto e quindi codificarla utilizzando Jasmine ecc.

Qualche esperto di BDD può suggerire un modo per fondere il processo di pensiero creativo con BDD?

    
posta user90766 04.09.2014 - 06:00
fonte

2 risposte

8

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.

    
risposta data 04.09.2014 - 08:04
fonte
0

Ho intenzione di parcheggiare il primo punto, se posso. Se il risultato finale è altamente auspicabile e produrrà un beneficio tangibile, sarà naturalmente un clamore che venga consegnato rapidamente.

Il secondo punto mi interessa. A mio parere, se l'azienda ha il requisito che un'interfaccia si comporti in un certo modo, anche questo dovrebbe rientrare nel processo data-when-then di BDD.

Tuttavia, mi sembra che non siano sicuri di ciò che realmente vogliono finché non lo vedono, quindi sarei incline a separare questo dal resto dello sviluppo in modo che possa essere prodotto separatamente. Quindi, una volta che l'azienda è felice con l'interfaccia, collegala alla consegna principale e prova come al solito.

    
risposta data 04.09.2014 - 14:12
fonte

Leggi altre domande sui tag