Quanto è importante conoscere la funzionalità prima della codifica?

Lavoro per un'azienda di sviluppo software in cui il lavoro di sviluppo è stato affidato a noi. Il team on shore gestisce l'assistenza e parla direttamente con i clienti. Non parliamo mai direttamente con i clienti, parliamo solo di persone del team on shore, che parlano direttamente con i clienti.

Quando i requisiti arrivano, il team on shore parla con i clienti e crea i documenti dei requisiti e ci informa. Realizziamo documenti di progettazione dopo aver studiato i requisiti (seguiamo il modello tradizionale a cascata).

Ma c'è un problema nell'intero processo: nessuno nel team off-shore o on-shore capisce completamente la funzionalità dell'applicazione. Sappiamo solo che si tratta di una grande e complessa app Web che gestisce l'elaborazione complessa degli ordini, la gestione dei cataloghi, la gestione delle campagne e altre attività. Lottiamo con il documento di progettazione poiché i requisiti non sarebbero chiari. Quindi entra in una serie di domande / risposte avanti e indietro tra il team on shore, il team offshore e i clienti. Spesso ci viene detto di comprendere la funzionalità dal codice. Ma di solito non è fattibile in quanto la base di codice è enorme e anche la comprensione di una semplice voce di menu richiede giorni se non settimane. Abbiamo provato a dire ai clienti di darci il trasferimento delle conoscenzesull'applicazione ma senza risultati. Il nostro responsabile spesso ci dice di iniziare a scrivere codice anche se il documento di progettazione non è completo o i requisiti non sono chiari. Inizieremo codificando la parte dei requisiti che sembra chiara e aspetteremo il resto.

Questo di solito ritarderebbe la distribuzione di un mese. In casi estremi avremmo errori molto bassi nello sviluppo e nella produzione, ma i clienti direbbero che non è quello che hanno chiesto. Ciò darebbe inizio a un gioco di colpa e a una serie di richieste di modifica e finiremmo per sviluppare qualcosa di molto diverso.

La mia domanda è: come faresti a lavorare allo sviluppo se non conosci completamente la funzionalità dell'app?

AGGIORNARE

La metodologia di sviluppo non è davvero la mia scelta e non sono il capo del mio team. È così che è iniziato. Ho cercato di dire alla gente i vantaggi di Agile ma senza risultati. Inoltre, non credo che il mio team abbia la mentalità necessaria per lavorare in un ambiente agile.

Versione breve:

Sapere cosa fare ≠ conoscere il tuo cliente.

Immagina questo: sei una società legata allo sviluppo immobiliare. Chiedi al tuo partner di costruire un grande complesso. Il partner afferma che, nonostante tutti i documenti che gli hai fornito, deve anche parlare direttamente con le persone che acquisterebbero 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 grandi progetti.

Alcuni domini sono troppo complessi. Se sei solo uno sviluppatore e stai lavorando su più applicazioni da più domini, non riesci sempre a capire cosa sta facendo l'utente finale , perché richiederebbe di dedicare cinque anni all'apprendimento della contabilità, dieci anni alla facoltà di medicina, sei anni in giurisprudenza, ecc.

D'altra parte, un prodotto software realizzato senza alcuna comprensione del dominio specifico sarà, nella migliore delle ipotesi, 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 comporta allo stesso tempo:

