Discussion :

[randriano]

Bonjour,

D'abord, je sais: le terme "méthode" ici peut faire débat!!

Dans la phase d'analyse habituelle (ou ancienne) d'un projet informatique, on perd beaucoup de temps à imaginer totalement tout le projet puis de faire une modélisation UML du projet par exemple. Cela peut aller jusqu'à l'élaboration des wireframes même!!

VRAI OU FAUX: avec Scrum, il n'y a plus de tout cela? Le temps de l'analyse est réduit? Car on ne fait plus que le "scrum poker".

La notion de "deadline" d'un projet n'est plus d'actualité avec Scrum?? Les sprints permettent d'avoir une visibilité mais pas une deadline précise! VRAI OU FAUX également?

[Laurent 1973]

Une réponse de normand: Vrai et Faux

Le temps d'analyse n'est pas réduite, mais elle ne se fait plus pareil.

On commence au début par une analyse succincte afin d'établir un premier "Product Backlog" de fonctionnalités.
Chaque item est alors trié par importance pour s’intéresser à la meilleur valeur ajoutée.
Par contre, régulièrement au cours du développement, on va se pencher sur les fonctionnalités les plus haute pour les analyser plus finement afin qu'elles puissent être réaliser dans le sprint suivant.

Donc, on fait aussi beaucoup d'analyse mais tout au long du projet et au plus près du développement et des besoins utilisateurs en tenant en compte de l'évolution du projet.
Cela permet des analyses beaucoup plus précise, je trouve.

Le "scrum poker" que tu évoques n'est qu'une petite partie de ce temps d'analyse.
C'est juste un temps avec l'équipe de développement pour estimer (en relatif) l'effort de chaque item afin d'affiner les priorités et le contenu de chaque itération.
Le plus gros de l'analyse se fera avec le client sur la prise en compte et la compréhension de ses besoins.

On a aussi des deadlines en Scrum.

Et heureusement parce que les outils informatiques que nous réalisons sont livrés, déployés, exploités.
Quand un SI bloque un temps pour migrer un outil sur des serveurs, c'est important d'avoir des dates précises.

Par contre, si en Scum nous ne cherchons pas à négocier la date de livraison (produit potentiellement livrable à chaque fin de sprint d'une durée fixe) nous allons négocier le contenu de la livraison.
Donc, on pourra s'engager à livrer dans 6 mois une version.
Avec son Product Owner, l'équipe va faire en sorte de livrer un logiciel qui permettra de satisfaire au mieux le client en livrant un produit à grande valeur ajouté.

[Luckyluke34]

Je plussoie, Vrai car on ne fait plus de Big Design Upfront mais Faux car on ne se contente pas de "faire le scrum poker" (heureusement).

• Le caractère itératif de Scrum permet de faire de l'analyse très fréquemment (à l'échelle de la semaine) plutôt qu'une fois en début de projet, et de mettre en place des rétrospectives pour s'améliorer de cycle en cycle.

• Son caractère incrémental signifie qu'on n'analyse en profondeur qu'une petite partie des specs différente à chaque itération, et que cette analyse tient compte des enseignements tirés de la précédente.

Différence très importante aussi, on met en prod très régulièrement pour nourrir notre réflexion de résultats du monde réel plutôt que se baser sur des conjectures.

Concernant les diagrammes UML, qui servent à faire de l'analyse (use cases) mais surtout de la conception (diagrammes de classes, collaboration, état...), le manifeste agile dit qu'un logiciel qui fonctionne a plus de valeur qu'une documentation exhaustive, et que répondre au changement est plus important que suivre un plan. Cela ne veut pas dire qu'on ne doit rien documenter et ne faire aucun plan. Scrum ne dit rien sur la modélisation UML et les wireframes, juste que l'équipe de développement doit réunir tout ce dont elle a besoin pour produire l'incrément logiciel en cours. Si cela veut dire dessiner des diagrammes et faire des maquettes, très bien, attention juste à ne pas les considérer comme des vérités figées dans le marbre et ne pas dépasser le périmètre du sprint.

[randriano]

Réduction de la phase de conception

Effectivement, on arrive toujours à produire un premier "product backlog" mais on est sûr que ce n'est pas assez complet (voire à 60% seulement complet, c'est dangereux). Oui je sais c'est là la logique de la méthode Scrum qui a prévu comment traiter cette incertitude qui existe toujours dans les projets informatiques par sa technique itérative, etc.

