Ce document traite de l'adaptation de la méthode Scrum dans les projets forfaitaires, en soulignant les contraintes et les bénéfices de cette approche. Il met en évidence l'importance du partage des risques entre les équipes de développement et les clients, tout en proposant des exemples de projets réussis basés sur Scrum. La conclusion évoque les bonnes pratiques et la nécessité d'une collaboration étroite pour garantir le succès des projets agiles dans un cadre forfaitaire.

1. Les projets au forfait
Scrum but...
But Scrum !
Scrum day France 2011

2. Merci aux sponsors
du Scrum day !
Sponsors Platinum
Sponsors Gold
Parrainage :

3. Copyright
● Cette présentation vous est fournie sous licence Creative Commons
Attribution Share Alike
● Vous êtes libres :
✔ De reproduire, distribuer et communiquer cette création au public
● Selon les conditions suivantes :
✔ Paternité. Vous devez citer le nom des auteurs originaux mais pas
d'une maniere qui suggérerait qu'ils vous soutiennent ou approuvent
votre utilisation de l'œuvre.
✔ A chaque réutilisation ou distribution de cette création, vous devez
faire apparaitre clairement au public les conditions contractuelles de
sa mise a disposition sous licence identique Creative Commons Share
Alike.
✔ Chacune de ces conditions peut être levée si vous obtenez
l'autorisation du titulaire des droits sur cette œuvre.
✔ Rien dans ce contrat ne diminue ou ne restreint le droit moral de
l'auteur ou des auteurs.

4. Ippon Technologies en bref
160
CA
8 000 (Keuros)
CA 2010 : 9,1 ME Effectif
120
Objectif 2011 : 10,5 ME 6 000
115 Collaborateurs : 4 000
80
- Paris
40
- Nantes 2 000
- Bordeaux
- 0
2005 2006 2007 2008 2009 B2010
Principaux Clients 2010 Services
Services Publics : DGA, RATP, SNCF, CCIP, Apec
Banques : Crédit Immobilier, BNP Paribas, Crédit
Mutuel, Société Générale, GMF, Pacifica, Coface - Conseil : Architecture, Performances, Audit, POC
Telecoms / Internet : Orange Vallée, Globecast, - Assistance : Développement, Intégration, « Coaching »
PagesJaunes, Karavel Promovacances - Forfaits : 50 à 1500 j.h, méthodes agiles SCRUM
Distribution : Fnac, Accor, Carrefour, Cora, LVMH, - Centres de services : Agile ou UP / Prise en charge SLAs
Chanel
- Formations : Inter & Intra, 120 cours spécialisés
Industrie : CEA, EDF, Thales, GDF Suez,
Partenaires

5. Qui suis-je ?

20 ans d'activité dans la création de systemes informatique...

Dans l'industrie
 Utilisation de Hood, RUP, 6Sigma...

En SSII
 Passage sur UP, XP, Scrum

Participation a la mise en place de plusieurs socles méthodologiques

Directeur technique chez Ippon Technologies depuis 2003

Chef de projet et Directeur de projet
de plusieurs projets réalisés sur
une base Scrum

6. Scrum et forfait

Pourquoi Scrum peut-il s'adapter au
mode forfait ?

Comment peut-on adapter Scrum au
mode forfait ?

7. La vaste notion de projet

Définition PMI

Entreprise temporaire décidée dans le but de créer un produit,
un service ou un résultat unique

La gestion d'un projet s'inscrit dans des contraintes :
Coût

De périmetre fonctionnel

De délai

De coût
Délai Périmetre

Pour arriver au résultat, plusieurs voies sont possibles dont le
mode forfait

8. Tout est dans le partage du risque !

Traditionnellement, on oppose en SSII :

La régie : délégation de ressources aupres d'un client

Le forfait : prise en charge de la réalisation d'un périmetre
fonctionnel

Forfait : C'est la que ça frotte !

Le Client voudrait garder engagement délai / périmetre / budget

Tout le monde est intéressé par
le changement Partage du risque
Régie

Résistance a s'engager Forfait
SSII Client

9. La préhistoire de la gestion de projet

Waterfall (Cascade)

Hérité du BTP

Ce qui est spécifié est livré
a la virgule pres

Le cycle de prédilection du forfait

Long, tres long

Cycle en V

UP, RUP, 2TUP,...

Parallélisation

Cycle raccourcis

Résistance au changement

10. Introduire de l'agilité dans le forfait

Le manifeste agile : 2001 
Bénéfices

Individuals and interactions over 
Validation permanente du produit
processes and tools 
Flexibilité

