Processus de développement de logiciels SCRUM (1995)

Auteur : Jeff Sutherland
Source : SCRUM Software Development Process
Date : 22/11/1995 (dernière mise à jour)

---

Traducteur : Fabrice Aimetti
Date : 07/12/2023

---

Traducteur :

Construire le meilleur logiciel possible

"Le problème pour les ingénieurs est que le changement se traduit par le chaos, en particulier lorsqu'une seule erreur peut potentiellement faire tomber un système entier. Mais le changement est aussi synonyme d'opportunités. C'est aussi simple que cela : si l'on a le temps d'intégrer facilement une certaine quantité de fonctionnalités dans le produit, alors on a le temps d'intégrer davantage de fonctionnalités au prix d'une certaine quantité de perturbations et de risques. C'est ainsi que la folie s'insinue dans nos projets - nous aurons tendance à prendre autant de risques que possible."

James Bach. Octobre 1995. "American Programmer"
Copyright 1995 Advanced Development Methods All Rights Reserved

Introduction

Dans cet article, nous présentons un processus de développement, SCRUM, qui traite les principales parties du développement de systèmes comme une boîte noire sous contrôle. Nous faisons le lien avec la théorie de la complexité pour montrer pourquoi cette approche augmente la flexibilité et la capacité à gérer la complexité, et produit un système qui répond à la fois aux exigences initiales et à celles qui surviennent ultérieurement.

De nombreuses approches visant à améliorer le processus de développement des systèmes ont été testées. Chacune d'entre elles a été présentée comme apportant des "améliorations significatives de la productivité". Aucune ne l'a fait. Comme l'a fait remarquer Grady Booch, "nous appelons souvent cette situation la crise du logiciel, mais franchement, une maladie qui dure depuis si longtemps doit être qualifiée de normale".

Dans le présent document, des concepts issus du contrôle des processus industriels sont appliqués au domaine du développement de systèmes. Le contrôle des processus industriels définit les processus comme étant soit "théoriques" (entièrement définis), soit "empiriques" (boîte noire). Lorsqu'un processus de boîte noire est traité comme un processus entièrement défini, des résultats imprévisibles apparaissent. Un traitement plus approfondi de cette question est fourni à l'annexe 1.

Un grand nombre de processus de développement de systèmes ne sont pas entièrement définis, mais sont traités comme s'ils l'étaient. Il en résulte une imprévisibilité sans contrôle. L'approche SCRUM traite ces processus de développement de systèmes comme une boîte noire sous contrôle.

L'approche SCRUM est utilisée avec succès par des entreprises de pointe dans le domaine des logiciels. Nous pensons que SCRUM peut être approprié pour d'autres organisations de développement logiciel afin de bénéficier des avantages attendus des techniques et des outils orientés objet.

Vue d'ensemble

Notre nouvelle approche du développement de systèmes est basée à la fois sur la gestion des processus définis et boîtes noires. Nous appelons cette approche la méthodologie SCRUM, en référence au SCRUM du rugby - un groupe chargé de ramasser le ballon et de le faire avancer.

SCRUM est une méthodologie de gestion, d'amélioration et de maintenance d'un système existant. SCRUM abordera les efforts de développement de nouveaux systèmes ou de systèmes entièrement remaniés à une date ultérieure.

Les versions des produits logiciels sont planifiées en fonction des variables suivantes :

• Exigences du client : comment le système actuel doit être amélioré.
• Pression du temps : quel est le délai nécessaire pour obtenir un avantage concurrentiel ?
• Concurrence : ce que fait la concurrence et ce qu'il faut faire pour la surpasser.
• Qualité : quelle est la qualité requise, compte tenu des variables ci-dessus.
• Vision : quels sont les changements nécessaires à ce stade pour concrétiser la vision du système.
• Ressources : le personnel et les fonds disponibles.

Ces variables constituent le plan initial d'un projet d'amélioration logiciel. Toutefois, ces variables évoluent également au cours du projet. Une méthodologie de développement efficace doit tenir compte de ces variables et de leur nature évolutive.

Situation actuelle du développement

Les systèmes sont développés dans un environnement très complexe. La complexité se situe à la fois dans l'environnement de développement et dans l'environnement cible. Par exemple, lorsque le développement du système de contrôle du trafic aérien a été lancé, les systèmes client-serveur à trois niveaux et la déréglementation des compagnies aériennes n'ont pas été pris en compte. Pourtant, ces changements environnementaux et techniques sont intervenus au cours du projet et ont dû être pris en compte dans le système en cours de construction. Les variables environnementales sont les suivantes

