Méthode AGILE : SCRUM Réalisé par : Imen SADKI Ines GHERAB Rania BEN ISMAIL Takwa BOUALLEGUE 2011 - 2012

Plan Préambule Introduction Concepts Perspectives Conclusion Cas pratique

Préambule (1/2) Les méthodes AGILE Plus pragmatiques que les méthodes traditionnelles Satisfaction réelle du besoin du client; Minimisation des risques , Indiqué pour l'imprévu , Officialisation en 2001 : le Manifeste Agile (Agile Manifesto). Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du besoin du client et non les termes d'un contrat de développement. Minimisation des risques :les itérations sont courtes, donc les problèmes sont rapidement identifiés. Indiqué pour l'imprévu : on s'adapte rapidement au changement. Communication temps réelle : on préfère les « face à face », on écrit donc peu de documentation La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant qu'auteur de leur propre méthode. Cette methode est véritablement une liste de valeurs attachés au monde du développement Agile : Les personnes et interactions priment sur les processus et outils Logiciel fonctionnel privilégié par rapport à une documentation détaillée Collaboration avec le client plutôt qu'une négociation au contrat S'adapter au changement plutôt que de suivre un plan

Spécification des besoins Préambule (2/2) F4, F5 F2’, F3 Voici un schéma qui illustre le principe générale d’une méthode agile . Il représente la réalisation d’un ensemble de fonctionnalités par itération durant le cycle de vie d’un projet. On commence par une spécification des besoins où on spécifie les exigences du client ,Puis une conception de notre projet ensuite l’implémentation et enfin les tests. Et à chaque fois, on reboucle si les fonctions ne sont pas encore terminées. F1, F2 Délivrable Spécification des besoins Conception Implémentation Test

Introduction (1/5) Définition de la méthode SCRUM Origine du terme sportif de rugby signifiant : mêlée, Utilisation d’ une procédure itérative, Processus agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. logiciel fonctionnel rentabilité, satisfaction du client . SCRUM tient son origine du terme sportif de rugby signifiant : mêlée. Tout comme cet aspect technique de la partie du jeu, la méthodologie demande à ses acteurs d'être soudés pour atteindre un but . Mais tout comme au rugby, une mêlée n'est pas un processus unique. C'est une partie du jeu que l'on retrouve fréquemment pour faire avancer l'équipe. Dans le même concept SCRUM utilise une procédure que l'on nome itérative (On parlera de sprint pour décrire les itérations). Chaque itération ou sprint fournit une partie de produit fonctionnelle. En résumé SCRUM est un processus agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. SCRUM veut avant tout produire un logiciel fonctionnel. N'oublions pas que SCRUM veut mettre en avant la rentabilité et surtout la satisfaction client. Ce dernier doit pouvoir donc juger sur le tas de l'avancement de son produit.

Backlog réparti sur les équipes Introduction (2/5) Méthodologie 24h Backlog réparti sur les équipes Dans la méthodologie SCRUM, le métier définit les priorités. L'équipe de développement s'organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires (on parle de « bottom up ») Finalement, à chaque fin de sprint, tout le monde a un pouvoir de décision. L'équipe devra décider de livrer le produit en l'état, ou de continuer à améliorer le produit sur une itération supplémentaire. // Ines essaye de faire un texte descriptif du schémas en suivant l’animation dans cet ordre : Préparation du Backlog du prroduit, puis backlog du sprint Répartition du backlog sur les équipes Entrée dans le Sprint qui dure dans les 30 jours Réunion quotidienne durant le sprint : 15 min, debout, mise à jour… A la fin du sprint, décision de livrer le produit ou l’améliorer. Backlog du sprint 30j Backlog du produit

Introduction (3/5) Caractéristiques Méthode itérative Travail en équipe Grande adaptabilité Contrôle du chaos Augmentation de la communication et maximisation de la coopération Protection de l'équipe Augmentation de la productivité Itératif, lié a des processus incrémentaux Approche basé sur l'équipe Fait pour développer des produits/applications nécessitant une grande adaptabilité Contrôler le chaos résultat de conflits d'intérêt et des différents besoins Augmenter la communication et maximiser la coopération Protéger l'équipe des éléments externes perturbateurs Un moyen d'augmenter la productivité

