Quali argomenti posso usare per "vendere" il concetto BDD a un team riluttante ad adottarlo?

Sono un po 'un sostenitore vocale della metodologia di sviluppo guidato dal comportamento (aka BDD). Sto applicando BDD da un paio d'anni e ho adottato StoryQ come framework di mia scelta nello sviluppo di applicazioni DotNet. Anche se ho testato le unità per molti anni e in precedenza mi ero spostato su un approccio test-first, ho scoperto che ottengo molto più valore dall'uso di un framework BDD, perché i miei test catturano l'intento dei requisiti in modo relativamente chiaro inglese nel mio codice e poiché i miei test possono eseguire più asserzioni senza terminare il test a metà strada, il che significa che posso vedere quali asserzioni specifiche passano / falliscono a colpo d'occhio senza eseguire il debug per dimostrarlo.

Questa è stata davvero la punta dell'iceberg per me, poiché ho anche notato che sono in grado di eseguire il debug del codice di test e di implementazione in un modo più mirato, con il risultato che la mia produttività è cresciuta significativamente e che posso più determinare facilmente dove si verifica un errore se si verifica un problema per arrivare fino alla build di integrazione a causa dell'output che si fa strada nei log di build. Inoltre, l'API StoryQ ha una bella sintassi fluida che è facile da imparare e che può essere applicata in un numero straordinario di modi, che non richiede dipendenze esterne per usarlo.

Quindi, con tutti questi vantaggi, penseresti facile introdurre il concetto al resto della squadra. Sfortunatamente, gli altri membri del team sono riluttanti a guardare anche StoryQ per valutarlo correttamente (figuriamoci per intrattenere l'idea di applicare BDD), e si sono convinti l'un l'altro a provare a rimuovere un numero di elementi StoryQ dal nostro framework di test core, anche sebbene originariamente supportassero l'uso di StoryQ, e anche se il codice che desiderano rimuovere non influisce su nessun'altra parte del nostro sistema di test. Farlo finirebbe per aumentare in modo significativo il mio carico di lavoro nel complesso e andare davvero controcorrente, poiché sono convinto, attraverso l'esperienza pratica, che è un modo migliore di lavorare in modo test-first nel nostro particolare ambiente di lavoro e può solo portare a una maggiore miglioramenti nella qualità del nostro software, dato che ho trovato più facile attenersi al test prima usando BDD. Per chiarire ulteriormente, la maggior parte dei test unitari che abbiamo tende ad essere piuttosto fragili e difficili da mantenere, una sospensione da anni di test poco applicati in cui una riluttanza a attenersi a un processo guidato dai test ha visto gli sviluppatori ricadere su vecchie abitudini e fare tutti i test alla fine del progetto (queste stesse persone dichiarano di essere Agili!).

Quindi la domanda si riduce davvero a quanto segue:

1. Quali argomenti posso usare per portare davvero a punto il fatto che sarebbe meglio per questo team usare StoryQ o almeno adottare la metodologia BDD?
2. Potete indicarmi eventuali prove aneddotiche che posso usare per supportare la mia tesi di adottare BDD come nostro metodo standard di scelta?
3. Quali contro argomenti puoi pensare che potrebbero suggerire che il mio desiderio di incoraggiare il team ad adottare BDD potrebbe essere un errore? Sì, sono felice di essere smentito, a condizione che l'argomento sia valido.

NOTA : non sto sostenendo di riscrivere i nostri test nella loro interezza, ma piuttosto di iniziare semplicemente a lavorare in modo diverso per tutti i futuri lavori di test, e preferibilmente nel modo in cui coinvolgiamo i nostri clienti.

E per quelli di voi che desiderano saperne di più sul BDD, possono essere utili i seguenti collegamenti:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Per chi è interessato a maggiori dettagli, siamo un piccolo gruppo di 4 persone che lavora a circa 5 grandi progetti. Il "processo pilota" per BDD è durato inizialmente per circa 2 mesi, seguiti da un altro periodo di circa 4 mesi. Il team ha accettato che avrei dovuto continuare a lavorare in questo modo e dovevo fare le loro prove. Sono in BDD da circa 2 anni dalla fine del processo, mentre gli altri sono diventati molto bravi a evitare il problema. Piuttosto che forzare un "confronto" sulla questione, sto cercando modi per convincere delicatamente la squadra a togliersi le spalle collettive e trovare il tempo di fare la propria parte.}

