È possibile adottare un approccio flessibile e agile ai progetti che richiedono stime sia del tempo impiegato che del tempo risparmiato?

Come qualcuno che ha lavorato in modo efficace con Agile prima, sto cercando di convincere i miei attuali datori di lavoro dei suoi benefici. Tuttavia, i dirigenti insistono sul fatto che manteniamo la capacità di effettuare stime anticipate al fine di valutare il valore commerciale dei progetti.

La maggior parte dei miei clienti sono interni e di recente mi è stato assegnato il compito di andare in giro per i team e chiedere loro idee sui processi aziendali da automatizzare. Dovevo quindi scoprire quanto tempo li impiegava, capire quanto tempo la soluzione avrebbe risparmiato e stimare il tempo totale di sviluppo. In questo modo, i manager potrebbero tentare di misurare l'efficacia di una soluzione in termini di tempo risparmiato.

Tuttavia, mi sembra che non ci sia modo di affrontare questo requisito in modo "agile". Requisiti flessibili significa che non solo le stime del tempo impiegato saranno errate, ma anche le stime del tempo potenziale risparmiato. Ho spiegato altrettanto, spiegato perché era probabile che fosse problematico, ma mi è stato detto che non era negoziabile.

La domanda su come vendere lo sviluppo Agile ai clienti (a cascata) ha alcuni consigli utili su come "vendere" Agile a clienti esterni. Non sto cercando di venderlo a clienti esterni: sto cercando di capire come conciliare al meglio le esigenze della gestione interna mantenendo una metodologia che credo funzioni bene.

Esiste un modo per affrontare questo compito in modo flessibile che mi consente di conservare almeno alcuni vantaggi Agile?

Come hanno affermato altre risposte, la direzione ha tutto il diritto di ottenere una stima di alto livello in anticipo di un progetto. Non sono irragionevoli per il tentativo di determinare il ROI.

Uno degli approcci che mi piacciono di Agile è che l'ambito di un progetto non è fisso. Inizialmente può essere dimensionato a livello di funzionalità ed epico, quindi il business può determinare il ROI in base a quali sono le funzionalità più importanti. Forse l'interfaccia utente di fantasia con campane e fischietti ha un basso valore commerciale, ma il motore del flusso di lavoro per la gestione dei sinistri ha un ROI elevato.

Quando metti insieme l'intero progetto, è più difficile rispettare il ROI che se ti concentri sulle funzionalità aziendali critiche desiderate.

Ecco un modo in cui ho fatto questo:

Prendi le pietre miliari di WBS e trasforma ognuna di esse in una funzionalità disponibile

Ciò consente di classificare il progetto in mini sottoprogetti con valore commerciale variabile. Ognuno di questi dovrebbe essere autonomo in termini di valore aziendale.

T-Shirt Taglia lo sforzo sulle caratteristiche

Questo è un modo molto semplice per avere un'idea approssimativa di quanto possa essere grande o coinvolta una particolare funzionalità. Forse le caratteristiche di basso valore hanno ancora un ottimo ROI se sembrano vincite facili.

Suddividere una caratteristica in storie

Esegui l'esercizio per trovare una piccola funzione ben compresa e suddividerla inizialmente in storie. Stimare queste storie per punti. Ora hai una base dove

Piccolo -> 40 punti

Questa sarà una base di confronto con altre funzionalità

Associare lo sforzo del punto narrativo a tutte le funzionalità

Confronta la tua piccola funzionalità con altre funzionalità. Per esempio,

La caratteristica media Y sembra che sia il doppio della dimensione e dello sforzo di una caratteristica piccola X di 40 punti storia.

Media caratteristica Y è probabilmente 80 punti trama. Continua fino a quando non hai i punti della storia stimati a un livello elevato per tutte le funzionalità.

Stimare la velocità della tua squadra

Guardando il tuo team di sviluppo, prova a determinare quanti punti della trama potrebbe effettivamente raggiungere questo team in un determinato sprint. Se hai precedenti progetti Agile come esempio con questo team, è un ottimo punto di partenza. Se non hai una tale storia alle spalle del team, passa attraverso una finta Sprint Planning con il tuo team in cui inizi a guardare la tua piccola funzionalità che hai dettagliato. Che tipo di stime orarie stanno dando le persone per i loro compiti su queste storie?