Working software over 
Qualité du code
comprehensive documentation

Satisfaction du client

Customer collaboration over contract
negotiation 
Communication et motivation
permanente

Responding to change over following
a plan

Les méthodes agiles 
Contraintes

XP 
Acceptation du changement

Scrum 
Collaboration étroite avec le client

Crystal 
Priorisation des besoins

DSDM 
Prise de décision opérationnelle et
rapide

Lean

Contractualisation adéquate

11. Le forfait « non agile »
Bill – Maitrise ouvrage
« J 'ai fait 42 réunions utilisateurs pour sortir
mes 220 pages de cahier des charges,
c'est la Bible de l'Intranet »
Jo – Chef de projet
« Avec 220 pages de cahier des charges
et 342 pages de specs je suis sûr
que les développeurs vont sortir le projet »
« En plus j'ai pris les moins chers au forfait comme ça
j'aurai du budget pour les avenants »
Mike – Développeur(s)
« Je sais pas lire, je suis a 600 km de Jo,
je ne connais pas Bill,
je vais coder et je verrai bien... »

12. Le forfait « agile » Jo – Scrum Master
« Je lance le projet avec
25 exigences,
Bill – Product Owner Je communique avec Bill
« On lance le projet avec nos 25 pour faire évoluer cette liste
plus importantes exigences » Je me mets d'accord avec
Mike pour faire des sprints
efficaces et ne pas
les perturber »
Mike et ses copains
« Je travaille sur les taches qui m'intéressent a partir du chiffrage fait avec Jo
On démontre a Bill toutes les 3 semaines un soft qui marche
On l'adapte a l'issue du sprint selon le retour de Bill »

13. Concilier agilité et forfait

Pas une recette miracle, mais des pistes a explorer :

Engagement des équipes :
 Responsabilisation des développeurs
 motivation portée par les sprints

Partage du chiffrage et du risque
 Transparence
 Répondre aux changements dans
le respect des charges

Priorisation des exigences

Engagement sur des sprints courts et consistants

Mise en avant des avantages pour le client
 Flexibilité et acceptation des demandes de changement
 Tester tôt = recetter moins

Ne pas forcément appliquer Scrum a la lettre :

Le ScumMaster doit rester centré sur le management de l'équipe de réalisation

Ne pas hésiter a prendre la casquette de « Product Owner » si les décisions tardent

Gérer le calcul de vélocité de l'équipe pour les sprints a venir

14. Pistes de contractualisation forfaitaires
Modalités Avantages Contraintes Use Case
Forfait normal Périmetre fixe Habitude Cdc/specs 100% Refonte
Délai fixe Légitimité Pas de applicative
Budget fixe changement
Forfait par Périmetre évolutif Flexibilité Implication PO Marché privé
itérations Délai fixe Contrôle Contrat toutes les Régie ++
(3 mini) Budget évolutif 3 itérations
Forfait agile Périmetre évolutif Le changement Respect des Marché public
« Change for Délai fixe se fait par charges
free » remplacement
Budget fixe
Régie bonus / Périmetre évolutif Focus Respecter Scrum Productivité
malus Délai évolutif Prédictibilité Bonus / malus d'une équipe
Budget évolutif Suivi quotidien pour tout le monde régie
Engagement Périmetre a deux Engagement de Respecter Proof of concept
sur périmètre niveaux best effort sur périmetre
minimum Délai fixe périmetre minimum
Budget fixe complet

15. Case studies Scrum et forfait

Cadre peu propice a l'approche

Client demandeur d'une telle approche

Client déja préparé a la méthode Scrum

Proof of concept a fort risque

16. Plate-forme Internet eco - multi-sites (1/2)

Informations projet

Client public
 Dialogue compétitif suivi de la publication d'un CCTP
 Communication avant projet tres formalisée
 Equipe MOA en frontal des utilisateurs finaux

Non formé au méthodologies agiles

Constituée de plusieurs personnes pouvant porter la décision
 Contexte « tres politique »

Coût / Délai / Contenu
 Charge importante : environ 600 j.h
 Délai tres serré : moins de 6 mois
 Périmetre fonctionnel peu clair
 Incertitude technique forte (intégration avec un SI en construction)

17. Plate-forme Internet eco - multi-sites (2/2)

Utilisation d'une approche agile orientée Scrum

Définition « dirigiste » d'un product
backlog

Gestion d’un sprint 0 de 6 semaines
et de 6 sprints de 2 a 3 semaines

Lots de travaux visibles

Mise en place d'un outillage de
support méthode

