« Processus de développement de logiciels SCRUM (1995) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (19 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/> | <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 80 : | 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 98 : | 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/> | ||
| Ligne 110 : | 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 132 : | 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 144 : | 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/> | ||
| Ligne 245 : | Ligne 251 : | ||
===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 : | ||
