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

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

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

Quando si raggruppa l'intero progetto, è più difficile incontrare il ROI piuttosto che concentrarsi sulle funzionalità aziendali critiche desiderate.

Ecco un modo in cui ho fatto questo:

Prendi le tue pietre miliari WBS e trasforma ognuna di queste in una funzione consegnabile

Ciò consente di classificare il progetto in mini sottoprogetti che hanno un valore aziendale variabile. Ognuno di questi dovrebbe stare in piedi da soli in termini di valore aziendale.

T-Shirt Misura lo sforzo sulle funzioni

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

Analizza una caratteristica in storie

Segui l'esercizio per trovare una piccola funzionalità che sia ben compresa e suddividila inizialmente in storie. Stimare queste storie per punti. Ora hai una base in cui

Small -> 40 points

Questa sarà una base di confronto con altre caratteristiche

Associare lo sforzo del punto di storia a tutte le funzioni

Confronta la tua piccola caratteristica con altre funzionalità. Ad esempio,

Medium Feature Y feels like it is twice the size and effort of Small Feature X of 40 story points.

Caratteristica media Y è probabilmente 80 punti storia. Continua fino a quando i punti della storia sono stimati a un livello elevato per tutte le funzioni.

Stima la velocità del tuo team

Guardando il tuo team di sviluppo, cerca di determinare quanti punti della storia potrebbero portare 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 storia del genere dietro al team, passa a 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 le persone danno per i loro compiti su queste storie?

In base a quanto lavoro il team pensa di poter offrire in 2 settimane, usa quel numero totale di punti storia come la velocità potenziale media della tua squadra!

Trova la data di completamento proiettata

Se la tua squadra nella pianificazione di sprint simulati si sente a suo agio nel realizzare 25 punti in uno sprint, e il tuo accumulo totale sembra di 300 punti nella versione oro Cadillac del tuo progetto, sembra che il tuo team impiegherebbe idealmente 12 sprint o 24 settimane per completare tutto.

Ora è banale trasformare il costo delle risorse del tuo team in dollari a settimana per arrivare a un costo per il ROI rispetto al valore aziendale. La negoziazione può continuare su quali sono le caratteristiche più importanti e quindi la gestione del progetto diventa fondamentalmente un Problema dello zaino.

Questo non è un problema con "gestione". È un requisito assoluto essere in grado di stimare il costo e il beneficio di qualsiasi potenziale progetto prima di iniziare. Altrimenti, come qualcuno dovrebbe sapere cosa vale la pena (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 tiene conto di questo piuttosto che fingere che non ci saranno cambiamenti.
• Le specifiche dettagliate spesso contengono difetti di progettazione che non sono scoperti fino a quando non sono stati inseriti nel progetto. Questo può significare cambiamenti più grandi in un progetto tradizionale rispetto a uno Agile.
• Una stima del tempo basata su "quanto grande di una cosa penso che sia l'intero progetto?" è probabile che sia preciso esattamente come 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.

Aggiornamento:

Giusto per chiarire, la tua risposta ai tuoi capi sembra essere "Non possiamo stimare il tempo risparmiato o lo sforzo di sviluppo totale molto bene 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 esiste comunque. E, naturalmente, Agile consente un processo più flessibile e reattivo man mano che il progetto si sviluppa.

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

"La gestione richiede ancora stime temporali"

Il mio approccio è:

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

• Chiedi una revisione basata sul lavoro svolto in quello che sarebbe il punto "a metà strada" del progetto. Progetto quando saresti completo in base al lavoro svolto. Quindi parla al management e passa a quello che sacrificare - funzionalità o qualità - dato che il tempo è fissato in base alle ipotesi all'inizio del progetto.

• Assicurati di collaborare alle funzionalità e alla qualità con la gestione in modo che prendano effettivamente queste decisioni

• Vai con il flusso per questo progetto e lascia che accadano le solite cose: mancate scadenze, qualità compromessa, dipendenti bruciati e stressati (e possibilmente defunti) che se ne vanno. Quando verrà il prossimo progetto di fase, discuti questi "effetti collaterali".

• Concentrati e dimostra i vantaggi di un approccio "vero" agile. Parla del miglioramento della qualità. Parliamo della possibilità di apportare modifiche alla fine della giornata fino al loro passaggio in produzione. Ho parlato di meno bisogno di ri-lavoro. Parliamo di un indebitamento meno tecnico che alla fine porterà lo sviluppo a una scansione. Crea analogie con il mondo reale, ad esempio, possiamo rimandare un cambio di petrolio in qualsiasi giorno, ma rimandalo abbastanza a lungo e il motore soffre, si comporta male e alla fine soffia una canna.

• Mantieni aggiornato il tuo curriculum e il tuo profilo collegato. Se non riesci a ottenere supporto gestionale dopo aver risolto il tuo caso alcune volte, vai avanti. Alcune organizzazioni non verranno elencate ai tuoi argomenti, quindi spostati su quelle che fanno. Si chiama occupazione del darwinismo;)

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

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

I requisiti flessibili (leggi: modifica) sono i benvenuti in Agile. Concesso se chiedi alla maggior parte degli sviluppatori, aggiungeranno un avvertimento che il cambiamento deve essere ragionevole. Chiedere a una squadra di costruire un gioco 3D, quindi 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 è perfettamente corretto.

La domanda è come affrontare i mutevoli requisiti? la risposta tipica è quella di utilizzare brevi iterazioni in modo da poter effettuare aggiustamenti di rotta in anticipo prima di perdere troppo tempo. Inoltre, costringe il team a scomporre i requisiti in parti più piccole, in modo che tutti possano comprenderli meglio e implementarli in tempi e sforzi ragionevoli.

