Come avere successo ai seminari sulle specifiche BDD?

Oggi abbiamo cercato di introdurre BDD nel nostro processo di sviluppo software organizzando un seminario sulle specifiche.

Per questo workshop abbiamo avuto 2 sviluppatori, 1 tester e 1 analista aziendale. Il seminario è durato 1h30 e alla fine siamo riusciti a capire alcuni scenari BDD per la nostra nuova funzionalità. Abbiamo cercato di concentrarci sulla ricerca degli scenari che potevamo perdere e di quelli difficili.

Alla fine del seminario alcune persone erano effettivamente insoddisfatte del seminario.

Uno sviluppatore ha ritenuto di aver sprecato il suo tempo in quanto era abituato a distribuire gli scenari direttamente dall'analista aziendale e a rivederli con lei. L'analista di business non si sentiva sicuro della copertura dei nostri scenari (aveva la sensazione che avremmo potuto perdere altre cose importanti), ma soprattutto sentiva che questo workshop era anche una perdita di tempo in quanto avrebbe potuto capire da sola tutti questi scenari e in un periodo di tempo più breve .

Questo seminario sperimentale è durato 1h30 e alla fine non ci siamo sentiti abbastanza sicuri di ciò che abbiamo fatto ... sicuramente avremmo potuto dedicare più tempo a farlo, ma onestamente la maggior parte delle persone si esaurisce dopo 1h30 di brainstorming per recuperare gli affari regole dal cervello BA.

Quindi la mia domanda è come questo tipo di laboratorio può effettivamente funzionare. Nella teoria, dato che hai una nuova funzionalità da sviluppare, metti l'albero "amigos" (dev / tester / ba) nella stessa stanza in modo che possano collaborare insieme per scrivere i diversi requisiti per la nuova funzionalità usando esempi. Ne posso vedere tutti i benefici. Specialmente in termini di condivisione delle conoscenze e visione comune del prodotto / obiettivo finale / fatto.

La nostra conclusione da questo esperimento è stata che in realtà è più conveniente avere prima un BA a lavorare da solo sugli esempi e solo allora avere gli scenari da rivedere / rielaborare dai 3 "amigos". Avendo il BA a lavorare da solo, ci sentiamo davvero più sicuri di perdere meno cose + possiamo ancora rivedere gli scenari in seguito per ricontrollare. Non pensiamo che una semplice sessione di brainstorming / scoperta deliberata sia effettivamente sufficiente per coprire seriamente tutti i requisiti per una nuova funzionalità. L'analista aziendale è in realtà la persona migliore per quel tipo di cose. La cosa migliore che possiamo fare è rivedere ciò che ha scritto e vedere se poi abbiamo una comprensione comune (che potrebbe quindi portare a riscrivere alcuni dei suoi scenari o aggiungerne di nuovi che avrebbe potuto perdere).

Quindi, come puoi farlo funzionare efficacemente nella pratica ?

Se riesci a ricavare gli scenari dalla descrizione, il gioco è fatto.

Un anti-pattern che vedo spesso in BDD è che le persone sentono il bisogno di parlare e scrivere ogni scenario in dettaglio.

Alcuni scenari sono così ben compresi che è sufficiente derivarli da una breve descrizione. Ad esempio, se dico "Mi piacerebbe la funzione di accesso questa settimana", sapresti come dovrebbe essere. Sai che ci sono scenari per la password giusta, la password sbagliata, il nome utente sbagliato. Non abbiamo davvero bisogno di parlarne o catturarli in dettaglio.

Allo stesso modo, potrei dire: "Ecco il modulo per la registrazione degli utenti. Dobbiamo essere in grado di creare nuovi utenti, consentire loro di modificare i loro dettagli ed eliminare se stessi, tranne per il fatto che la cancellazione non dovrebbe effettivamente eliminare, dovrebbe semplicemente contrassegnarli come eliminati in modo che possano recuperare i loro account se lo desiderano ".

E puoi chiedere "Il recupero dell'account fa parte di questa funzione?"

"Se vuoi, possono essere due funzioni."

"Va bene, quindi abbiamo scenari per creare, leggere, aggiornare, eliminare; dovrebbe essere abbastanza facile. Parliamo del recupero dell'account; sembra più interessante."

In generale, se la descrizione del comportamento è sufficiente affinché il team di sviluppo tragga gli scenari, non è necessario parlarne. Puoi farlo in caso di dubbi, ma potresti voler solo catturare gli scenari che devi ricordare, se ne catturi uno.

Se non l'hai mai fatto prima o non sei sicuro, parla attraverso gli scenari.

Concentrati sulle aree insolite, in particolare se ci sono funzioni che non hai mai fatto prima. Questi sono posti fantastici per conversare e scrivere tutti gli esempi sorprendenti che emergono. Di solito ho due domande che faccio, basate sul modello BDD:

