1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM

Transcription

1 1 PROCESSUS DE DEVELOPPEMENT : METHODOLOGIE SCRUM Scrum est une méthode agile pour la gestion de projets informatiques. C est une méthode itérative basée sur des itérations de courte durée appelées Sprints. Cette méthode a pour objectif d améliorer au mieux la productivité tout en assurant la satisfaction du client. 1. LES ROLES L équipe d un projet Scrum (Scrum Team) est constituée d un maître du Scrum (Scrum Master), d un Directeur de produit (Product Owner) et des membres. La figure suivante illustre les membres d une équipe d un projet Scrum et l interaction entre eux : Figure 1: Scrum Team Le maître du Scrum (Scrum Master) : joue le rôle d un facilitateur et d un coach plus que le rôle d un superviseur. Il est chargé de protéger l'équipe de tous les éléments perturbateurs et de résoudre les problèmes non techniques (administratifs par exemple). Il doit aussi veiller à ce que les valeurs de Scrum soient appliquées Le Directeur de produit (Product Owner) : représente le client. Il est chargé de clarifier ses besoins et de déterminer leurs priorités. Il définit l'ordre dans lequel les fonctionnalités seront développées, et prend les décisions importantes concernant l'orientation du projet. Idéalement, le Product Owner sera présent à plein temps avec l équipe du projet afin de répondre à leurs questions et de prendre les décisions importantes le plus tôt possible.

2 L équipe de développement (Development Team) : il n y a pas de rôle prédéfinis dans cette équipe ni de hiérarchie. Cette équipe s autogère, s entraide et tous les membres prennent les décisions ensemble. Dans cette équipe, chaque membre peut jouer des rôles différents (développeur, concepteur, testeur,etc.). L'équipe s'adresse directement au Product Owner. Mis à part ces membres là, on peut retrouver d autres intervenants appelés Stakeholders qui sont les personnes qui souhaitent avoir une vue sur le projet sans réellement s'investir dedans. Il peut s'agir par exemple d'experts techniques ou d'agents de direction qui souhaitent avoir une vue très éloignée de l'avancement du projet. 2. LE PRINCIPE Scrum est basé sur des itérations, qui durent entre 2 à 4 semaines, appelés sprints. La figure suivante illustre le principe du processus d un projet Scrum : Figure 2 : Vue globale du processus Scrum 1. Tout projet Scrum commence par la définition de la liste des besoins du client, appelée Product Backlog. A chaque item de backlog on associe deux attributs : une estimation en points et une valeur client, qui est définie par le Product Owner. Ce dernier définit dans quel ordre devront être réalisés ces items. Il peut changer cet ordre en cours de projet, et même ajouter, modifier, ou supprimer des items dans le backlog. La somme des points des items du backlog de produit constitue le reste à faire total du projet. 2. L équipe du projet choisit les items à développer durant le sprint. Ces items constituent le Sprint Backlog. Chaque item choisi est décomposé en liste de tâches élémentaires, pouvant être fonctionnelle ou technique. Chaque tâche est estimée en heures et ne doit pas dépasser les 2 jours. 3. Chaque Sprint commence par un Sprint planning meeting qui dure de 4 à 8 heures durant lequel toute l équipe établi le Sprint backlog et chacun s attribue une tâche à réaliser.

3 4. Quotidiennement toute l équipe se réunit, pendant 15 minutes au maximum, afin que chaque membre rappelle le travail qu il a effectué le jour d avant, annonce le travail qu il réalisera le jour même et liste les difficultés qu il a rencontrées. Ces réunions sont appelées Daily Scrum ou mêlée quotidienne. 5. A la fin de chaque Sprint, l équipe délivre un produit potentiellement livrable au client et se réunit pour un Sprint retrospective meeting où chaque membre de l équipe donne son avis par rapport au déroulement du Sprint précédent et discute des améliorations qui peuvent avoir lieu au court du Sprint suivant. 6. Le suivi du projet se fait via les Burndown Charts qui sont des graphiques d'avancement permettent de visualiser graphiquement l'avancement du travail. Une interprétation simple permet d'avoir une idée sur les échéances futures. Figure 3 : Exemple d'un burndown chart d'un sprint Ce graphique représente la quantité totale d'heures restantes à faire dans le sprint, au fil des jours. Il permet d'avoir une vue sur l'avancement du sprint.

4 Figure 4 : Exemple d'un burndown chart d'une release Ce graphique représente la quantité totale de points restant à faire dans la release, au fil des sprints. Il permet d'avoir une vue sur l'avancement de la release. Outre le fait de montrer l'avancement concret du travail, ces graphiques permettent d'anticiper de façon relativement fiable les échéances futures en cours du sprint ou de la release.

