Agile software lifecycle

Francesco (cphp) Trucchia

http://joind.in/talk/view/1426

o meglio...

a real software quality lifecycle experience

Chi sono

Francesco Trucchia... per gli amici ciccio, per il web cphp!! • Sviluppatore PHP dal 1999 • Sviluppatore XP dal 2006• Fondatore dell'XPug Romagna • CTO, co-founder e coach @ ideato srl• Autore di libri

Agenda

Parte I • Nozioni elementari di qualità, agile e XP• Processi di produzione software in una piccola azienda

 Parte II • Approfondimenti sulle pratiche e gli strumenti a supporto dei

processi di produzione software in una piccola azienda

Contestualizziamo un po'...

Le esperienza trattate in questo workshop vengono da esperienze reali nella mia azienda:

• fondata nel 2008• 7 dipendenti• sviluppo di applicazione PHP

La mission condivisa

"Produrre, per i nostri clienti, software di qualità nel minor tempo possibile"

Ma prima alcune nozioni....

Che cos'è il software lifecycle?

”Un processo di sviluppo software è un flusso strutturato e imposto per lo sviluppo di un prodotto software. Alcuni sinonimi possono essere software life cycle e processo software. Ci sono modelli differenti che cercano di descrivere questo processo." - Wikipedia

Alcuni modelli di sviluppo software

• Waterfall• Iterative and incremental• Agile

Che cosa significa qualità?

"Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something. Quality is a perceptual, conditional and somewhat subjective attribute and may be understood differently by different people." - Wikipedia

Che ne pensa il team?

• Codice semplice da capire e da modificare• Facilità nel fixare i bug• Requisiti chiari, mutevoli e semplici da stimare• Utilizzo di standard aperti• Utilizzo di pattern• Codice ad oggetti• Lavorare in team autogestiti• Comunicazione chiara• Feedback rapidi• Partecipare a corsi di formazioni• Apprendere• Vedere il fallimento il prima possibile così da poter

cambiare/correggere strada in tempo

E per voi che cosa significa produrre software di qualità?

Manifesto agile === ricerca della qualità

Stiamo ricercando modi migliori di sviluppare software facendolo e aiutando gli altri a farlo.

Grazie a questa attività siamo arrivati a considerare importanti:  

Gli individui e le interazioni più dei processi e degli strumentiIl software funzionante più che la documentazione esaustiva

La collaborazione col cliente più che la negoziazione del contrattoRispondere al cambiamento più che seguire i piani

 Ovvero, fermo restando il valore delle entità a destra, consideriamo più

importanti le entità a sinistra.

Noi cerchiamo la qualità con XP

"L'Extreme Programming (espressione inglese per programmazione estrema, spesso abbreviato in XP) è una metodologia agile e un

approccio all'ingegneria del software formulato da Kent Beck, Ward Cunningham e Ron Jeffries." - Wikipedia

XP si basa su 5 valori assoluti

• Comunicazione• Semplicità• Feedback• Rispetto• Coraggio

XP si basa su pratiche chiare

Primary • Sedersi insieme• Team completo• Workspace informativo• Lavoro energizzante• Pair Programming• Storie• Cicli settimanali• Cicli mensili• Ten minute build• Continous Integration• Test-First Programming• Design incrementale

Corollari

• Coinvolgimento del cliente• Deploy incrementale• Continuità del team• Shrinking Teams• Analisi alla radice delle causes• Codice condiviso• Code and Tests• Single Code Base• Deploy quotidiano• Scope del contratto negoziabile• Pay-Per-Use

I principi XP

• Flusso• Opportunità• Ridondanza• Fallimento• Qualità• Piccoli step• Responsabilità accettata

• Umanità• Economia• Mutuo Beneficio• Self-Similarity• Improvement• Diversità• Reflection

Noi condividiamo i valori XP e attraverso i suoi principi ne applichiamo le pratiche alla

ricerca della massima qualità

Vi ricorda qualcosa?

Pre-Produzione

