Appunti gestione per verifica del 23-03-2023

Metodologia Agile
Che cosa è Agile?
Agile è una metodologia di Project Management che usa cicli di sviluppo
brevi chiamati sprint per mantenere l’attenzione sul miglioramento
continuo nello sviluppo di un prodotto, servizio o altro risultato.

Da quanto tempo si parla di Agile?

Agile fu trattato a fondo per la prima volta negli anni 1970 da William
Royce, che pubblicò uno scritto sullo sviluppo dei grandi sistemi
software.
Più tardi, per la precisione nel 2001, fu pubblicato il Manifesto Agile,
definito come una “dichiarazione formale dei quattro valori chiave e dei
dodici principi per un approccio allo sviluppo del software iterativo e
incentrato sulle persone”. Quelli che seguono sono i dodici principi
chiave che ancora oggi guidano l’Agile Project Management:
1. La nostra massima priorità è soddisfare il cliente attraverso il
rilascio anticipato e continuo di software di valore.
2. I cambiamenti dei requisiti sono bene accetti, anche a stadi
avanzati dello sviluppo.
3. Consegnare un software funzionante a cadenze ravvicinate, con
una preferenza per l’intervallo più breve.
4. Le persone del business e gli sviluppatori devono lavorare insieme
quotidianamente per tutta la durata del progetto.
5. Costruire progetti intorno a persone motivate, offrire loro
l’ambiente ed il supporto di cui hanno bisogno e fidarsi della loro
capacità di portare a compimento il lavoro.
6. Il metodo più efficiente ed efficace di veicolare le informazioni verso e
all’interno di un team di sviluppo è la conversazione faccia a faccia.
7. Il software funzionante è la principale misura dell’avanzamento
del lavoro.
8. I processi Agile promuovono lo sviluppo sostenibile, gli sponsor, gli
sviluppatori e gli utenti dovrebbero essere in grado di mantenere un
ritmo costante a tempo indeterminato.
9. L’attenzione continua verso l’eccellenza tecnica e la buona
progettazione aumenta l’agilità.
10. La semplicità è essenziale.
11. Le architetture, i requisiti e le progettazioni migliori vengono fuori dai
team auto-organizzati.
12. Ad intervalli regolari, il team riflette su come diventare più efficace
e poi regola e modifica il suo comportamento di conseguenza.

Chi usa la metodologia Agile?

Sebbene originariamente fosse destinata all’industria del software,
molti altri tipi di industria hanno oggi adottato l’uso di Agile per lo
sviluppo dei loro prodotti e servizi, in virtù della elevata collaboratività e
della maggiore efficienza proprie di questa metodologia. Agile è quindi
utilizzato anche in industrie che si occupano di marketing e pubblicità,
costruzioni, formazione e finanza.

Perché è necessario utilizzare i metodi Agile?

Come alternativa al tradizionale approccio a cascata (Waterfall), Agile ha
fornito in definitiva agli sviluppatori e ai team un modo di consegnare un
prodotto migliore più velocemente, attraverso sessioni/sprint brevi,
iterativi ed interattivi.

Come viene utilizzato Agile?

Le tradizionali metodologie più pesanti come quella a cascata richiedono
che tutti i gruppi di progetto si incontrino e discutano di tutti gli obiettivi
del progetto in ogni sua fase. La metodologia Agile utilizza invece gruppi
più ristretti e maggiormente focalizzati, che si riuniscono più spesso per
discutere però di obiettivi molto specifici, rendendo così più facile
apportare cambiamenti veloci, quando necessario. Questo consente ai
team di essere più ‘agili’, più efficaci ed aumenta le possibilità di
soddisfare con successo gli obiettivi del cliente, tanto più perché anche
le esigenze di un cliente potrebbero cambiare. Agile munisce i team di
un meccanismo che permette di ripetere rapidamente un processo, di
isolare i problemi e realizzare velocemente obiettivi specifici, anziché
attendere la fine di una lunga fase di progetto per scoprire di avere
trascurato requisiti e obiettivi del cliente.
Quali sono i vantaggi di Agile?
• Un più rapido sviluppo delle soluzioni
• Riduzione degli sprechi
• Maggiore flessibilità e adattabilità al cambiamento
• Maggiore successo grazie a sforzi più mirati
• Tempi di consegna più rapidi
• Rilevamento più rapido di questioni e difetti
• Un processo di sviluppo ottimizzato
• Un framework più snello e leggero
• Controllo di progetto ottimale
• Un aumento della concentrazione sui bisogni specifici del cliente
• Collaborazione e feedback più frequenti e costanti

