Scrum Tour d'horizon de la mthode

Agenda
Agilit Scrum Pilotage d'un projet agile selon Scrum Contractualisation Forces & questions ouvertes

Les mthodes agiles

Mthodes de dveloppement d'applications logicielles caractrises par
Leur approche adaptative plutt que prdictive Leur orientation vers les personnes plutt que vers les processus Mthodes les plus connues : XP, Scrum

Concepts formaliss en 2001 par le Manifeste Agile Les 4 principes essentiels du Manifeste Agile
L'quipe >> Personnes et interactions plutt que processus et outils L'application >> Logiciel fonctionnel plutt que documentation complte La collaboration >> Collaboration avec le client plutt que ngociation de contrat L'acceptation du changement >> Ragir au changement plutt que suivre un plan
Un objectif : la russite des projets informatiques
Sanjiv Augustine 3 CC Pace Systems, Inc

La mthode Scrum
Initialise par Ken Schwaber et Jeff Sutherland en 1996 (volutive) Utilise pour organiser les quipes et amliorer la productivit avec une meilleure qualit
L'quipe est implique : elle peut choisir la quantit de travail raliser et comment le raliser de faon optimale
> climat serein propice une meilleure productivit > quipe en confiance et responsabilise

Le client est impliqu : Scrum est conue pour s'adapter rapidement aux volutions et aux demandes du clients
> amlioration de la satisfaction client et limination des "dchets" (fonctionnalits sans valeur ajoute pour l'utilisateur)

La mthode se concentre sur la valeur mtier des fonctionnalits et priorise l'implmentation en fonction de cela
> adaptabilit & ractivit

La mthode favorise des cycles de dveloppement courts

> retour sur investissement rapide, pas d'effet tunnel
4

Phases d'une version de projet

Le projet est dcoup en versions (releases), elles-mme divises en itrations (appeles Sprint)
CC-BY-1.0

{Version} Prparer, cadrer

Pr-jeu
Planning Dfinition du backlog, des jalons, de l'quipe Identification des facteurs de risques Choix des outils & infrastructure + logistique Budget, chiffrage & estimation du cot Architecture gnrale, conception gnrale

Adapter

Dvelopper

Sprints Revoir

Jeu
Sprints Dveloppement (analyse, conception, codage)> livraison > rvision > adaptation (~ Plan/Do/Check/Act)

Packager

Post-jeu
Finaliser

Packaging global de la version Intgration & jeux de tests Documentation & manuels utilisateur globaux, accompagnement au changement
5

Les rles & artfacts

Rles
PO

Artfacts (lments produits)

Backlog produit Liste des macro-fonctionnalits de l'application, priorises par leur valeur mtier
TODO

Product Owner Reprsentant du client et des utilisateurs. Formalise et priorise le backlog du produit

SM

Scrum Master Meneur d'quipe, facilitateur, travaillant de faon rapproche avec le Product Owner et l'quipe

Backlog de Sprint

Liste des tches implmenter sur un Sprint, classes par importance et tat

Burn-down chart
E

quipe +/- 7 personnes Elle doit tout faire pour dlivrer le produit (organisation, profils, ...). La responsabilit est collective.

Diagramme permettant de suivre l'avancement du projet (reprsentation du Reste Faire)

Produit partiel Rsultat du Sprint, test et potentiellement livrable.

Intervenants ("chickens & pigs") Observent & conseillent

6

Le cycle de dveloppement
Backlog produit Vision
SM PO PO I

[vers Sprint suivant]

Product Owner Scrum Master Equipe
I PO SM

[Sprint]
SM

Backlog de sprint
E
I TODO

PO

24h
E

SM

E
I

Produit partiel

24 semaines

Intervenants

Points de rencontres
Planification du sprint Avant le dmarrage du sprint, pour dfinir l'objectif et le plan dtaill de l'itration Mle Photo quotidienne du projet, pour identifier de nouvelles dpendances, rpondre aux besoins de l'quipe, ajuster le plan de travail Revue/Rtrospective de sprint Revue pour vrifier la conformit de ce qui a t ralis pendant le sprint Rtrospective pour amliorer le sprint suivant
7

Activits d'un projet Scrum

Ralisation d'un Sprint

Activits & organisation de l'quipe

Elle s'auto-organise, estime, fait les choix et se rpartit les tches pour dlivrer le produit partiel

Intgration continue pour une optimisation des dveloppements et des tests Profils : dveloppeurs, intgrateurs, experts (DBA, ...), ...

Elle doit tre dans un environnement optimis pour atteindre l'objectif

Le Scrum Master veille au quotidien ce que l'quipe soit au mieux Les informations sont partages : tableaux blancs, WIKI, ...

Les tableaux de bord et indicateurs sont actualiss quotidiennement par le Scrum Master et permettent de suivre l'avancement de l'itration.

Mthodes
L'estimation, l'analyse et la conception sont ralises avec des mthodes agiles (cartes, index, croquis UML, ...) L'accent est mis sur les tests (Test Driven Developpement > mesure d'avancement par les tests, issu de l'XP)
8

Estimations, planification, avancement

Estimations :
par analogie de prfrence (utilisation du ralis comme rfrence), ou par point de fonction Utilisation de mthodes agiles ("planning poker")

Activits d'un projet Scrum

Planification
Le planning doit permettre l'quipe de "souffler" entre 2 sprints

Exemple : dmos & rtrospective le vendredi matin pour le sprint n, planification du sprint n+1 le lundi matin vendredi AM libre pour de la veille, ...

Les estimations et la planification se basent sur le calcul de la vlocit

Vlocit estime = (nb de jour/homme disponibles) x (coefficient d'effort)
rel, aprs application congs, temps partiel, ...

Le coefficient d'effort est une estimation sur la concentration de l'quipe. Il peut tre valu partir des sprint prcdents. Par exemple :
La correction d'anomalie peuvent tre intgres dans ce coefficient, les difficults techniques peuvent tre vues comme des "tech stories"
SCRUM and XP from the Trenches, Henrik Kniberg
9

Outillage d'un projet Scrum

Outils Excel (cf. exemple http://blog.crisp.se/henrikkniberg) Backlog (produit, Systme de suivi de bug (Mantis, ...) sprint) Spcifique Agile (VersionOne, Xplanner, ScrumWorks, IceScrum, Jira, Eclipse Plugin...)

Notes
Excel est suffisant pour la gestion de la liste, mais on ne peut se passer d'un outil de suivi des anomalies. Pas de best practices, si ce n'est faire au simple et au mieux pour l'quipe

Communication & gestion documentaire Gestion de conf. & intgration continue Pilotage (tableaux de bord)

WIKI Tableau de tches ("Sprint wall" + post-it, appareil photo...) Imprimer les cartes du backlog pour les afficher au regard de tous Espace de stockage Subversion Hudson, Continuum ... Indicateurs : RAF, vlocit, rpartition de charge codage/test/correctif, ...) excel, Spcifique Agile (cf. backlog) Actions : idem > Excel ou spcifique Risques : idem
A homogniser avec la gestion des backlogs Complexit dfinir les diagrammes sous excel?? (burn-down chart...) A homogniser avec la gestion des backlogs

Pilotage (suivis)

10

Aspect contractuel (1/2)

Problmatique : comment grer un projet Scrum sur le plan contractuel, sachant que les concepts Agiles prfrent la collaboration la ngociation de contrat?
Contrats pour les forfaits "classiques"

prix fixe, primtre fixe 4 axes caractriss et figs : Primtre, budget, dlai, qualit

Dans un contrat plus agile, on peut imaginer

De la part du soumissionnaire, un engagement sur les moyens (comptences, mthodes, pilotage, ...) pour assurer la qualit

Estimation du rapport qualit/prix plutt que prix le plus bas Exemples de critres : niveau de qualit (mthodes, ...), frquence des feedbacks, expriences des ressources, capacit s'adapter, communication, maturit de la relation client

Un budget et des dates de livraisons (dure du sprint) fixs par le client Un primtre initial trac de faon collaborative (backlog produit initialis conjointement)
11

Aspect contractuel (2/2)

Diffrentes approches possibles pour l'agilit
Contrat engagement de moyens (~rgie) : primtre variable et cot fixe

Risques principaux : retard de livraison, d-responsabilisation du soumissionnaire

Co-sourcing
Prconis par Valtech

Equipe mixte, sur le site du client Visibilit, transfert de comptences intrinsque, risques partags (des ressources des deux parties sont impliques) Le cot et le dlai sont fixs par le client le primtre est la variable d'ajustement Le soumissionnaire se positionne sur sa capacit et son savoir-faire (engagement sur des critres de qualit) Le contrat a donc bien un prix et une date fixs. La diffrence est dans la frquence de livraison et dans l'ajustement du primtre. Forte implication des parties Dfinition de points de mesures concrets et reprsentatifs (par exemple : Dfinition d'units d'uvre, engagement sur un niveau de qualit, ...)
12

Forfait collaboratif
Prconis par Aubry

Forfait avec engagement mesurable

Prconis par

Scrum, forces & questions ouvertes (1/2)

Forces
Copilotage avec le client

Questions

Propice une confiance rciproque Transparence sur l'avancement (rsultats rapides) Adaptabilit : le client peut modifier son besoin

Le client est-il prt s'impliquer? Comment grer le changement par rapport au mode classique? (organisation, comportements, contrat, ...) Comment viter de retourner dans le mode classique au 1er point dur?

Equipe & responsabilit collective

Capacit travailler en quipe, partager? Capacit se responsabiliser, s'impliquer Plus de responsabilisation, plus de motivation (envie?) Pas d'individualisme Capacit faire l'effort d'tre polyvalent? (alternance codage, tests, correctif) Amlioration permanente Comment grer les ressources non adaptes ce mode de fonctionnement?

13

Scrum, forces & questions ouvertes (2/2)

Forces
Cadre de production, mthodologies

Questions

Orient productivit et qualit pas de travail superflu Environnement adapt (IC) Orient tests (TDD) Plus de souplesse et de crativit Recherche de la simplicit Pilotage au quotidien

Framework minimaliste > risque d'htrognit? (si mauvaise communication dans l'quipe...) Comment justifier et estimer le surcot li aux tests et la mise en place de l'environnement d'IC? Pour un 1er Scrum, comment estimer la charge de pilotage? (accrue par rapport forfait "classique" + cot des outils si spcifiques agile)

14