Gestire sprint e scadenze non riuscite

Molti libri e articoli Scrum affermano che uno sprint fallito (quando il team non riesce a completare alcune funzionalità dallo Sprint Backlog) non è qualcosa di così brutto, succede di tanto in tanto e può effettivamente essere utile se il team impara dai propri errori e migliora qualcosa nei seguenti sprint. E la squadra non dovrebbe essere punita per non aver completato il lavoro a cui si è impegnata.

Questo sembra fantastico dal punto di vista dello sviluppatore, tuttavia, supponiamo che abbiamo una società di software " Scrum-Addicts LLC " che sta sviluppando qualcosa per clienti seri (" Money-Bags Corporation "):

1. I manager di Scrum-Addicts suggeriscono di creare un software per Money-Bags
2. Sono d'accordo su un elenco di funzionalità e Money-Bags chiede di fornire una data di spedizione
3. I manager di Scrum-Addicted consultano il loro team di Scrum e il team afferma che ci vorranno 3 sprint di una settimana per completare tutte le funzionalità
4. Il responsabile Scrum-Addicts aggiunge 1 settimana per sicurezza, promette di spedire il software in 1 mese e firma un contratto con Money-Bags
5. Dopo 4 sprint (termine di spedizione), il team Scrum può fornire solo l'80% delle funzionalità (a causa dell'inesperienza con il nuovo sistema, della necessità di correggere bug critici nelle funzionalità precedenti nell'ambiente di produzione, ecc ...)
6. Come suggerisce Scrum, a questo punto, il prodotto è potenzialmente spedibile, ma Money-Bags ha bisogno del 100% delle funzionalità, come indicato nel contratto. Quindi rompono il contratto e non pagano nulla.
7. Scrum-Addicts è sull'orlo del fallimento perché non ha ricevuto denaro da Money-Bags e gli investitori sono rimasti delusi dai risultati e non sono più disposti ad aiutare la società.

Ovviamente, nessuna società di software vuole essere nei panni di Scrum-Addicts. Quello che non capisco di Agile e Scrum è come suggeriscono ai team di gestire la pianificazione e le scadenze per evitare la situazione sopra descritta. Quindi, per riassumere, ho 2 domande:

Di chi è la colpa?

1. Manager, perché è il loro lavoro fare la corretta pianificazione
2. Il team, perché si sono impegnati a fare più lavoro di quello che potevano
3. Qualcun altro

Che cosa si deve fare?

1. I gestori devono spostare la scadenza 2 volte (o 3 volte) più tardi rispetto alla stima del team originale.
2. I membri del team dovrebbero essere incoraggiati a fare tutto il lavoro che hanno commesso, indipendentemente dal fatto (emettendo penalità per sprint falliti)
3. Il team dovrebbe abbandonare Scrum perché non si adatta alla politica di scadenza dell'azienda
4. Dovremmo abbandonare tutti lo sviluppo del software e unirci a un monastero
5. ???

Vedo diversi problemi di gestione fondamentali nel tuo esempio:

• se un manager di Scrum-Addicted firma un contratto "scadente", ma aggiunge solo un margine di sicurezza del 33% in una situazione in cui "è coinvolto un nuovo sistema", è piuttosto sconsiderato.

• la disponibilità di fornire almeno il x% delle funzionalità dopo un mese avrebbe potuto essere utilizzata per negoziare un contratto in cui i clienti pagano i soldi almeno parzialmente quando ottengono solo l'80% delle funzionalità alla scadenza. Un contratto tutto o niente è qualcosa di cui né il fornitore del software né il cliente trarranno vantaggio: ciò significa non solo 0 soldi per il fornitore, ma anche 0 funzionalità per il cliente. E una metodologia di sviluppo del tutto o niente come "Waterfall" ti consentirà solo di scrivere tali contratti, un approccio agile offre ulteriori possibilità.

• l'esame dei risultati del primo o dei due sprint avrebbe dovuto rendere evidente al manager che la squadra non è in grado di rispettare la scadenza. Quindi avrebbe dovuto intraprendere azioni precedenti e riordinare le attività e le funzionalità rimanenti, oppure provare a rinegoziare con il cliente prima. Ad esempio, il gestore avrebbe potuto tentare di ridimensionare l'ambito di alcune delle funzionalità rimanenti, quindi il team avrebbe potuto fornire tutte le funzionalità menzionate nel contratto, ma ognuna di esse in un ambito ridotto.

