Agile requirements - alla ricerca del filo rosso (iad 2013)
Upcoming SlideShare
Loading in...5
×
 

Agile requirements - alla ricerca del filo rosso (iad 2013)

on

  • 2,456 views

requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo ...

requisiti rappresentano, a mio avviso, il ‘fil rouge’ di tutto lo sviluppo software, sia che si tratti di applicazioni web o mobile, sia che siano coinvolti grandi sistemi Enterprise. Cerchiamo di capire perché.
Possiamo affermare che Lean Agile sta di fatto divenendo uno delle metodologie più adottate (se non il main-stream stesso) in ambito informatico e conseguentemente anche in ambiti connessi con l’informatica.
Nel mio talk (che spero possa trasformarsi in una tavola rotonda sul tema degli agile requirements e di ciò che ruota attorno ad essi) desidero presentare le varie possibilità di gestire i requisiti in modo agile e di seguire ad esempio il percorso delle “user story” (uno dei più efficaci metodi inventati in ambito agile o meglio nella metodologia eXtreme Programming per gestire i requisiti) in tutte le diverse fasi della loro ‘vita’ : a partire da ‘theme’, ‘epic’ e poi ‘story’ realizzata durante una determinata iterazione, fino al loro testing mediante Acceptance Test Driven Development e convalida business sul campo con gli utenti finali e i diversi stakeholder.

Bene… per poter effettuare questo affascinante itinerario cosa e chi viene coinvolto? Scopriremo assieme (ed argomenteremo le diverse soluzioni) che un’intera organizzazione Enterprise si dovrà plasmare per consentire ad una storia di divenire parte di una nuova funzionalità di successo.
Per avere realmente successo dovremmo scomodare molte metodologie tra le quali Lean , Agile, Lean StartUp, Lean UX e questo ci porterà nuovamente al punto di partenza. Perché vogliamo realizzare proprio questa storia? Quale era il requisito da cui siamo partiti. A quale Vision ci siamo ispirati?
Sono certo che il tema è affascinante e sarà interessante affrontarlo collettivamente, specialmente se trattato in ambito di round table.

Statistics

Views

Total Views
2,456
Views on SlideShare
717
Embed Views
1,739

Actions

Likes
10
Downloads
14
Comments
0

5 Embeds 1,739

