Agile-IT

Agilité et Lean-IT: penser l'informatique au plus juste

Revue de Web N°2 – 6 février 2011

février 06
by Damien 6. février 2011 17:42

Deuxième numéro de ma revue du web Agile, avec un focus sur le test et la gestion d’exigence et une nouvelle rubrique (outils). Je signale également que le dernier numéro (2010-4) de la revue Methods & Tools est sorti : http://www.methodsandtools.com/PDF/mt201004.pdf; à noter, entre autres, un article sur “Non-Functional Requirements: Do User Stories Really Help?

Agenda

  • Petit rappel. Le ScrumDay Paris a lieu le 31 mars. Si vous voulez proposer des sujets, la deadline c’est le 25 février. http://www.scrumday.fr
  • Agile 2011: L’Agile Alliance a annoncé sa conférence annuelle ; dix ans après la publication du manifeste Agile c’est “back where it all began” à Salt Lake City au mois d’Aout prochain: http://agile2011.agilealliance.org/

Pratiques

  • Je suis tombé cette semaine sur un blog intéressant “thoughts from the test eye” alimenté par une équipe Q&A et, plus précisément sur un article intitulé “Développeurs, laissez les testeurs vous aider sur la dette technique” (http://thetesteye.com/blog/2011/01/developers-let-the-testers-assist-with-the-technical-debt/). Il redéfinit assez longuement ce qu’est la dette technique (avec plein de références utiles) puis construit une liste de 10 règles pour améliorer la coopération entre l’équipe de développement et les testeurs.
    A noter une phrase de Steve Connell, que je trouve très pertinent et que je cite moi-même assez souvent; je n’ai pas reconnu l’extrait mais il vient sans doute de Code Complete. Il s’agit ici des raccourcis que l’on fait parfois dans le code, avec l’intention  d’y revenir plus tard:
    ”Si le raccourci que vous envisagez de prendre est trop mineur pour ajouter sa correction au backlog produit, à la liste des bugs à régler ou au service de la dette alors il est trop mineur pour faire une différence dans le projet; ne prenez pas ce raccourci. On ne veut prendre que les raccourcis que l’on peut tracer et réparer plus tard.”
  • Sur le même sujet, Lisa Crispin raconte comment sa propre exploration des scénarios de test l’a conduite à identifier des trous dans les fonctionnalités décrites par les user stories et comment elle a pu identifier une solution globale plus simple que les différents fragments assemblés. Une bonne illustration de l’intérêt de définir les fonctionnalités par les scénarios de recette. Essayer de faire marcher le système qu’on envisage fait ressortir ses contradictions. http://lisacrispin.com/wordpress/2011/01/24/exploring-to-get-specifications-story-tests/
  • Mayank Gupta se demande que signifie “un produit potentiellement livrable” et réfléchit, dans un article assez complet, sur la définition du “fait” (http://blog.scrumedge.com/2011/01/definition-of-done-reference.html) qui rejoint pas mal notre propre approche :
    P1010149
  • Grosse découverte de ma semaine: un blog que je n’hésite pas à qualifier d’extraordinaire car les sujets et l’angle sous lequel ils sont abordés sont très différents de ce que je lis ailleurs. Ca fait tellement de bien d’entendre des voix originales. Ici il s’agit beaucoup de ScrumBoard puisque le blog est entièrement dédié au management visuel. A bookmarker et à suivre: http://www.xqa.com.ar/visualmanagement/
    image
  • Ce blog je l’ai découvert en lisant “How to work with a whiteboard with a distributed Team”, sur le scrumboard en mode distribué, donc ; à voir les commentaires, tout le monde arrive peu ou prou à la conclusion qu’aucun logiciel ne vaut un bon vieux tableau physique avec des post-it; j’ai noté une lectrice qui disait poster sur le blog du projet une photo de chaque scrumboard de chaque équipe après les daily; c’est ce que faisait mon vieux copain Denis Lemarchand : pratique aussi pour la rétrospective, on peut re-dérouler le film du sprint.
    http://www.hanoulle.be/2009/10/how-to-work-with-a-whiteboard-with-a-distributed-team/

Outils

  • Peut-être que ce sera une évidence pour certains d’entre-vous (“comment ? tu ne connaissais pas !”) mais je viens de découvrir un outil qui à l’air d’une superbe idée pour définir et suivre les requirements sous forme de tests : Concordion; apparemment il existe une version .NET, je vais l’essayer rapidement. http://www.concordion.org/Example.html
  • Toujours dans le domaine du test, je suis un grand fan de WatiN mais je continue toujours à suivre Selenium et je viens de voir qu’un toolkit pour .NET est sorti : http://seleniumtoolkit.codeplex.com/

Livres

Tags: , , , , ,

Mini liens