1. Tecnici (ad esempio sviluppatori che direbbero che una funzione specifica è impossibile, che questa può essere molto meglio se fatta in questo modo, e questa costerà migliaia di dollari mentre esiste un'alternativa molto più economica),

2. Persone specializzate nella gestione di progetti,

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

Uno dei requisiti funzionali e non funzionali sono scritti e sono abbastanza precisi, non hai bisogno di nient'altro come persona il cui lavoro è quello di tradurre tali requisiti in codice.

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

Lottiamo con il documento di progettazione poiché i requisiti non sarebbero chiari.

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 inequivocabili. Se il documento sui 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 ciò, devi agire diversamente:

• Se sai che la squadra che raccoglie i requisiti è disperata e la tua squadra ha persone qualificate per la raccolta dei requisiti, spiega la situazione al tuo superiore e dì che l'altra squadra deve essere sostituita da qualcuno competente , ad esempio le persone della tua.

• Altrimenti (cioè se non sono disperati), cerca di determinare la causa interna di quei bassi requisiti e di convincerli che fare il loro lavoro correttamente ridurrà 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 sui requisiti è incompleto. Lo vedo sempre: i project manager inesperti sono solo convinti che il documento di una pagina sia sufficiente e non capiscono perché avrebbero mai scritto da tre a quattrocento pagine anziché una. Se è il caso nella tua azienda, mostra che dedicare più tempo ai requisiti ridurrebbe i costi.

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

Usando Waterfall ti impegni a:

1. Ottenere i requisiti giusti in anticipo - questo ovviamente non funziona
2. Codificare i requisiti lontano dal cliente: non si è in grado di controllare efficacemente i problemi con il cliente dato che ci si è impegnati a sviluppare i requisiti
3. La prima possibilità per il cliente di vedere la propria funzionalità è durante i test - questo è troppo tardi, visti i problemi che stai riscontrando

Prendi in considerazione l'idea di utilizzare, se possibile, un modo diverso di gestire il progetto. Lo sviluppo software agile ha diverse funzionalità progettate per affrontare i problemi che si presentano.

Un discreto confronto di Waterfall vs Agile è stato scritto qualche tempo fa, prendiamo un paio di citazioni che evidenziano i tuoi problemi:

Manca il segno:

Una volta completata una fase nel metodo Cascata, non è più possibile tornare indietro, poiché la maggior parte dei software progettati e implementati con il metodo Cascata è difficile da modificare in base al tempo e alle esigenze dell'utente. Il problema può essere risolto solo tornando indietro e progettando un sistema completamente nuovo, un metodo molto costoso e inefficiente.

Legato...

I metodi agili consentono di modificare le specifiche secondo i requisiti dell'utente finale, garantendo la soddisfazione del cliente. Come già accennato, ciò non è possibile quando si utilizza il metodo a cascata, poiché qualsiasi modifica da apportare implica che il progetto deve essere riavviato da capo.

... e Impossibile spostare

Per sintetizzare la differenza tra i due, si può dire che il classico metodo a cascata è sinonimo di prevedibilità, mentre la metodologia Agile ne indica l'adattabilità. I metodi agili sono efficaci nel ridurre le spese generali, come la logica, la giustificazione, la documentazione e le riunioni, mantenendole il più basse possibile. Ed è per questo che i metodi Agile avvantaggiano i piccoli team con requisiti in costante evoluzione, piuttosto che progetti più grandi.

Dove sei ora è male; non state soddisfacendo i requisiti del cliente e, se si è nella parte responsabile dello sviluppo del software, la produttività finirà fuori dalla finestra, la sfiducia aumenterà e le cose probabilmente peggioreranno, non meglio.

Il rapporto con il cliente è fondamentale ; qui, sembra che tu non sia in grado di raccogliere efficacemente i loro problemi e adattarsi ai loro mutevoli requisiti nel modo in cui stai attualmente lavorando; quindi è necessario cercare modi per cambiarlo.

Non è così che funziona. Una delle materie della mia attuale formazione è quella dell'analisi e del rapporto con un cliente. L'enfasi è sempre stata sulla definizione chiara del progetto. Immagina questo:

• Ordini a una società di costruzioni di costruire una casa ma non sai come vuoi che appaia. Devi solo personalizzare il primo piano, quindi il team costruisce una casa fino al primo piano. Quindi vuoi che il piano terra sia disposto in modo diverso. Spiacenti ...

A meno che tu non sia molto sicuro di poter (parzialmente) fondare correttamente l'applicazione, direi semplicemente al cliente che non ci sarà altro modo che obiettivi e funzionalità chiaramente definiti. Perché se prendi solo una pugnalata a quello che potrebbe essere, rischierai di buttare un sacco di soldi e tempo in fondo.

Ecco alcune cose che aiuteranno a superare i problemi:

1. Migliora la comunicazione tra le due squadre. Chiedi all'altra squadra di comprimere il requisito in 3 parole, quindi il programmatore implementerà esattamente queste parole. Le parole devono solo essere corrette. Nulla sarà implementato senza quelle parole. Ogni parola ti dà 2000 righe di codice. L'implementazione inizia quando si conosce una nuova parola.
2. Se una parola non è immediatamente chiara per i programmatori, è consentito porre una sola domanda . La domanda deve essere di nuovo corretta. Ha bisogno di una risposta immediata: la risposta non può attendere un viaggio di andata e 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 dalla lettera.
3. Se durante l'implementazione ci sono requisiti poco chiari o confusi, il modo per risolverli è prima guardare 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 3 parole corrette.
4. Se dopo tutto ciò, il requisito è ancora poco chiaro o impossibile da implementare, il modo corretto di 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 modificarle prima di reinserirle nel sistema. Il rifiuto delle parole sposta sempre la scadenza e l'implementazione dovrà essere nuovamente pianificata.
5. Le squadre dovrebbero essere valutate in base al numero di parole respinte che hanno. Dopo che il requisito è stato implementato, viene risolto per sempre e non può più essere modificato . Qualsiasi tentativo di modificare funzionalità già implementate verrà rifiutato.
6. Il vero problema con la domanda è che si presume che più informazioni facilitino l'implementazione. Questo non è vero. La maggiore libertà i tuoi programmatori hanno, il 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.