18
Avoir des projets qui correspondent à leur client MÉTHODES AGILES & SCRUM Olivier Conq Juillet 2011 V1.0

Méthodes Agiles & SCRUM

  • Upload
    beck

  • View
    31

  • Download
    0

Embed Size (px)

DESCRIPTION

Méthodes Agiles & SCRUM. Avoir des projets qui correspondent à leur client. Olivier Conq Juillet 2011 V1.0. L’état des lieux des projets informatiques. Etat des lieux. L’état des projets. Statistiques. Les causes de l’échec. - PowerPoint PPT Presentation

Citation preview

Page 1: Méthodes Agiles & SCRUM

Avoir des projets qui correspondent à leur client

MÉTHODES AGILES & SCRUM

Olivier ConqJuillet 2011

V1.0

Page 2: Méthodes Agiles & SCRUM

ETAT DES LIEUXL’état des lieux des projets informatiques

Page 3: Méthodes Agiles & SCRUM

• Rivalité: le projet est une pratique qui permet au manager de s’affirmer. Par conséquent il devient un terrain de conflit: politique, financier, personnel. Cela vaut pour les acteurs internes et externe

• Logique de résultat: dans la plupart des réalisation, on cherche à savoir avant tout ce que doit être le produit à la fin. C’est une contradiction avec le business qui nécessite une forte adaptabilité sur un marché toujours plus rapide

• Outillage: l’outillage masque aujourd’hui la dimension humaine du management. Or seule une bonne équipe est en mesure de fournir un travail de qualité

• Qualité: du fait de la logique du résultat et de la dérive qu’accumulent les projets, la qualité est finalement sacrifié au profit de la date de livraison.

• 31% des projets ne sont jamais terminés

• 52% des projets ont un coût qui avoisinera les 200% du budget

• Le délais de réalisation d’un projet est en moyenne de 2,3x celui initialement prévu

• 94% des projets sont relancés dû à un échec

Source: Etude Standish Group

L’ÉTAT DES PROJETS

Statistiques Les causes de l’échec

Page 4: Méthodes Agiles & SCRUM

• Sur les 15 dernières années, les proportions n’ont que peu variées

• La majorité des projets est en difficulté

• Seul le quart des projets est considéré comme réussi

L’ÉVOLUTION DANS LE TEMPS

Page 5: Méthodes Agiles & SCRUM

CHANGER LES MENTALITÉSCHANGER LES PROJETSLa conviction est projets AGILE est qu’il faut commencer par changer les mentalités et l’approche des projets:

• Ne pas imposer au client une définition complète du projet avant le démarrage, permettre les changements le plus fréquent possible

• Délivrer le plus vite et régulièrement possible un produit fini et utilisable afin que le client puisse l’utiliser et l’adapter au besoin du business le plus souvent possible

• Constituer une équipe avec le client afin que tout le monde soit dans le même bateau et ainsi limité les guerres d’égos

• Définir des indicateurs de mesure simples et pragmatiques

• Adopter une politique de tests immédiatement, voir diriger les développements par les tests

Page 6: Méthodes Agiles & SCRUM

• Planning réalisé au dernier moment, juste à temps pour s’adapter aux changements Business

• Le backlog n’est précis que sur les premières stories: démarrage rapide

• Le changement est encouragé et peut intervenir jusqu’à la veille des sprints

• Pilotage très pragmatique. Seul le Product Owner est nécessaire

• Approche pragmatique

• Etablir un planning prévisionnel à l’avance: on veut savoir ce que l’on va faire sur les x prochains mois

• Travail conséquent pour établir l’ensemble du besoin et le planning

• Tout changement doit impacter le plan projet

• Nécessite une importante équipe de pilotage (établir les documents, le suivis, garder l’historique, etc.)

• Travail théorique de grande ampleur

LES FAMILLES MÉTHODOLOGIQUES

Cycle en V, CMMI, etc. Agile

Page 7: Méthodes Agiles & SCRUM

LA RÉPONSE DES MÉTHODES AGILELes méthodes Agile permettent de répondre à une grande partie de ces changements. Le Manifest Agile donne quatre valeurs fondamentales:

• Les interactions entre individus plutôt que les process et les outils• Travail en groupe

• Responsabilisation de tous les acteurs

• Des logiciels opérationnels plutôt qu’une documentation exhaustive• Privilégier la qualité du produit par rapport à des documents exhaustifs: privilégier le client

• Documentation permanente du code

• Avoir une politique de test complète

• La collaboration avec les clients plus que la négociation contractuelle• Associer le client à l’équipe de développement

• Feedback régulier du client

• Relation de confiance

• L’adaptation au changement plus que le suivi d’un plan• Considérer le changement comme une opportunité, ne pas en avoir peur

• Plus une modification est prise tôt moins elle est coûteuse

Page 8: Méthodes Agiles & SCRUM

LES MÉTHODES AGILESPlusieurs méthodes Agile sont apparues:

• 1950, Kanban: modèle utilisé dans l’industrie et créé par Toyota, il s’agit d’une méthode à flux tirée. Basé sur un workflow dans lesquels des éléments rentrent et sortent en temps réels.

• 1988, Spiral Model: un des premiers modèles de développement itératif montrant notamment l’aspect primordiale de cette approche

• 1991, Rapid Application Developpement (RAD): modèle adaptatif de développement basé sur la validation permanente des utilisateurs

