Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Gestion de projet Agile avec SCRUM

Par Angoua Omer N'dry N'GORAN Publié le 31/10/2016 à 23:44:39 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Les Origines

SCRUM a été formalisé en 1995 par:

Jeff Sutherland

et Ken Schwaber

Définition de SCRUM

SCRUM est défini par ses créateurs comme un « Framework »

(Cadre de travail permettant de répondre à des problèmes complexes et changeants tout en livrant de manière

productive et créative des produits de la plus grande valeur possible).

Scrum est léger (Lightweight),facile à comprendre (Simple to understand) mais difficile à maîtriser (Extremely difficult to master).

Scrum est un processus agile qui produit tous les 30 jours (= 1 SPRINT (TimeBox)) du logiciel qui fonctionne.

Les exigences et les priorités sont définies dans le Product Backlog géré par le productOwner.

L'équipe Scrum s'auto-organise et définit les sprints de release avec le PO et SM.

A chaque fin de Sprint, la décision de livrer le produit dans l'état ou de continuer à l'améliorer est prise. On retrouve bien l’aspect itératif et incrémental.

Un framework Scrum est constitué:

  • d'une équipe (ScrumTeam)

  • de rôles (PO, SM, Team)

  • d'évènements (avec Time-box (planification,…)

  • d'artefacts

Les 3 piliers de Scrum sont:

Transparence : Avoir un langage commun entre l’équipe, le management, le client. Exemple fait, pas fait,…

Inspection : Le point est fait sur les différents artefacts produits, afin de détecter toute variation indésirable.

Adaptation: Si on constate une dérive lors de l’inspection, on ajuste directement et pour les prochaines fois.

Les rôles dans Scrum

Product Owner

C'est le responsable du projet ainsi que de la gestion, le contrôle et la visibilité du Product Backlog.

Il s'assure de la valeur du travail fourni par l'équipe.

Il est selectionné par le management, le client et le Scrum Master.

Ses caractéristiques:

  • Visionnaire

  • Leader et Team Player

  • Communicateur et Negociateur

  • Concerné et Engagé

  • Disponible et Qualifié

Collaboration:

  • Collaboration avec l'équipe SCRUM

    • Lui même membre de la SCRUM Team

    • Le Product Owner doit se trouver sur le même site que la SCRUM Team

  • Collaboration avec le SCRUM Master

    • Rôles complémentaires

    • Product Owner est responsable du "QUOI"

    • SCRUM Master est responsable du "COMMENT"

    • Une personne ne doit pas cumuler les 2 rôles

Ajustement du rôle:

  • Pour les grands projets SCRUM

    • Difficile pour un Product Owner de s'occuper de plus de 2 SCRUM Team

    • Quid de projets comprenant plus de 2 SCRUM Team alors que le Product Owner est unique?

  • Introduction du rôle du Chief Product Owner

    • Responsable de coordonner différents Product Owner

    • Responsable de la vision du produit

Erreurs à éviter:

  • Ne pas donner assez de pouvoir au Product Owner

    • Il ne dispose pas assez d'autonomie

  • Surcharger le Product Owner

    • Pas soutenable

    • Devient le bottleneck du projet

  • Ne pas séparer les tâches du Product Owner entre différentes personnes

Le Scrum Master

Il est responsable de la bonne utilisation des pratiques, valeurs et règles de la méthode Scrum, de l'avancement du developpement,

et il s'engage à supprimer tous les freins à l'avancement du projet (manager)

