06 - XP, Lean e DevOps: Pratiche Tecniche e Cultura Agile

XP, Lean e DevOps: Pratiche Tecniche e Cultura Agile

Oltre a Scrum e Kanban, esistono altre metodologie e culture fondamentali per lo sviluppo software moderno: Extreme Programming (XP) con le sue pratiche tecniche estreme, Lean con focus sull'eliminazione sprechi, e DevOps che abbatte i silos tra development e operations.

Extreme Programming (XP)

Storia e Filosofia

Extreme Programming nasce alla fine degli anni '90, creato da Kent Beck durante il progetto Chrysler C3. Il nome deriva dal fatto che porta le buone pratiche di sviluppo agli "estremi":

I 5 Valori di XP

1️⃣ COMMUNICATION (Comunicazione)
   └─ Costante, faccia a faccia, onesta

2️⃣ SIMPLICITY (Semplicità)
   └─ Fare la cosa più semplice che funziona (YAGNI)

3️⃣ FEEDBACK
   └─ Rapido e continuo (da test, cliente, team)

4️⃣ COURAGE (Coraggio)
   └─ Coraggio di refactorare, dire la verità, cambiare

5️⃣ RESPECT (Rispetto)
   └─ Rispetto reciproco tra membri del team

Le 12 Pratiche di XP

1. Test-Driven Development (TDD)

TDD è la pratica fondamentale di XP: scrivi il test prima del codice di produzione.

🔴 RED: Write a failing test
   ├─ Scrivi test per funzionalità che non esiste ancora
   ├─ Test deve fallire (altrimenti non stai testando nulla!)
   └─ Focus su "what" non "how"

🟢 GREEN: Make the test pass
   ├─ Scrivi codice minimo per far passare il test
   ├─ Non importa se il codice è "brutto"
   └─ Obiettivo: green bar il più velocemente possibile

🔵 REFACTOR: Improve the code
   ├─ Migliora design mantenendo test verdi
   ├─ Elimina duplicazione
   ├─ Rendi codice più leggibile
   └─ Test ti proteggono da regressioni

♻️ REPEAT per ogni piccola funzionalità (cicli di 2-10 min)

// 🔴 RED: Scrivi test che fallisce
describe('isPalindrome', () => {{ '{' }}
  it('should return true for "racecar"', () => {{ '{' }}
    expect(isPalindrome('racecar')).toBe(true);
  {{ '}' }});
{{ '}' }});

// Test fallisce perché isPalindrome non esiste!

// 🟢 GREEN: Implementa funzione minima
function isPalindrome(str: string): boolean {{ '{' }}
  return str === str.split('').reverse().join('');
{{ '}' }}

// Test passa! ✅

// 🔵 REFACTOR: Migliora
function isPalindrome(str: string): boolean {{ '{' }}
  const normalized = str.toLowerCase().replace(/[^a-z0-9]/g, '');
  return normalized === normalized.split('').reverse().join('');
{{ '}' }}

// Aggiungi più test (edge cases)
it('should return true for "A man, a plan, a canal: Panama"', () => {{ '{' }}
  expect(isPalindrome('A man, a plan, a canal: Panama')).toBe(true);
{{ '}' }});

it('should return false for "hello"', () => {{ '{' }}
  expect(isPalindrome('hello')).toBe(false);
{{ '}' }});

2. Pair Programming

Due sviluppatori lavorano insieme allo stesso computer su stesso codice.

3. Continuous Integration (CI)

Integrare codice nel repository condiviso frequentemente (più volte al giorno), con build e test automatici.

📝 DEVELOPER COMMIT (multiple times per day)
   ↓
🔔 CI SERVER TRIGGERED (webhook da Git)
   ↓
📦 BUILD
   ├─ Checkout latest code
   ├─ Install dependencies (npm install)
   ├─ Compile (tsc, webpack)
   └─ Package artifacts
   ↓
🧪 TEST
   ├─ Unit tests (Jest, Mocha)
   ├─ Integration tests
   ├─ Lint & code style (ESLint)
   └─ Security scan (npm audit)
   ↓
✅ SUCCESS: Notifica team (Slack, email)
   └─ Artifact pronto per deploy

❌ FAILURE: Notifica team immediatamente
   └─ Fix diventa priorità #1 (stop the line!)

4. Refactoring Continuo

Refactoring: cambiare struttura interna del codice senza modificare comportamento esterno. Fatto continuamente, non "quando abbiamo tempo".

5. Simple Design

Il design più semplice che passa tutti i test. 4 regole in ordine di priorità:

1️⃣ Passes all tests
   └─ Funzionalità corretta è priorità #1

2️⃣ Reveals intention
   └─ Codice esprime chiaramente cosa fa

3️⃣ No duplication (DRY)
   └─ Elimina codice duplicato

