Sviluppo agile

"Ciao, Amico!"

"Ciao Bilaabo!"

"Oggi vi parlerò di come vengono solitamente sviluppati i programmi."

"Nel 20° secolo, quando l'IT moderna era agli inizi, tutti sembravano pensare che la programmazione fosse come la costruzione o la produzione".

"Le cose di solito andavano così:"

" Il cliente spiegherebbe il tipo di programma di cui aveva bisogno, cosa dovrebbe fare e come dovrebbe farlo."

" Gli analisti aziendali lo ascolterebbero e stilerebbero un elenco completo dei requisiti del programma in base a ciò che ha detto".

"Quindi i project manager dividerebbero questi requisiti in attività e determinerebbero anche quale programmatore svolgerebbe quale attività e in quale ordine".

"Quindi i programmatori si mettevano al lavoro. A volte lavoravano per diversi anni (!)."

"Quando hanno finito, il programma è stato dato ai tester".

"I tester esaminavano ciascuno dei requisiti del programma per verificare che fossero implementati e che il programma funzionasse come previsto".

"Se qualcosa andava storto, i tester registravano i bug e li inviavano ai programmatori."

"Quindi i programmatori correggerebbero i bug e rispedirebbero il programma corretto ai tester. E il ciclo si ripeterebbe."

"Quando i bug principali sono stati corretti, il programma è stato consegnato al cliente."

"È davvero così che sono andate le cose?"

"Beh, certo, ho semplificato molto, ma è abbastanza vicino a come sono state fatte le cose."

"E un progetto potrebbe davvero richiedere da un anno e mezzo a due anni per essere completato?"

"A volte, se lo sviluppo di un progetto era molto lungo, lo suddividevano in versioni separate. Ogni 3-6 mesi, gli sviluppatori dovevano creare una parte specifica della funzionalità del programma, testarla, correggere tutti i suoi bug e mostrarla al cliente."

"Prima di tutto, in modo che potesse condividere le sue impressioni. E in secondo luogo, e cosa più importante, in modo che continuasse a pagare per lo sviluppo del programma."

"Continui a pagare?"

"Allora, lo sviluppo richiedeva spesso 2-3 volte più tempo del previsto. E poiché i programmatori venivano spesso pagati a ore, il programma diventava 2-3 volte più costoso. Inoltre, anche i vantaggi erano ridotti. Dopotutto, ciò che il cliente desidera oggi per $ 100.000 potrebbe non essere necessario in 3 anni, specialmente a tre volte il prezzo."

"I clienti si rifiutavano spesso di pagare?"

"Sì. In seguito hanno iniziato ad aggiungere sanzioni al contratto, ma questo non ha migliorato la situazione. Lo sviluppo del software si trascinava all'infinito. E nessuno poteva farci niente, anche se lo volesse."

"Ma perché?"

"Beh, in primo luogo, si sa troppo poco durante la fase di pianificazione. Il più delle volte, all'inizio, nessuno poteva prevedere i problemi che i programmatori avrebbero dovuto affrontare."

"Ma i programmatori esperti dovrebbero essere in grado di prevedere tutto, giusto?"

"Vedi che la programmazione è una professione unica."

"Un lavoratore ordinario svolge spesso lo stesso lavoro più e più volte. Gli orologiai fabbricano orologi, i cuochi cucinano, gli insegnanti insegnano, i medici trattano, ecc."

"Ciascuno di questi professionisti fa fondamentalmente la stessa cosa giorno dopo giorno. Di conseguenza, iniziano a migliorare sempre di più nel loro lavoro".

"Nella programmazione, l'approccio è diverso. Non appena un programmatore affronta lo stesso compito ogni giorno, scrive una funzione, un modulo o un programma per eseguirlo e non ci torna più".

"Ogni programmatore di solito risolve ogni compito una volta nella vita."

"Qualcosa come scienziati o ingegneri progettisti che inventano cose."

"Ah. Beh, qual è il ruolo più importante in un progetto?"

"Hmm, come dovrei rispondere. È facile dire qual è il più importante, ma identificare il meno importante è difficile."

" Il compito principale di un tester ( Q uality  A ssurance, QA )  è monitorare lo stato di un programma e segnalare tempestivamente i bug. Quanto più e prima un tester trova bug, tanto più questi possono essere risolti.  Un buon tester influenza la qualità del prodotto più di un buon programmatore lo fa ."