Quali argomenti posso usare per portare davvero a punto il fatto che sarebbe meglio usare StoryQ o almeno applicare la metodologia BDD?

"Il cliente lo vuole."

IMO vuoi vendere BDD ai tuoi clienti / esperti di dominio almeno tanto quanto al team di sviluppo.

BDD è un processo di collaborazione esterna in cui sono coinvolti più stakeholder. I vantaggi di BDD non sono solo per gli sviluppatori di dedurre automaticamente il loro codice di test dai test di accettazione, ma si trovano anche nella cooperazione creativa che si svolge tra tecnici e uomini d'affari per produrre preziose e ben definite specifiche del comportamento previsto del sistema.

Dare ai clienti / analisti aziendali l'accesso a un'interfaccia in cui possono eseguire ogni specifica eseguibile, controllare il loro stato e vedere i progressi nella loro implementazione è generalmente molto apprezzato.

C'è una presentazione di Dan North su come vendere BDD all'azienda: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. In una squadra riluttante ad adottare BDD, probabilmente non ci sono "argomenti" che puoi usare per "convertire" i tuoi colleghi in adozione su vasta scala.
    
   Penso che il meglio che puoi fare sia convincerli a provarlo ("test del fumo", "corsa a secco", "progetto pilota") - specialmente se chiarisci perfettamente che abbandonerai l'idea se i risultati del test sono negativi.
2. Il tuo approccio per trovare prove aneddotiche si adatta perfettamente all'idea di convincere il team a provarlo. Per questo, vorrei semplicemente cercare sul web qualcosa come "Storia di successo dello sviluppo guidato dal comportamento" e scegliere ciò che mi sembra più facile da usare.
3. Ci sono due argomenti contrari che posso pensare che potrebbero suggerire che il tuo desiderio di convertire gli sforzi del team in BDD potrebbe essere in errore.
    
   Nessuno di questi è particolarmente costruttivo, soprattutto dal punto di vista di un "difensore del cambiamento", ma sfortunatamente probabilmente dovrai affrontare esattamente questa gentile retorica ( BTDTGTTS ):
    
   • non puoi garantire che la produttività complessiva del team migliorerà
   • non puoi garantire che gli sforzi investiti nell'adozione del BDD generino un ROI sostanziale
   • la squadra stava facendo abbastanza bene senza BDD, il rischio di cambiare l'approccio attuale non è giustificato
   • Google (o Microsoft o IBM - basta inserire il nome di qualunque fornitore di software "rispettabile") vada bene senza BDD, il che "prova" che BDD non è necessario
   • Gli approcci non BDD non hanno avuto una buona possibilità nei test comparativi
   • BDD potrebbe essere generalmente OK ma per questo e quel modulo / progetto non è applicabile

Secondo la mia esperienza, il modo meno doloroso per affrontare argomenti contrari come quelli sopra elencati è stato quello di eseguire un test controllato limitato per una modifica proposta.

Lo stato di "test limitati" sostanzialmente invalida tre dei quattro argomenti sopra, tranne uno su "fornitore rispettabile", che potrebbe essere contrastato fornendo prove aneddotiche di storie di successo (prove aneddotiche probabilmente non funzioneranno per un "cambiamento del big bang" ma per test limitato è abbastanza buono).

Se il cambiamento è davvero utile e la corsa di prova è organizzata correttamente, noterai un cambiamento positivo nell'atteggiamento di squadra e gestione, rendendo la transizione al cambiamento su larga scala regolare e indolore.

Un altro vantaggio dell'esecuzione di test limitata è che consente di chiarire e regolare i dettagli del processo di destinazione senza causare troppi problemi e con un rischio inferiore di "danno alla reputazione" dell'idea. Ogni volta che ho partecipato a tali esecuzioni di test , sono stato piacevolmente sorpreso di scoprire quanto sia stato facile passare all'adozione su larga scala avendo i dettagli più importanti impostati e chiariti nell'esecuzione del test.

Potrebbe essere il momento di assumere la gestione. Se hai provato e visto risultati concreti, ma il team è in difficoltà, potrebbe essere necessario coinvolgere la direzione.

Ciò è particolarmente vero se stanno danneggiando il membro del team più produttivo delle aziende. Preparati al gioco. Puoi iniziare avvicinandoti alla direzione e cercando di far smettere di sottovalutare il team eliminando i casi di test.