Test driven vs Requisiti aziendali in costante cambiamento

La tua domanda sembra suggerire che il TDD è legato ai cicli di vita dello sviluppo. Non sono sicuro di essere d'accordo.

La risposta a requisiti flessibili e mutevoli è lo sviluppo iterativo. TDD non ha nulla da dire su questo, o sui programmi software; è uno strumento per lo sviluppo di software in base a qualsiasi esigenza e pianificazione. Se i requisiti cambiano, cambia anche il software. Questo vale anche per i test unitari.

Il TDD non sviluppa requisiti, anche se alcuni proponenti lo suggeriscono. Piuttosto, i requisiti guidano i test delle unità, che a loro volta guidano il codice che viene scritto. Non si sviluppa un'architettura dai test, né si sviluppano requisiti con i test. Invece, i test sono il risultato dell'architettura e dei requisiti designati.

Se i requisiti cambiano al livello atomico (metodo / unit test) dello sviluppo del software, allora suggerirei che i tuoi requisiti siano troppo granulari. I requisiti dovrebbero specificare quali il software fa, non come lo fa. Il modo in cui il software soddisfa i requisiti è il dominio e la responsabilità degli sviluppatori di software, non i principali stakeholder.

Per dirla in un altro modo, non dico al cliente o al proprietario dell'azienda come gestire la sua azienda, e lui non mi dice come progettare le mie lezioni.

Cambiare i requisiti è una cosa normale, ma quando cambiano ogni giorno e cambiano i requisiti nel mezzo di uno sprint, questo non è un ambiente favorevole al software sviluppato in modo significativo e qualitativo. In altre parole, TDD è l'ultimo dei tuoi problemi qui, sono più fondamentali.

Hai menzionato gli sprint, il che significa che stai eseguendo una sorta di sviluppo Agile, che è una buona cosa. Gestire lo sviluppo in brevi sprint rapidi funziona bene su progetti per quando le priorità e i requisiti sono volatili e potrebbero cambiare nel bel mezzo del progetto. Il problema serio è che hai esigenze che cambiano drasticamente nello sviluppo e nei team di test nel bel mezzo di uno sprint.

Le priorità dello sprint non dovrebbero cambiare una volta iniziato lo sprint. Lo sprint dovrebbe essere un accordo tra le parti interessate e il team di sviluppo che le seguenti funzionalità e storie utente concordate verranno consegnate e testate entro una data specifica. Le parti interessate non mantengono la loro parte dell'accordo quando iniziano a cambiare le loro aspettative per lo sprint dopo lo sviluppo.

Quindi gli stakeholder non stavano facendo attenzione o pensavano a quello che stavano chiedendo, quindi cambierebbero le loro aspettative immediatamente. Gli sviluppatori hanno quindi il lusso di spingere la data di consegna per le funzionalità? Spesso no. Nel migliore dei casi le parti interessate sono state negligenti o incompetenti e gli sviluppatori pagano il prezzo negli straordinari per soddisfare comunque la data. A volte anche gli stakeholder fanno questo consapevolmente sapendo di poter ottenere più lavoro dai loro sviluppatori.

Ciò che dovrebbe accadere onestamente quando i requisiti fondamentali cambiano al punto in cui il lavoro corrente per lo sprint sarebbe inutile è interrompere immediatamente lo sviluppo dello sprint fino a quando un nuovo sprint può essere pianificato in base ai nuovi requisiti. Non c'è sicuramente alcun motivo per continuare a sviluppare software per la prossima settimana e mezza che l'azienda ti ha già detto che in ogni caso non sarebbe stato utile a tutti.

Ciò che sta accadendo in realtà è che gli stakeholder aziendali stanno fallendo il team di sviluppo non mantenendo o rispettando l'impegno di sprint. Dimostrano o la completa mancanza di competenza nel determinare ciò che vogliono nel software o hanno una completa mancanza di rispetto per il team di sviluppo e come viene prodotto il software di qualità.

