Le scadenze sono agili?

Per chiarezza, una scadenza è:

Un limite di tempo o una scadenza è un ristretto campo di tempo, o un particolare momento nel tempo, entro il quale un obiettivo o un compito deve essere realizzato.

^{Da Wikipedia}

Per tutta la mia carriera nello sviluppo di software ho fatto "Agile" che ovunque sembrava significare che almeno le seguenti pratiche erano rispettate:

• Sprint settimanali o bisettimanali
• Retrospettive Pianificazione Sprint
• Un proprietario del prodotto
• Mischia
• Storie utente

Tuttavia, ogni progetto a cui abbia mai partecipato ha insistito nel fissare una scadenza. Dato che Agile tenta di concentrarsi su pianificazione adattiva, flessibilità e cambiamento; le scadenze sono agili?

La mia opinione è che non lo sono, poiché vedo scadenze che portano a una mancanza di flessibilità e mancanza di qualità. Invece, penso che fornisca più valore per concentrarsi su Sprint e consegne anticipate. Sembra tuttavia che in ogni circolo in cui mi trovo, non è così, e le scadenze sono viste andare di pari passo con lo sviluppo Agile.

Le scadenze sono una realtà. La maggior parte delle volte devi avere qualcosa entro una certa data. È inevitabile Senza scadenze, anche i progetti agili possono soccombere alla legge di Parkinson :

Il lavoro si espande in modo da riempire il tempo disponibile per il suo completamento.

In altre parole, se il tuo progetto può andare avanti per sempre, lo farà.

In relazione alle scadenze, Agile cerca di fare alcune cose:

• Garantire che tutti possano sempre vedere quanto lavoro verrà svolto entro la scadenza
• Assicurarsi che le funzionalità più importanti siano completate per prime
• Assicurarsi che le funzionalità completate siano utilizzabili, nel senso che non dipendono da funzionalità che non sono state ancora completate
• Garantire che lo sviluppo prosegua a un ritmo sostenibile

In questo modo, quando arriva l'inevitabile giorno, non hai una pila di codice inutile, ma un prodotto funzionante e testato con, si spera, solo le cose meno importanti non finite. E nessuno è sorpreso dal prodotto finito.

Quindi sì. "Agile" e "scadenze" possono essere perfettamente compatibili.

Le scadenze sono un dato di fatto. Ci sono cose che hanno una data molto ferma.

Abbiamo bisogno del software di Comdex

o

I giochi devono essere sugli scaffali dei negozi entro il Black Friday

e simili. Non si possono rimandare Comdex o il Black Friday: il resto del mondo non funziona in questo modo.

L'obiettivo che Agile ha è che le cose che non rispettano la scadenza falliscano più rapidamente (e che sia una buona cosa), o che l'ambito sia in grado di essere riesaminato prima in modo che le risorse possano essere focalizzate sul ROI corretto in un modo più tempestivo.