In base alla quantità di lavoro che la squadra pensa di poter consegnare in 2 settimane, usa quel numero totale di punti trama come velocità media potenziale della tua squadra!

Trova la data di completamento prevista

Se il tuo team nella finta pianificazione dello sprint si sente a tuo agio nel consegnare 25 punti storia in uno sprint e il tuo arretrato totale assomiglia a 300 punti storia per la versione d'oro Cadillac del tuo progetto, allora sembra che il tuo team impiegherebbe idealmente 12 sprint o 24 settimane per completa tutto.

Ora è banale trasformare il costo delle risorse della tua squadra in dollari a settimana per arrivare a un costo per ROI vs. Valore aziendale. La negoziazione può continuare su quali sono le caratteristiche più importanti e quindi la gestione del progetto diventa sostanzialmente un problema di zaino.

Questo non è un problema con "gestione". È un requisito assoluto essere in grado di stimare i costi e i benefici di qualsiasi potenziale progetto prima di iniziare. Altrimenti, come si potrebbe sapere cosa vale la pena fare (o tentare)?

Allora perché Agile?

Direi che usare i metodi Agile non significa scegliere l'incertezza. Piuttosto, Agile sostiene che l'incertezza è inevitabile e che le specifiche dettagliate e le stime dei metodi tradizionali introducono una falsa certezza, che può essere piuttosto costosa.

Alcuni punti chiave in termini di stima del tempo:

• Le modifiche ai requisiti durante un progetto sono inevitabili; Agile ne tiene conto piuttosto che fingere che non ci saranno cambiamenti.
• Le specifiche dettagliate spesso contengono difetti di progettazione che non vengono scoperti fino a quando nel progetto. Ciò può comportare maggiori cambiamenti in un progetto tradizionale rispetto a un progetto Agile.
• Una stima del tempo basata su "quanto grande penso sia l'intero progetto?" è probabile che sia preciso quanto sommare il tempo stimato per molti requisiti dettagliati.
• La cosa principale che porta a buone stime è un ciclo di stima, misurazione e revisione, che può essere applicato a qualsiasi processo coerente.
• La stima del "lavoro salvato" sarà guidata dai requisiti primari per il progetto piuttosto che dai dettagli, quindi dubito che Agile danneggerebbe molto la capacità di stimarlo.

Aggiornare:

Giusto per chiarire, la tua risposta ai tuoi capi sembra essere "Non possiamo stimare molto bene il tempo risparmiato o lo sforzo di sviluppo totale usando Agile, perché è flessibile". Penso che questo sia sbagliato. Credo che queste stime possano essere fatte altrettanto bene quando si utilizza un processo Agile, poiché l'incertezza è presente comunque. E, naturalmente, Agile consente un processo più flessibile e reattivo durante lo svolgimento del progetto.

Questa è sicuramente una delle parti più difficili dell'introduzione di Agile

"La direzione necessita ancora di stime temporali"

Il mio approccio è:

• Pad 300%. Il vecchio detto del 300% è utile quando ci si trova in una situazione in cui l'essere veramente agili a livello di gestione non accadrà. Questo non è un "approccio agile" forse, ma è un compromesso per questa situazione. Sarai in grado di venire avanti alcune volte - ma non contare su di esso!

• Chiedere una revisione basata sul lavoro svolto in quello che sarebbe il punto "a metà strada" del progetto. Proietta quando verrai completato in base al lavoro svolto. Quindi parla con il management e scopri quali sacrificare - funzionalità o qualità - dato che il tempo è fissato sulla base di ipotesi all'inizio del progetto.

• Assicurati di collaborare alle funzionalità fatte e alla qualità con la direzione in modo che prendano effettivamente quelle decisioni

• Segui il flusso di questo progetto e consenti che accadano le solite cose: scadenze mancate, qualità compromessa, dipendenti bruciati e stressati (e possibilmente defunti) che se ne vanno. Quando arriverà il prossimo progetto di fase, discutete di questi "effetti collaterali".

