Quanto è importante conoscere la funzionalità prima della codifica?

Versione breve:

Sapere cosa fare ≠ conoscere il tuo cliente.

Immagina: sei un'azienda legata allo sviluppo immobiliare. Chiedi al tuo partner di costruire un grande complesso. Il partner dice che nonostante tutti i documenti che gli hai dato, ha anche bisogno di parlare direttamente con le persone che comprerebbero gli appartamenti in questo complesso. Sul serio?

Versione lunga:

È sempre bello sapere come verrà utilizzata un'applicazione specifica, perché è divertente imparare le cose, ma non è sempre possibile su progetti di grandi dimensioni.

Alcuni domini sono troppo complessi. Se sei solo uno sviluppatore e lavori su più applicazioni da più domini, non puoi sempre capire cosa sta facendo l'utente finale , perché richiederebbe per trascorrere cinque anni a studiare contabilità, dieci anni in una scuola di medicina, sei anni in giurisprudenza, ecc.

D'altra parte, un prodotto software realizzato senza alcuna comprensione del dominio specifico sarà al meglio, beh, un po 'inutilizzabile .

Ecco perché i requisiti funzionali e non funzionali devono essere scritti da persone che comprendono appieno il dominio. In generale, la raccolta dei requisiti coinvolge allo stesso tempo:

1. Tecnici (ad esempio gli sviluppatori che direbbero che una caratteristica specifica è impossibile, che quest'altro può essere molto meglio se fatto in questo modo, e questo costerà migliaia di dollari mentre c'è un'alternativa molto più economica) ,

2. Persone specializzate nella gestione dei progetti,

3. Persone specializzate nel dominio del cliente , che hanno piena conoscenza di questo dominio e delle precise esigenze del cliente. Naturalmente, questo potrebbe essere il cliente stesso.

I requisiti funzionali e non funzionali sono scritti e sono sufficientemente precisi, non è necessario nient'altro che una persona il cui lavoro è tradurre questi requisiti in codice.

Per quanto riguarda il tuo caso specifico, descrivi tu stesso la causa del problema:

We struggle with the design document as the requirements would not be clear.

Non è la mancanza di conoscenza del cliente che causa tutti i problemi , è la bassa qualità dei requisiti. In un progetto gestito correttamente, i requisiti funzionali e non funzionali devono essere perfettamente chiari e non ambigui. Se il documento dei requisiti non è chiaro o se ti dice che "il design visivo del prodotto deve essere attraente" o altre stupidaggini del genere, è perché è stato scritto da persone che non sanno come scriverlo.

Sapendo questo, devi agire in modo diverso:

• Se sai che il team che raccoglie i requisiti è disperato e il tuo team ha personale qualificato per la raccolta dei requisiti, spiega la situazione al tuo superiore e spiega che l'altra squadra deve essere sostituita da qualcuno competente , ad esempio le persone del tuo.

• Altrimenti (vale a dire se non sono disperati), cerca di determinare la causa interna di quei requisiti bassi e persuaderli a fare in modo che il loro lavoro corretto riduca solo il costo complessivo del progetto . Mostrare le statistiche su come i requisiti scritti male hanno influenzato il progetto aumentando il costo (quanto?) E il rischio di non essere pronti per la scadenza è una buona idea qui.

Probabilmente il documento dei requisiti è solo incompleto. Lo vedo sempre: i project manager inesperti sono convinti che un documento di una sola pagina sia sufficiente e non capiscono perché mai scriverebbero da tre a quattrocento pagine invece di una. Se è il caso della tua azienda, dimostra che passare più tempo ai requisiti ridurrebbe i costi.

Stai utilizzando esattamente la metodologia di sviluppo sbagliata per i problemi che stai affrontando.

Usando Waterfall ti stai impegnando a:

1. Ottenere i giusti requisiti in anticipo - questo ovviamente non lo è funzionante
2. Codificare i requisiti lontano dal cliente - non lo sei in grado di controllare efficacemente i problemi con il cliente dato che hai impegnato a sviluppare i requisiti
3. La prima occasione in cui il cliente può vedere la propria funzionalità è durante i test - questo è troppo tardi dato i problemi che stai riscontrando

Considera l'utilizzo, se possibile, di un modo diverso di gestire il progetto. Sviluppo software agile ha diverse funzionalità progettate per affrontare i problemi che stai affrontando.

Un buon paragone di Waterfall vs Agile è stato scritto qualche tempo fa , lascia prendere un paio di citazioni da esso che evidenziano i tuoi problemi:

Manca il segno:

Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method.

Legato giù ...

Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

... e Impossibile spostare

To synopsise the difference between the two, one can say the classic waterfall method stands for predictability, while Agile methodology spells adaptability. Agile methods are good at reducing overheads, such as, rationale, justification, documentation and meetings, keeping them as low as is possible. And, that is why Agile methods benefit small teams with constantly changing requirements, rather more than larger projects.

Dove sei ora è cattivo; non stai consegnando ai requisiti del cliente e, se sei incolpato di parte dello sviluppo del software, la produttività sta per uscire dalla finestra, la sfiducia aumenterà, e le cose andranno probabilmente peggiorando, non meglio.

La relazione con il cliente è critica ; qui sembra che tu non sia in grado di raccogliere efficacemente i loro problemi e adattarsi alle loro mutevoli esigenze nel modo in cui stai lavorando; pertanto è necessario considerare i modi per modificarlo.

Non è così che funziona. Uno dei temi della mia attuale formazione è quello dell'analisi e della relazione con un cliente. L'enfasi è stata sempre sulla chiara definizione del progetto. Immagina questo:

• Ordina a una società di costruzioni di costruire una casa ma non sai come la vuoi guardare. Personalizzi solo il primo piano, così il team costruisce una casa fino al primo piano. Quindi vuoi che il piano terra sia disposto diversamente. Oops ...

A meno che tu non sia molto sicuro di poter (parzialmente) fare le basi corrette per l'applicazione, vorrei solo dire al cliente che non c'è altro modo di fare che con obiettivi e funzionalità chiaramente definiti. Perché se ti limiti a quello che potrebbe essere, rischi di buttare un sacco di soldi e tempo da perdere.

Ecco alcune cose che ti aiuteranno a superare i problemi:

1. Migliora la comunicazione tra i due team. Chiedere all'altra squadra di comprimere il requisito in 3 parole, e quindi il programmatore implementerà esattamente quelle parole. Le parole devono solo essere corrette. Niente sarà implementato senza quelle parole. Ogni parola ti dà 2000 linee di codice. L'implementazione inizia quando si conosce una nuova parola.
2. Se una parola non è immediatamente chiara per i tuoi programmatori, è possibile fare una sola domanda . La domanda deve essere ancora una volta corretta. Ha bisogno di una risposta immediata - la risposta non può aspettare un viaggio di ritorno dall'altra parte del mondo, ma deve essere conosciuta in anticipo. L'implementazione inizia immediatamente dopo aver ricevuto la risposta e la risposta verrà seguita alla lettera.
3. Se durante l'implementazione ci sono dei requisiti non chiari o confusi, il modo per risolverli è di guardare prima le 3 parole (esistenti). Se non è ancora chiaro, il programmatore rende la migliore ipotesi possibile . Qualsiasi ritardo in questo processo è assolutamente vietato; e chiedere aiuto all'altra squadra non è il modo giusto per risolverlo - hanno già avuto la possibilità di cambiare i requisiti decidendo correttamente 3 parole.
4. Se dopo tutto ciò, il requisito non è ancora chiaro o impossibile da implementare, il modo corretto per gestire è rifiutare quelle 3 parole che hanno causato il problema e passare alle parole successive. Tutte le parole rifiutate verranno raccolte e passate all'altra squadra e dovranno modificare le parole prima di reinserirle nel sistema. Rifiutare le parole sposta sempre la scadenza e l'implementazione dovrà essere pianificata di nuovo.
5. I team dovrebbero essere valutati in base a quante parole rifiutate hanno. Dopo che il requisito è stato implementato, è stato risolto per sempre e non può più essere modificato . Qualsiasi tentativo di modificare le funzionalità già implementate verrà rifiutato.
6. Il vero problema con la domanda è che presuppone che più informazioni rendano l'implementazione più semplice. Questo non è vero. La più libertà dei tuoi programmatori ha, più facile l'implementazione . La compressione dei requisiti consente di comunicare grandi quantità di informazioni senza limitare troppo ciò che i programmatori sono autorizzati a fare.