La scadenza è una data difficile fissata con fermezza. Agile è uno strumento che consente di rendersi conto all'inizio del ciclo che il software impiegherà il doppio dello sviluppo come sperato inizialmente. È importante che i project manager siano in grado di realizzare questi problemi prima o poi in modo che sia possibile aggiungere più risorse, cambiare l'ambito, modificare la scadenza (nella situazione in cui è un'azienda piuttosto che una scadenza solida) o il progetto annullato.

La trasparenza che Agile cerca è quella di mostrare i problemi e i progressi all'inizio del ciclo. Il classico fallimento della consegna a cascata è quello in cui hai trascorso mesi a porte chiuse e consegna il prodotto una settimana prima della scadenza e ti viene detto che stai sbagliando tutto e hai perso mesi (e ora hai completamente saltato la scadenza) . L'altro classico fallimento della cascata sta scoprendo una settimana prima della scadenza che hai ancora mesi a disposizione. Agile cerca di far conoscere questi problemi all'inizio del processo.

L'altra parte che Agile cerca di fare nel contesto di una scadenza è che anche se solo una parte delle funzionalità concordate è completa (per qualsiasi motivo), l'attuale versione del software è utile e distribuibile.

Ok, ci siamo persi di avere tutto ciò che desideravamo che il software fiscale potesse essere implementato il 15 aprile, ma abbiamo il 75% e ciò che abbiamo funziona e ha funzionato da quando abbiamo iniziato lo scorso novembre. Abbiamo saputo che non saremo in grado di implementare l'intero set di funzionalità da metà dicembre e abbiamo ricentrato i nostri sforzi sull'80% della base clienti.

Alcune scadenze devono essere rispettate. Obblighi contrattuali, convenzioni, requisiti regolamentari. Alcuni sono imposti dai manager che vogliono essere in grado di mettere lo sviluppo del software nella stessa tabella della produzione sul loro foglio di calcolo. Qualunque sia la causa, la maggior parte delle persone non può allontanarsi da loro.

Se stai lavorando in un team funzionante, la comunicazione tra gli sviluppatori e il management / le parti interessate significa che le persone che devono prendere una decisione sono ben informate per decidere se perdere la scadenza o continuare con lo sviluppo è più importante.

Anche se stai fornendo storie utente complete una volta alla settimana o due volte al mese, avrai probabilmente delle scadenze. Quando uno sta arrivando, assicurati che le parti interessate sappiano cosa pensi che si adatterà entro la scadenza e stabilisci le aspettative.

Se stai costantemente costruendo il miglior software possibile con i requisiti che hai attualmente in ogni fase, una scadenza alla fine di ogni sprint non dovrebbe teoricamente essere un problema. In pratica, questo non è normalmente il caso, ma nemmeno le scadenze che appaiono dal nulla. Le scadenze più importanti che mi siano mai state date mi sono state comunicate molto prima, era l'aspettativa della qualità e delle caratteristiche che erano il problema.

Le scadenze arbitrarie che non hanno conseguenze se mancate non sono molto agili, ma ci sono situazioni in cui per ragioni al di fuori delle scadenze di controllo del team di sviluppo devono essere stabilite e rispettate. Fortunatamente, se le scadenze sono ragionevoli, ci sono molti modi per invertire l'equazione e gestire le scadenze in modo agile.

Le scadenze non sono sempre sbagliate. Come abbiamo imparato da Obi-Wan:

"Solo gli accordi Sith in assoluto"

È giusto dire che nella maggior parte dei casi le scadenze sono sciocche, inutili e certamente non agili, ma sarebbe sciocco dire che è sempre così. Il caso architypal è un software necessario per un uso sensibile al tempo, come il software di monitoraggio elettorale. Se il software non è pronto in tempo per le elezioni, non sarebbe sensato né pratico posticipare le elezioni, e non sembra essere molto orientato al cliente solo per dire 'Mi dispiace, sembra che ci sia voluto troppo tempo. So che questo software per il quale ci stai pagando è completamente inutile, ma le scadenze non sono agili, quindi come puoi davvero tenerlo contro di noi per non averlo rispettato?

Non è molto agile dire ai tuoi clienti di spingerlo per desiderare qualcosa che sia sensibile al tempo, e alla fine qualcuno dovrà costruire queste cose. Quindi, come possiamo ancora rendere felici i clienti e fornire soluzioni apparentemente ragionevoli a cose che sono sensibili al tempo? Bene, se lo sviluppo di software richiede un tempo incerto e la scadenza non è variabile, qualcos'altro dovrà essere variabile per gestire quell'incertezza ...

Se la data di consegna viene mantenuta costante, alcuni altri aspetti diventano variabili.Come tutti sappiamo, ci possono essere molte incertezze nei progetti software. Qualcosa deve essere reso variabile in risposta a questa incertezza se vuoi avere successo nel tuo progetto, e di solito questa è la data di consegna. Sembra abbastanza naturale, comunque. Ma questa non è la tua unica opzione. Se sei bloccato a rispettare una scadenza rigida, il modo per gestirlo è rendere variabili le funzionalità fornite. Dai la priorità a un elenco di funzioni, comunica chiaramente che non vi è incertezza sulla quantità di funzioni che possono essere fornite entro tale data. Collabora con il cliente per dare la priorità a queste funzionalità in modo che le più importanti abbiano maggiori probabilità di essere spedite. Quindi, è come al solito, solo quando la scadenza scade intorno alla tua nave tutto ciò che è pronto per essere spedito. In questo modello,

Se qualcuno vuole fissare una scadenza, allora va bene e la scadenza può essere fissata, ma ciò che devono capire è che se la scadenza è fissa, l'ambito deve rimanere flessibile.

tl; dr

In un mondo ideale non avremmo scadenze e consegneremo le cose quando saranno pronte. La realtà è che le persone che pagano per le cose di solito vogliono sapere quando hanno finito. Le metodologie agili lo riconoscono, ma riconoscono anche che non tutto può essere legato.

Ciò garantisce che sia possibile mantenere la qualità della consegna al livello giusto per il prodotto. Se fissi una scadenza, un ambito (e un budget), le cose si affrettano e finirai di nuovo nel vecchio mondo delle cascate con un pazzo tempo alla fine del progetto. L'aumento del budget di solito non è la risposta, perché l'aggiunta di più sviluppatori e tester non risolve più rapidamente un problema. È una visione ben nota (e sono d'accordo con essa per esperienza), che più persone aggiungi (ognuna con le proprie debolezze) più tempo ci vuole.

Ora, in genere (a meno che non comprendano davvero i metodi Agile) alla persona che paga per il software non piace essere informata, possiamo rispettare la scadenza ma non possiamo fare tutto ciò che desideri. Questo può essere gestito dando la priorità alle funzionalità che compongono il software. La discussione sulla definizione delle priorità potrebbe essere simile a:

Dev Team (D): "Per favore, puoi dare la priorità alle funzionalità che desideri vengano fornite, prima le più importanti?"

Cliente (C): "Tutto ha la priorità 1: li voglio tutti fatti entro la fine del prossimo mese."

D : "Potrebbe essere possibile, ma potrebbe non essere possibile se i requisiti cambiano o scopriamo problemi che non ci aspettavamo durante lo sviluppo."

C: "Beh, se ti do più soldi?"

D: " sospiro ... anche con più risorse ci vorrà un mese per iniziare davvero; quindi se non sei sicuro di come stabilire le priorità delle funzionalità, dicci solo quali vuoi prima fare."

C: "Ok, voglio il pulsante grande ma renderlo davvero grande, e poi ... ecc."

Ora puoi iniziare a lavorare sulle funzionalità in ordine di priorità. Aiuta anche a guardare avanti con il tuo team su quegli elementi più in basso nell'ordine di priorità e fare delle prime stime, sapendo che potresti cambiarli quando arrivi allo sviluppo quando hai più informazioni. Questo può essere usato per ridefinire o creare la tua roadmap se non ne hai ancora una. Ciò costituisce quindi la base del piano di rilascio. La tabella di marcia può essere discussa con il cliente, riconoscendo che l'ambito di applicazione potrebbe cambiare ma si dispone di un ordine delle cose da consegnare.

Uno dei grandi vantaggi di Agile è che riconosce che le cose cambiano mentre attraversi lo sviluppo e ti adegui mentre lo fanno. Contrariamente agli approcci più tradizionali, questo principio, in combinazione con i consegne sprint regolari e la comunicazione in corso con il cliente, significa che sei naturalmente costretto ad essere più trasparente sui progressi, il che è una buona cosa.

A volte al cliente non piace che non ottengano ciò che vogliono entro una certa data, ma capiranno perché e ciò che ottengono sarà di buona qualità. E 6 mesi dopo la consegna delle funzionalità, il cliente non si preoccuperà o ricorderà di averlo consegnato entro una certa data, ricorderà la qualità del prodotto che sta ancora utilizzando.

Le scadenze si basano tradizionalmente sul ciclo di vita aziendale. Il software fiscale deve arrivare entro il 15 aprile. Le relazioni per il prossimo anno fiscale potrebbero essere necessarie entro luglio.

Il manifesto Agile afferma:

Individui e interazioni su processi e strumenti

Software funzionante su documentazione completa

Collaborazione con i clienti sulla negoziazione del contratto

Rispondere al passaggio dopo aver seguito un piano

Le scadenze sono un contratto. Sono un piano. Non rispondono alla velocità della tua squadra. Non cambiano se perdi i tuoi tre migliori sviluppatori.

Le scadenze non sono agili, ma Agile può darci un feedback sulle scadenze. Agile facci sapere se la nostra velocità non ci consentirà di stabilire una scadenza senza tagliare una funzione. Ci informa anche se dobbiamo assumere per fissare una scadenza. E in alcuni casi, ci fa sapere che una scadenza è impossibile, quando non ci sono caratteristiche da tagliare.

La cosa migliore che un team Agile può fare è lasciare che la velocità e l' arretrato prioritario guidino le scadenze. Ciò fornirà le date di consegna stimate. Se quelli non rientrano nella scadenza, è il momento di parlare seriamente con il cliente e determinare se la scadenza è persino fattibile.

Direi che la consegna di ogni sprint non è negoziabile. Valuta il lavoro, ci metti le dimensioni delle carte e carichi abbastanza da tenere occupata la tua squadra fino al termine dello sprint (e lo sprint dovrebbe essere piccolo, da una settimana a un mese). Le "scadenze di consegna" dovrebbero basarsi sull'andamento storico del lavoro completato rispetto al lavoro previsto. Agile non aggiunge / rimuove nulla dalla vecchia idea di vincolo "costo / tempo / ambito", utilizza semplicemente l'ambito come metodo preferito di gestione dello slippage sulla base del fatto che una migliore priorità rispetto all'ambito è generalmente preferibile a spendere più tempo o denaro.

Alcune persone sembrano confondere l'agile con il "selvaggio west". Agile non significa che tutto vada. Agile significa che smettiamo di mentire a noi stessi sul modo in cui una persona ragionevole può stimare. Fondamentalmente possiamo stimare lo sviluppo del software tra 2 e 4 settimane nel futuro. Oltre a ciò, sono tutti gradi diversi di swag e ipotesi. Peggio ancora, il costo di fornire stime per le cose sempre più avanti nel futuro si avvicina al costo del solo fare il lavoro. Per qualsiasi motivo, i Project Manager non sono stati storicamente disposti ad ammettere queste verità assolute ai clienti. Agile aggiusta semplicemente questo pensiero affermando che esiste un limite al modo in cui possiamo prevedere il futuro nell'ingegneria del software e passa in modo sottile alla "stima basata sull'evidenza" per le previsioni a lungo termine.sono in grado di stimare e possiamo fornire stime ragionevolmente ragionevoli della consegna futura a lungo termine in base a ciò che abbiamo consegnato finora.

TL; DR

Le scadenze [a] gile? ... [D] eadline sono considerate andare di pari passo con lo sviluppo di [a] gile.

Molte risposte qui probabilmente si concentreranno sugli aspetti ingegneristici della domanda. Invece, affronterò questo aspetto dal punto di vista della gestione del progetto.

Una scadenza implica una grande pianificazione iniziale che non è in linea con i principi agili. Invece, i modelli di sviluppo iterativo si basano su intervalli temporali, cadenza e cicli di rilascio che includono la pianificazione just-in-time, ma non la "pianificazione anticipata" che è generalmente associata alle scadenze tradizionali di gestione dei progetti.

È ancora possibile eseguire la pianificazione del rilascio con metodologie agili, ma i piani si basano generalmente su una stima del numero di iterazioni richieste per raggiungere un obiettivo piuttosto che su obiettivi di gestione stabiliti da Fiat. Ciò non significa che le date di spedizione non possano essere stabilite o che gli obiettivi non possano essere raggiunti, ma il modo in cui sono definiti e raggiunti è molto diverso rispetto alle tradizionali metodologie di gestione del progetto.

Pensa a caselle temporali, non scadenze

Tuttavia, ogni progetto a cui abbia mai partecipato ha insistito nel fissare una scadenza. Dato che Agile tenta di concentrarsi su pianificazione adattiva, flessibilità e cambiamento; le scadenze sono agili?

Questo è un malinteso comune sui principi agili. I framework agili come Scrum e Kanban non si concentrano sulle scadenze, ma piuttosto sul time-boxing e su una cadenza di consegna sostenibile.

In Scrum, ad esempio, lo Sprint non è una "scadenza". Si tratta di una casella temporale che viene riempita con la quantità di lavoro che il team stima si adatterà all'interno della finestra temporale senza traboccare, e viene quindi "fatto" o "non fatto" alla scadenza della finestra temporale. Una volta sparito, il time-box è andato per sempre; qualsiasi lavoro che non viene svolto deve essere riprogrammato e rivalutato in una nuova finestra temporale altrettanto effimera basata sulle esigenze attuali (piuttosto che storiche) del progetto.

L'importanza del time-box è che crea sia una cadenza prevedibile per le parti interessate per rivedere i progressi, sia un ritmo sostenibile per il team in cui fornire incrementi di valore potenzialmente shippable . Il lavoro è incrementale e segue la cadenza; il concetto di una grande scadenza anticipata non è pertanto in linea con i principi agili.

Pianificazione del rilascio basata su time-box

Forse l'area in cui le persone hanno più difficoltà a mappare i processi agili con i framework tradizionali è la pianificazione del rilascio. La pianificazione del rilascio comporta spesso risultati a portata fissa o a data fissa. In framework agili, la pianificazione del rilascio viene generalmente eseguita attraverso un processo di stima in cui l' ambito viene esplicitamente definito come variabile mutabile, mentre le date di rilascio sono stimate in iterazioni.

Ad esempio, un progetto può essere impegnato a rilasciare v1.0 di un progetto al termine di 20 iterazioni; l'ambito di ciò che viene rilasciato può cambiare nel corso della vita del progetto (poiché l'ambito, le caratteristiche e le priorità possono cambiare all'inizio di ogni Sprint), ma le date target per ciascuna versione sono fissate nel piano del progetto. Il team si impegna a fornire un incremento potenzialmente shippable ogni Sprint e la Definizione di Fine include controlli di qualità come l'integrazione continua per garantire che il progetto sia in uno stato rilasciabile alla fine di ogni Sprint.

Occasionalmente, vedrai progetti agili in cui l'ambito è fisso, ma poiché l'ambito è la variabile mutabile in progetti agili, la data di rilascio può cambiare nel tempo man mano che l'ambito di ciascuna iterazione si adegua, cambia o si adatta alle esigenze in evoluzione del progetto . Certamente non raccomando l'approccio a portata fissa ai team agili, in particolare i team inesperti, ma ci sono momenti in cui è l'approccio giusto.

Guarda anche

• Come eseguire la pianificazione delle versioni agili

Pensa alle scadenze come impegno. Il fatto che il progetto sia agile non significa che non dovresti impegnarti a fornire determinate funzionalità per una determinata data.

Ciò che l'agilità porta è ciò che accade nel mezzo. Invece di disporre di un documento di specifica dei requisiti software rigoroso che definisce che è necessario fornire la funzione A composta da funzioni secondarie B, C, D ed E per una determinata data, l'utente si impegna a consegnare la funzione A per una determinata data, dato che al nella fase iniziale, né tu né i tuoi clienti sapete come apparirà la funzionalità, o avrebbe le funzionalità secondarie B, C, D ed E o forse B e C o una dozzina di altre funzionalità secondarie.

Immagina una società che in precedenza consegnava merci solo a piccole aziende e ha appena firmato un contratto con una grande società. Questa grande azienda utilizza EDIFACT e sembra che l'attuale software di contabilità utilizzato dalla tua azienda non gestisca EDIFACT. Stai chiesto di creare un plugin che fa che, dato che contrattualmente, la vostra azienda dovrebbe essere pronto per 15 aprile ^° .

L'agilità significherebbe che i passaggi intermedi verranno consegnati progressivamente e si baseranno su feedback regolari. Fondamentalmente, mostrerai i tuoi progressi ai contabili e ti diranno cosa ne pensano, quali sono i possibili problemi, ecc. Ciò significa anche che, in origine, i contabili avevano una grande idea che, pensavano, potesse migliorare sostanzialmente l'esperienza dell'utente. Tre settimane dopo, è emerso che non solo non lo migliora molto, ma comporterà anche un mese di sviluppo aggiuntivo. Grazie ad Agile, puoi quindi reindirizzare i tuoi sforzi da questa funzione a qualcos'altro, assicurandoti di consegnare in tempo.

Dovresti anche comprendere il punto di vista del cliente:

• Spesso le aziende hanno bisogno di una data di consegna specifica. Ad esempio, non è possibile fornire il servizio di streaming online delle Olimpiadi dopo la fine delle Olimpiadi. Per quanto riguarda il business, questo è semplicemente un fallimento, con enormi conseguenze negative.

• Senza avere un impegno, è allettante per uno sviluppatore o un subappaltatore essere perfezionista o dare priorità al progetto. Mentre la regolarità degli sprint aiuta, non impedisce totalmente questo rischio.

  Non mi piacciono le scadenze per questo, soprattutto perché le scadenze si verificano molto facilmente, ma capisco ancora perché molte aziende lo fanno. Non è sempre facile vedere che il progetto è in ritardo guardando solo agli sprint: una scadenza mancata, in questo contesto, può essere un chiaro promemoria che qualcosa va fuori controllo e dovrebbe essere affrontato, in questo momento.

Stati di programmazione eXtreme sulla pianificazione delle versioni:

La filosofia di base della pianificazione del rilascio è che un progetto può essere quantificato da quattro variabili: ambito, risorse, tempo e qualità.

Che sembra giusto. Lo afferma anche

Nessuno può controllare tutte e 4 le variabili. Quando ne cambi una, inavvertitamente fai cambiare un'altra in risposta. Si noti che la riduzione della qualità a un valore non eccellente ha un impatto imprevisto sulle altre 3 variabili

E come già notato da br3w5 , aumentare le risorse è una soluzione limitata. Probabilmente puoi aggiungere un paio di persone che facevano già parte del team se fossero state inviate su qualcos'altro. Ma non puoi semplicemente aumentare le dimensioni del team in modo rapido e indefinito, almeno non senza una riorganizzazione del team che richiede molte volte.

Quindi, con qualità irriducibile e risorse fisse: una scadenza è un vincolo di tempo, significa che è necessario adattare la portata. E l'utilizzo dell'agilità ti dà il mezzo per rispettare la scadenza con l'ambito più produttivo possibile. Tuttavia, in genere è possibile garantire che una parte dell'ambito verrà eseguita in tempo. Questa è la parte che puoi stimare con fiducia il suo tempo per essere limitato al di sotto della scadenza. In genere qualcosa che è molto vicino a quello che hai fatto più volte e ha poco sconosciuto.

Lo scopo dei metodi di sviluppo del software, se compreso correttamente, è di renderci più produttivi focalizzando i nostri pensieri e di fornire un linguaggio comune per le situazioni tipiche. Si tratta di ispirazione e abilitazione, non di controllo mentale e senso di colpa.

Seguire un metodo di sviluppo software letteralmente senza compromessi corrisponde a ciò che viene chiamato radicalismo o fondamentalismo in altri contesti. La forma pura di questa aberrazione è raramente vista in pratica perché in genere porta a un rapido fallimento nel mercato. Ma ovviamente quando gli sviluppatori competono nel difficile compito di implementare un metodo specifico, il superamento del marchio è un evento naturale.

Il problema è aggravato dal fatto che i missionari e gli evangelisti prendono di mira principalmente coloro che hanno ancora bisogno di convincere a usare il metodo; e anche se predicano moderazione, la natura umana assicura che riceva meno attenzione.

Le scadenze non sono agili, sono:

1) Cascata e 2) Sbagliato.

