L’agilité est souvent mise en œuvre par les équipes, avant d’être adoptée par le management. Les premiers pas peuvent être effectués sous l’impulsion de développeurs motivés, ou de chefs de projets conscients de la force des équipes auto-organisées.

Mais rendre agile une organisation nécessite, au delà du charisme des agilitateurs – et des solutions efficaces qu’ils proposent – de former les équipes, d’abord les intervenants techniques, puis les interlocuteurs métiers. La communication ouverte et l’approche transdisciplinaire de l’agilité doivent alors être mise en place dès la genèse du projet. Mais comment former à la gestion de projets informatiques des participants de cultures techniques et professionnelles différentes ?

Le constat: rien de tel qu’une approche ludique et interactive pour mobiliser les équipes, surtout si elles sont hétérogènes et ne connaissent pas encore bien les principes de Scrum.

Une réponse: une journée d’initiation à SCRUM, animée comme un projet agile. La journée commence par un état des lieux permettant d’orienter la formation selon l’expérience des participants et les besoins métiers. Elle est ponctuée d’un ‘half-daily Scrum’ qui illustre la mêlée quotidienne et se conclue par une ‘démonstration’ maison et une rétrospective en bonne et due …

A l’instar d’un musicien qui doit pratiquer ses gammes entre deux concerts pour parfaire la maîtrise de son art, un développeur doit savoir “faire retraite” pour s’exercer à d’autres techniques et méthodologies que celles qu’il pratique quotidiennement.

C’est avec cette métaphore on-ne-peut-plus-compréhensible que les deux organisateurs, Jérémie Hattat et Adrian Bolboaca, nous ont présenté l’intérêt d’évènements tels que ce deuxième Code Retreat lillois, qui s’est déroulé samedi 14 janvier dans les locaux de Proxiad. Le programme de la journée s’est composé de :

• 6 sessions de 45 minutes de programmation en binôme sur le thème du Jeu de la Vie, chacune devant nous pousser dans l’exploration par l’introduction de nouvelles contraintes,
• Le langage d’implémentation était au choix de chaque binôme.
• Chaque session était suivie d’une rétrospective commune, à la mode Agile, durant laquelle les participants exposaient leur approche du problème, leurs difficultés et progrès.

L’idée était bien entendu de partager les connaissances et de faire évoluer chacun, sans engager personne dans quelque compétition que ce soit.

L’intérêt de savoir implémenter le Jeu de la Vie ? Aucun.

Ce sujet était simplement l’occasion d’introduire, de pratiquer et d’expliquer les avantages du Test Driven Development (TDD) ou encore du Pair Programming ; de découvrir de nouveaux outils, tels …

Lorsque l’on arrive sur un projet qui a quelques difficultés, bien souvent, l’une des premières choses à faire est le bilan du projet. Cela passe par constater et, surtout, faire constater ce qui fonctionne aux différents acteurs de l’équipe : les développeurs bien sûr (qui devraient déjà avoir une idée sur la question) mais surtout aux chefs de projet fonctionnels voire même au client, qui ne manipulent pas le projet quotidiennement et pourraient en avoir une vision tronquée. Cette action capitale permet de discuter autour d’une base réelle et connue de tous, de rassurer ceux qui imaginaient le pire et de rétablir un dialogue constructif à travers toute l’équipe.

Pour cela, déployer l’application sur un serveur accessible par toute l’équipe est une étape primordiale : ce déploiement sera le point de départ du futur travail à effectuer, la remise à zéro des compteurs.

Afin d’être réactif, le (ou les) premier déploiement pourra se faire à la main, sans mettre en place de systèmes automatisés particuliers. En revanche, il deviendra vitre nécessaire de déployer régulièrement et automatiquement l’application. Cela permettra à toute l’équipe de constater les évolutions et de faire des critiques qui seront particulièrement utiles pour repérer les écueils à venir.

Dès aujourd’hui, …

L’Elsass JUG s’est réuni le jeudi 19 Mai pour une soirée ‘Atelier Agile‘, avec Oana Juncu, scrum master et membre du board de l’Agile Tour. La soirée est à guichet fermé: le format ‘atelier’ ne permet d’accueillir que 35 personnes.

Agile c’est agile

Nous avons commencé par une présentation de quelques principes fondateurs de l’agilité, que je vous présente librement:

• le client c’est le client: l’objectif est de livrer un produit fonctionnel correspondant aux besoins. Ceci ne peut se faire que par une communication régulière avec le client du produit.
• le développeur développe: une communication régulière permet de maximiser le temps de développement efficace. De plus, seul le développeur sait quelle est la complexité des fonctionnalités à réaliser, il est donc associé pleinement à la planification du projet.
• l’heure c’est l’heure: chaque ’sprint’, c’est à dire chaque étape du projet telle que définies par Scrum, est définie par son ‘backlog‘, l’ensemble des fonctionnalités à implémenter, et par une date de livraison. Les fonctionnalités livrées peuvent être réduites, mais les délais sont toujours respectés.

• fini c’est fini: un produit livré ne doit plus être modifié. S’il est nécessaire de …

On le sait, une opération de développement ou de maintenance se décompose en deux phases : la compréhension du sujet et son implémentation.

Des études démontrent que la phase de compréhension peut prendre jusqu’à 90% du temps de l’opération !