Se un'attività risulta richiedere più tempo di quanto pensassi, nessuna metodologia di sviluppo ti salverà da quello. Ma un approccio agile come Scrum offre al management maggiori opportunità di controllare cosa succede in quella situazione. Se non sfruttano queste opportunità, è chiaramente colpa loro, non del team, non di "Scrum", e non del cliente perché "non accetta l'agilità".

Una delle dichiarazioni di valore del " Manifesto per lo sviluppo di software Agile " è:

Collaborazione con i clienti sulla negoziazione del contratto

Il fatto che Scrum-Addicts LLC abbia negoziato un contratto invece di stabilire una collaborazione con un cliente mi fa dubitare della loro agilità.

Una cosa è chiara: l'agilità deve essere accettata da TUTTI. L'agilità non è solo per gli sviluppatori. Anche i manager e i clienti devono accettare i valori del Manifesto Agile. Se i clienti non accettano l'agilità e richiedono comunque contratti rigidi e una collaborazione minima, non utilizzare l'agile o trovare clienti migliori.

È colpa del cliente che sono bloccati nella bolla del contratto con uno sviluppo determinato dalle scadenze.

Di chi è la colpa?

Manager, ufficio legale, commercialisti: scegli ...

So che l'esempio è in qualche modo inventato, ma il fatto che la società potrebbe andarsene senza pagare un centesimo se non fosse soddisfatto al 100% avrebbe dovuto suonare campanelli d'allarme immediati come mescolare cascata e pensiero agile.

I clienti vogliono avere la loro torta e mangiarla - sono felici di accettare la cascata, la mini-cascata, l'agile, la-la-land fintanto che ottengono il prodotto X per $ Y per data Z.

Lo sviluppo agile richiede assolutamente che il team di sviluppo e il cliente siano sulla stessa pagina dal punto di vista della metodologia. Pensare che le differenze nella cultura emergeranno nel lavaggio è un pio desiderio.

I progetti IT si occupano di incognite ; alcune di queste incognite sono anche incognite sconosciute . Cosa significa?

Prendi ad esempio un ponte giocattolo per la tua ferrovia modello. Ci sono tutti i parametri che ti sono noti:

• Sai quanto è grande la valle

• Conosci il materiale delle montagne, la loro altezza, stabilità ecc.

• Sai quanto materiale ti serve

• Sai dai precedenti "progetti" quanto tempo hai impiegato per costruire cose simili

Sono coinvolte molte variabili che influenzano il calcolo dell'investimento di tempo libero e denaro. Ma potresti dire senza pensarci se è finito il prossimo fine settimana.

Fai un ulteriore passo avanti nell'esempio:

• Di 'che non costruisci il ponte per il tuo modello di ferrovia, invece lo costruisci per un estraneo completo: il tuo compito è costruire un ponte ferroviario tra due montagne

• Supponi di non avere quasi nessuna informazione prima del panorama del modello

• L'informazione sul paesaggio è, cioè ha due montagne, che non sembrano troppo grandi

• La consistenza della montagna è tra roccia e gelatina

• Il costo totale ha un massimo di 10 $

• Il posto di lavoro è completamente buio e non vi è alcuna possibilità di luce: hai solo una scatola di 8 partite

• La scadenza è di 3 ore

Sarebbe l'analogia con un progetto IT. Hai esperienza nella costruzione di ponti ed è facile camminare su terreni noti. Ciò che rende difficile è l'oscurità . Ci sono molte cose che difficilmente puoi prevedere: le misure delle montagne sono note solo dopo aver frugato un po 'di tempo al buio. Così è la coerenza delle montagne. Da ciò potresti fare delle stime su quanto tempo ti impiegherà e quanto costerà. Qui le incognite sono cose che non conosci all'inizio del progetto come il terreno concreto ecc. Ma ci sono cose che non puoi prevedere, anche con la maggior esperienza e le stime più prudenti. Queste cose sono le incognite sconosciute che portano un po 'di caos.

Ogni azienda IT dovrebbe saperlo. Devono affrontare il rischio del progetto.