Dato un contesto
Quando si verifica un evento
Quindi dovrebbe verificarsi un risultato.

• Esiste un altro contesto che, per lo stesso evento, produce un risultato diverso?
• C'è qualche altro risultato che è anche importante?

Se tutti al tavolo sembrano annoiati, la funzione di cui stai parlando è probabilmente ben compresa. Spesso è sufficiente dire "Dovrebbe funzionare come X , ma con Y invece". Questo è ciò che Dan North chiama il modello Ginger Cake ; è come la ricetta della torta al cioccolato, ma con lo zenzero invece del cioccolato.

Anche se gli stakeholder aziendali sono in grado di ricavare lui stesso gli scenari, è davvero importante che il team di sviluppo sia in grado di parlare con lui, raccogliere e interiorizzare la sua lingua. Tale linguaggio viene quindi inserito nel codice, consentendo loro di avere conversazioni migliori in futuro e aiutando i nuovi arrivati ​​nel progetto a capire cosa sta succedendo. Se gli sviluppatori non riescono a parlare la lingua, non la useranno .

Se lo stakeholder o l'analista aziendale non vuole davvero passare il tempo a catturare cose nella sessione, preferirei che gli sviluppatori abbiano scritto gli scenari in collaborazione con i tester, quindi gli hanno chiesto di esaminarli. Ciò ha maggiori probabilità di scoprire incomprensioni rispetto al contrario.

A volte BDD non funziona.

Un'altra possibilità è che trovi uno scenario di cui gli stakeholder aziendali non sono sicuri. "Oh, non ci avevo pensato! Non ne sono sicuro." Invece di cercare di inchiodare il business e punire il business con certezza, potrebbe valere la pena abbandonare BDD a questo punto e provare qualcosa di semplice per ottenere un feedback e dare all'azienda qualcosa su cui possono iterare. Cambia facilmente e scrivi gli scenari una volta che avrai capito meglio cosa sta succedendo.

BDD fatto bene può davvero aiutare a scoprire luoghi di incertezza. Dal momento che ogni progetto la pena di fare ha qualche aspetto di esso che è nuovo e non è mai stato fatto prima, non v'è qualche incertezza in là, da qualche parte. Se ti concentri sull'utilizzo degli scenari per aiutare a scoprire deliberatamente l'ignoranza , imparerai più velocemente e l'apprendimento è di solito gran parte del tempo trascorso in un progetto.

Inoltre, ho scoperto che più team di sviluppo collaborano in questo modo, più l'azienda è pronta a fidarsi di loro con incertezza e più inizia a verificarsi l'innovazione. Le aziende innovative, per loro stessa natura, hanno molte incertezze nei loro progetti.

Ho scritto un post sul blog qualche tempo fa su Cynefin , che trovo davvero mi aiuta a capire dove le conversazioni saranno più efficaci. Se lo leggi e comprendi i quattro domini, ecco le regole che utilizzo:

• Le cose semplici e complicate (conosciute) sono spesso ben comprese e non è necessario parlare dettagliatamente degli scenari.

• Roba molto complessa (sconosciuta) non è affatto compresa. Puoi scoprirlo parlando attraverso gli scenari. La mancanza di certezza significa che BDD non funzionerà qui, quindi ripeti su qualcosa di facile da cambiare e ricevi invece un feedback rapido. Qualsiasi pratica che mantenga le tue opzioni, come i test AB, è ottima anche in questo spazio.

• BDD funziona brillantemente nello spazio tra (conoscibile) come meccanismo per trasmettere conoscenza e scoprire gli altri due spazi. Non è un martello e non tutto è un chiodo. In effetti, se riesci a concentrare il tempo trascorso conversando su qualcosa, non si tratta degli esempi che puoi trovare; si tratta di trovare gli esempi che non puoi .

La durata della riunione non è un tuo problema. Va bene che quelle riunioni durino a lungo. MA tutti dovrebbero uscirne con fiducia. Non è un tuo problema.

Suggerirei una breve riunione per discutere di un requisito. Pianifica un secondo incontro qualche giorno dopo, in modo che tutti sappiano che devono essere preparati entro quel momento.

Quindi il BA e il tester dovrebbero escogitare ciascuno i propri scenari, perché entrambi guardano al software in modi molto diversi. Invitali a scriverli sulle carte e incollarli tutti su una lavagna da qualche parte, almeno un giorno prima del secondo incontro, lasciare che tutti guardino nel loro tempo libero e ci pensino su. Butta via tutti i duplicati, attacca tutti gli scenari che non sono stati considerati.