Software e scadenze non funzionano bene insieme e non lo sono mai stati. In molti modi, i metodi Agile sono una reazione al grosso problema di scadenze o software mancati che è stato abbandonato quando è diventato chiaro che la scadenza non poteva essere rispettata (così come le questioni di bilancio).

Agile tenta di iniettare la realtà nella situazione dicendo "Sai che la scadenza o le caratteristiche scivoleranno e / o cambieranno, lo sappiamo, quindi scendiamo con il piede giusto e non pretendiamo nemmeno".

La chiave è che la scadenza diventa semplicemente una data di rilascio per la prima versione del software. Ciò potrebbe essere ancora scritto in pietra - diciamo, il software è per uso accademico e DEVE essere utilizzabile all'inizio del mandato - ma ciò che fornirai non lo è. Hai un prodotto minimo che tutti sono sicuri che possano essere consegnati da allora, e hai un carico di "vorrebbe avere". Invece di alzare tutte le mani quando si scopre che l'intera lista non sarà consegnata entro la "scadenza", ti assicuri di far uscire l'MVP dalla porta e quanti "vorrebbe avere" possibile e quindi valutare il costo / beneficio del resto a quel punto.

Chiunque abbia giocato a giochi per computer per un certo periodo di tempo sa esattamente come funziona! Se la prima versione è all'altezza degli standard beta, molti giocatori sono felici, così basse sono le aspettative su cosa significhino "scadenze ferme e reali" nella vita reale.

