D’abord celui de l’équipe, expérimenter et améliorer… Les rétrospectives sont là pour ça, l’amélioration continue est une des garanties de la performance dans un projet.

Mais au finale qu’elle est notre désir et ce qui pousse à adopter de nouvelle méthode ? La valeur, la motivation, la productive et la qualité. Pour que l’agilité ne reste pas qu’une promesse, il faut se fixer des objectifs élevées et les suivre.

Pour commencer, je voudrais juste dire de ce qu’est l’agilité pour moi et ce que ça représente. L’agilité est un ensemble de pratiques et de principes (cf manifeste agile) qu’on applique de manière pragmatique afin d’atteindre les objectifs projet, ce n’est pas une méthode miracle qui s’utilise de la même manière quelques soit le projet. Scrum par exemple est un Framework qui permet de donner un cadre à l’équipe de développement sans apporter de réponse quand à la phase de spécification et d’analyse. Mais ceci ne veux pas dire qu’elles ne sont pas utiles ou qu’elles n’ont pas de sens c’est juste que Scrum ne donne pas les outils pour le faire. L’agilité nous pousse à trouver des solutions à nos problèmes pour lesquels encore une fois il n’existe pas de solution miracle et pour ce faire on part du minimum, on part donc d’un processus léger (cf Scrum ou encore plus frappant avec Kanban) et on doit utiliser d’autres pratiques sans les imposer pour répondre aux éventuels problématique dans un projet cf Scrum et XP tirer les meilleurs des deux ou encore Scrum et CMMI… Le culte d’une méthode n’a plus beaucoup de sens aujourd’hui, c’est pour cette raison qu’il faut cesser de suivre aveuglement les différentes modes et tirer le meilleur de ce qui existe pour la bonne conduite de nos projets.
Donc non, agile ne veut pas dire manque de prédictibilité ou encore de documentation ou d’analyse, bien au contraire si le projet le nécessite.

La valeur

Produire de la valeur, obtenir de la valeur le plus rapidement possible, revient à développer les éléments les plus prioritaires et ceux apportant le plus de valeur tout en constituant un ensemble cohérent et livrable, à valider le plus tôt et livrer aussitôt. Il est bien question ici de Time To market.
Alors entendre dire que dans l’agilité il n’y a pas de place à l’analyse est pour moi un non sens totale, comment penser qu’on peut constituer une première liste d’éléments pour la première version du produit sans faire un énorme travail d’analyse ? Alors oui, il faut définir une liste de fonctionnalité, les priorisés, définir un plan de release (valider avec l’ensemble de l’équipe projet), être sûre que ce premier plan contient une liste cohérente et suffisante pour avoir un produit exploitable, apportant une valeur, avec l’ensemble des critères d’acceptation associés. Non seulement il y a une phase d’analyse mais en plus elle est faite à chaque incrément du produit. Voici un des défis de l’agilité, à savoir recueillir le besoin, l’exprimer et passer en production le plus rapidement possible.

La productivité

La productivité d’une équipe est étroitement lié à la quantité de valeur que l’équipe produit pendant un sprint/release livré en production. Plus l’équipe est productive, moins elle met de temps à pousser des fonctionnalité en production (donc raccourcir et améliorer les processus de livraisons) avec des fonctionnalités qui répondent au besoin de l’utilisateur/client, l’implication ici du métier dans l’équipe est vitale et la notion de test automatisé est primordiale, voir Test Driven Requierment (TDR)/Behavior Driven Development (BDD). Le test est le seul garant d’un Refactoring sans casse et le Refactoring est la seul garant d’une productivité qui ne baisse pas avec le temps.

La motivation

Une équipe productive est une équipe motivé, l’agilité a besoin d’individu motivé, investi et moteur. Une des valeurs de l’agilité est de donner de l’autonomie à l’équipe, ce qui donne le champs libre à l’épanouissement personnel et avec des individus épanouis on forme des équipes performantes. Si en plus de la motivation l’accomplissement ou le désir de l’excellence fait partie des attentes des développeurs, nous avons alors une équipe qui innovera, se souciera de la qualité et proposera des solutions d’améliorations.

