Then we first need to refactor many of things because the real needs are a little bit different

Stai creando un falso dilemma.

Le esigenze reali sono quasi sempre diverse da ciò che gli utenti pensano / possono dirti. Agile cerca di trovare queste differenze più vicine a quando il codice viene scritto anziché alla fine di un progetto completo.

Agile NON è "inizieremo a programmare e vedere cosa succede". Se non sai nemmeno quali funzioni hai intenzione di lavorare per uno sprint o se cambiano in modo consistente, hai aggiunte o modifiche significative durante lo sprint, non stai facendo veramente lo sviluppo Agile.

Hai bisogno di una pianificazione sufficiente per essere in grado di fare uno sprint senza rivedere costantemente i requisiti / le storie degli utenti. Se ciò non sta accadendo, non stai realmente utilizzando Agile in modo appropriato.

Questa domanda correlata descrive i tempi approssimativi di pianificazione. Potresti trovarlo utile Inoltre, questa risposta tratta direttamente la pianificazione di Agile.

Agile! = nessuna pianificazione (contrariamente a molte prospettive ...).

Definisci "pianificazione"

Per "pianificare", penso che intendi comprendere i bisogni e capire come farlo, in genere con un gruppo di stakeholder (specialmente utenti) e sviluppatori (e altri). Ciò comporta molte conversazioni, pensieri, tempo di apprendimento ecc.

I metodi tradizionali cercano di pianificare troppo per iniziare, quasi sempre con informazioni incomplete / instabili.

