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.

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.

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.

AGILE TOUR 2008 - VALENCE

Ce qui devait être un petit évènement pour tout au plus une cinquantaine de personnes est en voie de devenir une grande date avec 120 inscrits pour le moment!

Le programme de l'Agile Tour est désormais établi et consultable ici. Conférences, ateliers, débats et échanges autour d'un buffet sont au programme de cette demi-journée.

De grands conférenciers nationaux nous font l'honneur de nous présenter des sujets, tels que Régis Médina, Gery Derbier et Alexandre Boutin.

Vu le nombre d'inscris, il semble que l'Agile Tour réponde bien à un besoin. Par contre, je ne sais affirmer de quel besoin il s'agit.

• Est-ce un besoin de recherche d'information sur les méthodes Agiles?
• Est-ce un besoin de lever le nez du guidon et d'assister à des conférences pour élargir son horizon?
• Est-ce un besoin de se rencontrer et d'échanger entre professionnels du développement logiciel?
• Y aurait-il eu autant d'inscriptions avec un autre thème?

Nous tâcherons de répondre à ces questions ce 23 octobre à l'ESISAR. A très bientôt!

AGILE RETROSPECTIVES: MAKING GOOD TEAMS GREAT, par Esther Derby et Diana Larsen

Dans notre équipe, nous conduisons une réunion de rétrospective d'itération par mois, le dernier jour du sprint.
Je trouve que ces réunions ne sont pas évidentes à mener. Comment garder les participants concentrés? Comment amener chaque équipier à s'exprimer? Il faudrait que chaque participant ait le sentiment que le temps qu'il a accordé à la rétrospective serve l'équipe et le projet. Comment assurer ce retour ce investissement?

Je suis un grand fan de la collection Pragmatic Bookshelf. Les ouvrages My Job Went To India, Practices Of An Agile Developer, Pragmatic Project Automation, Ship It, et The Pragmatic Programmer m'ont beaucoup aidé à améliorer mes pratiques de développement ainsi que celles de l'équipe.

Alors, quand j'ai vu que la collection proposait un ouvrage sur la conduite des rétrospectives, je m'en suis procuré un exemplaire. J'attendais beaucoup de la lecture de ce livre d'autant plus que nous planifions une grande rétrospective de version en équipe élargie.

Et bien, sur plus d'une vingtaine de livres sur le génie logiciel, c'est la deuxième fois que je suis très déçu ...
Certes, le livre indique clairement et utilement quels sont les objectifs et les différents temps d'une rétrospective. Les auteurs donnent de très bons conseils sur la manière de préparer et conduire la réunion.
Malheureusement, la grande majorité du livre est un catalogue d'outils à utiliser en rétrospective. Ce devrait être une bonne chose - sauf que je ne vois pas notre équipe (pourtant TRES ouverte et innovante) en appliquer plus de deux ou trois. Il s'agit d'exercices très (trop?) anglo-saxons pour nous autres du vieux continent. Ces séances de travail en binômes, ces prises de paroles de type Alcooliques Anonymes et ces exercices proches de la psychothérapie de groupe ne me semblent pas (encore?) adaptés à notre approche du travail d'équipe.
Peut-être nous ne sommes pas assez ouverts? Peut-être nous prenons-nous trop au sérieux? Peut-être avons nous du mal à reconnaître la part des sentiments dans la vie professionnelle? Peut-être nous ne sommes pas encore prêts?

Toujours est-il que je ne recommande pas ce livre ...
Au prochain!

EQUIPE VERSUS GROUPE