1) Esistono diversi modi per ridurre al minimo il rischio (finanziario): l'accordo potrebbe comprendere che il cliente paghi per ogni incremento di funzionamento. Pertanto, dopo la consegna dell'incremento 1, è necessario pagare una tariffa parziale. Finché Scrum-Addicts LLC offre, c'è un rischio finanziario minimo. Più sono pianificati gli obiettivi dello sprint , più basso è il rischio totale di ogni sprint. Ciò significa che se Money-Bags Corporation ha ricevuto l'80% del contratto, dovrebbe almeno pagare l'80% del valore del contratto. Se si rifiutano di pagare dopo uno sprint fallito, il rischio non è elevato quanto il rifiuto di pagare il 100%.

2) Scrum-Addicts LLC ha un problema con i loro sviluppatori

I manager di Scrum-Addicts consultano il loro team di Scrum e il team afferma che ci vorranno 3 sprint di una settimana per completare tutte le funzionalità Il manager di Scrum-Addicts aggiunge 1 settimana per sicurezza, promette di spedire il software in 1 mese e firma un contratto con sacchi di denaro

Ciò suggerisce che a) gli sviluppatori non hanno esperienza con la mischia o b) stanno facendo una mischia sbagliata Più i team lavorano con la mischia, migliori sono le loro stime. Se i team fanno stime e il manager aggiunge un "buffer" come "sicurezza", il manager sembra conoscere meglio del team, il che è un brutto segno . Se hai un team esperto, non è necessario un "managerbuffer", il team lo ha già incluso nella stima. L'idea è che più sprint il team ha lavorato insieme più il team conosce i suoi punti di forza e di debolezza e ha alcune metriche per fare stime realistiche. Naturalmente ci sono - come già accennato - le incognite sconosciuteche tendono a rendere le stime difficili; o almeno impreciso. Ma a lungo termine, le stime dovrebbero andare sempre meglio.

Di chi è la colpa?

1) Gestione

Come detto sopra: c'è chiaramente un fallimento nella gestione del rischio. Se la società è sull'orlo del fallimento, la società se lo merita. Se lavori in un'azienda del genere: vattene!

2) Il team

Anche se la gestione è assolutamente stupida, il team avrebbe dovuto opporsi a tale progetto. Un buon manager dovrebbe conoscere i rischi; ma un buon sviluppatore dovrebbe indicare i rischi. E soprattutto: il team dovrebbe segnalare in anticipo se qualcosa fallisce.

Che cosa si deve fare?

Ora: porta Money-Bags in tribunale

Per il futuro: non stipulare tali contratti

Scrum non è da biasimare per errori di gestione. Scrum è stato sviluppato sulla base dell'esperienza di molti progetti IT falliti. Non può prevenire il fallimento, né può curare l'incompetenza di team o dirigenti. L'idea di base è:

• strutturare i modi di comunicazione (chi parla a chi quando cosa)

• per incoraggiare tempestivamente gli errori di segnalazione degli sviluppatori

• per dividere i problemi in compiti e sottoattività

• strutturare tempo e capacità (chi lavora quando su cosa)

• per distribuire le attività nelle fasce orarie

• rendere l'imprevedibile un po 'più prevedibile (pianificazione del poker)

o nel complesso: per ridurre al minimo il rischio.

Scrum è uno strumento come un martello. Se è un buon strumento dipende dalla tua conoscenza su come usarlo. Ma a volte un cacciavite si adatta meglio. Tocca a voi.

Prima di tutto, "Di chi è la colpa?" è la domanda sbagliata da porre. Assegnare la colpa è divertente e tutto, e probabilmente farà sentire sollevati tutti tranne la (le) persona (e) incolpata (in un senso "ehi, non è colpa mia, lo ha detto il capo!"), Ma non è un uso produttivo del tuo tempo e può effettivamente essere controproducente e causare un calo del morale dei dipendenti.

Un modo migliore per vederlo è "Cosa ha causato il ritardo?". È stata la mancanza di esperienza nella tecnologia? Bug critici che non sono stati rilevati nei test / QA? Mancanza di test / QA? Troppo ottimista nella stima? Non prendere in considerazione le stime non così ottimistiche del team? Qualcuno è stato investito da un autobus? Qualunque sia la causa, la domanda successiva è "Come possiamo assicurarci che non accada di nuovo?". In alcuni casi (si spera rari), la risposta potrebbe essere "sbarazzarsi di così e così", ma se si parte da "Ho bisogno di punire chiunque sia responsabile", è improbabile che tu veda la maggior parte dei casi dove non è la soluzione giusta.

