Agilite Aspectize

1 510 vues

Publié le

Critique de l\'Agilité pure

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

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

Aucune remarque pour cette diapositive

Agilite Aspectize

  1. 1. Monothéisme ou Darwinisme, deux solutions pour ignorer le problème Frédéric Fadel Aspectize 1
  2. 2.  Le pourquoi ?  Y a-t-il un problème ?  Les idées reçues  Le comment Frédéric Fadel Aspectize 2
  3. 3.  Contre la méthode  Paul Feyerabend  Zen and the art of motorcycle maintenance  Robert Pirsig  Birth of the Chaordic Age  Dee Hock  The Pragmatic Programmer  Andrew Hunt & David Thomas Frédéric Fadel Aspectize 3
  4. 4. Pourquoi ? Ya -t-il un problème ? Frédéric Fadel Aspectize 4
  5. 5.  Question  Si l'approche Agile est la solution, quel est le problème ? ▪ Le coût des développements informatiques ? ▪ L'efficacité des systèmes d'information ? ▪ L'inadéquation entre ce qui est livré et ce qui est attendu ? ▪ L'incapacité de prévoir et/ou d'adhérer aux coûts ? ▪ … Frédéric Fadel Aspectize 5
  6. 6.  Les réalités du quotidien  Besoin de prévoir et d'estimer les coûts  Il y a souvent confusion entre besoin et solution  Les besoins ne sont pas toujours définis  Les ambiguïtés des échanges humains  Les erreurs quotidiennes  L'évolution des besoins  … Frédéric Fadel Aspectize 6
  7. 7.  La précision (artificielle) exigée par une machine  …  Question ?  Comment faire cohabiter le flou quotidien avec la précision machine ?  Deux réponses classiques  Réponse du monothéiste  Réponse du darwiniste Frédéric Fadel Aspectize 7
  8. 8.  Le monothéiste  Croit qu'il y a une bonne façon de…  Il suffit de réfléchir beaucoup  Il suffit de spécifier le besoin clairement  Il suffit de concevoir correctement la solution  Pour cela il suffit de mettre en place un processus garantissant les trois points précédents  Le reste étant un détail de codage Frédéric Fadel Aspectize 8
  9. 9.  Le monothéiste a une approche abstraite qui se résume à réfléchir d'abord développer après c.à.d.  Tenter l’impossible : ▪ Consacrer beaucoup de temps à réfléchir et analyser le problème pour lever les ambiguïtés, éviter les erreurs, prévoir les évolutions…  Sacrifier l’architecture ▪ Utiliser les outils et technologies RAD pour rattraper le temps "perdu"  C'est l'approche rigide, "traditionnelle", "académique"… mise en avant par des méthodologies style OO, UML… qui rigidifient l'homme : elle est adaptée au bâtiment, l'armée et l'usine. Frédéric Fadel Aspectize 9
  10. 10.  Le darwiniste  Croit qu'il y a une bonne façon de…  Il suffit … ▪ d'avoir un gars qui connait le besoin sous la main ▪ d'avoir des développeurs compétents et motivés ▪ d'avoir un environnement sympa (coca, pizza, café…) ▪ de mettre l'accent sur l'excellence technique ▪ de s'y mettre à deux ▪ de se réunir debout et régulièrement se mettre en cause  L'évolution se chargera du reste Frédéric Fadel Aspectize 10
  11. 11.  C'est une approche de rêveur  Qui s'est construite essentiellement en opposition au monothéisme, à ses coûts et ses échecs : ▪ L'aéroport de Denver ▪ Accord 1, Accord 2, Chorus, Copernic (canard : 21/1/9) ▪ FoxMeyer…  Qui a son lot d'échecs et de déceptions : ▪ Projet C3 qui a donné naissance à XP ▪ … Frédéric Fadel Aspectize 11
  12. 12. Les idées reçues Frédéric Fadel Aspectize 12
  13. 13.  Taille des projets Agiles  Plus le projet est gros, plus l'agilité a de la valeur ▪ Parce que c'est plus facile de réussir un petit projet  Mettre des contraintes a priori sur la taille de la salle de réunion est stupide ▪ Cela n'empêche que souvent, une bonne façon de communiquer c'est parler de vive voix ▪ Mais ce n'est pas la seule, ni toujours la meilleure Frédéric Fadel Aspectize 13
  14. 14.  TDD…  Il n'y a pas de doute : ▪ Que des tests (unitaires ou pas) sont nécessaires. ▪ Qu'il faille manger la banane par les deux bouts ▪ La qualité s'améliore si l'auteur d'un bout de code se met à la place de son utilisateur  Mais dire que l'architecture doit être trouvée par tâtonnement c'est une technique de Shadoks. ▪ Comme si les voitures étaient conçues par crash test ! Frédéric Fadel Aspectize 14
  15. 15.  Les tests :  Doivent-ils être exécutés : ▪ Automatiquement ? Oui. ▪ Impérativement ? Oui.  Peuvent-ils, doivent-ils être produits : ▪ Automatiquement ? Sûrement pas. Chez MS : ▪ les moins de 30 ans codent ▪ les plus de 30 ans testent : avec salaire élevé et prime sur défaillances trouvées. ▪ Exhaustivement ? Sûrement pas. ▪ Le choix de ce qu'on teste et pourquoi on teste est un choix intelligent. Frédéric Fadel Aspectize 15
  16. 16.  … Refactoring…  Il n'y a pas de doute ▪ Qu'un bout de code mal conçu, mal écrit, pas adapté à la situation, trop complexe, pas assez robuste… doit être réécrit et le plus tôt possible ▪ Don't Live with Broken Windows ▪ Fixing Broken Windows ▪ Mais une analyse d'impact bien au delà des tests unitaires doit aussi être faite. Frédéric Fadel Aspectize 16
  17. 17.  … Refactoring  Connaître des ruses, astuces, techniques et outils pour minimiser l'impact du changement est une bonne chose.  Mais faire du refactoring une méthode de conception ou une habitude de développement comme le suggère notre ami Martin Fowler, fait penser à nos amis Shadoks.  Le refactoring c'est de la maintenance corrective ▪ Nécessaire , oui ! Evitable, non ! Structurant, NON. Frédéric Fadel Aspectize 17
  18. 18.  Industrialisation… Robotisation ?  Métriques ▪ Mesurer quoi ? ▪ Pourquoi ?  Processus ▪ Automatiser quoi ? ▪ Pourquoi ? Frédéric Fadel Aspectize 18
  19. 19.  Métriques ▪ Nécessaire pour détecter les dérives ? ▪ OUI ▪ Suffisant pour garantir l'absence de dérive ? ▪ NON ▪ Nécessaire ou suffisant pour garantir la qualité ? ▪ NON et NON ▪ Peuvent réduire la qualité ? ▪ Peut être ?  C'est toujours plus facile de respecter la lettre que l'esprit ! Frédéric Fadel Aspectize 19
  20. 20.  Processus ▪ Pour améliorer le travail en équipe ? Forcément. ▪ Gestion des sources, des builds, de l'intégration continue, de l'exécution des tests… ▪ Dans la mesure où ça se substitue à la communication et favorise la robotisation, bien sûr que non  ▪ Automatiser les tâches bêtes favorise l'agilité ▪ Automatiser les tâches nécessitant analyse nuit à l'agilité ▪ Le CargoCultisme nous guette Frédéric Fadel Aspectize 20
  21. 21. Comment ? Frédéric Fadel Aspectize 21
  22. 22.  We value :  Working software ▪ over comprehensive documentation  Responding to change ▪ over following a plan  Customer collaboration ▪ over contract negotiation  Individuals and interactions ▪ over processes and tools Frédéric Fadel Aspectize 22
  23. 23.  CMM :  Nous déclarons que la qualité d’un produit logiciel est intimement liée à la qualité de son processus de fabrication. C’est pourquoi nous mesurons la conformité de ce processus (Watts Humphrey).  Agile :  Nous déclarons que la qualité d’un produit logiciel est intimement liée à la qualité de ce produit logiciel. C’est pourquoi nous mesurons la qualité de ce produit logiciel (Jean-Pierre Vickoff). Frédéric Fadel Aspectize 23
  24. 24.  L'animiste urbain  Croit qu'il y n'y a pas une bonne façon de…  Pense que c'est aux applications d'être agiles ▪ Qu'il faut donner vie aux applications ▪ Qu'il faut les dynamiser ▪ Qu'il faut assouplir les applications ▪ pour qu'elles soient évolutives ▪ Qu'il faut les développer agile ▪ Prend très aux sérieux : ▪ Responding to change over following a plan (manifeste Agile) Frédéric Fadel Aspectize 24
  25. 25.  Il considère que les ambiguïtés, erreurs et évolutions sont inévitables (voire souhaitables)  Il est convaincu que le développement de l'application ne s'arrête pas le jour de livraison. Que l'application va évoluer et doit changer même après la livraison.  Il est convaincu que les ambiguïtés se lèvent, les erreurs se corrigent et les évolutions s'imaginent et se décrivent mieux si les interlocuteurs sont devant un produit certes incomplet mais bien réel et qui tourne. Frédéric Fadel Aspectize 25
  26. 26.  C'est pourquoi il développe d'abord pour que l'application développée serve dès le début en tant que catalyseur : ▪ D'estimation des coûts ▪ D'évaluation des risques ▪ D'expression des besoins ▪ Conception de la solution ▪ Tests de fonctionnalités  Bref il se met dans une situation de maintenance continue sur l'application dès le premier jour. Il développe pour le long terme. Frédéric Fadel Aspectize 26
  27. 27.  Se sortir du cercle vicieux Croissance de code Croissance Besoin de de code défensif complexité Besoin de Croissance plus de tests de fragilité Frédéric Fadel Aspectize 27
  28. 28.  Et entrer dans un cercle vertueux Réduire le code Réduire le Réduire la code défensif complexité Réduire les Augmenter tests la robustesse Frédéric Fadel Aspectize 28
  29. 29.  Réduire la complexité  En réduisant le couplage (Orthogonalité)  En réduisant le code (DRY) ▪ La perfection est atteinte non quand il ne reste rien à ajouter, mais quand il ne reste rien à enlever. Antoine de Saint-Exupéry  En bâtissant une architecture sur les invariants techniques ▪ En abandonnant l'orienté objet Frédéric Fadel Aspectize 29
  30. 30.  Distinguer et isoler :  Les besoins métier évolutifs d'une architecture technique stable (le quoi du comment) ▪ Imaginer de réutiliser la couche technique pour un autre métier  La présentation, le métier et le stockage ▪ Imaginer de réutiliser la couche métier avec un autre IHM ▪ Imaginer de réutiliser la couche métier avec un autre stockage Frédéric Fadel Aspectize 30
  31. 31.  Les besoins techniques  Ne sont pas exprimés par le client (et ne devraient pas l'être)  TechnicalDebt ▪ Ne peuvent pas émerger dans un processus darwiniste surtout si on pratique (et on le devrait) le YAGNI  Sont connus du technicien expérimenté  Peuvent être implémentés sous forme "réutilisable" par une approche OO, typé, rigide, design time… Frédéric Fadel Aspectize 31
  32. 32.  Des besoins métier  Sont souvent exprimés d'une manière approximative  Emergeront mieux et se clarifieront si l'application ou la fonctionnalité est livrée tôt (quelques petits jours)  Sont orienté données et traitements  Doivent être implémentés sous forme "réutilisable" par une approche dynamique, non typée, souple, runtime… Frédéric Fadel Aspectize 32
  33. 33.  L'architecture technique offre des services configurables de  appels typés et non typés  bouchons , intercepteurs, factory, publish/subscribe  trace, log, gestions des exceptions  accès aux données, communications interprocess, sécurité  beaucoup d'autres…  Hollywood Principle  Dans la mesure du possible c'est la couche technique qui appelle (dynamiquement) le métier (pas l'inverse) Frédéric Fadel Aspectize 33
  34. 34.  Le métier  Les données métier (stockées ou pas) se modélisent selon un schéma relationnel.  L'application connaît ce schéma et s'en sert dans ses trois couches  Les traitements métier se modélisent sous forme de services (regroupement de méthodes stateless) configurables Frédéric Fadel Aspectize 34
  35. 35.  Quelques ruses pour développer agile dans .net :  Des techniques AOP (attributs .net) ▪ Découverte de types dynamiques par introspection  Chargement dynamique de dll (MEF) ▪ L'instanciation dynamique d'objet  Proxys dynamique (Transparent proxy) ▪ Pour écrire une Factory générique ▪ Pour implémenter la plupart des design pattern Frédéric Fadel Aspectize 35
  36. 36.  Génération de code (IL) à l'exécution  Utilisations des interfaces  Données relationnelles en mémoire (DataSet)  Existence d'un point de passage unique pour accéder aux services métier ▪ Une fonction ExecuteCommand qui peut tout appeler Frédéric Fadel Aspectize 36
  37. 37.  Pour les éléments de l'IHM ▪ Data binding (dynamique) ▪ Point de passage unique mémoire -> IHM ▪ Point de passage unique IHM -> mémoire ▪ Command binding (dynamique) ▪ Point de passage unique pour que l'IHM appelle le métier Frédéric Fadel Aspectize 37
  38. 38.  Existence d'un point de passage unique pour lire des données ▪ Une fonction GetData qui peut tout lire ▪ REST, ADO DataServices  Existence d'un point de passage unique pour écrire, modifier et supprimer des données ▪ Une fonction SaveData qui peut tout écrire ▪ "REST" ▪ Style DataAdapter amélioré Frédéric Fadel Aspectize 38
  39. 39.  Existence d'un point de passage unique ▪ Changer de format ▪ Transformer les données ▪… Frédéric Fadel Aspectize 39

×