L'unico modo in cui gruppi di aziende come questo guadagnano rispetto per come funziona davvero lo sviluppo del software è assumere una società di consulenza esterna o un fornitore di software per sviluppare software per loro e pagare con lo sprint. Una volta che perdono soldi per pochi sprint di sviluppo che non possono utilizzare, inizieranno ad apprezzare l'importanza di mantenere il loro impegno come stakeholder e di essere molto attenti e specifici con le loro caratteristiche e requisiti.

Senza entrare in una specifica terminologia agile, sembra che il problema fondamentale sia la mancanza di comprensione e / o impegno nei confronti della responsabilità del cliente durante l'iterazione: una volta selezionato l'insieme di elementi implementabili (dal cliente, concordato dagli sviluppatori ) per un'iterazione, il cliente accetta di non cambiare idea fino alla fine dell'iterazione.

Questo dà agli sviluppatori un obiettivo stazionario per un breve periodo.

Se i requisiti sono così instabili da non poter sopravvivere un giorno da soli, il progetto presenta problemi ben oltre la metodologia ... In tal caso, torna agli obiettivi del progetto e riconsidera le funzionalità proposte.

I don't think the rest of the business is going to help because they have no sense of development life cycles, and requirements get changed all the time within a single sprint.

Una cosa che generalmente le aziende ascoltano è tutto ciò che ha un impatto sul budget. Se i requisiti in continua evoluzione sono stati fatti in modo frivolo, allora si vorrà creare un argomento con esempi dettagliati per mostrare come tale cambiamento influenzi l'efficienza del team, crea lavoro che si sovrappone e costa ai soldi dell'azienda. Se, d'altra parte, le modifiche sono necessarie e potrebbero comportare una perdita per l'azienda se non sono state eseguite, potrebbe essere semplicemente necessario indossarle e trovare un modo per far fronte a requisiti in costante cambiamento.

Tuttavia, è stata la mia esperienza che quando le cose cambiano a un ritmo così elevato come suggerito, potrebbe essere dovuto ai seguenti motivi:

• Il concetto è sperimentale, nel qual caso potresti voler aumentare tutte queste modifiche piuttosto che implementarle direttamente nel codice di produzione.
• Il concetto non è stato analizzato a fondo, il che suggerisce che il prodotto non è stato pensato e il requisito è quello di codificare il prodotto mentre è stato pensato.
• Le pressioni costanti del mercato e della concorrenza determinano un cambiamento impulsivo
• Una scarsa relazione tra i responsabili del progetto, i manager e il team di implementazione, in termini di capacità di tutti gli stakeholder di comunicare liberamente sulla necessità di cambiare.
• Scarsa prioritizzazione delle attività, e questo può essere un errore sia del personale di gestione che di implementazione.

A volte i proprietari di progetti non sanno veramente come dovrebbe funzionare il prodotto, perché hanno in mente un concetto di base, tuttavia sentono di aver bisogno di vedere come funziona prima di prendere una decisione. Ciò può essere dovuto al fatto che il dominio del problema non è molto ben compreso o perché non hanno realmente pensato a come una funzione aziendale si tradurrà in una soluzione basata su software. La prototipazione può essere utile in questi casi. È possibile prototipizzare facilmente GUI con oggetti finti se le modifiche sono estetiche, oppure è possibile utilizzare i test unitari come mezzo per testare e ottimizzare le modifiche che sono algoritmiche. Tuttavia, la chiave è garantire che i cambiamenti vengano applicati il più sistematicamente possibile, in modo da mantenere il processo relativamente snello e meno costoso.

We have suggested setting up processes to dodge those requirement changes and educate the business about development life cycles.