• 1991, Scrum: première présentation de cette méthodologie basé sur l’esprit d’équipe, le client au cœur des développements, la communication, la simplicité, la flexibilité.

• 1999, eXtreme Programming (XP): méthode basé sur la communication honnête et régulière, le feedback rapide du client et la simplicité

Page 9: Méthodes Agiles & SCRUM

LA CONSTRUCTION ITÉRATIVE• La construction en mode itératif est un des pilliers des méthodes Agile

• On commence par attaquer tous les bouts du projet en même temps

• On livre un produit fonctionnel, très incomplet, dans un délais très court

• On repasse tous les morceaux du produit à chaque itération pour préciser l’ensemble jusqu’à la fin

• Cela implique un backlog construit de la sorteet qui n’est pas fabriqué sur une idéologietechnique

• Il y a une repasse permanente sur l’ensembledu code ce qui permet de tout adapter très vite

Page 10: Méthodes Agiles & SCRUM

LES ERREURS, LES RACCOURCIS• « Agile est une méthodologie sans documentation»

• FAUX: Agile ne recommande pas de ne pas faire de documentation mais va préférer faire une produit fonctionnel plutôt qu’un produit de mauvaise qualité avec beaucoup de documentation

• Ce point existe en revanche sur les projets gérés en « Cycle en V » car sous la pression des délais, la documentation est abandonnée

• « Agile n’est adapté qu’à de petits projets »• FAUX: Agile fonctionne sur des projets de grande taille. Quelques ajouts existent pour ces cas comme

Scrum de scrum par exemple

Page 11: Méthodes Agiles & SCRUM

SCRUMPrésentation de la méthode

Page 12: Méthodes Agiles & SCRUM

ScrumScrum est un ensemble d’outils applicables à un projet et permettant de suivre les principes énoncés précédemment

Quelques principes sont fondateurs dans Scrum:

• Le travail est itératif

• Les cycles sont limités dans le temps (2-4 semaines)

• L’équipe est constitué du développement ET du client

• Le travail est revu tous les jours

Page 13: Méthodes Agiles & SCRUM

LES RÔLES DANS SCRUM• Le Scrum Master

• Il s’assure que les principes et les valeurs de Scrum sont appliqués

• Il facilite la communication au sein de l’équipe

• Il cherche a améliorer la productivité et le savoir faire de l’équipe, il a un rôle de « facilitateur »

• L’équipe

• Toute personne réalisant des tâches: testeur, développeur, architecte, etc.

• 4/10 personnes le plus souvent

• Le Product Owner

• Définit la liste des fonctionnalités de manière itérative

• Priorise les besoins selon leur valeur business

• Valide les livrables fournit par l’équipe

• Représente le client, est le point d’entrée unique de l’équipe

Page 14: Méthodes Agiles & SCRUM

LES ARTEFACTSScrum utilise quelques termes spécifiques à la méthode:

• User Story: il s’agit de la description d’une fonctionnalité dans le langage du client et sous la forme d’un cas d’utilisation

• Product backlog: il s’agit de la liste des user stories du produit dans son ensemble (plus ou moins détaillées)

• Sprint: désigne une itération. Un sprint a une durée fixée, il démarre par un « sprint planning » et se termine par une démo de l’équipe au client montrant ce qui a été livré

• Sprint Backlog: la liste des user stories qui seront réalisées durant un sprint. C’est un sous-ensemble du product backlog

• Vélocité: la vitesse relative de réalisation des user stories par l’équipe

• Burn Down Chart: la quantité de travail restant à faire sur le sprint en cours. Ce graphique est mis à jour quotidiennement

Page 15: Méthodes Agiles & SCRUM

LES CÉRÉMONIES• Sprint planning: la première réunion d’un sprint où l’équipe définit la liste des User Stories

qui vont être réalisées. Chaque story est alors découpée en tâche plus fines chiffrées en heures.

• Scrum meeting: réunion quotidienne de toute l’équipe (y compris le Product Owner) où chacun exprime ce qu’il a fait la veille, ce qu’il va faire dans la journée et les problèmes qu’il rencontre

• Sprint review / démo: l’équipe montre au Product Owner ce qui a été livré. Le PO valide alors les livraisons et fait mouvemente le backlog en fonction. Des stories peuvent être revues et remises dans le backlog, les priorités peuvent changer, etc.

• Rétrospective: un réunion de fin de sprint où l’équipe discute de ce qui fonctionne ou ne fonctionne pas. Il s’agit d’un processus d’amélioration continuer permettant à l’équipe de faire évoluer sa façon de travailler pour en améliorer la productivité.

• [Optionnel] Planning Poker: permet de quantifier la taille des user stories dans le product backlog. Cette réunion est organisée autour d’un jeux de poker permettant d’attribuer des points aux stories

Page 16: Méthodes Agiles & SCRUM

COMMENT DÉMARRER EN AGILE?Retours d’expériences et prérequis

Page 17: Méthodes Agiles & SCRUM

BIEN DÉMARRER UN PROJET EN AGILE• Une méthode Agile par définition n’impose rien, elle est complètement adaptable à la

politique de l’entreprise, aux personnes

• Cependant, il existe certains prérequis qui permettent d’améliorer sensiblement les chances de succès:

• Avoir un et un seul Product Owner qui porte et qui a une vision claire sur le produit

• Avoir un backlog itératif et priorisé selon le business

• Avoir un Scrum Master avec de l’expérience sur la méthodologie

Page 18: Méthodes Agiles & SCRUM