Sta avendo delle date di consegna fisse per gli elementi un modo di lavorare "agile"?

Se ci si aspetta che determinate serie di funzionalità siano consegnate in date specifiche, allora no, questa non è una gestione agile del progetto. La gestione del progetto agile è di natura empirica. Le proiezioni non sono fatte sulla base dei desideri dei dirigenti, ma piuttosto sull'analisi delle prestazioni precedenti.

La tua descrizione corrisponde a quella che considero un'agile cargo-cult. L'attenzione si concentra sui processi e sulle cerimonie specifici e non sui concetti chiave della gestione del progetto basata sull'evidenza. Potresti avere un po 'di fortuna nel capire agli uomini d'affari se ti riferisci a Lean o TPS . Il vero problema che devi risolvere qui è ottenere la gestione oltre la loro paura dell'ignoto. La risposta giusta per i dirigenti è "non possiamo dirvi ora quando le cose verranno fatte, ma una volta iniziato a fornire valore, possiamo costruire delle proiezioni basate sulla nostra esperienza". Gli sviluppatori tendono a dire cose come "è fatto quando è fatto" e "non so quando sarà fatto". I manager non diranno cose del genere ai dirigenti, li farà sembrare dei noccioli. Stanno semplicemente facendo quello che sanno.

Molto probabilmente, il piano fallirà e dovrà essere rivisto. Il più grande rischio per la squadra è che ci sarà una grande spinta per rispettare le scadenze e la qualità ne risentirà. Ad un certo punto non sarai sul bersaglio (molto probabilmente, sarà la prima scadenza) e ci sarà una spinta per colpire quella data. Ci si aspetta uno straordinario e ci saranno pressioni per tagliare gli angoli (salta il test unitario, le recensioni del codice, ecc.) Questa è una pendenza scivolosa e una volta che inizi questo percorso, è un po 'una spirale discendente e le cose diventeranno brutte. La produttività peggiorerà man mano che il progetto continuerà in questo modo.

Se riesci a convincere il team di sviluppo a presentare un fronte unificato, dovresti davvero respingere e mantenere la linea sulla qualità. La mia esperienza è che i project manager tendono a pensare che l'output del software sia lineare. Cioè, ogni periodo X produrrà Y 'precentage completo'. Cioè, se non sei "completo al 50%" entro la metà del tempo concesso, i klaxon iniziano a suonare a tutto volume. In realtà, se lo stai facendo bene, la prima funzione tende a richiedere molto più tempo della 50a funzione (di dimensioni simili). Se riesci a superare quel periodo iniziale di crisi di pericolo ("cosa sta succedendo?", "I don" per vedere qualcosa da fare! ") probabilmente starai bene.

Benvenuto nel mondo reale.

C'è uno stile di business più vecchio, che io tendo a chiamare derisorio "sviluppo tradizionale" e poi c'è un nuovo stile, "sviluppo agile". Se cerco di trattare questi come ideali opposti, vediamo una divisione lineare nel mezzo: i piani e le esigenze vanno nella colonna tradizionale, la scoperta e l'evoluzione vanno nella colonna agile. È pulito, ordinato e sbagliato.

In realtà, il business è una ricerca del mezzo felice tra i due. È facile dimostrare che entrambi gli estremi in realtà cadono in superficie. Noi che amiamo Agile dimostriamo avidamente tutte le questioni del puro ideale dello sviluppo tradizionale, e ce ne sono molte che possono mostrare i molti modi in cui l'Agile cade a pezzi. Le aziende agili di successo sono quelle che trovano il loro particolare equilibrio tra i due. Le aziende tradizionali di successo sono quelle che trovano il loro particolare equilibrio tra i due. Non puoi averne uno senza l'altro.

