Perché preoccuparsi di raccogliere i requisiti quando sappiamo che cambieranno?

Perché non tutti i requisiti cambiano e non tutti i requisiti cambiano nello stesso modo. Non trascorrerai un po 'di tempo a lavorare su un software per gestire un magazzino, ma deciderò semplicemente di rielaborare il software per pianificare appuntamenti dal dentista.

Alcuni requisiti cambiano che hanno un grande impatto, come cambiare il sistema operativo su cui viene eseguito e, a volte, i requisiti cambiano per ridefinire l'etichetta con una casella di testo. Tuttavia, la riformulazione di un'etichetta di testo è molto più probabile, il sistema operativo non lo è. Quindi c'è valore nell'ottenere molti aspetti del software pensati e scritti.

Mentre crei un sacco di software per una varietà di persone e domini diversi, inizierai a farti un'idea di ciò che è nell'aria e cosa non lo è, e avrai anche un'idea di come progettare software per essere flessibile nei posti giusti.

Why do we spend so much time gathering detailed requirements at the beginning if we know that they will be invalidated and change in the not so distant future?

È ora di smettere di raccogliere i requisiti al momento di scrivere e dimostrare il codice diventa il modo più efficace per comunicare la tua comprensione dei requisiti. Se continui a raccogliere oltre questo punto, stai rallentando le cose. Tuttavia, se non si raccolgono requisiti fino a questo punto, si rallentano anche le cose.

Se lo stai facendo bene, i requisiti cambiano sia durante la raccolta che la dimostrazione. Perché? Perché il cambiamento è il risultato di una comunicazione efficace.

Dovresti imparare (così dovrebbe essere il proprietario del tuo prodotto). Il che significa che il punto nel progetto quando sei il più stupido è all'inizio. Quindi non vuoi l'inizio impostato nella pietra. Smetti di raccogliere i requisiti quando smette di causare cambiamenti significativi.

È un po 'come usare il popcorn al microonde. Ferma quando passa troppo tempo tra i pop.

Un aspetto di questo; Se non hai requisiti, perché stai scrivendo un codice? Il codice non esiste per piacere a se stesso. Qualunque sia la ragione per cui stai scrivendo ha un requisito nascosto in esso, e prima comprendi ciò che è veramente importante, allora puoi prendere decisioni che ti preparano al successo.

Devi sapere che aspetto ha il "fatto", altrimenti ti agiti casualmente e speri di scrivere un software utile per sbaglio.

Quello che probabilmente stai pensando è Big Design Up Front , e sì, non è necessariamente il modo migliore per gestire un progetto software.

Ma hai ancora bisogno di un'immagine chiara di ciò che vuoi realizzare quando intraprendi un nuovo progetto di sviluppo software. In generale, devi sapere quali benefici ti aspetti dal nuovo software, quanto denaro salverà e le funzionalità (a grandi pennellate) che avrà. Più in particolare, è necessario conoscere, in dettaglio, quali sono i processi di business e come tali processi di business saranno incorporati nel nuovo software.

Il problema è che hai bisogno di istruzioni dettagliate prima di poter iniziare la codifica. Altrimenti, come farai a sapere cosa fare? Queste istruzioni non devono necessariamente essere formali (può essere sotto forma di schizzi grezzi) o molto dettagliate, ma ci sono alcuni ingredienti che sai di aver bisogno. Hai bisogno di un design del database. Hai bisogno di un design dell'interfaccia utente. Sono necessari metodi che implementano i processi di business. E così via. L'unico modo per ottenerli è trasformare le funzionalità in requisiti, e lo fai facendo incontri con le parti interessate, comprendendo i loro processi aziendali, mostrando loro i prototipi, creando prototipi funzionali ad alta velocità e così via.

I processi di sviluppo del software Agile vedono i requisiti, non come punto finale, ma come punto di partenza. I requisiti possono evolversi, se diventa chiaro che sono in qualche modo inadeguati. Indipendentemente da ciò, è necessario disporre di istruzioni sufficientemente dettagliate da scrivere codice e "cuocere una torta" non è abbastanza specifico.

I have always been taught that one of the most important things to do at the beginning of the developments of a software is the Requirement gathering.

Bene, in più di tre decenni di sviluppo del software ho fatto l'esperienza di prima mano che un'analisi dettagliata dei requisiti (se intendi quella per "raccolta") è davvero molto importante per lo sviluppo della prossima feature o feature slice di un software, e queste caratteristiche non dovrebbero essere troppo grandi (è per questo che dovresti provare a tagliare le grandi caratteristiche a fette). E in questi anni, questa esperienza ha raggiunto anche il mainstream ed è diventata parte delle cosiddette metodologie "agili". Quindi chiunque ti abbia insegnato questo, sembra che ti abbiano detto alcune cose antiquate del passato.

Quindi la risposta a

Why do we spend so much time gathering detailed requirements at the beginning

is - "noi" non , solo teorici del passato, che non hanno una propria esperienza nello sviluppo di software efficace, e molto probabilmente non sanno che cosa significa sviluppo agile.

