Come posso coinvolgere maggiormente gli analisti di business in BDD?

Quello che ho finito è installare Visual Studio 2010 Express sui loro computer e configurare i modelli SpecFlow. Ho mostrato loro come aggiungere un file .feature. Abbiamo discusso di come dovrebbero essere scritte le caratteristiche e gli scenari e se ne sono andati.

Ho anche mostrato loro come eseguire i commit di base e spingere con TortoiseGit.

Parte del tuo lavoro di sviluppatore è di mappare i tuoi strumenti e le tue idee agli strumenti e alle idee che i tuoi stakeholder utilizzano. Il Domain-Driven Design (non il BDD) può certamente aiutare in questo senso, perché può aiutare a creare il linguaggio comune "ubiquitario" attraverso il quale voi e i vostri stakeholder potete comunicare.

Ma queste persone non hanno alcun interesse nella tua architettura di progettazione del software; sono interessati solo a risolvere i loro problemi dal loro punto di vista. Quindi devi essere in grado di comunicare le tue idee nella loro lingua, il che significa prendere i concetti in BDD e tradurli in strumenti e termini che capiscono e viceversa.

Non dovresti costringere gli analisti aziendali a utilizzare Visual Studio per far funzionare senza problemi il tuo processo BDD. Questo è uno strumento per gli sviluppatori, non per il business.

SpecFlow ha uno strumento da riga di comando che può generare i test richiesti in base ai file .feature. Ciò consentirebbe di creare uno script di compilazione che raccolga file .feature da qualche parte, generi i file .cs, li compili ed esegua i test. Se i tuoi analisti aziendali preferiscono usare Jira, allora dovresti creare uno strumento che estrae i file .feature di Jira, almeno se è pratico e possibile. Non conosco abbastanza Jira per dire se sia o meno pratico.

Ricorda che qualsiasi buona soluzione software dovrebbe essere basata sui processi e le esigenze dell'utente; non dovrebbe dettare nuovi processi per l'utente. E in questo caso, l'utente è l'analista di business.