mercredi 29 octobre 2008

PROGRAMMEZ PAR CONTRAT!

Vous avez sûrement entendu qu'il est peut être efficace de favoriser la collaboration avec le client plutôt que la négociation du contrat?
Et bien, je vous assure qu'il est efficace de programmer par contrat!


Cela n'a rien avoir avec la dualité collaboration/contrat du Manifeste Agile, mais cela a peut-être suscité votre curiosité. Pour découvrir en quoi la programmation par contrat contribue à la mise en pratique des principes agiles et du Lean, lisez le court article suivant:
Programmez par Contrat!

lundi 27 octobre 2008

ANALOGIES ENTRE L'EQUIPE ET SON LOGICIEL (2NDE EDITION)

La récente conférence de Géry Derbier à l'Agile Tour à Valence et les conflits que nous avons vécu il y a peu sur notre projet m'ont amené à ajouter d'autres dualités dans mon article sur les analogies entre une équipe et son logiciel.
La seconde édition de l'article est consultable ici.

AGILE TOUR 2008 VALENCE - REGIS MEDINA

Pendant 50 minutes, Régis Medina (Crossbow Labs) remanie du code en direct.
Cette session permet de recentrer l'attention des participants sur le (beau) code et les pratiques techniques.

AGILE TOUR 2008 VALENCE - ALEXANDRE BOUTIN 2

Alexandre présente un retour d'expérience sur la transition vers l'agilité chez Yahoo!.
Pragmatisme et franc-parler sont au rendez-vous.

AGILE TOUR 2008 VALENCE - GERY DERBIER 2

Après son alelier "Spécifieurs et Artistes", Géry termine les conférences avec une présentation de la démarche Crystal.

AGILE TOUR 2008 VALENCE - PATRICE PETIT 2

Patrice Petit commence les conférences avec une introduction aux démarches agiles en 50 minutes.

dimanche 26 octobre 2008

AGILE TOUR 2008 VALENCE - OUVERTURE ET CLOTURE

Nicolas Blanpain a mené l'ouverture et la clôture des conférences.

AGILE TOUR 2008 VALENCE - PARTICIPANTS

L'amphithéâtre de l'ESISAR était plein. Environ 120 participants sont venu partager cet évènement.

AGILE TOUR 2008 VALENCE - FRANCOIS BRUN

François Brun anime à son tour un forum ouvert, le dernier de la journée.
Il faut une sacrée expérience pour animer ce genre de session destinée à accueillir les sceptiques.

AGILE TOUR 2008 VALENCE - ALEXANDRE BOUTIN

Après son retour d'expérience sur Yahoo!, Alexandre Boutin enchaine en animant un forum ouvert pour les curieux et les sceptiques.

Alexandre a publié un billet sur sa participation à l'évènement.

AGILE TOUR 2008 VALENCE - GERY DERBIER

Géry Derbier fait un carton en animant son atelier "Spécifieurs et Artistes".
Il démontre en pratique que le développement est bien un jeu coopératif d'invention et de communication.

AGILE TOUR 2008 VALENCE - PATRICE PETIT

Patrice Petit, organisateur de l'Agile Tour, présente les sponsors globaux de l'évènement.

AGILE TOUR 2008 VALENCE - COFRAMI

Nicolas Blanpain passe la parole au sponsor COFRAMI.
Bruno Morata, responsable de l'agence de Valence, explique pourquoi COFRAMI mise sur le développement logiciel agile.

AGILE TOUR 2008 VALENCE - THALES

Nicolas Blanpain passe la parole aux sponsors de l'Agile Tour.

Loïc LeGall parle au nom de THALES. L'accent est mis sur le développement logiciel agile, le Lean et de nouvelles relations entre clients et fournisseurs.

Je chronomètre la minute de temps de parole de chacun.

AGILE TOUR 2008 VALENCE - L'ACCUEIL

Jean-Pierre, Emmanuel, Marie, Nicolas et Jean-Christophe accueillent les participants.

lundi 20 octobre 2008

VERIFICATION STATIQUE ET EXTREME PROGRAMMING