Attività

• Analisi dei Requisiti • Pianificazione

Analisi Requisiti I

L'analisi dei requisiti è l'attività attraverso la quale si definiscono le funzionalità utente con il software.

Dall'analisi dei requisiti si producono delle storie funzionali (User stories) che serviranno a pianificare la release.

Analisi dei Requisiti II

Ruoli • Account• Figure primarie del team (UX, dev, design)• Product owner

 Pratiche• Sedersi insieme• Storie• Coinvolgimento del cliente• Time boxing

Pianificazione I

La pianificazione è l'attività attraverso la quale si definisce la più piccola release di valore da realizzare, delineando tempi e budget a scope variabile.

Durante la pianificazione si stimano le user stories utilizzando il buffer d'incertezza (regola dell'80/20) e lo scope variabile (must to have, nice to have).

In XP questo tipo di pianificazione è chiamata "Release Planning".

Pianificazione II

Ruoli• Account• Figure primarie del team• Product owner

 Pratiche• Sedersi insieme• Planning game• Coinvolgimento del cliente• Time boxing• Storie

Produzione

Attività

• Pianificazione• Sviluppo iterativo• Demo

Produzione - Pianificazione I

Ad ogni iterazione si pianifica quali storie implementare. Le storie vengono suddivide in task, i task stimati e si riempie il buffer dell'iterazione.

In XP questo tipo di pianificazione è chiamta "Iteration Planning".

Produzione - Pianificazione II

Ruoli• Tutto il team di sviluppo• Product owner• Account

Pratiche• Sedersi insieme• Team completo• Coinvolgimento del cliente• Time boxing • Storie• Informative workspace• Weekly cycle

 

Produzione - Sviluppo Iterativo I

Ad ogni iterazione si testano e implementano i task relativi alle storie. Ogni coppia di sviluppatori è responsabile della storia che ha scelto di implementare. Le storie vengono implementate in base all'ordinamento dato dal cliente.

Alla fine di ogni iterazione si memorizza la velocity.

Se durante l'iterazione nascono nuove storie, queste vengono messe in backlog e poi pianificate nel successivo iteration planning.

Produzione - Sviluppo Iterativo II

Ruoli• Tutto il team• Product owner

 Pratiche• Sedersi insieme• Team completo• Coinvolgimento del cliente• Time boxing • Storie• Informative workspace• Weekly cycle• Single code base• Pair Programming

 

• Sviluppo Test First• Continuità del team• Analisi della causa alla radice• Deploy quotidiano• Negoziare lo scope• Continous Integration• Codice condiviso• Stand-up meeting 

Produzione - Demo I

La fase di Demo è il momento nel quale il team si riunisce con il cliente per presentare la demo dell'ultima iterazione eseguita. Ogni singola storia viene mostrata al cliente e il cliente ne approva la bontà o fa emergere bug e nuove storie.

Produzione - Demo II

Ruoli• Tutto il team• Product owner

Pratiche• Sedersi insieme• Team completo• Coinvolgimento del cliente• Time boxing • Storie• Weekly cycle

 

Post-Produzione

Attività

• Consegna release• Bug-fixing

Consegna Release I

La fase della consegna della release è il momento nel quale si fa il deploy del codice nella macchina di produzione.

Alla fine del deploy in produzione il team festeggia l'obiettivo raggiunto.

Alla fine del deploy viene individuato il release manager.

Consegna Release II

Ruoli• Tutto il team• Product owner• Release manager

Pratiche• Pair programming• Continous Integration• Deploy quotidiano 

Mantenimento I

La fase di mantenimento è la fase nella quale una release è stata messa in produzione e il codice va mantenuto in caso di bug-fixing o micro modifiche.

Mantenimento II

Ruoli• Release manager• Cliente

Pratiche• Analisi della causa alla radice• Deploy quotidiano• Continous Integration• Kanban

Non è oro tutto ciò che luccica!!

Alcuni problemi reali che abbiamo incontrato

