Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Seminario Project Management e il Mito del Garage Marco A. Boschetti Università di Bologna
Il Mito del Garage
https://www.businessinsider.com
2
Il Mito del Garage
Alcune aziende di successo hanno avuto inizio in un garage dove un gruppo
di giovani intraprendenti ha sviluppato soluzioni in grado di competere con
quelle prodotte da aziende strutturate con team più numerosi e organizzati.
https://www.gettyimages.it/immagine/steve-jobs-garage
3
Il Mito del Garage
Alcune aziende di successo hanno avuto inizio in un garage dove un gruppo
di giovani intraprendenti ha sviluppato soluzioni in grado di competere con
quelle prodotte da aziende strutturate con team più numerosi e organizzati.
https://www.gettyimages.it/immagine/steve-jobs-garage
4
Il Mito del Garage: Apple Computers
La leggenda vuole che Steve Jobs e Steve
Wozniak svilupparono il loro primo PC in
un garage.
Recentemente Wozniak ha confessato che
la maggior parte del lavoro lo ha svolto nel
suo “cubicolo” presso HP, che però non ha
creduto nel suo progetto.
Però l’essenza non cambia: Wozniak e Jobs
hanno sviluppato il loro primo PC.
Certo che il risultato, seppur funzionante,
era tutto tranne che un “prodotto”.
Cosa gli mancava per essere un prodotto?
5
Il Mito del Garage: Apple Computers
6
Il Mito del Garage: Google
Larry Page e Sergey Brin scrissero la prima versione Google quando erano
entrambi studenti di dottorato alla Stanford University nel loro garage.
7
Il Mito del Garage: Facebook
Come è nata l’idea di Facebook? Non in un garage, ma in un campus!
Tutto iniziò nel 2003, quando Mark Zuckerberg creò un’applicazione online
chiamata “Facemash”, che consentiva di confrontare delle foto di compagni
di università per determinare “chi era più sexy”.
8
Il Mito del Garage: Facebook
9
Dal Garage al Mercato
● In un garage possono nascere buone idee e prototipi interessanti, ma non
prodotti.
● Le soluzioni sviluppate in un garage non hanno richiesto un’approfondita
analisi dei requisiti e dell’architettura, un insieme di test sufficiente, una
documentazione dettagliata, un piano di manutenzione, etc.
● Per portare sul mercato un prodotto è necessario fare un piano.
● Se siamo una start-up e cerchiamo finanziatori la prima cosa da scrivere è
un business plan.
● Gli elementi fondamentali possono essere sintetizzati in due keywords:
Goal Progetto
10Il Goal
Il goal del Programma Apollo: “Landing a man on the Moon by the end of this
decade and returning him safely to the Earth.” (President J.F. Kennedy’s 1961
challenge).
11Il Progetto
● Per raggiungere il goal è necessario definire il progetto.
● Un progetto è un’iniziativa temporanea intrapresa per creare un prodotto,
un servizio o un altro risultato con caratteristiche di unicità.
● Un progetto è una sequenza unica, complessa e connessa di attività che
hanno un obiettivo ben preciso e devono essere completate rispettando
le specifiche e i vincoli di tempo e di budget per fornire il “business value”
atteso. Le attività derivano dai requisiti.
Attività A Attività D
Inizio Attività C Fine
Attività B Attività E
12Project Management
Definizione del Project Management Institute (PMI)
Il project management (gestione di progetto) corrisponde all’applicazione di
conoscenze (knowledge), capacità (skills), strumenti (tools) e tecniche alle
attività di progetto per soddisfare i requisiti (requirements).
Definizione di Wysocki
Il project management corrisponde a un insieme di strumenti, templates e
processi studiati per rispondere alle seguenti domande:
● Quale problema/opportunità affronta il progetto?
● Cosa hai bisogno di fare?
● Cosa farai?
● Come lo farai?
● Come saprai che lo hai fatto?
● Quanto bene lo hai fatto?
13Project Management Life Cycles
Definizione del Project Management Life Cycle Model (Modello del Ciclo
di Vita della Gestione del Progetto)
Il ciclo di vita della gestione di un progetto è modellato con una sequenza
di processi che possono essere raggruppati nei seguenti 5 gruppi:
● Scoping: definizione dell’ambito del progetto;
● Planning: pianificazione;
● Launching-Execution: avvio ed esecuzione del progetto;
● Monitoring & Controlling: monitoraggio e controllo;
● Closing: chiusura del progetto.
I cinque gruppi di processi contribuiscono al raggiungimento degli obiettivi
del progetto e devono comparire almeno una volta nella sequenza. Alcuni
di essi possono essere ripetuti anche più volte.
14Cosa sono i requisiti?
Definizione di Requisito (IEEE Std 610.12)
(A) A condition or capability needed by a user (stakeholder) to solve a
problem or achieve an objective (scope).
(B) A condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard, specification, or
other formally imposed documents (solution).
(C) A documented representation of a condition or capability as in
definition (A) and (B).
Un requisito rappresenta uno stato finale desiderato, la cui integrazione
con successo nella soluzione fornisce un aumento specifico e misurabile di
business value.
15Alcuni esempi di progetti
Esempi per ogni tipo di progetto:
TPM Installare un prodotto software standard.
APM Realizzare un sistema di e-commerce.
SOLUTION
xPM Realizzare un nuovo prodotto innovativo. Clear Not Clear
MPx Trovare un impiego per una Not Clear MPx xPM
nuova tecnologia sviluppata. GOAL
Clear TPM APM
16Project Management Life Cycle Models
Linear Project Management Life Cycle Model
17Project Management Life Cycle Models
Incremental Project Management Life Cycle Model
18Project Management Life Cycle Models
Iterative Project Management Life Cycle Model
19Project Management Life Cycle Models
Adaptive Project Management Life Cycle Model
20Project Management Life Cycle Models
Extreme Project Management Life Cycle Model
21Ciclo di Vita di un Progetto
22Ciclo di Vita di un Progetto
23Ciclo di Vita di un Progetto
24Qualità
Definizione
In un progetto vengono considerati due tipi di qualità:
● Qualità del prodotto: è riferita alla qualità del deliverable del progetto.
Il termine “prodotto” può essere riferito a un bene tangibile, come un
software, ma anche a processi aziendali o altro.
● Qualità del processo: è riferita alla qualità del processo di gestione del
progetto. In questo contesto si vuole misurare la bontà del processo di
gestione del progetto e individuare eventuali miglioramenti.
La corretta gestione della qualità, del prodotto e del processo, permette di
garantirsi la soddisfazione del cliente e consente anche all’organizzazione
(e.g., software house, etc.) di usare le proprie risorse in modo più efficace
ed efficiente, riducendo sprechi e revisioni.
25Scope Triangle
Scope e Qualità
Risorse Disponibili
26Il punto di vista di Brooks
● F.P. Brooks è stato un “computer scientist” e “software engineer” che è
stato responsabile dei progetti per lo sviluppo della famiglia di computer
IBM System/360 e del sistema operativo IBM OS/360.
● La notorietà di Brooks è comunque soprattutto dovuta al suo libro “The
Mythical Man-Month” pubblicato nel lontano 1975 e agli articoli che lo
hanno accompagnato, che hanno generato un vivace dibattito che dura
ancora oggi.
● Le idee proposte da Brooks, che non devono essere considerate come
verità assolute, ma costituiscono una interessante base di discussione.
● Uno degli argomenti proposti da Brooks è riassunto nella seguente frase
nota come Legge di Brooks:
“adding people to a late software project just makes it later”
27The Tar Pit
Figura: La Brea Tar Pits dipinta da Charles R. Knight.
● La “tar pit” è una palude/lago di bitume. Brooks usa la seguente metafora:
“Software like a tar pit: The more you fight it, the deeper you sink!”
28Perché un progetto fallisce?
● La domanda fondamentale che si pone Brooks è la seguente:
“Why does software fail?”
● I motivi possono essere ricercati, per esempio, nei seguenti fattori:
o Mancato rispetto degli obiettivi (integrità concettuale violata);
o Difficoltà nella stima corretta dei tempi (e.g., troppo spesso lo
sviluppatore sottostima volutamente il tempo per compiacere il
management);
o Troppo ottimismo (i.e., lo sviluppatore non pensa mai che le cose
potrebbero andare male);
o La convinzione che l’impegno da solo assicuri l’avanzamento del
progetto (Effort ≠Progress);
o Mancato monitoraggio dello stato di avanzamento rispetto a quanto
preventivato;
o Ritardi dovuti all’aggiunta di nuovo personale al progetto.
29Il Processo Creativo
● Dorothy Sayers nel suo libro “The Mind of the Maker” suddivide il
processo creativo in tre fasi: l’idea, l’implementazione e l’interazione.
● Brooks fornisce un’efficace sintesi di questa decomposizione del
processo creativo:
“A book, then, or a computer, or a program comes into existence first
as an ideal construct, built outside time and space, but complete in the
mind of the authors. It is realized in time and space, by pen, ink, and
paper, or by wire, silicon, and ferrite.
The creation is complete when someone reads the book, uses the
computer, or runs the program, thereby interacting with the mind of
the maker.”
● Brooks sottolinea una triste realtà: gli sviluppatori sono ottimisti!
Pensano che tutto debba andare sempre bene. Purtroppo, eventuali
errori e inconsistenze presenti nell’idea iniziale emergono solo durante
l’implementazione e l’interazione degli utenti con la soluzione.
30The Mythical Man-Month
● Tutti i task hanno una probabilità non nulla di fallire o subire ritardi.
● La probabilità che tutto vada bene è prossima allo zero!
● I costi dipendono strettamente dalle risorse impiegate (compreso il
tempo/uomo del personale coinvolto nel progetto), ma la velocità di
avanzamento di un progetto non dipende strettamente dalla quantità
di risorse allocate.
● Il semplice uso del “man month” (mese-uomo) come misura delle
risorse disponibili è sbagliato e pericoloso.
● La Legge di Masson dice che “esiste un tempo minimo di sviluppo che
non può essere ridotto ulteriormente, anche aumentando le risorse
disponibili”.
Esempio: Un progetto che richiede 100 mesi/uomo non dura 1 mese
se si impiegano 100 sviluppatori.
31The Mythical Man-Month
Esempio:
Consideriamo l’esempio di un pit-stop per il cambio gomme in un gran
premio di Formula 1.
32The Mythical Man-Month
Valutiamo le seguenti ipotesi, assumendo che siano sempre disponibili due
meccanici che si occupano esclusivamente del sollevamento dell’auto:
● Se il team impiegasse un solo meccanico per il cambio delle 4 gomme
impiegherebbe un tempo T.
● Se i meccanici impiegati per il cambio gomme fossero 2 si potrebbe
sperare di dimezzare il tempo T.
● Se i meccanici fossero 3, quanto tempo impiegherebbero?
● Se invece fossero 4?
● Se fossero 8?
● Se fossero 50?
● Come si può notare la funzione non è affatto lineare!
33The Mythical Man-Month
● Si noti che ogni meccanico ha assegnato un ruolo ben preciso.
34The Mythical Man-Month
25
20
Tempo (mesi)
15
10
5
0
1 2 3 4 5 6 7 8 9 10
N. Sviluppatori
Figura: Tempo vs Numero di Lavoratori, nel caso di task
perfettamente partizionabili.
35The Mythical Man-Month
25
20
Tempo (mesi)
15
10
5
0
1 2 3 4 5 6 7 8 9 10
N. Sviluppatori
Figura: Tempo vs Numero di Lavoratori, nel caso di task
non partizionabili.
36The Mythical Man-Month
25
20
Tempo (mesi)
15
10
5
0
1 2 3 4 5 6 7 8 9 10
N. Sviluppatori
Figura: Tempo vs Numero di Lavoratori, nel caso di task con
complesse interrelazioni.
37The Mythical Man-Month
● I costi per il test di ciò che è stato implementato sono sempre sottostimati.
● Brooks suggerisce che il tempo complessivo di sviluppo è mediamente così
partizionato:
1/3 progettazione e pianificazione;
1/6 implementazione (scrittura del codice);
1/4 test dei componenti (early system test);
1/4 test del sistema quando i componenti sono integrati.
● Svolgere i test significa anche scrivere del codice esclusivamente per
questo scopo. Il costo per scrivere la parte di codice per testare una
funzionalità può superare il costo per produrre il codice necessario per
implementare la funzionalità stessa.
38The Mythical Man-Month
“Question: How does a large software project get to be one year late?
Answer: One day at a time!”
● Spesso le stime dei tempi sono sbagliate per mancanza di coraggio
(gutless estimating) da parte degli sviluppatori, che non riescono a
contrastare le richieste del management che impone tempi di
realizzazione più stretti e irrealistici.
● I ritardi che si riscontrano nella fase finale dei test sono più difficili da
recuperare, perché tendono a deprimere e mandare nel panico gli
sviluppatori.
● Sviluppatori depressi, nel panico e sotto pressione sono sicuramente
meno produttivi sia in termini di qualità che di quantità.
● Come ci si comporta quando viene riscontrato un ritardo? Come si
modifica il progetto?
39Il Team
● Per la riuscita di progetto uno degli elementi fondamentali è il Team.
● La corretta composizione del Team è un prerequisito fondamentale per
una corretta ed efficiente gestione del Team stesso.
● La composizione e organizzazione del team è fortemente influenzata
dall’ambito del progetto e dalle metodologie che si intende utilizzare.
● Prenderemo in considerazione un team molto “agile”, dove sono definite
poche figure e in cui tutti devono saper fare tutto.
40The Scrum Team
● Un approccio alla gestione dei progetti sempre più utilizzato negli ultimi
anni è la metodologia Scrum.
● Il termine Scrum, che nel rugby indica la mischia, descrive un approccio
in cui le persone (i.e., il team) sono concentrate sullo stesso obiettivo: il
successo del progetto.
Fonte: www.guidagalatticaperagilisti.com
41The Scrum Team
● Scrum è un “framework” di project management proposto negli anni
novanta da Ken Schwaber e Jeff Sutherland per lo sviluppo iterativo e
incrementale di prodotti software.
● Nel rugby lo sprint è quel tratto di corsa che si fa per portare avanti il
pallone. In Scrum, “il portatore di palla corre in avanti seguito dai suoi
compagni che lo sostengono: spirito di gruppo, comunicazione, empatia
sono tutte caratteristiche importanti”.
● Quindi in Scrum il lavoro viene suddiviso in iterazioni (gli sprint), che
hanno una durata ben precisa e predeterminata.
● La metodologia Scrum prevedere solo tre ruoli per il personale che
costituisce lo Scrum Team:
o Product Owner;
o Scrum Master;
o Team di sviluppo (Dev Team).
42The Scrum Team
● Product Owner: ha la responsabilità del prodotto, conosce l’utente e i
suoi bisogni. Il Product Owner (PO) è responsabile del “cosa” sarà
contenuto all’interno del prodotto, ma non del “come” questo verrà
realizzato, che è di competenza del team di sviluppo.
● Scrum Master: il suo ruolo non è quello del “capo” del team, come il
termine “master” potrebbe far pensare, ma è un coach al servizio del
team, che aiuta la sua crescita, agevola la comunicazione, fa in modo
che si rispettino le indicazioni, etc...
● Team di Sviluppo: è composto da persone che dovrebbero avere tutte
le competenze per sviluppare la soluzione (i.e., le user story inserite nel
loro backlog). Per questo motivo dovrebbero sempre avere la massima
autonomia sulle scelte tecniche, in particolare sul come implementare
le funzionalità.
43Dimensioni ideali di un Team
● Il tema del dimensionamento del team di sviluppo è molto dibattuto,
ma c’è accordo su un punto: team troppo numerosi sono di difficile
gestione, perché richiedono un alto overhead per le comunicazioni.
● Jeff Bezos’ Two-Pizza Team Rule: secondo Bezos un team deve avere
un numero di componenti che possono essere sfamati da due pizze.
● Quante persone si possono accontentare di due pizze?
● L’idea di Bezos è ormai condivisa da una vasta platea di professionisti
che quantifica le dimensioni ideali in circa 4-8 sviluppatori.
● Quindi, indipendentemente dalle dimensioni dell’azienda e dal numero
di sviluppatori coinvolti in un progetto, i team non devono superare un
certo numero di componenti.
● Sulla composizione c’è la possibilità di puntare a team generalisti (e.g.,
full-stack) o specialisti (che coprono uno specifico dominio) o un mix.
44Conceptual Integrity
● Il rispetto della conceptual integrity è molto importante, ma al tempo
stesso è difficile definire in cosa consiste.
● Per produrre un sistema efficace, efficiente e user-friendly è necessario
che sia rispettata la sua integrità concettuale, ossia è necessario che le
funzionalità e la loro implementazione risponda solo e solamente ai
requisiti definiti in fase di progettazione.
● Il sistema deve permettere di fare tutto ciò per il quale è stato progettato
(efficacia) e lo deve fare nel modo migliore (efficienza).
● Nessuna funzionalità non prevista nel progetto deve essere implementata
e nell’implementazione ogni funzionalità deve prevedere solo ciò che è
necessario.
● Il motivo è piuttosto semplice: se un sistema è troppo complicato da
usare, allora molte delle sue funzionalità non saranno usate perché
nessun utente ha il tempo e la pazienza di impararle a usare.
45Conceptual Integrity
● Per mantenere l’integrità concettuale del sistema è necessario separare
l’architettura dall’implementazione.
● Uno o più architetti decidono cosa deve essere presente nel sistema e
cosa invece no. Gli architetti devono tenere in considerazione le esigenze
dell’utente finale.
● L’architetto o il team di architetti devono definire cosa il sistema dovrà
essere, dopodiché devono assicurarsi che la loro visione sia condivisa dal
resto del team.
● Se gli architetti definiscono cosa il sistema dovrà essere, il come dovrà
essere implementato lo dovrà definire il team che si prenderà carico
dell’implementazione del sistema.
● Delegare al team l’implementazione, permette una gestione più efficiente
evitando di sovraccaricare di lavoro l’architetto che può diventare un
“collo di bottiglia”.
46Conceptual Integrity
● Agli sviluppatori deve essere lasciata la “gioia” di dare libero sfogo alla
propria creatività, a patto che sia rispettata l’integrità concettuale di
quanto progettato dagli architetti. Books riassume questo concetto così:
“Architecture is what happens, and implementation is how it happens”.
● In questo contesto Brooks parla di aristocracy e democracy.
● I pericoli per gli architetti:
o Le specifiche degli architetti potrebbero essere troppo “ricche” e non
considerare in modo adeguato i costi di implementazione.
o Gli architetti si prendono tutto il divertimento lasciando pochi margini
alla creatività degli sviluppatori. Se gli architetti rispettano i confini tra
“what” e “how” l’implementazione può essere divertente.
o Gli sviluppatori devono essere coinvolti quando le specifiche sono
pronte o addirittura quando vengono definite.
47La Comunicazione
Come si comunica?
● Informally: telefono, pausa caffè, instant message, pub, etc...
● Meetings: riunioni sia a cadenza regolare che al bisogno, dove i team
informano gli “altri” (propri colleghi, altri team, manager, etc.) sullo
stato di avanzamento, su eventuali criticità riscontrate, su proposte
progettuali o implementative, etc.
● Workbook: contenitore in cui sono riportate formalmente tutte le
informazioni riguardanti un progetto. Anni fa erano dei documenti
stampati su carta, oggi sono sempre più spesso fruibili via web
utilizzando intranet aziendali, soluzioni cloud, etc.
48La Documentazione
● Documentare il proprio lavoro è fondamentale per:
o indicare il funzionamento di un programma, un componente, etc.;
o ricordarsi a distanza di tempo cosa si è fatto;
o condividere il proprio lavoro con i colleghi;
o definire formalmente le interfacce tra componenti, etc.;
o tenere traccia dei problemi e delle soluzioni (e.g., bugs, etc.);
o stabilire i test case, definire il loro utilizzo, etc.;
o etc...
“Most documentation fails in giving too little overview.
The trees are described, the bark and leaves are commented,
but there is no map of the forest.”
49La Documentazione
50Self-Documenting Programs
● Martin Fowler sostiene che il codice stesso può essere considerato la
documentazione principale di un sistema software, ma ci ricorda anche
che non deve essere l’unica documentazione disponibile.
● In effetti un modo molto efficace ed efficiente per documentare il codice
è inserire la documentazione nel codice stesso.
● Per documentare il codice si possono usare i commenti, i nomi delle
variabili, l’indentazione, etc.
● Un vantaggio evidente consiste nel fatto che la documentazione è
“immediatamente” disponibile ed è aggiornata e allineata con il codice
(a patto che lo sviluppatore faccia il proprio dovere aggiornando con
costanza i commenti, etc.).
● Usando delle particolari regole sintattiche nella scrittura dei commenti è
possibile consentire anche la produzione automatica di documentazione,
utilizzando dei software ad hoc (e.g., Doc++, Doxygen, etc.).
51Self-Documenting Programs Esempio … float O[ND,NG]; float P[ND]; float S[ND]; F1(ND,NG,O); F2(ND,P) for (i=0; i
Self-Documenting Programs Esempio … float OreLavorate[NumeroDipendenti,NumeroGiorni]; float PagaOraria[NumeroDipendenti]; float Stipendio[NumeroDipendenti]; LeggiOreLavorate(NumeroDipendenti,NumeroGiorni,OreLavorate); LeggiPagaOraria(NumeroDipendenti,PagaOraria) for (i=0; i
Self-Documenting Programs
Esempio: Doxygen
/*! A test class */
class Test
{
public:
/** An enum type.
* The documentation block cannot be put after the enum!
*/
enum EnumType
{
int EVal1, /**< enum value 1 */
int EVal2 /**< enum value 2 */
};
void member(); //!< a member function.
protected:
int value; /*!< an integer value */
};
54Self-Documenting Programs
Esempio: Doxygen
55Self-Documenting Programs
Esempio: Doxygen
56Documentare un progetto
● Molti progetti di sviluppo software iniziano con numerose riunioni per
definire la struttura, poi si inizia subito a scrivere il codice.
● Anche per progetti di piccole dimensioni sarebbe però opportuno
produrre della documentazione.
● Per gestire un progetto software è necessario quanto meno produrre la
seguente documentazione:
o What: objective. Questo documento definisce i bisogni che devono
essere soddisfatti, gli obiettivi, i desiderata, i vincoli e le priorità.
o What: product specifications. La prima versione può essere una
proposta sintetica, ma deve “evolvere” in un documento completo
costituito dal manuale (ciò che vede l’utente) e una descrizione
dettagliata dell’implementazione (a uso interno).
57Documentare un progetto
o When: schedule. Descrizione completa dell’organizzazione del
progetto (i.e., GANTT, etc.). Può essere espressa usando degli
strumenti software specifici (e.g., Microsoft Project, etc.).
o How much: budget. Questa documentazione è tra le più importanti
per la gestione dei progetti. Il budget può influenzare anche le scelte
tecniche.
o Where: space allocation. Solitamente nella produzione del software
non è un tema fondamentale, però non deve essere sottovalutato e
deve essere considerato.
o Who: organization chart. Documentare l’organizzazione delle risorse
umane coinvolte nel progetto è fondamentale sia per attribuire i
compiti e le responsabilità sia per stabilire la rete delle comunicazioni
(e quindi la rete delle responsabilità).
58Perché abbiamo bisogno della documentazione?
1. Mettere per iscritto le decisioni è fondamentale.
● Solo quando si scrive ci si accorge di eventuali inconsistenze e del gap tra
l’idea e l’implementazione.
● Nello scrivere è necessario prendere numerose “mini-decisioni”, che nella
fase di ideazione non era stato necessario prendere.
2. La documentazione serve per comunicare le decisioni agli altri.
● Se qualche aspetto del progetto non è riportato nella documentazione non
ci si può sorprendere se qualche membro del team lo ignora.
● Se il progetto non è ben documentato è facile che l’integrità concettuale sia
violata e che il prodotto finale non rispetti alcuni requisiti.
● Il compito fondamentale per il management è riuscire a far andare tutti nella
stessa direzione. Quindi il suo compito fondamentale non è solo prendere
decisioni, ma anche comunicare e la documentazione aiuta.
59Perché abbiamo bisogno della documentazione?
3. La documentazione è un database e una checklist fondamentale per il
progetto.
● La documentazione deve essere continuamente aggiornata e registrare
l’evoluzione del progetto.
● Nell’aggiornare la documentazione il management e gli sviluppatori
capiscono dove sono e quali cambiamenti di rotta sono stati eventualmente
apportati.
60La rivoluzione Agile
● Ciò che abbiamo detto finora è in linea con un approccio tradizionale al
project management.
● Negli ultimi anni nell’ambito dello sviluppo software si stanno imponendo
numerosi approcci che sembrano “violare” molti dei principi del project
management tradizionale.
● Uno dei movimenti di maggior successo è quello Agile.
● Le idee ispiratrici del movimento Agile sono riassunte nel noto Manifesto
for Agile Software Development (agilemanifesto.org).
● Il Manifesto è stato redatto nel febbraio del 2001, quando 17 sviluppatori
software si incontrarono allo Snowbird Resort nello Utah per discutere di
metodi di sviluppo “leggeri”.
● A quanto pare non avevano le stesse idee, ma trovarono un accordo su
quattro punti.
61Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
62Twelve Principles of Agile Software
Un’importante precisazione (agilemanifesto.org):
● The Agile movement is not anti-methodology, in fact, many of us want to
restore credibility to the word methodology.
● We want to restore a balance. We embrace modeling, but not in order to
file some diagram in a dusty corporate repository.
● We embrace documentation, but not hundreds of pages of never-
maintained and rarely-used tomes.
● We plan, but recognize the limits of planning in a turbulent environment.
63Conclusioni
Non è importante il Luogo,
… ma il Progetto e la sua
corretta” Gestione!
64Marco A. Boschetti
C.d.S. Ingegneria e Scienze Informatiche
marco.boschetti@unibo.it
https://www.unibo.it/sitoweb/marco.boschetti
http://isi-personale.csr.unibo.it/marco.boschettiPuoi anche leggere