• La disponibilité de professionnels qualifiés : plus la technologie, les outils, les méthodes et le domaine sont récents, plus le nombre de professionnels qualifiés est réduit.
• Stabilité de la technologie de mise en œuvre : plus la technologie est récente, plus la stabilité est faible et plus il est nécessaire d'équilibrer la technologie avec d'autres technologies et des procédures manuelles.
• Stabilité et puissance des outils : plus l'outil de développement est récent et puissant, plus le nombre de professionnels qualifiés est faible et plus le fonctionnement de l'outil est instable.
• Efficacité des méthodes : quelles sont les méthodes de modélisation, de test, de contrôle des versions et de conception qui seront utilisées, et dans quelle mesure sont-elles efficaces, efficientes et éprouvées ?
• Expertise dans le domaine - des professionnels compétents sont-ils disponibles dans les différents domaines, y compris le métier et la technologie ?
• Nouvelles fonctionnalités : quelles sont les fonctionnalités entièrement nouvelles qui vont être ajoutées et dans quelle mesure s'intègrent-elles dans le fonctionnement actuel ?
• Méthodologie - l'approche globale du développement des systèmes et l'utilisation des méthodes sélectionnées favorisent-elles la flexibilité ou s'agit-il d'une approche rigide et détaillée qui limite la flexibilité ?
• Concurrence - que fera la concurrence pendant le projet ? Quelles nouvelles fonctionnalités seront annoncées ou mises sur le marché ?
• Temps/financement - combien de temps est disponible au départ et au fur et à mesure de l'avancement du projet ? Quel est le montant du financement disponible pour le développement ?
• Autres variables - tout autre facteur auquel il faut répondre pendant le projet pour garantir le succès du système livré, par exemple des réorganisations.

La complexité globale est fonction de ces variables :

complexité = f(variables de l'environnement de développement + variables de l'environnement cible)

sachant que ces variables peuvent changer et changent effectivement au cours du projet.

Plus la complexité du projet augmente, plus le besoin de contrôles se fait sentir, en particulier en ce qui concerne l'évaluation continue des risques et la réponse à y apporter.

Les tentatives de modélisation de ce processus de développement se sont heurtées aux problèmes suivants :

• De nombreux processus de développement ne sont pas contrôlés. Les entrées et les sorties sont soit inconnues, soit mal définies, le processus de transformation manque de la précision nécessaire et le contrôle de la qualité n'est pas défini. Les processus de test en sont un exemple.
• Un nombre inconnu de processus de développement qui relient des processus connus mais non contrôlés ne sont pas identifiés. Les processus détaillés visant à garantir qu'un modèle logique contient un contenu adéquat pour aboutir à un modèle physique réussi en sont un exemple.
• Les données environnementales (exigences) ne peuvent être prises en considération qu'au début du processus. Des procédures complexes de gestion du changement sont ensuite nécessaires.

Les tentatives visant à imposer un modèle méthodologique micro ou détaillé au processus de développement n'ont pas fonctionné parce que le processus de développement n'est pas encore complètement défini. Agir comme si le processus de développement était défini et prévisible revient à ne pas être préparé aux résultats imprévisibles.

Bien que le processus de développement ne soit pas entièrement défini et qu'il soit dynamique, de nombreuses organisations ont mis au point des méthodologies de développement détaillées qui incluent les méthodes de développement actuelles (structurées, OO, etc.). La méthodologie en Cascade (Waterfall) a été l'un des premiers processus de développement de systèmes définis. La figure 1 illustre la méthodologie en Cascade.


Figure 1 : illustration de la méthodologie en Cascade

Bien que l'approche en Cascade impose l'utilisation de processus non définis, sa nature linéaire a été son plus grand problème. Le processus ne définit pas comment réagir à des résultats inattendus provenant de l'un ou l'autre des processus intermédiaires.

Barry Boehm a introduit une méthodologie en Spirale pour résoudre ce problème. Chacune des phases de la cascade se termine par une évaluation des risques et une activité de prototypage. La méthodologie en spirale est illustrée à la figure 2.

La méthodologie en Spirale "épluche l'oignon", en progressant à travers les "couches" du processus de développement. Un prototype permet aux utilisateurs de déterminer si le projet est sur la bonne voie, s'il doit être renvoyé à des phases antérieures ou s'il doit être terminé. Toutefois, les phases et les processus de phase sont toujours linéaires. Le travail sur les exigences est toujours effectué dans la phase des exigences, le travail de conception dans la phase de conception, et ainsi de suite, chacune des phases étant constituée de processus linéaires et explicitement définis.


Figure 2 : illustration de la méthodologie en Spirale

La méthodologie itérative améliore la méthodologie en spirale. Chaque itération comprend toutes les phases standard de l’approche en Cascade, mais chaque itération n'aborde qu'un seul ensemble de fonctionnalités analysées. Le résultat global du projet a été divisé en sous-systèmes classés par ordre de priorité, chacun ayant des interfaces propres. Cette approche permet de tester la faisabilité d'un sous-système et d'une technologie lors des premières itérations. Les itérations ultérieures peuvent ajouter des ressources au projet tout en accélérant la vitesse de livraison. Cette approche permet de mieux contrôler les coûts, de garantir la livraison de systèmes (même s'il s'agit de sous-systèmes) et d'améliorer la flexibilité générale. Cependant, l'approche itérative suppose toujours que les processus de développement sous-jacents soient définis et linéaires. Voir la figure 3.


