Des conférences à surveiller

Il y a quelques conférences d'importances dans les prochains mois et je tenais à en parler si jamais vous chercher à acquérir un baggage supplémentaire pour votre développement de carrière. 

Agile & Beyond

Le 10 mars prochain, cette conférence dans le Michigan semble prometteuse. Je connais un peu l'organisateur et avec des keynote comme David Anderson et Steve Denning, je serais tenté d'y faire un tour.

Agile Games 2012

Du 19 au 21 avril, cette conférence se veut une exploration des jeux que l'on peut créer pour améliorer la collaboration des équipes. 

Citation de leur site:

"The Agile Games conference is an exploration of how concepts like serious play, collaboration, and experiential learning apply to the field of Agile software development and project management. More than a conference, this will be an experience where attendees will be able to learn new concepts, then immediately share and experiment with other professionals. Forget death by PowerPoint. Every single session we offer will be interactive, hands on, and - dare we say - fun! Whether you're new to Agile, a capable practitioner, or a seasoned veteran, this conference has something for you."

Lean Software and System Conference

Du 13 au 18 mai, cette conférence propose du contenu Lean avec des experts qui sortent du contexte de l'Agilité. Le 13 mai, on y tient un Lean Camp tandis que les 17 et 18 mai, on offre des tutoriels Lean. 

Agile Conference

La conférence qui reste la référence année après année. J'y ai assisté en 2007 et 2008. Je la considère comme un excellent point de départ pour les gens qui se lancent dans l'Agilité et qui veulent baigner parmis les experts. Les plus critiques disent que c'est une conférence qui est rendu trop commercial. Ils ont probablement raison mais j'espère que cela ne vous empêchera pas d'y faire un tour. 

De mon bord, le choix est déjà fait. Je serai à Boston du 13 au 16 mai prochain.

Un dérivé du "wall session"

Traditionnellement, les équipes Agile estiment leurs stories à l'aide du planning poker. Puisqu'il y a beaucoup de stories à estimer en démarrage de projet Agile, j'utilise plutôt un "wall session" pour accélérer l'estimation des stories.

Dans la vidéo suivante, Boris Gloger nous présente le "magic estimation" qui est, à mon avis, un dérivé du wall session. Au lieu de placer les stories une à une sur le mur, on remet quelques stories à chaque membre de l'équipe. Chaque personne place alors ses stories au bon endroit sur le mur. On demande alors à tout le monde de réviser chaque story pour s'assurer qu'elle est au bon endroit.

Bon visonnement!

Comment bâtir une équipe exceptionnelle

Dans cette entrevue, Robert C. Martin présente son approche sur les bonnes façon de composer une équipe exceptionnelle de développement logiciel. Il propose plusieurs pistes intéressantes et offre même quelques références pour approfondir le sujet

Est-ce que vous avez déjà utilisé l'approche du "chef programmeur" tel que mentionné par uncle Bob et popularisé par Fred Brooks dans son ouvrage The Mythical Man-Month?

Établir sa vélocité initiale

Suite à une discussion où mon collègue Mathieu Boisvert chez notre client m'a fait réfléchir, j’ai voulu écrire un billet sur la façon de dresser la vélocité initiale d'une équipe pour ainsi prédire le plan de livraison de cette dernière.

Mise en situation

Imaginons une équipe qui a évalué qu’elle devra livrer un projet de 200 points répartis de la façon suivante :

• Obligatoire: 100 points
• Important: 60 points
• Facultatif: 40 points

Nous avons 43 itérations d’une semaine pour livrer ces points, donc environ 1 an pour livrer ce projet si on enlève les vacances de l'équipe. Le SunSet graph suivant nous permet d'illustrer ces points sur une ligne du temps. 

La prochaine étape consiste donc à établir la vitesse à laquelle seront livrés les points du projet. J'avais surtout l'approche client mais en parlant avec Mathieu, il m'a fait comprendre que l'approche de l'équipe était très important, surtout parce qu'elle m'expose un risque dès le départ.

Comparons donc les deux approches pour voir ce qu'elle nous apporte comme information

L'approche client

Si on se place dans les souliers du client, il veut son projet complété dans 1 an. Si on enlève les vacances de son équipe, on peut dire qu'il faut 43 itérations pour livrer. S’il a 200 points à livrer, il peut se donner trois scénarios possibles :

• Meilleur scénario : 200 points / 36 itérations = 5,55 points par itération
• Scénario normal : 200 points / 43 itérations = 4,65 points par itération 
• Pire scénario : 200 points / 50 itérations = 4 points par itération