"Perché i programmatori non possono testare i propri programmi. Dopotutto, non sanno meglio dei tester cosa funziona e cosa non funziona?"

"Un buon programmatore è semplicemente incapace di essere un buon tester. Un programmatore sa come funziona davvero bene il programma, quindi lo usa sempre in un certo modo. A differenza degli utenti ordinari che usano il programma come preferiscono. "

"Inoltre, i tester non testano ciò che non funziona ancora. Il tester verifica la funzionalità o le parti del programma che secondo il programmatore funzionano già quasi perfettamente."

"E quando il tester trova tonnellate di bug in quella funzionalità e il programmatore li corregge, allora il prodotto si avvicina effettivamente alla perfezione."

" Il compito principale di un programmatore ( S oftware  Developer Engineer  ,  Developer ,  SDE ) è quello di implementare nuove funzionalità. O, più semplicemente, eseguire i compiti che gli sono stati assegnati. Quando ai programmatori vengono assegnati compiti con nuove funzionalità , li eseguono. Quando vengono assegnati bug, li correggono."

"Ma a volte ci sono compiti più impegnativi, ad esempio elaborare l'architettura per il programma o parti di esso. Migliore è l'architettura proposta, più facile sarà fare le cose in futuro."

"Il problema è che l'architettura deve essere scelta all'inizio, ma è solo quando sei nel mezzo dello sviluppo che è chiaro se hai scelto l'architettura giusta".

"Inoltre, se l'architettura ha successo e il programma risulta ottimo, probabilmente il cliente vorrà usarlo come base per nuove versioni del programma."

"Ecco a cosa sto arrivando."

"Qualunque architettura tu scelga, ci saranno sempre un sacco di modifiche, aggiunte e nuove funzionalità che l'architettura non tiene conto."

"Ecco un buon esempio."

"Un cliente ti chiede di costruire un edificio di 5 piani, quindi progetti un'architettura e costruisci la casa."

"Quindi il cliente chiede di aggiungere un'altra storia, e poi un'altra, e così via."

"Ma le pareti del primo piano non sono state progettate per così tanto peso, e nemmeno le fondamenta. Quindi tutto deve essere rifatto."

"Ma dopo che l'edificio di 5 piani è finito, cosa succede se il cliente decide immediatamente di volere un edificio di 50 piani?"

"Sarebbe più facile demolire la struttura esistente e ricostruire tutto da zero..."

"Ma ho un consiglio da darti riguardo all'architettura."

"L'architettura di un'applicazione deve, prima di tutto, essere flessibile, il che significa che non dovrai ricominciare da capo se decidi di rifare metà dell'applicazione. Questo tipo di architettura è solitamente chiamata flessibile e modulare . "

" Il compito principale del project manager è prendere decisioni. Il project manager è colui che vede il quadro generale e prende decisioni basate su quella prospettiva."

"Supponiamo che durante lo sviluppo diventi chiaro che una determinata attività non verrà completata come previsto. Il project manager può quindi:"

" a)  provare a negoziare con il cliente per modificare l'attività"

" b)  dedicare più tempo all'attività"

" c)  coinvolgere programmatori più esperti da altri progetti."

"E ci sono molte altre possibilità."

"Ogni opzione richiede di sacrificare qualcosa e il lavoro del manager è ridurre al minimo le perdite totali derivanti da questi sacrifici " .

"Ad esempio, supponiamo che i concorrenti rubino il capo programmatore offrendogli il doppio dei soldi."

"Il project manager può:"

" a)  non fare nulla. Il programmatore se ne andrà e il progetto probabilmente rimarrà indietro e incorrerà in sanzioni."

" b)  raddoppiare il suo stipendio. Quindi anche tutti gli altri membri del team vorranno aumenti. Se dai a tutti loro più soldi, i costi del progetto aumenteranno e potrebbe diventare non redditizio."

" c)  qualche altra opzione che pensi."

"Vedo."

"Con un cattivo project manager, un buon team di solito allunga un progetto, ma non sempre."

"Un buon manager con un team di programmatori mediocri completerà quasi sempre un progetto più velocemente di un cattivo manager con un team di programmatori eccellenti."

"Vedo."

"Va bene, facciamo una breve pausa e poi continuiamo."