http://www.agileday.it 1726
http://www.linkedin.com 7
http://10.1.1.6 3
http://www.google.it 2
https://www.google.es 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile requirements - alla ricerca del filo rosso (iad 2013) Agile requirements - alla ricerca del filo rosso (iad 2013) Presentation Transcript

    • 1  
    • Agile  Requirements   Alla  ricerca  del  filo  rosso   2  
    • 3  
    • 4  
    • Chi sono –  CEO di OpenWare –  Direttore artistico dell’etichetta Different Lands –  Certified ScrumMaster & Scrum Professional –  PMI-ACP Certified –  @fabioarmani –  www.open-ware.org 5  
    • 6  
    • 7  
    • Agile  Requirements   COSA  SONO  I  REQUISITI?   8  
    • 9  
    • 10  
    • 11  
    • 12  
    • Star Trike 13  
    • Moto RV 14  
    • 15  
    • 16  
    • Problem  space   Needs   Features   So?ware  requirements   SoluFon  space   17  
    • Fred  Brook’s   “The  most  difficult  part  of  building  a  so7ware   system  is  to  decide,  precisely,  what  must  be   built.  No  other  part  of  the  work  can  undermine   so  badly  the  resul>ng  so7ware  if  not  done   correctly.  No  other  part  is  so  difficult  to  fix  later.”     18  
    • Fred  Brook’s   “The  most  difficult  part  of  building  a  so7ware   system  is  to  decide,  precisely,  what  must  be   built.  No  other  part  of  the  work  can  undermine   so  badly  the  resul>ng  so7ware  if  not  done   correctly.  No  other  part  is  so  difficult  to  fix  later.”     19  
    • RequisiF  so?ware   •  Stabilire  cosa  richiede  il  cliente  ad  un  sistema   so?ware     •  (Non  stabilire  come  il  sistema  verrà̀  costruito)     20  
    • RequisiF  so?ware   •  (so?ware  requirements):  descrizione  dei   servizi  che  un  sistema  so?ware  deve  fornire,   insieme  ai  vincoli  da  rispeTare  sia  in  fase  di   sviluppo  che  durante  la  fase  di  operaFvità  del   so?ware     21  
    • 22  
    • 23  
    • 24  
    • Agile  Requirements   PERCHÉ  SONO  NECESSARI  I   REQUISITI?   25  
    • •  Ci  sono  due  principali  finalità  del  processo  di   requisiF,  a  prescindere  se  si  uFlizza  un   approccio  tradizionale  o  uno  agile  per  le   metodologie  di  sviluppo.   26  
    • waterfall   27  
    • agile   28  
    • •  Il  primo  rappresenta  un  ponte  tra  il  problema   di  mercato  da  risolvere  e  la  soluzione   immaginata.   29  
    • 30  
    • 31  
    • •  Anche  se  il  problema  di  base  rimane  lo  stesso,   molte  soluzioni  possono  esistere  ed  i  requisiF   si  andranno  a  collegare  ad  una  tra  queste   possibili  soluzioni.     32  
    • 33  
    • •  Il  secondo  scopo  del  processo  dei  requisiF  è  la   Comunicazione.   34  
    • 35  
    • 36  
    • 37  
    • 38  
    • 39  
    • AGILE 40  
    • 41  
    • 42  
    • 43  
    • 44  
    • 45  
    • Guardando da 10000 metri 46  
    • 5 livelli della pianificazione agile Vision   Roadmap   Release   IteraFon   Day   47  
    • Stesso processo @ tutti I livelli •  Lo stesso processo agile agisce (come un frattale) a differenti scale temporali, differenti time-box e livelli di pianificazione. 48  
    • Agile  Requirements   OGGETTI  COINVOLTI   49  
    • Strategic   Theme   IniFaFve   IniFaFve   Feature   Feature   Tac>c   Feature   Epic   T Epic   Story   Story   Story   T Epic   Story   Story   Story   Story   Story   Story   Story   T T T T T T T Story   Story   T T T T 50  
    • Product   Backlog   51  
    • Product   Backlog   Passare  dalla  documentazione  alla   discussione   52  
    • Product  Backlog   53  
    • Vision  » Backlog   •  Come  possiamo  passare  dalla  Vision  al   Product  Backlog?   •  Ad  esempio  uFlizzando  una  serie  di  canvas   così  come  proposto  da  Roman  Pichler   54  
    • 55  
    • 56  
    • 57  
    • 58  
    • 59  
    • Product  Backlog   •  Ecco  alcune  cose  da  tenere  presenF  riguardo  il   product  backlog:     –  I  requisiF  sono  emergenF   –  Il  product  backlog  richiede  “grooming”  –  ovvero   un  conFnuo  raffinamento  dei  suoi  requisiF   –  Il  Product  Backlog  può  essere  visto  come  un   iceberg   60  
    • Story   Story   Story   Story   Story   Story   Story   Story   Epic   Epic   Epic   61  
    • 62  
    • Product  Backlog   •  Il  Product  Backlog  deve  essere  DEEP  (acronimo   suggerito  da  Mike  Cohn).   •  Detailed  Appropriately   •  EsFmated   •  Emergent   •  PrioriFzed   63  
    • Backlog  item   •  Dai  requisiF  ai  backlog  item   Requirement   1…*                                1…*   Backlog  Item   64  
    • Backlog  item   •  Il  Product  Backlog  può  contenere  molteplici   Fpologie  di  elemenF  (genericamente  chiamaF   Backlog  item):   –  Feature   –  Epic   –  Story  (user  story,  tech  story)   –  Bug   –  …   65  
    • Backlog  item   Requirement   1…*                                1…*   Backlog  Item   66  
    • Backlog  item   Requirement   1…*                                1…*   Backlog  Item   Is  one  of   Feature   0,1                    1…*   Realized  by   Epic   0,1                1…*   Story   Realized  by   67  
    • Cos’è una”Feature” 68  
    • 69  
    • Feature   •  Indipendentemente  dalla  forma,  il  contenuto   primario  della  Vision  è  un  insieme  di  feature   che  descrivono  quali  nuove  funzionalità  il   sistema  dovrà  fare  per  i  propri  utenF  e  quali   benefici  quesF  ulFmi  ne  trarranno.   Leffingwell  [2012]   70  
    • 71  
    • Feature   •  Una  feature  è  un  servizio  fornito  da  un   prodoTo  per  soddisfare  uno  o  più  bisogni  del   cliente.   72  
    • Feature   •  Per  esempio:  "Il  sistema  offre  un  database   relazionale  per  ges>re  i  da>  persisten>”     73  
    • Feature  » CaraTerisFche   •  Una  feature  è  un  elemento  valido  a  livello  di   strategia  e  cosFtuisce  un  elemento  del   Program  Backlog   •  Inoltre  può  essere  considerato  un  elemento  di   transizione  tra  il  layer  strategico  e  quello   tajco  (di  esecuzione)   74  
    • Feature   Feature   Feature   Feature   Feature   Feature   Feature   Feature   75  
    • Feature   Feature   Feature   Feature   Program  Backlog   Feature  grain   Feature   Feature   Feature   Feature   76  
    • Feature   Feature   Feature   Feature   Program  Backlog   Feature  grain   Feature   Feature   Feature   Feature   77  
    • Feature   Realized  by   0,1                                1…*   Story   78  
    • 79  
    • 80  
    • 81  
    • 82  
    • 83  
    • Una User Story dovrebbe tagliare tutti i livelli dell'architettura   84  
    • 85  
    • 86  
    • 87  
    • Acceptance  Tests   •  Le  feature  come  le  user  story,  richiedono   acceptance  test   •  Ogni  feature  richiede  uno  o  più  acceptance   test,  e  non  può  essere  considerata  done  finché   tuj  i  suoi  test  non  passano   88  
    • Backlog  Item   Is  one  of   Feature   1   Realized  by   Story   0,1                                1..*   1   Done  when  passes   1..*   Feature   Acceptance  Test   1..*   Story   Acceptance  Test   89  
    • 90  
    • Story   91  
    • Story   Implemented  by   0,1                        1…*   Task   92  
    • 93  
    • Story   0,1                        1…*   Task   Is  one  of   User  Story   Other   work  item   Done  when  passes   Story   Acceptance  Test   Unit  Test   94  
    • Story   0,1                        1…*   Task   Is  one  of   User  Story   Other   work  item   Done  when  passes   Story   Acceptance  Test   Unit  Test   95  
    • 96  
    • 97  
    • Cos’è Test Driven Development?   98  
    • 1.  Scrivi  un  test  che  fallisca   RED   3.  Elimina  le   ridondanze   REFACTOR   GREEN   2.  Rendi  il  codice  funzionante   99  
    • •  L'uso  del  Test  Driven  Development  permeTe   non  solo  di  costruire  il  programma  assieme  ad   una  serie  di  test  di  regressione   automaFzzabili,  ma  anche  di  sFmare  in   maniera  più  precisa  lo  stato  d'avanzamento   dello  sviluppo  di  un  progeTo.   •  E’  una  tecnica  di  design  e  di  coding.   100  
    • 101  
    • 102  
    • Acceptance  Test   103  
    • 104  
    • Backlog  Item   Constrained  by   0..*                                                                          0..*   Non-­‐funcFonal   Requirement   105  
    • Backlog  Item   Constrained  by   0..*                                                                          0..*   Non-­‐funcFonal   Requirement   1..*   Compliant   when  passes   0..*   System  QualiFes   tests   106  
    • NonfuncFonal  requirement   •  I  nonfuncFonal  requirement  possono  essere   visF  come  dei  vincoli  sui  Backlog   Feature   Story   Feature   Story   Feature   Story   Feature   Story   Feature   Story   Feature   Epic   Feature   Epic   Feature   Epic   NFR   NFR   107  
    • FURPS+   FF   108  
    • 109  
    • 110  
    • 111  
    • 112  
    • 113  
    • 114  
    • Product Owner collaboration Business Facing User Acceptance Tests! Exploratory Tests! Usability Tests Functional Tests! Customer Tests! Story Tests/Examples Critiques Product Supports the Team Customer collaboration Q2 Q3 Q1 Q4 Performance Tests! Load Tests! ‘ility’ Tests Unit Tests! Integration Tests Developer collaboration Technology Facing IT collaboration 115  
    • 116  
    • Requirement   Constrained  by   Backlog  Item   0…*                                                                                      0…*   1…*                                1…*   Is  one  of   Feature   Non-­‐funcFonal   Requirements   System  QualiFes   tests   Realized  by   0,1                                1…*   Story   Implemented  by   0,1                        1…*   Task   Is  one  of   Feature   Acceptance   Test   User  Story   Other   work  item   Done  when  passes   Story   Acceptance  Test   Unit  Test   117  
    • 118  
    • Chi sono –  CEO di OpenWare –  Direttore artistico dell’etichetta Different Lands –  Certified ScrumMaster & Scrum Professional –  PMI-ACP Certified –  @fabioarmani –  www.open-ware.org 119  
    • A  suivre  …  ;-­‐)   120  
    • Strategic   Theme   IniFaFve   IniFaFve   Feature   Feature   Tac>c   Feature   Epic   T Epic   Story   Story   Story   T Epic   Story   Story   Story   Story   Story   Story   Story   T T T T T T T Story   Story   T T T T
    • Requirement   1…*                                1…*   Backlog  Item   0…*                                                    1…*   Constrained  by   Non-­‐funcFonal   Requirements   Is  one  of   Feature   0,1                1…*   Realized  by   Story   0,1                        1…*   Implemented  by   Done  when   passes   Acceptance  Test   Task  
    • Requirement   1…*                                1…*   Backlog  Item   0…*                                                    1…*   Constrained  by   Non-­‐funcFonal   Requirements   Is  one  of   Strategic   Product   Theme   1                    1…*   IniFat.   Realized  by   0,1                    1…*   Feature   Realized  by   0,1                1…*   Realized  by   Story   0,1                        1…*   Implemented  by   Done  when   passes   Acceptance  Test   Consumer  Init.   Architecture  Init.   Task  
    • Disclaimer 124