Agile software lifecycle

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 strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione del contratto
Rispondere 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
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
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
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
Time boxing
Storie
Informative workspace
Weekly cycle
Single code base
Pair Programming

Sviluppo Test First
Analisi della causa alla radice
Deploy quotidiano
Negoziare lo scope
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
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
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
Deploy quotidiano
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
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

Time boxing

Planning game

Spazio di lavoro informativo

Weekly cycle

Single code base

Test First

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
[email_address]
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 Trucchia Jacopo Romei Apress June 2010

Agile software lifecycle

by Francesco Trucchia on May 17, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 48

Statistics

Agile software lifecycle — Presentation Transcript