Quindi le scadenze non sono agili, sono ritardi dai tempi in cui la gente pensava che il software potesse essere trattato come hardware e ingegneria dell'acciaio. Abbiamo imparato che questo non è né possibile né desiderabile, poiché getta via il più grande vantaggio che il software ha sull'hardware: è morbido.

Agile cerca di sfruttare questa morbidezza consentendo agli obiettivi di svilupparsi e cambiare nel corso del progetto in un modo che un progetto di ponte non potrebbe mai.

Rispondi "probabilmente no"

Il Project_management_triangle afferma che il costo, durata e portata (e anche la qualità) dipendono l'uno dall'altro. ("scegli due e ottieni il terzo")

Uno sprint di scrum sceglie il tempo fisso (cioè 7 giorni = durata dello sprint) e il costo (cioè il budget per 7 membri del team) e stima l'ambito (il numero di storie da fare nello sprint)

Se la direzione o il reparto vendite cercano di definire tutti e tre (costo, tempo e ambito), non è agile nel senso di mischia perché il team non può promettere di raggiungere l'obiettivo (senza violare la qualità = definizione del fatto)

La gestione professionale cerca di definire costi e tempi e di ridurre l'ambito se necessario se c'è una data fissa da rispettare.

Non è possibile rispondere in modo semplice e diretto?

