Come si sviluppa il software senza criteri di accettazione?

Come sviluppare in modo collaborativo software in un team di 4-5 sviluppatori senza criteri di accettazione, senza sapere per cosa testeranno i tester e con più (2-3) persone che agiranno come proprietari del prodotto.

Tutto ciò che abbiamo è una 'specifica' imprecisa con alcune schermate e alcuni punti elenco.

Ci è stato detto che sarà facile, quindi queste cose non sono necessarie.

Sono in perdita su come procedere.

Informazioni addizionali

Ci è stata data una scadenza rigida.

Il cliente è interno, in teoria abbiamo un product owner, ma almeno 3 persone che testano il software potrebbero fallire un articolo di lavoro semplicemente perché non funziona come pensano che dovrebbe funzionare e c'è poca o nessuna trasparenza di ciò che si aspettano o per cosa stanno effettivamente testando fino a quando non ha fallito.

i proprietari dei prodotti non sono prontamente disponibili per rispondere a domande o fornire feedback. Non ci sono riunioni regolari programmate o chiamate con loro e il feedback può richiedere giorni.

Posso capire che non possiamo avere una specifica perfetta ma ho pensato che sarebbe stato "normale" avere criteri di accettazione per le cose su cui stiamo effettivamente lavorando in ogni sprint.

Un processo iterativo lo farà bene, senza specifiche dettagliate.

È sufficiente creare un prototipo impreciso, chiedere feedback al cliente, apportare modifiche in base al feedback e ripetere questo processo fino al completamento dell'applicazione.

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

Va da sé che in questo modo non hai intenzione di stipulare un contratto a tempo determinato o a tempo determinato.

Se ciò che stai dicendo è vero e le specifiche non sono abbastanza buone da poter iniziare (e sei onesto in questa valutazione), ti consiglio questo approccio:

1. Leggi gli schizzi e le specifiche "imprecise" che ti sono state fornite.
2. Scrivi le tue specifiche a un livello sufficiente per poter codificare. Potrebbe essere necessario fare molte ipotesi.
3. Mostra le tue specifiche al cliente per la revisione. Nota le parti che gli piacciono e ottieni maggiori informazioni sulle parti in cui pensano di aver sbagliato.
4. Ripeti i passaggi 2 e 3 fino a quando tu e il cliente 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 tuo 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 abbia bisogno di puntare un dito o discutere) poiché lo farà essere proprio di fronte a loro e ovvio. Inoltre, le tue specifiche serviranno come un ottimo strumento di discussione per risolvere quelle ambiguità e serviranno come un registro delle decisioni chiave mentre le rivedi con il loro feedback.

Il proprietario del prodotto ti ha consegnato un prototipo; restituiscilo a quelli migliori (fino a quando non hai finito)

Sembra che ti sia stato fornito un prototipo di carta per iniziare il progetto. Non è un inizio terribile. Ti suggerisco di comunicare con il proprietario dell'azienda nella stessa lingua , fornendo prototipi progressivamente capaci.

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

Treehouse ha una guida eccellente per questo, che conclude:

La cosa meravigliosa della prototipazione con un framework è che il prototipo spesso diventa il vero sito perché la struttura e lo stile sono già in atto. Non è necessario ricreare il sito da zero se utilizzerà lo stesso framework.

Potresti voler fornire anche una specifica formale, soprattutto se rimani preoccupato di essere incolpato per un brutto risultato. Ma probabilmente otterrai più feedback dai prototipi.

Rispetta la tua scadenza

Nota che i tuoi sforzi successivi non saranno i classici "prototipi", in quanto non saranno usa e getta (o parti di essi non lo saranno). L'ultima iterazione più completa che completi prima della scadenza diventa il tuo deliverable.

La scadenza è il requisito meglio definito che hai. Avere qualcosa di completo e coerente che puoi consegnare in tempo.

Collabora con i tuoi tester

Se questo processo allentato è una novità per la tua azienda, i tuoi tester probabilmente sono ancora più in perdita di te e potrebbero essere alla ricerca di una guida. Devi dedicare 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 fermo che devono fornire, come la documentazione di prova del collaudo, a cui puoi "tornare".

Prova Test First Design