Voici une excellente vidéo sur le sujet : http://www.youtube.com/watch?v=u6XAPnuFjJc

La qualité

Faire de la qualité pour de la qualité n’est pas une quête en soit, par contre faire de la qualité pour maintenir un niveau de production malgré une quantité de code grandissante est essentiel. Il faut chercher continuellement à rendre le code évolutif et facile à maintenir, en limitant les régressions avec une bonne couverture en test et une architecture/design facile à enrichir, l’ajout d’une nouvelle fonctionnalitée avec un impacte minimale sur le code existant permet d’éviter le code spaghetti.

Voici quelques facteurs importants pour garantir une productivité qui dure

Article précédent, Vers la production agile : Construire une usine logicielle .NET efficace

Comme pour tout problème non trivial, il existe une multitude de solutions, d’ailleurs il n y a pas longtemps une liste des solutions possibles a été donnée dans un des blogs de developpez :

http://blog.developpez.com/nico-pyright/p8194/c/tests-unitaires-comment-tester-sa-couche/

Pour moi la base de donnée fait partie intégrante du système et pour cette raison je ne conçois pas des test indépendant de la base (en tout cas en ce qui concerne la DAL), quitte à rendre cette partie de mes test moins unitaires.
Et la meilleure façon de tester en évitant les surprises est de tester dans des conditions proches de l’environnement de production. Mais ceci pose un problème majeur, comment peut on garantir le même résultat pour plusieurs exécutions ?

Pour remédier à cela, il existe des Frameworks qui permettent de faire certaines choses (DBunit …), initialiser les données avant de lancer les tests, par exemple.
Mais de toutes les approches, je préfère celle qui manipule directement le contenu de la base sans altérer son contenu, évitant par ailleurs le télescopage entre plusieurs test.

Certains Frameworks permettent l’utilisation de l’attribut Rollback, Nunit permet de le faire mais seulement avec une extension (xtUnit pour qui ça intéresse), l’autre solution serait d’utiliser TransactionScope :

Pour exécuter un tel test il faut :

– Référencer System.transactions
– Avoir une entité Customer
– Une class d’accès customerDAL ayant une méthode InsertCustomer qui retourne le nombre de lignes affectées.

Autre scénario

Voici un scénario pas forcément très unitaire, mais qui permet de tester efficacement une mise à jour, à condition que l’insertion et la sélection soit bien tester également.
La condition de l’utilisation de TransactionScope ici est que la IDBConnection soit partager entre les différentes méthodes appelées de la DAL.

Donc pour conclure ma solution n’est pas forcément un Test Unitaire, mais pour l’instant c’est la seule qui m’est vraiment convaincu

http://rad-hass.developpez.com/tutoriels/conception/route-vers-agilite-scrum-et-xp-retour-experience/

Cet article, revient sur ma transformation agile, mais aussi la transformation agile de mon équipe. La pratique de l’agilité m’a permis d’améliorer mon quotidien, mais aussi la qualité de mes développements, refactoring, test, amélioration continue, participation du client… Sont quelques clés de cette transformation.

Cette expérience, m’a donné la possibilité de voir les bénéfices de l’agilité, mais aussi les difficultés lié aux changements.

Au delà des pratiques, l’agilité constitue un ensemble de principes qui sont parfois heurté à des réticences, liées aux mentalités. La transparence, l’absence de hiérarchie forte dans une équipe sont parfois perçu comme des menaces pour les individus. Et l’organisation des équipes avec la présence d’un représentant client, peuvent être un défi compte tenu des hiérarchisations de certaines grandes structures.
Dans le vaste domaine qu’est la conduite du changement, on parle parfois de résistance naturel, le changement doit être progressif, il faut convaincre et accompagné.

Dans les premières étapes de l’introduction de l’agilité dans une équipe, la dynamique que peut apporter une nouvelle pratique apporte un effet levier indispensable au démarrage, mais ceci n’a qu’une durée limitée et tant que l’ensemble de l’entreprise ne pratique pas et adhère pas à ces principes, la courbe de progression risque de stagner, voir régresser. Car tant que la MOA sera MOA et toujours aussi loin de l’équipe MOE, le bénéfice totale de l’agilité ne se fera pas, sans parler des équipes de productions qui sont parfois totalement indépendantes des équipes projets.