Nessuna scadenza non è agile.

Il punto è costruire ciò che è possibile in modo iterativo apprendendo e adattandosi man mano che procedi.

Una scadenza è "devi consegnare x per y" che fallisce in entrambi i casi in quanto stai promettendo un risultato fisso in un calendario predeterminato (dove agile dice che non siamo sicuri di ciò che stiamo cercando di consegnare, e l'apprendimento dall'agile ci insegna che anche se sappiamo che è molto difficile avere certezza riguardo ai tempi - o è un problema risolto e non dovremmo farlo comunque).

Avendo stabilito che la risposta alla domanda è "No, le scadenze non sono agili" - allora siamo in grado di avere una conversazione interessante che affronta la questione di "come possiamo affrontare le scadenze in un contesto agile" e c'è molto di buono pensandoci nelle altre risposte.

A mio avviso, una risposta ragionevole a quest'ultima è che forniremo incrementi di valore in anticipo e spesso e vedremo dove siamo a tempo debito, ma non esiste una dimensione adatta a tutti.

Il grado di agilità richiesto nel proprio lavoro è inversamente proporzionale alla loro posizione sull'organigramma.

"Agile" è buono, per quello che è. "Agile" significa "apertura mentale unita a sufficiente competenza". Sono i grugniti in fondo che devono essere i più agili.

Se, a livello di gestione, il capo con i capelli a punta fosse abbastanza agile da capire che la scadenza di una scadenza a una settimana renderà un prodotto migliore o creerà un codice più pulito, più privo di bug e più sfruttabile in modo che la società ( o la divisione) salva due settimane in futuro, questa è una scadenza agile.

Ma come l'interesse personale illuminato, in realtà non esiste.