Decidere la data di uscita prima di raccogliere tutti i requisiti non è agile?

Ho appena iniziato a leggere il libro Applying UML and Patterns di Craig Larman. Lo trovo molto interessante perché sfida molti di ciò che mi è stato detto al lavoro. Ho letto che i requisiti non sono completamente raccolti in una volta sola in agile e ci vogliono molte iterazioni per completare la raccolta dei requisiti. Se questo è il caso, sta fissando una scadenza fissa, che è quello che sono costretto a fare sul lavoro, molto poco agile, considerando che domani potrebbero esserci nuovi requisiti rivoluzionari (o richieste di modifica mascherate da requisiti)?

Non c'è assolutamente alcun problema "Agile" con una data di rilascio fissa se si è pronti a spostare uno degli altri due bordi del "triangolo di ferro": i requisiti per ciò che deve essere presente in quella versione o le risorse disponibili . Non è possibile risolvere tutti e tre - e in pratica, il lato "risorse" del triangolo è molto spesso o non molto flessibile o inefficiente da modificare.

Se c'è un nuovo importante requisito domani, va bene finché l'azienda è pronta ad accettare che il requisito potrebbe non rendere la data di rilascio, ovvero passare alla versione successiva.

Penso che il problema in molti campi Agile sia con la parola scadenza. Il rischio con una scadenza è che tu presumi di sapere cosa deve essere fatto. Come fai notare, non puoi avere una scadenza per uno sconosciuto.

Ciò che è descritto nella risposta di Filippo è molto meno una scadenza che un vincolo. Potremmo dire che abbiamo finanziamenti fino a marzo e quindi dobbiamo rendere il miglior prodotto possibile in quel momento.

Per fare un'analogia, supponiamo che ti chieda di andare alla storia della spesa e acquistare tutti i generi alimentari per la settimana e, prima che tu vada o guardi tutti i prezzi, voglio che tu mi dica esattamente cosa spenderai. Inoltre, sarai penalizzato se sbagli. Farai esattamente quello che fanno le persone con le scadenze del progetto: sceglierai un numero nella fascia alta di quello che pensi che l'intervallo potrebbe essere perché ha la più bassa probabilità di essere penalizzato. Ora, diciamo che ti dico che questo è inaccettabile e devi acquistare le stesse cose che avevi pianificato, ma devi farlo per $ 50 in meno, oppure. Ora cosa puoi fare? Puoi rifiutare, puoi semplicemente rimandare l'argomento fino a dopo aver fatto acquisti, oppure puoi trovare un modo per ingannare la situazione. Questo è ciò che accade in molte organizzazioni con scadenze fissate su incognite.

Ora, vedendo quanto sia malsana tutta questa situazione, Agile dice semplicemente "Se hai un budget, posso promettere di rientrare in quello stato e offrirti i migliori pasti possibili per questa settimana in quel vincolo". Che è una conversazione molto più sana da avere.

Agile è una tecnica, non un risultato. Rispetto alla falciatura del prato, un'iterazione è come una linea di erba che hai falciato. Se qualcuno dice "falcia il tuo intero prato in 15 minuti" e stai usando agile, forse alla fine completerai il 30%. Quindi ripeterai più tardi e finirai.

Puoi avere una data di uscita pianificata senza problemi. Assicurati solo che a questa data particolare non abbia fine. Si dovrebbe avere un prodotto che potrebbe essere spedito alla fine di ogni sprint, ma di solito non c'è niente di male se non lo fanno; è più un obiettivo che concentra il lavoro anziché un requisito. Se hai una data di uscita pianificata, devi avere un prodotto rilasciabile a quella data.

Di solito mirerai ad avere un prodotto non testato, ma si spera possa essere rilasciato un po 'di tempo prima della data di rilascio pianificata, quindi il prodotto viene testato e i bug corretti fino al rispetto degli standard di qualità, quindi viene rilasciato senza alcun panico necessario. Il rilascio conterrà tutto ciò che era pronto in quel momento.

Ora potrebbe non essere ovvio per il tuo capo che dovresti pianificare anche una seconda data di rilascio, con più funzioni effettivamente implementate.