Dal momento che non hai requisiti formali, ottenere casi di test per sviluppare fornirebbe una struttura.

Acquisisci familiarità con Test First Design e / o sviluppo guidato dai test e fornisci indicazioni ai tuoi tester sul processo, se necessario. Per un progetto rapido come questo, non è necessario diventare esperti del processo. Ma l'utilizzo di una metodologia comprovata rifletterà bene su di te e sui tuoi tester.

Rispetta gli standard, in particolare per l'interfaccia utente

Non hai requisiti di aspetto, ma hai una scadenza. Usa 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 personalizzarla a meno che / fino a quando non viene indirizzata 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 e-mail al proprietario del prodotto al giorno. Invia di più solo se è un'emergenza.

Se hai domande, descrivi come procedere se non ricevi assistenza. Per esempio:

Gli utenti di questa app dovranno accedervi con dispositivi mobili? In questo momento stiamo assumendo che questo sarà un sistema solo desktop / laptop.

Non fatevi prendere dal panico

Sono stato coinvolto molti progetti per persone che non conoscevano il termine "requisito". La maggior parte ha avuto successo. I proprietari di prodotti a mani libere ti danno la possibilità di creare 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 è stata “deliziata” dai 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 è un po 'di ambiguità nei requisiti. A volte, è molto impreciso. Dovrai allenarti come parte del lavoro.
• Il trucco è ridurre iterativamente questa incertezza (combinando analisi, progettazione e implementazione), perfezionando le storie degli utenti e implementando il tuo sistema.
• Casi / scenari di test e criteri di accettazione dovranno essere chiariti allo stesso modo. Contribuiranno a ridurre l'incertezza su qualità e correttezza (tra l'altro).
• Alla fine, viene raggiunta una sufficiente certezza: 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, così come la comprensione da parte del cliente delle proprie aspettative e requisiti attraverso il suo coinvolgimento nel processo di sviluppo.

È un problema?

Più sketchi sono i requisiti iniziali, maggiore è l'incertezza e maggiore è il tempo necessario per eseguire i compiti. Quindi è solo una questione di chi farà il lavoro aggiuntivo e chi pagherà i costi.

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

" Non ci sono riunioni regolari programmate ". Bene, perché non inizi a programmare incontri 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 al momento della decisione. Ancora meglio se riesci a scrivere PERCHÉ qualcosa è stato deciso così com'era. Non importa se si tratta di un file sul tuo PC, una pagina nella tua wiki intranet o un taccuino sulla tua scrivania. Il registro protegge te e il progetto: quando un tester dice che un elemento "fallisce", puoi sottolineare che è stato deciso in questo modo con queste persone, e non è un tuo problema ma tra loro e i tester. Se questo porta al cambiamento delle specifiche, va bene, ma a questo punto non possono aspettarsi di rispettare una scadenza che avevano in mente - o devono tagliare l'ambito da qualche altra parte.

Un progetto senza requisiti chiari, leadership sciolta, nessuna definizione di done (DoD), nessuno disposto ad essere responsabile di assicurarsi di disporre delle informazioni necessarie per svolgere il proprio lavoro in modo tempestivo e rispettare la scadenza è una ricetta per il progetto fallimento.

Lo sviluppo iterativo non è un cattivo suggerimento, ma richiede una stretta collaborazione tra i proprietari dei prodotti e gli sviluppatori. Cerca di convincere qualcuno a rispondere dicendo "Sappiamo che avremo domande. Chi può essere regolarmente disponibile per assicurarsi che ricevano risposta in modo che la consegna del progetto non sia ritardata?" Pianifica orari regolari con qualcuno per rivedere i progressi e rimuovere gli impedimenti. Se non mostrano, o rifiutano, segui con gentile corrispondenza scritta e ritardi o mancate risposte dei documenti. Se i proprietari dei prodotti non sono disponibili, chiedi loro di fornire un rappresentante che possa esserlo.