Et à ce propos on voit beaucoup de livre et de conférence à ce sujet, prochainement Valtech organise un afterwork (à Paris) sur cette thématique le 13 Octobre, après cela vous pouvez retrouver des sessions sur l’agilité et la transformation agile en particulier dans l’Agile Tour 2010 prévu le 28 Octobre.

Dont’s worry, we aren’t saying that people shouldn’t write comments. In our olfactory analogy, comments aren’t a bad smell; indeed they are a sweet smell. the reason we mention comments here is that comments often are used as a deodorant. It’s suprising how often you look at thickly commented code and notice that the comments are the because the code is bad.

Comments lead us to bad code that has all the rotten whiff’s we’ve discussed in the rest of this chapter. Our first action is to remove bad smells by refactoring. Wehn we’re finished, we often find that the comments are superfluous.

If you need a comment to explain what a block of code does, try extract method. If the method is already extracted but you still need a comment to explain what it does, use rename method. if you need to state some rules about the required state of system, use introduce assertion.

When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.

A good time to use a comment is when you don’t know what to do. In addition to describing what is going on, comments can indicate areas in which you aren’t sure. A comment is a good place to say why you did something. This kind of information helps future modifiers, especially forgetful ones.

Extrait de « Refactoring: improving the design of existing code »

L’idée est que certains commentaires sont utilisés comme du déodorant pour masquer les mauvaises odeurs, alors avant de commenter voyez si votre code ne peut pas être amélioré, Refactoring Inside. Un commentaire superflue, nuit plus qu’il ne contribue, alors essayer d’extraire le code à commenter, si c’est déjà fait renommer la méthode pour rendre plus explicite ce qu’elle fait…

Après avoir fait le tour de la question, je suis revenu à la solution d’automatisation la plus simple : Excel.

D’abord l’étape exploration d’outils :

Parmi la multitude d’outils disponibles deux avaient retenu particulièrement mon attention d’abord GreenHopper un plugin pour Jira (l’outil utilisé chez mon client) et IceScrum.
Pour mon expérimentation j’ai choisi IceScrum, qui avait l’avantage d’être totalement gratuit et les graphiques proposées sont plutôt réussi. Ayant déjà un environnement de travail Scrum (mur blanc, backlog de produit …), j’ai voulu utiliser IceScrum comme complément, solution peu évidente puisque l’utilisation partiel des fonctionnalités désirées était impossible. Mais séduit par l’outil et par le panel de fonctionnalités, j’ai convaincu mon équipe de l’expérimenter comme outil principale … Solution vite abandonnée (au bout de 3 sprints) tant l’adoption de l’outil fut un échec, quelques éléments de l’échec ont été sa complexité (peut être il aurait fallu mieux former), des lourdeurs … Au finale une utilisation beaucoup moins instinctive et automatisable que l’est le mur blanc

Ensuite les templates excels :

Souvent payant (chose qui m’a beaucoup étonné), parfois gratuit, les modèles trouvés m’ont souvent frappés par leurs complexités … Ne répondant pas à mon besoin assez simpliste du départ.

Après ces explorations forts enrichissantes des outils Agiles utilisés, je me suis rendu compte que je m’éloignai de mon besoin initial et que les solutions proposées ne répondait pas à mon besoin le plus agilement possible, alors je suis reparti d’une simple feuille excel qui me génère juste ce dont j’ai besoin. Et oui j’ai réinventé la roue, et si c’est le prix à payer pour ne pas devenir esclave d’un outil ?

Et à ses préoccupations, il y a deux sujets d’actualités qui ont le vent en poupe d’une part le Cloud Computing, désigné comme étant la prochaine évolution majeure du Web et d’autres part l’Agile Testing (les tests agiles). Comme le démontre la récente étude réaliser par Capgemini et Sogeti World Quality Report.