Quali sono gli svantaggi di Agile?

Come del resto ogni altro tipo di metodologia, anche Agile non è
pienamente adatto a tutti i progetti.
In particolare, è utile tenere presente che:
• Agile supporta gli sviluppatori, i team di progetto e gli obiettivi del
cliente durante tutto il processo di sviluppo, ma non necessariamente fa
altrettanto per l’utente finale;
• A causa dei suoi processi meno formali e più flessibili, la metodologia
Agile potrebbe non essere facilmente assimilata dalle organizzazioni di
grandi o grandissime dimensioni con una struttura più tradizionale.

Scrum
Cos’è Scrum?
Scrum è un framework di gestione dei progetti Agile che aiuta i team a
strutturare e gestire il proprio lavoro attraverso un insieme di valori,
principi e pratiche. Proprio come una squadra di gioco del rugby (sport a
cui deve il nome).
Sebbene il framework Scrum sia utilizzato più frequentemente dai team
di sviluppo software, i suoi principi e insegnamenti possono essere
applicati a tutti i tipi di lavoro in team. Questo è uno dei motivi per cui è
così diffuso. Spesso considerato come un framework di gestione dei
progetti Agile, Scrum descrive in realtà una serie di riunioni, strumenti e
ruoli che lavorano insieme per aiutare i team a strutturare e gestire il loro
lavoro.

Agile e Scrum a confronto

Spesso si pensa che Scrum e Agile siano la stessa cosa, tuttavia, Scrum
è in realtà un framework che consente di eseguire il lavoro, mentre Agile
è una mentalità.
"Diventare Agile" non è in realtà semplice, tuttavia puoi utilizzare un
framework come Scrum per iniziare ad adottare questo tipo di approccio
mentale e a mettere in pratica la creazione di principi Agile nella
comunicazione e nel lavoro quotidiano.
Scrum è un framework si basa sull'apprendimento continuo da parte
degli sviluppatori e sull'adattamento a fattori variabili.
Tiene conto del fatto che il team non dispone di tutte le conoscenze
all'inizio di un progetto e che si evolverà man mano che acquisisce
esperienza. Scrum è strutturato per aiutare i team ad adattarsi in modo
naturale alle mutevoli condizioni ed esigenze degli utenti, con una
ridefinizione delle priorità integrata nel processo e cicli di rilascio brevi
che consentono al team di imparare e migliorare costantemente.

Il Team Scrum
Un team Scrum è una squadra snella e agile che si occupa di fornire
incrementi di prodotto mirati. Le dimensioni del team Scrum sono in
genere ridotte, circa da 3 a 9 persone.
Un team Scrum ha bisogno di tre ruoli specifici: owner di prodotto,
Scrum Master e team di sviluppo. Inoltre, poiché i team Scrum sono
interfunzionali, il team di sviluppo include non solo sviluppatori ma anche
tester, progettisti, esperti in interfaccia utente e tecnici operativi.

L'owner di prodotto Scrum

Il Product Owner, abbreviato in PO, è colui che ha la responsabilità del
prodotto. Conosce l’utente e i suoi bisogni. È responsabile del cosa sarà
contenuto all’interno del prodotto, ma non del come questo verrà
realizzato, che è di competenza del team di sviluppo.
Gli owner di prodotto efficaci:

-Creano e gestiscono il backlog di prodotto.

-Collaborano a stretto contatto con l'azienda e il team per garantire che
tutti comprendano gli elementi del lavoro nel backlog di prodotto.
-Forniscono al team indicazioni chiare su quali funzionalità fornire in
futuro.
-Decidono quando rilasciare il prodotto, con una predisposizione verso
una distribuzione più frequente.

