Come sviluppi software senza criteri di accettazione?

Un processo iterativo lo realizzerà in modo soddisfacente, senza specifiche dettagliate.

Crea semplicemente un prototipo abbozzato, chiedi feedback al cliente, apporta modifiche in base al feedback e ripeti questo processo fino al completamento dell'applicazione.

Se il cliente è abbastanza paziente da farlo in questo modo è una domanda diversa. Alcuni clienti e sviluppatori preferiscono in realtà questo processo; dal momento che il cliente è sempre pronto, alla fine otterrà esattamente ciò che desidera.

Dovrebbe essere ovvio che non lavorerai in questo modo a un contratto a tempo determinato o fisso in questo modo.

Se quello che dici è vero e le specifiche non sono neanche lontanamente sufficienti per iniziare (e sei onesto in questa valutazione), raccomando questo approccio:

1. Leggi gli schizzi e le specifiche "imprecise" che ti sono state fornite.
2. Scrivi le tue specifiche ad un livello che è sufficiente per tu per essere in grado di codice. Potresti dover fare un sacco di ipotesi.
3. Mostra le tue specifiche al cliente per la revisione. Prendi nota delle parti che preferiscono e ottieni ulteriori informazioni sulle parti in cui pensano che tu abbia sbagliato.
4. Ripeti i passaggi 2 e 3 finché tu e il cliente non siete sincronizzati.
5. Ora hai una specifica adeguata

Se il tuo cliente aveva ragione quando ha detto "sarà facile", allora questo esercizio dovrebbe essere un gioco da ragazzi.

Se il cliente ha sbagliato e in effetti ci sono tutti i tipi di problemi e lacune nei requisiti, la tua bozza specifica illustrerà rapidamente il problema e comunicherà loro che erano sbagliati (senza che tu debba puntare il dito o discutere) poiché sarà proprio di fronte a loro ed evidente. Inoltre, le tue specifiche serviranno come un ottimo strumento di discussione per risolvere tali ambiguità e serviranno da record di decisioni chiave man mano che le rivedi con il loro feedback.

Il proprietario del prodotto ti ha consegnato un prototipo; restituiscigli quelli migliori (finché non hai finito)

Sembra che ti sia stato fornito un prototipo cartaceo per avviare il progetto. Non è un inizio terribile. Ti suggerisco di comunicare di nuovo al proprietario dell'attività commerciale nella stessa lingua , fornendo prototipi progressivamente capaci.

I tuoi prototipi dovrebbero iniziare con la carta, passare a prototipi digitali e poi essere costruiti con tecnologie "reali".

La casa sull'albero ha una guida eccellente per questo, che conclude:

The wonderful thing about prototyping with a framework is that the prototype often just becomes the real site because the structure and styling are already in place. There’s no need to recreate the site from scratch if it’s going to use the same framework.

Potresti anche voler fornire una specifica formale, specialmente se rimani preoccupato di essere incolpato di un cattivo risultato. Ma probabilmente riceverai più feedback dai prototipi.

Incontra la scadenza

Nota che i tuoi sforzi successivi non saranno "prototipi" classici come tutti, poiché non saranno usa e getta (o parti di essi non saranno). L'ultimo, più efficace, iterazione che completi prima della scadenza diventa il tuo deliverable.

La tua scadenza è il requisito migliore che hai. Hai qualcosa di completo e coerente che puoi consegnare in tempo.

Collabora con i tuoi tester

Se questo processo di rilascio è una novità per la tua azienda, i tuoi tester sono probabilmente ancora più in difficoltà di te, e potrebbero cercare tu come guida. Devi prendere un po 'del loro tempo all'inizio del processo. Fai sapere al loro capo che stai cercando di aiutarli a fornire un test significativo senza ricevere criteri di accettazione formali.

Scopri se i tester hanno qualcosa di solido che devono fornire, come la documentazione di prova dei test, a cui puoi "tornare".

Prova Prova il primo progetto

Dato che non hai requisiti formali, sviluppare i casi di test per fornire una certa struttura.

Ottieni familiarità con Prova il primo progetto e / o sviluppo guidato dai test e fornire indicazioni ai tuoi tester sul processo in base alle esigenze. Per un progetto rapido come questo, non è necessario diventare esperti nel processo. Ma l'utilizzo di una metodologia comprovata rifletterà bene su di te e sui tuoi tester.

Attenersi agli standard, in particolare per l'interfaccia utente

Non hai requisiti sull'aspetto, ma hai una scadenza. Utilizza il lavoro di progettazione di qualcun altro per ridurre al minimo il lavoro che devi fare per creare un artefatto dall'aspetto professionale.

Scegli un'interfaccia utente standard per il tuo sito e non personalizzarlo a meno che / fino a quando non venga indirizzato a. Non so per quale piattaforma stai sviluppando, ma Bootstrap o Google Material Design sono due esempi.