Christophe Baillon de la société SOGILIS (http://sogilis.com/) m'a transféré la publication Static Verification and Extreme Programming (www.praxis-his.com/pdfs/svandxp.pdf). L'article parle notamment de l'étonnante cohabitation entre le développement de logiciels critiques et la pratique de XP.

Christophe a bien vu de me faire connaitre cette publication. En effet, cet article m'intéresse à plusieurs égards. D'abord, je développe en équipe des applications très critiques tout en appliquant une forme adaptée de l'eXtreme-Programming. Aussi, j'ai publié un article sur la criticité et XP (Agilité et Avionique) et j'ai présenté une conférence sur ce thème aux XP Days 2008 et à l'Agile Tour Grenoble 2008 (Agilité et Avionique). Enfin, lors de ma session à Grenoble, Bruno Orsier m'a interroge sur notre éventuelle utilisation des outils de vérification statique. J'aurais mieux fait de lire l'article transmis par Christophe bien avant pour mieux répondre à Bruno!

J'écris ce billet pour réagir à certaines affirmations de l'article.

Tout d'abord, l'auteur explique qu'un outil de vérification statique est en partie assimilable à un relecteur dans la pratique du pair-programming. En effet, un tel outil saura efficacement déceler certaines erreurs mieux et plus rapidement qu'un humain. Néanmoins, cette comparaison me semble se fonder sur une vision très réductrice du binômage. En effet, en plus d'une relecture en continue, la pratique du pair-programming offre un moyen efficace d'assurer la propriété collective du code et permet d'homogéneiser la conception et le code au delà des règles de nommage et de constructions élémentaires. Aussi et surtout, la conception et le code convergent vers un bon produit grâce à la confrontion de deux points de vues (et même plus, puisque le binômes permutent).

Ensuite, l'auteur montre que la vérification formelle permet de détecter des régressions introduites lors d'un remaniement. L'exemple donné est très proche d'une utilisation de la programmation par contrat, mais non compilable. Fort heureusement, depuis la sortie de l'article, AdaCore (http://www.adacore.com/home/) nous a gratifié d'un compilateur Ada2005 incluant un sous ensemble très efficace d'une véritable programmation par contrat (pré-conditions et post-conditions compilées et exercées à l'exécution). Cette nouvelle manière d'utiliser Ada n'exige même pas d'employer un sous-ensemble du langage comme la vérification statique de SPARK l'impose. Bref, la vérification formelle est sûrement un outil puissant, mais un peu moins lorsque la programmation par contrat est pratiquée.

De plus, je pense que l'auteur a tord de suggérer d'éviter de remanier pour les cas ou cela dégraderait la couverture structurelle du code par les tests. Sur nos projets nous remanions sans retenue car l'analyse de la couverture du code par les tests est automatisée dans le build complet activé par l'intégration continue. Les branches non pertinentes sont systématiquement éliminées par les développeurs ou alors les tests sont complétés. Ces pratiques permettent au code de rester malléable.

Enfin, l'auteur regrette de ne pouvoir disposer d'un client sur site. Je pense qu'il s'arrête à une vision dogmatique d'XP. Certes, l'organisation optimale prévoit un client sur site. Sur nos projets, nous n'y arrivons pas, cependant nous travaillons systématiquement avec des représentants internes du client. Il faut savoir adapter XP à son contexte sans trahir les valeurs et les principes de la démarche.

Je remercie Christophe car il m'a donné certains augments pour défendre la pratique d'XP en milieu critique. Il m'a semblé que cet article a surtout été écrit par des vendeurs d'outils qui cherchent à promouvoir leur solution dans un milieu prometteur qui n'y porte que peu d'attention. Un logiciel critique doit s'exécuter de manière sûr. je crois que je préfère porter l'effort de vérification lors de son exécution plutôt que sur une démonstration statique.
Working software is the primary measure of progress.

vendredi 10 octobre 2008

LE CHANGEMENT ET LES CONFLITS

IRRÉDUCTIBLES GAULOIS

Je travaille dans une grande organisation dont le modèle de fonctionnement n'est pas agile.
Le modèle est assez classique des grandes structures françaises qu'elles soient industrielles, administratives, militaires, scolaires ou universitaires. Il s'agit de structures pyramidales, hiérarchisées, descendantes et élitistes. Le changement y est freiné par l'inertie des grandes organisations. On y pratique la séparation de penser et de faire, tout comme dans le paradigme de la production de masse et le cycle en vie en V. Une élite pense des procédures que les d'autres doivent appliquer pour faire.

Pourtant, il existe un appétit de changement. Différentes initiatives locales cohabitent comme la mise en place de la démarche Lean et l'adoption du développement logiciel Agile. Soutenues par la hiérarchie proche, plusieurs équipes agiles y développent des produits,
tels des villages d'irréductibles gaulois.

HOUSTON, NOUS AVONS UN PROBLÈME

