Agile Project Management

Manifesto Agile (Snowbird, Utah, febbraio 2001)

17 firmatari (Beck, Fowler, Cockburn, Highsmith, Schwaber, Sutherland, Martin, ...). 4 valori cardine:

Individui e interazioni PIÙ CHE processi e strumenti
Software funzionante PIÙ CHE documentazione esaustiva
Collaborazione col cliente PIÙ CHE negoziazione contrattuale
Rispondere al cambiamento PIÙ CHE seguire un piano

I valori a destra hanno valore, ma quelli a sinistra hanno più valore.

12 Principi del Manifesto

1. Soddisfazione cliente con consegne frequenti di software funzionante
2. Accogliere i cambiamenti, anche tardivi
3. Consegnare software funzionante frequentemente (settimane > mesi)
4. Business e sviluppatori collaborano quotidianamente
5. Persone motivate, ambiente di supporto, fiducia
6. Conversazione faccia a faccia = metodo più efficiente
7. Software funzionante = principale misura di progresso
8. Sviluppo sostenibile (ritmo costante)
9. Eccellenza tecnica e buon design
10. Semplicità (massimizzare lavoro non fatto)
11. Team auto-organizzati producono migliori architetture
12. Riflessione regolare + adattamento (retrospettive)

Quadro

Framework agile più diffuso (~70% adoption Agile). Definito nello Scrum Guide (ultima versione 2020, edizione attuale).

3 Ruoli (Accountabilities)

1. Product Owner — massimizza valore del prodotto, gestisce Product Backlog
2. Scrum Master — facilita Scrum, rimuove impedimenti, coach
3. Developers — auto-organizzati, costruiscono Increment

Il team Scrum totale: dimensione tipica 10 o meno persone.

5 Eventi

Evento	Durata max	Scopo
Sprint	1-4 settimane	Contenitore di tutti gli altri eventi, ciclo di sviluppo
Sprint Planning	8 ore (Sprint 1 mese)	Pianifica cosa fare nello Sprint
Daily Scrum	15 min	Sincronizzazione team, ispezione progresso
Sprint Review	4 ore	Ispezione Increment con stakeholder
Sprint Retrospective	3 ore	Ispezione di processo, miglioramento

3 Artefatti + Commitment

• Product Backlog → commitment Product Goal
• Sprint Backlog → commitment Sprint Goal
• Increment → commitment Definition of Done (DoD)

Definition of Done (DoD)

Lista condivisa di criteri che un Increment deve soddisfare per essere considerato rilasciabile. Garantisce qualità e trasparenza.

Velocity

Misura quantità di lavoro completata per Sprint (in story point). Usata per stime, NON per confronti tra team.

Filosofia

"Spingere agli estremi" pratiche di sviluppo riconosciute valide → maggior beneficio.

12 Pratiche XP originali

1. Planning Game (planning collaborativo)
2. Small Releases (rilasci piccoli e frequenti)
3. Metaphor (vocabolario condiviso del sistema)
4. Simple Design (design semplice)
5. Testing (TDD — Test-Driven Development)
6. Refactoring (miglioramento continuo del codice)
7. Pair Programming (2 dev su una postazione)
8. Collective Ownership (codice di tutti)
9. Continuous Integration (build + test automatici frequenti)
10. 40-Hour Week (sviluppo sostenibile)
11. On-Site Customer (cliente in sede)
12. Coding Standards (convenzioni codice)

TDD (Test-Driven Development) — ciclo Red-Green-Refactor

1. Red: scrivi un test che fallisce
2. Green: scrivi il codice minimo per passarlo
3. Refactor: pulisci codice mantenendo i test verdi

Pair Programming — vantaggi

Code review continua, condivisione conoscenza, riduzione difetti, mentoring. Driver scrive, Navigator osserva e suggerisce.

Origine

Sistema giapponese (Toyota, Taiichi Ohno, anni '40-50) — significato letterale "cartellino visuale". Adattato al software da David Anderson (2010).

6 Pratiche Kanban

1. Visualizzare il flusso (Kanban Board)
2. Limitare il WIP (Work In Progress) — colonne con numero massimo card
3. Gestire il flusso (ottimizzare lead time)
4. Rendere esplicite le policy
5. Implementare loop di feedback
6. Migliorare collaborativamente, evolvere sperimentalmente

Kanban Board tipico

To Do	In Progress (WIP=3)	Review (WIP=2)	Done
Card pendenti	Card in lavorazione	Card in revisione	Card completate

Metriche Kanban

• Lead Time: tempo da inizio richiesta a consegna
• Cycle Time: tempo lavorazione effettiva
• Throughput: numero card completate per unità tempo
• CFD (Cumulative Flow Diagram) — visualizza accumuli/colli di bottiglia

Scrumban

Ibrido Scrum + Kanban — sprint Scrum con board Kanban e WIP limit.

Origine

Adattamento del Toyota Production System (Lean Manufacturing, 1950) al software, formalizzato da Mary e Tom Poppendieck (2003).

7 Principi Lean

1. Eliminate waste (ridurre sprechi)
2. Build quality in (costruisci la qualità dentro il processo)
3. Create knowledge (crea conoscenza, learning)
4. Defer commitment (rimanda decisioni al momento opportuno)
5. Deliver fast (consegna rapidamente)
6. Respect people (rispetta le persone)
7. Optimize the whole (ottimizza il sistema, non le parti)

7 Sprechi (Muda)

1. Lavoro parzialmente fatto
2. Funzionalità extra non richieste
3. Re-apprendimento (informazione persa)
4. Handoff (passaggio di consegne)
5. Ritardi
6. Task switching (cambio contesto)
7. Difetti (bug)

Value Stream Mapping

Mappatura del flusso di valore dall'idea al deployment, identifica colli di bottiglia e sprechi.

Framework principali

Framework	Caratteristica
SAFe (Scaled Agile Framework)	Più completo e prescrittivo, livelli Team/Program/Large Solution/Portfolio
LeSS (Large-Scale Scrum)	Estende Scrum minimizzando aggiunte
Nexus	3-9 team Scrum integrati, Nexus Integration Team
Disciplined Agile (DA)	Toolkit ibrido (PMI dal 2019)
Spotify Model	Squad/Tribe/Chapter/Guild

SAFe (Scaled Agile Framework) — versione attuale 6.0 (2023)

• Team Level: Scrum/XP/Kanban
• Program Level: ART (Agile Release Train) — 50-125 persone, PI Planning ogni 8-12 settimane
• Large Solution Level: per multipli ART
• Portfolio Level: lean budgeting, value streams strategici

DevOps

Cultura + pratiche che uniscono Development e Operations → consegna rapida e affidabile. Pilastri: CALMS (Culture, Automation, Lean, Measurement, Sharing).

CI/CD pipeline

CI (Continuous Integration): merge frequente → build + test automatici.
CD (Continuous Delivery / Deployment): rilascio automatico.

Tool: Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD.

Metriche DORA (DevOps Research and Assessment)

1. Deployment Frequency
2. Lead Time for Changes
3. Mean Time to Restore (MTTR)
4. Change Failure Rate