Figure 3 : illustration de la méthodologie Itérative

Compte tenu de la complexité de l'environnement et de la dépendance accrue à l'égard des nouveaux systèmes "de pointe", le risque encouru par les projets de développement de systèmes a augmenté et la recherche de mécanismes pour gérer ce risque s'est intensifiée.

On peut affirmer que les méthodologies actuelles valent mieux que rien. Chacune améliore l'autre. Les approches en spirale et itérative implantent des mécanismes formels de contrôle des risques pour gérer les résultats imprévisibles. Un cadre de développement est fourni.

Cependant, chacune repose sur l'idée fausse que les processus de développement sont des processus définis et prévisibles. Or, des résultats imprévisibles surviennent tout au long des projets. La rigueur impliquée dans les processus de développement étouffe la flexibilité nécessaire pour faire face aux résultats imprévisibles et répondre à un environnement complexe.

Bien qu'elles soient largement répandues dans la communauté des développeurs, les méthodologies ne sont pas utilisées, si ce n'est comme macroprocessus ou pour la description détaillée des méthodes.

Le graphique suivant illustre l'environnement de développement actuel, en utilisant l'un des processus en Cascade, en Spirale ou Itératif. Lorsque la complexité des variables augmente, même à un niveau modéré, la probabilité d'un projet "réussi" diminue rapidement (un projet réussi est défini comme un système qui est utile lorsqu'il est livré). Voir la figure 4.


Figure 4 : illustration de la complexité/du risque d’un processus défini

Méthodologie SCRUM

Le processus de développement d'un système est compliqué et complexe. C'est pourquoi une flexibilité maximale et un contrôle approprié sont nécessaires. L'évolution favorise ceux qui fonctionnent avec une exposition maximale aux changements environnementaux et qui ont une flexibilité maximale. L'évolution défavorise ceux qui se sont isolés des changements environnementaux et qui ont minimisé le chaos et la complexité de leur environnement.

Il faut une approche qui permette aux équipes de développement de s'adapter à un environnement complexe en utilisant des processus imprécis. Le développement de systèmes complexes se produit dans des circonstances chaotiques. La production de systèmes ordonnés dans des circonstances chaotiques exige une flexibilité maximale. Plus l'équipe de développement est proche de la limite du chaos, plus le système qui en résultera sera compétitif et utile.

La méthodologie pourrait bien être le facteur le plus important pour déterminer la probabilité de succès. Les méthodologies qui encouragent et soutiennent la flexibilité ont un degré élevé de tolérance aux changements d'autres variables. Avec ces méthodologies, le processus de développement est considéré comme imprévisible dès le départ et des mécanismes de contrôle sont mis en place pour gérer l'imprévisibilité.

Si nous représentons graphiquement la relation entre la complexité de l'environnement et la probabilité de réussite avec une méthodologie flexible qui intègre des contrôles et une gestion des risques, la tolérance au changement est plus pérenne. Voir la figure 5.


Figure 5 : illustration de la comparaison risque/complexité

Les figures 4 et 5 reflètent les expériences de développement de logiciels chez ADM, Easel, Vmark, Borland et pratiquement tous les autres fabricants de logiciels "prêts à l'emploi". Ces organisations ont accepté le risque et la complexité de l'environnement au cours des projets de développement. L'impact du produit s'est accru, les projets ont été couronnés de succès et des gains de productivité ont été enregistrés. Les meilleurs logiciels possibles sont construits.

Les méthodologies en Cascade et en Spirale définissent le contexte et les produits à livrer au début d'un projet. Les méthodes SCRUM et itératives planifient initialement le contexte et la définition globale du produit à livrer, puis font évoluer le produit au cours du projet en fonction de l'environnement. SCRUM reconnaît que les processus de développement sous-jacents sont définis de manière incomplète et utilise des mécanismes de contrôle pour améliorer la flexibilité.

La principale différence entre l'approche définie (en Cascade, en Spirale et Itérative) et l'approche empirique (SCRUM) est que l'approche SCRUM part du principe que les processus d'analyse, de conception et de développement de la phase Sprint sont imprévisibles. Un mécanisme de contrôle est utilisé pour gérer l'imprévisibilité et contrôler le risque. Les résultats sont la flexibilité, la réactivité et la fiabilité. Voir la figure 6.


Figure 6 : illustration de la méthodologie SCRUM

Les caractéristiques de la méthodologie SCRUM sont les suivantes :