Le SCRUM Master:

  • est le garant de l'application du processus Scrum

  • aide l'équipe à travailler de façon autonome et à s'améliorer constamment

  • anime les réunions de Pré-Sprint, Scrum, Post-Sprint

  • élimine les obstacles qui ralentissent l'équipe

  • communique avec le management (ex. rapports d'avancement)

Les caractéristiques :

  • Bien connaître SCRUM

  • Talent de communication

  • Pouvoir résoudre les conflits

  • Etre capable de guider sans imposer

Erreurs à éviter:

  • Le SCRUM Master n'est pas un chef de projet

  • Il ne dirige pas, il n'impose pas, il ne contraint pas

  • Il fait partie de l'équipe

La ScrumTeam

Elle(l'équipe) est responsable du déroulement de chaque Sprint, c-à-d, ce qui est mis en oeuvre pour atteindre les objectifs du Sprint,

elle est impliqué dans l'estimation de la charge de travail,la création du Sprint Backlog et l'identification des freins à l'avancement du projet.

Le Processus

Processus SCRUM

Un processus SCRUM consiste en 3 phases:

La phase Initiale

La phase de Sprints

La phase de Clôture

Phase Initiale

La phase de planning aboutit à:

  • La conceptualisation et l'analyse du système

  • La mise en place d'un "Product Backlog", c'est à dire une liste de tâches “restant” à effectuer

  • La définition approximative de la date de livraison

  • La définition des fonctionnalités à livrer

  • La formation de l'équipe de développement

  • L'analyse du risque et des coûts

Phase de sprint

  • La phase où le développement est, à proprement parlé, réalisé (analyse, conception, implémentation... de chaque élément)

  • Les sprints sont guidés par une liste de tâches provenant du Product Backlog formant le Sprint Backlog

  • Durée de +/- 30 jours (tend à devenir 2 semaines)

  • Isolation de l'équipe de toute influence extérieure

Sprint Planning Meeting

Réunion de pré-Sprint organisée par le SCRUM Master en 2-temps:

  • 1ère Phase: Clients, utilisateurs, management, product owner et Scrum Team établissent le Sprint Backlog

  • 2ième Phase: Le Scrum Master et la Scrum Team organise le déroulement du Sprint

TIMEBOX: 2 heures par semaine de SPRINT

Daily Scrum

Participation quotidienne aux réunions Scrum

  • partager les connaissances acquises

  • faire un point sur l'avancement

  • donner au management une certaine visibilité sur la progression du projet

Contrôle continu et empirique via 3 questions quotidiennes:

  • qu'est ce qui a été fait pendant la journée ?

  • que reste-il à faire ?

  • quels sont les obstacles qui gênent l'avancement du projet ?

Deroulement du Daily scrum:

  • Réunion quotidienne informelle de toute l'équipe

  • Toujours à la même heure et au même endroit

  • N'interviennent que les personnes qui travaillent effectivement sur le développement

  • Les extérieurs y sont invités pour suivre l'avancement du projet

  • TIMEBOX: 15 à 30 minutes max

  • Le Scrum Master prend les décisions que l'équipe est incapable de prendre par elle même et s'engage à apporter une solution à tout ce qui entrave le développement du projet

  • Permet la synchronisation quotidienne de l'équipe et le partage des connaissances

Sprint Review
  • Réunion informelle

  • L'équipe présente au client ce qui a été développé pendant les 30 jours précédents via une démonstration

  • Confronter les résultats du travail de l'équipe avec la complexité et le chaos de l'environnement dans lequel l'application sera utilisée

  • Décision de release ou non

  • TIMEBOX: 1 heure par semaine de Sprint

Sprint Retrospective
  • Réunion ayant lieu après le Sprint Review et avant le Sprint Planning Meeting

  • Le but du Sprint Retrospective est de: o Inspecter la manière dont s'est déroulée le Sprint précédent quant aux personnes, relations, processus et outils utilisés

  • Identifier et ordonner les éléments majeurs qui se sont déroulés ainsi que les améliorations potentielles

  • Créer un plan pour implémenter des améliorations quant à la manière de travailler de l'équipe Scrum

  • TIMEBOX: 3 heures pour 4 semaines de Sprint

Phase de Clôture

Préparation du produit pour une livraison:

  • intégration,

  • tests systèmes,

  • documentation utilisateur,

  • préparation de supports de formation,

  • préparation de supports marketing

Itération

Le product Backlog

Les qualités du Product Backlog

4 Qualités: DEEP

  • Detailed Appropriately

  • Estimated

  • Emergent

  • Prioritized

Entretenir le product backlog
  • Processus continu qui assure les 4 qualités du Product Backlog comprenant:

    • Ajout, modification, suppression d'éléments (Emergent)

    • Prioritisation (plus important en haut)

    • Estimation des éléments via le planning poker

    • Les éléments hautement prioritaires sont décomposés et raffinés en vue de la réunion du planning de Sprint (Detailed Appropriately)

  • Processus collaboratif:

    • Toute l'équipe Scrum y participe

    • Communication en face-à-face plutôt qu'au travers de documents

  • Responsabilité du Product Owner

Détaillé de manière appropriée
  • Les éléments du product backlog sont des user story

    • En tant que [rôle], je veux [action] afin de [but]

  • Exemple:

    • En tant qu'utilisateur, je veux pouvoir rechercher mes clients par leur prénom et leur nom de famille afin de les retrouver rapidement lorsque je reçois un appel de leur part.

    • En tant qu’étudiant, je veux m’inscrire à une formation afin d’obtenir le diplôme.

Pourquoi utiliser des user stories?

  • Suscite la communication verbale

  • Compréhensible pour chacun

  • Taille appropriée pour la planification

  • Fonctionne bien dans des procéssus itératifs

User Story:

  • Indépendante

  • Négociable

  • Valeur

  • Estimable

  • Small

  • Testable

Eléments Estimés
  • Connaître la charge de travail aide à donner des priorités aux éléments

  • Estimation grossière exprimée en nombre Story Points

    • Jour idéal de travail

    • Effort à fournir - NUT (Nebulous Units of Time)

      • Effort vs Complexité

  • Les estimations sont réalisées par les membres de la Scrum Team

  • Le Product Owner et le Scrum Master ne doivent ni participer, ni influencer l'estimation

  • Story points

    • Mesure relative de l'effort à fournir

    • Planning Poker

    • Le responsable de produit explique à l'équipe

    • Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui permettront de le considérer comme "terminé".

    • Chaque membre dépose une carte avec une valeur de l'échelle face cachée

    • Si il y a des divergences, les deux extrêmes présentent leur motivations

    • On réitère l'opération jusqu'à convergence

Planning Poker

Quelques bonnes pratiques:

  • Spécifier un intervalle de temps par tour de table (ex.: 2min max) et le chronometrer

  • Eviter d’influencer l’estimation avec des “Je pense que ce sera vite fait” ou “Ca risque de prendre des semaines… si pas des mois”

  • Ne jamais prononcer son estimation tant que tous les autres membres n’ont pas estimé

  • Toujours obtenir un consensus plutôt qu’une moyenne

  • Ceux qui votent sont ceux qui feront le boulot (le Product Owner ne vote pas)

Emergent
  • Le contenu du product backlog change continuellement:

    • De nouveaux éléments sont ajoutés

    • Des éléments sont modifiés

    • Des éléments sont supprimés

Priorisés
  • Valeur apportée aux clients/utilisateurs

    • « Quel est le bénéfice financier à développer cette fonctionnalité ? »

  • Coût de développement estimé

    • « Quel est le coût de développement ? De maintenance ? De formation des utilisateurs ? »

    • « Quel est le coût d’un changement ? »

  • Opportunité d'apprentissage pour l'équipe « L’implémentation de cette fonctionnalité nous permet-elle d’apprendre ou de développer de nouvelles compétences ? »

    • « Cette fonctionnalité va-t-elle améliorer la productivité de mon personnel ? »

  • Le risque de développement

    • « Cette fonctionnalité nous expose-t-elle à davantage de risques ? Ou, au contraire, nous permet-elle de nous confronter au risque ? »

    • « Cette fonctionnalité va-t-elle impacter les processus métier ? »

    • « Cette fonctionnalité va-t-elle susciter de la frustration ou de la résistance ? »

    • « Quel est le préjudice si cette fonctionnalité n’est pas implémentée ? »

Etendue du Product Backlog dans de larges projets
  • Utilisé un seul Product Backlog

    • Permet d'éviter les problèmes de synchronisation

  • Préparer les éléments pour les 2 à 3 Sprints suivants

    • Les nombres d'éléments détaillés est donc plus important

  • Proposer différentes vues pour les différentes teams SCRUM

Release et sprints

Les Releases

La problématique de la planification Avec une méthode Agile,

définition de:

  • La vision

  • Des moyens o Permet la définition d'un budget

  • Des étapes (chemin à suivre)

    • Plan initiale a moins une valeur contractuelle que dans traditionnelle

    • Affiné au fur et à mesure de l'avancement du projet

  • Planification au fil de l'eau

    • Acceptation de l'incertitude

    • La fiabilité des estimations augmente avec les enseignements des itérations précédentes

Estimer les durées

  • Principe de vélocité v

    • La somme des story points qu’une équipe est capable de développer durant une itération

  • Valeur hypothétique au début du projet et s'affine au fur et à mesure des itérations

  • Après une première itération, on peut estimer une durée réaliste du projet

    • Durée du projet = (Somme SP) / v

  • Estimer la vélocité initiale

    • Données historiques

    • Après la première itération

5 niveaux de planification

  • Etablissement de la vision

    • Livraison finale (à partir du PB)

  • Etablissement d'une roadmap

    • Les différentes releases

  • Planification d'une release

    • Les différents Sprint aboutissant à la release

  • Planification d'un SPRINT

    • Les différentes user stories à réaliser durant cette itération

  • SCRUM

    • Réajustement du planning

  • Trois variables de décision à considérer pour plannifier une release

    • TempsLa date de lancement est-elle fixe?

    • CoûtsLe budget de développement est-il fixe?

    • FonctionnalitésUn certain niveau de fonctionnalité doit-il être assuré pour une release?

  • Fixer les trois variables est impossible

  • Fixer les fonctionnalités

    • Ne prend pas en compte l'émergence des exigences

    • Limite la capacité d'adaptation de l'équipe aux besoins du client

  • Fixer un prix (enveloppe budgétaire)

    • Arrêt du développement lorsque:

      • Toutes les fonctionnalités sont implémentées ou,

      • Le budget est consommé

  • Fixer un prix (enveloppe budgétaire)

    • Arrêt du développement lorsque:

      • Toutes les fonctionnalités sont implémentées ou,

      • Le budget est consommé

  • Fixer un prix et un ensemble de fonctionnalités

    • A éviter

    • Séparer le contrat en deux projets consécutifs

      • 1. Créer la vision du produit et partiellement l'implémenter en 2 ou 3 sprints

      • 2. Créer un planning de releases sur la base du Product Backlog avec un budget réaliste

Erreurs courantes

  • Pas d'utilisation du Release Burndown

  • Big-Bang Release

  • Délivrer un maximum de fonctionnalités au détriment de la qualité

Les Sprints

Définition du done

  • Les critères sur la définition du done sont définis avant le premier Sprint par:

    • Le Product Owner

    • Le Scrum Master

    • La Scrum Team

  • Typiquement, un élément du produt backlog est considéré comme achevé lorsque:

    • il est implementé

    • il est testé

    • il est documenté

Les SCRUM

  • Permet à la Scrum Team de:

    • gérer son travail

    • soulever les freins à l'avancement du projet

  • Le Product Owner peut répondre à certaines interrogations de l'équipe

Les Sprints Backlog et Burndown

  • Sprint Backlog

    • Contient les différents éléments à implémenter

  • Sprint Burndown

    • Visualise la progression du Sprint

    • Visualise la probabilité d'atteindre les objectifs

Le produit

Les Difficultés du recueil

  • Recueillir les besoins présentent 3 problèmes majeurs:

    • Une mauvaise communication

    • L'illusoire exhaustivité

    • La défaillance du client

Une mauvaise communication

  • Divergences possibles entre:

    • la représentation qu’a le client de son futur produit

    • la difficulté éventuelle qu’il rencontre à le décrire

    • l’interprétation possible de cette description par l’équipe de réalisation

    • l’outil qui lui est livré au final

La vision du produit

Les questions à se poser:

  • Qui va acheter le produit? Qui va utiliser le produit?

  • Quels besoins vont être satisfaits par le produit? Qu'est ce que le produit ajoute de plus?

  • Quels sont les attributs critiques pour répondre à ces besoins?

  • Comment se comporte le produit par rapport à la concurrence?

  • Quel est le business model?

  • Le produit est-il réalisable?

Les qualités de la vision

  • Partagée et unifiée

    • Permet d'aligner les efforts fournis par la Team

  • Large et engageante

    • Guide le développement mais laisse la place à la créativité

  • Brève et concise

    • Ne contient que l'information critique au succès du produit

Formaliser et exprimer les besoins

  • Use Cases (Cas d'utilisations)

    • Modélisation UML

    • Décrit les échanges entre le système et les acteurs externes (utilisateurs ou autres systèmes) pour un contexte particulier

    • Décrit les différentes étapes pour les séquences:

      • nominales

      • d'exception

  • User Stories

    • En tant que ..., je veux ... afin de ...

Les erreurs courantes

  • Pas de vision o Produit limité à un ensemble de features

  • Vision prophétique o Capacité limité de projection

  • Analyse sans fin des besoins o Peur de l'échec

  • "On sait ce qui est bon pour le client"

  • "Big is beautiful"

Bibliographie

Agile Product Management with Scrum, Creating Products that Customers Love, Roman Pichler, Addison-Wesley, 2010

Gestion de projet, Vers les méthodes Agiles, Véronique Messager Rota, Eyrolles, 2007

The Scrum Guide, The definitive Guide to Scrum: The Rules of the Game, Ken Schwaber, Jeff Sutherland, Scrum.org, 2011

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels