Scrum et XP depuis les Tranchées

Comment nous appliquons Scrum

13. Comment nous combinons Scrum avec XP▲

Dire que Scrum et XP (eXtreme Programming) peuvent être combinés avec profit n'est pas une déclaration réellement sujette à controverse. La plupart des choses que je vois sur le net sont en faveur de cette hypothèse, donc je ne vais pas passer de temps à argumenter pourquoi.

Tout de même, je vais mentionner une chose. Scrum se concentre sur le management et les pratiques d'organisation tandis que XP se concentre surtout sur les pratiques de programmation concrètes. C'est pour ça qu'ils fonctionnent bien ensemble - ils concernent différentes zones et sont complémentaires.

Je déclare donc formellement que j'ajoute ma voix aux preuves empiriques déjà existantes que Scrum et XP peuvent être combinés de manière productive !

Je vais souligner certaines des pratiques XP les plus intéressantes, et comment elles s'appliquent à notre travail de tous les jours. Toutes nos équipes n'ont pas réussi à adopter toutes les pratiques, mais au total nous avons expérimenté la plupart des aspects de la combinaison XP/Scrum. Certaines pratiques XP sont directement prises en compte par Scrum et peuvent être vues comme du recouvrement, par exemple « Toute l'équipe », « S'asseoir ensemble », « Histoires » et « Jeu du planning ». Dans ces cas nous nous en sommes simplement tenus à Scrum.

13-1. La programmation en binôme▲

Nous avons commencé cela récemment dans une de nos équipes. Ca a plutôt bien fonctionné en fait. La plupart de nos autres équipes ne travaillent toujours pas beaucoup en duo, mais après l'avoir réellement essayé avec une équipe pendant maintenant plusieurs sprints, je suis motivé pour essayer d'entraîner plus d'équipes à faire l'essai.

Quelques conclusions pour l'instant sur la programmation en binôme :

La programmation en binôme améliore la qualité du code.
La programmation en binôme améliore la focalisation de l'équipe (par exemple quand le gars derrière vous dit « hé est-ce que ce truc est vraiment nécessaire pour ce sprint ? »).
Curieusement beaucoup de développeurs qui sont fortement opposés à la programmation en binôme ne l'ont pas réellement essayée, et apprennent rapidement à l'apprécier une fois qu'ils l'essayent.
La programmation en binôme est épuisante et ne devrait pas être pratiquée toute la journée.
Faire tourner fréquemment les duos est bénéfique.
La programmation en binôme améliore la diffusion des connaissances dans le groupe. De façon étonnamment rapide.
Quelques personnes ne sont simplement pas à l'aise avec la programmation en binôme. Ne jetez pas un excellent programmeur juste parce qu'il n'est pas à l'aise avec la programmation en binôme.
Les revues de code sont une alternative acceptable à la programmation en binôme.
Le « copilote » (le type qui n'utilise pas le clavier) devrait également avoir un ordinateur à lui. Pas pour le développement, mais pour de petites activités quand c'est nécessaire, pour parcourir la documentation quand le « pilote » (le type au clavier) est bloqué, etc.
N'imposez pas la programmation en binôme aux gens. Encouragez-les et fournissez les bons outils mais laissez-les expérimenter à leur propre rythme.

13-2. Le Développement Dirigé par les Tests (DDT)▲

Amen ! Ceci, pour moi, est plus important que Scrum et XP tous les deux. Vous pouvez prendre ma maison et ma télé et mon chien, mais n'essayez pas de m'empêcher de faire du DDT ! Si vous n'aimez pas le DDT alors ne me laissez pas entrer dans votre bâtiment, parce que je vais essayer d'en introduire d'une manière ou d'une autre :o)

Voici un résumé du DDT en 10 secondes :

Le développement dirigé par les tests signifie que vous écrivez un test automatisé, puis vous écrivez juste assez de code pour faire passer ce test, puis vous remaniez le code principalement pour améliorer la lisibilité et supprimer les duplications. Rincez et recommencez.

Quelques réflexions sur le développement dirigé par les tests.

Le DDT est difficile. Cela prend du temps à un programmeur pour voir la lumière. En fait, dans beaucoup de cas, le temps que vous passez à former et à démontrer n'a pas réellement beaucoup d'importance - dans beaucoup de cas la seule manière pour un programmeur de voir la lumière est de le faire programmer en duo avec quelqu'un de vraiment bon en DDT. Une fois qu'un programmeur voit la lumière, cependant, il sera en principe gravement infecté et ne voudra jamais plus travailler d'une autre manière.
Le DDT a un effet profondément positif sur la conception du système.
Cela prend du temps pour avoir du DDT parfaitement au point dans un nouveau produit, surtout des tests d'intégration en boite noire, mais le retour sur investissement est rapide.
Assurez-vous d'investir le temps nécessaire pour que ce soit facile d'écrire des tests. Cela signifie obtenir les bons outils, éduquer les gens, fournir des classes utilitaires ou des classes de base appropriées, etc.

