Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo

 
CONTINUA A LEGGERE
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
Seminario

Project Management e
il Mito del Garage
Marco A. Boschetti
Università di Bologna
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
Il Mito del Garage

             https://www.businessinsider.com
                                               2
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
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
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
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
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
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
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
Il Mito del Garage: Apple Computers

                                      6
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
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
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
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
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
Il Mito del Garage: Facebook

                               9
Seminario Project Management e il Mito del Garage - Marco A. Boschetti Università di Bologna - Unibo
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
                                                                                   10
Il 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).

                                                                                11
Il 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

                                                                                   12
Project 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?
                                                                               13
Project 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.

                                                                               14
Cosa 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.

                                                                              15
Alcuni 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

                                                                              16
Project Management Life Cycle Models

Linear Project Management Life Cycle Model

                                             17
Project Management Life Cycle Models

Incremental Project Management Life Cycle Model

                                                  18
Project Management Life Cycle Models

Iterative Project Management Life Cycle Model

                                                19
Project Management Life Cycle Models

Adaptive Project Management Life Cycle Model

                                               20
Project Management Life Cycle Models

Extreme Project Management Life Cycle Model

                                              21
Ciclo di Vita di un Progetto

                               22
Ciclo di Vita di un Progetto

                               23
Ciclo di Vita di un Progetto

                               24
Qualità

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.

                                                                                25
Scope Triangle

  Scope e Qualità

 Risorse Disponibili

                       26
Il 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”

                                                                               27
The 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!”

                                                                               28
Perché 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.
                                                                          29
Il 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.
                                                                              30
The 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.

                                                                              31
The Mythical Man-Month

Esempio:
Consideriamo l’esempio di un pit-stop per il cambio gomme in un gran
premio di Formula 1.

                                                                       32
The 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!

                                                                            33
The Mythical Man-Month

● Si noti che ogni meccanico ha assegnato un ruolo ben preciso.

                                                                  34
The 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.

                                                                        35
The 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.

                                                                        36
The 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.

                                                                        37
The 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.

                                                                              38
The 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?
                                                                                  39
Il 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.

                                                                            40
The 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
                                                                                  41
The 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).

                                                                               42
The 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à.

                                                                                43
Dimensioni 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.

                                                                               44
Conceptual 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.
                                                                                 45
Conceptual 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”.
                                                                               46
Conceptual 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.

                                                                                      47
La 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.

                                                                             48
La 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.”

                                                                        49
La Documentazione

                    50
Self-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.).
                                                                               51
Self-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 */
};

                                                                54
Self-Documenting Programs

Esempio: Doxygen

                                           55
Self-Documenting Programs

Esempio: Doxygen

                                           56
Documentare 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).

                                                                                 57
Documentare 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à).

                                                                              58
Perché 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.

                                                                                     59
Perché 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.

                                                                                   60
La 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.

                                                                               61
Manifesto 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.
                                                           62
Twelve 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.

                                                                              63
Conclusioni

Non è importante il Luogo,
 … ma il Progetto e la sua
    corretta” Gestione!

                             64
Marco 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.boschetti
Puoi anche leggere