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

Preview:

DESCRIPTION

La méthodologie Scrum et son caractère profondément itératif conduisent souvent à éviter une mise en place pour les projets au forfait. Cette session se propose, au travers de 3 projets concrets portant sur des problématiques différentes (Intranet, portail web, application métier), de montrer les possibilités et les limites de Scrum en mode forfait :Comment trouver le Product Owner ?Comment gérer un périmètre projet contractuel ?Quels outillage utilisé ?Que faire de la vélocité ?...

Citation preview

Agile Tour Nantes 2011

Scrum but...Scrum but...But Scrum !But Scrum !

Les projets au forfaitLes projets au forfait

Copyright Cette présentation vous est fournie sous licence Creative Commons

Attribution Share Alike

Vous etes 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 etre 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.

Ippon Technologies en bref

Partenaires

CA 2010 : 9,1 ME

Objectif 2011 : 10,5 ME

115 Collaborateurs :

- Paris

- Nantes

- Bordeaux

Principaux Clients 2010Services Publics : DGA, RATP, SNCF, CCIP, Apec Banques : Crédit Immobilier, BNP Paribas, Crédit Mutuel, Société Générale, GMF, Pacifica, Coface

Telecoms / Internet : Orange Vallée, Globecast, PagesJaunes, Karavel Promovacances

Distribution : Fnac, Accor, Carrefour, Cora, LVMH, Chanel

Industrie : CEA, EDF, Thales, GDF Suez,

Services

- Conseil : Architecture, Performances, Audit, POC

- Assistance : Développement, Intégration, « Coaching »

- Forfaits : 50 à 1500 j.h, méthodes agiles SCRUM

- Centres de services : Agile ou UP / Prise en charge SLAs

- Formations : Inter & Intra, 120 cours spécialisés

2005 2006 2007 2008 2009 B2010

-

2 000

4 000

6 000

8 000

0

40

80

120

160

CA(Keuros)Effectif

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

Qui suis-je ?

Scrum et forfait Pourquoi Scrum peut-il s'adapter 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 d'un projet s'inscrit dans des contraintes :

De périmetre fonctionnel De délai De coût

Pour arriver au résultat, plusieurs voies sont possibles dont le mode forfait

Coût

Délai Périmetre

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 Résistance a s'engager

ClientSSII

ForfaitRégie

Partage du risque

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 l'agilité dans le forfait

Le manifeste agile : 2001 Individuals and interactions over

processes and tools Working software over

comprehensive documentation Customer collaboration over contract

negotiation Responding to change over following

a plan

Les méthodes agiles XP Scrum Crystal DSDM Lean

Bénéfices Validation permanente du produit Flexibilité Qualité du code Satisfaction du client Communication et motivation

permanente

Contraintes Acceptation du changement Collaboration étroite avec le client Priorisation des besoins Prise de décision opérationnelle et

rapide 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, 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 çaj'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... »

Le forfait « agile »

Bill – Product Owner« On lance le projet avec nos 25

plus importantes exigences »

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 »

Jo – Scrum Master« Je lance le projet avec

25 exigences,Je communique avec Bill

pour faire évoluer cette listeJe me mets d'accord avec Mike pour faire des sprints

efficaces et ne pas les perturber »

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 Case

Forfait normal Périmetre fixeDélai fixeBudget fixe

HabitudeLégitimité

Cdc/specs 100%Pas de changement

Refonte applicative

Forfait par itérations(3 mini)

Périmetre évolutifDélai fixeBudget évolutif

FlexibilitéContrôle

Implication POContrat toutes les 3 itérations

Marché privéRégie ++

Forfait agile« Change for free »

Périmetre évolutifDélai fixeBudget fixe

Le changement se fait par remplacement

Respect des charges

Marché public

Régie bonus / malus

Périmetre évolutifDélai évolutifBudget évolutif

FocusPrédictibilitéSuivi quotidien

Respecter ScrumBonus / malus pour tout le monde

Productivité d'une équipe régie

Engagement sur périmètre minimum

Périmetre a deux niveauxDélai fixeBudget fixe

Engagement de best effort sur périmetre complet

Respecter périmetre minimum

Proof of concept

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

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)

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 semaineset 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 etre 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

DéveloppeursEquipe

(dont ScrumMaster)

Product owner

PMO

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

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

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

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 extremement satisfait du résultat et du moyen de l’atteindre

Périmetre souhaité

Périmetre contractualisé

Périmetre réalisé

Retour d'expérience

Éligibilité d'un projet Bonnes pratiques

Management de l'équipe Outillage

Forces et faiblesses

Eligibilité d'un projet à Scrum

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)

Taille équipe Moyenne GrandePetite

Délai projet correct DétenduSerré

Budget projet correct ConfortableSerré

Périmètre contractuel Peu clair BrumeuxClair

Coopération client FaibleForte

Autonomie équipe FaibleForte

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

Bonnes pratiques

Ne pas masquer « L'arrache » par « Agile »

É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 etre 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

http://www.risacher.com/la-rache/

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 honneteté des estimations Respect de la capacité maximale d'un sprint

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 !

Starter kit Scrum Ippon Technologies Outillage d'un projet standard

Gestionnaire de configuration Wiki de collaboration Gestion documentaire Tableau de bord de pilotage Gestionnaire de tests

Outillage d'un projet ScrumGestion du product backlog

Planification des sprints

Gestion des sprints backlog

Décomposition et estimation des tâches

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

Forces, faiblesses et écueils de Scrum

Forces Faiblesses Ecueils

Relation avec le client

Permet d'instaurer une relation de confiance et d'échange Démonstration réguliere Transparence sur l'avancement

Donne la capacité de satisfaire au mieux les besoins

A t-on véritablement un Product Owner côté Client ?

Est-on réellement protégé contractuellement pour accepter le changement ?

Retourner a un mode forfaitaire standard des le premier symptôme de blocage

Se retrouver dans une approche trop dirigiste du projet Prendre définitivement la

casquette de Product Owner...

Management de l'équipe de réalisation

Réduction de l'inertie de démarrage d'un projet

Maintien de la motivation de l'équipe a chaque sprint

Démarche de responsabilisation

L'équipe est-elle prete a s'impliquer et a collaborer ?

Les développeurs sont-ils suffisamment polyvalents (codage, tests, correction) ?

Rendre chaque sprint comme un challenge pour l'équipe en les surchargeant

Renoncer a gérer une ressource non formée

Qualité générale du produit

Démarche de tests et d'assemblage systématique

Recherche de la simplicité de réalisation

Visibilité anticipé du résultat pour le client

Comment minimiser le surcoût lié aux tests et aux démonstrations de fin de sprint ?

Ne pas négliger de gérer la dette technique

Bien gérer la communication entre membres de l'équipe

Ne pas omettre les outils connexes (IC, Sonar, etc..)

Merci