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

11

Sono un po 'un sostenitore della metodologia Behavior Driven Development (aka BDD). Ho applicato BDD per un paio d'anni e ho adottato StoryQ come framework di scelta per lo sviluppo di applicazioni DotNet. Anche se sono stato test unitario per molti anni, e in precedenza avevo adottato 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 relativamente chiaro l'inglese nel mio codice, e poiché i miei test possono eseguire più asserzioni senza terminare il test a metà strada - ciò significa che posso vedere quali asserzioni specifiche passano / falliscono a prima vista 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 di entrambi i test e il codice di implementazione in modo più mirato, con il risultato che la mia produttività è cresciuta in modo significativo e che Riesco più facilmente a determinare dove si verifica un errore se si verifica un problema fino a raggiungere la build di integrazione a causa dell'output che si inserisce nei log di compilazione. Inoltre, la StoryQ api ha una bella sintassi fluente, facile da apprendere e che può essere applicata in un numero straordinario di modi, senza richiedere dipendenze esterne per poterla utilizzare.

Quindi con tutti questi vantaggi, si potrebbe pensare che sia facile introdurre il concetto al resto del team. Sfortunatamente, gli altri membri del team sono riluttanti a guardare StoryQ per valutarlo correttamente (per non parlare dell'idea di applicare BDD), e si sono convinti a provare a rimuovere un numero di elementi StoryQ dal nostro framework di testing core, anche sebbene originariamente supportassero l'uso di StoryQ e anche se il codice che desiderano rimuovere non ha alcun impatto su nessun'altra parte del nostro sistema di test. Fare così finirebbe per aumentare il mio carico di lavoro in modo significativo nel complesso e va davvero controcorrente, poiché sono convinto dall'esperienza pratica che è un modo migliore di lavorare in prima persona nel nostro particolare ambiente di lavoro, e può solo portare a maggiori miglioramenti nella qualità del nostro software, dato che ho trovato più facile rimanere con il primo test usando BDD. Per chiarire ulteriormente, la maggior parte dei test unitari tendono ad essere alquanto fragili e difficili da mantenere, un residuo di anni di test applicati male, in cui una riluttanza ad aderire a un processo guidato dai test ha visto gli sviluppatori ripiegare su vecchie abitudini e fai tutti i test alla fine del progetto (queste stesse persone sostengono di essere Agili!).

Quindi la domanda si riduce a quanto segue:

  1. Quali argomenti posso utilizzare per guidare veramente il punto a casa che sarebbe meglio per questo team usare StoryQ o almeno per adottare la metodologia BDD?
  2. Puoi indicarmi eventuali prove aneddotiche che posso utilizzare per supportare la mia argomentazione ad adottare BDD come metodo di scelta standard?
  3. Quali contro argomenti puoi pensare che potrebbe suggerire che il mio desiderio di incoraggiare la squadra ad adottare BDD potrebbe essere sbagliato? Sì, sono felice di essermi dimostrato sbagliato purché l'argomento sia valido.

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

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

Per coloro che sono interessati a maggiori dettagli, siamo una piccola squadra di 4 persone che lavorano su circa 5 grandi progetti. Il "processo pilota" per BDD ha funzionato inizialmente per circa 2 mesi, con un altro periodo successivo di circa 4 mesi. La squadra ha accettato che avrei dovuto continuare a lavorare in questo modo e che dovevo fare le loro prove. Sono stato BDD-ing da circa 2 anni da quando il processo è terminato, mentre gli altri sono diventati molto bravi a ridurre il problema. Piuttosto che forzare uno "scontro" sul problema, sto cercando dei modi per convincere la squadra a smettere di giocare alle spalle collettive e trovare il tempo per fare la loro parte.

    
posta S.Robins 26.03.2012 - 02:57
fonte

3 risposte

5

What arguments can I use to really drive the point home that it would be better to use StoryQ, or at the very least apply the BDD methodology?

"Il cliente lo desidera."

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

BDD è un processo collaborativo esterno che coinvolge più parti interessate. I vantaggi di BDD non sono solo gli sviluppatori a dedurre automaticamente il loro codice di test dai test di accettazione, ma si trovano anche nella cooperazione creativa tra tecnici e uomini d'affari per produrre specifiche valide e ben definite del comportamento previsto dal sistema.

Offrire ai clienti / analisti aziendali l'accesso a un'interfaccia in cui possono eseguire ogni specifica eseguibile, controllare il loro stato e vedere che la progressione nella loro implementazione è generalmente molto apprezzata.

C'è una presentazione di Dan North su come vendere BDD al business: link

    
risposta data 26.03.2012 - 17:26
fonte
5
  1. In una squadra riluttante ad adottare BDD, probabilmente non ci sono "argomenti" che puoi usare per "convertire" i tuoi colleghi in adozione su larga scala.

    Penso che il meglio che puoi fare sia convincerli a provarlo ("smoke test", "dry run", "progetto pilota") - specialmente se rendi perfettamente chiaro che tu sia " Lasciamo perdere l'idea se i risultati del test sono negativi.
  2. Il tuo approccio per trovare prove aneddotiche si adatta perfettamente all'idea di convincere la squadra a fare un tentativo. Per questo, cercherò semplicemente sul Web qualcosa come "Storia di successo dello sviluppo comportamentale" e sceglierò cosa mi sembra più facile da usare.
  3. Ci sono due argomenti contrari a cui posso pensare che potrebbero suggerire che il tuo desiderio di convertire gli sforzi del team in BDD potrebbe essere sbagliato.

    Nessuno di questi è particolarmente costruttivo, specialmente dal punto di vista di un "difensore del cambiamento", ma sfortunatamente probabilmente dovrai affrontare esattamente questa retorica di questo tipo ( BTDTGTTS ):
    • non puoi garantire che la produttività complessiva del team migliorerà
    • non puoi garantire che gli sforzi investiti nell'adozione di BDD forniscano un sostanziale ROI
    • il team stava facendo abbastanza bene senza BDD, il rischio di cambiare l'approccio attuale non è giustificato
    • Google (o Microsoft, o IBM - basta compilare il nome di qualsiasi "rispettabile" fornitore di software) stanno andando bene senza BDD, che "dimostra" che BDD non è necessario
    • gli approcci non BDD non hanno avuto una buona possibilità di test comparativo
    • 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 come quelli sopra elencati è stato eseguire una prova di prova limitata per una modifica proposta.

Lo stato di "testing limitato" essenzialmente invalida tre dei quattro argomenti sopra, eccetto uno su "rispettabile venditore", che potrebbe essere contrastato fornendo prove aneddotiche della storia di successo (probabilmente non saranno disponibili prove aneddotiche lavoro per un "big bang change" ma per test limitati è abbastanza buono)

Se il cambiamento è davvero utile e l'esecuzione del test è organizzata correttamente, noterai un cambiamento positivo nell'atteggiamento di squadra e di gestione, rendendo la transizione verso cambiamenti su vasta scala agevole e indolore.

Un altro vantaggio del test run limitato è che ti consente di chiarire e regolare i dettagli del processo target senza causare troppi problemi e con un minore rischio di "danno alla reputazione" all'idea. Ogni volta che ho partecipato a tali test runs , sono stato piacevolmente sorpreso di scoprire quanto fosse agevole passare all'adozione su larga scala con i dettagli più importanti impostati e chiariti nell'esecuzione di test.

    
risposta data 26.03.2012 - 10:15
fonte
-1

Potrebbe essere il momento di assumere la gestione. Se hai dato una prova e hai visto risultati solidi, ma il team sta rallentando, la gestione potrebbe dover essere coinvolta.

Questo è particolarmente vero se stanno danneggiando il membro più produttivo della squadra. Preparati per il contraccolpo. Puoi iniziare avvicinandoti al management e cercando di far smettere di farti sottoquotazione dal team eliminando i casi di test.

    
risposta data 27.03.2012 - 14:29
fonte

Leggi altre domande sui tag