Nous utilisons les outils suivants pour le développement dirigé par les tests :

jUnit / httpUnit / jWebUnit. Nous envisageons TestNG et Selenium.
HSQLDB en tant que BD embarquée en mémoire pour les tests.
Jetty en tant que container web embarqué en mémoire pour les tests.
Cobertura pour les métriques de couverture de test.
Spring pour câbler différents types de montages de test (avec mocks, sans mocks, avec base de données externe, avec base de données en mémoire, etc).

Dans nos produits les plus sophistiqués (du point de vue du DDT) nous avons des tests d'acceptation automatisés de type boîte noire. Ces tests démarrent le système complet en mémoire, y compris les bases de données et les serveurs web, et accèdent au système en utilisant uniquement ses interfaces publiques (par exemple HTTP).

Cela permet des cycles développement-construction-test extrêmement rapides. Cela agit également comme un filet de sécurité, donnant suffisamment de confiance aux développeurs pour remanier (refactor) souvent, ce qui signifie que la conception reste propre et simple même quand le système grandit.

13-2-1. Le DDT sur du nouveau code▲

Nous pratiquons le DDT pour tous les nouveaux développements, même si cela signifie que la mise en place initiale du projet prend plus de temps (puisqu'il nous faut plus d'outils et de support pour les harnais de test, etc). Il n'y a pas vraiment de question à se poser, les bénéfices sont tellement importants qu'il n'y a vraiment pas d'excuse pour ne pas faire du DDT.

13-2-2. Le DDT sur du vieux code▲

Le DDT est difficile, mais faire du DDT sur une base de code qui n'a pas été construite avec du DDT dès le début... ça c'est vraiment difficile ! Pourquoi ? Eh bien, en fait, je pourrais écrire beaucoup de pages sur ce sujet, alors je pense que je vais m'arrêter ici. Je garde cela pour mon prochain papier « le DDT depuis les tranchées » :o)

Nous avons passé pas mal de temps à essayer d'automatiser les tests d'intégration de l'un de nos systèmes les plus complexes, une base de code qui existe depuis un moment et qui était dans un état de pagaille extrême et était complètement dépourvue de tests.

A chaque release du système nous avions une équipe de testeurs dédiés qui réalisaient un lot complet de tests de régression et de performance. Les tests de régression étaient essentiellement manuels. Ceci ralentissait notablement notre cycle de développement et release. Notre but était d'automatiser ces tests. Après nous être cogné la tête contre le mur pendant plusieurs mois, toutefois, nous n'avons pas beaucoup avancé.

Après ça nous avons changé d'approche. Nous avons accepté le fait que nous étions obligés de vivre avec du test de régression manuel, et nous avons plutôt commencé à nous demander « comment pouvons-nous rendre le processus de test manuel moins consommateur de temps ? » C'était un système de jeu, et nous avons réalisé qu'une bonne partie du temps de l'équipe de test était consacrée à des tâches de mise en place assez triviales, comme bricoler dans le back office pour mettre en place des tournois pour le test, ou attendre qu'un tournoi planifié démarre. Donc nous avons créé des utilitaires pour cela. Des raccourcis et des scripts petits, facilement accessibles qui font tout le travail de base et permettent aux testeurs de se concentrer sur le véritable test.

Cet effort a vraiment été rentable ! En fait, c'est probablement ce que nous aurions dû faire au départ. Nous étions tellement impatients d'automatiser le test que nous avons oublié de le faire étape par étape, la première étape étant de construire des choses qui rendent le test manuel plus efficace.

Leçon tirée : si vous êtes coincés avec du test de régression manuel, et voulez vous en débarrasser en l'automatisant, ne l'automatisez pas (à moins que ce soit vraiment facile). A la place, construisez des choses qui rendent le test de régression manuel plus facile. Ensuite, considérez l'automatisation du véritable test.

13-3. La conception incrémentale▲

Cela signifie garder la conception simple au départ et l'améliorer continuellement, plutôt qu'essayer de tout faire parfaitement dès le départ et ensuite tout geler.

Nous sommes plutôt bons à ça, c'est-à-dire que nous passons un temps raisonnable à remanier et améliorer la conception existante, et que nous passons rarement du temps à faire de grandes conceptions à l'avance. Quelques fois nous échouons bien sûr, par exemple en permettant à une conception branlante de s'implanter trop fortement, si bien que le remaniement devient un gros projet. Mais tout bien considéré nous sommes raisonnablement satisfaits.

L'amélioration continue de la conception est principalement un effet de bord automatique du DDT.

13-4. L'intégration continue▲

La plupart de nos produits ont un système d'intégration continue plutôt sophistiqué, basé sur Maven et QuickBuild. Cela est très efficace et fait économiser du temps. C'est la solution ultime au bon vieux problème « hé mais ça marche sur ma machine ». Notre serveur de build en continu sert de « juge » ou point de référence à partir duquel on peut déterminer la santé de toutes nos bases de code.