• La première et la dernière phase (planification et clôture) consistent en des processus définis, où tous les processus, les entrées et les sorties sont bien définis. La connaissance de la manière d'exécuter ces processus est explicite. Le flux est linéaire, avec quelques itérations dans la phase de planification.
• La phase de sprint est un processus empirique. De nombreux processus de la phase de sprint ne sont pas identifiés ou contrôlés. Elle est traitée comme une boîte noire qui nécessite des contrôles externes. Par conséquent, des contrôles, y compris la gestion des risques, sont mis en place à chaque itération de la phase de sprint afin d'éviter le chaos tout en maximisant la flexibilité.
• Les sprints sont non linéaires et flexibles. Lorsqu'elle est disponible, la connaissance explicite du processus est utilisée ; dans le cas contraire, la connaissance tacite et les essais et erreurs sont utilisés pour construire la connaissance du processus. Les sprints sont utilisés pour faire évoluer le produit final.
• Le projet est ouvert à l'environnement jusqu'à la phase de clôture. Le produit à livrer peut être modifié à tout moment pendant les phases de planification et de sprint du projet. Le projet reste ouvert à la complexité de l'environnement, y compris aux pressions concurrentielles, temporelles, qualitatives et financières, tout au long de ces phases.
• Le produit à livrer est déterminé au cours du projet en fonction de l'environnement.

La figure 7 compare les principales caractéristiques de SCRUM à celles d'autres méthodologies.

Figure 7 : Tableau de comparaison des méthodologies

Texte de l’en-tête	Texte de l’en-tête	Texte de l’en-tête tête	Texte de l’en-tête	Texte de l’en-tête
	en cascade	en Spirale	Itératif	SCRUM
Processus définis	Requis	Requis	Requis	Planification & Clôture uniquement
Coût du projet	Déterminé pendant la planification	Déterminé pendant la planification	Défini pendant le projet	Défini pendant le projet
Date de fin	Déterminé pendant la planification	Partiellement variable	Défini pendant le projet	Défini pendant le projet
Réactivité à l’environnement	Planification uniquement	Planification initiale	À la fin de chaque itération	Débit
Créativité, flexibilité de l’équipe	Limitées – Approche du livre de recettes	Limitées – Approche du livre de recettes	Limitées – Approche du livre de recettes	Illimitées pendant les itérations
Transfert de connaissances	Formation avant le projet	Formation avant le projet	Formation avant le projet	Travail d’équipe pendant le projet
Probabilité de succès	Faible	Moyennement faible	Moyenne	Forte

Phases SCRUM

SCRUM comporte les groupes de phases suivants :

Avant le jeu

• Planification : Définition d'une nouvelle version sur la base du backlog actuellement connu, ainsi qu'une estimation de son calendrier et de son coût. Si un nouveau système est développé, cette phase comprend à la fois la conceptualisation et l'analyse. Si un système existant doit être amélioré, cette phase se résume à une analyse limitée.
• Architecture : concevoir la manière dont les éléments du backlog seront mis en œuvre. Cette phase comprend la modification de l'architecture du système et la conception de haut niveau.

Jeu

Sprints de développement : développement de la fonctionnalité d'une nouvelle version, dans le respect constant des variables que sont le temps, les exigences, la qualité, le coût et la concurrence. L'interaction avec ces variables définit la fin de cette phase. De nombreux sprints ou cycles de développement itératifs sont utilisés pour faire évoluer le système.

Après le jeu

Clôture : Préparation de la mise en production, y compris la documentation finale, les tests par étapes avant la mise en production et la mise en production.


Figure 8 : illustration du flux de la méthodologie SCRUM

Étapes des phases

Chacune des phases comporte les étapes suivantes :

Planification

• Élaboration d'une liste backlog globale.
• Définition de la date de livraison et des fonctionnalités d'une ou plusieurs versions.
• Sélection de la version la plus appropriée pour un développement immédiat.
• Cartographie des packages produits (objets) pour les éléments du backlog dans la version sélectionnée.
• Définition de(s) l'équipe/équipes projet pour l'élaboration de la nouvelle version.
• Évaluation des risques et des mesures de contrôle des risques appropriées.
• Revue et ajustement éventuel des éléments du backlog et des packages.
• Validation ou resélection des outils de développement et de l'infrastructure.
• Estimation du coût de la version, y compris le développement, le matériel annexe, le marketing, la formation et le déploiement.
• Vérification de l'approbation et du financement de la Direction.

Architecture/Conception de haut niveau

