Misurazione dello stato di avanzamento in un progetto agile

Secondo James Shore, l'autore del libro "The Art of Agile Development", il successo ha tre aspetti: successo organizzativo, tecnico e personale. Se soddisfa tutti, allora può essere considerato un successo. Quello che segue è l'estratto dal libro.

Success is usually defined as delivering on time, under budget, and as specified. That's a flawed definition. Many late projects are huge successes for their organizations, and many on-time projects don't deliver any value. Instead, think in terms of organizational, technical, and personal success.

Agile development is no silver bullet, but it is useful. Organizationally, agile delivers value and reduces costs; technically, it highlights excellence and minimal bugs; personally, many find it their preferred way to work.

Puoi vedere più dettagli qui: link

Supponendo che il risultato ben definito sia una raccolta di storie di utenti, misurare il successo potrebbe significare una progressione costante del software che soddisfi le storie degli utenti.

Ci sono davvero solo due misure di successo per qualsiasi progetto, in realtà:

1. Il cliente è soddisfatto dei risultati? Questo è l'elemento più importante.
2. Quante vittime del team di progetto sono risultate dal progetto? Meno è, meglio è

Questo è tutto.

Indipendentemente dalla velocità o dalle effettive user story completate o qualcosa del genere, non è la vera misura del successo su un progetto agile (in realtà, qualsiasi progetto) che l'utente ha accettato il software? Forse se ti concentri maggiormente sull'illustrazione di uno scenario in cui il proprietario del tuo prodotto ha approvato alcune storie, non ha approvato gli altri, forse ne ha aggiunto o modificato alcune e ha raggiunto un punto di accettazione del progetto come "fatto" che potrebbe essere più illustrativo di solo dicendo qualche equivalente di "non è fatto fino a quando tutti i requisiti non superano i test".