In un processo agile, il proprietario del prodotto ha inserito le idee non formali / gli articoli degli utenti / backlog nello sprint / iterazione. Sprint / iteration è come un piano per un breve periodo ed è guidato da una riunione quotidiana. La pianificazione è fatta in entrambi i processi. Quindi qual è la differenza tra lo sviluppo agile e il vecchio piano?
I processi pianificati e quelli agili per il software possono essere rapidamente caratterizzati da alcune coppie.
In qualche modo, questa domanda ha già ricevuto risposta dal Agile Manifesto , ma invece di leggere da sinistra a destra, leggi da destra a sinistra.
Alcuni dei confronti sopra riportati possono essere un po 'aspri, perché certamente c'è un sacco di sviluppo basato sulle funzionalità che è prassi con pianificato, e le pubblicazioni possono essere trimestrali (ma probabilmente non mensilmente).
I migliori pensatori dietro il processo pianificato sono stati influenzati da problemi con approcci ad-hoc o poco adatti a software come quelli descritti in Mythical Man-Month. Già nel 1968, la NATO ha tenuto una conferenza sull'ingegneria del software per cercare di risolvere la crisi e a quel punto. Penso che abbiano avuto delle grandi innovazioni. Pagina 12 del loro rapporto della conferenza ha un disegno notevole che descrive la cascata ma con le curve invece di scatole. Include anche materiale sulle sfide della stima dei progetti software. Successivamente, gli esperti di processo software pianificati hanno preso in prestito e rubato dai pionieri del controllo qualità come Demming e dai numerosi esperti giapponesi che hanno dimostrato il loro valore nella produzione di automobili ed elettronica.
Penso che i migliori pensatori agili fossero estremamente familiari con il processo pianificato e reagirono contro i suoi limiti, pur mantenendo alcuni dei suoi punti di forza. Il processo pianificato non ha perso tutta la sua rilevanza e alcuni sostengono che sia essenziale per i grandi progetti. Pianificato è ancora ampiamente utilizzato, in particolare nelle grandi organizzazioni, ma molti cercano di ibridarsi con tecniche agili. Forse sono pianificati approcci progettuali di System of Systems, ma hanno una buona caratteristica di creare piccoli team che è un posto più pratico per l'agile. Pianificato era sensibile alla necessità di sartoria locale, ma si aspettava che sarebbe stato facilitato da riunioni e comitati.
Grandi riferimenti a questo argomento includono libri, articoli e rapporti tecnici di Watts Humphries sul gruppo organizzativo e processo del software personale. Confrontate quelli con le sezioni introduttive di Kent Beck da Programmazione eXtreme illustrata .
Uno dei miei professori ha descritto la storia dello sviluppo del software qualcosa del genere:
Teoricamente @JVXR è giusto. Cascata significa che ottieni i requisiti, pianifica il lavoro, imposta il prezzo e il programma di consegna in un batter d'occhio. Alla fine, tutto si riunisce, spesso i requisiti erano sbagliati o cambiati, il lavoro era più del previsto e si trasforma in una grande palla di fango. Agile promette di risolvere tutti i problemi della cascata facendo piccoli lavori in risposta alle mutevoli esigenze e aumentando le conoscenze, offrendo regolarmente qualcosa di valore per il cliente e fermandosi quando il cliente decide che il lavoro è fatto (in realtà - quando i soldi si esaurisce).
I problemi relativi alle cascate sono ben noti e documentati e quindi facili da suggerire soluzioni. Agile ha anche i suoi problemi, tuttavia sono meno conosciuti e anche meno documentati - noi, come industria, abbiamo provato a cascata e abbiamo fallito miseramente. Ora stavano provando con Agile, e fallendo (leggermente meno miseramente, ma continuando a fallire), e nessuno vuole suggerire che non funzioni finché non possono vedere / vendere una soluzione migliore.
Di conseguenza, per ogni 100 software house, ci sono probabilmente 200 processi "agili" dichiarati (molti negozi hanno più di una squadra e una parte dell'agile è una squadra che può farlo come preferiscono. questi processi sono veramente agili, il resto è meglio descritto come cascata nella resistenza (es. cascata senza la documentazione)
Lo sviluppo basato sul piano si concentra sulla creazione di un piano upfront dettagliato mentre agile, o più accuratamente scrum, rimanda piani dettagliati fino a quando il lavoro sta per iniziare e consente di modificare l'ordine o la priorità del lavoro. Ciò minimizza l'impatto del cambiamento e significa che le decisioni (cioè i piani) possono essere prese quando la maggior parte della conoscenza è disponibile. Mentre lo sviluppo in base al piano richiede che il piano venga revocato quando si verificano cambiamenti e richiede che la maggior parte delle decisioni vengano prese in anticipo quando il team conosce il problema e le soluzioni.
Per "Vecchia pianificazione" Suppongo che tu voglia dire cascata, Non c'è alcun feedback da parte dei clienti fino a quando il prodotto non viene sviluppato e consegnato, e solitamente questo è quando le cose colpiscono la ventola nel processo a cascata. La cascata dipende in gran parte dai "documenti dei requisiti", che il cliente giurerà di non aver mai detto nulla del genere nel giro di mesi.
In agile, in teoria si producono piccoli incrementi di lavoro e si ottiene il feedback del cliente e lo si incorpora nella prossima versione. Quindi le probabilità di colpire il ventilatore sono ridotte. Nel complesso, il cliente sente di ottenere qualcosa da quello che ti sta pagando.
Leggi altre domande sui tag development-process agile scrum