Agile riconosce che le informazioni sono incomplete (in qualsiasi punto del progetto, ma soprattutto all'inizio), e quindi favoriscono conversazioni frequenti e incrementali (e progettazioni / adattamenti del piano).

Supponiamo che sia necessario un certo volume V di comunicazione per ottenere la comprensione reciproca necessaria per pianificare ed eseguire correttamente un progetto. Quanta V dovrebbe essere consumata in anticipo rispetto a in-process è soggettiva.

Personalmente, mi piace consumare abbastanza V up-front per iniziare; una volta che tutti hanno un'idea di base / metafora / obiettivo ed è entusiasta del progetto, entra in qualcosa con un valore tangibile e mostra vantaggi, ma con tutte le conversazioni aggiuntive (ma più mirate) necessarie.

Agile non significa nessuna pianificazione , o anche meno pianificazione ; ma può significare nessuna fase di pianificazione nel progetto.

In un vero progetto Agile, il team è sempre in fase di pianificazione, ma in blocchi più piccoli. Ogni nuova conoscenza acquisisce il "piano" in un modo o nell'altro. Il piano stesso è fluido e accetta il cambiamento.

Il problema è che c'è la tendenza a voler sedersi e documentare il piano. Nel momento in cui lo fai, il piano diventa un po 'fuori dal contatto con la realtà, che è in costante cambiamento. Il più tempo che passi a documentare il piano, può diventare più sfuocato .

Agile riconosce questo fatto contro-intuitivo e cerca di ridurre al minimo la pianificazione quando meno conosci ciò di cui i tuoi utenti hanno bisogno (cioè all'inizio del progetto) e massimizza la pianificazione più vicina a quando ne sai di più (cioè più avanti nel progetto, mentre stai sviluppando e ricevendo feedback). Agile riconosce anche che in molti casi, documentazione del piano è meno utile / importante di esecuzione del piano.

In quanto tale, Agile chiede di spendere solo quanto basta per pianificare il tempo e gli sforzi (e documentare il piano) per consentire al progetto di andare avanti in modo responsabile. Più di questo, ed è uno spreco.

Direi che Agile (nel mio caso la mischia agile) è in realtà una pianificazione differita rispetto alla cascata. La differenza è una pianificazione agile Personalmente ritengo che il vostro piano su larga scala sia sfocato / non ancora dettagliato, ma il vostro piano a breve termine è pianificato in modo estremamente dettagliato. Come richiesto a Waterfall, dove tradizionalmente hai pianificato l'intero progetto (nella misura in cui potresti realisticamente farlo)

Pianificazione agile

Lo stesso Agile può essere suddiviso in tonnellate di sotto metodologie, ma al più alto livello ha piani dettagliati per un periodo di tempo limitato da 1 settimana a 1 mese, un passato che sta davvero spingendolo. I tuoi piani a lungo termine più di 1 mese lungo la strada in genere non sono pianificati in modo molto dettagliato (ancora) e vivono come elenco di funzionalità, bug, ecc. Da fare un giorno nel tuo backlog.

La pianificazione del tuo breve termine "sprint" è molto dettagliata. Pianifichi l'intero sprint, chi farà cosa, i dettagli tecnici, ecc. La precisione di questi piani varia da squadra a squadra, ma in generale i negozi di successo tendono ad aria sul lato di una pianificazione più che meno. La fine del tuo sprint è la tua scadenza, tutto il lavoro elencato dovrebbe essere fatto da allora (si applicano eccezioni)

In genere elencherai tutti i tuoi desideri / necessità in un backlog, ogni sprint che inizi dagli elementi più importanti li dividerà fuori dalla tua squadra fino a quando non li avrai assegnati al punto in cui saranno tenuti occupati, mentre in modo realistico finendo in tempo.

Ripeti questo processo ogni sprint. Ciò rende la pianificazione progressiva in modo che la situazione del progetto cambi il progetto in grado di adattarsi.

Tradizionalmente a cascata hai pianificato tutto in anticipo e hai speso 3,6 o 12 mesi a martellarlo, poi tornare indietro e aggiustare le cose alla fine.

un modo di pensare agile è che è ancora cascata, solo i tuoi rilasci sono settimanali e non annualmente. (qualcuno non sarà contento, l'ho detto, il mio punto è che pianifichi le cose solo attraverso la scala del piano, è più piccola, ma più spesso.)

BA talks to key users, collects data, which are pretty much just a sketch what they really want.

Pensi che il BA dovrebbe impiegare più tempo, porre domande migliori, raccogliere più dati in modo da poter pianificare l'intera strategia con poco o nessun refactoring? Perché gli sviluppatori non chiedono maggiori dettagli prima di iniziare a codificare? Sembra che ci sia una storia qui.

we realize they need a bigger system we expected, following that we need to make bigger refactor and generalize everything afterwards.

Fai una specie di retrospettiva e determina se queste cose potrebbero essere state identificate prima piuttosto che dopo. Potresti scoprire che nessuno se lo aspettava affatto.

Is this the way it should be?

Non so "dovrebbe essere" ma di solito è così com'è e agile è un modo per gestirlo meglio. Come ti sentiresti se passassi più tempo a raccogliere specifiche incomplete, a spendere mesi a scrivere il codice e poi dover riscrivere tutto questo? Suona anche peggio.

Given by the information are we doing it in the good way? And if the answer yes, then does the low planning costs match with the higher refactoring and rewriting costs? So to say: profitable?

Devi capire perché i requisiti "reali" non vengono riconosciuti fino a quando non si sono verificati alcuni sviluppi (non è così raro). Forse il BA può raccogliere di più o forse hai bisogno di fare più domande e farlo tornare ai clienti per i dettagli.

A volte devi creare qualcosa e metterlo davanti ai clienti in modo che possano determinare cosa vogliono veramente. Pochi possono farlo in astratto. Non aspettarti di raddoppiare la tua pianificazione anticipata e dimezzare lo sviluppo. Probabilmente ti troverai a fare piani più dettagliati che vengono semplicemente buttati via perché molti posti non prendono il tempo di riscriverli a causa di un ritardo.

Ho agito da anni ormai: l'unica risposta alla tua domanda è: "sì".

Lo sviluppo agile si traduce in qualcosa di simile a una pianificazione minima o quasi del tutto assente - si concentra su soluzioni flessibili e orientate al cliente - in realtà pianificazione la soluzione elimina completamente flessibilità / agilità perché il cliente è legato alle sue specifiche e alle sue storie.

È un processo un po '"caotico", anche se non proprio; le soluzioni sono implementate in un ambiente rigorosamente preimpostato che si piega secondo regole di flessibilità / agilità, scrum (per esempio) non ha alcuna pianificazione (se non si conta la programmazione sprint), ma il processo di il cambiamento può avvenire solo attraverso il lavoro di gruppo, la pianificazione strategica e tattile e grandi quantità di feedback da parte degli utenti. Nel risultato, il team avrà implementato una soluzione altamente funzionale e altamente conforme agli utenti anche in termini di tempo inferiore rispetto ad altri processi / framework ... se eseguita correttamente (sarà necessario un team altamente competente) la mancanza di pianificazione non fa del male, ci sono solo piccoli inconvenienti che sono molto gestibili e possono essere eliminati nel tempo con poco sforzo.