Manager coraggiosi: to BDD or not to BDD?

Secondo la Treccani:

Coraggio = Forza d’animo nel sopportare con serenità e rassegnazione dolori fisici o morali

Audacia = È la qualità di chi ha molto coraggio e lo dimostra, esponendosi in imprese difficili o pericolose.

Spesso si assiste a comportamenti da parte di manager che sono poco coraggiosi. Possono essere motivati dalla situazione contingente, da ignoranza, da un atteggiamento prudente, dalla volontà di difendere una nicchia di comfort costruita nel tempo. Talvolta queste ragioni sono valide e derivano da un’analisi dei rischi. Ma altre volte le motivazioni sono deboli.

Comunque sia la ragione, le conseguenze a livello strategico di eccessiva prudenza possono essere gravi e raramente considerate nella loro interezza. Vediamone alcune, nel contesto delle pratiche di Behaviour-Driven Development. In questi casi serve un manager audace, o basta uno che sia solo un po’ coraggioso?

Talvolta mi capita di assistere a manifestazione di rifiuto, da parte di un manager, dell’adozione di pratiche BDD. Ad esempio, nel contesto dello sviluppo di un’applicazione software in un momento in cui alcune specifiche comportamentali sono incomplete, vaghe, e tali per cui diversi stakeholder di business hanno diverse opinioni su quali comportamenti sarebbe meglio che l’applicazione esibisse in quale circostanza.

Il manager in questione decide invece di continuare a svolgere l’analisi e il progetto nel modo standard in quell’azienda, facendo scrivere a più mani un documento (chiamato fantasiosamente “Analisi tecnica”) che delinea i possibili comportamenti attesi da parte dell’applicazione, spiegandone allo stesso tempo una possibile implementazione, ma tralascia ad esempio di menzionare le ragioni per cui si ritiene un comportamento migliore di un altro. 

Alcuni degli stakeholder si impegnano a contribuire, altri lo vorrebbero fare ma non ne hanno il tempo, altri fanno fatica a inserire i propri ragionamenti ed esigenze, e infine altri perdono subito interesse e non contribuiscono.

Per molte persone il BDD vuol solamente dire di formulare dei test sotto forma di frasi in italiano o inglese, prefissate dalle parole chiave GIVEN-WHEN-THEN (un linguaggio chiamato Gherkin o Cucumber). Questi scenari di test sono sì un perno importante del BDD, ma il BDD va ben al di là di questa formulazione.

Ad esempio, nel nostro esempio, l’adozione di BDD aiuta a sviscerare le ragioni di business, gli obiettivi aziendali o di business del prodotto, che sono importanti e pertinenti in quel momento. Questo aiuta in due modi. Primo, consente di valutare e decidere l’importanza relativa delle varie scelte tra i comportamenti possibili: sceglieremo i comportamenti che più supportano gli obiettivi di business che riteniamo più importanti. Secondo, l’individuare gli obiettivi di business consente di focalizzare il resto del lavoro, aiutando a scremare ulteriormente eventuali opzioni che saltano fuori nel tempo, escludendo quelle che mal si allineano con gli obiettivi.

A partire da questa prima analisi degli obiettivi di business, che va fatta ovviamente di concerto con i responsabili di business, da praticanti del BDD iniziamo a formulare le relative feature dell’applicazione che sono necessarie affinché essa possa alla fine esibire i comportamenti individuati. E per essere sicuri di aver capito bene come si articolano queste feature e che tipo di comportamento alla fine vogliamo ottenere, formuleremo una serie di scenari di test che le caratterizzano. Spesso gli scenari faranno riferimento a casi ed esempi concreti, seguendo la filosofia della “specification by example” secondo la quale esempi concreti e realistici sono estremamente utili per chiarire e far capire delle regole di business generali.

Questi scenari vengono usati come veicolo per stimolare discussioni e revisioni da parte di tutti gli stakeholder coinvolti. Gli scenari, dato che non fanno riferimento ad aspetti implementativi della soluzione e nemmeno a tecnologie, risultano di facile comprensione da parte del management.