Retour d'expérience

Les difficultés
 Difficulté a identifier un Product Owner
 Décision tardant a être prise

Les avantages
 Visibilité progressive de la solution
 Motivation continue de l'équipe
 Adaptation aux retards des
systemes tiers connectés

18. Galaxie de sites Internet européens (1/2)

Informations projet

Client européen
 Migration technologique
 Coldfusion => Liferay
 Réorganisation des équipes
 Fin du 1 projet = 1 développeur

Plateformes Internet
 15+ sites vitrines (petits projets)
 5 plateformes collaboratives (gros
projets)

Besoin initial
 Formations techniques
 Coaching technique
 Delivery de préférence au forfait

19. Galaxie de sites Internet Européens (2/2)

Formation Product Owner

Réorganisation avec mise en place PMO qui arbitre

Véritable backlog multi-projets partagé

Centre de service de développement multi-projets alimenté par
capacité (régie ou forfait)
Responsables de site Product owner
PMO
Equipe
Développeurs (dont ScrumMaster)

20. Projet d'application métier innovante (1/2)
 Informations projet
 Client privé
 Grosse entreprise du CAC40
 Précédente expérience de forfait Scrum
 Applicatif tres innovant
 Gros travail de spécifications préalables
 Wireframes applicatifs
 Spécifications fonctionnelles
 Évolutivité et adaptabilité de la solution
fortement recherchée
 En terme de fonctionnel
 En terme d'ergonomie
 Charge initiale de 250 j.h
 Délai de réalisation sur 16 semaines

21. Projet d'application métier innovante (2/2)

Utilisation de l'outillage Trac / Agilo

Publication du product backlog et du sprint backlog

Découpage des tâches et estimation partagée
de leur charge

Priorisation systématique des Users Stories

Planification initiale sur :

1 sprint 0 de 2 semaines
 Architecture, spécifications, mise en place environnements

6 sprints de 2 semaines en réalisation

1 release sprint de 3 semaines pour la recette avant production

Déroulement du projet avec acceptation des
demandes de changement

User stories supplémentaires

Travail de priorisation

Ajout concerté d'un sprint 7 de réalisation

Conclusion

Grande confiance réciproque

Disponibilité d'un vrai product owner

Equipe co-localisée et performante

22. Proof of concept bancaire (1/2)

Informations projet

Grande banque française
 Objectif de refonte sur technologie récente d'une offre existante

Proof of concept
 Utilisation d'un progiciel portail CMS éditeur
 Intégration applicative d'applications métier
 Fonctions Web 2.0 évoluées

Demande de cotation au forfait malgré :
 Une forte incertitude technique
 Une couverture fonctionnelle importante

Budget serré et délai tres court
 Objectif d'engagement du projet complet
 Durée : 4 semaines
 Charge : environ 50 j.h

23. Proof of concept bancaire (2/2)

Contractualisation avec un engagement

De résultat sur un périmetre minimum

De moyen sur le périmetre complet

Réalisation effectuée sur 4 sprints

Priorisation des users stories

Participation de toutes les parties prenantes aux scrum meetings

Finalisation du périmetre minimum des la fin du troisieme sprint

Ajouts fonctionnels selon demande sur sprint 4

Client extrêmement satisfait du résultat et du moyen de l’atteindre
Périmetre souhaité
Périmetre contractualisé
Périmetre réalisé

24. Retour d'expérience

Éligibilité d'un projet

Bonnes pratiques

Management de l'équipe

Outillage

Forces et faiblesses

25. Eligibilité d'un projet à Scrum
Taille équipe Petite Moyenne Grande
Délai projet Serré correct Détendu
Budget projet Serré correct Confortable
Périmètre contractuel Clair Peu clair Brumeux
Coopération client Forte Faible
Autonomie équipe Forte Faible

Critères essentiels :

Equipe projet de taille modeste (< 8 personnes)

Projet suffisamment long (au moins 10 semaines)

Critères facilitateurs :

Interaction forte possible avec le client (disponibilité, colocation, etc..)

Equipe de réalisation assez autonome (déja formée a Scrum, senior sur les technos
utilisés)

26. Particularités des sprints forfaitaires

Sprint 0 obligatoire :

Constitution, valorisation et priorisation du backlog

Mise en place de l'environnement de développement

Formation de l 'équipe a l'approche méthodologique et aux outils

Définition d'éléments d'architecture

Production de livrables contractuels

Sprint de réalisation :

Scrum meeting et auto-affectation des tâches

Tests unitaires et description des tests fonctionnels

Démonstration systématique en fin de sprint