1995 1996 2001 Introduction (4/5) Historique Analyse des processus communs au développement Scrum parJeff Sutherland & Ken Schwaber Renforcement de Scrum par Mike Beedle & combinaison de Scrum avec Extreme Programming 1996 Introduction de Scrum à la OOPSLA conférence 1995: Analyse des processus communs au développement : non adapté à l’imprévu, aux répétitions Design d’une nouvelle méthode : Scrum parJeff Sutherland & Ken Schwaber Renforcement de Scrum par Mike Beedle & combinaison de Scrum avec Extreme Programming 1996: introduction de Scrum à la OOPSLA conference 2001: publication de “Agile Software Development with Scrum” par Ken Schwaber & Mike Beedle De nos jours l’application de SCRUM est un succès sur plus de 50 entreprises 2001 Publication de “Agile Software Development with Scrum” par Ken Schwaber & Mike Beedle

Introduction (5/5) Requis Equipe responsable, en auto-organisation Avancement du produit par une série de « sprints » Exigences définies Pas de prescription de pratiques d’ingénierie Utilisation de règles génériques SCRUM s'impose comme un modèle d'efficacité, pronant l'expression : "aller à l'essentiel". Voici donc ce qu'il faut pour mettre en place correctement une méthodologie SCRUM efficace : Equipe responsable, en auto-organisation : l'équipe de développement se doit d'être autonome pour palier aux éventuels changements d'un client trop indécis. Avancement du produit par une série de « sprints » : les itérations sont courtes, 2 à 4 semaines au plus, pour permettre des interventions rapides en cas de problèmes. Exigences définies : en fait d'exigences, on parlera surtout d'éléments à mettre en oeuvre. Ces éléments sont regroupés sous l'appelation de "Backlog du produit". Pas de prescription de pratiques d’ingénierie : on reste dans un esprit d'autonomie de développement. Utilisation de règles génériques : on permet l'établissement d'un environnement agile propre au projet.

Concepts (1/8) Directeur de produit (Product Owner) SCRUM Master Rôles Directeur de produit (Product Owner) SCRUM Master Equipe SCRUM (SCRUM team)

Concepts (2/8) Rôles SCRUM Master Client Clients Client Intervenants Directeur de produit SCRUM Master Elément perturbateur Directeur de produit : Le Directeur de produit, ou Product Owner en anglais, représente à la fois les clients et les utilisateurs. Mais le terme de directeur est ici à prendre au sens de guide plus que de chef hiérarchique. En effet, ses responsabilités se bornent à l'établissement des limites du projets et de chaque itératon. L'avantage du Directeur de Produit est sa relation avec le client. Il peut néanmoins et pour des raisons évidentes de productivité travailler dans le même espace que l'équipe de développement. Celui-ci sachant de façon précise les attentes du client, il peut répondre directement interrogations des collaborateurs. Finalement, le Directeur de Produit définit les fonctionnalités du produit. Voici une liste de ses responsabilités : Choisit la date et le contenu de la release Responsable du retour sur investissement Définit les priorités dans le backlog en fonction de la valeur « métier » Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire Scrum master Le SCRUM Master représente le management du projet. On l'assigne bien souvent au rôle de manager de projet ou de Chef d'équipe. Son travail principal consiste remédier aux imprévus. C'est celui qui interviens dans le cas ou une situation ou un événement peut empêcher ou retarder la progression du travail prévu au cours du sprint. Voici quelques unes de ces caractéristiques : Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum Résout des problèmes S'assure que l'équipe est complètement fonctionnelle et productive Facilite une coopération poussée entre tous les rôles et fonctions Protège l'équipe des interférences extérieures Equipe SCRUM: Une bonne équipe SCRUM est assez réduite et comporte finalement 5 à 10 personnes. L'échange est un atout primordial dans l'utilisation de SCRUM, il faut donc garder l'aspect dialogue au sein de son équipe de développement. Une équipe trop grande amène souvent plus de dissension que d'approbation. Les caractéristiques d'une bonne équipe : Regroupant tous les rôles : Architecte, concepteur, développeur, spécialiste IHM, testeur, etc. A plein temps sur le projet, de préférence Exceptions possibles (administrateur, …)‏ Organisation autonome La composition de l’équipe ne doit pas changer pendant un Sprint. Membre de l’équipe Membre de l’équipe Membre de l’équipe Membre de l’équipe

