INGENOSYA ET LA METHODOLOGIE AGILE
METHODOLOGIE AGILE
INGENOSYA pratique la méthodologie AGILE ayant pour objectif la satisfaction du client. C’est une approche itérative et incrémentale, avec la mise en place d’une gestion de projet pragmatique : pilotage par les livrables avec une livraison opérationnelle toutes les 2 semaines afin de donner une visibilité globale du déroulement du projet.
Ce découpage de projet en courte période de temps permet d’améliorer la conformité aux besoins en impliquant plus les utilisateurs sur des bases concrètes. Pour cela, la constitution d’une équipe mixte client-prestataire, embarquée dans un objectif commun de livraison régulier, est fondamentale.
Une méthode AGILE doit respecter les 4 principes du manifeste agile :
1. Priorité aux personnes et aux interactions plutôt qu’aux outils et processus.
Le Product Owner (PO) est le porteur de la réalisation et de la vision produit, il représente le client au sein de l’équipe de réalisation. Il est la seule personne responsable de gérer le carnet de produit (Product Backlog)
Le Scrum Master est un leader au service de l’équipe de réalisation. Il est responsable de s’assurer que Scrum est compris et mis en oeuvre
Le Product Backlog est la liste priorisée des fonctionnalités du produit. Le Product Backlog est de la responsabilité du Product Owner (PO).
2. Préférer la collaboration avec le client plutôt que les négociations contractuelles.
3. Préférer un logiciel qui fonctionne plutôt qu’une documentation exhaustive.
4. Réactivité au changement plutôt que suivi de plan.
METHODE SCRUM
Depuis quelques mois, INGENOSYA a mis en place la méthode SCRUM. Chaque projet commence par un sprint préparatoire, les sprints suivants sont des sprints de 2 semaines. L’objectif du sprint préparatoire est de définir la vision du produit, les grandes lignes de l’architecture et de mettre en place des environnements de développements.
Pour les sprints suivants, nous avons repris certains éléments de la méthode SCRUM.
Réunion de début de sprint
Chaque sprint est précédé d’une réunion de début de sprint dont l’objectif est de décrire les users stories (exigences fonctionnelles), produire le Backlog de sprint et avoir le planning de l’équipe.
Durant cette réunion, le Product Owner (la personne qui porte la vision du produit à réaliser) explique les user stories. En fin de réunion, toute l’équipe doit avoir compris le contenu du sprint. Le fonctionnel doit être clair et bien compris et les contraintes doivent être connues de tous.
Pour l’évaluation des user stories, chaque membre donne une valeur à chaque user story en utilisant la suite de Fibonacci. On confronte le chiffrage individuel au groupe et décider de commun accord l’estimation à prendre.
Réunion daily meeting
Tous les matins, l’équipe projet avec le Product Owner fait une réunion daily meeting d’une durée de 15 minutes. Cette réunion a comme objectifs de synchroniser l’équipe, de maintenir l’engagement, d’identifier les points de blocage. Chaque participant doit présenter ce qu’il a fait la veille, ce qu’il va faire le jour-même et énoncer les points de blocages s’il en a.
A la fin du sprint, il y a deux réunions :
Réunion de revue de sprint
La réunion de revue de sprint est une réunion de démonstration où chaque membre de l’équipe fait une démonstration des fonctionnalités qu’il a réalisées à l’utilisateur final.
L’objectif de cette réunion est de livrer une version de démonstration utilisable par le Product Owner afin de mettre le Backlog produit à jour.
Réunion rétrospective
Cette réunion est une réunion en interne avec toute l’équipe projet. L’objectif est d’inspecter les éléments positifs et négatifs du processus de développement, ceux qui ont bien fonctionné et ceux qui sont à améliorer pour en déduire un plan d’actions à mettre en œuvre lors de du sprint suivant.
En matière de développement, nous utilisons la technique TDD (Test Driven Developpement), le développement est piloté par les tests.
Néanmoins, il est important de noter que nous n’imposons pas la méthode à nos clients. En démarrage de projet, nous définissons avec le client la méthodologie et l’organisation qui correspondent à son organisation.
LISTE DES OUTILS PRATIQUES POUR JAVA
|
Source code management, release, code review |
SVN, Git, GitHub |
|
Unit tests |
jUnit, Mockito |
|
Tracking tool |
Mantis, Redmine |
|
Quality measurement tool code |
Sonar |
|
Project management tool |
iceScrum, Microsoft project, OpenErp |
|
Continuous integration tool |
Jenkins, maven, SoapUI, Hudson |
|
Construction tool |
Maven, Ant |
|
Communication |
Skype, Jabber, hangouts, Mumble |
|
Frameworks |
Spring, hibernate |
|
Java Security |
Acegi security, Spring security |
|
Java Web |
Spring MVC |
|
Java User Interface |
Swing, Eclipse RCP |
|
Reporting |
Ireport, jasper report |
|
Database |
Oracle 9i/10g, MySQL, MariaDB, PostGreSQL |
|
IDE tools |
Eclipse, NetBeans |
|
Servlet/JSP Container |
Tomcat 6/7, jetty |
|
Business process |
JBPM |
|
XMP API |
JAX Bind |
|
JSON API |
Jackson |
|
AJAX |
jQuery, JS, Ext JS |