4️⃣ Fewest elements
   └─ Minimo numero di classi/metodi necessari

6. Collective Code Ownership

Tutto il team possiede tutto il codice. Chiunque può modificare qualsiasi parte.

Altre Pratiche XP

7️⃣  SMALL RELEASES
    └─ Rilasci frequenti (settimane, non mesi)

8️⃣  40-HOUR WEEK
    └─ Sostenibilità, no overtime

9️⃣  ON-SITE CUSTOMER
    └─ Cliente disponibile quotidianamente

🔟 CODING STANDARDS
    └─ Team segue stesse convenzioni

1️⃣1️⃣ SYSTEM METAPHOR
    └─ Metafora condivisa per architettura

1️⃣2️⃣ SUSTAINABLE PACE
    └─ Marathon, not sprint

Lean Software Development

Origini: Toyota Production System

Lean deriva dal Toyota Production System (TPS) sviluppato da Taiichi Ohno negli anni '50. Adattato al software da Mary e Tom Poppendieck (2003).

I 7 Principi Lean

1. Eliminate Waste (Elimina Sprechi)

I 7 sprechi (Muda) nello sviluppo software:

1️⃣ PARTIALLY DONE WORK (Lavoro parzialmente completato)
   ├─ Es: Codice non integrato, feature 90% completa
   └─ Soluzione: Definition of Done rigorosa, CI/CD

2️⃣ EXTRA FEATURES (Funzionalità extra)
   ├─ Es: Gold plating, "nice to have" mai usati
   └─ Soluzione: YAGNI, MVP approach

3️⃣ RELEARNING (Riapprendimento)
   ├─ Es: Conoscenza persa, documentation assente
   └─ Soluzione: Knowledge sharing, pair programming

4️⃣ HANDOFFS (Passaggi di consegna)
   ├─ Es: Dev → QA → Ops (silos)
   └─ Soluzione: Cross-functional teams, DevOps

5️⃣ DELAYS (Ritardi)
   ├─ Es: Waiting for approvals, dependencies
   └─ Soluzione: Rimuovere impedimenti, autonomia team

6️⃣ TASK SWITCHING (Multitasking)
   ├─ Es: Developer su 5 progetti contemporaneamente
   └─ Soluzione: WIP limits, focus

7️⃣ DEFECTS (Difetti)
   ├─ Es: Bug in produzione, rework
   └─ Soluzione: TDD, code review, automated testing

2. Build Quality In (Qualità Integrata)

Non "aggiungiamo qualità dopo" (testing phase) ma costruiamo qualità dentro dal primo momento.

