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

4,141 views

Published on

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.

Published in: Business

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

  1. 1. 1  
  2. 2. Agile  Requirements   Alla  ricerca  del  filo  rosso   2  
  3. 3. 3  
  4. 4. 4  
  5. 5. 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. 6. 6  
  7. 7. 7  
  8. 8. Agile  Requirements   COSA  SONO  I  REQUISITI?   8  
  9. 9. 9  
  10. 10. 10  
  11. 11. 11  
  12. 12. 12  
  13. 13. Star Trike 13  
  14. 14. Moto RV 14  
  15. 15. 15  
  16. 16. 16  
  17. 17. Problem  space   Needs   Features   So?ware  requirements   SoluFon  space   17  
  18. 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.”     18  
  19. 19. 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  
  20. 20. RequisiF  so?ware   •  Stabilire  cosa  richiede  il  cliente  ad  un  sistema   so?ware     •  (Non  stabilire  come  il  sistema  verrà̀  costruito)     20  
  21. 21. 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. 22. 22  
  23. 23. 23  
  24. 24. 24  
  25. 25. Agile  Requirements   PERCHÉ  SONO  NECESSARI  I   REQUISITI?   25  
  26. 26. •  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  
  27. 27. waterfall   27  
  28. 28. agile   28  
  29. 29. •  Il  primo  rappresenta  un  ponte  tra  il  problema   di  mercato  da  risolvere  e  la  soluzione   immaginata.   29  
  30. 30. 30  
  31. 31. 31  
  32. 32. •  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. 33. 33  
  34. 34. •  Il  secondo  scopo  del  processo  dei  requisiF  è  la   Comunicazione.   34  
  35. 35. 35  
  36. 36. 36  
  37. 37. 37  
  38. 38. 38  
  39. 39. 39  
  40. 40. AGILE 40  
  41. 41. 41  
  42. 42. 42  
  43. 43. 43  
  44. 44. 44  
  45. 45. 45  
  46. 46. Guardando da 10000 metri 46  
  47. 47. 5 livelli della pianificazione agile Vision   Roadmap   Release   IteraFon   Day   47  
  48. 48. 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  
  49. 49. Agile  Requirements   OGGETTI  COINVOLTI   49  
  50. 50. 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  
  51. 51. Product   Backlog   51  
  52. 52. Product   Backlog   Passare  dalla  documentazione  alla   discussione   52  
  53. 53. Product  Backlog   53  
  54. 54. 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. 55. 55  
  56. 56. 56  
  57. 57. 57  
  58. 58. 58  
  59. 59. 59  
  60. 60. 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  
  61. 61. Story   Story   Story   Story   Story   Story   Story   Story   Epic   Epic   Epic   61  
  62. 62. 62  
  63. 63. Product  Backlog   •  Il  Product  Backlog  deve  essere  DEEP  (acronimo   suggerito  da  Mike  Cohn).   •  Detailed  Appropriately   •  EsFmated   •  Emergent   •  PrioriFzed   63  
  64. 64. Backlog  item   •  Dai  requisiF  ai  backlog  item   Requirement   1…*                                1…*   Backlog  Item   64  
  65. 65. Backlog  item   •  Il  Product  Backlog  può  contenere  molteplici   Fpologie  di  elemenF  (genericamente  chiamaF   Backlog  item):   –  Feature   –  Epic   –  Story  (user  story,  tech  story)   –  Bug   –  …   65  
  66. 66. Backlog  item   Requirement   1…*                                1…*   Backlog  Item   66  
  67. 67. Backlog  item   Requirement   1…*                                1…*   Backlog  Item   Is  one  of   Feature   0,1                    1…*   Realized  by   Epic   0,1                1…*   Story   Realized  by   67  
  68. 68. Cos’è una”Feature” 68  
  69. 69. 69  
  70. 70. 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. 71. 71  
  72. 72. Feature   •  Una  feature  è  un  servizio  fornito  da  un   prodoTo  per  soddisfare  uno  o  più  bisogni  del   cliente.   72  
  73. 73. Feature   •  Per  esempio:  "Il  sistema  offre  un  database   relazionale  per  ges>re  i  da>  persisten>”     73  
  74. 74. 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  
  75. 75. Feature   Feature   Feature   Feature   Feature   Feature   Feature   Feature   75  
  76. 76. Feature   Feature   Feature   Feature   Program  Backlog   Feature  grain   Feature   Feature   Feature   Feature   76  
  77. 77. Feature   Feature   Feature   Feature   Program  Backlog   Feature  grain   Feature   Feature   Feature   Feature   77  
  78. 78. Feature   Realized  by   0,1                                1…*   Story   78  
  79. 79. 79  
  80. 80. 80  
  81. 81. 81  
  82. 82. 82  
  83. 83. 83  
  84. 84. Una User Story dovrebbe tagliare tutti i livelli dell'architettura   84  
  85. 85. 85  
  86. 86. 86  
  87. 87. 87  
  88. 88. 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  
  89. 89. 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. 90. 90  
  91. 91. Story   91  
  92. 92. Story   Implemented  by   0,1                        1…*   Task   92  
  93. 93. 93  
  94. 94. Story   0,1                        1…*   Task   Is  one  of   User  Story   Other   work  item   Done  when  passes   Story   Acceptance  Test   Unit  Test   94  
  95. 95. Story   0,1                        1…*   Task   Is  one  of   User  Story   Other   work  item   Done  when  passes   Story   Acceptance  Test   Unit  Test   95  
  96. 96. 96  
  97. 97. 97  
  98. 98. Cos’è Test Driven Development?   98  
  99. 99. 1.  Scrivi  un  test  che  fallisca   RED   3.  Elimina  le   ridondanze   REFACTOR   GREEN   2.  Rendi  il  codice  funzionante   99  
  100. 100. •  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. 101. 101  
  102. 102. 102  
  103. 103. Acceptance  Test   103  
  104. 104. 104  
  105. 105. Backlog  Item   Constrained  by   0..*                                                                          0..*   Non-­‐funcFonal   Requirement   105  
  106. 106. Backlog  Item   Constrained  by   0..*                                                                          0..*   Non-­‐funcFonal   Requirement   1..*   Compliant   when  passes   0..*   System  QualiFes   tests   106  
  107. 107. 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  
  108. 108. FURPS+   FF   108  
  109. 109. 109  
  110. 110. 110  
  111. 111. 111  
  112. 112. 112  
  113. 113. 113  
  114. 114. 114  
  115. 115. 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. 116. 116  
  117. 117. 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. 118. 118  
  119. 119. Chi sono –  CEO di OpenWare –  Direttore artistico dell’etichetta Different Lands –  Certified ScrumMaster & Scrum Professional –  PMI-ACP Certified –  @fabioarmani –  www.open-ware.org 119  
  120. 120. A  suivre  …  ;-­‐)   120  
  121. 121. 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
  122. 122. 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  
  123. 123. 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  
  124. 124. Disclaimer 124  

×