En ce moment, l'équipe dont je fais partie est en train de traverser une zone de turbulences. Nous sommes confrontés à des conflits à répétition avec les intervenants en périphérie de l'équipe.
Au sein même de notre équipe et avec le Product-Owner, l'ambiance est mouvementée mais dynamique, constructive et réconfortée par des résultats. Par contre, les relations se dégradent avec les acteurs qui ne sont pas directement et quotidiennement impliqués dans la construction du logiciel.

EST-CE UN CAS PARTICULIER?

Curieusement, dans les conférences auxquelles nous assistons et participons (XP Days, Agile Tour), il y a une part importante des sessions qui traitent de la gestion du conflit et de la conduite du changement. Ce que nous vivons n'est donc pas un cas isolé:
Le travail en mode agile déclenche tôt des conflits dans les organisations qui les mettent en place.
POURQUOI? A CAUSE DU CHANGEMENT!

Ces conflits naissent car les équipes auto-organisées conduisent des changements pour lesquels certaines personnes hors de l'équipe ne sont pas préparées. Les équipes agiles adaptent les standards et les meilleures pratiques du moment, elles s'organisent d'elles-même sans chef directif, elles développent des compétences nées du vrai travail d'équipe qui déstabilisent certains experts, elles sont soudées et acceptent les contraintes si elles sont comprises et non imposées par l'extérieur.
Les équipes agiles ne font pas conformément aux procédures pensées par une élite. Elle n'appliquent pas la séparation de pensée et de faire. Elles pensent ET font.
Tout changement déstabilise, mais ce changement particulier a un effet accentué dans une structure élitiste, pyramidale, hiérarchisée et descendante. Ainsi naissent les conflits entre les équipes agiles et leur entourage.

POURQUOI? PAR MALADRESSE!

Nous sommes pris par l'élan de l'équipe. Nous consacrons plus d'énergie à avancer qu'à communiquer sur notre manière de travailler. Certains se sentent exclus de cette dynamique, de cette solidarité d'équipe et ne se sentent plus respectés.
Nous sommes des techniciens passionnés, plus habiles en amélioration continue de nos pratiques de développement qu'en communication et qu'en conduite du changement.
Ainsi, il me semble qu'une organisation qui souhaite mettre en place des démarches agiles se doit d'investir dans la conduite du changement: communication, formation, sensibilisation ...

POURQUOI? PARCE QU'ON LIVRE TÔT!

Des conflits arrivent si tôt dans un projet agile qu'on entend même dire que les démarches agiles sont plus génératrices de conflits que les démarches descendantes. Est-ce vrai?

Pour analyser ce problème, faisons (encore une fois) le parallèle entre l'équipe et son produit.

Sur un projet précédant, nous avons travaillé en mode eXtreme-Programming au sein d'un programme plus large avançant en cycle en V. A l'époque, on nous a reproché de générer plus de défauts que le reste du programme. Pourquoi? Parce que nous levions les défauts plus tôt! C'est le propre des démarches agiles qui testent tôt et livrent tôt du logiciel opérationnel pour obtenir tôt des retours d'informations sur la satisfaction du client.
Pourquoi dit-on qu'une équipe agile génère plus de conflits qu'une équipe descendante? Parce qu'une équipe agile lève les conflits plus tôt!
A partir du moment où plusieurs personnes partagent un même objectif, des conflits apparaissent. Les points de vue se confrontent, tout simplement. Les conflits accompagnent les équipes.
Dans un groupe travaillant en cycle en V, il n'y a pas de vrai travail d'équipe jusqu'à la tardive phase d'intégration. D'ailleurs, l'objectif de la phase d'intégration est de réunir les travaux menés en parallèle. A partir de l'intégration, les crises apparaissent avec le travail d'équipe. Avez-vous vécu des projets en cycle en V qui ne sont pas devenus des poudrières à partir de la phase d'intégration? Et bien les projets agiles travaillent dès le début en équipe. Les conflits sont donc levés bien plus tôt.
Un conflit est à l'équipe ce qu'un défaut est au produit. Plus il est identifié tôt, plus son impact sera limité.
Pour contenir les défauts, les développeurs utilisent les tests. Si on poursuit le parallèle entre conflit et défaut, comment maitriser les conflits dans les équipes?
Les rétrospectives d'itération sont un moment où l'équipe identifie ses dysfonctionnements et se réorganise pour les corriger.
Si le conflit est à l'équipe ce que le défaut est au produit, alors la rétrospective et l'amélioration continue des pratiques est à l'équipe ce que les tests et le remaniement sont au produit.
Bref, il me semble que:
Il n'y a pas plus de défauts dans un produit développé par une équipe agile que dans un produit développé par une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les défauts plus tôt.
De même, il n'y a pas plus de conflits dans une équipe agile que dans une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les conflits plus tôt.