3. Create Knowledge (Amplifica l'Apprendimento)

Sviluppo software è knowledge creation, non produzione ripetitiva.

4. Defer Commitment (Decide il Più Tardi Possibile)

Ritarda decisioni irreversibili fino all'ultimo momento responsabile. Più informazioni hai, migliori decisioni prendi.

5. Deliver Fast (Consegna Velocemente)

Cicli brevi di sviluppo → feedback rapido → apprendimento accelerato.

6. Respect People (Rispetta le Persone)

Le persone sono la risorsa più importante. Empowerment e fiducia.

7. Optimize the Whole (Ottimizza il Tutto)

Ottimizza il value stream end-to-end, non sotto-ottimizzazioni locali.

VALUE STREAM: Dalla richiesta del cliente al valore consegnato

[Customer Request] → [Backlog] → [Dev] → [Test] → [Deploy] → [Customer Value]
     ⏱️ 1 day         ⏱️ 3 days  ⏱️ 5 days ⏱️ 2 days ⏱️ 1 day

📊 LEAD TIME: 12 giorni totali
📊 VALUE-ADD TIME: 8 giorni (effettivo lavoro)
📊 WASTE: 4 giorni (attese, handoff)

🎯 OTTIMIZZAZIONE:
- Ridurre tempo in backlog (WIP limits)
- Automatizzare testing (da 2 giorni a 2 ore)
- CI/CD per deploy (da 1 giorno a 10 min)

RISULTATO: Lead time 7 giorni → 2x più veloce!

DevOps: Development + Operations

Cos'è DevOps?

DevOps è una cultura e set di pratiche che abbatte i silos tra Development e Operations, abilitando continuous delivery di valore.

DEV: "Il nostro obiettivo è rilasciare features velocemente"
OPS: "Il nostro obiettivo è stabilità, no cambiamenti!"

RISULTATO: Conflitto, deploy ogni 3 mesi, outages frequenti

DevOps Team: "Obiettivo condiviso: consegnare valore continuamente E in sicurezza"

RISULTATO: Deploy multipli al giorno, high reliability

CALMS Framework

I 5 pilastri di DevOps:

🔵 C - CULTURE (Cultura)
   ├─ Collaborazione Dev-Ops
   ├─ Shared responsibility
   ├─ Blameless post-mortems
   └─ Continuous learning

🔵 A - AUTOMATION (Automazione)
   ├─ CI/CD pipelines
   ├─ Infrastructure as Code
   ├─ Automated testing
   └─ Self-service deployment

🔵 L - LEAN
   ├─ Elimina sprechi
   ├─ Small batch sizes
   ├─ Value stream focus
   └─ Continuous improvement

🔵 M - MEASUREMENT (Misurazione)
   ├─ Metriche chiave (DORA metrics)
   ├─ Monitoring & Observability
   ├─ Data-driven decisions
   └─ Feedback loops

🔵 S - SHARING (Condivisione)
   ├─ Knowledge sharing
   ├─ Open communication
   ├─ Cross-team collaboration
   └─ Communities of practice

CI/CD in Dettaglio

Continuous Integration (CI)

Già trattato in XP. Developer integrano codice frequentemente (daily), con build e test automatici.

Continuous Delivery (CD)

Ogni commit che passa CI è potenzialmente deployabile in produzione. Deploy richiede approvazione manuale.

Continuous Deployment

Ogni commit che passa CI è automaticamente deployato in produzione. Nessun intervento manuale.

🔵 COMMIT & PUSH
   ↓
📦 CI: BUILD & TEST (2-5 min)
   ├─ Compile
   ├─ Unit tests
   ├─ Lint
   └─ Security scan
   ↓
🟢 DEPLOY TO STAGING (auto) (1 min)
   ├─ Blue/Green deployment
   ├─ Smoke tests
   └─ Integration tests (5 min)
   ↓
🟡 MANUAL APPROVAL (Continuous Delivery)
   ├─ Product Owner reviews staging
   ├─ Click "Deploy to Prod" button
   └─ OR: Automatic (Continuous Deployment)
   ↓
🔴 DEPLOY TO PRODUCTION (1 min)
   ├─ Canary release (5% traffic)
   ├─ Monitor metrics
   ├─ Gradual rollout 100%
   └─ Success! 🎉 (or auto-rollback if errors)

Infrastructure as Code (IaC)

Gestire infrastruttura con codice versionato, invece di configurazione manuale.

// Define infrastructure as code
resource "aws_instance" "web_server" {{ '{' }}
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {{ '{' }}
    Name = "ProductionWebServer"
  {{ '}' }}
{{ '}' }}

resource "aws_s3_bucket" "assets" {{ '{' }}
  bucket = "my-app-assets"
  acl    = "public-read"
{{ '}' }}

// terraform apply → Infra creata automaticamente!
// terraform destroy → Infra eliminata
// Version control → Git per infra changes

DORA Metrics

DevOps Research and Assessment ha identificato 4 metriche chiave per misurare performance DevOps:

1️⃣ DEPLOYMENT FREQUENCY
   └─ Quanto spesso deployiamo in prod?
      Elite: Multiple per day
      High: Weekly to monthly
      Low: Monthly to every 6 months

2️⃣ LEAD TIME FOR CHANGES
   └─ Tempo da commit a produzione?
      Elite: < 1 hour
      High: 1 day to 1 week
      Low: 1 month to 6 months

3️⃣ TIME TO RESTORE SERVICE
   └─ Quanto per ripristinare dopo incident?
      Elite: < 1 hour
      High: < 1 day
      Low: 1 week to 1 month

4️⃣ CHANGE FAILURE RATE
   └─ % deploy che causano failure?
      Elite: 0-15%
      High: 16-30%
      Low: 31-45%

Integrare XP, Lean e DevOps con Scrum

📅 SPRINT PLANNING (Scrum)
   └─ Team seleziona User Stories (Lean: pull system)

💻 DEVELOPMENT (XP Practices)
   ├─ Pair Programming
   ├─ TDD (Red-Green-Refactor)
   ├─ Continuous Refactoring
   └─ Simple Design

🔄 EVERY COMMIT (DevOps)
   ├─ CI pipeline runs
   ├─ Automated tests
   ├─ Deploy to staging
   └─ Ready for production

📊 DAILY STANDUP (Scrum)
   └─ Walk the board, identify impediments

🎬 SPRINT REVIEW (Scrum)
   └─ Demo features deployed to staging

🔁 RETROSPECTIVE (Scrum + Lean)
   ├─ Inspect & Adapt
   ├─ Identify waste
   └─ Kaizen experiments

🚀 DEPLOY TO PRODUCTION (DevOps)
   └─ Continuous Delivery: quando PO approva

Conclusioni

XP, Lean e DevOps sono complementari e si integrano perfettamente con framework Agile come Scrum. Insieme formano un approccio completo per sviluppo software moderno: fast, high-quality, continuous delivery.