samedi 3 mars 2012

Sortie de IceScrum version R4#4

IceScrum

Icescrum version R4#4 (release 4 de la version 4) vient de sortir. Icescrum est un outil libre web (licence GNU Affero GPL V3 et en partie sous licence LGPL V3) permettant de gérer de multiples projets agiles (Scrum, Kanban) y compris pour des équipes distribuées, via un interface web conviviale offrant des affichages proches de ceux qu'on peut obtenir avec des tableaux blancs et des post-it pour faciliter le management visuel. IceScrum supporte les principaux navigateurs (IE 7+, Firefox 3+, Safari 3+, Chrome).

On retrouve:

Différents type d'import et d'export (odf, word 2007, pdf et RTF) sont également disponibles, ainsi qu'une interface REST. L'interface est en français (entre autres) et un système de plugins est en cours, permettant d'espérer un support de LDAP prochainement. Une connexion avec Eclipse est également possible via le connecteur Mylyn.

Pour le côté technique, l'outil est réalisé avec Grails et fait appel à une base de données via Hibernate (dont Postgres, MySQL, Oracle, SQL Server) ou pas (HSQLDB, un gestionnaire de base de données Java, sur fichiers), s'appuie sur liquibase pour la gestion de la création ou de la montée en version du schéma de bases de données.

On peut le télécharger en bundle (avec un tomcat) ou sous forme de war. Voir le site de suivi de projet pour vous faire une idée tout de suite.

J'ajoute enfin qu'il y a de la documentation et une équipe très réactive en cas de problème à contacter via le forum.

Lire la suite...

lundi 6 février 2012

Qu'y a-t'il dans une histoire (une Story) ?

Le Behaviour-driven development (BDD ou développement dirigé par le comportement) est une méthodologie « extérieur-intérieur ». Il démarre à l' extérieur en identifiant les produits métiers puis pénètre dans les fonctionnalités (« features ») pour déterminer qui réalise ces produits. Chaque fonctionnalité est capturée dans une « story » qui définit la portée de cette fonctionnalité en même temps que les critères d'acceptation. Cet article est une introduction à l'approche BDD qui définit et identifie les histoires et leurs critères d'acceptation.

Ce qui suit est la traduction de l'article de Dan North : http://dannorth.net/whats-in-a-stor..., publiée ici avec son aimable autorisation.

Les termes fréquemment usités dans le domaine seront également signalés en anglais.

Introduction

La livraison de code consiste à écrire du code qui produit des résultats métiers. Cela semble évident, mais souvent des facteurs politiques ou environnementaux nous conduisent à l'oublier. Parfois, la livraison de code peut sembler ne consister qu'à réaliser des rapports optimistes permettant de s'assurer de la bonne humeur des responsables projet ou juste à simplement maintenir les gens occupés pour garantir de conserver les effectifs existant, mais c'est un autre sujet.

En général, les attendus métiers sont trop génériques pour pouvoir être utilisés directement pour écrire du code (où commencer à coder quand l'attendu est « économiser 5% de mes frais de fonctionnement »?), aussi nous avons besoin de définir des exigences à un niveau intermédiaire afin de pourvoir faire le travail.

Le Behaviour-driven development (BDD) prend le parti que vous transformez simplement et efficacement une idée d'exigence en code implémenté, testé et prêt pour la production tant que les exigences sont suffisamment spécifiques pour que tout le monde comprenne de quoi il retourne. Pour ce faire, nous avons besoin d'un moyen de décrire les exigences de telle sorte que tout le monde – les fonctionnels, les analystes, les développeurs et les testeurs – ait une compréhension commune de la portée du travail. A partir de là, ils peuvent se mettre d'accord sur une définition commune de « terminé » (« done ») et nous échappons aux pièges mentaux du découragement (« gumption traps ») du « ce n'est pas ce que j'avais demandé » et « j'ai oublié de vous dire quelque chose ».

Ceci, alors, est le rôle de l'histoire (« Story »). Elle doit être une description d'une exigence et du bénéfice métier associé assortie d'un ensemble de critères grâce auxquels on pourra s'accorder sur le fait que l'exigence est satisfaite, donc que le travail spécifié est terminé (« done »). Ceci constitue une définition plus rigoureuse que celle que l'on trouve dans d'autres méthodologies où elle est diversement décrite comme « la promesse d'un dialogue » ou « la description d'une fonctionnalité ». (Une histoire BDD peut aussi facilement décrire une exigence non fonctionnelle du moment que le travail peut être cadré, estimé et validé par tous).

Lire la suite...

samedi 4 février 2012

Test d'une application Web avec Thucydides

Thucydides

L'objet de cet article, inspiré fortement par le guide utilisateur de Thucydides, et de mettre en place des tests de validation fonctionnelle sur une application Web à l'aide de Thucydides, donc, et de WebDriver/Selenium 2. Thucydides est une bibliothèques OpenSource destinée à faciliter ces tests de recette, en utilisant, soit JUnit, soit EasyB.

Lire la suite...