Cloud Computing

Le Cloud Computing répond aux multiples besoins d’externalisation, mobilité, délocalisation et dématérialisation … Des études vont mêmes jusqu’à affirmer qu’une entreprise sur trois sera dans les nuages d’ici 2012, on comprend aisément alors les investissements consentis par les acteurs majeurs de l’informatique. Google a eu un grand succès avec Google Apps qui représentent une des applications les plus réussis du Cloud Computing, rendant même l’utilisation offline possible.

Mais les critiques n’ont pas épargné ce modèle, autre le fait que les utilisateurs perdent le contrôle de leurs applications, d’autres voient en lui un simple phénomène de mode, gonflé à grand coup de marketing.

Alors solution miracle ou écran de fumer ? La vérité est probablement entres les deux.

Agile Testing

Le besoin est simple avoir des logiciels qui marchent le plus tôt possible, pour avoir un retour rapide sur investissement.
Alors la réponse est de tester le plus rapidement et le plus souvent, pour d’une part avoir un logiciel qui fonctionne et qui continue à fonctionner. Car au delà du fait qu’un logicielle répondent aux exigences à l’instant T, les régressions et la maintenance restent des grands consommateurs de coût dans la vie d’un produit.

Ainsi les méthodes agiles deviennent une solution séduisante pour améliorer les délais de mises à disposition des applications, ainsi que l’augmentation de la qualité des livrables.
Et pour rendre vos tests plus efficaces, il faut les exécuter très tôt dans le processus de développement (Test Driven Development) et continuer à les exécuter continuellement (Intégration continue). Et pour aller plus loin, il y a la possibilité d’avoir des spécifications fonctionnel exécutable (Test Driven Requirement ou encore Dehavior Behaviour-Driven Development), spécifier l’application en scénario de test et les traduire en test fonctionnel, garantis que l’application non seulement fonctionne mais qu’elle répond aux bons besoins. Et le fait que l’exécution soit automatisé rend cet outil redoutable quand à la détection des régressions.

Il existe une multitude de méthodologie permettant d’améliorer votre organisation, mais il est souvent difficile de garder l’effet levier de productivité, une fois que l’euphorie de la découverte et la motivation initiale ne soit dissipé.

C’est pour cette raison que la simplicité de la méthodologie de travail a une importance primordiale.

Pour ma part, travaillant dans un cadre Scrum, nous avons des rituels quotidien permettant d’orchestrer notre rythme de travail, la mêlée quotidienne en est une, dans laquelle chaque membre répond aux trois questions : Ce que j’ai fais la veille ? Ce que je fais aujourd’hui ? Et les problèmes rencontrer ? Pour avoir une visibilité quotidienne sur le travail effectué, nous veillons à faire un découpage en tâche le facilitant.

Reste que ceci ne nous permet pas d’entrer dans le détail du programme journalier … Nous avons mis en place sans appliquer de réelles méthodologies, un travail d’énumération des tâches à faire dans la journée. Mais à ceci il a manqué une vraie rigueur d’une méthodologie permettant de mieux respecter le plan initial.

C’est à ce moment que je me suis intéresser aux méthodologies existantes et pour ceci je m’étais intéressé à deux d’entre elles, qui revenaient souvent dans les communautés agiles ; Getting Things Done (GTD) et Pomodoro.

Ces deux méthodes, essai d’inculquer une discipline, un processus continue de priorisation des tâches courantes et la réalisation d’une et une seul tâche en s’y consacrant pleinement.

Pour ma part c’est la seconde qui a le plus retenu mon attention, d’une grande facilité d’application, Pomodoro m’a permis de mieux structurer mon travail journalier et d’augmenter mon facteur de focalisation. Il n y a pas de magie, c’est surtout une gymnastique souvent difficile à respecter, mais qu’il faut appliquer le plus rigoureusement possible, pour espérer voir des résultats positifs sur la longue.

Des itérations successives de 25mn (pomodori) pour réaliser ses tâches, le plan de travail est le suivant :