Comunicare, ma non infastidire

Suggerirei di inviare una sola email al proprietario del prodotto al giorno. Invia solo altro se è un'emergenza.

Se hai domande, descrivi come procederai se non ricevi una guida. Ad esempio:

Will the users of this app need to access it with mobile devices? Right now we are assuming this will be a desktop/laptop only system.

Non farti prendere dal panico

Ho partecipato a molti progetti per persone che non conoscevano il termine "requisito". La maggior parte ha avuto successo. I proprietari di prodotti hands-off ti danno la libertà di costruire grandi soluzioni.

Nota, alcuni proprietari di progetti in questi progetti erano impossibili da accontentare e si nascondevano dietro la scusa "Sono troppo occupato per ..." per la loro incompetenza. Ma la maggior parte erano "soddisfatti" dei risultati finali.

Un progetto è l'atto di ridurre l'incertezza fino al raggiungimento della certezza :

• C'è sempre un certo grado di incertezza all'inizio. A volte è una piccola ambiguità nei requisiti. A volte, è molto impreciso. Dovrai lavorare come parte del lavoro.
• Il trucco è ridurre iterativamente questa incertezza (combinando analisi, progettazione e implementazione), perfezionando le storie degli utenti e amp; implementando il tuo sistema.
• Verifichi casi / scenari e i criteri di accettazione dovranno essere chiariti allo stesso modo. Contribuiranno a ridurre l'incertezza sulla qualità e sulla correttezza (tra le altre).
• Alla fine, si raggiunge una certezza sufficiente: il cliente ottiene un prodotto testato che si adatta alle sue esigenze e può essere utilizzato.

Questo è il principio dell'elaborazione progressiva: i requisiti, i criteri e i risultati saranno elaborati passo dopo passo, come farà la comprensione del cliente delle sue aspettative e richieste attraverso il suo coinvolgimento nel processo di sviluppo.

Questo è un problema?

Lo sketchier i requisiti iniziali, maggiore è l'incertezza e maggiore è il tempo necessario per eseguire le attività. Quindi è solo questione di chi farà il lavoro aggiuntivo e chi pagherà per i costi.