L'owner di prodotto non sempre coincide con il responsabile di prodotto.

Gli owner di prodotto hanno principalmente il compito di garantire che il
team di sviluppo offra il massimo valore all'azienda. Inoltre, è importante
che l'owner di prodotto sia una sola persona. A nessun team di sviluppo
piace avere indicazioni contrastanti da parte di più owner di prodotto.

Lo Scrum Master
Gli Scrum Master sono i promotori delle attività Scrum nell'ambito dei
propri team. Affiancano i team, gli owner di prodotto e l'azienda sul
processo Scrum e si adoperano per perfezionarne le prassi.
Uno Scrum Master efficace ha una comprensione profonda del lavoro
svolto dal team e può aiutarlo a ottimizzare la trasparenza e il flusso di
consegna. In qualità di capo facilitatore, pianifica le risorse necessarie
(sia umane che logistiche) per la pianificazione dello sprint, la riunione
stand-up, la revisione dello sprint e la retrospettiva dello sprint.

Il team di sviluppo Scrum

I team Scrum sono sempre operativi. Sono i promotori delle pratiche di
sviluppo sostenibile. I team Scrum più efficaci sono affiatati, ubicati nello
stesso luogo e in genere includono da tre a nove membri. Per stabilire le
dimensioni ottimali del team un metodo utile è quello della famosa
"regola delle due pizze" coniata da Jeff Bezos, CEO di Amazon,
secondo la quale per sfamare un qualsiasi team in azienda non
dovrebbero essere necessarie più di due pizze.
I membri del team hanno competenze diverse, ma condividono le
proprie conoscenze. I team Scrum solidi si organizzano in modo
autonomo e affrontano i progetti con un evidente spirito collaborativo.
Tutti i membri del team si aiutano a vicenda per garantire il
completamento efficace dello sprint.
Il team Scrum guida il piano per ogni sprint. Prevede la quantità di lavoro
che ritiene di poter completare nel corso dell'iterazione utilizzando come
linea guida la propria velocity storica. Mantenere una durata fissa
dell'iterazione offre al team di sviluppo un feedback importante sul
processo di stima e consegna, il che a sua volta rende le previsioni
sempre più accurate nel corso del tempo.

Artefatti Scrum
Gli artefatti Scrum sono informazioni importanti utilizzate dal team Scrum
che aiutano a definire il prodotto e il lavoro da svolgere per crearlo. I tre
artefatti Scrum sono il backlog di prodotto, il backlog dello sprint e
l'incremento rispetto alla definizione di "completato", e
rappresentano i concetti cardine sui quali un team Scrum dovrebbe
riflettere durante gli sprint e nel tempo.

-Il backlog di prodotto è l'elenco principale dei lavori che devono

essere eseguiti ed è mantenuto dall'owner di prodotto o dal responsabile
di prodotto e funge da input per il backlog dello sprint.
Il backlog di prodotto è costantemente rivisto, modificato in termini di
priorità.
-Il backlog dello sprint è l'elenco di elementi, storie utente o correzioni
di bug selezionati dal team di sviluppo per l'implementazione nel ciclo di
sprint corrente. Prima di ogni sprint, nella riunione di pianificazione dello
sprint il team sceglie dal backlog di prodotto gli elementi su cui lavorerà
per lo sprint. Un backlog dello sprint può essere flessibile ed evolversi
durante uno sprint. Tuttavia, l'obiettivo fondamentale dello sprint, cioè
quello che il team desidera ottenere dallo sprint corrente, non può
cambiare.
-L'incremento (o obiettivo dello sprint) è il prodotto finale utilizzabile di
uno sprint.
 Cerimonie o eventi Scrum
Il framework Scrum include le prassi, le cerimonie o le riunioni che i
team Scrum eseguono regolarmente. Le cerimonie Agile rappresentano
gli eventi in cui le divergenze di opinioni dei team si manifestano in
misura maggiore.

Di seguito è riportato un elenco di tutte le cerimonie chiave a cui un team

Scrum potrebbe partecipare:

-Organizzazione del backlog: a volte noto come backlog grooming,

