Upload
fredy-fadel
View
703
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Critique de l\'Agilité pure
Citation preview
Monothéisme ou Darwinisme, deux solutions pour ignorer le problème
Frédéric Fadel 1Aspectize
Le pourquoi ?
Y a-t-il un problème ?
Les idées reçues
Le comment
Frédéric Fadel 2Aspectize
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 3Aspectize
Pourquoi ? Ya -t-il un problème ?
Frédéric Fadel 4Aspectize
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
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 6Aspectize
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 7Aspectize
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 processusgarantissant les trois points précédents
Le reste étant un détail de codage
Frédéric Fadel Aspectize 8
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 9Aspectize
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
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
Les idées reçues
Frédéric Fadel Aspectize 12
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
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
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
… 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
… Refactoring Connaître des ruses, astuces, techniques et outils
pour minimiser l'impact du changement est unebonne chose.
Mais faire du refactoring une méthode deconception ou une habitude de développementcomme le suggère notre ami Martin Fowler, faitpenser à nos amis Shadoks.
Le refactoring c'est de la maintenance corrective▪ Nécessaire , oui ! Evitable, non ! Structurant, NON.
Frédéric Fadel Aspectize 17
Industrialisation… Robotisation ?
Métriques
▪ Mesurer quoi ?
▪ Pourquoi ?
Processus
▪ Automatiser quoi ?
▪ Pourquoi ?
Frédéric Fadel Aspectize 18
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
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
Comment ?
Frédéric Fadel Aspectize 21
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
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
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 24Aspectize
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 25Aspectize
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 26Aspectize
Se sortir du cercle vicieux
Frédéric Fadel Aspectize 27
Croissance de code
Croissance de
complexité
Croissance de fragilité
Besoin de plus de tests
Besoin de code défensif
Et entrer dans un cercle vertueux
Frédéric Fadel Aspectize 28
Réduire le code
Réduire la complexité
Augmenter
la robustesse
Réduire les tests
Réduire le code défensif
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
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
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
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
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
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
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
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
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
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
Existence d'un point de passage unique
▪ Changer de format
▪ Transformer les données
▪ …
Frédéric Fadel Aspectize 39