– Découpage en tâches du travail à faire pour la journée.
– Priorisation.
– Estimer les tâches en pomodori.
– Faire 4 pomodori de 25mn séparer d’environ 5mn de pause.
– Au bout de 4 pomodori, prendre une longue pause d’environ 15 à 30mn.

Pendant un pomodori on s’engage à faire une seul tâche, on se focalise pleinement sur celle-ci, le fait de n’avoir que 25mn pour le faire aide beaucoup à augmenter le focus sur la tâche, surtout que toute autre distraction ou courte tâche (mail, téléphone …) peuvent probablement attendre la pause de 5mn …

Autres bénéfices

– On ne peut pas être concentré pleinement sur une très longue période, donc ces cycles avec des pauses régulières permettent une concentration accrue sur les tâches. Et se traduit sur la journée souvent avec un meilleur rendement.
– Ne plus courir derrière le temps, cette méthode permet d’avoir une meilleure visibilité sur le temps qui passe, on maîtrise en détail le temps passé et le temps restant sur nos tâches.
– On renonce à l’idée qu’on peut tout faire en même temps, car ceci est le plus grand facteur de stress et au finale d’une productivité effective largement inférieur aux efforts consentis.

Et vous ? Comment vous organisez vous ?

Quelques liens :

http://www.pomodorotechnique.com/ : Site officiel de la méthode. Vous trouverez ici un article complet.
Quelques blogs intéressant : lifehacker, etre-meilleur ou aubryconseil
Une dernière référence du Wall Street Journal

Une User Storie est en générale présenté sous cette forme :

« En tant qu’utilisateur je peux m’identifier afin d’administrer mon compte »
« En tant que comptable je peux calculer le reste à payer »

Elle permet de décrire en 1 ou 2 phrases une fonctionnalité qui représente l’apport de la tâche du point de vue de l’utilisateur, elle est complété par les critères d’acceptation qui sont sous cette forme :

« Vérifier que l’utilisateur connecté est un comptable »
« Vérifier que le comptable connecté est le gestionnaire du porte feuille du département concerné »
« Vérifier que la somme du reste à payer ne fait pas dépasser le budget initial sinon levé une alerte »

Un autre façon d’écrire des critères d’acceptation serait la suivante :

« Étant donné un utilisateur connecté ayant le rôle de comptable dans le département du projet ouvert Quand le comptable calcule les prévisions des prochaines échéances Alors une alerte est levé si cette prévisions fait dépasser le budget initial ».

Bien sûre au préalable il faut veiller que les users stories ne soient pas de taille trop importante et ne pas hésiter à les découper en users stories de plus petites tailles.

Un des constats c’est que parfois la traduction de la rétrospective* en une réel amélioration n’est pas aisé et certains points votés ne sont toujours pas efficacement mis en place.

Il n’est pas toujours évident d’identifier un cadre à la mise en place d’une amélioration, si une intervention ne nécessite qu’une intervention ponctuel, il est suffisant de la prendre en compte dans un sprint (ex : Notre serveur de sources n’est pas performant, il est suffisant d’avoir un tâche de migration dans un sprint pour améliorer …).

Donc pour éviter que des points d’amélioration qui ont été retenu lors d’une rétrospective ne soit délaisser par l’équipe, on a mis en place un système de responsable de point d’amélioration pour ça on mise sur le volontariat ;-), cette personne doit proposer un cadre et des actions concrètes à mettre en place pour faciliter la vie de l’équipe, bien sûre en collaborant avec le reste de l’équipe.

Le meilleur moment pour le faire ? Entre la rétrospective et la réunion de lancement, il est intéressant de laisser un temps de battement pour faire ce qu’on a pu traiter pendant le sprint.

quel intérêt ? Tout ce que j’ai dis au dessus, mais surtout lancer le débat

*La rétrospective de Sprint est une des réunions majeure dans la pratique de Scrum, elle permet d’inspecter un Sprint pour en déduire les axes d’améliorations (les points d’améliorations sont votés par l’équipe en fin de réunion), elle s’inscrit dans l’axe de l’amélioration continue et permet d’adapter et améliorer le processus.