Inoltre, un altro segno distintivo dello sviluppo iterativo è che un cambiamento nei requisiti richiede un cambiamento nella sequenza temporale. Non puoi impegnarti a rispettare una scadenza se non puoi sviluppare una sequenza temporale e non puoi sviluppare una sequenza temporale se non hai una buona idea di ciò che deve essere fatto. Invece di chiedere dogmaticamente una specifica, rivedere la specifica corrente, documentare eventuali domande che tu o il tuo team avete riguardo a come dovrebbe funzionare, pianificare il tempo con i proprietari del prodotto per discuterne e documentare le risposte. Quando hai finito, avrai le tue specifiche in base alle loro decisioni, che puoi quindi far concordare ai proprietari del prodotto (per iscritto). Lo scopo di una specifica è rimuovere l'ambiguità e creare un DoD, che è esattamente ciò che una sessione di domande e risposte potrebbe fornire. Se c'è un'opposizione a una specifica, non chiamarla una specifica.

Non credere a nessuno quando ti diranno che sarà facile . A volte è davvero così semplice come sembra, e potrei crederci se (e solo se ) conosco i proprietari dei prodotti abbastanza bene da confidare pienamente che i requisiti siano davvero semplici come dicono che sono, e le specifiche che sono stato fornito sono autoesplicativi (in caso contrario, pianifico una sessione di domande e risposte e la documento). Sono stato in troppe situazioni in cui facile dal punto di vista delle operazioni è incredibilmente difficiledal punto di vista dello sviluppo, o pensi di aver completamente fatto e senti le parole della 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 i test di accettazione si trasforma in "Oh, abbiamo dimenticato che alcuni di questi sono stati letti lateralmente in modo completamente incoerente, e alcuni hanno la dimensione della pagina sbagliata definita e alcuni hanno bisogno di queste tre pagine aggiunte, e abbiamo bisogno che tutte mostrino la stessa cosa. È davvero facile da risolvere, giusto? ".

Il punto è che potrebbe essere davvero facile e un incontro veloce potrebbe confermarlo, permettendoti di documentare tutti i presupposti e ottenere la conferma che sono accurati e corretti. Ti consiglio di alzarti in piedi per rimuovere gli impedimenti che devi scrivere nel codice di lavoro che soddisfi le loro aspettative, perché indipendentemente dal fatto che passi le dita dei piedi, qualcuno sarà probabilmente infelice alla fine comunque. Se sei persistente nel ricevere risposte alle domande e irritare qualcuno, se ne dimenticheranno quando consegnerai un ottimo prodotto in tempo che soddisfi i requisiti. Se non si ottengono chiarimenti e non si consegna, nessuno si ricorderà che ti hanno detto di non disturbarli.

Senza una specifica, hai un lavoro di squadra. Diventa agile.

Siediti con l'OP e ritaglia una / e piccola / e piccola / e storia / e. "Forniremo solo questa schermata, con solo questo pulsante che diventa 'bing!'". Accontentarsi di alcuni AC. Trasmetti la storia. Dimostrare la storia. Si scopre che i pulsanti dovrebbero essere rossi. Solleva un bug o una nuova storia. Consegnare i pulsanti che vanno bong e bang. E così via.

Specificare e distribuire in modo collaborativo piccole sezioni verticali che sono spesso dimostrate.

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

Ho trascorso diversi lavori facendo progetti proprio come hai delineato. Finché l'OP sa quali decisioni progettuali stai prendendo e perché le devi prendere, dovresti andare bene. Se, d'altra parte, non comprendono le decisioni di progettazione, è necessario premerle per almeno un documento scritto di prova di accettazione dell'utente.

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

Se nessun altro è disposto a scrivere quella specifica, gli sviluppatori devono scriverla. Quindi ottieni una specifica incompleta. Lo trasformi in una specifica completa (che significa "questo è quello che ho intenzione di implementare a meno che qualcun altro non mi dica di non"). Consegnate tale specifica agli stakeholder e date loro la possibilità di modificare la specifica. Solo un'opportunità per modificare le specifiche, non rovinarle per esempio dicendo "Non mi piace in questo modo". A quel punto, è la tua specifica, oppure possono fornire una specifica diversa, ma non rimuovere la specifica.

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: avevi una specifica e l'hai implementata. Se la specifica non è ciò che il cliente desidera, è direttamente responsabilità del proprietario del prodotto o del cliente che non potrebbe essere disturbato a scrivere una buona specifica.