La mancanza di requisiti funzionali è agile?

Oggi tutti vogliono essere agili. In ogni squadra con cui ho lavorato, la forma dell'agile era diversa. Alcune cose sono comuni - come stand-up giornalieri o pianificazione, ma altre parti variano in modo significativo.

Nella mia squadra attuale c'è un dettaglio che trovo inquietante. È la mancanza di requisiti funzionali. Non solo non esiste una forma scritta di aspettative, ma anche nei compiti è piuttosto vagamente definito ciò che deve essere fatto.

L'obiettivo del progetto è quello di riscrivere il vecchio sistema usando le nuove tecnologie. Anche il vecchio sistema non ha alcuna documentazione ragionevole. Sicuramente non ne esiste uno aggiornato. La descrizione dei requisiti degli imprenditori è: facciamolo in una nuova implementazione allo stesso modo di quelli precedenti. Sembra ragionevole ma non lo è. Il vecchio sistema è una specie di codice spaghetti e l'estrazione dei requisiti aziendali è costosa. Sembra che la situazione influisca negativamente sulla pianificazione. Di sicuro è soggetto a errori e bug nella nuova implementazione (omettendo alcuni dettagli).

Pertanto sto pensando: è davvero agile non avere requisiti aziendali in caso di riscrittura del vecchio sistema?

Se mancano o meno requisiti funzionali è agile, è una ricetta per il disastro. Non è possibile ricostruire un sistema quando non si conosce il funzionamento di tale sistema.

Devi dire al proprietario dell'azienda che non hai idea di come funzioni il vecchio sistema.

L'opzione migliore è collaborare con il proprietario dell'azienda o con pochi utenti esperti per comprendere i processi aziendali in gioco e sviluppare i propri test di accettazione. Se riesci a lavorare con alcuni utenti finali, potresti ricevere più feedback su come funziona il vecchio sistema.

In caso contrario, dovrai raccogliere alcuni test esplorativi in ​​un ambiente non di produzione per raccogliere i tuoi requisiti. Molte volte quando un imprenditore dice "fallo funzionare come quello vecchio" sono vincolati in tempo e non sono in grado di aiutarti come dovrebbe fare un imprenditore. Hai bisogno dell'esperienza di alcuni utenti esperti o di numerosi test manuali da parte tua per capire come funziona il vecchio sistema.

Informare l'imprenditore che la mancanza di requisiti e la comprensione del vecchio sistema aumenterà notevolmente il tempo necessario per ricostruirlo - circa il triplo del tempo o più. Di fronte all'aumento della tempistica e dei costi, il proprietario dell'azienda ti fornirà le competenze necessarie per raccogliere i requisiti più rapidamente o deciderà in questo momento che la riscrittura non è economicamente fattibile.

Otterrai uno dei seguenti:

• Requisiti adeguati e un ciclo di sviluppo più rapido
• È ora di raccogliere i requisiti e ricostruire il software
• Un nuovo progetto che non finirà per essere un segno nero nella tua carriera

Agile non cambia la necessità di requisiti funzionali, ma generalmente cambia il modo in cui li raccogli . Il modo non agile è che qualcuno esegua un lungo processo, quindi ti fornisca una sorta di documento contenente tutti i requisiti per il sistema.

Il modo agile per raccogliere i requisiti è lavorare insieme per specificare i requisiti per un piccolo incremento del sistema, crearlo, quindi ottenere feedback e fare l'incremento successivo. Nella tua situazione in cui stai riscontrando problemi nel far avviare il processo agli imprenditori, inizierei impiegando forse mezza giornata a esplorare la parte del vecchio sistema su cui vuoi lavorare in seguito e generare un elenco di domande sui requisiti.

Quindi siediti con i proprietari della tua attività e fai loro le domande. Ad alcune domande sarà facile rispondere, altre sono più facili da rispondere guardando il codice e altre sono difficili da rispondere in entrambi i modi. Rompi le domande difficili in pezzi sempre più piccoli fino a raggiungere qualcosa a cui è possibile rispondere.

L'obiettivo è quello di ottenere una risposta sufficiente alle tue domande al fine di creare qualcosa, ottenere feedback e riavviare il processo. Ricorda, più piccole sono le modifiche e più breve è il tuo ciclo di feedback, meno è un grosso problema se costruisci la cosa sbagliata.

Catturare i requisiti è una parte essenziale di qualsiasi progetto software (di successo). Ma scrivere una specifica dei requisiti non lo è.

• Un approccio incentrato sulla documentazione può finire come un gioco di sussurri cinesi: un esperto in materia esprime un requisito, un analista lo scrive, uno sviluppatore cerca di scrivere qualcosa che soddisfa la descrizione dell'analista, l'utente finale è confuso perché il software non lo fa risolvere il loro problema.

  Le tecniche agili suggeriscono che gli sviluppatori dovrebbero raccogliere i requisiti direttamente dagli esperti in materia, di solito gli utenti finali. Esistono varie tecniche per farlo, ad esempio parlando di uno scenario esemplificativo con la PMI. Gli sviluppatori sono bravi a individuare casi limite e a chiedere alle PMI di chiarire come dovrebbe comportarsi il software in quel caso limite.

