Your SlideShare is downloading. ×
0
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Scrum et forfait
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum et forfait

2,921

Published on

Scrum et le forfait incompatibles ? Pas si sûr. Lors du Scrumday 2011, Bertrand Pinel, directeur technique d'Ippon a présenté les retours d'expérience de la société

Scrum et le forfait incompatibles ? Pas si sûr. Lors du Scrumday 2011, Bertrand Pinel, directeur technique d'Ippon a présenté les retours d'expérience de la société

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,921
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Les projets au forfaitScrum 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 dune maniere qui suggérerait quils 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 lautorisation du titulaire des droits sur cette œuvre. ✔ Rien dans ce contrat ne diminue ou ne restreint le droit moral de lauteur ou des auteurs.
  • 4. Ippon Technologies en bref 160 CA 8 000 (Keuros)CA 2010 : 9,1 ME Effectif 120Objectif 2011 : 10,5 ME 6 000115 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 dactivité dans la création de systemes informatique...  Dans lindustrie  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 sadapter 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 dun projet sinscrit 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 dun client  Le forfait : prise en charge de la réalisation dun périmetre fonctionnel Forfait : Cest 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 sengager 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 lagilité 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, cest la Bible de lIntranet » 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 jai pris les moins chers au forfait comme ça jaurai 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 daccord avec Mike pour faire des sprints efficaces et ne pas les perturber » Mike et ses copains « Je travaille sur les taches qui mintéressent a partir du chiffrage fait avec Jo On démontre a Bill toutes les 3 semaines un soft qui marche On ladapte a lissue 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 CaseForfait normal Périmetre fixe Habitude Cdc/specs 100% Refonte Délai fixe Légitimité Pas de applicative Budget fixe changementForfait 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érationsForfait agile Périmetre évolutif Le changement Respect des Marché public« Change for Délai fixe se fait par chargesfree » remplacement Budget fixeRégie bonus / Périmetre évolutif Focus Respecter Scrum Productivitémalus Délai évolutif Prédictibilité Bonus / malus dune équipe Budget évolutif Suivi quotidien pour tout le monde régieEngagement Périmetre a deux Engagement de Respecter Proof of conceptsur périmètre niveaux best effort sur périmetreminimum Délai fixe périmetre minimum Budget fixe complet
  • 15. Case studies Scrum et forfait  Cadre peu propice a lapproche Client demandeur dune 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 dun 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 dune approche agile orientée Scrum  Définition « dirigiste » dun 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 dun outillage de support méthode Retour dexpé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 dapplication 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 dergonomie  Charge initiale de 250 j.h  Délai de réalisation sur 16 semaines
  • 21. Projet dapplication métier innovante (2/2) Utilisation de loutillage 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é dun sprint 7 de réalisation Conclusion  Grande confiance réciproque  Disponibilité dun 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 dune offre existante  Proof of concept  Utilisation dun progiciel portail CMS éditeur  Intégration applicative dapplications 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 dengagement 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 dexpérience  Éligibilité dun projet  Bonnes pratiques Management de léquipe  Outillage  Forces et faiblesses
  • 25. Eligibilité dun projet à Scrum Taille équipe Petite Moyenne Grande Délai projet Serré correct Détendu Budget projet Serré correct ConfortablePé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 lenvironnement de développement  Formation de l équipe a lapproche méthodologique et aux outils  Définition déléments darchitecture  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 « Larrache » 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 lavancement  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 dun sprint
  • 29. Importance de loutillage Le besoin essentiel est de gérer  Le « product backlog »  Le « sprint backlog »  De donner une visibilité de lavancement du projet Les différents niveaux doutillage  Les post-it  Co-localisation obligatoire  Attention aux courants dair !  La matrice Excel  Peu visible car au fond dun répertoire de fichiers  Circulation de la matrice a organiser  Loutil dédié. Les grands classiques :  Jira + Greenhopper  IceScrum  Beaucoup d’autres !
  • 30. Starter kit Scrum Ippon Technologies Outillage dun projet standard Outillage dun 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 lintégration continue  Plate-forme unifiée de suivi projet complete :  Sur base du gestionnaire danomalie Trac spécifiquement paramétré (http://trac.edgewall.org/)  Présence dun 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 dextension 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 dinstaurer 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 lavancement 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 linertie de  Léquipe est-elle prête a  Rendre chaque sprint comme un démarrage dun projet simpliquer 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 dassemblage 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

×