J'ai remarqué dans les équipes qui font du Scrum que la longue période de modélisation n'existe plus: fini les diagrammes UML.
C'est comme si Scrum jette à la poubelle toute une unité d'enseignement étudiée dans les écoles d’ingénierie informatique non???

Deadline

Par contre, si en Scrum nous ne cherchons pas à négocier la date de livraison (produit potentiellement livrable à chaque fin de sprint d'une durée fixe) nous allons négocier le contenu de la livraison.

C'est un problème avec un client qui n'arrivera jamais à cerner la méthode Scrum, il acceptera au meilleur des cas d'être coopératif et d'assister à des meeting de fin de sprint.
Il leur faut une deadline!

[ZenZiTone]

Réduction de la phase de conception
J'ai remarqué dans les équipes qui font du Scrum que la longue période de modélisation n'existe plus: fini les diagrammes UML.
C'est comme si Scrum jette à la poubelle toute une unité d'enseignement étudiée dans les écoles d’ingénierie informatique non???

SI je ne me trompe pas, Scrum est une méthode de gestion de projet, pas une méthode de développement... Même si il est constaté une documentation moindre, rien empêche au développeur d'utiliser les outils tels que les diagrammes UML pour concevoir ses bouts de code...

[Laurent 1973]

Deadline

C'est un problème avec un client qui n'arrivera jamais à cerner la méthode Scrum, il acceptera au meilleur des cas d'être coopératif et d'assister à des meeting de fin de sprint.
Il leur faut une deadline!

Je l'ai dis, il y a une deadline, c'est à dire une date à laquelle on livrera le produit logiciel a des fin de mise en production.
Comme on en a discuté dans l'article Pourquoi nous trompons-nous toujours dans l’estimation des délais ?, il y a 4 moyens pour respecter une date de livraison suite a des complications dans le développement:

1. Repousser la date de livraison.
   Par contre, quand les mise en production sont lourde et compliqué, c'est très difficile.
2. Augmenter les ressources humaines et matériel.
   Mais n'oublions pas que certaines durées restent incompressible: On ne fait pas un enfant en 1 mois avec 9 femmes
3. Baisser la qualité.
   Réduire l'investissement de tests, de code review, ... Par contre, ça se paye souvent très chère en support.
4. Changer le périmètre fonctionnel.
   Livrer moins mais dans les délais.

Scrum, comme d'autres méthodes Agiles, préconise plutôt d'agir sur le dernier point en concertation avec le client.

C'est vrai que dans un premier temps, un client aura sûrement du mal à accepter l’incertitude annoncer à l'avance de ce que l'on va lui livrer.
Par contre:

• Combien de fois a-t-il du géré un retard de livraison extrêmement pénible?
• Quel coût d'exploitation a-t-il du faire face suite à un outil instable voir inutilisable en production?

N'oublions pas que le changement de périmètre se fait en total transparence avec le client.
En effet, il n'aura pas toute sa belle liste au Père Noël qu'il avait défini au début, mais on lui livre dans les délais un produit logiciel de haute qualité et répondant au mieux à ces principaux besoins.
Il en a donc le meilleur rapport qualité/prix possible et dans les délais.

Que veux-t-il de plus? Plus de fonctionnalité?
Pas de souci, l'équipe peux continuer pour préparer un nouvelle version prévu à une nouvelle date précise.

[Laurent 1973]

SI je ne me trompe pas, Scrum est une méthode de gestion de projet, pas une méthode de développement... Même si il est constaté une documentation moindre, rien empêche au développeur d'utiliser les outils tels que les diagrammes UML pour concevoir ses bouts de code...

Tout à fait, en Scrum, UML reste toujours un outil pour les développeurs même .

C'est surtout ça qui reste important: c'est un outil pour développeurs
C'est à dire que l'UML n'est pas un but, mais un moyen: le but est de développer un logiciel, pas des documentations.

Par contre, l'outil peut aider les développeurs à réaliser leurs conceptions et améliorer leurs communications.
A ce moment là, ils auraient bien tord de s'en passer.

[autran]

scrum et les deadline
si une SSII travaille au forfait, il y aura contractuellement:

• soit une deadline
• soit une négociation sur du best effort par rapport aux exigence d'un backog

pour des gros projets, tout cela sera ajuster en copil à chaque fin de sprint

scrum et UML
on fait moins de doc et moins d'UML car en général on fait du web et plus du C++ ou du COBOL mais c'est au chef de projet maitrise d'œuvre d'imposer s'il le souhaite de l'UML qui sera sauvegardé avec les sources (En GED pas sur SVN). en effet, en web on fait des maquettes pour découvrir le besoin et on valide en fin de sprint.