How to be Agile - ABC of team working
42
-
Upload
commit-university -
Category
Engineering
-
view
84 -
download
5
Transcript of How to be Agile - ABC of team working
Perché Agile?
● Presentata nel 1970 da Winston W. Royce a una conferenza ingegneristica: IEEE WestCom.
● Processo sequenziale in cui ogni fase è completata prima che la successiva sia iniziata.
WATERFALL
● Rigidità: il committente del progetto, anche a fronte di cambiamenti dello scenario del mercato, ha difficoltà ad influire su quanto richiesto, perché la fase di progettazione è tutta all’inizio
LIMITI DEL WATERFALL● Time to Market: il committente del progetto non
riceve nulla se non in fondo al progetto, che spesso dura mesi se non anni.
● Costi elevati e non predicibili: quello che appare come un processo lineare ed efficiente diventa spesso una serie di cicli turbolenti che fanno perdere tanto tempo e tanti soldi.
The CHAOS Report (1994)
Source: http://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf
Type 1: Progetti completati rispettando tempi e budget prefissati
Type 2: Progetti completati ma senza rispettare tempi e budget
Type 3: Progetti abortiti prima del loro completamento.
16,2%
52,7%
31,1%
31,1%
52,7%
16,2%
The CHAOS Report (2001)
Source: http://www.cin.ufpe.br/~gmp/docs/papers/extreme_chaos2001.pdf
Type 1: Progetti completati rispettando tempi e budget prefissati
Type 2: Progetti completati ma senza rispettare tempi e budget
Type 3: Progetti abortiti prima del loro completamento.
28%
49%
23%
23%
49%
28%
"The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labour to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labour to perform the same task." - Tom Clancy (The Sum of All Fears)Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf
Nel 2001 diciassette professionisti di spicco si radunarono in una località sciistica dello Utah per discutere assieme del futuro del mondo software, stanchi di assistere ad una percentuale sempre crescente di progetti software che si frantumavano sulle rocce al termine della cascata.
Manifesto per lo Sviluppo Agile di Software
Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti
Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.
PLAN ANALYSIS DESIGN CODE TEST DEPLOY
ANALYSIS
DESIGN
CODE
TEST
PLA
N
DE
PLO
Y ANALYSIS
DESIGN
CODE
TEST
PLA
N
DE
PLO
Y ANALYSIS
DESIGN
CODE
TEST
PLA
N
DE
PLO
Y
Modello di sviluppo AGILE
Modello di sviluppo WATERFALL
Fatti, non...
3 year transition: 2005 – 2008 Results in 2008: 200 scrum teams world wide, total approx. 1500+ employees Average Team Velocity increase estimated at +35% / year Development cost reduction of over USD 1 million / year ROI on transition and trainings about 100% in first yearhttp://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption
Down to 1 release/yr Scrum adoption: 3 months
Salesforce.com - 2007
Results: 60+ Critical features delivered in < 9 months “Idea to Release” avg. rate: 2.2 quarters 70% of “Top 10 Ideas” are on track for delivery in 2007
All bugs are fixed for the release
All high level bugs are fixed for the release. Medium and low level bugs are not fixed
Product qualityindex
Client feedback
Burndown ChartNoneVisibility toolsProgress tracking
4070Average working
hours/week
6040Defects fixed
53New features
Increase in productivity
Release with ScrumRelease before ScrumMetricCategory
HCL EAI Services Inc. Enterprise application integration services: healthcare, retail, telecommunication, wireless.
2010 Videocitofono Touch
Metodologia Waterfall
· 15 anni uomo di effort · 3 anni di sviluppo · Scarso impatto sul mercato · Time to market inaccettabile –
2014 Videocitofono Serie 300
Metodologia Agile
· 3 anni uomo di effort · 1 anno di sviluppo · Prodotto innovativo · Time to market competitivo · Visibilità di processo
Fonte: Agile for Innovation, Milan 3 March 2015
http://www.cio.com/article/368313/100_Most_Agile_Companies_Honored100 Most Agile Companies Honored (2004)
Aerospace
Automotive Manufacturing Banking/Investment
Business/Consumer Services
Communications Computer Manufacturing
EducationFinancial services
Government
Health Care/Health Insurance
Insurance
Legal Services Manufacturing/Process Industries
Pharmaceuticals Retail/Wholesale
Technology Services
Transportation/Distribution
COME OTTENERE QUESTI RISULTATI?
COESIONE
COMUNICAZIONE
CADENZA
PRODUTTIVITÀ
QUALITÀ
TRASPARENZA
SPRECHI
VALORE
VALIDATED LEARNING
ITERATIVO
INCREMENTALE
RISCHIO
AGILE OVERVIEW
© Paolo Sammicheli 2015
PRACTICESMETODOLOGIES
PRINCIPLES
VALUES
© Paolo Sammicheli 2015
PRACTICESPlanning
GameTest Driven
DevelopmentBehaviour Driven
Development
Continuous Integration
Continuous RefactoringPair Programming
Small Releases
Collective code ownership
Management 3.0 #Workout Coding standard
System metaphor User Stories
Personas Product Canvas Jobs Stories
Popcorn Flow Retrospectives StandUp Meetings
U.S. Mapping Lean Change Canvas …
© Paolo Sammicheli 2015
METODOLOGIES
eXtreme Programming
KanbanSCRUM
DSDM ATERN FDD
SAFe DAD LeSS
© Paolo Sammicheli 2015
Lean Software Development AgileUP
PRINCIPLES
Lean Change
AGILELEAN
Lean Startup
© Paolo Sammicheli 2015
Radical Management
Kaizen Cynefin
VALUES
AGILELEAN
© Paolo Sammicheli 2015
MAGIC BALLS
MAGIC BALLS
· Le palle all'inizio non hanno energia. · Per diventare magiche devono essere toccate da tutti i membri del team. · Due membri non possono toccare la stessa palla. contemporaneamente (la palla deve essere scambiata al volo, “air time”). · Le palle che cadono a terra o toccano altri oggetti perdono energia. · Non si possono passare le palle lateralmente, solo frontalmente.
MAGIC BALLS
· Pianificazione 2 Minuti · Stima 1 Minuto · Esecuzione 3 Minuti · Retrospettiva 3 Minuti
5 ITERAZIONI
RISULTATI
Cosa vi portate a casaIterazioni
Rilasci frequenti
Team auto-organizzato
Ispezione ed adattamento