Questo è un buon inizio e ti consente di interagire con il management per cercare di ottenere risultati positivi in modo misurato e strutturato. L'istruzione è il metodo più efficace per affrontare problemi in cui gli sviluppatori e la gestione sono fuori sincronia ideologica. Tuttavia, per ottenere il massimo beneficio, l'educazione deve essere bidirezionale, così come la comunicazione. Devi insegnare a te stesso e al management a comunicare i tuoi bisogni e ad aiutarsi a vicenda per comprendere le motivazioni che guidano tali bisogni. Dire che è "troppo difficile" o "molto lavoro" o "una perdita di tempo" si presenterà solo come lamentoso e "pigro". Il tuo ragionamento deve essere chiaro e in una lingua che dimostri che stai lavorando per ottenere risultati positivi per l'azienda e il prodotto su cui stai lavorando e che i tuoi motivi sono con in mente questi interessi. Allo stesso modo, potrebbe essere necessario imparare ad accettare le ragioni per cui le tute ti danno perché sentono il bisogno di cambiare le cose così rapidamente. Forse tra di voi sarete in grado di trovare una buona via di mezzo quando entrambe le parti sono in grado di comprendere il punto di vista reciproco.

What if the business fails to get the idea? What would you do?

Se non raggiungi il risultato che speri, forse i tempi non sono corretti. Forse i tuoi argomenti devono essere fatti in modo diverso. Forse hai sbagliato tutto e hai bisogno di saperne di più su ciò che sta pensando l'altra parte. In definitiva, se il tuo approccio particolare fallisce, sta a te decidere quanto sia importante per te avere a che fare. Tuttavia, piuttosto che preoccuparti di ciò che può o non può accadere, pensa in modo positivo e semplicemente decidi cosa puoi fare oggi. I problemi di domani non sono necessariamente garantiti e non valgono lo stress di preoccuparsi finché non si verificano effettivamente.

Un ultimo punto da considerare. Il tuo CTO è probabilmente preoccupato per molti degli stessi problemi che tu sei. Certamente avere un decreto per adottare il TDD mi suggerisce che questo potrebbe essere il caso dato che il TDD è altamente efficace in situazioni in cui il codice è spesso soggetto a cambiamenti. In uno scenario test-first, i test non diventano inutili il giorno successivo perché forniscono una rete di sicurezza per lavorare all'interno, consentendo di applicare le modifiche rapidamente e con sicurezza. Tuttavia, dovrai ancora trovare un modo per gestire le aspettative delle persone che richiedono modifiche al fine di aiutare a gestire il cambiamento in modo efficiente.

To make it more clear, a requirement requires the site to be able to upload an image and resize to below 500kb if actual size is over 500kb.

Requirement change might be this feature is not needed (most of the time is after they have seen it, they realized they don't actually need it)

We have suggested setting up processes to dodge those requirement changes and educate the business about development life cycles. What if the business fails to get the idea?

In primo luogo, sembra che potrebbe essere necessario fare più prototipi fittizi. Significa mockup funzionanti e cliccabili che non memorizzano o recuperano effettivamente dati reali, ma che emulano il comportamento del software. Quindi, per le applicazioni web, ciò significherebbe un codice HTML / CSS / JavaScript completo che consente all'utente di "fare clic" attraverso il software, anche se si dispone di pochissime operazioni di codifica. Forse questo può aiutare gli utenti a vedere che cosa stanno chiedendo prima di investire il lavoro nella codifica.

Successivamente, non è proprio il reparto IT a decidere come funziona l'azienda. E potrebbe essere che l'azienda valuti l'agilità sull'affidabilità per le sue esigenze di software. Quindi ottenere qualcosa cambiato OGGI è più prezioso che assicurarsi che una determinata funzione funzioni il 100% delle volte, invece del 95,5% delle volte. Solo l'azienda stessa può decidere questo. A meno che il tuo dipartimento non venga criticato per problemi di qualità, forse dovresti considerare che il business è totalmente OK con i requisiti di spostamento e il codice non testato. Il tuo CTO / CIO dice che vuole che tu sia "guidato dai test", ma se i requisiti di business sono regolarmente "fai cambiare questo cambiamento entro le 16" allora non puoi averli entrambi.