Scrum, un retour aux post-it …

Posté par le 11/08/2008

Avec Scrum, les post-it en force …

Dans la méthode Scrum, toutes les users stories énoncées par le product owner dans son backlog sont découpées en tâches au début du sprint lors de la réunion de planification. Chaque tâche est estimée en heures et chacune doit faire moins de 16h afin d’éviter l’effet tunnel et de tourner en rond sur les problèmes.
Elles sont consignées sur des post-it qui évoluent dans 3 états :

  • A faire
  • En cours
  • Fini

Tous les matins, chaque membre de l’équipe fait bouger les post-it en fonction de ce qu’il a traité et des tâches sur lesquelles il s’était engagé la veille.
Il doit répondre à trois questions :

  • Qu’as-tu fais hier ?
  • Qu’est-ce que tu vas faire aujourd’hui ?
  • Quels sont les problèmes rencontrés ?

Une notion très importante que nous avions minimisé au début est la définition du terme « Fini » sur lequel l’équipe doit s’entendre. Que veut dire fini ? Une tâche est-elle finie quand le développement est fini ? Quand les tests sont validés ? Vaste débat …
Pour notre part nous avons opté pour la définition suivante. Une tâche est finie lorsque :

  • le développement est réalisé conformément au backlog
  • les tests sont réalisés conformément au backlog
  • elle est validée par le product owner

Un petit exemple de tableau des tâches Scrum :

Tableau des taches Scrum

 

Les users stories sont en vert et les tâches correspondantes en rose.
Les tâches de tests sont en orange. Les tâches en jaune sont des bugs.

Nous démarrons le sprint 8 aujourd’hui avec un beau challenge de 152 points sur 3 semaines avec les congés de chacun.

Affaire à suivre…

Observations Closed

Velocity au runtime : modification de template

Posté par le 23/07/2008

Modification de template Velocity au runtime

Velocity est un moteur de template Open Source Java de la fondation Apache. Nous utilisons Velocity depuis pas mal de temps pour tout ce qui est rapport aux fusions (Mail, publipostage,…).
Jusqu’à présent nous l’utilisions sous sa forme la plus « traditionnelle », basée sur des fichier template (.vm), que nous chargions au runtime pour être fusionnés à une map de paramètres :

  // Initialisation du moteur velocity
VelocityEngine engine = new VelocityEngine();
engine.init();
// Chargement du template
Template template = engine.getTemplate( "test.vm" );
// Création du contexte
VelocityContext context = new VelocityContext();
context.put("nom", "Durand");
// Exécution du template dans une String
StringWriter writer = new StringWriter();
template.merge( context, writer );System.out.println( writer.toString() );

Dernièrement nous avons eu le besoin de composer une variable sur la base de plusieurs autres. Il s’agit de faire un peu plus que de la concaténation ; nous avons donc laissé nos utilisateurs créer leur propres variables de la sorte :

 politesse = &civilite &nom &prenom

Mais nous devions à ce moment là modifier nos template au runtime. Velocity offre pour cela une méthode evaluate qui permet d’évaluer un template (sous forme de String) :

StringWriter result = new StringWriter();
try {
velocityEngine.evaluate(velocityContext, result, "template", template);
} catch (Exception e)...

Ceci nous a permis de stocker les modèles en base de données sans avoir ensuite à recréer des InputStream ou autre pour les fusionner.

Nous modifions les modèles au runtime en leur ajoutant les variables créées par les utilisateurs.

Observations Closed

Organisation et méthodologie Scrum

Posté par le 07/07/2008

Quelques retours sur notre organisation avec la méthode Scrum.

Nous avons mis en place la méthodologie Agile Scrum dès le début du projet de développement de l’offre ViaXeo.

Cette démarche est issue d’un constat sur nos vies antérieures et plus particulièrement sur les méthodologies de projets classiques. Ces dernières, souvent lourdes à mettre en œuvre et consommatrices de temps, ne nous permettaient pas d’obtenir les résultats escomptés.

Les phases de spécifications détaillées sont souvent lourdes, la validation des clients est partielle et le résultat ne correspond pas souvent aux attentes du client… et les problèmes commencent.

Dans un contexte tel que ViaXoft, jeune startup dynamique dans le tourisme, en pleine création d’une nouvelle application, nous avons décidé de mettre en place Scrum pour plus d’agilité.

Le principe de Scrum (mêlée en anglais) est de motiver une équipe autour d’un objectif commun pour réaliser ce dernier sur une courte période appelée Sprint.

Nous avançons donc au rythme de sprints de 2 semaines en nous focalisant sur des objectifs précis à chaque fois.

Après une petite phase de réglage, Scrum nous permet maintenant d’obtenir des résultats rapidement avec des premières fonctionnalités et des écrans clés de l’application.

Au début de chaque sprint, l’équipe s’engage sur la réalisation d’un objectif défini par le product Owner sous la forme d’un product backlog priorisé (liste de fonctionnalités). Le sprint est rythmé tous les jours par le « Scrum Meeting » où chaque personne de l’équipe explique ce qu’il a traité la veille, s’engage sur ce qu’il va faire aujourd’hui et expose les différents problèmes qu’il a pu rencontrer.

A la fin du sprint, le product Owner valide ou non les résultats lors de la présentation faite par l’équipe (Revue de Sprint).

La rétrospective qui suit la revue permet d’identifier ce qui a marché ou non sur le sprint et permet de mettre en place des actions correctives pour le sprint suivant.

