Agilite Aspectize

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


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


Pourquoi ? Ya -t-il un problème ?


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

…


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


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


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.


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


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

▪ …


Les idées reçues


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


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 !


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.


… 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.


… 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.


Industrialisation… Robotisation ?

Métriques

▪ Mesurer quoi ?

▪ Pourquoi ?

Processus

▪ Automatiser quoi ?

▪ Pourquoi ?


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 !


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


Comment ?


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


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).


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)


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.


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.


Se sortir du cercle vicieux


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


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


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


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…


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…


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)


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


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


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


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


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é


Existence d'un point de passage unique

▪ Changer de format

▪ Transformer les données

▪ …


Documents

Agilite Aspectize