5 2 JEUX DES TESTS 3. STRATEGIE DE TEST Afin d améliorer la qualité de nos livrables et de diminuer les coûts de maintenance, nous allons consacrer une équipe chargée des campagnes de test. La figure ci-dessous résume la stratégie générale que nous allons adoptée et décrit l intervention de l équipe tout au long du projet Description de processus : Le travail de l équipe Testing couvre deux grands volets : la conception et la planification des tests puis leur déroulement Conception et planification des tests L équipe Testing est impliquée dès les premières phases du projet. Après avoir pris connaissance des spécifications fonctionnelles et techniques et suite à une analyse des documents de projet, l équipe définit les périmètres des différentes catégories de tests.

6 Cette étape aboutit à dégager un ensemble de cahiers de tests et un planning des tests imbriqué avec les jalons du projet. Cette étape de conception et de planification des tests ne sera clôturée qu après la validation du chef de projet Réalisation des tests Après s être assuré que tous les moyens nécessaires aux tests (matériels, connexions, environnements, jeux de données significatifs, etc.) sont disponibles, l équipe entame l exécution des différents tests. Plusieurs itérations seront effectuées. Chaque itération sera documentée, les anomalies seront relevées et communiquées à l équipe de développement. Lors de l itération suivante, l équipe Testing s assure que les anomalies relevées précédemment ont été bien corrigées et que la correction n induit pas de nouveaux problèmes et notamment des bugs de non-régression. Les itérations se poursuivront jusqu à épuisement des scénarios. A la suite de cette campagne, un rapport final de test sera livré au client. 1. ORGANISATION DE L EQUIPE TESTING : L équipe Testing est une équipe transversale au projet et qui est en contact permanent avec de nombreux interlocuteurs. Trois profils se distinguent : 2.1. Test Manager : Il est responsable du pilotage, du suivi et de l amélioration continue de l activité Testing. Il s occupe aussi de la coordination entre les test leaders et les chefs des projets. Le Test Manager élabore et met à jour de manière hebdomadaire un tableau de bord général des activités de test pour l ensemble des projets B&D Tunisie. Ce tableau de bord permettra de fournir au chef de projet les indicateurs du bon déroulement des activités de test en terme de charges et de délais Test Leader : Pour chaque projet, un Test Leader est désigné. Il définit et met en œuvre la campagne de test. Il participe à l estimation de charge et définit un planning de tests. Le Test Leader encadre les testeurs affectés au projet Testeur : Il déroule les tests qui lui sont attribués, il livre à intervalles réguliers un rapport décrivant les erreurs trouvées.

7 2.4. Volet Communication : En dehors des campagnes de test, l équipe Testing est présente dès le début du projet. Un représentant de l équipe participe aux principaux points de communication. Interlocuteur privilégié de l équipe de réalisation, l équipe Testing prodigue des conseils en amont et ce afin d anticiper d éventuels blocages. Elle remonte aussi les alertes selon un processus bien défini. 2. OUTIL DE TESTING : Pour la réalisation de nos campagnes de test nous avons retenu l outil TestLink. C est une solution web open source qui gère les tests et leurs exécutions. TestLink nous assure : La gestion des exigences La gestion du référentiel de test La gestion de l exécution des campagnes de test La génération automatique des métriques et rapports de test Testlink-Vision Générale La solution TestLink crée et gère les cas de test et les organise en plans de tests à partir des exigences fonctionnelles. Ces plans de tests nous permettent d'exécuter les cas de test et de suivre dynamiquement les résultats. Des rapports sont générés fournissant des statistiques et des indicateurs décrivant le déroulement des tests et leurs résultats.

8 Exemple de rapport généré par Testlink Pour la partie gestion des anomalies, TestLink est mappé avec l outil Bug Tracking afin de compléter tout le cycle de test.

9 3 ENVIRONNEMENT TECHNIQUE 3.1 ENVIRONNEMENT D INTEGRATION : Hudson 1.3 Hudson 1.3 JDK 1.6 Maven Oracle 10g Tomcat 6 Serveur d intégration continue Serveur SVN système de gestion de versions Serveur Archiva système de gestion de dépôt Serveur de pré-prod JDK 1.6 Oracle 10g Tomcat 6 Poste Développement JDK 1.6 Spring Tool Suite 2.5 Maven Oracle 10g Spring 3.0 GWT 2.0 jbpm 4 Hibernate 3

10 3.2 ENVIRONNEMENT DE RECETTE Base de Données Serveur de Pré-prod Installation de l instance de Pré-prod Accès via Internet vers le serveur de Pré-prod Equipe de Recette Client Serveur d intégration continue Une fois notifiée de la livraison de l itération N sur une instance d intégration, l équipe de recette fonctionnelle, exécute les cahiers de recette A partir de subversion, le serveur d intégration continue Hudson, exécute les tests unitaires et génère les modules à installer sur l instance d intégration Equipe de Recette interne Chaque anomalie remontée fait l objet d une tâche JIRA : Le UC SFD, Numéro de Test, Lien vers l écran, description détaillée du comportement constatée, imprimé écran en pièce jointe JIRA bug & issue tracker Cahiers de Tests Prise en compte des demandes Serveur SVN Les développeurs commitent les sources Spécifications Equipe de développement