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

Après avoir supporté tant bien que mal cette plénière aux allures d’avant vente géante d’Azure, mon objectif journalier était d’éviter autant que possible les sessions sur Azure, car à part un regard d’actualité, je n’éprouve aucun intérêt particulier pour ce sujet.

Mais heureusement les sujets qui m’intéressaient ne manqués pas ! Et en particulier un était largement représenté l’Asynchronisme

- Windows Phone 7 et mode offline

La première session présenté une solution à ce problème en s’appuyant sur Sync Framework, ce Framework offre une solution simple pour la synchronisation d’une base en locale (sur le téléphone) et une autre distante. Le mécanisme est simple et à l’air d’être efficace, une session bien orchestré !

- Asynchronne et parallélisme

Ensuite j’ai assisté à plusieurs sessions sur l’asynchone, traitant de l’asynchronisme permettant de donnée un aspect fluide à une application WPF, jusqu’au Framework Async (disponible dans la prochaine version de c#) en passant par TPL et des notions de parallélisme.
Avec des machines ayant de plus en plus de cores, il devient essentiel aujourd’hui de s’intéresser à ces sujets qui sont parfois assez complexe. Heureusement que les évolutions du framework tendent à simplifier leurs usages, dans WPF par exemple il est assez simple de rendre un binding Asynchrone en passant par une propriété (Binding.IsAsync), ou de paralléliser simplement un foreach avec Parallel.ForEach… Les exemples sont nombreux, si vous avez l’occasion de voir les podcasts n’hésitez pas

- WPF et patterns

Y avait également plusieurs sessions sur WPF et les patterns, mais malheureusement aucune d’elle n’a traité un sujet en profondeur, les sujets étaient souvent très nombreux et les speakers les ont souvent survolés, même si y avait des choses intéressantes j’ai été globalement un peu déçu.

Allé, il se fait tard et demain j’y retourne, aux programmes TFS 2010, VS 2010, EF4 et autres joyeuseries

Après des articles où je parlais de la réussite d’Apple avec l’iPhone et les promesses de Windows Phone 7, c’est bien Android de Google qui semble aujourd’hui se diriger sur la plus grande marche… Plus mature aujourd’hui, Android se paie le luxe d’avoir un des smartphones les plus aboutis dans ses ronds, qui n’est autre que le Nexus S. Avec une part de marché de plus en plus importantes et des promesses qui se concrétisent dans le temps, Google semble prendre le large détrônant au passage Nokia dans le secteur des smartphones, tout en faisant une belle entrée dans le secteur des tablettes avec une part estimé à 22%.

- Un système ouvert

A l’opposé des autres OS, Android a misé sur un système totalement ouvert, chose qui était un handicape à ces débuts (stabilité et performances du système) devient un argument de choix une fois que le système a atteint la maturité et touché un large public. Le support de Flash, le mode modem ou l’indépendance du système (aucun outil externe n’est nécessaire pour administrer le téléphone) en sont quelques illustrations…

- Applications et développement

En tant que développeur .NET, j’ai bien évidemment un faible pour le framework Windows Phone 7 que je trouves vraiment réussi, mais la réalité des chiffres est encore une fois en faveur d’Apple et d’android avec plus de 200000 et 100000 applications respectivement, avec un avantage pour android compte tenu que le système soit Open Source.

- Que fais la concurrence

La grande question aurait pu être que fait Apple ? Partie avec une avance considérable à la sortie de l’iPhone 3G en 2008, le système a très peu évoluer, laissant le temps à ses concurrents de l’époque de sortir de leur torpeur (à part Nokia mais ça, c’est encore une autre histoire) et de rattraper (dépasser ?) la révolution que fut l’iPhone dans le monde de la mobilité. Alors cette année, Apple va-t-il enfin nous remettre plein la vue, ou va-t-il encore exploiter son image avec une nouvelle version en forme de mini-évolutions ?
Quand a Microsoft la question qui revient souvent, est à savoir, est il déjà trop tard ? Seulement 2% d’utilisateurs équipés de Windows Phone 7 et 4% environ tous systèmes Microsoft confondu, sans être un constat d’échec pour WP7, c’est un chiffre totalement consternant quand on connait la position historique et l’investissement de Microsoft (partenariat, développement…). Les dernières rumeurs font échos d’un partenariat avec Nokia, Nokia qui est toujours hors du coup dans les smatphones haut de gamme (paie-t-il encore le prix de ne pas avoir cru dans le tactile).

- Nexus S

Nexus S est l’aboutissement de l’évolution d’android ces dernières années, j’ai été vraiment agréablement surpris par celui-ci, très fluide et assez beau, enfin un appareil qui mets vraiment en valeur ce système.

Alors après Google géant du Web, se diriges-t-on vers Google géant de la mobilité ?

Microsoft a beaucoup investi pour cet nouvel OS, qui se présente comme une rupture, avec un nouveau design et une nouvelle ergonomie, une interface nommée Metro. Microsoft prend le risque de rompre avec la tradition, on trouvera difficilement des liens de parenté avec iOS ou Android.
Avec le système de « hubs » par exemple, Windows Phone 7 essai d’intégrer un peu plus les applications dans l’os, dans le hub people par exemple on trouvera une agrégation de nos différents réseaux sociaux, contacts… Autre particularité est le défilement en mode panoramique, largement utilisé dans les hubs, cette vue permet une navigation naturel.

Quel mobile

Microsoft a toujours su s’entourer et pour le lancement de son tout nouvel OS, il ne déroge pas à la règle, pas moins de 9 modèles ont été présentés, avec un partenaire privilégié qui sera HTC auteur de 5 modèles. On annonce des prix de lancement avec SFR et Orange autour de 29€ dès le 21 octobre. Et on annonce également que Microsoft va partager les gains de vente d’application avec les opérateurs, ce qui a coup sûre sera une inépuisable source de motivation pour soutenir cet OS.

Les applications, nerf de la guerre ?

Microsoft arrive avec beaucoup de retard dans ce secteur, ne pouvant pas s’appuyer sur l’existant (les applications Windows Mobile étant incompatible), il nous offre une communication tournée sur la qualité des applications et non pas sur la quantité. Habile manipulation, qui s’appuie sur une des grandes tares des markets déjà en place qui dans leur très large catalogues offrent un éventail d’applications a faible valeur.

Et le développement ?

Microsoft a capitalisé sur son existant, en proposant une plateforme de développement autour de Silverlight pour les applications standard et de XNA pour les jeux. Mettant à disposition un environnement déjà très mature et qui compte une large communauté de professionnel possédant les connaissances pour développer.

• Des outils répandu
  Visual Studio et Blend, sont aujourd’hui les principaux outils utilisés pour le développement d’applications riche (WPF et Silverlight), seul contrainte pour développer pour Windows Phone est d’avoir la dernière version de ces outils.
• Des standards
  Pour développer en Silverlight, comme en WPF d’ailleurs, le design MVVM parent proche de MVC est largement répandu, de nombreux toolkits facilitent son utilisation, dont le plus répondu est MVVM Light. Ce standard facilite entre autres l’évolutivité et la testabilité de l’application.
• Design
  Pour la partie Design Microsoft s’appuie sur le principe d’interface Metro, qui reprend des principes déjà expérimentés dans ZuneHD. L’objectif étant d’offrir une navigation naturel et une expérience tactile aboutie, mais y arrivera-t-il ?

Mot de la fin

Microsoft nous donne enfin l’impression de se donner les moyens de son ambition, mais le retard non négligeable pris pour cette sortie, donne à Windows Phone 7 des allures de dernière chance. Avec un iPhone au sommet de son art, un Android à l’évolution détonante et un Windows Phone 7 très prometteur, nous voilà enfin dans une air concurrentiel des plus prometteuse et comme diraient les sportifs que le meilleur gagne.

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