Scrum - Ce qu'il faut en connaître

Scrum - Ce qu'il faut en connaître

> Vous vous intéressez au rugby, alors peut-être connaissez-vous déjà le mot Scrum, terme anglais qui désigne la « mêlée ». Cette image d'effort puissant d'un collectif d'hommes soudés a été reprise pour qualifier une méthodologie de programmation qui fait partie - tout comme l'eXtreme Programming déjà traité dans un précédent article - des méthodes dites « Agiles » .

Qu'est-ce que SCRUM ?

 Une méthode « Agile » parmi d'autres

> Scrum - comme XP ou Crystal - est un processus « Agile » qui progresse de façon itérative et incrémentale et vise à développer un produit (ou d'ailleurs gérer n'importe quel type de tâche) en livrant un ensemble de fonctionalités à la fin de chaque cycle. Il focalise naturellement l'énergie d'une organisation toute entière sur le succès de l'élaboration des produits. Scrum peut être mis en œuvre dès le début d'un projet mais également en cours de projet ou lorsque le processus de développement rencontre une difficulté. Il génère le meilleur produit possible dans les conditions de ressources allouées, de niveau de qualité requis et de délais de livraison fixé. Des fonctions utiles doivent être livrées tous les trente jours en même temps que le cahier des charges, l'architecture et le design prennent forme, et ceci, même si les technologies utilisées sont instables.

 Traits caractéristiques de Scrum

> En voici les plus grands traits tels qu'ils sont formulés par les auteurs :

  • Cette méthodologie est ndépendante des pratiques existantes d'ingéniérie, elle ne fait que les envelopper.
  • Elle est basée sur l'équipe une (ou des équipes) qui s'autogère(nt), elle permet de développer de façon itérative et incrémentale des systèmes et des produits dont le cahier des charges peut rapidement changer.
  • Elle permet ou aspire à contrôler le chaos liés aux conflits d'intétêts et de besoins.
  • Elle permet d'améliorer la communication et de maximiser la coopération entre les membres de l'équipe.
  • Elle permet de détecter et de provoquer le retrait de tout ce qui peut faire obstacle au développement et à la livraison des produits.
  • Elle permet de maximiser la productivité de l'équipe.
  • Elle est ajustable à l'échelon de projets simples ou plus complexes à l'échelon d'entreprises toutes entières
  • C'est une façon de travailler qui permet à tout un chacun d'être satisfait dans son ouvrage, de sa contribution, grâce au sentiment d'avoir effectué sa tâche le mieux que possible.

 Scrum en action

> Depuis son élaboration, la méthodologie Scrum a été mis en œuvre dans des dixaines d'entreprises pour des milliers de projets où elle a contribué à une amélioration significative de productivité. Il a permis de sortir de l'ornière de nombreux projets (produits financiers, internet ou médicaux) qui semblaient dans l'impasse et mettaient en péril la santé de l'entreprise. Entre autres, cette méthodologie a été utilisée pour construire Windows NT™ (approximativement 4 millions de lignes de code C et C++) ou le logiciel Quattro Pro™ de la firme Borland™.

Génèse de Scrum

 Problématique

> Confrontées à une absence d'accroissement de productivité lors du développement de logiciel en programmation orientée objet (POO), les firmes Advanced Development Methods (ADM) et VMARK Software (VMARK) décidèrent - dans la fin des années 80 - de faire cause commune pour essayer de remédier à cet état de fait. Les méthodes de programmations utilisées à l'époque semblaient être un frein à la POO et au développement basée sur les composants.

> Ken SCHWABER et Jeff SUTHERLAND qui participaient à plusieurs projets qui stagnaient avec des difficultés pour livrer des solutions logicielles, mirent en place quelques principes simples afin d'aider les acteurs de ces groupes de travail à améliorer leur performance. C'est de ces expériences qu'ils ont tirés les grands principes de la méthodologie Scrum.

 Analyse du problème

> L'analyse de la manière dont les Sociétés de Services Informatiques (SSI) qui réussissaient menaient à bien l'élaboration de leurs logiciels, alors que d'autres se référant au Capability Maturity Model (CMM) du Software Engineering Institute n'y arrivaient pas, a permis à ces auteurs de constater que les processus étaient assez similaires :

  • Toutes utilisaient des méthodes empiriques.
  • Ces méthodes empiriques étaient contrôlées par des mesures quantitatives.
  • Le résultat de ces méthodes était qualifié de « meilleur logiciel possible » (the best possible software) ou « logiciel suffisamment bon » (good enough software).

