Lorenzo chiede e io rispondo.
Credo che in linea di massima tradizionali e agili vada bene anche se io, dopo adeguata spiegazione e discussione, preferisco definirli in un altro modo: Tayloristici ed Ermeneutici! Lorenzo in chat mi ha chiesto cosa fumo... ;-)
Per cercare di spiegare un minimo cosa intendo riporto alcune slide che ho usato in una lezione tenuta presso l'universita' di Milano qualche mese fa (non sono sicuro che il format sia efficace pero' e' un inizio):
--------------------------------------------------------------------
Nasce l’ingegneria del SW…
1968 ? crisi del software:
Più richieste che sviluppatori disponibili
Progetti cancellati ? 50%
Progetti di successo ? 20% (on time, on budget)
Progetti non cancellati ma falliti ? 30%
--------------------------------------------------------------------
...37 anni dopo
2005 ? crisi del software (almeno parzialmente) rientrata:
Molti sviluppatori (spesso delocalizzati per spendere meno)
Fallimento dei progetti ? 50%-60%
Progetti over time ed over budget ? 20%-30%
Qualità (mancanza) uno dei maggiori problemi
Inefficiente, pieno di bug, non user-friendly, marginalmente utile
--------------------------------------------------------------------
Formalismo
XVIII secolo ? illuminismo (Descarts, Hobbes, Leibniz):
Universo come un complicato meccanismo che opera secondo leggi conoscibili. Una volta comprese sarà possibile manipolarle a nostro piacimento
Formalismo, razionalismo, determinismo, meccanicismo
Controllo centrale, gerarchia, predicibilità, provabilità
Babbage, Turing, von Neumann ? si assicurano che la computer science si evolva in questo senso
Intelligenza Artificiale Classica (Newell, Simon, Minsky):
Scoprendo i token di base e le regole di manipolazione è possibile specificare una sintassi che catturi tutti i possibili significati
--------------------------------------------------------------------
Ingegneria del software
Ombrello per uno spettro di proposte:
Programmazione strutturata
Fondamenti formali (matematici e logici) per le specifiche
UML
ISO 9000
CMM
…
--------------------------------------------------------------------
Taylorism
Migliori tool, metodi e processi permettono di creare software migliore usando risorse umane nella media
Il lavoro dei manager sarà meno rischioso adottando metodi e processi strettamente formali (scientific management, moderna linea di assemblaggio)
Ingegneria del software: imporre processi e metodi puo’ compensare le mancanze delle persone:
Esistono certamente casi di successo
Le statistiche pero’ mostrano che quasi nulla è cambiato dal 1968
--------------------------------------------------------------------
Ermeneutica
Ermes ? il messaggero o dio della comunicazione
Husserl, Heidegger, Gadamer, Dilthey, Vygotsky
Contesta tutte le basi del formalismo
Iterative development & Object thinking
Le parole (token del pensiero secondo i formalisti) non hanno un significato chiaro e non ambiguo. La semantica viene negoziata e determinata dalle persone che le stanno usando in un dato momento.
Emergono durante il processo di comunicazione
Fondamentale non determinismo dell’universo, auto-organizzante, adattivo, evolutivo (Gell-Mann, Kauffman, Langton, Holland, Prigogine, Wolfram, Maturana & Varela)
--------------------------------------------------------------------
Software Craftsmanship
Obiettivi condivisi (software improvement) ma rigetto delle assunzioni implicite dell’ingegneria del software a favore di:
Creatività
Arte
Ruolo centrale dell’uomo
I Metodi Agili ne rappresentano l’incarnazione contemporanea
--------------------------------------------------------------------
Persone migliori
Sono da tutti riconosciute come la più promettente soluzione ma ancora oggi quasi tutta la nostra energia viene spesa nella creazione di tool, metodi e processi invece che nella crescita delle persone!
Motivo: le persone sono un problema più difficile da risolvere dei tools, delle tecniche e dei processi.
--------------------------------------------------------------------
Reazioni
Marginalizzazione:
Sono ok per piccoli progetti
Con piccoli team
In progetti non mission-critical
Assorbimento:
Sono solo un subset di RUP
Delegittimazione:
Solo un disturbo da parte di alcuni petulanti Smalltalker arrabbiati per la sempre minor importanza del proprio linguaggio preferito
--------------------------------------------------------------------
Ammissioni…
Parnas, Dykstra, Boehm, Yourdon, Martin ammettono ora che gli sviluppatori con grandi skill e produttività NON lavorano nel modo in cui, secondo i metodi tradizionali, dovrebbero!
L’unico fattore veramente cruciale per sviluppare software di alta qualità è avere buoni sviluppatori.
--------------------------------------------------------------------