• Concentrati e dimostra i vantaggi di un approccio "vero" agile. Parla del miglioramento della qualità. Parla della possibilità di apportare modifiche alla fine della giornata fino a quando passano in produzione. Parlato di meno necessità di rilavorazioni. Parla di un minore debito tecnico che alla fine porterà lo sviluppo a gattonare. Analizzando il mondo reale, ad esempio, possiamo rimandare un cambio d'olio in qualsiasi giorno, ma rimandarlo abbastanza a lungo e il motore soffre, funziona male e alla fine soffia una canna.

• Mantieni aggiornato il tuo curriculum e collegati nel tuo profilo. Se non riesci a ottenere supporto di gestione dopo aver sollevato il caso alcune volte, vai avanti. Alcune organizzazioni non saranno elencate ai tuoi argomenti, quindi passa a quelli che lo fanno. Lo chiamò Darwinismo impiego;)

Penso che tu stia facendo false ipotesi sullo sviluppo Agile. Flessibilità e requisiti mutevoli sono letteralmente integrati nel Manifesto Agile .

Benvenuti a cambiare i requisiti, anche in ritardo di sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente.

I requisiti flessibili (leggi: in evoluzione) sono i benvenuti in Agile. Concesso se chiedi alla maggior parte degli sviluppatori che aggiungeranno un avvertimento che la modifica deve essere ragionevole. Chiedere a una squadra di costruire un gioco 3D e cambiare i requisiti per essere "sistema di controllo per un reattore nucleare" è un po 'troppo. Ma aggiungere, rimuovere o modificare i requisiti nell'ambito del progetto va benissimo.

La domanda è: come affrontare le mutevoli esigenze? La risposta tipica è quella di utilizzare brevi iterazioni in modo da poter apportare modifiche al corso in anticipo prima di perdere troppo tempo. Inoltre costringe il team a scomporre i requisiti in pezzi più piccoli in modo che tutti possano comprenderli meglio e implementarli in un ragionevole lasso di tempo e fatica.

La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.

Mi piace anche questo principio Agile. Normalmente si intende che una squadra dovrebbe sforzarsi di fornire solo quelle cose che sono necessarie attraverso un'efficienza spietata. Ad esempio: se il cliente pensa di aver bisogno di qualcosa ma sembra sospetto, scava. Forse gli utenti finali non ne hanno davvero bisogno, quindi il lavoro non dovrebbe essere fatto.

Tuttavia, penso che la tua domanda abbia colpito un altro aspetto di questo principio. Il software serve generalmente allo scopo di automatizzare un processo manuale. Il software stesso esiste per massimizzare la quantità di lavoro non svolto dagli utenti finali.

Misurare la quantità di lavoro che il software salverà gli utenti finali è sicuramente una metrica degna. L'ho misurato da solo nella mia carriera. In realtà è un componente critico di un'analisi costi / benefici: quanto sforzo il progetto software compirà per implementare, rispetto a quanto sforzo il prodotto finale salverà gli utenti finali.

Questo è assolutamente compatibile con la filosofia di sviluppo Agile (o qualsiasi altra) e il tuo management dovrebbe assolutamente comprarlo.

Sì, l'agilità ha alcuni vantaggi.

• Permette agli uomini d'affari di cambiare idea durante il volo.
• In qualche modo protegge l'azienda dalle stime perpetuamente negative dell'ingegnere.
• Fornisce valore presto e spesso, prima che venga raggiunta la visione finale.
• Ti risparmia alcuni dei costi di pianificazione anticipata, che spesso possono produrre piani sbagliati comunque .
• È fantastico. Destra?

Tuttavia, è ancora necessario fornire stime iniziali ragionevolmente accurate.

In caso contrario, stai effettivamente chiedendo all'azienda di investire nel tuo prodotto senza alcuna prova del fatto che il tuo prodotto valga addirittura l'investimento iniziale e, in alcuni casi, qualsiasi cosa.

E posso sentirlo ora.

L'ho già sentito prima. Sono abbastanza sicuro di averlo detto prima:

Oh - Ma Haow !? HAOW un semplice uomo mortale come me guarda i miei occhi nel destino di queste cose! Cose che solo gli dei stessi possono divinare e dirigere. Cose che gli uomini mortali possono solo sognare nei sogni più profondi e dimenticarsi di giorno in giorno! Oh tirannici tipi manageriali, HAOW possono essere soddisfatte tali esigenze !?

Usa la tua performance passata come guida e sii onesto .

• Abbia abbastanza una conversazione con l'interessato e / o l'utente finale per determinare quanto sia complesso il prodotto e / oi suoi componenti principali rispetto ad altri componenti principali su cui hai lavorato. Fai una stima iniziale relativa.
• Gonfia quel numero in base alla quantità storica di cambiamento dell'ambito e alla ricaduta del bug che hai visto storicamente.
• Applica la tua velocità storica alla stima puntuale per arrivare a una linea temporale approssimativa. E, applicare un ragionevole cono di incertezza .
• Rivedi la tua stima e comprensione del progetto. Assicurati di essere disposto a prendere una decisione sull'affrontare un progetto in base alla tua valutazione.

Infine, presenta il tuo cono di incertezza agli stakeholder, indica i tuoi presupposti e le tue preoccupazioni e lascialo a quello.

A parte ciò, suggerirei anche di elaborare un'euristica stima dei punti oggettiva per verificare la sanità mentale e / o le normali stime della tua squadra.

Puoi utilizzare questa stima come un ennesimo voto durante la pianificazione del poker o per convalidare la tua stima privata se stai andando da solo. Ad esempio, il mio team tende a stimare circa 1 punto al minuto di discussioni scoperte vagamente tecniche su una storia. Ciò è particolarmente utile se il tuo istinto ti dice che una storia ha 5 punti, ma ti ci sono voluti 20 minuti per capire cosa bisogna fare - di solito è un buon indicatore che ci sono ancora complessità e incomprensioni in agguato.

Non ho mai lavorato in nessuna società che fosse in grado di avere costantemente buoni tempi, né ho mai lavorato con nessuno che afferma di averlo fatto. La ricerca ti mostrerà che la stima è un problema irrisolto in tutto il settore.

Proverei a ottenere un riscontro sulla misurazione della velocità in base a punti astratti della trama, e se non riesci a farlo, riempirei di più le tue stime.

Agile è un'ottima soluzione per tutta una serie di problemi, ma nonostante ciò che alcuni evangelici suggerirebbero, non è l'unica soluzione e non è sempre la soluzione giusta.

Il tuo caso dichiarato non è semplicemente un problema agile:

Recentemente mi è stato assegnato il compito di andare in giro per i team e chiedere loro idee sui processi aziendali da automatizzare. Dovevo quindi scoprire quanto tempo li impiegava, capire quanto tempo la soluzione avrebbe risparmiato e stimare il tempo totale di sviluppo. In questo modo, i manager potrebbero tentare di misurare l'efficacia di una soluzione in termini di tempo risparmiato.

Hai il compito di determinare i costi e i benefici dell'automazione di alcuni processi aziendali, che non è un'attività agile soggetta a modifiche, è un problema specifico con una soluzione specifica. Producerai un elenco con un numero arbitrario di processi aziendali e per ciascuno di essi ci sarà un costo stimato per l'automazione, un costo stimato per non automatizzare e un beneficio stimato per l'automazione. La direzione si confronterà con il budget, le risorse, i requisiti e gli obiettivi strategici e determinerà quali (se ve ne sono) di questi processi da automatizzare. Se sei coscienzioso, avrai evidenziato le attività selezionate che hanno di per sé un ROI potenzialmente inferiore ma che ridurranno il costo di altre fasi migliorando così il ROI totale. Potresti anche aver identificato diversi modi per raggiungere l'automazione, incluso lo sviluppo su misura in-house e in outsourcing (utilizzando tecniche agili e / o a cascata), acquistando soluzioni standard, utilizzando fornitori di servizi di terze parti e così via. L'intero processo era molto di moda negli anni '90 quando era noto come reingegnerizzazione dei processi aziendali.