Alcuni clienti utilizzano termini della lingua del dominio in modo intercambiabile e non corretto. Ciò, in diverse occasioni, ha portato all'implementazione di una funzionalità in un modo che non era desiderato dal cliente. Esistono tecniche che possono essere utilizzate per far rispettare l'uso corretto dei termini? Esistono tecniche che possono essere utilizzate per impedire a qualcuno di passare i requisiti del "pacchetto di sigarette" a uno sviluppatore?
Il modo migliore per trovare un terreno / una lingua comune con gli stakeholder è scrivere i requisiti. Questo processo dovrebbe essere iterativo, quindi niente di sbagliato se qualcosa è stato scritto in modo errato.
come una delle opzioni - usa la tecnica di specifica dei requisiti di Tom Gilb.
Trovo che se mi sto confondendo su ciò che è effettivamente desiderato, o se sospetto che non stiamo usando le stesse parole nello stesso modo, discutere di esempi specifici insieme è il modo più rapido ed efficace per scoprire che tu avere idee diverse (Non posso dirti quante volte sono stato seduto in una riunione, e tutti sono convinti di essere d'accordo - e poi qualcuno descrive un esempio specifico, e improvvisamente metà della stanza annuisce si, si, è così, e l'altra metà sta andando "aspetta un minuto, vuoi cosa?").
Naturalmente, questo è più facile se ti trovi nella stessa stanza quando i requisiti sul "dorso di un pacchetto di sigarette" vengono consegnati e (a mio avviso) più facile se stai lavorando in modo iterativo e chiarificando i piccoli numeri dei requisiti alla volta, ma ho usato questo in un ambiente a cascata durante la revisione dei requisiti - i miei commenti di revisione includevano solo esempi.
Come tester, tendo a pensare immediatamente a esempi concreti, sia in un percorso felice che in casi limite. Se sei un programmatore, potrebbe essere un buon approccio per coinvolgere un tester nella conversazione con il cliente - entrambi penserai a diversi esempi, e ognuno potrebbe rivelare qualche idea sbagliata che il cliente ha di ciò che stai pianificando implementare, o cosa fa attualmente il sistema. Ognuno ha un modello mentale del sistema - è probabile che il cliente sia meno esperto di un programmatore o di un tester nel descrivere quale sia il suo modello mentale, quindi avvicinarsi a questo discutendo esempi specifici ti dà una serie di test di accettazione e aiuta per supportarli nello spiegare cosa vogliono veramente.
Un altro buon approccio è quello di assicurarti di non cadere nella pratica di usare termini completamente diversi all'interno del team tecnico: in una società in cui ho lavorato, questa pratica era endemica, e mi ha fatto impazzire - il mio monitor era pepato con pochi post per ogni progetto con traduzioni business to tech "nome commerciale: X, nome tecnico: Y." Inoltre, ha spesso portato a problemi del tipo che descrivi in quanto il significato di ciascun termine andrebbe alla deriva nel tempo. Come tester, ho sempre guardato con particolare attenzione i problemi di integrazione in aree in cui sapevo che c'erano termini diversi, perché sapevo che era probabile che ogni team di sviluppo avrebbe avuto un'interpretazione leggermente (ma critica) diversa.
Queste sono cose che ho sempre cercato di fare in modo informale come individuo nei progetti, ma dovresti dare un'occhiata al lavoro di Gojko Adzic se vuoi sapere come le persone implementano questo in modo più formale come parte del modo in cui eseguono i progetti. Controlla il seguente link al blog: consiglierei anche i suoi due libri, Bridging the Communication Gap e Specification by Example:
Non cercare di "far rispettare" nulla. Come analista dei requisiti, è il tuo lavoro a dare un senso a ciò che loro stanno dicendo, non viceversa.
Sicuramente prenditi del tempo per spiegare il tuo modello a loro, e se usano una terminologia errata in una riunione (" blah blah warehouse") allora ripeti il loro - educatamente - come se avessero usato la terminologia corretta (" blah blah inventario"). Nella maggior parte dei casi prenderà nella tua lingua, purché tu sia coerente con il suo uso.
Tuttavia, devi in definitiva lasciare che i clienti parlino nella loro lingua, altrimenti creerai una situazione contraddittoria e rallenterai l'intero processo di analisi.
Chiarifica i termini necessari durante le sessioni live e invia i deliverable finali scritti nella tua lingua per la revisione (di solito con un glossario di qualche tipo). Il tuo obiettivo non è quello di calzare le scarpe nel tuo modo di pensare, è semplicemente capire come fanno affari e implementare / ottimizzare dove appropriato.
Solo un'altra cosa rapida:
Are there any techniques that can be used to prevent someone from handing "back of a cigarette packet" requirements to a developer?
Se hai clienti che inviano eventuali requisiti direttamente a uno sviluppatore, allora hai un problema nel tuo team o nella struttura organizzativa. Non sono sicuro che volevi dire letteralmente, quindi ti prego di perdonarmi se ho frainteso, ma i requisiti dovrebbero passare attraverso un analista dei requisiti o un analista aziendale, il cui mandato esclusivo è quello di tradurre tra i domini aziendali e di sistema.
Se hai una manciata di sviluppatori che sono tutti molto bravi in questo, allora, nessun problema - ma come probabilmente stai iniziando a notare, questo non si adatta troppo bene.
Leggi altre domande sui tag requirements communication specifications