Cependant, cette approche a un problème. Le client dresse ses attentes dès le départ. Si on présente ces chiffres à l’équipe, elle aura naturellement tendance (à mon avis) à atteindre ces chiffres, même si elle se met à couper dans la qualité des fonctionnalités.

Voyons voir si l'approche de l'équipe peut nous apporter une perspective différente.

L'approche équipe

Si on se place dans les souliers de l’équipe, on constate qu’il faut 200 points à livrer dans 43 itérations. Cependant, on ne leur demandera pas de dresser les trois scénarios comme avec le client.

Lors de la planification de l’itération initiale, on demande à l’équipe de découper les stories retenues pour l'itération en tâches. Selon le nombre d’heures qu’elle peut donner, on voit le nombre de points qu’ils peuvent faire en une itération dès la fin de la planification de l'itération. On va donc chercher la vélocité initiale que l’équipe peut donner dès le départ du projet.

À ce moment, on peut tout de suite constater si l’équipe pense être en mesure d’atteindre les 200 points pour la fin de l’année. Si l’équipe ne peut prendre que 2 points pour la première itération, on voit donc déjà un risque apparaître. Si l’équipe se rend compte qu’elle peut faire 15 points dès la première itération suite au découpage, peut-être que la durée du projet sera plus courte.

Conclusion

Si on utilise l'approche du client, il faut attendre la fin de la première itération pour faire le constat si l’équipe peut (ou non) livrer les points dans l’année. Cependant, avec l'approche de l'équipe, on peut faire ce constat dès le départ, avant même l’itération 1, qu’il y a un risque que l’équipe n’atteigne pas ses 200 points à la fin de l’année du projet.

Ma conclusion est qu’il faut faire les deux approches. Je ferais l'approche client avec le client, seul, pour qu’il constate ce qu’il attend de son équipe dans la prochaine année. Par la suite, à la fin de la planification de l’itération 1, je ferais l'approche de l'équipe. Une fois les deux approches élaborées, je les comparerais et les mettrais en évidence au client pour qu’il puisse comparer de par lui-même que ce qu’il espère (l'approche client) puisse ou non se réaliser par l’équipe.

.NET Continuous unit testing : a dream comes true

.NET Continuous unit testing : a dream comes true

For many years, I’ve been green with envy of those Java guys who could use tools like Infinitest and JUnitMax to continuously unit test their code.  My wait is finally over. Similar tools have now become available for the .NET platform!  Some of you may be wondering: “What’s the point of a continuous unit test tool?”  In short, a continuous unit testing tool provides you, the developer, with constant feedback about the state of your unit tests without requiring any manual intervention on your part. It tells you immediately when you break something by running the tests automatically as soon as you change the code.

A few tools started to come out last year:

●      ContinuousTests

●      .NET Demon

●      NCrunch

I have not used ContinousTests or .NET Demon.  Therefore, my intention in this article is not to compare these tools but to discuss my experience with NCrunch.

Running in the background

The first thing you notice when using NCrunch is that there is no need to save your file.  A simple keystroke will launch the continuous test runner in the background.  It does not interrupt your current work and you can always see the current status of your test in the Risk/Progress window.

Figure A – Progress Bar (1 failing test)

You can also see a more traditional detailed view of the tests in the Tests window.

Figure B – NCrunch Tests Window

Code Editor Integration

NCrunch offers visual indicators of the state of your tests directly in the source code editor.  All paths and lines of code covered by a working unit test (and the test themselves) have a green widget besides it.  There is a red widget in front of all failing tests or code that isn’t covered.

Figure C – Code Integration

Impact navigator

You can see which tests cover a specific line of code simply by clicking on the widget in front of the line.

Figure D – Impact Navigator

Conclusion

I’ve been using NCrunch for a few months and have been extremely satisfied with it.  It runs smoothly on almost every existing solution I have tried it on.  The very few bugs I have had were all related to specific configuration errors within a solution.

NCrunch is free for the beta testing period but will be sold as a commercial product when it officially comes out.  .NET Demon, from RedGate, has the same disclaimer.  I guess (and hope) those products will be reasonably priced.  Not all employers will invest on a tool that does not necessarily increase the developers’ productivity by much even though it provides them with a more enjoyable experience while doing TDD.

When I use this tool, it really makes me feel more nimble. I think price will be a key point given that many companies still think tools like Resharper are expensive toys instead of seeing them as really cheap investments to increase developer productivity.

At less than 50$, I would not even wait for my company to buy it. I’d buy it from my own pocket simply for my personal enjoyment and satisfaction. I’m eagerly awaiting the official launch of NCrunch. In the meantime, I’ll probably take a look at .Net Demon but I can tell you NCrunch has definitely become part of my TDD tool belt.