Parte della difficoltà in termini di scrittura di un documento di specifiche da parte del cliente è che il cliente spesso non sa come tradurre le cose che il cliente desidera in una lingua che descriva effettivamente ciò di cui il cliente ha bisogno. Sebbene il cliente possa dire che desidera che un determinato comportamento esista in un sistema, in genere non è così interessato alle minuzie finché non ha visto, utilizzato e sperimentato il funzionamento del software in un modo che il cliente ritiene non corrisponda al suo esigenze.
Quando i clienti descrivono un processo aziendale, spesso lasciano fuori molte informazioni rilevanti. Spesso queste informazioni si riferiscono a cose su un processo che sono comunemente comprese all'interno del dominio particolare del cliente e che quindi sono date per scontate e spesso non trasmesse al programmatore. Altre volte, il cliente in realtà non sa come gestire tutte le condizioni al contorno all'interno di un sistema e sta cercando una guida per il programmatore. A volte è tutto un semplice caso di usabilità, con il cliente che pensa di voler lavorare in un modo, ma in seguito cambia idea quando diventa più chiaro che le cose dovrebbero funzionare diversamente.
Ok, quindi abbastanza di "relazioni con i clienti 101 per i programmatori". La domanda è se sia ancora utile che il cliente utilizzi un DSL leggibile dal punto di vista aziendale per definire come definire una specifica. Credo che, con la guida, la risposta sia un "sì" provvisorio, e dico provvisorio perché la domanda successiva che mi viene in mente è: perché un cliente dovrebbe creare un DSL quando è possibile che un programmatore ne definisca più facilmente uno che possa fornire a un cliente un linguaggio semplice ma ricco per definire come un sistema deve funzionare?
Quando hai fornito a un cliente un linguaggio per descrivere come vorrebbero che un sistema funzioni, finirai con delle affermazioni che dicono qualcosa sulla falsariga di:
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
Questo tipo di affermazione finisce per descrivere un requisito in modo molto chiaro, fornendo la forma generale che il cliente desidera sostanzialmente che il sistema assuma, o un altro modo di vederlo è che il cliente sta descrivendo quale sia il sistema. Se desideri che i tuoi clienti pensino un po 'di più alle cose, puoi quindi chiedere loro di descrivere le regole alle quali la funzione deve obbedire usando una serie di dichiarazioni simili forse a:
"Given 'some system state', When 'some action occurs', Then expect 'some result'
Ancora una volta descrizioni molto chiare, questa volta su comeil sistema dovrebbe comportarsi. Il fatto è che questo non sostituirà la necessità per uno sviluppatore di software di riempire tutti gli spazi vuoti e di prendere in giro ulteriori dettagli di cui il cliente può essere solo periferico. Mentre il programmatore può essere in grado di essere "addestrato" dal programmatore per descrivere caratteristiche e comportamenti in un formato adatto al programmatore, il cliente non avrà davvero le capacità o le conoscenze per generare casi di test significativi, né per fornire l'implementazione codice. Questo è stato il punto dell'articolo Martin Fowler cui l'OP ha fatto riferimento. Quindi sì, il software stesso non è scrivibile dal cliente, ma la descrizione del software sicuramente può - e IMHO dovrebbe - essere scritta dal cliente. Per quello che vale, non ho letto l'articolo di Fowler che diceva che il cliente non avrebbe dovuto
Sento che a volte i programmatori possono dimenticare che i nostri clienti sono generalmente molto intelligenti in termini di comprensione delle loro attività e dei loro processi, sicuramente molto meglio di noi. Quando non hanno un programmatore per dire loro come costruire un sistema software, i clienti generalmente ricorrono ad altri - forse meno efficienti - mezzi per risolvere i loro particolari problemi di gestione aziendale. Con questo intendo semplici database (pensa ad Access) o fogli di calcolo, o addirittura libri contabili scritti a mano, e con regole e procedure ben definite per gestire tali processi. Ciò che manca a molti clienti non è un mezzo per determinare come un sistema deve funzionare, ma piuttosto come dovrebbe essere costruito e, soprattutto, quanto efficacemente descrivere le regole comportamentali di un sistema alle persone chenon hanno le competenze per costruire realmente il sistema.
Se c'è davvero un consenso sulla mancanza di scrivibilità, vedresti un problema con uno strumento che, invece di iniziare con gli scenari e strumentarli, genererebbe scenari leggibili dal business dai test reali?
Penso che questo stia esaminando la questione nel modo sbagliato. Vedrei un grosso problema con uno strumento che genera documentazione dai test se quella documentazione fosse destinata a rappresentare una specifica in alcun modo. Per testare uno scenario, è necessario capirlo, pertanto lo scenario deve già esistere affinché sia possibile definire un test per esso. Se descrivi lo scenario in una sintassi BDD, lo hai già specificato e quindi puoi solo strumentare gli scenari dopo il fatto. Se invece avessi uno strumento che consentisse al cliente di descrivere un sistema in un bel DSL adatto alla programmazione, e se quello strumento potesse essere utilizzato per generare i modelli di codice che verrebbero utilizzati come suite di test, allora io ' d dire che ci sarebbe un grande valore in un simile strumento. Non vedrebbe il cliente allontanare i programmatori dall'equazione e contribuirebbe a ridurre lo sforzo richiesto per soddisfare i desideri del cliente e generare requisiti codificati in modo test in BDD, e forse renderebbe i desideri del cliente più facilmente comprensibili. Non sarebbe tuttavia un sostituto per avere a disposizione uno sviluppatore di software esperto per aiutare il cliente a separare le esigenze del cliente dalle sue esigenze.