questo evento rientra nell'ambito delle responsabilità dell'owner di
prodotto, il cui compito principale è di favorire l'attuazione della vision del
prodotto e avere un quadro costante del mercato e del cliente. Pertanto,
l'owner di prodotto gestisce questo elenco utilizzando il feedback degli
utenti e del team di sviluppo per definire le priorità e mantenere l'elenco
pulito e pronto per essere utilizzato in qualsiasi momento.

-Pianificazione dello sprint: il lavoro da svolgere durante lo sprint

corrente è pianificato nel corso di questa riunione dall'intero team di
sviluppo. Questo incontro è guidato dallo Scrum Master ed è il momento
in cui il team decide l'obiettivo dello sprint. Le storie utente specifiche
vengono quindi aggiunte allo sprint dal backlog di prodotto. Queste
storie sono sempre in linea con l'obiettivo e sono anche concordate dal
team Scrum per essere fattibili da implementare durante lo sprint.
Al termine della riunione di pianificazione, ogni membro del team Scrum
deve sapere con chiarezza cosa può essere rilasciato nello sprint e
come l'incremento può essere rilasciato.

-Sprint: uno sprint è il periodo di tempo effettivo in cui il team Scrum

collabora per completare un incremento. In genere lo sprint ha una
durata di due settimane, anche se alcuni team ritengono che una
settimana sia sufficiente per definire l'ambito, mentre un mese è
considerato un periodo adeguato per consegnare un incremento
importante.
Durante questo periodo, l'ambito può essere nuovamente negoziato tra
l'owner di prodotto e il team di sviluppo, se necessario.

Tutti gli eventi, dalla pianificazione alla retrospettiva, avvengono durante

lo sprint. Una volta stabilito un certo intervallo di tempo per uno sprint,
questo deve rimanere coerente per tutto il periodo di sviluppo. Ciò
consente al team di imparare dalle esperienze passate e di applicare gli
insegnamenti acquisiti agli sprint futuri.

-Scrum giornaliero o riunione stand-up giornaliera: si tratta di una

riunione quotidiana estremamente breve che, per praticità, avviene
sempre alla stessa ora (di solito al mattino) e nello stesso luogo. Molti
team cercano di completare l'incontro in 15 minuti, ma questa tempistica
è solo indicativa. Questa riunione è anche definita "riunione stand-up
quotidiana" per sottolineare il fatto che deve essere rapida. L'obiettivo
dello Scrum quotidiano è di assicurarsi che tutti i membri del team siano
allineati all'obiettivo dello sprint e di definire un piano per le prossime 24
ore.
La riunione stand-up rappresenta il momento in cui vengono espresse
tutte le preoccupazioni riguardo al raggiungimento dell'obiettivo dello
sprint o a eventuali bloccanti.

Un modo comune per condurre una riunione stand-up è di chiedere a

ogni membro del team di rispondere a tre domande riguardanti il
raggiungimento dell'obiettivo sprint:
• Cosa ho fatto ieri?
• Cosa ho intenzione di fare oggi?
• Ci sono ostacoli?

Tuttavia, spesso la riunione si trasforma in una lettura rapida del

calendario del giorno precedente e di quello successivo da parte dei
membri del team. La riunione stand-up poggia su una teoria: limitare il
più possibile le chiacchiere e far sì che il team possa concentrarsi sul
lavoro per il resto della giornata. Pertanto, se diventa una lettura
giornaliera del calendario, non esitare a cambiarla in nuovi modi creativi.
-Revisione dello sprint: alla fine dello sprint, il team si riunisce per una
sessione informale allo scopo di visualizzare una demo o ispezionare
l'incremento. Il team di sviluppo mostra gli elementi del backlog con lo
stato "Completato" agli stakeholder o ai membri del team con lo scopo di
ricevere un feedback. L'owner di prodotto può decidere se rilasciare o
meno l'incremento, anche se nella maggior parte dei casi l'incremento
viene rilasciato.
La riunione di revisione avviene anche quando l'owner di prodotto
modifica il backlog di prodotto in base allo sprint corrente, che può
essere incluso nella prossima sessione di pianificazione dello sprint. Per
uno sprint di un mese, il timebox per la revisione dello sprint dovrebbe
essere di massimo quattro ore.

