Agile et Ingénierie Des Exigences, Patrice Petit, Mars 2012

1 029 vues

Publié le

L'Ingénierie des eXigences consiste en partie à construire un référentiel qui s’auto-alimente par de nombreux changements en cours de vie du produit. L’Agile en propose une approche apprenante, centrée autour de l’interaction des individus et la qualité des produits. Elle permet d’obtenir une optimisation d’une spécification par l’exemple et exécutable créée juste au bon moment (just in time) et avec un ROI visualisable à chaque instant. Entre les vrais besoins, les faux besoins et les envies, la satisfaction du client est construite en consolidant l’ensemble des exigences à base de livraisons fréquentes et de feedbacks. Ainsi l’Agile semble faire évoluer positivement l’ingénierie des exigences.

Référence : http://www.agilbee.com/lab/ingenierie_des_exigences.html

Publié dans : Direction et management
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 029
Sur SlideShare
0
Issues des intégrations
0
Intégrations
103
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agile et Ingénierie Des Exigences, Patrice Petit, Mars 2012

  1. 1. L’Agile et l’Ingénierie des exigences Connaissance et Changement (c) Agilbee 2012. All right reserved. Patrice Petit Coach Agile & CST 29/03/2012 1
  2. 2. Ingénierie des eXigences (IX) L’IX consiste (…) à établir et maintenir un référentiel unique qui s’affine et se complète au cours du développement et qui est maintenu tout au long de la vie du système (…) Extrait du site afis.fr Changement 29/03/2012 (c) Agilbee 2012. All right reserved. 3
  3. 3. Un système complexe (c) Agilbee 2012. All right reserved. - 4 - • Evolution • Environnement Instabilités chaotiques Temps Le Changement est devenu nécessaire 29/03/2012
  4. 4. Agile = A la recherche du système optimal Besoins Exigences Produit Comment satisfaire un Client dans un temps fini, à budget fini et périmètre fixe ? Utopie ou Réalité ? 29/03/2012 (c) Agilbee 2012. All right reserved. 5
  5. 5. Un Processus de Qualité et la réalité Business (c) Agilbee 2012. All right reserved. - 6 - J’ai 1 nouvelle idée ! Pour une équipe de 10 personnes, le coût de la nouvelle idée devient : - Solution d’Architecture = 10 personnes x 10 jours = 100 jH - Solution du « Patch » : 1 personne x 1 h = 1heure x Homme 29/03/2012
  6. 6. Un Processus de Qualité et la réalité Business (c) Agilbee 2012. All right reserved. - 7 - J’ai besoin de 10 jours! Solution d’Architecture = 10 personnes x 10 jours = 100 jours x Homme 29/03/2012
  7. 7. Un Processus de Qualité et la réalité Business (c) Agilbee 2012. All right reserved. - 8 - J’ai besoin de 1 heures pour un Patch ? Solution du Développeur = 1 personne x 10 heure = 1 heure x Homme 29/03/2012
  8. 8. Un Processus de Qualité et la réalité Business (c) Agilbee 2012. All right reserved. - 9 - +25 % 29/03/2012 Instabilités Vue sur le terrain On réécrit les produits tous les 4 ans
  9. 9. Coût du Changement et des Paradigmes 29/03/2012 (c) Agilbee 2012. All right reserved. - 10 -temps Coût des évolutions Exponentiel (Boehm) 3 Linéaire (A. Cockburn) Constant (Kent Beck)
  10. 10. Agile : Itératif et Incrémental Approche Traditionnelle Approche Agile Démarrer le DEV à 40% du temps Démarrer le DEV le + tôt possible 29/03/2012 (c) Agilbee 2012. All right reserved. 11
  11. 11. Agile Système Complexe Humain As-tu reçu mon mail ? … pas son mail La documentation est mon Référentiel Qualité… Le Changement est devenu indispensable… Il faut donc l’accepter ! 29/03/2012 (c) Agilbee 2012. All right reserved. 12 Nous avons un BRUIT cognitif qui va ralentir l’équipe
  12. 12. Changement 29/03/2012 (c) Agilbee 2011. All right reserved. - 13 - Changement Connaissance Risques accrus Changement Connaissance Risques réduis Traditionnel Agile
  13. 13. Communication, Interaction, Alignement et Consensus (c) Agilbee 2012. All right reserved. - 14 -29/03/2012
  14. 14. Granularité et Connaissance 29/03/2012 (c) Agilbee 2012. All right reserved. 15 Résumé des Objectifs Objectifs des utilisateurs Sous-fonctionnalités EPIC UserStory TACHES Thème
  15. 15. Optimisation en continue 42% 17% 17% 12% 12% Taux des fonctionalités utilisés dans un système-type Never Rarely sometimes often Always (c) Agilbee 2012. All right reserved. - 16 - t 80% 50% 29/03/2012
  16. 16. Conception émergeante et Refactoring (c) Agilbee 2012. All right reserved. - 17 - Le besoin à changer ! Yeah !!! TEST 29/03/2012
  17. 17. Connaissance et Changement 29/03/2012 (c) Agilbee 2012. All right reserved. 18 Eh si l’on n’avez rien découvert !!!??? Exemple : « Comment garder son secret à l’infini ? »
  18. 18. A la recherche de la Satisfaction à tous les niveaux Est-ce utopique ? 29/03/2012 (c) Agilbee 2012. All right reserved. 19 Satisfaction des utilisateurs Satisfaction des clients Satisfaction de l’entreprise Satisfaction des développeurs
  19. 19. Spécification 2 Approches : 29/03/2012 (c) Agilbee 2012. All right reserved. 20 Spécification « Just In Time » Spécification avant
  20. 20. Spécification par l’exemple Division Numerateur Denominateur Quotient? 10 2 5.0 12.6 3 4.2 22 7 ~=3.14 9 3 <5 11 2 4<_<6 100 4 33 29/03/2012 - 21 -(c) Agilbee 2011. All right reserved. Test Driven Development Behaviour Driven Development
  21. 21. Mémoire d’un produit Produit = Equipe (Mc Carthy) Cas limite : La mort des produits et la santé de l’équipe 29/03/2012 (c) Agilbee 2012. All right reserved. 22
  22. 22. La méthodologie Scrum (c) Agilbee 2012. All right reserved. - 24 - Vélocité ≤4 weeks 24 h Product Backlog Items priorisés par le Product Owner Sprint 0 Produit Incremental Scrum Quotidien Sprint Backlog Items découpés en tâches par l’équipe Sprint Planning Sprint Sprint Review Rétrospective 29/03/2012 3 Piliers + 3 Briques + 1 Cycle de Vie
  23. 23. Les Grands Projets et l’ingénierie des eXigences • Scrum Of Scrum et Granularité 29/03/2012 (c) Agilbee 2012. All right reserved. 25 EPIC UserStory TACHES Thème
  24. 24. Conclusion 29/03/2012 (c) Agilbee 2012. All right reserved. 26 Qui penserait à accompagner ces équipes ? …Et les équipes dépérissent… …Plus d’exigences… Fin de vie des produits… Regard sur les limites de l’ingénierie des eXigences
  25. 25. Agilbee Organisme de Formation et de Coaching Agile www.agilbee.com Questions ? 29/03/2012 (c) Agilbee 2012. All right reserved. 27
  26. 26. Patrice Petit Agile Coach & Certified Scrum Trainer • Founder of Agile Paris • Founder and President of Agilii and Agilbee • AgileTour Founder • President of Agile World University & Univercity • Create and organize the first events on Agile in France: XP Day France, Paris SIG • Teach Agile in several universities in France: University of Paris Ouest, University of Toulouse and University of Bretagne Sud • Agile practitioner since 2000 28(c) Agilbee 2012. All right reserved. www.agilii.com www.agilbee.com www.agiletour.org www.agile-world.org 29/03/2012

×