Concepts (3/8) Processus Planification par niveau : réunion sur 8h et en deux temps. En première partie 4h avant de manger On effectue la création du Backlog produit On détermine les enjeux du Sprint Participants : Product Owner, SCRUM Master, l'équipe Ce processus du processus de gestion du projet vise à organiser les exigences d’affaires, établir le coût et le calendrier précis du projet (y compris une liste des livrables et leurs dates de livraison), planifier l’organisation du travail et obtenir l’autorisation des gestionnaires. En SCRUM la planification se fait par niveau, chaque niveau correspondant à un Sprint. Une réunion de collabrateur s'effectue généralement sur 8h et en deux temps. En première partie : 4h avant de manger On effectue la création du Backlog produit On détermine les enjeux du Sprint Participants : Product Owner, SCRUM Master, l'équipe Deuxième partie 4h après manger :) Participants: Scrum Master, l'équipe On crée le Backlog de Sprint En SCRUM l'équipe choisit, à partir du backlog de produit, les éléments qu'elle s'engage à finir.Une fois le backlog de sprint est créé, les tâches sont identifiées et estimées (1-16 heures)‏. Finalement on peut alors lancer le Sprint. Deuxième partie 4h après manger Participants: Scrum Master, l'équipe On crée le Backlog de Sprint

Concepts (4/8) Processus Scrum quotidien : Tous les jours 5 minutes Debout Répondre à 3 questions essentielles : qu’est ce que j’ai fais hier? qu’est ce que je fais aujourd’hui? quels sont les problèmes? Le SCRUM meeting est une réunion organisée de la façon suivante : Tous les jours 5 minutes Debout Le SCRUM meeting n'est pas fait pour ésoudre mais plutot pour identifier les problèmes. Finalement Tout le monde peut participer au meeting, mais seuls les membres de l'équipe peuvent parlés. Le SCRUM meeting est effectué pour répondre à 3 questions essentielles : qu’est ce que j’ai fais hier? qu’est ce que je fais aujourd’hui? quels sont les problèmes? Toute l'quipe interviens et le tour de parole doit être scrupuleusement respecté pour éviter que le SCRUM dérive sur des discussions techniques et déborde des 15 minutes. Si le besoin s'en fait sentir, des discussions sont alors menées librement après le SCRUM.

Concepts (5/8) Processus Revue du Sprint Maximum 4 heures Objectif : validation du logiciel produit pendant le sprint. Démonstration de nouvelles fonctionnalités ou de l'architecture : des livrables Représentation informelle Préparation < 2 heures Revue du Sprint A la fin du sprint, tout le monde se réunit pour effectuer la Revue de sprint, qui dure au maximum 4 heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint. L'équipe présente ce qu'elle a fait pendant le sprint. Habituellement la revue de Sprint se fait avec une démonstration des nouvelles fonctionnalités ou de l'architecture ( des livrables) La Revue de Sprint est une rpésentation informelle. Ici il ne s'agit pas de présenter un PowerPoint ou tout autre diapositives, l'idée est ici simplement de montré ce qui a été réalisé et qui donc fonctionne. La préparation est simple et nécessite généralement moins de 2 heures. Tout le monde peut participer à cette présentation. Rétrospective Cette étape est une démarche courante en fin de projet. En SCRUM elle s'effectue à chaque fin de Sprint. L'idée ici est de réfléchir régulièrement à ce qui marche et ce qui ne marche pas. Pour cela l'équipe prend en général 15 à 30 minutes pour se réunir et faire un point. On applique ici un principe de Start / Stop / Continue : ce qu’on aimerait faire, arreter de faire, continuer a faire. Rétrospective A chaque fin de Sprint Ce qui marche / ce qui ne marche pas 15 à 30 minutes Start / Stop / Continue