Anche il nostro benedetto processo SCRUM mostra un equilibrio tra i due. Mentre c'è un chiaro tentativo di massimizzare l'agilità, ci sono alcuni compromessi chiave fatti. Ad esempio, il Product Owner ha il potente lavoro di advocating per tutti i clienti. SCRUM intenzionalmente non specifica come funziona l'interazione. Evita intenzionalmente il fatto che tutti debbano essere pagati alla fine della giornata. E 'compito del Product Owner creare l'illusione che ciò non abbia importanza.

(È interessante notare che la pura agilità funziona alla grande, purché non vieni pagato fino a quando non produci un prodotto, e non hai accesso a informazioni proprietarie finché non ti viene conferito. Penso che i soli ingegneri del software che stanno bene con questo mestiere sono gli imprenditori)

Quindi la direzione ha dettato quali caratteristiche saranno presenti e quando dovranno esserci. Va bene. Una frase che ho sentito è "il cliente sceglie il cosa e il quando, il produttore sceglie chi e il come". Sei stato registrato per "cosa" e "quando". Non hanno dichiarato nulla su chi o sul come, oltre a offrirti la possibilità di usare "Agile" come tuo. Non resta che aiutare la direzione a capire quante persone avranno bisogno di assumere per soddisfare le loro esigenze.

In un mondo perfetto, la tua azienda è agile dall'esterno. Interagisce con i suoi clienti in modo agile, permettendo agli sviluppatori di sviluppare agilmente per loro. Tuttavia, molto spesso l'azienda deve interagire con l'esterno sviluppandosi agilmente all'interno. In mezzo c'è sempre una serie complessa di compromessi, unica per ciascuna azienda.

Personalmente, considero questa situazione un banco di prova per chiunque pensi di capire lo sviluppo agile. Ad un certo punto in futuro, dovrai sviluppare un prodotto per una scadenza e quella coppia prodotto / scadenza sarà relativamente fissa. Se un prodotto / scadenza fissa frantuma il tuo processo, puoi davvero dire che sei stato Agile in primo luogo?

Il mio consiglio: non pensare a questo come a una cascata. Tu controlli ancora il "come". Puoi ancora fare tutti gli sprint rapidi e la prototipazione flessibile per cui Agile è così famoso. Devi solo essere consapevole che la gomma incontra la strada e devi consegnarla. Questo è il mondo reale, non il mondo ideale. Sarebbe stato meglio per loro chiederti in primo luogo? Sicuro. Potrebbe non essere stata la tua chiamata. Ci possono essere migliaia di ragioni legate al business per farlo a modo loro che semplicemente non capisci completamente. Sentiti libero di respingerli, ma capisci che potrebbero avere una buona ragione per quello che hanno fatto.

Agile non ti impedisce di pianificare le pietre miliari (E.g pubblicheremo V 1.0 in 3 mesi), ma ciò che accade in ciascuna pietra miliare non può essere risolto.

Penso che il modo in cui dovresti reagire dipende dalla natura del progetto. Se il progetto è quello di inviare un uomo sulla luna entro il secondo trimestre 2017, tutti sarebbero d'accordo che è destinato a fallire. Se pensi di poter consegnare un MVP entro la fine del secondo trimestre del 2017, dovresti lavorare sullo sprint per sprint.

Se la direzione ritiene che la tua squadra stia facendo del suo meglio e puoi mostrare i progressi con ogni sprint, dovresti essere in grado di negoziare per più tempo.

OGNI progetto commerciale pertinente ha dei vincoli:

• Ora
• Risorse
• Un set di funzionalità minimo previsto

Questo non è altro. Sviluppare agile non significa "la gente ci paga denaro, così possiamo sviluppare tutto ciò che vogliamo per quando è pronto" - avrai sempre un po 'di tempo. Ci sarà sempre qualche data con alcuni requisiti minimi e se non saranno soddisfatti il progetto verrà annullato e verrà chiamato un fallimento. A volte possono essere impliciti, quindi il manager sa "Se non ho un'interfaccia utente funzionante con queste funzionalità dopo 4 settimane, questo progetto è destinato a fallire" - oppure potrebbero esserci azionisti che stabiliscono un obiettivo.