Non gettare via nulla con cui non sei d'accordo, ma contrassegnalo come controverso. Se una conversazione molto breve con la persona che l'ha scritta ti aiuterà, fallo, ma soprattutto salvalo.

POI organizza la tua riunione di pianificazione / progettazione. Avere una solida agenda per quell'incontro (inizia con il mazzo di carte, metti quelle controverse in cima) e non permettere che vaghi fuori pista. Assicurati di uscire da quell'incontro con tutti i punti di contesa risolti.

Assicurati sempre che tutti in una riunione siano preparati per l'argomento di quella riunione!

Non usare mai un incontro per "fare brainstorming" insieme. Spreca il tempo di tutti.

Ricetta generale per incontri efficaci:

• chiedi a qualcuno di preparare gli argomenti da discutere
• imporre a tutti i partecipanti di aver studiato (e non solo letto) tali elementi
• raccogliere commenti in anticipo e richiedere a tutti i partecipanti di averli studiati (non solo di leggerli)
• tenere la riunione per prendere decisioni

Informazioni sui reclami ...

Cominciamo con questi:

Uno sviluppatore ha ritenuto di aver sprecato il suo tempo in quanto era abituato a distribuire gli scenari direttamente dall'analista aziendale e a rivederli con lei.

È quello che stava facendo in officina. Quindi mi sembra una scusa lunatica e cattiva. Sospetto che a questo sviluppatore non piaccia proprio (o entrambi) il controllo del workshop e i suoi vincoli di pianificazione.

L'analista aziendale non si sentiva sicuro della copertura del nostro scenario (aveva la sensazione che avremmo potuto perdere altre cose importanti)

In che modo è diverso da quando lo fa dalla sua parte e lo ha rivisto da uno sviluppatore, a parte il fatto che più persone lo hanno visto? Sospetto che questo sia solo il risultato di un seminario forse un po 'caotico. Avrai la certezza di avere abbastanza test implementandoli e integrandoli. Non puoi mai essere sicuro di aver trovato tutti i bug e, quando si tratta di copertura, il modo migliore sarebbe quello di tracciarli nelle storie degli utenti.

ma soprattutto è sembrato che questo seminario fosse anche una perdita di tempo in quanto avrebbe potuto capire tutti questi scenari da sola e in un periodo di tempo più breve.

Sì, e da solo, nel suo giardino recintato e senza condividere conoscenze. Considerando che in questo modo i seminari futuri potrebbero essere più produttivi in ​​quanto tutti i partecipanti hanno acquisito una piccola conoscenza su come affrontare queste cose.

Forse l'incontro è stato lento questa volta, non significa che lo sarà sempre. E come personale esterno, avrei ricevuto un po 'di formazione per ottenere questo risultato, più sicurezza che la copertura fosse migliore in un seminario con 3 partecipanti con mentalità diverse che con un singolo dittatore.

Inoltre, se c'era già la necessità per uno sviluppatore di rivedere questi scenari con lei, sono abbastanza sicuro che il avanti e indietro sia molto più veloce ed efficiente in officina rispetto all'uso del "Faccio le mie cose da solo e do cose a tu, lo rivedi da solo e torni da me e facciamolo di nuovo "approccio.

suggerimenti

• Sii positivo e sottolinea che se il processo è corretto, riuscirai a migliorarlo.

• Prova a semplificare il seminario e tienilo in pista.

• Forse dare un po 'di spazio all'analisi del "lupo solitario", avviando il seminario con tutti coloro che progettano alcuni scenari per conto proprio (ancora meglio, prima del seminario), quindi triage e uniscili.

E se non pensi che sia necessario fare quel brainstorming, va bene: fai in modo che il BA lavori da solo, ma almeno fai la revisione come workshop. I più bulbi oculari il meglio, per citare Eric S. Raymond 's Legge di Linus' :

Given enough eyeballs, all bugs are shallow.

Hai già delle risposte piuttosto buone qui, quindi mi concentrerò su un piccolo aspetto che finora è stato trascurato. Il ruolo di ciascuno dei tre Amigo dovrebbe essere in grado di svolgere la sessione. Ognuno di essi offre valore in modi diversi, ciascuno comprende un diverso insieme di vincoli.

In generale, la BA dovrebbe essere in grado di portare il principale percorso felice alla sessione, dovrebbe anche essere in grado di fornire i principali scenari di fallimento dal punto di vista aziendale. L'esperienza del test dovrebbe essere in grado di identificare casi limite e scenari aggiuntivi necessari per dimostrare che il sistema funziona in tutte le circostanze. Il compito dello sviluppatore non è davvero quello di aggiungere scenari, anche se spesso lo faranno per guasti tecnici, anche il loro lavoro garantisce la piena comprensione dei requisiti in modo da trasmettere implicazioni e implementare il requisito con la minima comunicazione aggiuntiva.