Discussion :

[loic_midy]

bonjour,

je travaille dans la sphère informatique à l'INSEE. Nous utilisons pour le moment une méthode de gestion de projet type cascade (spec générale puis spec détaillée puis développement puis tests,...).

Je suis intéressé par les méthodes agiles et par SCRUM et XP en particulier qui si j'ai bien compris peuvent être combinées.

Voici en tant que débutant mes questions :
1 : au tout début d'un projet nous avons besoin d'avoir une estimation de son coût en jours*hommes pour pouvoir arbitrer entre les projets (et donc en rejeter éventuellement car les ressources ne sont pas suffisantes). Nous avons donc un doc d'expression des besoins de la MOA puis une phase de conception générale avec une estimation de charge avec la méthode des points de fonctions (tout celà prend environ 6 mois). Comment réaliser cela en méthode agile?

2: comment doit on faire les spécifications en SCRUM? J'ai lu en diagonale le livre scrum et xp des tranchées dans lequel on parle de description d'histoires. Cela me semble adapté pour des histoire liées à une IHM mais comment faire pour des traitements métiers complexes (soit associés à l'IHM soit en traitement batchs). Chez nous les traitements métiers sont très complexes et je ne vois pas comment raconter les histoires associées lors d'une réunion de planning de sprint (raconter l'histoire prendrait plusieurs heures). Il me semble que dans ces cas il nous faut tout de même une spécification détaillée pour pouvoir développer (ex: une spec pour le tirage d'un échantillon d'enquête).

3: en lien avec la question 2. Peut être que SCRUM n'est adaptée que dans les projets dans lesquels le besoin du client peut se décrire facilement en terme d'IHM? Chez nous pour une bonne partie de nos projets, le besoin du client est défini en premier en terme de données et de traitements faits sur les données (contrôle des données et apurement, codification automatique, agrégations,...), la partie IHM est secondaire: elle sert à faciliter la mise en oeuvre des traitements.

4: que devient le chef de projet informatique dans SCRUM? Il me semble qu'il n'y en a pas.

cordialement

[pseudocode]

Il y a 2 niveaux de BackLog en SCRUM.

- Le BackLog du Produit, qui correspond aux fonctions issues de l'analyse fonctionnelle. On est ici au niveau du Cahier des charges / Exigences

- Le BackLog du Sprint, qui correspond aux fonctions à implémenter dans le logiciel. On est ici au niveau spécification / Design.

1 : au tout début d'un projet nous avons besoin d'avoir une estimation de son coût en jours*hommes pour pouvoir arbitrer entre les projets (et donc en rejeter éventuellement car les ressources ne sont pas suffisantes).

Ici, on est en amont des Sprint, donc au niveau BackLog du Produit.

Pour estimer les couts, on peut utiliser la méthode du "Planning poker" qui consiste à demander aux équipes techniques d'attribuer des "points de complexité" pour chaque fonction du BackLog Produit.

2: comment doit on faire les spécifications en SCRUM? J'ai lu en diagonale le livre scrum et xp des tranchées dans lequel on parle de description d'histoires. Cela me semble adapté pour des histoire liées à une IHM mais comment faire pour des traitements métiers complexes (soit associés à l'IHM soit en traitement batchs). Chez nous les traitements métiers sont très complexes et je ne vois pas comment raconter les histoires associées lors d'une réunion de planning de sprint (raconter l'histoire prendrait plusieurs heures). Il me semble que dans ces cas il nous faut tout de même une spécification détaillée pour pouvoir développer (ex: une spec pour le tirage d'un échantillon d'enquête).

Les specs sont écrites à partir du Backlog Produit car il contient les exigences qu'il va falloir spécifier. Ensuite il y a 2 moyens:

- Le travail de spécification est effectué en meme temps que l'implémentation, et donc est inclus dans le Backlog du Sprint.

- Le travail de spécification est effectué en parrallèle de l'implémentation, dans un "Sprint spécifique" (avec possibilité de durées différentes).

Personnellement, je recommande d'avoir au début 2 équipes en parrallèle. Il faut plusieurs itérations pour avoir un début de spec utilisable. Pendant ce temps, l'equipe d'implémentation s'occupe de mettre en place la plomberie (outils, frameworks, configurations, ...)

3: en lien avec la question 2. Peut être que SCRUM n'est adaptée que dans les projets dans lesquels le besoin du client peut se décrire facilement en terme d'IHM? Chez nous pour une bonne partie de nos projets, le besoin du client est défini en premier en terme de données et de traitements faits sur les données (contrôle des données et apurement, codification automatique, agrégations,...), la partie IHM est secondaire: elle sert à faciliter la mise en oeuvre des traitements.

Non, on peut utiliser SCRUM sur tout type de projet. L'idée de SCRUM c'est de faire des itérations courtes, basées sur un "contenu" qui est définit AVANT le début d'itération et qui est IMMUABLE durant toute l'itération.

4: que devient le chef de projet informatique dans SCRUM? Il me semble qu'il n'y en a pas.

Bah, il sert à rien comme d'habitude.

Non, serieusement le CdP s'occupe de la conduite du projet c'est à dire de gérer le nombre, la durée et le contenu des RELEASES. C'est le scrum master qui s'occupe de découper les releases en Sprint et de faire l'interface entre les demandes du CdP et la définition des BackLog.

[Patriarch24]

Non, serieusement le CdP s'occupe de la conduite du projet c'est à dire de gérer le nombre, la durée et le contenu des RELEASES. C'est le scrum master qui s'occupe de découper les releases en Sprint et de faire l'interface entre les demandes du CdP et la définition des BackLog.

Il n'y a pas de CP dans Scrum, mais un "Directeur de Produit", qui est plus le "client" que le CP traditionnel. D'ailleurs, en méthode agiles il n'y a pas de "chef de projet", mais seulement un "manager d'équipe", ce qui est sensiblement différent.

[pseudocode]

Il n'y a pas de CP dans Scrum, mais un "Directeur de Produit", qui est plus le "client" que le CP traditionnel. D'ailleurs, en méthode agiles il n'y a pas de "chef de projet", mais seulement un "manager d'équipe", ce qui est sensiblement différent.

Dans la théorie oui. En pratique, les CP ont du mal à renoncer au prestige de leur titre.

[Patriarch24]

Dans la théorie oui. En pratique, les CP ont du mal à renoncer au prestige de leur titre.

On est entièrement d'accord. C'est d'ailleurs pour cela que les méthodes agiles ont du mal à s'imposer en France.

[predacktor]

Je ne suis pas franchement d'accord avec la définition de la méthode évoquée. Au sujet de son adoption en France voire dans le monde, elle a considérablement augmenté entre 2007 et 2009 (voire les rapports de VersionOne), et la crise fera office de moteur dans l'optique de maitriser les côuts/besoins.


Je travaille sur un outil de gestion de la méthode opensource avec quelques sympathisants et des étudiants (http://www.icescrum.org). Voici comment nous avons implémenté les pratiques de la méthode par rapport à vos besoins :
Pour estimer le cout d'un projet, on se base sur le vécu de l'équipe. Tout d'abord, un projet est découpé à grosse maille en "Features" : les supers fonctionnalités transverses. On assure un lien avec le métier fonctionnel.


On voit bien les concepts clés du projet (Note: on gère notre logiciel en mode Scrum avec notre propre logiciel^^). Ca permet également d'assurer une catégorisation des besoins plus détaillés.

On découpe alors ces "features" en "stories". Un backlog de produit -ou liste des besoins fonctionnels/non fonctionnels- garde une trace de tout ceci. Ces besoins peuvent être estimés par l'équipe en flux tendu (au fur et à mesure) ou avant le lancement du projet. Mais attention Scrum ne verrouille pas cette liste :pendant le développement, des fonctionnalités vont disparaître, changer de priorité, ou apparaître. La phase estimation fait l'objet d'un jeu qui s'appelle Planning Poker et se fait avec les membres actifs du projet (Membres, Scrum Master, Product Owner). A partir du ressenti technique sur la complexité et la valeur ajoutée on obtient un nombre de points relatifs : une page de login (1pt) et une page administration des produits (5pts).



Enfin au lancement du sprint 0 (vrai faux sprint avant le lancement du développement) on déterminera et fera des études sur la faisabilité et la technicité des besoins afin de parfaire l'estimation ensemble et de fournir une premiere planification temporelle de référence.

Un projet est découpé en releases, elles mêmes découpées en itérations (sprints) de x jours. La planification consiste à définir quand démarre et finit une release, combien de sprints sont prévus et quand les stories seront développées. La force de la méthode est de s'auto ajuster avec le temps. La priorisation du backlog de produit auparavant permet de naturellement placer les stories mais c'est surtout le nombre de points moyen (vélocité) que l'équipe peut produire en un sprint (en finissant une story complètement) qui va affiner cette planification. Si l'équipe fait 20 points en moyenne, inutile de prévoir 40 points dans le sprint 2. Cela marche si le turnover est faible car la connaissance du projet aura tendance à grandir et la productivité aussi avec une équipe durable.

La vélocité mise à jour, on peut faire des tendances et estimer le reste à faire en points facilement :


Enfin à l'intérieur d'un sprint les stories sont découpées en tâches de travail. En effet elles ne font qu'exprimer des besoins d'assez haut niveau mais pas la manière de les réaliser. On peut également y associer des tests d'acceptation qui valideront l'état "Fini" de la story. Le découpage en tâche donne l'occasion à l'équipe de faire une réunion de lancement du Sprint qui estime le côut en unité de temps et non en point. Les tâches ont 3 états classiques : en attente, en cours, fait. On produit un "dashboard" de Sprint de cette manière.


Le plus régulièrement possible (en théorie tous les jours), l'équipe se réunit à l'occasion du daily Scrum. Elle y présente membre par membre ce qu'elle a fait depuis la dernière "dailyScrum", ce qu'elle va faire jusqu'à la prochaine et les problèmes qu'elle a rencontré. C'est une occasion aussi pour mettre à jour le 'reste à faire' des tâche, en effet on ne trace pas le consommé c'est à dire les heures passées à effectuer la tâche. La est un point difficile à accepter pour certains traditionnels suivis de budget et pourtant se focaliser sur ce qu'il faut faire est nettement plus productif. Cependant on peut étudier la gestions des ressources d'un sprint (pas le cas encore dans icescrum), c'est à dire savoir si un membre est chargé à 100% en se basant sur sa durée travaillée dans le sprint et la durée des tâches qu'il a prises. La méthode est productive mais veut rester humaine, un sprint c'est pas comme son nom ne l'indique pas une course contre la montre stressante. Bien sûr il s'en dégage un peu de pression d'être timeboxé en si peu de temps (3semaines en général) mais cela doit rester de la pression positive.

Finalement vu que chaque jour les membres mettent à jour leurs tâches, on peut produire un graphe : le burndown chart de sprint. Il permet de constater l'avancement technique à faible granularité et de corriger le tir si quelque chose cloche. Exemple de soucis sur la courbe ci dessous, au 8ème et 13ème jours le Scrum Master (coach d'équipe) s'est aperçu que le reste à faire cumulé du sprint stagnait, lors d'une réunion un point particulier a été étudié afin de determiner la raison du blocage


A la fin du Sprint, le product owner valide les stories finies et le scrum master peut alors cloturer le sprint et lancer le suivant lors du cérémonial post sprint (revue + retrospective + réunion de lancement du prochain sprint).

J'espère avoir été simple et clair dans ce résumé parfois réducteur de la méthode

[predacktor]

bonjour,
2: comment doit on faire les spécifications en SCRUM? J'ai lu en diagonale le livre scrum et xp des tranchées dans lequel on parle de description d'histoires. Cela me semble adapté pour des histoire liées à une IHM mais comment faire pour des traitements métiers complexes (soit associés à l'IHM soit en traitement batchs). Chez nous les traitements métiers sont très complexes et je ne vois pas comment raconter les histoires associées lors d'une réunion de planning de sprint (raconter l'histoire prendrait plusieurs heures). Il me semble que dans ces cas il nous faut tout de même une spécification détaillée pour pouvoir développer (ex: une spec pour le tirage d'un échantillon d'enquête).

3: en lien avec la question 2. Peut être que SCRUM n'est adaptée que dans les projets dans lesquels le besoin du client peut se décrire facilement en terme d'IHM? Chez nous pour une bonne partie de nos projets, le besoin du client est défini en premier en terme de données et de traitements faits sur les données (contrôle des données et apurement, codification automatique, agrégations,...), la partie IHM est secondaire: elle sert à faciliter la mise en oeuvre des traitements.

Les histoires utilisateurs ou stories peuvent cacher un immense iceberg - quoi que leur poids en points va s'alourdir. Pour décrire une story, on se sert non seulement de son identité ("En tant que Observateur Je peux obtenir un rapport statistique détaillé sur le recensement de l'année souhaité Afin de renseigner une analyse extérieure") mais aussi de ses tests d'acceptation (résultats attendus qui peuvent être détaillés dans le cadre de process complexes), son thème ou feature parent, son type ("spike"=>étude,"bug"=>feedback correctif et "user story"). Il y a toujours un moyen de raffiner une story et donc de la découper en sous problèmes, comme en ingénierie des exigences.
Ce qui est vrai c'est que la méthode s'applique plus facilement aux équipes ouvertes aux changements et aux développements non critiques/embarqués. L'adoption a toujours droit à sa chance, avec un peu de volonté les résultats arriveront toujours. J'ai vu/entendu des institutions du développement classique (état,grand compte) changer leur stratégie même si parfois c'est une intention plus politique qu'une volonté de faire du Scrum. Je crois que le principal frein reste le forfait classique des SSII.

4: que devient le chef de projet informatique dans SCRUM? Il me semble qu'il n'y en a pas.

Selon le profile (position, fonctionnel ou technique, ...) le chef de projet peut jouer le rôle du Product Owner ou du Scrum Master. J'ai vu les 2 possibles mais c'est vrai que la fonction n'est pas défini dans le projet Scrum même. Le chef de projet est en général le Scrum Master puisqu'il permet de s'interfacer avec les problemes et son équipe, de coacher le groupe et de donner le rythme de développement : ce qui peut se rapprocher de son ancienne fonction.