Ma essi non solo non fanno riferimento a tecnologie. Scenari ben scritti evidenziano il linguaggio che gli specialisti di quel dominio userebbero per discutere dei comportamenti. Ad es. nel contesto di un’applicazione per l’e-banking, termini e frasi di questo linguaggio saranno “bonifico”, “disposizione”, “domiciliazione utenze”, “un bonifico viene archiviato”, “un bonifico può venir richiamato dall’archivio”, “il destinatario di un bonifico può venir aggiunto alla rubrica”", etc. E non si parla di chiamata REST o il “grid-widget” usato nell’interfaccia utente per mostrare dati in forma tabellare. 

Questo “glossario” di termini e frasi, oltre ad essere la base per la formulazione degli scenari, e quindi essere la ragione per cui gli scenari sono facilmente comprensibili, scrivibili e modificabili da tutti gli interessati, può venir sfruttato anche in altri modi. Quello più interessante e raramente seguito è di usarlo come punto di partenza per definire il “linguaggio ubiquo” in analisi e progettazione secondo il Domain-Driven Design - che porta alla progettazione di sistemi ad alta testabilità, manutenibilità ed estendibilità. 

In questo modo gli scenari sono comprensibili e pertinenti per il mondo del business e fanno riferimento a concetti importanti del dominio. Questo facilita il coinvolgimento del business e fa miracoli dal punto di vista di creare allineamento tra stakeholder di business e con gli sviluppatori.

Alla luce delle discussioni e revisioni degli scenari, seguendo la pratica BDD, essi vengono ripuliti e finalizzati fino al punto in cui uno sviluppatore li correda di codice che li rende eseguibili. Costituiscono quindi un insieme di test automatizzati.

Gli scenari possono essere anche associati alle feature (o user story) pianificate per lo sviluppo, sottoforma di corredo ai criteri di accettazione. In questo modo gli scenari possono venir usati per determinare in maniera oggettiva (essendo diventati dei test eseguibili) lo stato di avanzamento dello sviluppo delle feature: una certa feature sarà “fatta” solamente quando tutti gli scenari associati ai suoi criteri di accettazione vengono eseguiti con successo.

Un altro utilizzo degli scenari è di trattarli come base per la “living documentation”: documentazione facilmente comprensibile da vari stakeholder e automaticamente aggiornata e relativa ai comportamenti previsti della nostra applicazione. La documentazione in questo caso si manifesta in un “test book” (o varianti più interattive) che contiene i vari scenari.

Quindi il nostro manager poco coraggioso, nel rifiutare di adottare pratiche BDD, va incontro, insieme alla sua azienda, a queste importanti perdite, conseguenze strategiche negative:

• scarsa e vaga identificazione degli obiettivi aziendali da perseguire;
• scarso allineamento e focus rispetto agli obiettivi;
• scarso allineamento rispetto ai comportamenti desiderati e caratterizzati dagli scenari;
• più difficile avvio di iniziative di Domain-Driven Design, e realizzazione di codice e architetture di bassa qualità;
• assenza di test automatizzati per i vari comportamenti individuati;
• assenza della living documentation;
• incapacità di monitoraggio automatizzato dello stato di avanzamento dello sviluppo.

Non è che il BDD garantisca di evitare tutto ciò, ma è un buon modo per mettersi nella buona strada. Vale la pena per quel manager non essere coraggioso? Che “dolori fisici o morali” deve affrontare? Credo che di dolori fisici non ce ne siano proprio; ma per quanto riguarda quelli morali potremmo pensare a situazioni in cui il team non è abituato a svolgere BDD, o in cui gli stakeholder di business non lo sanno fare, e che quindi si utilizzi più tempo del previsto. Queste sono situazioni facilmente risolvibili con opportuna formazione e addestramento. Comunque chiaramente la gente non potrà mai imparare a fare una cosa nuova se non gli si concede abbastanza tempo per provare, sbagliare e migliorare.

Altre ragioni potrebbero essere una riluttanza da parte di stakeholder di business di partecipare con la necessaria costanza e intensità a questi incontri. O, peggio ancora, alla riluttanza del nostro manager a rilasciare una parte del controllo sulle persone che governa, dato che il BDD si fonda sul concetto di “conversazione” tra le parti coinvolte e sull’accettare il contributo di tutti, non solo degli esperti o degli analisti.

Serve essere un manager audace per sfruttare quelle leve strategiche evidenziate sopra? Non credo.

Pubblicato originariamente come Articolo LinkedIn.