> L'analyse mettaient aussi en évidence le fait que la construction de systèmes informatiques, comme tout processus créatif artistique (peinture, écriture ou architecture) , est guidée par un ensemble de règles, d'astuces et de techniques. Si la méthode fournit un canevas qui dit comment s'y prendre et identifie les parties où il faut faire preuve de créativité, la créativité demeure un élément indispensable.

Pourquoi la mise en application du CMM ne donne pas les résultats escomptés ?

> Lorsque la question fut posée à un scientifique de l'industrie chimique, il commença par expliquer la différence entre un système prévisible (défini) et imprévisible (empirique) :

  • Si un processus peut être entièrement défini, on connaît tout sur lui. On peut alors le modéliser et le faire tourner de manière répétée avec des résultats prévisibles. Il peut être automatisé.
  • .Si tous les paramètres du système ne sont pas connus, les processus son dits empiriques. On se contente alors de mélanger les entrées et ce qu'il est nécessaire de mesurer et de contrôler les paramètres qui permettent d'obtenir le résultat recherché.

> Alors qu'un processus défini est prévisible, l'empirique requière une surveillance et un contrôle étroit avec des interventions fréquentes guidées par un monitoring intelligent. La modélisation d'un processus empirique s'appuie sur la stricte exploitation des données expérimentales d'entrée / sortie de système, sans recours à aucune loi concernant les propriétés fondamentales du système. Aucune connaissance a priori sur le système n'est requise, le processus est traité comme une boîte noire.

> En ce qui concerne le processus de développement de logiciel, le scientifique conclut après analyse qu'ils sont principalement de nature empirique pour les raisons suivantes :

  • il n'existe pas de lois fondamentales applicables ; 
  • on commence seulement à comprendre le processus ;
  • le processus est complexe ;
  • le processus est changeant et imprévisible.

Complexité d'un système
Degré de complexité d'un projet

L'application d'un système de modélisation déterministe tel que le CMM à ce processus est abérant car il génère des résultats erratiques qui stérilisent l'effort de développement.

> Les SSI qui ont le vent en poupe, en adoptant un processus empirique de développement (« do what it takes »), ont su surmonter le degré croissant de complexité et d'incertitude liée au chaos dans lequel sont développés leurs produits. Ce chaos existe tant dans le marché où on souhaite distribuer le produit et que dans le domaine des technologies qu'ils utilisent pour concevoir et bâtir leur produits. C'est la maîtise de ce chaos qui fait leur fortune.

Scrum, un processus empirique de développement

> En 1996, Ken SCHWABER et Jeff SUTHERLAND donnent enfin officiellement naissance à Scrum avec la publication du premier article traitant de cette méthodologie, fruit de la synthèse de leurs investigations.

  • Scrum s'y dessine comme une approche itérative, incrémentale du développement logiciel.
  • Les interactions avec l'environnement technique, compétitif et les utilisatateurs y sont autorisés ce qui peut amener à modifier la portée du projet, sa technologie, ses fonctionnalités, son coût et sa plannification si nécessaire.
  • L'utilisation de contrôles permet d'en mesurer et d'en gérer l'impact.
  • Scrum intègre le fait que le processus de développement est imprévisible. Le produit livré est « meilleur logiciel possible » compte tenu des contraintes de coût , de délai, de fonctionnalités et de qualité.

Scrum - Caractéristiques et Règles

Inclure ce qui marche le mieux dans les SSI les plus performantes

> Grâce à leur analyse, les inventeurs de cette méthodologie on donc extrait ce qui faisait la force de certaines organisations. Ainsi, plusieurs des caractéristiques qui guident chez Microsoft le processus de développement grâce à l'approche dite « du chaos contrôlé », sont inhérentes à Scrum :

  • Tronçonner des produits trop volumineux en morceaux plus gérables - des sous-produits dotés de peu de fonctions que des petites équipes peuvent créer en quelques mois.
  • Permettre au projet d'avancer de manière systématique, même lorsque les membres de l'équipe ne sont pas capables de fixer un contour complet et stable pour le produit dès le début du projet.
  • Permettre aux équipes volumineuses de travailler comme de petites équipes en fractionnant les tâches, en les faisant progresser en parallèle avec une synchronisation continue, en les stabilisant lors des incrémentations successives, et en recherchant et résovant les problèmes au fur et à mesure.