• Revoir les éléments du backlog qui lui ont été affectés.
• Identifier les changements nécessaires à la mise en œuvre des éléments du backlog.
• Effectuer une analyse du domaine en fonction des besoins pour construire, améliorer ou mettre à jour les modèles de domaine afin de refléter le nouveau contexte et les nouvelles exigences du système.
• Affiner l'architecture du système pour prendre en charge le nouveau contexte et les nouvelles exigences.
• Identifier les problèmes ou les questions liés au développement ou à la mise en œuvre des changements.
• Lors de la réunion de revue de conception, chaque équipe présente son approche et les changements à apporter pour mettre en œuvre chaque élément du backlog. Réaffecter les changements si nécessaire.

Développement (Sprint)

La phase de développement est un cycle itératif de travail de développement. Le management détermine que les délais, la concurrence, la qualité ou la fonctionnalité sont respectés, les itérations sont achevées et la phase de clôture a lieu. Cette approche est également connue sous le nom de "Concurrent Engineering" (ingénierie simultanée). Le développement se compose des macro-processus suivants :

• Réunion avec les équipes pour examiner les plans de release.
• Distribution, revue et ajustement des standards auxquels le produit doit se conformer.
• Sprints itératifs, jusqu'à ce que le produit soit considéré comme prêt à être distribué.

Un sprint est un ensemble d'activités de développement menées au cours d'une période prédéfinie, généralement une ou quatre semaines. L'intervalle est basé sur la complexité du produit, l'évaluation des risques et le degré de contrôle souhaité. La vitesse et l'intensité du sprint dépendent de la durée choisie pour le sprint. Les risques sont évalués en permanence et des contrôles et réponses adéquats sont mis en place. Chaque sprint se compose d'une ou de plusieurs équipes qui effectuent les tâches suivantes :

• Développement : définir les changements nécessaires à la mise en œuvre des exigences du backlog en packages, ouvrir les packages, effectuer l'analyse du domaine, concevoir, développer, mettre en œuvre, tester et documenter les changements. Le développement consiste en un micro-processus de découverte, d'invention et de mise en œuvre.
• Enveloppe : fermer les packages, créer une version exécutable des changements et de la manière dont ils mettent en œuvre les exigences du backlog.
• Revue : toutes les équipes se réunissent pour présenter le travail et faire le point sur les progrès accomplis, en soulevant et en résolvant les questions et les problèmes, en ajoutant de nouveaux éléments au backlog. Les risques sont examinés et les réponses appropriées sont définies.
• Ajustement : consolidation des informations recueillies lors de la réunion de revue dans les packages concernés, incluant des aspects différents et de nouvelles propriétés.

Chaque sprint est suivi d'une revue, dont les caractéristiques sont les suivantes :

• L'ensemble de l'équipe et du product management est présent et participe.
• La revue peut inclure les clients, les ventes, le marketing, etc.

La revue couvre les systèmes fonctionnels et exécutables qui englobent les objets assignés à cette équipe et incluent les changements apportés pour mettre en œuvre les éléments du backlog.

• La manière dont les éléments du backlog sont mis en œuvre par des changements peut être modifiée en fonction de la revue.
• De nouveaux éléments du backlog peuvent être introduits et attribués aux équipes dans le cadre de la revue, ce qui modifie le contenu et l'orientation des produits livrables.
• La date de la prochaine revue est déterminée en fonction de l'avancement et de la complexité du projet. Les sprints ont généralement une durée de 1 à 4 semaines.

Clôture

Lorsque le management estime que les variables de temps, de concurrence, d'exigences, de coût et de qualité concordent pour qu'une nouvelle version soit produite, elle déclare la version "clôturée" et entre dans cette phase. Cette phase prépare le produit développé à une diffusion générale. L'intégration, les tests système, la documentation utilisateur, la préparation du support de formation et du support de marketing font partie des tâches de clôture.

Contrôles SCRUM

Le fonctionnement à la limite du chaos (imprévisibilité et complexité) nécessite des contrôles pour éviter de tomber dans le chaos. La méthodologie SCRUM intègre ces contrôles souples, en utilisant des techniques orientées objet pour la construction effective des produits livrables.

Le risque est le premier contrôle. L'évaluation des risques entraîne des changements dans d'autres contrôles et des réponses de la part de l'équipe.

Les contrôles de la méthodologie SCRUM sont les suivants :

• Backlog : Exigences de fonctionnalité du produit qui ne sont pas traitées de manière adéquate par la version actuelle du produit. Les bugs, les défauts, les améliorations demandées par les clients, les fonctionnalités des produits concurrents, les fonctionnalités concurentielles et les mises à jour technologiques sont des éléments du backlog.
• Version/Amélioration : éléments du backlog qui, à un moment donné, représentent une version viable sur la base des variables que sont les exigences, le temps, la qualité et la concurrence.
• Packages : composants ou objets du produit qui doivent être modifiés pour mettre en œuvre un élément du backlog dans une nouvelle version.
• Changements : changements qui doivent être apportés à un package pour mettre en œuvre un élément du backlog.
• Problèmes : Problèmes techniques qui surviennent et doivent être résolus pour mettre en œuvre un changement.
• Risques : les risques qui affectent la réussite du projet sont évalués en permanence et des réponses sont planifiées. D'autres contrôles sont affectés par l'évaluation des risques.
• Solutions : solutions aux problèmes et aux risques, entraînant souvent des changements.
• Sujets : sujets du projet qui ne sont pas définis en termes de packages, de changements et de problèmes.