Simplicity--the art of maximizing the amount of work not done--is essential.

Mi piace anche questo principio Agile. Normalmente si intende che una squadra dovrebbe sforzarsi di fornire solo quelle cose che sono necessarie attraverso l'efficienza spietata. Ad esempio: se il cliente pensa ha bisogno di qualcosa ma sembra un pesce, scavare intorno. 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 generalmente ha lo 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. Ho misurato questo me stesso nella mia carriera. In realtà è un componente critico di un'analisi costi / benefici: quanto impegno dovrà intraprendere il progetto software rispetto a quanto sforzo il prodotto finale salverà gli utenti finali.

Questo è assolutamente compatibile con la filosofia di sviluppo Agile (o qualsiasi altra) e la tua gestione dovrebbe assolutamente comprarla in questo.

Sì, l'agilità ha alcuni vantaggi.

• Permette agli uomini d'affari di cambiare idea a metà del volo.
• Protegge il business contro le stime perennemente negative dell'ingegnere.
• Fornisce valore presto e spesso, prima che la visione finale sia raggiunta.
• Ti risparmia alcuni del costo di pianificazione iniziale, che spesso può produrre un piano comunque .
• È fantastico. Giusto?

Tuttavia, è ancora necessario fornire preventivi preventivi ragionevolmente accurati.

Se non lo fai, stai effettivamente chiedendo all'azienda di investire nel tuo prodotto senza alcuna prova che il tuo prodotto valga addirittura l'investimento iniziale - e in alcuni casi, qualsiasi cosa.

E ora posso ascoltarlo

L'ho già sentito prima. Sono piuttosto sicuro di aver detto prima:

Oh - Ma Haow !? HAOW fa un semplice mortale come me stesso che guarda i miei occhi nel destino di queste cose! Cose che solo gli dei stessi possono divinizzare e dirigere. Cose che gli uomini mortali possono solo sognare nei più profondi sonnacchi e dimenticare la scia del giorno! Oh tipi gestionali tirannici, HAOW può soddisfare tali richieste!?

Utilizza le tue prestazioni passate come guida e sii onesto .

• Avere abbastanza di una conversazione con lo stakeholder e / o l'utente finale per determinare quanto il prodotto e / o i suoi componenti principali siano relativi ad altri componenti principali su cui hai lavorato. Crea un iniziale, stima del punto relativo.
• Gonfia quel numero in base alla quantità storica di modifiche dello scope e di bugout che hai storicamente visto.
• Applica la tua velocità storica alla stima del punto per arrivare a una linea temporale approssimativa. E applica un ragionevole cono di incertezza .
• Riesaminare la stima e la comprensione del progetto. Sii sicuro che tu vorresti prendere una decisione su come affrontare un progetto in base alla tua valutazione.

Infine, presenta il tuo cono di incertezza agli stakeholder, enuncia le tue ipotesi e preoccupazioni, e lascia perdere.

Per inciso, suggerirei anche di formulare un'euristica stima dei punti per valutare l'equilibrio e / o le stime normali della tua squadra.

Puoi usare questa stima come voto Nesimo durante la pianificazione del poker, o per convalidare il tuo preventivo privato se stai andando da solo. Ad esempio, il mio team tende a stimare circa 1 punto al minuto di discussione approssimativa e tecnica su una storia. Questo è particolarmente utile se il tuo istinto ti dice che una storia è di 5 punti, ma ti ci sono voluti 20 minuti per capire cosa deve essere fatto - di solito è un buon indicatore che ci sono ancora complessità e incomprensioni in agguato.

Non ho mai lavorato in nessuna azienda che fosse in grado di avere costantemente stime di buon tempo, né ho mai lavorato con nessuno che affermasse di averlo fatto. La ricerca ti mostrerà che la stima è un problema irrisolto in tutto il settore.

Cercherò di ottenere un buy-in sulla misurazione della velocità basandomi su punti astratti della storia, e se non puoi farlo, risponderò di più alle tue stime.

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

Il tuo caso dichiarato non è semplicemente un problema agile:

I was recently tasked with going round teams and asking them for ideas on business processes to automate. I was then to find out how much time this was taking them, work out how much time the solution would save and estimate the total development time. That way, managers could attempt to measure how effective a solution was likely to be in terms of time saved.

Hai il compito di determinare i costi e i vantaggi dell'automazione di alcuni processi aziendali, che non è un compito agile soggetto a modifiche, è un problema specifico con una soluzione specifica. Si produrrà una lista con un numero arbitrario di processi di business e per ognuno di essi ci sarà un costo stimato per l'automazione, un costo stimato di non automazione e un vantaggio stimato dell'automazione. La gestione corrisponderà a ciò contro i budget, le risorse, i requisiti e gli obiettivi strategici e determinerà quali (se ve ne sono) di questi processi automatizzare. Se sei coscienzioso, avrai evidenziato attività selezionate che hanno un ROI potenzialmente basso in sé ma che ridurranno il costo di altre fasi, migliorando così il ROI totale. Potresti aver identificato diversi modi di realizzare l'automazione, incluso lo sviluppo su misura interno ed esterno (usando tecniche agili e / o a cascata), l'acquisto di soluzioni a scaffale, l'utilizzo di fornitori di servizi di terze parti e così via. L'intero processo era molto di moda negli anni '90 quando era conosciuto come reingegnerizzazione dei processi di business.