All'interno del progetto, sei già affondato. La scadenza va e viene, hai avvertito il cliente non appena era evidente che stava per scivolare (perché l'hai fatto, giusto? In caso contrario, questo è parte del problema), e ora deve essere gestito comunque è stato spiegato nel contratto (in realtà è indicato nel contratto, giusto?). In generale, ciò dovrebbe comportare la negoziazione con il cliente su come consegnare ciò che manca. A molte persone piace pensare a un contratto come qualcosa che non può essere modificato, ma di fronte a a) far cadere il contratto e non avere ciò che hai acquistato, b) fare causa alla società per violazione del contratto e spendere molti soldi in tribunale, e c) negoziando come ottenere il proprio prodotto con il minor numero possibile di problemi, la maggior parte delle aziende sceglie c.

Guardando al futuro, prima di quotare un prezzo / scadenza a un cliente, dovresti analizzare i rischi connessi a una scadenza scaduta o al superamento dei costi (quali sono le possibili cause di tale cosa? Quali cause puoi mitigare in qualche modo, e quali non puoi e semplicemente devi pianificare) e utilizzare tali informazioni per aiutarti a decidere cosa prometterai. Se è un caso in cui è al 100% o niente, ovviamente citerai prezzi più alti e scadenze più lunghe, perché il rischio è più alto.

Noterai che non ho parlato di Agile in tutta questa risposta. Questo perché (dimenticherò per un secondo il coinvolgimento del cliente in Scrum, anche se è molto, molto importante) a questo punto non ha molta importanza. Dovrai affrontare questo problema in Agile, Waterfall o in qualsiasi processo di sviluppo utilizzi. Sì, si suppone che Agile ti aiuti a gestire meglio i rischi, facendoti vedere se sono diventati problemi reali in precedenza e coinvolgendo il cliente nel processo stesso in modo che siano sempre informati, ma non è una panacea.

Innanzitutto, questo è un problema con qualsiasi metodologia di sviluppo. Almeno con un sistema di sviluppo iterativo hai qualcosa da mostrare al cliente alla fine della scadenza, che può essere sufficiente per ottenere un'estensione per completare il prodotto (anche se il cliente non paga più!).

Ci sono casi in cui una scadenza è una scadenza, tuttavia, immagina di scrivere un gioco e deve assolutamente essere rilasciato in tempo per le vacanze di Natale. Sbagliare ha fatto fallire molte aziende!