Pas de mise en production

Sprint final de recette (« Release sprint »)

Finalisation des tests fonctionnels usine

Support a la recette cliente

27. Bonnes pratiques

Ne pas masquer « L'arrache » par « Agile »
http://www.risacher.com/
la-rache/

Éduquer, expliquer, démontrer

En début de projet : brieffing, REX, formation

En cours de projet : démos larges, outils accessibles a tous

Dire ce que je fais, faire ce que je dis

Ne pas être le premier a bypasser le stand-up

Ne jamais décaler une démo

Ne pas se tuer a vouloir « faire bouger les lignes »

Si management dit « non », ne pas essayer au niveau opérationnel

Si MOA dit « non » alors réduire scope a MOE

28. Management de l'équipe

Equipe au sens large
 Client (Product Owner) et Fournisseur (ScrumMaster)

Etablir une relation de confiance
 Assurer une transparence totale

Sur l'avancement

Sur le chiffrage des efforts
 Montrer un respect des engagements

Pas de décalage des rendez-vous

Démonstration de la qualité des livrables

Au sens de l'équipe de réalisation

Maintenir un rythme de production soutenu sans en abuser
 Prévoir un délai entre les sprints

Préparation des démonstrations

Estimation des tâches du sprint suivant
 Ne pas céder a la tentation de trop charger un sprint

Collégialité et honnêteté des estimations

Respect de la capacité maximale d'un sprint

29. Importance de l'outillage

Le besoin essentiel est de gérer

Le « product backlog »

Le « sprint backlog »

De donner une visibilité de l'avancement du projet

Les différents niveaux d'outillage

Les post-it
 Co-localisation obligatoire
 Attention aux courants d'air !

La matrice Excel
 Peu visible car au fond d'un répertoire de fichiers
 Circulation de la matrice a organiser

L'outil dédié. Les grands classiques :
 Jira + Greenhopper
 IceScrum
 Beaucoup d’autres !

30. Starter kit Scrum Ippon Technologies

Outillage d'un projet standard Outillage d'un projet Scrum

Gestionnaire de configuration Gestion du product backlog

Wiki de collaboration Planification des sprints

Gestion documentaire Gestion des sprints backlog

Tableau de bord de pilotage Décomposition et estimation des tâches

Gestionnaire de tests Burn down chart
Intégration continue et audit de code
 Ippon Technologies a mis en place une plate-forme spécifique orientée Scrum :
 SVN + Hudson + Sonar pour la gestion du code et son contrôle
 Plate-forme virtualisée pour l'intégration continue
 Plate-forme unifiée de suivi projet complete :
 Sur base du gestionnaire d'anomalie Trac spécifiquement paramétré (http://trac.edgewall.org/)
 Présence d'un Wiki simple et performant
 Structuration adaptée aux problématiques de GED
 Acces au SVN
 Intégration de la gestion des risques et des actions (PAQ)
 Plugin Agilo d'extension de trac (http://www.agile42.com/cms/pages/agilo/)
 Support des aspects propres a Scrum (User Stories, Sprints, etc..)

31. Forces, faiblesses et écueils de Scrum
Forces Faiblesses Ecueils
Relation avec le client
 Permet d'instaurer une relation  A t-on véritablement un Product  Retourner a un mode forfaitaire
de confiance et d'échange Owner côté Client ? standard des le premier
 Démonstration réguliere  Est-on réellement protégé symptôme de blocage
 Transparence sur l'avancement contractuellement pour accepter  Se retrouver dans une approche
 Donne la capacité de satisfaire le changement ? trop dirigiste du projet
au mieux les besoins  Prendre définitivement la
casquette de Product Owner...
Management de l'équipe de réalisation
 Réduction de l'inertie de  L'équipe est-elle prête a  Rendre chaque sprint comme un
démarrage d'un projet s'impliquer et a collaborer ? challenge pour l'équipe en les
 Maintien de la motivation de  Les développeurs sont-ils surchargeant
l'équipe a chaque sprint suffisamment polyvalents  Renoncer a gérer une ressource
 Démarche de responsabilisation (codage, tests, correction) ? non formée
Qualité générale du produit
 Démarche de tests et  Comment minimiser le surcoût  Ne pas négliger de gérer la
d'assemblage systématique lié aux tests et aux dette technique
 Recherche de la simplicité de démonstrations de fin de sprint ?  Bien gérer la communication
réalisation entre membres de l'équipe
 Visibilité anticipé du résultat  Ne pas omettre les outils
pour le client connexes (IC, Sonar, etc..)

32. Merci