Concepts (6/8) Artefacts Backlog du produit (ou catalogue des besoins) Besoins priorisé par le product owner Besoins évalués par l’équipe Les exigences Une liste de tout ce qui va entraîner du travail pour l'équipe Exprimé de telle façon que chaque élément apporte de la valeur aux utilisateurs ou clients du produit Les priorités sont définies par le Product Owner Les priorités sont revues à chaque sprint

Concepts (7/8) Artefacts Backlog du Sprint Ajustement quotidienne de l'estimation du reste à faire Adaptabilité du backlog Emergence prograssive du travail du sprint Définition de tâche avec plus de temps et sa décomposition après dans le cas de non clarté du travail Mise à jour du travail restant une fois connu Le Backlog de Sprint est un engagement. Chaque développeur s'engage sur un temps de travail pour chaque tâches établies. Suite à cela on évalue quotidiennement grâce aux SCRUM meeting les différences de prévision. Voici les principales caractérisitques du Baclog de produit : L'estimation du reste à faire est ajustée tous les jours Le backlog est adaptable Le travail du sprint émerge progressivement Si un travail n'est pas clair, il faut définir une tâche avec plus de temps et la décomposer après MAJ du travail restant quand il devient connu Il est interressant de noter que le travail en SCRUM n'est jamais assigné par un autre. N'importe qui peut ajouter, supprimer ou modifier le Backlog de Sprint tant que l'assignation se fait personnellement.

Concepts (8/8) Artefacts Histoire À faire En cours À vérifier Fait En tant qu’utilisateur, je … 8 points Coder le … 9 points Coder le … 3 points Tester le … 2 points Coder le … 9 points Coder le … 9 points Tester le … 9 points Coder le … 2 points Coder le … 2 points Coder le … 9 points Tester le … 9 points Coder le … 9 points Maintenant que nous savons comment lister les tâches il est interressant de savoir comment visualiser l'avancement du projet, et surtout des Sprints inhérent au projet. Pour ce faire nous avons ce que la terminologie SCRUM nommme un Burndown Chart et dont un exemple est fourni ci-dessous Le Brundown Chart est un indicateur temporelle de l'évolution des tâches en cours dans le Sprint. Nous disions précédement que le travail de l'équipe était adaptable et attribué de façon personnelle à chaque membre. Mais l'objectif restant de pouvoir, à chaque instant, visualiser l'état du projet, SCRUM met en place ce que l'on nomme le SCRUM Board et qui réflechit sous forme de post-it sur un tableau : Les tâches à faire Les tâches en cours les tâches terminées Une version plus avancée peut être rencontrée, version dans laquelle on identifie des tâches de vérification : Tester le … 8 points Tester le … 1 points En tant qu’utilisateur, je … 5 points Coder le … 4 points Coder le … 3 points Coder le … 9 points Coder le 9 points Tester le … 9 points Coder le … 9 points Tester le … 8 points Tester le … 6 points Tester le … 3 points

Perspectives (1/2) Backlog de produit normalisé Backlog de Sprint Niveau bas Backlog de Sprint Réunion de planning de Sprint Niveau haut Synchronisation Équipe C Équipe B Comme nous le disions précédement, l'équipe de SCRUM typique comporte entre 2 et 7 membres. Mais la méthodologie SCRUM ne connaitrait pas un tel essort si elle était restreinte au management d'équipe légère. Nous allons donc voir comment il est possible d'obtenir un management dit "de grande échelle". Selon Jeff Sutherland, co-fondateur de la méthode SCRUM, il est possible d'utiliser SCRUM dans un contexte intégrant plus de 800 personnes. Bien évidement certains facteurs doivent etre pris en compte pour maintenir une cohérence dans la gestion des équipes. Ces facterus les voici : Type d'application Taille de l'équipe Répartition géographique des équipes Durée du projet Finalement chaque équipe possède un travail bien précis a réalisé dans ses propres Sprint. Dans la pratique SCRUM a été utilisé pour de nombreux projets de plus de 500 personnes. On nomme la méthode pour réaliser des opérations de cette envergure : le SCRUM de SCRUM Réunion de planning de Sprint Sprint Équipe A 30j Synchronisation Réunions quotidiennes SCRUM 24h Réunion quotidienne SCRUM de SCRUM 24h