Ces contrôles sont utilisés dans les différentes phases de SCRUM. Le management utilise ces contrôles pour gérer le backlog. Les équipes utilisent ces contrôles pour gérer les changements et les problèmes. Le management et les équipes gèrent conjointement les problèmes, les risques et les solutions. Ces contrôles sont revus, modifiés et réconciliés lors de chaque réunion de revue de sprint.

Livrables SCRUM

Le produit livré est flexible. Son contenu est déterminé par des variables environnementales, notamment le temps, la concurrence, le coût ou la fonctionnalité. Les déterminants du produit livrable sont la connaissance du marché, le contact avec le client et les compétences des développeurs. Des ajustements fréquents du contenu du produit livrable ont lieu au cours du projet en réponse à l'environnement. Le produit à livrer peut être déterminé à tout moment au cours du projet.

Équipe projet SCRUM

L'équipe qui travaille sur la nouvelle version comprend des développeurs à temps plein et des personnes externes qui seront concernées par la nouvelle version, telles que le marketing, les ventes et les clients. Dans les processus de développement traditionnels, ces derniers groupes sont tenus à l'écart des équipes de développement par crainte de compliquer excessivement le processus et de provoquer des interférences "inutiles". L'approche SCRUM, en revanche, accueille favorablement et facilite leur implication contrôlée à intervalles déterminés, car cela augmente la probabilité que le contenu et le calendrier de la version soient appropriés, utiles et commercialisables.

Les équipes suivantes sont formées pour chaque nouvelle version :