-Retrospettiva dello sprint: la retrospettiva è il momento in cui team si

riunisce per documentare e discutere cosa ha funzionato e cosa non ha
funzionato in uno sprint, in un progetto, tra le persone o nell'ambito di
relazioni, strumenti o anche per determinate cerimonie. L'idea è quella di
creare una situazione in cui il team possa concentrarsi sugli aspetti
positivi e sulle aree di miglioramento per il futuro, mettendo in secondo
piano ciò che non è andato per il verso giusto.

Software Engineering
1. Define Software Engineering
Software engineering is the process of designing, developing, testing,
and maintaining software. It is a systematic and disciplined approach to
software development that aims to create high-quality, reliable, and
maintainable software.

2. Why and when should we adopt a Software Engineering approach?

Software Engineering is mainly used for large projects based on
software systems rather than single programs or applications. The main
goal of software Engineering is to develop software application for
improving the quality, budget and time efficiency.
 3. What are the main risks of software development that can
lead(portare) to project failure?

The main risks of software development are:

• Lack(mancanza) of feedback from the customer/user
• Turnover of staff and particularly the development team
• Implementation of unsolicited(indesiderate) features
• Delays in delivery
• Exceeding the project budget
• Realizing an unusable system
• Realize a system unable to work together with other existing
systems

4. How can software engineering help produce software with

"acceptable" costs?
Software engineering deals with:
• Methods of analysis and design of software products
• The study of the software development process
• The development of software production tools
• The economics of products and processes (how much does it cost to
produce a certain
• system?)
• The standardization of processes and technologies

5. Give some examples of specializations and skills required in

software production
Some examples of skills required in software production and
development are:
• Knowledge of analysis methods to produce Software requirements
• Software design skills in its architectural components
• Software construction, or the writing of code
• Planning, use cases definition and execution of Software testing

6. What are the types of software maintenance?

The main types of maintenance:
• Perfective or preventive (65%): improving the product
 • Adaptive (18%): responding to environmental changes (for instance,
regulatory
• changes on business rules)
• Corrective (17%): correct errors found after delivery

7. In a development team, what roles and skills are needed?

In the team there are people with different experiences, who play
different roles and have
different skills:
• How to design the software product (architects)
• How to build the software product (programmers)
• What the software product is for (domain experts)
• How the user interface should be made (interface designers)
• How the quality of the software product should be checked (testers)
• How to use project resources (project managers)
• How to reuse existing software (configuration managers)

8. Define the Software Development Life Cycle

SDLC is a popular practice that is followed by different organizations for
designing and developing high-quality software applications. It acts as a
framework that holds some specific tasks to be achieved at every phase
during the software development progression.
• Planning (or Requirements Collection):
The first phase involves gathering requirements from the customer and
preparing a Business Requirement Specification (BRS). The BRS
document outlines the objectives and goals of the project, the target
audience, and the expected outcomes.
• Defining (or Feasibility Study)
In this phase, the feasibility of the project is assessed by analyzing the
cost, resources, and time required. This phase results in the creation of
a Software Requirement Specification (SRS) document that outlines the
detailed requirements of the software.
• Designing
In this phase, a detailed design of the software is created based on the
SRS document. The design includes the architecture of the software, its
hardware requirements, and the system requirements.
 • Building (or Coding):
The building phase involves writing the code for the software based on
the design created in the previous phase.
• Testing:
In this phase, the software is tested to identify and fix any issues or
bugs. Different types of testing are carried out to ensure that the
software is functioning as expected.
• Deployment:
Once the software is tested and approved, it is deployed in the
production environment.
• Maintenance:
The final phase involves maintaining the software to ensure that it
continues to function properly and meets the changing needs of the
users.

Project Management
Fasi di un progetto:
-Concezione: nasce l’idea del progetto (fattibile).
-Definizione: pianificazione delle attività (piano di progetto).
-Realizzazione: progettazione ed effettiva realizzazione degli output.
-Chiusura: messa al regime presso il cliente