La risposta di queste due domande dovrebbe essere nel contratto. O sarà oggetto di una negoziazione. E il cliente deve accettare un coinvolgimento aggiuntivo (l'argomento principale sarà "spazzatura, spazzatura", anche se ti consiglierei strongmente di presentarlo in modo più diplomatico ;-))

Un progetto senza requisiti chiari, una leadership allentata, nessuna definizione di fatto (DoD), nessuno disposto a rendere conto di disporre delle informazioni necessarie per svolgere il proprio lavoro in modo tempestivo e incontrare i loro la scadenza è una ricetta per l'errore del progetto.

Lo sviluppo iterativo non è un cattivo suggerimento, ma richiede una stretta collaborazione tra i proprietari del prodotto e gli sviluppatori. Cerca di mettere qualcuno alle prese dicendo: "Sappiamo che avremo delle domande: chi può essere regolarmente disponibile per assicurarti che le persone ricevano risposta in modo che la consegna del progetto non venga ritardata?" Pianifica orari regolari con qualcuno per esaminare i progressi e rimuovere gli impedimenti. Se non mostrano, o rifiutano, seguono con cortese corrispondenza scritta e ritardi o mancate risposte. Se i proprietari del prodotto non possono essere disponibili, chiedere loro di fornire un rappresentante che può essere.

Inoltre, un altro segno distintivo dello sviluppo iterativo è che un cambiamento nei requisiti richiede un cambiamento nella timeline. Non puoi impegnarti a rispettare una scadenza se non riesci a sviluppare una timeline, e non è possibile sviluppare una cronologia se non si ha una buona idea di cosa deve essere fatto. Invece di chiedere dogmaticamente una specifica, rivedere le specifiche attuali, documentare eventuali domande che tu o il team avete riguardo a come dovrebbe funzionare, pianificare l'orario con i proprietari del prodotto per discuterne e documentare le risposte. Quando hai finito, avrai le tue specifiche in base alle loro decisioni, che potrai quindi accettare (per iscritto) dai proprietari dei prodotti. Lo scopo di una specifica è rimuovere l'ambiguità e creare un DoD, che è esattamente ciò che una sessione Q & A potrebbe fornire. Se c'è opposizione a una specifica, non chiamarla spec.

Non credere a nessuno quando ti dicono sarà facile . A volte è davvero così semplice come sembra, e potrei credere che se (e solo se ) conosco abbastanza bene i proprietari dei prodotti per credere pienamente che i requisiti siano davvero Semplice come dicono di essere, e le specifiche che mi sono state fornite si spiegano da sole (in caso contrario, programma una sessione di Q & A e la documento). Sono stato in troppe situazioni in cui facile da un punto di vista operativo è incredibilmente difficile da un punto di vista dello sviluppo, o pensi di avere completamente finito e senti le parole di disperazione ( "Oh, a proposito, ci siamo dimenticati di ..."). Esempio ... "Tutto quello che devi fare è leggere questi file PDF da un repository di documenti", che, durante il test di accettazione, si trasforma in "Oh, abbiamo dimenticato che alcuni di questi sono stati letti di lato in modo completamente incoerente, e alcuni hanno definito la dimensione della pagina sbagliata e alcuni hanno bisogno di aggiungere queste tre pagine, e abbiamo bisogno che tutti mostrino la stessa cosa: è davvero facile da risolvere, giusto? ".

Il punto è che potrebbe essere davvero facile, e una rapida riunione potrebbe confermarlo, permettendoti di documentare tutte le ipotesi e ottenere la conferma che sono accurate e corrette. Raccomando di alzarsi in piedi per rimuovere gli impedimenti che devi scrivere codice di lavoro che soddisfi le loro aspettative, perché indipendentemente dal fatto che tu faccia un passo sulle dita dei piedi, qualcuno sarà probabilmente infelice, alla fine, comunque. Se sei ostinato a rispondere alle domande e ad irritare qualcuno, se ne dimenticherà quando consegnerai un ottimo prodotto nei tempi che soddisfano i requisiti. Se non ottieni chiarimenti e non consegni, nessuno ricorderà che ti hanno detto di non infastidirli.

" Non ci sono incontri regolari in programma ". Bene, perché non iniziare pianificando riunioni regolari allora? Il solo fatto che tu abbia più proprietari di prodotti garantisce che il tuo progetto NON sarà facile, poiché ognuna di queste persone avrà requisiti contrastanti che DEVONO essere discussi di persona con tutte le parti interessate presenti.

Inoltre, ti consiglio davvero di tenere un registro delle decisioni dettagliato . Come minimo, scrivi tutto ciò che qualcuno ha deciso, con la data e un elenco di persone presenti quando la decisione è stata presa. Ancora meglio se puoi scrivere WHY qualcosa è stato deciso così com'era. Non importa se si tratta di un file sul PC, di una pagina nella wiki della tua intranet o di un notebook sulla tua scrivania. Il log protegge te e il progetto: quando un tester dice che un oggetto "fallisce", puoi sottolineare che è stato deciso in quel modo con queste persone, e non è un tuo problema, ma tra loro e i tester. Se questo porta a cambiare le specifiche, allora va bene, ma a questo punto non possono aspettarsi di rispettare le scadenze che avevano in mente - o devono tagliare lo scope da qualche altra parte.

Senza una specifica, hai un lavoro di squadra. Vai Agile.

Siediti con il PO e arricchisci una / alcune piccole storie iniziali. "Distribuiremo solo questo schermo, con solo questo pulsante che fa 'bing!'". Accontentarsi di alcuni AC. Consegna la storia. Dimostra la storia. Risulta che i pulsanti dovrebbero essere rossi. Alza un insetto o una nuova storia. Consegna i pulsanti che vanno a bong e bang. E così via.

Specificare in modo collaborativo e fornire piccole sezioni verticali che vengono spesso dimostrate.

Se il cliente non lavora con te in questo modo, cerca una via d'uscita.

Ho speso diversi lavori facendo progetti proprio come hai delineato. Finché il PO sa quali decisioni di progettazione stai prendendo e perché devi realizzarle, dovresti stare bene. Se, d'altra parte, non comprendono le decisioni di progettazione, è necessario premerle per almeno un documento di test di accettazione scritto dell'utente.

Hai bisogno di una specifica dettagliata e verificabile prima di poter iniziare a scrivere codice. Questo è un dato di fatto, e non c'è modo di aggirarlo.

Se nessun altro è disposto a scrivere quella specifica, gli sviluppatori devono scriverlo. Quindi ottieni una specifica incompleta. Lo trasformi in una specifica completa (il che significa "questo è ciò che implementerò a meno che qualcun altro non mi dica di"). Consegnate quella specifica agli stakeholder e date loro la possibilità di modificare le specifiche. Solo una possibilità di modificare le specifiche - non la si appunta, ad esempio dicendo "Non mi piace in questo modo". A quel punto, sono le tue specifiche, oppure possono fornire una specifica diversa, ma non rimuovere le specifiche.

Potrebbe essere una buona idea ottenere una rapida recensione dai tuoi colleghi che potrebbero migliorare le specifiche. Ma comunque, hai una specifica, scrivi il codice di conseguenza, i tester testano di conseguenza. E hai fatto il tuo lavoro: hai avuto una specifica e l'hai implementata. Se la specifica non è ciò che il cliente vuole, è direttamente responsabilità del proprietario del prodotto o del cliente che non si è preso la briga di scrivere una buona specifica.