Cette phase de compréhension est complexe et les connaissances en jeux peuvent difficilement être transmises par un tiers. La raison en est simple : chacun construit ses représentations du monde et ses cheminements cognitifs en fonction de ses expériences, de sa culture, de son entourage et des connaissances qu’il possède. Par exemple, le discours doit être adapté si l’on s’adresse à un consultant junior ou à un architecte expérimenté !

Ces dernières années, cette conviction est devenu mon cheval de bataille, et j’ai trouvé dans le développement dirigé par les tests un catalyseur pour expliciter les représentations entre les différents intervenants d’un projet.

Je cherche aujourd’hui les moyens de faire “passer le message” autour des pratiques de codage, des méthodes agiles et d’évangéliser le TDD ! Ma participation à ce blog s’inscrit dans cette logique de partage et de retour sur ces principes.

Keep the bar green !

Je me présente, Pierre Parrend, développeur Java et C++ chez ProxiAD. Mes spécialités - et passions - sont la sécurité des applications web et la qualité du logiciel.

Actuellement en mission dans l’équipe sécurité web d’une grande banque françaises, je cherche à développer à la fois la maîtrise du processus de développement et la pertinence des choix techniques, entre innovation et pragmatisme.

Passionné par la technologie, je participe également à l’animation de la communauté informatique en Alsace, en particulier par le biais de l’Elsass JUG, que j’ai contribué à initier.

L’objectif de ce blog est d’apporter des informations sur les technologies qui font l’actualité du secteur, et de partager avec vous mes expériences.

Voici comme promis hier un focus sur les thématiques que j’ai privilégiées lors de mon passage aux TechDays 2010.

En fait, je ne m’attarderai pas sur Office 2010. Cela fait maintenant 2 mois que j’utilise la version beta et cela marche plutôt bien. Sharepoint 2010 ammène également son lot de nouveautés avec en particulier un support avancé des ressources multimédia (videos notamment). Mais je m’écarte de mon sujet.

Il y a vraiment deux sujets que je veux mettre en valeur cette année.

Même pour un œil peu averti, il apparait évident que Microsoft continue son rapprochement vers les autres plateformes de développement. Ainsi n’ai je pas été le seul à relever hier les nombreuses références à PHP et à Java.

C’est d’abord avec le support souligné de PHP et Java sur Windows Azure dès la plénière du matin que le sujet est venu sur le tapis. Puis, dans l’après midi, une session, notamment, dédiée à l’industrialisation en environnements de développement hétérogènes a confirmé la tendance.

L’événement significatif en ce sens est le rachat par Microsoft fin 2009 de Teamprise de SourceGear. Teamprise est une suite d’outils qui permet à …

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Il va de soit que les tests représentent un gage de qualité pour un projet. Leur adoption dépend à mon avis de deux aspects :

• une bonne méthodologie ;
• une infrastructure adaptée.

Si les méthodes agiles et le TDD représentent un facteur de motivation, il serait dommage de ne pas les mettre en œuvre. Si ce n’est pas le cas, ou que le projet ne s’y prête pas, l’important à mon sens est de créer un besoin. L’un des aspects essentiels du développement assisté par les tests est de fournir un maximum de confort et de possibilités aux développeurs, afin de faire du test unitaire un outil de développement apprécié et indispensable.

Quelque soit la solution choisie, sa pérennité dépend fortement de la mise en place de l’infrastructure et de l’outillage nécessaires. L’intégration continue, notamment, est capitale.

Enfin, une solution de tests fonctionnels complètera efficacement l’une ou l’autre des méthodes citées.

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Gestion des données

Pour résumer, l’objectif est ici de placer la BDD dans un état prédéfini avant le test, de façon automatique, afin d’assurer sa reproductibilité. De plus, cette initialisation doit se faire :

• de façon suffisamment rapide pour que la durée d’exécution des tests ne devienne pas une contrainte ;
• de façon suffisamment souple pour injecter facilement toutes sortes de données. En outre, une méthode d’insertion dynamique permettra par exemple de créer des listes volumineuses pour tester un composant de pagination ou de tri.

Les tests contextuels nécessitent des jeux de données plus conséquents que les tests en isolation. Malgré tout, il est important que ceux-ci restent suffisamment légers pour conserver des performances acceptables.

Pour organiser ces jeux de données de façon optimale, nous distinguerons :

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

En pratique, que l’on choisisse le TDD ou une autre méthodologie, la complexité majeure de mise en œuvre réside dans la gestion des données de tests. La problématique consiste à placer la base de données dans un état prédéfini, avant l’exécution de chaque test, de façon automatique.

Par ailleurs, la politique de gestion des données est déterminante pour choisir les outils appropriés.

En TDD, les tests unitaires sont réalisés en pure isolation. C’est-à-dire que chaque fonction est testée en l’isolant de son contexte d’exécution afin d’éviter toute interférence externe qui risquerait de compromettre le résultat du test. C’est pour cela que les implémentations “mock” comme EasyMock ou Mockito (Mockito in six easy examples) sont très utilisées en TDD. L’isolation réduit aussi considérablement le volume de données de tests à gérer. Des outils comme DBUnit et SpringUnit, qui permettent de spécifier en XML les données attendues …