Agile Tour Nantes 2011 - Bertrand pinel les projets au forfait - scrum but... but scrum

Les projets au forfaitScrum but... But Scrum ! Agile Tour Nantes 2011

Copyright Cette présentation vous est fournie sous licence Creative Commons Attribution Share Alike Vous ê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 ê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.

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

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

Scrum et forfait Pourquoi Scrum peut-il sadapter au mode forfait ? Comment peut-on adapter Scrum au mode forfait ?

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

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

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

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

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... »

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 »

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 ScrumMaster 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

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

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

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)

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 être prise  Les avantages  Visibilité progressive de la solution  Motivation continue de léquipe  Adaptation aux retards des systemes tiers connectés

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

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)

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

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

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

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 extrêmement satisfait du résultat et du moyen de l’atteindre Périmetre souhaité Périmetre contractualisé Périmetre réalisé

Retour dexpérience  Éligibilité dun projet  Bonnes pratiques Management de léquipe  Outillage  Forces et faiblesses

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)

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

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 ê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

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 honnêteté des estimations  Respect de la capacité maximale dun sprint

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 !

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..)

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 prê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..)

Agile Tour Nantes 2011 - Bertrand pinel les projets au forfait - scrum but... but scrum

by atnantes on Oct 14, 2011

Accessibility

Upload Details

Usage Rights

1 Embed 1,222

Statistics

Agile Tour Nantes 2011 - Bertrand pinel les projets au forfait - scrum but... but scrum — Presentation Transcript