DevOps in 5 minuti: cos'è una User Story?

Che cos'è il DevOps pragmatico? È solo un modo accattivante per dire che consegniamo con il processo minimo praticabile utilizzando tecniche snelle per eliminare gli sprechi dal sistema. Se ci aiuta a fornire e supportare il nostro prodotto, va bene. In caso contrario, lo rimuoviamo.

Uno dei maggiori problemi che abbiamo riscontrato in molte aziende che passano allo sviluppo agile è il fatto che le persone che guidano il cambiamento in genere non sono attualmente sviluppatori. Molti hanno seguito corsi su "Agile" per diventare "certificati", ma gli esempi del mondo reale di cui le persone hanno bisogno per tradurre i loro processi attuali in consegne con maggiore agilità raramente provengono dai libri. Quanti dei firmatari del Manifesto per lo sviluppo agile del software sono certificati?

Hai sentito variazioni di discussioni come questa? Io ho.

Dev: "Cos'è una user story"

Certified Agile Coach: “Incontra INVEST, ovviamente. Inoltre, ha una persona e una dichiarazione di valore.

Dev: "Investire?"

CAC: "Indipendente, negoziabile, prezioso, stimabile, piccolo e verificabile"

Dev: "OK, quindi l'azienda non utilizzerà nulla finché non sarà tutto finito, quindi l'intera applicazione è una user story?"

CAC: “Beh, no. È più piccolo di quello, ovviamente!'

Dev: "Beh, non posso negoziare nulla di più piccolo e altrimenti non ha alcun valore quindi.."

E così via, fino a quando il contratto non scade e il Certified Coach riscuote il compenso e inizia il contratto successivo. Subito dopo arriva la conversazione sul "punto della storia".

Il risultato di ciò sono i team seduti in riunioni che analizzano le parole e escogitano "Come sviluppatore, voglio un database, in modo che l'applicazione possa archiviare i dati" e poi discutono su come stimarlo.

In qualità di professionista di Pragmatic DevOps, sono necessarie definizioni testabili per integrare efficacemente gli sviluppatori che sono nuovi alla distribuzione continua. Per raggiungere gli obiettivi di CI/CD e fornire risultati prevedibili, dobbiamo fornire piccoli lotti di lavoro che possiamo dimostrare e ottenere feedback . È anche molto importante essere in grado di comunicare in modo efficace utilizzando un linguaggio onnipresente comprensibile a tutte le parti interessate. In tal senso, utilizziamo le seguenti definizioni quando aiutiamo i team e le parti interessate esterne a comprendere funzionalità, storie e attività.

Funzionalità: un comportamento completo che implementa un nuovo processo aziendale e consiste in una o più storie utente . Se la tua funzionalità è troppo grande, rischi di ritardare una modifica che potrebbe aggiungere valore immediatamente, quindi mantieni le funzionalità piccole quanto ha senso.

User Story: la più piccola modifica che risulterà in un cambiamento di comportamento osservabile dall'utente e consiste in una o più attività . Se il cambiamento non è osservabile, non può essere dimostrato. Se non può essere dimostrato, non c'è un ciclo di feedback e non puoi adattarti con agilità.

Attività: la più piccola modifica distribuibile in modo indipendente. Esempi: modifica della configurazione, nuovo test, nuova funzione testata, modifica della tabella, ecc. Un'attività può implementare o meno modifiche osservabili, ma è sempre indipendente da altre modifiche. Se un'attività non può essere distribuita senza un'altra attività, modifica le priorità o scopri come utilizzare i flag di funzionalità.

Mantenere un linguaggio semplice e ridurre al minimo i modi in cui le definizioni possono essere interpretate è la chiave per una formazione efficace delle competenze. Ti consigliamo di iniziare un glossario e testare le definizioni. Se causano confusione, esegui il refactoring.

Prossimamente: non hai bisogno di punti storia!