« Processus de développement de logiciels SCRUM (1995) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (24 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: | [[Category: Ken Schwaber]] | ||
[[Category: Portail Framework]] | [[Category: Portail Framework]] | ||
Auteur : | Auteur : Ken Schwaber<br/> | ||
Sources : | |||
* [https://web.archive.org/web/20050706130307/http://jeffsutherland.com/scrum/ADM/scrumwp.htm SCRUM Software Development Process (web.archive.org)] | |||
* [https://www.scrum.org/resources/scrum-development-process SCRUM Development Process] présenté lors de [https://jeffsutherland.com/oopsla/oo95summary.html OOPSLA '95] | |||
Date : 22/11/1995 (dernière mise à jour)<br/> | Date : 22/11/1995 (dernière mise à jour)<br/> | ||
---- | ---- | ||
| Ligne 8 : | Ligne 10 : | ||
Date : 07/12/2023<br/> | Date : 07/12/2023<br/> | ||
---- | ---- | ||
Traduction :<br/> | |||
<br/> | |||
[[Fichier:Logo oopsla1995.gif|border|left|link=]] Il s'agit du document original (mis à jour le 5 avril 1996) sur Scrum, basé sur la présentation à [https://www.sigplan.org/Conferences/OOPSLA/ OOPSLA] 1995 (du 15 au 19 octobre à Austin, Texas) où le concept de Scrum a été initialement présenté. | |||
La philosophie déclarée et acceptée pour le développement de systèmes est que le processus de développement est une approche bien comprise qui peut être planifiée, estimée et menée à bien. Cette philosophie s'est avérée incorrecte dans la pratique. SCRUM part du principe que le processus de développement de systèmes est un processus imprévisible et complexe qui ne peut être décrit que de manière approximative en tant que progression globale. SCRUM définit le processus de développement de systèmes comme un ensemble souple d'activités qui combine des outils et des techniques connus et utilisables avec ce qu'une équipe de développement peut concevoir de mieux pour construire des systèmes. Étant donné que ces activités sont souples, des contrôles sont utilisés pour gérer le processus et les risques inhérents. SCRUM est une amélioration du cycle de développement itératif/incrémental orienté objet communément utilisé.<br /> | |||
<br/> | |||
<big>'''Construire le meilleur logiciel possible'''</big><br/> | |||
''"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."'' | |||
"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"'' | ''James Bach. Octobre 1995. "American Programmer"'' | ||
| Ligne 79 : | Ligne 86 : | ||
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. <br/> | 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. <br/> | ||
<br/> | <br/> | ||
[[spiral-model.jpg|border|link=]]<br/> | [[Fichier:spiral-model.jpg|border|link=]]<br/> | ||
<small>''Figure 2 : illustration de la méthodologie en Spirale''</small><br/> | <small>''Figure 2 : illustration de la méthodologie en Spirale''</small><br/> | ||
<br/> | <br/> | ||
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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
[[iterative-methodology.jpg|border|link=]]<br/> | [[Fichier:iterative-methodology.jpg|border|link=]]<br/> | ||
<small>''Figure 3 : illustration de la méthodologie Itérative''</small><br/> | <small>''Figure 3 : illustration de la méthodologie Itérative''</small><br/> | ||
<br/> | <br/> | ||
| Ligne 97 : | Ligne 104 : | ||
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. <br/> | 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. <br/> | ||
<br/> | <br/> | ||
[[defined-process-risk-complexity-graph.jpg|border|link=]]<br/> | [[Fichier:defined-process-risk-complexity-graph.jpg|border|link=]]<br/> | ||
<small>''Figure 4 : illustration de la complexité/du risque d’un processus défini''</small><br/> | <small>''Figure 4 : illustration de la complexité/du risque d’un processus défini''</small><br/> | ||
==Méthodologie== | ==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. <br/> | 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. <br/> | ||
<br/> | <br/> | ||
| Ligne 109 : | Ligne 116 : | ||
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. <br/> | 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. <br/> | ||
<br/> | <br/> | ||
[[risk-complexity-comparison-graph.jpg|border|link=]]<br/> | [[Fichier:risk-complexity-comparison-graph.jpg|border|link=]]<br/> | ||
<small>''Figure 5 : illustration de la comparaison risque/complexité''</small><br/> | <small>''Figure 5 : illustration de la comparaison risque/complexité''</small><br/> | ||
<br/> | <br/> | ||
| Ligne 131 : | Ligne 138 : | ||
<br/> | <br/> | ||
{| class="wikitable" style="margin:auto" | {| class="wikitable" style="margin:auto" | ||
|+ Tableau de comparaison des 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 | ! 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 | ||
| Ligne 143 : | Ligne 150 : | ||
| Date de fin || Déterminé pendant la planification || Partiellement variable || 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 | | 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 | | 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 | | 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 | | Probabilité de succès || Faible || Moyennement faible || Moyenne || '''Forte''' | ||
|} | |} | ||
<br/> | <br/> | ||
==Phases== | ==Phases SCRUM== | ||
SCRUM comporte les groupes de phases suivants : | SCRUM comporte les groupes de phases suivants : | ||
| Ligne 169 : | Ligne 176 : | ||
<small>''Figure 8 : illustration du flux de la méthodologie SCRUM</small><br/> | <small>''Figure 8 : illustration du flux de la méthodologie SCRUM</small><br/> | ||
==Étapes des phases== | ===Étapes des phases=== | ||
Chacune des phases comporte les étapes suivantes :<br/> | Chacune des phases comporte les étapes suivantes :<br/> | ||
===Planification=== | ====Planification==== | ||
* Élaboration d'une liste backlog globale. | * Élaboration d'une liste backlog globale. | ||
* Définition de la date de livraison et des fonctionnalités d'une ou plusieurs versions. | * Définition de la date de livraison et des fonctionnalités d'une ou plusieurs versions. | ||
| Ligne 184 : | Ligne 191 : | ||
* Vérification de l'approbation et du financement de la Direction. | * Vérification de l'approbation et du financement de la Direction. | ||
===Architecture/Conception de haut niveau=== | ====Architecture/Conception de haut niveau==== | ||
* Revoir les éléments du backlog qui lui ont été affectés. | * 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. | * Identifier les changements nécessaires à la mise en œuvre des éléments du backlog. | ||
| Ligne 192 : | Ligne 199 : | ||
* 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. | * 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)=== | ====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 : | 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. | * Réunion avec les équipes pour examiner les plans de release. | ||
| Ligne 212 : | Ligne 219 : | ||
* 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. | * 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=== | ====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. | 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== | ===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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
| Ligne 232 : | Ligne 239 : | ||
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. | 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== | ===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. | 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== | ===É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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
| Ligne 242 : | Ligne 249 : | ||
* É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. | * É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== | ===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 : | 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 | 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 : | Les projets SCRUM présentent les caractéristiques suivantes : | ||