• Management : pilotée par le Product Manager, il définit le contenu initial et le calendrier de la version, puis gère leur évolution au fur et à mesure que le projet progresse et que les variables changent. L'équipe de management s'occupe du backlog, des risques et du contenu de la version.
• Équipes de développement : les équipes de développement sont petites et comprennent chacune des développeurs, des documentalistes et du personnel chargé du contrôle qualité. Une ou plusieurs équipes de trois à six personnes chacune sont mises en place. Chacune se voit attribuer un ensemble de packages (ou d'objets), y compris tous les éléments du backlog liés à chaque package. L'équipe définit les changements nécessaires à la mise en œuvre des éléments du backlog dans les packages et gère tous les problèmes liés à ces changements. Les équipes peuvent être issues d'une fonction (on leur attribue les packages qui concernent des ensembles spécifiques de fonctionnalités du produit) ou d'un système (on leur attribue des couches spécifiques du système). Les membres de chaque équipe sont sélectionnés sur la base de leurs connaissances et de leur expertise concernant des ensembles de packages, ou expertise de domaine.

Caractéristiques SCRUM

La méthodologie SCRUM est une métaphore du jeu de rugby. Le rugby s'est développé à partir du football anglais (soccer) sous la pression intense du jeu :

William Webb Ellis, 17 ans, étudiant à Rugby, inaugure un nouveau jeu dont les règles seront codifiées en 1839. Jouant au football pour le collège du East Warwickshire, vieux de 256 ans, Ellis voit que le temps est compté et que son équipe est en retard. Il récupère donc le ballon et court avec, au mépris des règles.

The People's Chronology, Henry Holt and Company, Inc. Copyright © 1992.

Les projets SCRUM présentent les caractéristiques suivantes :

• Livrable flexible : le contenu du livrable est dicté par l'environnement.
• Calendrier flexible : le produit livrable peut être requis plus tôt ou plus tard que prévu.
• Petites équipes : chaque équipe ne compte pas plus de 6 membres. Il peut y avoir plusieurs équipes au sein d'un même projet.
• Revues fréquentes : les progrès de l'équipe sont revus aussi souvent que la complexité de l'environnement et les risques l'exigent (en général, des cycles de 1 à 4 semaines). Un exécutable fonctionnel doit être préparé par chaque équipe pour chaque revue.
• Collaboration : une collaboration intra et inter est indispensable tout au long du projet.
• Orienté objet : chaque équipe s'occupera d'un ensemble d'objets liés, avec des interfaces et un comportement clairs.

La méthodologie SCRUM partage de nombreuses caractéristiques avec le rugby :

• Le contexte est défini par le terrain de jeu (environnement) et les règles du rugby (contrôles).
• Le cycle principal consiste à faire avancer le ballon.
• Le rugby a évolué en enfreignant les règles du football et en s'adaptant à l'environnement.
• Le jeu ne se termine pas tant que l'environnement ne l'impose pas (besoin du métier, concurrence, fonctionnalité, calendrier).

Avantages de la Méthodologie SCRUM

D'autres méthodologies de développement sont conçues uniquement pour répondre à l'imprévisibilité des environnements externes et de développement au début d'un cycle d'amélioration. Des approches plus récentes telles que la méthodologie en Spirale de Boehm et ses variantes sont encore limitées dans leur capacité à répondre à l'évolution des besoins une fois que le projet a démarré.

La méthodologie SCRUM, en revanche, est conçue pour être assez flexible tout au long du projet. Elle fournit des mécanismes de contrôle pour planifier la sortie d'un produit et gérer les variables au fur et à mesure de l'avancement du projet. Cela permet aux organisations de modifier le projet et les produits livrables à tout moment, afin d'obtenir la version la plus appropriée.

La méthodologie SCRUM permet aux développeurs de concevoir les solutions les plus ingénieuses tout au long du projet, au fur et à mesure de l'apprentissage et de l'évolution de l'environnement.

De petites équipes collaboratives de développeurs sont en mesure de partager des connaissances tacites sur les processus de développement. Un excellent environnement de formation est offert à toutes les parties.

La technologie Orientée Objet constitue la base de la méthodologie SCRUM. Les objets, ou fonctionnalités d'un produit, offrent un environnement simple et facile à gérer. Le code procédural, avec ses interfaces nombreuses et entremêlées, ne convient pas à la méthodologie SCRUM. SCRUM peut être appliqué ponctuellement à des systèmes procéduraux dotés d'interfaces propres et d'une forte orientation vers les données.

Estimation d'un projet SCRUM

Les projets SCRUM peuvent être estimés à l'aide d'une estimation standard par points de fonction. Toutefois, il est conseillé d'estimer la productivité à environ deux fois la mesure actuelle. Cette estimation n'est toutefois qu'un point de départ, car le calendrier et le coût globaux sont déterminés de manière dynamique en fonction des facteurs environnementaux.

Nos observations nous ont amenés à conclure que les projets SCRUM présentent à la fois vélocité et accélération. En termes de fonctions livrées ou d'éléments du backlog terminés :

• la vélocité et l'accélération initiales sont faibles car l'infrastructure est construite/modifiée
• au fur et à mesure que les fonctionnalités de base sont intégrées dans les objets, l'accélération augmente
• l'accélération diminue et la vélocité reste à un niveau durablement élevé.

Il est nécessaire de poursuivre le développement de métriques pour les processus empiriques.

Annexe 1

Méthodologies de développement de systèmes : définies ou empiriques

Le développement d’un système est l’acte de créer une construction logique qui est mise en œuvre sous forme de logique et de données sur les ordinateurs. La construction logique se compose d’entrées, de processus et de sorties, à la fois macro (construction globale) et micro (étapes intermédiaires dans la construction globale). L’ensemble est connu sous le nom de système implémenté.

De nombreux artefacts sont créés lors de la construction du système. Les artefacts peuvent être utilisés pour guider la réflexion, vérifier l’exhaustivité et créer une piste d’audit. Les artefacts sont constitués de documents, de modèles, de programmes, de cas de test et d’autres livrables créés avant la création du système implémenté. Lorsqu’il est disponible, un métamodèle définit le contenu sémantique des artefacts du modèle. La notation décrit les conventions de représentation graphique et de documentation utilisées pour construire les modèles.

L’approche utilisée pour développer un système est connue sous le nom de méthode. Une méthode décrit les activités impliquées dans la définition, la construction et l'implémentation d’un système ; une méthode est un cadre de travail. Étant donné qu’une méthode est un processus logique de construction de (processus) systèmes, elle est connue sous le nom de métaprocessus (un processus de modélisation des processus).

Une méthode comporte des composants micro et macro. Les composants macro définissent le flux global et le cadre de travail séquencé dans le temps pour l’exécution du travail. Les micro-composants comprennent des règles de conception générales, des modèles et des règles empiriques. Les règles générales de conception énoncent les propriétés à atteindre ou à éviter dans la conception ou les approches générales à adopter lors de la construction d’un système. Les patterns sont des solutions qui peuvent être appliquées à un type d’activité de développement ; ce sont des solutions en attente de problèmes qui apparaissent lors d’une activité dans une méthode. Les règles empiriques consistent en un ensemble général de trucs et de astuces.

La figure 9 illustre la relation entre la méthode, les artefacts et le système.



En appliquant des concepts allant du contrôle des processus industriels au domaine du développement de systèmes, les méthodes peuvent être classées comme « théoriques » (entièrement définies) ou « empiriques » (boîte noire).

Il est essentiel de catégoriser correctement les méthodes de développement des systèmes. La structure appropriée d’une méthode pour construire un type particulier de système dépend du fait que la méthode est théorique ou empirique.

Les modèles de processus théoriques sont dérivés des principes premiers, en utilisant des bilans de matière et d’énergie et des lois fondamentales pour déterminer le modèle. Pour qu’une méthode de développement de systèmes soit classée comme théorique, elle doit être conforme à cette définition.

Les modèles de processus empiriques sont dérivés en catégorisant les entrées et les sorties observées et définissant les contrôles qui les amènent à se produire dans les limites prescrites. La modélisation empirique des processus consiste à construire un modèle de processus strictement à partir de données d’entrée/sortie obtenues expérimentalement, sans recours à des lois concernant la nature fondamentale et les propriétés du système. Aucune connaissance a priori du processus n’est nécessaire (bien qu’elle puisse être utile) ; un système est traité comme une boîte noire.

Les principales caractéristiques de la modélisation théorique et empirique sont détaillées dans le tableau 1.

Tableau 1

Modélisation théorique	Modélisation empirique
1. Implique généralement moins de mesures ; l'expérimentation n'est nécessaire que pour l'estimation des paramètres inconnus du modèle.	Nécessite des mesures approfondies, car il repose entièrement sur l'expérimentation pour l'élaboration du modèle.
2. Fournit des informations sur l'état interne du processus.	Fournit des informations uniquement sur la partie du processus qui peut être influencée par une action de contrôle.
3. Favorise une compréhension fondamentale du fonctionnement interne du processus.	Traite le processus comme une "boîte noire".
4. Nécessite une connaissance assez précise et complète du processus.	Ne nécessite pas de connaissances aussi détaillées ; il suffit que les données de sortie puissent être obtenues en réponse à des modifications des données d'entrée.
5. Pas particulièrement utile pour les processus mal compris et/ou complexes.	Il s'agit souvent de la seule alternative pour modéliser le comportement de processus mal compris et/ou complexes.
6. Produit naturellement des modèles de processus linéaires et non linéaires.	Nécessite des méthodes spéciales pour produire des modèles non linéaires.

À l’inspection, nous affirmons que le processus de développement des systèmes est empirique :

• Les premiers principes applicables ne sont pas présents
• Le processus commence seulement à être compris
• Le processus est complexe
• Le processus est en train de changer

La plupart des méthodologistes sont d’accord avec cette affirmation ; "... Vous ne pouvez pas vous attendre à ce qu’une méthode vous dise tout ce qu’il faut faire. L’écriture d’un logiciel est un processus créatif, au même titre que la peinture, l’écriture ou l’architecture... (une méthode) fournit un cadre de travail qui indique comment s’y prendre et identifie les endroits où la créativité est nécessaire. Mais encore faut-il faire preuve de créativité..."

La catégorisation des méthodes de développement des systèmes comme empiriques est essentielle à la gestion efficace du processus de développement des systèmes.

Si les méthodes de développement des systèmes sont classées comme empiriques, des mesures et des contrôles sont nécessaires parce qu’il est entendu que le fonctionnement interne de la méthode est si vaguement défini qu’on ne peut pas compter sur elle pour fonctionner de manière prévisible.

Dans le passé, des méthodes ont été fournies et appliquées comme si elles étaient théoriques. Du coup, les mesures n’ont pas été prises en compte et les contrôles dépendant des mesures n’ont pas été utilisés.

Bon nombre des problèmes rencontrés dans le développement des systèmes sont dus à cette catégorisation incorrecte. Lorsqu’un processus de boîte noire est traité comme un processus entièrement défini, des résultats imprévisibles se produisent. De plus, les contrôles ne sont pas en place pour mesurer l’imprévisibilité et y réagir.

Références

1. Bach, James. "Process Evolution in a Mad World." Borland International, Scotts Valley, CA.
2. Bach, James. October, 1995. "The Challenge of "Good Enough" Software", American Programmer.
3. Coplien, J. "Borland Software Craftsmanship: A New Look at Process, Quality and Productivity." Proceedings of the 5th Annual Borland International Conference, June 5, 1994. Orlando, Florida.
4. DeGrace, P. and Hulet Stahl, L. 1990. Wicked Problems, Righteous Solutions. Yourdon Press
5. Gleick, J. 1987. Chaos, Making A New Science. Penguin Books.
6. Kahn, D. and Sutherland, J. March-April 1994. "Let's start under-promising and over-delivering on OT." Object Magazine.
7. Ogunnaike, B. 1994. Process Dynamics, Modeling, and Control. Oxford University Press.
8. James Rumbaugh, October 1995, "What Is a Method". Journal of Object Oriented Programming.
9. Takeuchi, Hirotaka and Nonaka, Ikujiro. January-February 1986. "The New Product Development Game." Harvard Business Review.
10. Takeuchi, Hirotaka and Nonaka, Ikujiro. 1995. The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation, Oxford University Press.