Naturalmente, a volte ci sono ragioni sensate per cui dedicare molto tempo alla raccolta dei requisiti all'inizio di un progetto:

• perché devi offrire un'offerta a prezzo fisso a un potenziale cliente. Quando si calcola il prezzo, non si vuole trascurare un requisito nascosto in una mezza frase della pagina 42 della lista dei desideri dei clienti, che richiede diversi mesi o anni aggiuntivi per lo sviluppo.

• o, se sei il cliente, vuoi assicurarti che un potenziale appaltatore sviluppi tutte le funzionalità che ti aspetti da lui per una certa somma di denaro, quindi fai un elenco dettagliato dei requisiti per il contratto.

• perché è necessario prendere decisioni architettoniche sul sistema in anticipo e non si vuole trascurare un requisito che si scontra direttamente con l'architettura scelta

Nessuno di questi motivi, tuttavia, si aspetta che i requisiti non cambino nel tempo, o che ogni caratteristica del software sia analizzata in ogni dettaglio cruento prima di iniziare a scrivere la prima riga di codice. Ad esempio, se si stipula un contratto con i requisiti 1 2 e 3 e il requisito 3 è sostituito dal requisito 4, allora questa è una buona base per rinegoziare il contratto. O prendere decisioni architettoniche, queste sono in genere fondate su alcune nozioni generali sui requisiti non funzionali, quelle non diventano intrinsecamente sbagliate perché cambiano i requisiti funzionali, e non diventano sbagliati se i requisiti non funzionali cambiano entro un ragionevole grado .

Un altro punto vorrei menzionare che i "requisiti di raccolta" non significano necessariamente un'analisi dettagliata. È sempre una buona idea raccogliere costantemente idee per nuove funzionalità e miglioramenti in qualche backlog o issue tracker nell'intero progetto , non esclusivamente all'inizio di un progetto, ma parallelamente alle attività di sviluppo, ogni volta uno ha una buona idea che potrebbe migliorare il prodotto. Questa è davvero una parte importante della gestione dei requisiti, poiché ti consentirà in seguito di prendere una decisione su quale di queste idee dovrebbe essere prioritizzata, il che è abbastanza utile per essere analizzato in dettaglio e implementato come nuove funzionalità.

Why do we spend so much time gathering detailed requirements...?

I requisiti formano il contratto tra il team di sviluppo e il cliente. Se non raccogli i requisiti, nessuno saprà veramente cosa deve essere costruito e non ci sarà alcuna speranza di successo.

...at the beginning if we know that they will be invalidated and change in the not so distant future?

Il momento in cui vengono raccolti i requisiti dipende dal processo utilizzato. Il processo Waterfall impone che i requisiti vengano raccolti all'inizio del progetto e non deve cambiare . Un cambiamento nei requisiti del processo a cascata è un problema enorme e può portare a una nuova architettura, alla riprogettazione, alla reimplementazione, al ri-test in base a quanto lontano nel processo quando i requisiti cambiano. Questo è il motivo per cui se si utilizza il processo a cascata, viene investito molto tempo nell'ottenere i requisiti, spesso una specifica dei requisiti software (SRS) documento è stato creato e approvato dal cliente.

Poiché i cambiamenti nei requisiti con waterfall sono molto costosi e i requisiti cambiano spesso, esistono processi migliori per la gestione dei requisiti in evoluzione. Agile è una metodologia di processo molto popolare in cui i requisiti (spesso espressi come user story ) sono prioritari e sono stati scelti e implementati in uno sprint sufficienti requisiti per riempire uno sforzo di sviluppo di 2-4 settimane. Durante i requisiti dello sprint non deve cambiare , ma una volta terminato lo sprint, il cliente può esaminare il prodotto e decidere di modificare, aggiungere o rimuovere i requisiti per il prossimo sprint. Il ciclo si ripete fino a quando il cliente decide che non ci sono più requisiti.

Esistono molti modelli di processo che soddisfano i requisiti in modo diverso e il processo utilizzato deve essere scelto in base al progetto.

I have also been taught that requirements always (most of the time) change dramatically between the beginning and the end of the project

I requisiti possono cambiare, ma ci dovrebbero essere procedure in atto (determinate dal processo utilizzato) per limitare / controllare i cambiamenti nei requisiti.

Se si tratta di un sistema complesso, è difficile sapere quali sono i requisiti effettivamente disponibili. Se inizi a indicare i requisiti che ritieni di avere, puoi in un secondo momento fare un passo indietro e osservare il quadro generale, e improvvisamente realizzare ciò che realmente ti serve.

Molte persone non sanno quello che vogliono. Non possono esprimere chiaramente le loro esigenze. Pertanto, come sviluppatore di software, raccogli i requisiti nel miglior modo possibile, mostra loro i requisiti e troveranno molto più facile scoprire come i tuoi requisiti non corrispondono a quello di cui hanno effettivamente bisogno. Quindi prima hai bisogno dei requisiti per avere un Possibilità di ottenere i requisiti reali.