Plusieurs personnes m'ont demandé de republier des informations historiques sur Scrum. Cette information a été publiée sur mon site web en 1995 après que Bob Martin, signataire du Manifeste Agile, se soit exprimé sur la gestion de projet.
Groupe : comp.lang.smalltalk
De : rmartin@rcmcon.com Robert Martin
Org : R. C. M. Consulting Inc. 708-918-1004
Date : Fri, 3 Feb 1995 16:05:49 GMT
Subj : Re : Gestion de projet OO
____________________________________________________________
La question a été posée : "Comment utiliser notre projet standard ?
des outils de gestion pour aider à gérer les projets OO ? En apparence, les
Il semble qu'il s'agisse d'un problème important. Nous avons utilisé le
d'outils normaux pour la gestion de projets "en cascade", et il est
Il est difficile de voir comment ils peuvent être utilisés pour gérer des projets "itératifs".
Cependant, la suite standard d'outils de gestion de projet (par exemple PERT et
CPM et Ghant) ne sont pas incompatibles avec le développement itératif. Ils
sont conçues pour modéliser les calendriers des projets, et des
Les projets ont toujours un calendrier.
La difficulté réside dans le fait que les éléments du calendrier sont différents. En effet, en
dans la gestion de projet en cascade, les éléments du calendrier sont
"Analyse", "Conception", "Mise en œuvre", "Test", etc. Cependant, en
développement itératif, il n'est normalement pas judicieux d'utiliser de telles
les objets. Quels articles devrions-nous utiliser ?
Il existe un mythe répandu selon lequel les projets itératifs sont des projets qui ne comportent pas d'éléments de preuve.
des horaires. Ils divaguent, ici et là, jusqu'à ce qu'un technicien
décide qu'il a accompli suffisamment de travail et déclare le projet
complète. Ce n'est pas le cas. Un projet itératif a un calendrier
comme n'importe quel autre projet, et ce calendrier peut être modélisé à l'aide de
outils standard de gestion de projet
Au début d'un projet itératif, l'application est décomposée en
de nombreux sous-projets, chacun avec un très petit nombre de caractéristiques. Ces
Les sous-projets sont parfois appelés tranches verticales, ou simplement tranches.
Chaque tranche représente une petite quantité de travail à effectuer.
accompli. Il doit être possible de classer les tranches dans le temps, de telle sorte que
que les fonctionnalités mises en œuvre dans les tranches antérieures ne dépendent pas de la
les caractéristiques mises en œuvre dans les tranches ultérieures. Ainsi, les tranches peuvent être
dans un ordre chronologique.
Une fois les tranches attribuées, chacune d'entre elles peut faire l'objet d'une estimation en ce qui concerne le nombre d'heures de travail.
les ressources nécessaires à sa mise en œuvre. Ensuite, ces tranches
peuvent être présentés sur un graphique PERT, ou tout autre outil de gestion de projet, pour
produire une estimation complète du projet. Toutefois, cette estimation est
extrêmement peu fiable.
Au début du projet, le temps nécessaire à la mise en œuvre de la première phase de l'étude est de trois mois.
est enregistrée et réinjectée dans le programme. Chaque fois qu'une tranche
Nous en savons plus sur le temps que les autres tranches mettront à s'écouler.
prendre. Ainsi, notre calendrier devient de plus en plus précis au fil du temps
le. La date de fin du calendrier changera (probablement en recul) au fur et à mesure que le
davantage de données sur la mise en œuvre des tranches sont obtenues.
Fred Brooks a dit un jour : "L'ajout de main d'œuvre à un projet en retard le rend
plus tard". C'est certainement le cas lorsque 80% de l'emploi du temps a été
et seuls 40% du projet ont été réalisés. L'avantage
de l'ordonnancement itératif est que le retour d'information concernant l'exactitude des
l'horaire revient très tôt. Après les premières tranches,
project managers can begin to measure the error in their initial
estimates and plan for resource changes. Thus they can add manpower
to an early project so that it does not become late. (Or they can
decide to scrap the project altogether).
Note, that the items that are placed into the project management tool
are not "Analysis", "Design", etc. They are the slices themselves.
In projects that are really big, the slices should be broken down into
sub-slices, using exactly the same scheme. The schedule for these
slices should also be broken down into sub-schedules, and the process
repeated in a hierarchical fashion.
French 
English 
Spanish