Perspectives (2/2) L'organisation d'un SCRUM de SCRUM, ou encore nommé Meta-SCRUM s'effectue en placant des sous communauté SCRUM entre les équipes. Ces sous ensemble regroupe simplement des SCRUM Master des différentes équipes, qui on eux aussi un SCRUM Master principal, pouvant lui même faire partie d'un groupe de SCRUM Master plus haut placé, et ainsi de suite jusqu'à un groupe dominant le projet. Le graphique ci-dessous représente une façon de regouper les collaborauteurs avec un design de base de 3 groupes de 9 équipes distinctes. Dans ces projets-ci la fréquence des réunions est établie selon le degré dans l'échelle des responsabilités

Conclusion Avantages SCRUM Inconvénients SCRUM Entièrement développé et testé pour de courtes itérations Simplicité des processus Règles définies clairement Augmentation de productivité Organisation personnelle Chaque équipe a son lot de responsabilité Amélioration de la communication Combinaison possible avec XP Peu, voire pas, de documentation écrite Violation de responsabilité L'équipe ne se prête pas au SCRUM Nous avons vu en introduction une analyse concrète de la rentabilité produite par SCRUM. Néanmoins il serait assez orgueuilleux de dire que SCRUM a réonse a tout et en tout temps. Je me propose donc de vous faire partager une analyse de ma propre expérience SCRUM afin de mieux comprendre les avantages et les inconvenients de cette méthode. Comme je le note dans le tableau il reste encore certains désavantages à utiliser SCRUM. Le gros problème réside bien souvent dans l'aspect Documentation du projet. Comme la méthode privilégie le fonctionnel, on se retrouve rapidement avec des projets non-documentés. Les autres poins sont des parties inhérents à l'autonomie des collaborateurs. Il est clair que si l'équipe ne prends pas le temps de remplir correctement les indicateurs comme le SCRUM Board et les Burndow Chart, le suivi n'est pas correctement assuré. D'utres part on remarque bien souvent que dans la gestion du SCRUM de SCRUM les manager sont tentés de passer outre les responsabilités hierrachiques pour aller remonter le problème au sommet. On constate bien souvent ce problème dans des équipes ou un développeur requiert directement le client plutôt que son propre SCRUM master, ou Directeur de Produit.

Cas pratique (1/6) Application IRITAorganiser : Organisateur complet Description Un organisateur qui regroupe un agenda, un gestionnaire de planning/emploi du temps, un gestionnaire de budget, un client de courrier électronique et un gestionnaire de tâches dans une même application. Durée totale 15 semaines

Cas pratique (2/6) Participants : Client : M. Naoufel Kraiem Product Owner : Ines Gherab SCRUM Master : Rania Ben Ismail Equipe : Imen Sadki et Takwa Bouallegue Durée du Sprint Une semaine

Cas pratique (4/6) Back log du produit (Exigences) 1 2 3 4 5 6 7 être sécurisée par mot de passe, 2 gérer les différentes vues par année, par mois et par jour du calendrier, 3 manipuler le courrier électronique du client entre boîte d’envoi et boîte de réception, 4 gérer le planning et l’emploi du temps, 5 contrôler le budget du client en termes de revenus et de dépenses, 6 mémoriser des tâches à faire, les lister et leur assigner des priorités, 7 afficher une interface qui organise toutes les fonctionnalités de l’application.

But du Sprint Cas pratique (5/6) Offrir une interface sécurisée par un mot de passe permettant d’accéder à la gestion des tâches quotidiennes du client.

Cas pratique (6/6)

Merci pour votre attention.