• Invece di raccogliere tutti i requisiti in anticipo (e quindi rischiando grandi equivoci), i team agili probabilmente inizieranno con una piccola parte di requisiti, costruiranno un prototipo e lo useranno per raccogliere feedback per la prossima iterazione.

• Man mano che la comprensione dei requisiti si sposta nel tempo, una specifica dei requisiti statici non sarà aggiornata. Come può essere prevenuto?

  Esprimendo i requisiti come test eseguibili. Si scopre che "specifica leggibile" e "test eseguibili" non sono concetti esclusivi, ma possono finire per essere lo stesso documento. Ad esempio Cetriolo e altre idee fuori dallo spazio BDD possono essere molto utili qui.

Nel caso in cui si riscriva un vecchio sistema, il sistema originale può essere un'ottima fonte di requisiti. Ma quali aspetti sono rilevanti? Le sue funzionalità di nicchia vengono persino utilizzate? Quali bug devono essere reimplementati per la compatibilità? Di solito non c'è soluzione alternativa per parlare con gli utenti finali.

Avere un sistema di lavoro in giro può anche essere molto utile per testare il nuovo software, ma questo non è correlato ad alcuna preoccupazione agile.

Si noti che i progetti a tempo determinato a tempo determinato con scadenze incombenti sono l'antitesi di agile. L'approccio agile normale è quello di scegliere un frammento di funzionalità e prima distribuirlo, quindi iterare. Le cose più importanti vengono fatte per prime, quelle meno importanti in seguito (o mai). Se tutto è importante e DEVE essere fatto APPENA POSSIBILE, allora nulla è importante e è improbabile che il progetto fornisca qualcosa.

Nella tua situazione, la mancanza di requisiti non è una caratteristica agile ma piuttosto un caso medio di disfunzione organizzativa. Se vuoi che il progetto abbia successo, dovrai trovare un modo per eliminare questa disfunzione. Ad esempio, esortare il proprietario a non scrivere un documento completo sui requisiti, ma provare a organizzare una riunione in cui spiegano i propri requisiti per la funzionalità più importante. Puoi guardare il vecchio sistema per i dettagli. Quindi implementare quella funzione e iterare.

Ecco come l'abbiamo fatto. Abbiamo parlato con i proprietari. Abbiamo parlato con i gestori. Abbiamo parlato con gli utenti che svolgono il lavoro. Ciò che abbiamo trovato sedendoci alla scrivania di un utente e guardando (e ponendo domande) è stato incredibilmente utile. I gestori sapevano con quali utenti dovremmo sederci.

Abbiamo scoperto che alcune parti del sistema funzionavano davvero molto bene e potevamo facilmente scrivere abbastanza requisiti per iniziare la progettazione, la codifica e i casi di test e così via, ma altre parti avevano alcune brutte soluzioni che gli utenti sul pavimento stavano usando, di cui i gestori e i proprietari non erano a conoscenza. Per queste parti del vecchio sistema, siamo tornati al business e abbiamo parlato del flusso di lavoro e dei processi per un po 'prima di poter definire quali fossero i compiti più piccoli e quindi suddividerli in unità che il nostro metodo agile desiderava.

Quindi, sebbene Agile potesse rapidamente decollare su alcune parti del sistema, altre dovevano avere un po 'più di pensiero e documentazione prima di poter iniziare.

Raccogliere i requisiti in un framework Agile e nessuno ha menzionato User Story? Una user story è essenzialmente una definizione di alto livello di ciò che il software dovrebbe essere in grado di fare. In genere, qualsiasi feedback o richiesta proveniente dall'azienda o dall'utente finale può essere scritto come user story. ... Puoi pensare ai criteri di accettazione come ai requisiti funzionali che supportano una user story.

Questa domanda suggerisce ciò che è andato storto nel movimento agile. Non è colpa della persona che pone la domanda; Cado in questa trappola tutto il tempo perché anni di vita aziendale mi hanno insegnato.

La trappola di cui sto parlando sta pensando che esiste un modo Agile prescritto e corretto per fare le cose. Ciò potrebbe essere dovuto al fatto che la gente pensa che Agile esista. Non puoi fare Agile più di quanto tu possa fare Pragmatic.

Non avere "specifiche funzionali" o altro, sembra preoccupante, ma potrebbe non esserlo. Di quanti dettagli hai bisogno per iniziare? Sicurezza e prestazioni sono quelli ovvi che sono noti in anticipo e si applicano fino in fondo. Altrimenti, è un motore di valutazione delle opzioni o un'app per l'orologio?

Ci saranno continui rilasci, discussioni, apprendimento, ritorno e modifica del software? State voi costruendo morbido ware o hardware?

Gli sviluppatori che lavorano in un processo a cascata spesso non vengono coinvolti fino a una fase successiva, il che è un problema. Coinvolgerli prima o dall'inizio significa che sono a conoscenza di cose poco chiare, indefinite e semifornate, il che sembra sconvolgere gli sviluppatori di lunga data, quando in realtà parte del loro lavoro è porre domande, come "quali sono i requisiti funzionali per questa cosa che costruiremo? "

Identificare i buchi nel piano non riguarda la ricerca di errori, è solo lo sviluppo di software.

Per questo motivo, adoro la risposta di Guy.