Au-delà des aspects organisation interne, Scrum nous offre aussi plus d’agilité au niveau de l’implication client. Nous pouvons les faire participer plus activement à la construction du produit ViaXeo en leur montrant périodiquement les résultats obtenus par rapport à leurs attentes.

Pour conclure, je dirai que pour l’instant nous n’avons que des résultats positifs qui nous encouragent à continuer sur l’agilité et la méthode Scrum ….

A suivre

Observations Closed

GWT, Tomcat, Eclipse et Cypal Studio

Posté par le 20/06/2008

GWT et son hosted mode

GWT offre un mode de de développement « embarqué » (le hosted mode) qui permet de faire tourner l’application au sein de la machine virtuelle Java et ainsi garder tous les avantages d’un IDE tel qu’Eclipse et notamment le debugger.

Mais pour l’intégration de module plus avancés tels que la sécurité avec Acegi, il est primordial de déployer l’application sur un tomcat externe afin de configurer au mieux ce dernier. Voici un lien vers un très bon post, détaillant au sein d’Eclipse la création d’un projet GWT en s’appuyant sur le plugin Cypal. Ceux qui ont déjà galéré sur ce type de déploiement apprécieront :
Creating your first GWT app with Cypal Studio for GWT.
Merci à Prakash pour ce billet.

L’intégration d’Acegi au trio GWT, Spring, Hibernate fera l’objet d’un prochain post.

Observations Closed

Gestion des logs

Posté par le 06/06/2008

Au sujet de la gestion des logs

La gestion des logs est un sujet qui est souvent sous estimé de la part des équipes de développement. Avec l’utilisation des outils de développement moderne et leur débugger intégré, les logs applicatives ont bien moins d’intérêts au moment du développement. Par contre, lorsque l’application est testée ou déployée, les logs reprennent tout leur sens.

L’apparition de framework Java tels que Log4J ou celui intégré au JDK facilite grandement la vie du développeur, mais l’écriture de logs reste toujours à la discrétion de ce dernier.

L’AOP (Programmation Orientée Aspect) apporte une réponse à cette problématique. Nous pouvons grâce à celle-ci générer des logs à chaque entrée/sortie de méthode et à chaque levée d’exception. Voici un exemple d’implémentation de gestion des logs utilisant Spring et Spring AOP :

Nous définissons tout d’abord un greffon (advice) qui implémente MethodBeforeAdvice, AfterReturningAdvice et ThrowsAdvice. Ceci nous permet de redéfinir les trois méthodes before, afterReturning et afterThrowing afin de générer les logs à chaque entrée/sortie de méthode et à chaque levée d’exception.

package com.viaxoft.ext.logging;

import java.lang.reflect.Method;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.aop.AfterReturningAdvice;
import org.springframework.aop.MethodBeforeAdvice;
import org.springframework.aop.ThrowsAdvice;

public class LoggingAdvice implements MethodBeforeAdvice, AfterReturningAdvice,
ThrowsAdvice {
private static Log logger = null;

public LoggingAdvice() {
}

public void before(Method arg0, Object[] arg1, Object arg2)
throws Throwable {
logger = LogFactory.getLog(arg2.getClass());
logger.info("Entrée dans la méthode : " + arg0.getName());
}

public void afterReturning(Object arg0, Method arg1, Object[] arg2,
Object arg3) throws Throwable {
logger = LogFactory.getLog(arg3.getClass());
logger.info("Sortie de la méthode : " + arg1.getName());
}

public void afterThrowing(Method m, Object[] args, Object target,
Throwable ex) {
logger = LogFactory.getLog(target.getClass());
logger.error("Exceptiondans la méthode : " + m.getName() + " L'exception : "
+ ex.getMessage());
}
}

Nous devons ensuite définir notre aspect sous forme de bean au sein du fichier de config Spring. Nous utilisons l’implémentation RegexpMethodPointcutAdvisor qui nous permet de matcher les méthodes sur lesquelles notre aspects doit s’appliquer grâce à une expression régulière :

<bean id="loggingAdvisor"   class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
<property name="advice" ref="loggingAdvice" />
<property name="patterns" value=".*" />
</bean>

A noter ici que nous générons la log pour toutes les méthodes. On pourrait imaginer générer plusieurs niveau de log (DEBUG, INFO, …), en fonction de la méthode à laquelle on s’adresse ; par exemple les méthodes du layer DAO seraient en DEBUG, alors que celles de la couche service en INFO.

L’implémentation RegexpMethodPointcutAdvisor permet de définir à la fois l’aspect et la coupe au sens AOP.

Nous définissons également le greffon :

<bean id="loggingAdvice"
class="com.viaxoft.ext.logging.LoggingAdvice">
</bean>

Il ne nous reste plus ensuite qu’à tisser les aspects. Nous utilisons DefaultAdvisorAutoProxyCreator pour un tissage automatique :

<bean   class="org.springframework.aop.framework.autoproxy.
DefaultAdvisorAutoProxyCreator" />

Le résultat dans le fichier de log :

juin 06 08:54:25 INFO iaxoft.dao.impl.AddressDaoImpl before Entrée dans la méthode: saveAddress
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl before Entrée dans la méthode: openSession
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl afterReturning Sortie de la méthode : openSession
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl before Entrée dans la méthode: getTransactionManager
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl afterReturning Sortie de la méthode : getTransactionManager
juin 06 08:54:25 INFO iaxoft.dao.impl.AddressDaoImpl afterReturning Sortie de la méthode : saveAddress
Observations Closed
Loading...
X