User story come definizione del contratto?

1

Spesso mi viene chiesto di scrivere un documento dei requisiti per un nuovo lavoro. Scrivo i requisiti utilizzando le storie degli utenti. L'elenco dei requisiti viene quindi utilizzato come contratto con il cliente che indica la funzionalità che verrà consegnata. La tentazione diventa aggiungere ulteriori e più dettagli e sempre più storie nel tentativo di definire una specifica a tenuta stagna che escluda eventuali errori costosi.

Il problema è che le storie degli utenti non sembrano molto adatte a questo compito. Qualcuno può offrire qualche chiarimento sul ruolo delle user story? Ad esempio, la stessa user story è appropriata per il cliente, il programmatore e l'autore di una specifica funzionale?

Un po 'di regressione, forse sto chiedendo anche qual è il modo migliore per definire un contratto di ciò che sarà o non sarà consegnato in un progetto software?

    
posta Jack 09.08.2012 - 15:47
fonte

2 risposte

3

Anche il governo federale degli Stati Uniti non può scrivere specifiche del software a tenuta stagna.

C'è un conflitto naturale nel lavoro a contratto. Lo sviluppatore vuole essere pagato un importo ragionevole, mentre il cliente vuole sapere quale sarà il costo del software.

Se il cliente non ha idea di cosa vuole, il primo progetto dovrebbe consistere nello sviluppo di un documento dei requisiti. L'appaltatore e il cliente devono negoziare piccoli progetti realizzabili che alla fine raggiungono il progetto software di lavoro. In questo modo, entrambe le parti si sentono a proprio agio con il processo.

Se il cliente ha una buona idea di ciò che vuole, e l'appaltatore è ragionevolmente sicuro di poter sviluppare ciò che desidera il cliente, le immagini di schermate e report danno al cliente e allo sviluppatore una buona idea della portata di il processo di sviluppo.

    
risposta data 09.08.2012 - 16:30
fonte
1

Nei miei occhi semplicistici, ci sono 2 tipi generali di "artefatti" dettagliati che circondano "requisiti" e "ambito" di un progetto o una parte di un progetto.

  • Elementi necessari: ciò di cui il cliente ha bisogno / vuole. I requisiti sono in genere abbastanza utopici e cresceranno e cambiano man mano che l'attività del cliente cambia. User Story, output delle sessioni JAD, Use Case Models, wireframe delle schermate e altra documentazione focalizzata sul punto di vista del cliente, tutto in ordine, IMO. La dicitura è in genere nel dominio del cliente o degli utenti del sistema.
  • Manufatti relativi alle specifiche del contratto - "definizioni" stabili e dettagliate di tutti gli articoli che devono essere consegnati nell'ambito di un contratto. Questi includono sia "specifiche" funzionali che non funzionali (cioè qualità quali prestazioni, sicurezza, robustezza, scelta della tecnologia, ecc.). Una specifica non promette di soddisfare tutti i requisiti dei clienti, e spesso una specifica è limitata a un pezzo parziale del sistema (ad esempio una "generazione" o una iterazione RUP, ma probabilmente un po 'più di una Agile Sprint). Le specifiche sono di natura molto più tecnica (ad esempio includeranno definizioni di interfaccia, impegni di performance e possibilmente schermate "scollegate"). E come hai eluso, un contratto è spesso indicato come ciò che NON è incluso nella fornitura. Qualsiasi venditore sa che ai clienti odiano viene detto cosa non otterranno.

In un progetto a prezzo fisso, è una scelta suicida per lo sviluppatore essere d'accordo a livello di requisiti, ma allo stesso tempo, può essere molto difficile per uno sviluppatore recuperare il costo di una specifica, e spesso ti spaventerai clienti non sofisticati con specifiche - spesso lo guardano con scetticismo a causa del gergo tecnico e dell'angolo legale del documento. Ma con clienti sofisticati (ad esempio quelli utilizzati per gestire progetti altamente tecnici, ad esempio NASA, ESA, ecc.) Questo livello di definizione non è affatto un problema. Ma la formalità aggiuntiva ha un costo - i ritardi sono spesso sostenuti mentre la documentazione va avanti e indietro finché non viene finalizzata.

Di conseguenza, credo che l'idea generale sia quella di spostare gli impegni con la maggior parte dei clienti lontano dal prezzo fisso e verso una base di sviluppo del progetto a pagamento, utilizzando strumenti come Agile e Scrum per garantire che il team stia offrendo al massimo efficienza e trasparenza, e il team di solito è strettamente integrato con il cliente, ad es nei locali del cliente e / o con le risorse del cliente nel team. In questo modo, il cliente può 'vedere' che tutti stanno tirando il loro peso, il cliente ha la capacità di cambiare la direzione del progetto tra gli sprint e il software tangibile e testabile viene consegnato a intervalli regolari. In questo modo entrambe le parti possono eludere completamente le "Specifiche del contratto" e lavorare su una base di fiducia reciproca.

    
risposta data 10.08.2012 - 06:48
fonte

Leggi altre domande sui tag