Pianificazione cross progetti

Customer Care

Feedback

Agile dentro Waterfall

Quando si lavora da terzisti

Team remoto

Codice legacy

L’illusione del multi tasking

Interruzioni continue

E voi?

Quali problemi abbassano la qualità di produzione del vostro

software?

Crampi allo stomaco… non è colpa dei clienti è solo la fame!!!

Ci vediamo alle 14.15

Abbiamo provato a trovare alcun soluzioni ai nostri problemi

Problemi Souzioni

• Il facilitatore• Il Pronto soccorso• Il facilitatore

• Strumenti di collaborazione• Spike di studio e testing• Il facilitatore• La tecnica del pomodoro

Che cosa fa il facilitatore?

• Pianifica i progetti internamente• Crea il team• Supporta l'account• Supporta il team• Supporta il cliente• Pianifica e decide le attività del pronto soccorso

Pronto soccorso?Siamo forse un ospedale?

La metafora del pronto soccorso

"Il pronto soccorso è un'unità operativa dell'ospedale dedicata ai casi di emergenza e con spazi dedicati alla breve osservazione (medicina d'urgenza). Qui vengono prestate le prime cure in tutti i casi di urgenza ed emergenza (traumi, infarti, ...) e si accede quindi in modalità di ricovero urgente." - Wikipedia

Supporto e pronto soccorso I

Secondo noi rispondere in maniera rapida alle richieste o emergenze del cliente è sinonimo di qualità.

Gli sviluppatori fanno quotidianamente turni al pronto soccorso, offrendo la loro disponibilità ad attività di emergenza aziendali.

Il facilitatore è il Product Owner del progetto Pronto Soccorso ed è lui che decide e pianifica le priorità di intervento.

Supporto e pronto soccorso II

Ruoli• Sviluppatore• Facilitatore• Cliente

 Pratiche• Stand-up meeting• Test first• Analisi della causa alla radice• Deploy quotidiano• Customer care di secondo livello• Stime e pianificazioni di emergenza

Approfondiamo un po’ di pratiche

con immagini e colori…

Sedersi insieme

User story

Coinvolgimento del cliente

Time boxing

Planning game

Spazio di lavoro informativo

Weekly cycle

Single code base

Test First

Continuità del team

Continous integration

Stand-up meeting

Pair Programming

Ora proviamo insieme a trovare una soluzine ai problemi emersi nella prima parte del workshop

Altre domande?

Ringrazimanti

• Ideato - http://www.ideato.it• Al mio team - www.theideatos.com• Jacopo Romei (il mio mentore) - www.sviluppoagile.it

Contatti

Francesco (cphp) Trucchia

E-Mail: ft@ideato.it

Skype: trucchia

Twittter: cphp

Website: www.ideato.it

Blog: www.cphp.it

http://joind.in/talk/view/1426

Recruitment @ ideato

Stiamo cercando uno sviluppatori php

recruitment@ideato.it

http://www.ideato.it/Azienda/Lavora-con-noi

Fermatemi e chiedetemi informazioni

Riferimenti

• Extreme Programming Explained (Second edition). K. Back, C. Andres. Addison Wesley 2005.

• Agile Estimating and Planning. M. Cohn. Prentice Hall 2005.• User Stories Applied: For Agile Software Development. M.

Cohn. Addison-Wesley Professional 2004.• The Pragmatic Programmer: From Journeyman to Master.

A. Hunt, D. Thomas. Addison-Wesley Professional 1999

Pro PHP Refactoring

What you’ll learn

• What refactoring is and why you need to refactor code

• What test-driven design is and why you need to test your code

• How to write unit and functional tests with PHPUnit and Selenium RC

• How to detect “bad smells” in PHP code, and refactor them using test-driven design

• How to refactor a large procedural application affected by many bad smells

Who is this book for?

This book is for PHP developers, businesses, and developers relying on legacy PHP apps.

Francesco TrucchiaJacopo Romei

Apress June 2010