Chaque fois que quelqu'un enregistre quelque chose dans le système de gestion de version, le serveur de build en continu reconstruit tout à partir de zéro sur un serveur partagé, et exécute tous les tests. Si quelque chose ne va pas il envoie un email notifiant toute l'équipe que le build a échoué, en indiquant quel changement dans le code a cassé le build, des liens sur les rapports de test, etc.

Chaque nuit le serveur de build en continu va reconstruire le produit à partir de zéro et va publier les binaires (fichiers de type .EAR, .WAR, etc.), la documentation, les rapports de test, les rapports de couverture de test, les rapports de dépendance, etc, sur notre portail interne de documentation. Certains produits vont aussi être déployés automatiquement sur un environnement de test.

Mettre en place tout cela a représenté beaucoup de travail, mais chaque minute passée en valait la peine.

13-5. La propriété collective du code▲

Nous encourageons la propriété collective du code mais toutes les équipes ne l'ont pas encore adoptée. Nous avons découvert que la programmation en binôme avec rotations fréquentes des duos conduit automatiquement à un niveau élevé de propriété collective du code. Les équipes avec ce niveau élevé de propriété collective ont prouvé qu'elles étaient très robustes, par exemple leur sprint ne meurt pas juste parce qu'une personne clé est malade.

13-6. Un espace de travail informatif▲

Toutes les équipes ont accès à des tableaux blancs et de l'espace sur des murs vides, et en font un assez bon usage. Dans la plupart des pièces vous trouverez les murs couverts de toutes sortes d'informations sur le produit et le projet. Le plus gros problème est les vieux déchets qui s'accumulent sur les murs, il faudra peut-être introduire un rôle de « nettoyeur » dans chaque équipe.

Nous encourageons l'utilisation de tableaux de tâches, mais toutes les équipes ne les ont pas encore adoptés. Voir page 68 « comment nous organisons le bureau de l'équipe. »

13-7. Les normes de codage▲

Récemment nous avons commencé à définir des normes de codage. Très utiles, nous aurions dû le faire plus tôt. Cela ne prend presque pas de temps du tout, il faut juste commencer simple et les laisser se développer. Ecrivez juste les choses qui ne sont pas évidentes pour tout le monde et reliez-les à des supports existants chaque fois que c'est possible.

La plupart des programmeurs ont leur propre style de codage bien distinct. De petits détails comme comment ils gèrent les exceptions, comment ils commentent le code, quand ils retournent null, etc. Dans certains cas la différence n'a pas d'importance, dans d'autres cas elle peut conduire à une conception système gravement incohérente et du code très difficile à lire. Des normes de codage sont très utiles dans ce cas, du moins tant que vous vous concentrez sur les choses qui importent.

Voici quelques exemples de nos normes :

Vous pouvez violer n'importe laquelle de ces règles, mais assurez-vous qu'il y a une bonne raison et documentez-là.
Utilisez les conventions de codage de Sun par défaut : http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Ne jamais, jamais, jamais, attraper des exceptions sans les relancer ou enregistrer la pile d'appel dans un journal. log.debug() c'est bien, mais simplement ne perdez pas cette pile d'appel.
Utilisez l'injection de dépendances basée sur les accesseurs pour découpler les classes les unes des autres (sauf bien sûr quand un couplage fort est désiré).
Evitez les abréviations. Les abréviations bien connues comme ADO sont acceptables.
Les méthodes qui retournent des collections ou des tableaux ne devraient pas retourner null. Retournez des collections et des tableaux vides à la place de null.

13-8. Le rythme soutenable / le travail énergisé▲

Beaucoup de livres sur le développement logiciel agile prétendent que le dépassement des horaires est contre-productif dans le développement logiciel.

Après quelques expériences non désirées sur la question, je ne peux qu'être d'accord de tout coeur !

Il y a à peu près un an une de nos équipes (la plus grosse) faisait une quantité démente d'heures supplémentaires. La qualité de la base de code existante était déprimante et ils devaient passer la plupart de leur temps à éteindre les incendies. L'équipe de test (qui faisait aussi des heures supplémentaires) n'avait aucune chance de faire sérieusement le travail d'assurance qualité. Nos utilisateurs étaient mécontents et les tabloïdes nous mangeaient vivants.

Après quelques mois nous avons réussi à ramener le nombre d'heures à des niveaux décents. Les gens travaillent le nombre normal d'heures (sauf quelquefois dans des situations critiques). Et, surprise, la productivité et la qualité se sont améliorées de manière notable.

Bien sûr, la réduction des heures de travail n'a été en aucune manière le seul aspect ayant conduit à cette amélioration, mais nous sommes tous convaincus qu'elle a joué un grand rôle.