Ci sono molti progetti derivanti dalla legislazione. - Se il governo decide che è necessario implementare la Caratteristica X fino al 2017 per rispettare una nuova legge, si avrà un termine non negoziabile e una serie di caratteristiche che devono essere pronte. L'unica variabile è la quantità di risorse che la gestione può allocare all'attività. - E in questi progetti, in cui la scadenza è una decisione esterna, dovranno osservare i tuoi progressi, sentirti prognostico e aumentare il personale o esternalizzare parte del lavoro per raggiungere i loro obiettivi.

Tutto questo non si oppone allo sviluppo agile. Avrai ancora i tuoi sprint, svilupperai le tue caratteristiche nel tuo arco di tempo. Otterrai sempre le tue priorità di funzionalità da un cliente e lavorerai per fornire quante più funzioni possibili fino alla scadenza.

Se la scadenza verrà effettivamente soddisfatta con le risorse disponibili è un problema di gestione. Puoi dare la tua prognosi e gli aggiornamenti di stato settimanali / giornalieri e possono decidere se hanno bisogno di più risorse. Altrimenti continuerai a lavorare negli sprint e fornirai i runnables, come qualsiasi progetto.

Come qualcuno ha già indicato prima che il manifesto dica:

Individuals and interactions over process

Suggerirei di dare un'occhiata al piano proposto e suggerire modifiche ad esso. Ricorda che il Manifesto dice che l'arretrato non è mai definitivo, continua a evolversi.

Quindi potresti portare i tuoi suggerimenti al team. Se hai un ragionamento valido e il team è d'accordo, qualsiasi proprietario di prodotti che valga il suo / il suo sale li considererà e sfoglia il backlog per riflettere l'opinione dell'intero team.

Questo è il punto in cui potrebbe andare in due modi.

1. Il proprietario e l'azienda del prodotto concordano con il tuo ragionamento e potrebbero aumentare le risorse per rispettare la scadenza se questa è un'opzione OPPURE potrebbero scegliere di eliminare alcune funzionalità per rispettare la scadenza.

2. Potrebbero comunque voler attenersi alla loro versione contro l'opinione collettiva della squadra.

Se il risultato è # 2, questo non è Agile.

Se finisci con il n. 1, allora direi che il team è sulla strada giusta, perché Agile non riguarda solo gli sviluppatori "Rispondere al cambiamento", ma riguarda anche il fatto che l'azienda è in grado di rispondere ai cambiamenti.

Immagina di chiedere a qualcuno di dipingere un muro, una casa e poi un'intera strada per te, quanto tempo daresti a quella persona per farlo?

Qualunque sia la tua risposta, ti sbagli. Questo è tutto.

Non è possibile che abbiano ragione sulle date se non chiedono alle persone che hanno bisogno di fare il lavoro ciò che pensano.

A proposito, se tu (come una squadra) accetta queste date, sei nel torto lì.

Dovresti chiedere un po 'di tempo per lavorare su questa pianificazione insieme alle parti interessate, in modo che tu possa impostare le priorità a seconda di quanto sia facile e veloce fare le cose.

Ad esempio, forse il lavoro finale richiederà il doppio del tempo che pensavano, ma potrebbero usare una beta molto prima di quanto si aspettassero.

Tutto sommato, non puoi permettere alle persone di pensare che sarai in grado di eseguire X in Y se non puoi o potresti essere più veloce, è tua responsabilità chiarire ciò di cui hai bisogno in termini di dettagli e tempo.

Non è un altro progetto n.

Ma se prentate non conoscete il piano e lavorate semplicemente sprint a sprint. Potrebbe essere aglie lavorare.

Ci saranno sempre date e budget. C'è sempre il rischio che vengano persi o sovraccaricati e quando ciò accadrà sarà sempre necessario ricorrere a un piano B.

Se hai lavorato in modo agile, il piano B è sperare che la demo dell'ultimo sprint