Pianificare un progetto:
Durante la pianificazione di un progetto è essenziale il piano di
progetto.
Esso è un documento iniziale che definisce come bisogna spartirsi il
lavoro da svolgere e serve per valutare lo stato di avanzamento di un
progetto; esso deve essere flessibile e facile da aggiornare.
Durante la realizzazione del progetto è necessario, inoltre, che le
persone coinvolte si riuniscano periodicamente insieme in MILESTONE,
dove andranno a domandarsi l’un l’altro:
Dove ci troviamo? (misurazione)
Dove dovremmo essere? (valutazione)
Come dovremmo continuare? (correzione)
Si usano anche dei report sullo Stato di Avanzamento del Lavoro
(SAL), prodotti periodicamente.
I SAL contengono:
• la quantità o la percentuale di prodotto realizzato;
• l'impegno profuso (numero/tipo di risorse);
• il tempo impiegato.

Definire le attività di un progetto:

Work Breakdown Structure (WBS)

La WBS è uno strumento per la scomposizione gerarchica del progetto
orientata ai deliverable.
Il WBS permette di visualizzare attraverso un diagramma, o mediante
elenchi strutturati e descrittivi, tutte le parti di un progetto a diversi
livelli di dettaglio, dai primi sotto-obiettivi fino ai compiti specifici.
La rappresentazione gerarchica definisce sottosistemi sempre più
piccoli fino all'individuazione di pacchetti di attività (work package).
Scopo fondamentale del WBS è di identificare all'ultimo livello
gerarchico, compiti di lavoro (work package) attribuibili alla
responsabilità di un'unica risorsa, pianificati, con un budget stabilito e
controllabili.
I deliverable vengono tendenzialmente rilasciati in corrispondenza delle
milestone e corrispondono ad output misurabili, come ad esempio:
• parti del prodotto o del servizio da consegnare;
• i piani di progetto;
• i report sullo stato di avanzamento (SAL);
• la documentazione di progettazione;
• l'elenco delle criticità gravi;

Il Project Manager e il suo team sviluppano la struttura ad albero della

WBS, la quale presume che ogni elemento sia collegato a uno e uno
solo degli elementi di livello superiore.
Una volta verificata la validità della WBS da parte degli stakeholder, il
team di sviluppo passa all’individuazione degli Work p., tempi, costi e
materiali necessari ad essi.
Come costruire il WBS
-Livello 1: al primo livello c’è sempre il Progetto in se per se.
-Livello 2: ci possono essere i nomi delle diverse fasi, o degli obiettivi o
processi.
-Altri livelli intermedi: numero variabile a seconda della complessità del
progetto.
-Ultimo livello (foglie): corrisponde ai work package, cioè ad insiemi di
attività elementari.

Ogni WP deve avere le seguenti caratteristiche:

• essere distinto da tutti gli altri;
• avere un solo responsabile;
• deve essere programmabile in termini di costi, tempi e risorse
occorrenti;
• la sua durata deve essere limitata ad un periodo di tempo ben definito.

La programmazione e il controllo dei tempi

Il passo successivo alla WBS riguarda il controllo dei tempi, cioè:
• durata di ogni attività;
• vincoli di precedenza fra le attività.
Le tecniche utilizzate per il controllo dei tempi sono:
• Bar chart (diagramma di GANTT)
• Reticolo delle precedenze(CPM, PERT)

GANTT
Il diagramma di Gantt è un diagramma temporale sul piano cartesiano:
sulle ascisse(x) vengono poste le unità di tempo (giorni, settimane,
mesi), sulle ordinate(y) le attività (i WP del WBS);
la durata di una attività viene rappresentata con una barra della
lunghezza temporale necessaria alla sua terminazione; in esso possono
essere evidenziate le milestone.
Gantt comunque non mostra i vincoli di precedenza tra le attività.

Reticolo delle precedenze

Per rappresentare i vincoli di precedenze tra le attività utilizziamo le
tecniche reticolari, esse consentono:
-scheduling delle attività: definire la data di inizio e di
fine per ciascuna attività e, quindi, la durata dell’intero progetto.
• analisi degli slittamenti: individuazione di quanto può slittare un’attività
senza ritardare l'intero progetto.