Per i metodi agili che devono completare una certa quantità di funzionalità entro una certa data, la mischia non è probabilmente il metodo migliore da usare (poiché ho sempre scoperto che la mischia rende lo sviluppo più lento e non consente l'agilità sufficiente per alterare il processo quando necessario.

Ciò di cui hai bisogno, indipendentemente dalla metodologia, è impostare un backlog delle funzionalità richieste per dare visibilità sui progressi. I progressi su base per sprint non sono abbastanza buoni, non saprai se stai raggiungendo l'obiettivo finale. Quindi una metodologia in stile kanban sarebbe migliore: imposta tutte le funzionalità a sinistra e lavorale attraverso il sistema per mostrare i progressi fino al completamento.

Ciò focalizza le menti delle persone su ciò che deve ancora essere fatto in un modo che Scrum non gestisce e consente alle persone diverse dal team di sviluppo di vedere ciò che rimane e se è probabile che tu raggiunga l'obiettivo (e quindi gestisca le aspettative del cliente in anticipo o organizza quei bonus per gli straordinari prima che siano necessari).

Scrum è un sistema che va avanti per sempre, definendo e perfezionando continuamente qualcosa. Semplicemente non è adatto a questo tipo di sviluppo. Altri possono gestire questo sytle e mantenere ancora il concetto di sviluppo iterativo, Kanban è uno di questi, Crystal un altro. Ma ciò che è essenziale da capire è che se segui Scrum religiosamente, non sei agile. Qualsiasi vero sistema Agile dovrebbe essere in grado di trasformarsi per far fronte a questi problemi particolari, ecco perché è stato chiamato agile in primo luogo, si tratta di fare ciò che deve essere fatto, e se una scadenza fissa fa parte di questo, allora dovresti prendi in considerazione questo nel tuo modo di lavorare.

Il paradigma di sviluppo non è sincronizzato con il paradigma del contratto. Idealmente, il modo in cui i contratti vengono scritti cambierebbe, ma è improbabile che ciò accada effettivamente. Tuttavia, anche se dovessi abbandonare la mischia, avresti comunque sorprese e scadenze scadute (solo che probabilmente saresti molto più tardi perché hai fatto tutto quel disegno in anticipo ed era tutto sbagliato !!).

Con o senza una modifica alla modalità di scrittura dei contratti, spedisci ciò che stai lavorando . Quindi adempiere al contratto consumando un ciclo di tempo di sviluppo al fine di completare le funzionalità che non sono state eseguite.

È positivo che tu non sia riuscito a mantenere tutto ciò che hai promesso nel giorno in cui lo hai promesso? No, ma il tuo cliente sarà molto più felice se puoi consegnare qualcosa che funziona in tempo, quindi consegnare il resto rapidamente dopo che se sei semplicemente in ritardo e non hai nulla da offrire.

Molti libri e articoli Scrum affermano che uno sprint fallito (quando il team non riesce a completare alcune funzionalità dallo Sprint Backlog) non è qualcosa di così brutto, succede di tanto in tanto e può effettivamente essere utile se il team impara dai propri errori e migliora qualcosa nei seguenti sprint. E la squadra non dovrebbe essere punita per non aver completato il lavoro a cui si è impegnata.

Il modo in cui "punisci" questo tipo di comportamento è limitando la quantità di lavoro che chi non ha terminato può affrontare al prossimo sprint. Le possibilità di lavorare su cose interessanti stanno svanendo. La ricompensa per fare un buon lavoro è più lavoro.

Questo sembra fantastico dal punto di vista dello sviluppatore, tuttavia, supponiamo di avere una società di software "Scrum-Addicts LLC" che sta sviluppando qualcosa per clienti seri ("Money-Bags Corporation"):

I gestori di Scrum-Addicts suggeriscono di creare un software per Money-Bags Sono d'accordo su un elenco di funzionalità e Money-Bags chiede di fornire una data di spedizione I manager di Scrum-Addicts consultano il loro team di Scrum e il team dice che ci vorranno 3 settimane -lungo sprint per completare tutte le funzionalità Scrum-Addicts manager aggiunge 1 settimana per sicurezza, promette di spedire il software in 1 mese e firma un contratto con Money-Bags Dopo 4 sprint (termine di spedizione) il team Scrum può consegnare solo l'80% di funzionalità (a causa dell'inesperienza con il nuovo sistema, della necessità di correggere bug critici nelle funzionalità precedenti nell'ambiente di produzione, ecc ...) Come Scrum suggerisce, a questo punto, il prodotto è potenzialmente spedibile, ma Money-Bags ha bisogno del 100% di funzionalità, come indicato nel contratto. Quindi rompono il contratto e non pagano nulla.

Scrum-Addicts è sull'orlo del fallimento perché non ha ricevuto denaro da Money-Bags e gli investitori sono rimasti delusi dai risultati e non sono più disposti ad aiutare la società.

Se lunedì ti scommetto $ 100 che pioverà giovedì e non pioverà fino a venerdì avresti ragione di prendere i miei soldi. Se, piuttosto che la possibilità di giocare d'azzardo, quello che vuoi è una previsione meteorologica, allora abbiamo bisogno di un contratto che mi permetta di darti una previsione aggiornata martedì.

Ovviamente, nessuna società di software vuole essere nei panni di Scrum-Addicts. Quello che non capisco di Agile e Scrum è come suggeriscono ai team di gestire la pianificazione e le scadenze per evitare la situazione sopra descritta.

Pensa al perché MB vuole prendere la palla e tornare a casa. MB non ha richiesto che il lavoro venisse svolto all'inizio di un mese. SA ha promesso il 100% delle funzionalità critiche in un mese e non ha fornito. SA imposta la scadenza non MB. SA ha persino aggiunto arbitrariamente una settimana alla scadenza. Quindi perché è una scadenza?

Occasionalmente, quando competono per lavoro, le aziende di software cedono alla tentazione di mettersi in mostra e promettere la luna. I professionisti stabiliscono attentamente se è necessaria anche una luna. Qual è il bisogno più critico per MoneyBags? Il 100% delle funzionalità o un prodotto funzionante in un mese? Sanno persino cosa è veramente critico? C'è qualche evento imminente che fissa una scadenza dura?

Se fossi Scrum-tossicodipendenti a negoziare questo contratto, vorrei sapere molto di più sulle esigenze aziendali di Money-Bags e strutturare il contratto per garantire la massima flessibilità di Money-Bags. Insegnerei loro come funziona il processo agile in modo che sappiano cosa aspettarsi da noi.

In questo modo, invece di aspettarsi che tutto funzioni all'improvviso perfettamente entro un mese, si aspetterebbero di valutare il primo risultato disponibile in 1-2 settimane.

Quindi, per riassumere, ho 2 domande:

Di chi è la colpa? Manager, perché è il loro lavoro fare la corretta pianificazione
Il team, perché si sono impegnati a fare più lavoro di quanto potrebbero fare
qualcun altro

Chiunque avrebbe potuto fermare questa parodia prima che avessimo un mese lungo la strada.

Potrei arrivare a incolpare Money-Bags Corp per l'assunzione di una squadra che ovviamente ha rappresentato fraudolentemente un processo a cascata come agile. Il contratto stesso chiarisce che non è agile. Pianificare di essere fatto in un mese non lo rende agile.

Se insisti che sia agile, è agile con un solo sprint che dura un mese. Il che, sì, non lo consiglierei perché è, ancora una volta, la stessa cosa di Cascata.

Che cosa si deve fare?

Che ne dici di agile? Offri qualcosa ogni sprint? Ricevi feedback prima della scadenza? Scatti settimanali? Che ne dici di rinegoziare il contratto draconiano nel momento stesso in cui sospetti che la scadenza sia in pericolo piuttosto che nascondersi e pregare? Per lo meno puoi smettere di perdere tempo in un progetto condannato e trovare un cliente più ragionevole.

I gestori devono spostare la scadenza 2 volte (o 3 volte) più tardi rispetto alla stima del team originale.

I moltiplicatori di scadenza sono utili quanto impostare l'orologio con 15 minuti di anticipo, quindi non sarai mai in ritardo. Puoi solo ingannarti così a lungo prima di capire cosa stai facendo.

Le prime stime sono sbagliate. Prova a catturare quanto sbagliato. 5 settimane, dare o prendere alcune settimane è un'espressione semplice che ti consente di esprimere quanto sia incerta la data di completamento. Invece di provare a indovinare con precisione, indovina quanto è selvaggia la tua ipotesi. Fai un vero lavoro e ottieni alcuni dati reali. Quindi puoi iniziare a fare stime con un intervallo più ristretto. Una o due settimane sono un sacco di tempo per farlo.

I membri del team dovrebbero essere incoraggiati a fare tutto il lavoro che hanno commesso, indipendentemente dal fatto (emettendo penalità per sprint falliti)

I membri del team dovrebbero essere incoraggiati. Fallito, commesso o altrimenti. Invece di costruire conseguenze artificiali come punizioni o persino bonus (carote e bastoncini), gli studi hanno dimostrato che le persone che svolgono un lavoro creativo come la programmazione rispondono meglio se fornite tre cose: Autonomia, Maestria e Scopo.

Daniel Pink ne parla TED . Il discorso parla di motivazione non agile ma ho visto facilmente come mappare questi punti su agile:

Autonomia - Voglio dirigere la mia vita - Fammi scegliere il lavoro dal backlog.
Maestria: voglio migliorare in qualcosa che conta: feedback dei clienti.
Scopo - Voglio far parte di qualcosa di più grande di me - Una squadra collaborativa.

Il team dovrebbe abbandonare Scrum perché non corrisponde alla politica sulle scadenze dell'azienda. Scrum può rispettare una scadenza in modo più preciso rispetto a cascata. Data una scadenza, la mischia può soddisfarla. Potrebbe soddisfarlo con solo 1 delle 47 funzionalità a seconda del tempo, della funzionalità e dell'abilità, ma può soddisfarla.

Un progetto agile può essere disegnato in modo così estremo che ogni sera quando la squadra torna a casa è pronta per essere spedita. Questo sembra sciocco a meno che tu non pensi alla spedizione come a chiedere al cliente di testare e fornire feedback. Prima si verifica, prima è possibile apportare modifiche. Questo colpisce ogni possibile scadenza. Solo non tutte le funzionalità. Ma ti guida alle funzionalità che contano.

Dovremmo abbandonare tutti lo sviluppo del software e unirci a un monastero

Giusto, come rinchiudermi in una stanza lontana dalla vita reale mi farà scrivere MENO codice.

Ho modificato questa risposta fino alle dimensioni. Se sei curioso leggi la cronologia delle modifiche.

Tutti devono essere agili. Qualunque cosa tu decida che sarà, aspetto, chi fa cosa, come, quando, dove e perché da tutte le parti. Clienti, management e sviluppatori agili.

Non è possibile indicare una data di spedizione troppo lontana nel futuro. Dai un preventivo.

Qualcuno doveva gestire le aspettative del cliente. Il motivo per cui non ti preoccupi troppo di avere un paio di sprint è perché ti adegui per evitare che l'intero progetto rimanga indietro. Se dopo uno o due sprint giungi alla conclusione che non finirai di rispettare la "data di spedizione", è quando lo dici al cliente.

Ora cosa vuoi fare? Sbarazzati delle funzionalità che non ti servono o sposta la data. Se potessi consegnare in tempo, lo faresti. Non esitate a portare cattive notizie.

Chissà, su alcuni progetti, potresti spedire prima.

Non puoi essere agile se il cliente non vuole.

Obbiettivo

Credo che le seguenti due "metriche" dovrebbero essere la base per qualsiasi decisione commerciale:

• è il lavoro redditizio (per il cliente)
• stiamo lavorando nel modo più efficiente possibile

Questi sono abbastanza universali. Naturalmente diventa molto più complicato molto velocemente, ad esempio, il lavoro redditizio riguarda il prodotto che fa la cosa giusta, l'utente è in grado di utilizzare il prodotto, il prodotto viene commercializzato correttamente ecc. - per molti di questi " Scrum-tossicodipendenti LLC "non è responsabile.

Problema

Il contratto non si concentra sugli obiettivi sopra indicati. C'è una clausola "tutto o niente": fai tutto e fatti pagare, o non fai nulla e non essere pagato. Tuttavia, ciò non è direttamente correlato alla creazione di valore. Un altro aspetto negativo che segue: ora abbiamo bisogno di spendere tempo e denaro per assicurare e verificare che il contratto venga seguito. Perché mai vorremmo spendere questi soldi? In che modo garantire l'adempimento di un contratto aiuta nel frattempo a modificare i requisiti e abbiamo scoperto che il software ordinato non sta creando alcun valore? Ci sono solo più soldi che vanno in malora! Ora, ovviamente, c'è un motivo per questo comportamento:

• Culturalmente siamo abituati a fare acquisti per cose del genere. Ci aspettiamo di acquistare software come faremmo per un'auto: scegli una configurazione, ti verranno dati un prezzo e una scadenza, ed essere molto scontento se quei due non vengono rispettati.
• vogliamo scaricare il rischio e la responsabilità
• vogliamo stabilità, aiuta con la pianificazione e ci fa sentire meglio (e anche il nostro cliente, che è un aspetto importante!)

Alla fine, dovremo scegliere un compromesso che ci permetterà di raggiungere i nostri obiettivi nel miglior modo possibile.

Ecco come dovrebbe funzionare

• avere un contratto per servizi e lavoro anziché per un prodotto
  • deve essere risolvibile con un preavviso relativamente breve
• lavorare a stretto contatto per garantire l'efficienza ottimale
• coinvolgere tutte le parti necessarie, sia da " Scrum-Addits LLC " che da " Money-Bags Corporation " - un "punto di contatto unico" che scava tunnel tutte le informazioni non funzionerà qui

bene, in pratica ho appena detto "sii agile". Ora ecco perché:

• processo e contratto sono ottimizzati per spendere quanto più denaro possibile sull'obiettivo
• dovrai affidarti all'appaltatore per svolgere il suo lavoro e non dovrai investire molti soldi per verificare che sia all'altezza del lavoro.
• la capacità di citare in giudizio il contraente se le aspettative / il contratto non sono soddisfatti di solito non aiuta, perché farlo costerà di più che lasciarlo cadere. Alcune delle principali preoccupazioni qui sono il time-to-market. Molto probabilmente perderai molto più denaro / affari andando in tribunale di quanto otterrai.
  • alla fine della giornata dovrai solo correre dei rischi.