> De plus, la réalisation du cahier des charges du produit en s'appuyant sur le rétro-contrôle effectué par les clients/utilisateurs en est facilitée, et les durées de développement courtes intègrent un mécanisme qui permet d'incorporer leurs attentes, d'établir une hiérarchie pour réaliser en priorité les parties les plus importantes et changer ou mettre de côté les caractéristiques moins essentielles.

> Scrum suit également les règles usuelles de ces fameuses SSI :

  • Avoir toujours un produit théoriquement livrable.
  • Parler un langage commun sur un même site de développement.
  • Tester en permanence le produit au fil de son élaboration.

Préceptes clés du processus de développement Scrum

  • De petites équipes de travail,
    afin de maximaliser la communication, minimiser risque de « ras le bol », et maximaliser le partage des connaissances tacites et informelles
  • Une adaptabilité aux changements liés à la technologie ou au marché (utilisateur/consommateur)
    pour assurer l'élaboration du meilleur produit possible
  • Lédition de fréquents builds, ou éléments de code exécutables
    qui peuvent être inspectés, ajustés, testés, documentés et livrés
  • Le fractionnement du travail
    avec assignation aux équipes de partitions ou de paquetages propres et faiblement couplés
  • La mise en œuvre constante de tests et l'édition de la documentation
    au fil de l'élaboration du produit
  • La possibilité de déclarer le produit « fini » chaque fois que cela s'avère nécessaire
    (parce que c'est l'heure de la compétition, l'entreprise a besoin de l'argent, l'utilisateur/consommateur a besoin des fonctions ou parce que simplement, c'est ce qu'on avait promis...)

La méthodologie Scrum regroupe en fait trois processus distincts

> La plannification de l'Architecture du système
Les fonctionnalités du produit et les moyens nécessaires pour leur livraison sont plannifiés sur la base du cahier des charges (Backlog) et des risques estimés. L'aboutissement de ce processus, c'est la conception d'un disign optimal et élégant faisant coïncider les performances attendues du produit avec les impératifs architecturaux.
La définition d'une nouvelle version (release) est fondée sur la partie connue du cahier des charges non encore réalisée, avec une estimation de sa planification et de son coût. Si on développe un nouveau système, il faut en réaliser la conceptualisation et l'analyse. Si le projet correspond à la nouvelle version d'un système existant, l'analyse sera plus limitée.

> Détermination des caractéristiques du Produit de base
L'évolution de l'environnement de l'utilisateur/consommateur, du contexte compétitif et technologique va imposer des modifications des définitions de bases au fil de l'avancement du projet. Un accroissement de productivité lié à l'utilisation de bons outils ou la découvertes de composants déjà existants peut ouvrir l'oportunité d'ajouter des caractéristiques au produit ou de le livrer plus tôt. La gestion du cahier des charges et du risque va permettre de plannifier la livraison du produit en optimisant son contenu et ses chances de succcès dans l'environnement défini et avec les ressources allouées.

> Développement du produit en Environnement contrôlé
Le développement se fera dans un environnement contrôlé, aussi proche que possible de la frontière de la zone de chaos. La clé consiste à épingler la date à laquelle le produit doit être livré, en hiérarchisant les fonctionnalités souhaitées, identifiant les ressources disponibles pour l'effort de développement, envisageant l'architecture de l'application et déterminant l'environnement dans lequel va fonctionner la cible. En comparaison avec d'autres méthodes, la phase de plannification est conduite relativement rapidement car on présume que les gestionnaires pragmatiques du projets et le cours des événements vont apporter leurs lots de modifications.

Scrum et gestion du risque

> La plupart des projets essaient de minimiser les risques. La méthodologie Scrum prend l'identification et la gestion des risques à bras le corps afin de bâtir le meilleur produit possible.

> Un projet logiciel Scrum est contrôlé grâce à l'établissement, la maintenance et la surveillance de paramètres clés. Ces paramètres de contrôle remplacent les contrôles de tâches et de time-reporting utilisés dans le modèle en cascade et autres processus de développement définis. Nous avons vu que ces contrôles sont critiques quand le projet est un processus de type emprique englobant une quantité inconnue d'instabilités et d'imprévisibilités. L'utilisation de ces contrôles est l'épine dorsale du développement Scrum.

On peut estimer grossièrement ces variables en début de projet. Chaque variable commencera à évoluer avec le démarrage du projet, le compromis entre ces différentes variables étant ajusté au fil de l'avancement (amélioration d'une fonctionalité plus tard et quand plus d'argent, etc.).

> Quels types de contrôles la méthodologie Scrum utilise-t-elle ?

  • le Backlog :
    - détermination de la liste identifiant toutes les obligations que doivent être remplies pour élaborer le produit fini (cf. infra)
  • les Objets/Composants :
    - conception d'éléments autosuffisants réutilisables
  • les Paquetages :
    - définition de groupes d'objets au sein desquels un item du backlog va être implémenté. Le couplage entre les objets d'un même packetage est élevé. Le couplage entre paquetage est faible.
  • les Difficultés :
    - identification des difficultés que chaque membre de l'équipe doit surmonter au sein d'un ou plusieurs objets (bogues inclus) pour implémenter un item du backlog
  • les Problèmes :
    - identification des problèmes qui doivent être résolus avant d'assigner un item du backlog à un paquetage ou de problèmes pouvant être résolus par un changement d'assignation de paquetage
  • les Solutions :
    - élaboration de solutions pour les difficultés et les problèmes
  • les Modifications :
    - détermination des actions à mener pour réssoudre un problème
  • les Risques :
    - évaluation du risque associé à un problème, une solution ou un item du backlog

Ces contrôles sont mesurés, corrélés et suivis, Backlog et Risque étant les principaux.

Scrum s'adapte à un projet quelque soit sa taille

> Avant Scrum, les grands systèmes complexes devaient être bâtis en utilisant le modèle en cascade ou l'un de ses dérivés. Une approche entièrement définie, par étape générait des contrôles à chaque niveau de tâches. Cependant, beaucoup de ces projets échouèrent car ils n'étaient pas capables de s'adapter en cas de changements de technologie ou de modifications du cahier des charges et l'adéquation entre le produit livré et les tâches auxquelles il était destiné ne pouvaient être réalisée.

> Scrum et le développement empirique sont recommandés pour favoriser le développement de nouveaux logiciels ou des logiciels qui sont déjà orientés-objet ou qui ont des « interfaces propres ». Les objets et sous-systèmes de l'ouvrage qui sont cohérents et faiblement couplés avec les autres sont regroupés par paquetages. Chaque équipe peut ainsi travailler sur un ou plusieurs paquetages en toute indépendance.

> Au travers des contrôles formalisés de Scrum, le processus empirique de développement devient formellement mesurable. À partir d'une architecture et d'un design initial, le travail peut être partitionné et assigné à autant d'équipes qu'il est nécessaire et géré au niveau de chaque équipe. Le risque global et par équipe, la charge de travail, les problèmes et autres mesures sont toujours connnues, évaluées et gérées. Lors de la phase de conception Scrum du design et de l'architecture du système, les concepteurs et architectes divisent le projet en paquetages. Les paquetages sont assignés aux équipes en fonction du degré de priorité et des contraintes de planification. En fonction du degré de couplage entre les paquetages, des regroupements pouvant compter jusqu'à neuf équipes sont organisés en cluster. Cela peut être être poursuivi à l'étage supérieur (cluster de cluster) jusqu'à ce qu'on atteigne le niveau supérieur de contrôle.

Scrums de Scrums
Partage d'un projet en Scrums de Scrums

Scrum en pratique

L'équipe

> Composée généralement de 5 à 10 personnes, elle regroupe toutes les fonctions nécessaires au développement :

  • Architecte
  • Concepteur
  • Développeur
  • Spécialiste Interface Homme/Machine
  • Testeur
  • etc.

> L’équipe s’autogère et ses membres sont de préférence à plein temps, mais des exceptions sont possibles (Administrateur, …). Bien qu'il n'y ait normalement pas de titre, cela est rarement possible en pratique.

Isolement de l'équipe

> L'un des principes fondamentaux de Scrum consiste à isoler l'équipe de développement durant une période de 30 jours (de 2 à 6 semaines) - appelée « Sprint » - pour lui permettre de réaliser un maximum de fonctionnalités dans ce laps de temps. C'est le leader de l'équipe - le Scrum Master - qui a la charge de réduire au maximum les distractions extérieures qui pourraient gêner l'équipe pour l'atteindre l'objectif. Pour utiliser une métaphore, le Scrum Master joue le rôle de pare-feu entre l'équipe et le monde extérieur. Seules les informations et les tâches reliées au projet parviennent à l'équipe.

> La composition de l'équipe ne doit pas changer pendant la durée d'un Sprint

 Développement progressif

> Afin de forcer l'équipe à progresser, on oblige l'équipe à livrer une solution tous les 30 jours. Durant cette période de développement l'équipe se doit de livrer une série de fonctionnalités qui devront être opérationnelles à la fin des 30 jours. Le produit doit donc être conçu, codé et testé pendant le Sprint.

 Le pouvoir à l'équipe

> L'équipe a pleins pouvoirs pour réaliser les fonctionnalités. C'est elle qui détient la responsabilité de décider comment atteindre ses objectifs. Sa seule contrainte est de livrer une solution qui convient au client dans un délai de 30 jours.

> Pendant le Sprint, l’équipe a le droit :

  • d'ajouter de nouvelles tâches quand elle juge que c’est nécessaire pour atteindre le but fixé ;
  • de supprimer des tâches devenues inutiles.

 Contrôle du travail

> Le travail est contrôlé quotidiennement pour savoir se déroule conformément aux attentes des membres de l'équipe et à la fin des 30 jours de développement pour vérifier que la solution répond bien aux besoins du client. La liste des objectifs fixés pour un Sprint ne peut être mise à jour que par l’équipe elle-même. Les estimations du travail restant à effectuer (en heures) est actualisé chaque jour et représentée graphiquement par le « Burn down chart ».

 Cycle de développement

> Le cycle de développement Scrum peut être divisé en trois parties :

  • La phase d'initiation
  • Les sprints
  • La phase de clôture.

Processus Scrum
Cycle de développement Scrum

> La phase d'initiation (de démarrage)

Elle a pour but de définir le « Product backlog », c'est à dire le cahier des charges qui contient la liste des fonctionnalités du système réclamées par le client. Cette étape permet de se faire une idée générale de l'effort nécessaire pour la réalisation du système. Le Product backlog sera élaboré par le commanditaire appelé « Product owner », avec l'aide de représentants des clients ou utilisateurs, de commerciaux et de l'équipe de développement, afin de classer les fonctionnalités par ordre de priorité et d'effort.

Plannification du Sprint
Plannification du Sprint

> Les Sprints

  • Au début du Sprint, l'équipe choisit parmi les fonctionnalités du Product backlog celles qu'elle désire réaliser. Elle prendra autant de fonctionnalités qu'elle pense pouvoir en faire durant le Sprint qui suit. Ces fonctionnalités seront listées dans le « Sprint backlog » sous forme de petites tâches (entre 4 et 16 heures) qu'il faut accomplir pour les réaliser.
  • Durant le Sprint, les membres de l'équipe iront se choisir une tâche à faire parmi celles qui sont disponibles dans le « Sprint backlog ». Ils auront la charge de mettre à jour le Sprint backlog en indiquant le nombre d'heures restant avant de terminer celle-ci. Lorsque toutes les tâches sont à zéro, le Sprint est terminé. Bien que ce soit l'ensemble de léquipe qui soit responsable du travail à faire durant un Sprint, la charge de la gestion du Sprint revient au Scrum Master.
  • Tous les jours, les membres de l'équipe vont se réunir pour faire un Scrum. Durant cette rencontre informelle de 15 minutes où les membres se tiennent debout, ils font part de ce qu'ils ont accompli depuis le dernier Scrum, ce qu'ils pensent faire jusqu'au prochain et quels sont les obstacles pour y arriver. L'engagement pris devant ses pairs pousse chacun à tenir parole et faire effectivement ce qu'il a dit qu'il ferait.
  • En fin de Sprint, lors d'une revue informelle dont la préparation ne doit pas excéder 2 heures, l’équipe présente ce qui a été réalisé pendant le Sprint.
    • La présentation comporte une démonstration des nouvelles fonctionnalités ou de l’architecture.
    • Participent à cette revue :
      - le commanditaire du projet (Product owner)
      - le Client / Utilisateur ou ses représentants
      - l'encadrement du projet (Managerment)
      - les experts du domaine.

> Phase de clôture

La clôture est effectuée lorsqu'on considère que le build élaboré a réduit de façon satisfaisante les risques et résolu et implémenté le cahier des charges. Elle consiste à finir de tester le système et passer avec succès les tests de régression, à développer les supports de formations et achever la documentation finale.Cette phase prépare le produit pour sa livraison : intégration, test systèmes, documentation utilisateur, préparation de supports de formation, etc. Elle a lieu quand l'équipe d'encadrement estime que les variables de temps, exigences, coût et qualité concordent.

La méthodologie Scrum affirme de manière intrinsèque qu'un produit n'est jamais achevé ; après sa construction initiale, il demeure en développement permanent (maintenance ou améliorations). La consolidation permet de préparer le prochain cycle de développement. Elle a pour fonction de nettoyer les produits et artéfacts du cycle de développement qui s'achève pour permettre un démarrage propre du cycle suivant. C'est l'occasion de nettoyer les bouts de codes branlants qu'on a laissé dormir lors de la mise sous pression pour livrer le produit à l'extérieur.

Gestion d'un Sprint

 Gérer les embûches

> Une partie importante de la gestion d'un Sprint consiste à s'occuper des embûches que peut rencontrer l'équipe durant son travail. Pour toutes les embûches que l'équipe ne peut résoudre elle-même, le Scrum Master a la charge d'y apporter une solution.

 Gérer les tâches

> Durant un Sprint il est important de s'assurer que toutes les tâches du Sprint backlog qui sont à réaliser, puissent être terminées avant la fin du Sprint .

> En effet, durant un Sprint, le nombre de tâches à achever fluctue de jour en jour. Dans les meilleurs cas, les tâches sont effectuées une à une à un rythme qui permet de réaliser toutes les fonctionnalités dans le délai de 30 jours prévu. Malheureusement, c'est souvent le contraire qui arrive ; certaines tâches demandent plus d'heures pour être réalisées, d'autres sont ajoutées ou encore la progression ne se fait pas au rythme prévu. À ce moment, il y reste plus de travail à faire que le temps restant avant la fin d'un Sprint ne le permet. Dans ce cas, l'équipe doit modifier les tâches à accomplir pour qu'elle puisse livrer quelque chose en fin de Sprint.

> En se penchant sur les besoins minimaux du client, il peut s'avérer que certaines tâches ne soient pas indispensables pour réaliser les objectifs du Sprint. Dans ce cas, les tâches en question peuvent être retirées du Sprint backlog. De même pour l'évaluation des durées, il peut s'avérer que certaines tâches aient été mal estimées et l'équipe doit alors apporter les correctifs nécessaires.

> Malgré tout, il peut s'avérer que le nombre d'heures de travail nécessaires soit toujours supérieur au nombre d'heures restantes avant la fin du Sprint. Dans ce cas il est judicieux que l'équipe discute avec le client et la direction pour réduire l'étendue des fonctionnalités à réaliser. Par exemple si deux des besoins des usagers devaient être réalisés, le plus important des deux pourraient être conservé, ou encore l'une de ces fonctionnalités pourra n'être réalisée qu'à moitié. Le plus important, c'est que les trois parties arrivent à un compromis et soient d'accord.

 Saborder le Sprint

> Si au cours d'un Sprint, l'équipe découvre qu'elle n'a pas toute l'autorité ou l'information nécessaire pour atteindre les objectifs visés, elle peut décider elle même de saborder le Sprint. Dans ce cas le Sprint est annulé et un nouveau sera établi après avoir clarifié les zones d'ombres.

Productivité de Scrum - Prix à payer

 Productivité

> L'accroissement de la productivité est l'atout majeur de cette méthodologie. Scrum a été comparée par Capers JONES du Software Productivity Group aux autres méthodes de développement en vogue, voici ses conclusions :

« La méthodologie Scrum ressemble aux méthodologies itératives mais elle prend en compte le fait que tous les besoins ne sont pas connus par avance et que la voie la plus rapide pour faire le tour et implémenter tous ces besoins seront découverts lors du processus de développement. Des mécanismes prudents de contrôle sont mis en œuvre pour assurer à l'heure la livraison d'un produit de qualité, tout en conférant une flexibilité maximale de petites équipes de développement fortement couplées. Pour être efficace, elles doit s'appuyer sur une équipe motivée et bien dirigées. Dans ces conditions, des gains de productivité de 600% ont été observés de manière répétée sur des projets bien exécutés. »

 Inconvénients de Scrum

> La pratique qui consiste à isoler l'équipe de l'extérieur pendant les Sprints permet aux développeurs de se concentrer complètement sur les fonctionnalités sans être perturbé par des changements dictés par le client. Cette pratique rend la méthode beaucoup moins souple que d'autres, et ne pas prendre de modifications du projet au fur et à mesure provoque la production de code inutile. Ce point particulier mérite d'être examiné attentivement avant de mettre en place cette méthode.

> La survenue de conflits risquant de paralyser et de désagréger l'équipe est possible. Un procesus de résolution de situations conflictuelles doit être intégré au fonctionnement de l'équipe (cf. l'article « Nothing is for free » de Ken SCHWABER)

Terminologie Scrum

  Burndown Chart

Graphique sur lequel figure pour chaque jour du Sprint (ou pour chaque Sprint) , le nombre d'heures de travail encore nécessaires pour achever les différentes tâches.

Vitesse de progression
Diagrammes de progression du projet (Burndown chart)
Evaluation du terme

  Product Backlog

Liste de toutes les exigences auxquelles le logiciel devra répondre ; ce peut être une combinaison d’exigences fonctionnelles (chercher et remplacer du texte) et non fonctionnelles (améliorer la gestion des exceptions). (Référentiel des exigences)

  Product Owner

Personne chargée de mettre à jour le « Product backlog ». (Commanditaire)

  Scrum

Réunion quotidienne de 15 minutes, qui a pour but de faire le point sur ce qui a été fait depuis le dernierScrum, ce qui est prévue de faire jusqu'au prochain et que sont les embûches rencontrées durant le travail. (Mêlée)

  Scrum Master

Personne représentant l'équipe de gestion du projet et ambassadeur entre l'équipe de développement et les intervenants extérieurs. Il a pour mission de faire appliquer par l’équipe les valeurs et les pratiques de Scrum, de favoriser l'isolement de l'équipe des influences extérieures et de faciliter la résolution des problèmes durant le Sprint. (Animateur d’équipe)

  Sprint

Période de 30 jours durant laquelle l'équipe de développement travail à la réalisation de fonctionnalités. (Itération).
En fait, la durée des Sprints (2 à 6 semaines) doit permettre de différer la prise en compte d’un changement jusqu’au prochain Sprint sans nuire à la souplesse d'adaptation en cas de modifications de spécifications ou d'environnement. L'intervalle choisi correspond donc à un compromis établi selon la complexité du produit et le niveau d'expertise dans le domaine des différentes équipes, l'évaluation des risques et le degré de supervision et de contrôle souhaité. Cette durée peut également être variable au cours de l'avancement du projet (on accorde généralement une durée supérieurs aux premiers Sprints pour les raccourcir ultérieurement).

  Sprint Backlog

Listes de tâches détaillées que doivent accomplir l'équipe de développement afin de réaliser les fonctionnalités choisies pour un Sprint . (Plan d’itération)

Références utiles & Bibliographie

> La méthdologie Scrum appliquée au développement de produits trouve se source dans « The New New Product Development Game », Harvard Business Review 86116:137-146, 1986 - et s'est élaborée ensuite grâce « The Knowledge Creating Company », Oxford University Press, 1995 - deux publications de Ikujiro NONOKA et Hirotaka TAKEUCHI. Se fondant sur leurs idées et recherches à propos de la théorie des processus réalisées en collaboration avec DuPont Advanced Research Facility, Scrum a été formulé et présenté à l'Object Management Group en 1995. La méthodologie Scrum a été entièrement décrite en 2001 par Ken SCHWABER et Mike BEEDLE dans l'ouvrage « Agile Software Development with Scrum » dont vous pouvez lire un extrait >> ici <<.

> Les sources suivantes contiennent les références concernant la méthodologie Scrum et les concepts de « Good enough software », et de processus empiriques (et théoriques) sur lesquels elle s'appuie.

 Sites utiles

  Livres

  Articles

  • BACH James. The Challenge of "Good Enough" Software - American Programmer, Octobre 1995
  • CURIS B. A Mature View of the CMM - American Programmer, Septembre 1994
  • RACOON L.B.S. The Chaos Model and the Chaos Life Cycle. - Software Engineering Notes, Janvier 1995
  • RUMBAUGH J. What is a method ? - Journal of Object Oriented Programming, Octobre 1995

  Forums

  Listes de diffusion

Article rédigé par Lionel RAFFIN pour www.smart-doc.org
Édition 30 Avril 2006





Cet article provient de Smart-doc.org
http://smart-doc.org/