La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Avoir des projets qui correspondent à leur client MÉTHODES AGILES & SCRUM Olivier Conq Juillet 2011 V1.0."— Transcription de la présentation:

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

2 ETAT DES LIEUX Létat des lieux des projets informatiques

3 Rivalité: le projet est une pratique qui permet au manager de saffirmer. 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. Cest une contradiction avec le business qui nécessite une forte adaptabilité sur un marché toujours plus rapide Outillage: loutillage masque aujourdhui 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 quaccumulent 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 dun 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 StatistiquesLes causes de léchec

4 Sur les 15 dernières années, les proportions nont 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

5 CHANGER LES MENTALITÉS CHANGER LES PROJETS La conviction est projets AGILE est quil faut commencer par changer les mentalités et lapproche 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 lutiliser et ladapter 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

6 Planning réalisé au dernier moment, juste à temps pour sadapter aux changements Business Le backlog nest 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 à lavance: on veut savoir ce que lon va faire sur les x prochains mois Travail conséquent pour établir lensemble 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 lhistorique, etc.) Travail théorique de grande ampleur LES FAMILLES MÉTHODOLOGIQUES Cycle en V, CMMI, etc.Agile

7 LA RÉPONSE DES MÉTHODES AGILE Les 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 quune 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 Ladaptation au changement plus que le suivi dun 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

8 LES MÉTHODES AGILES Plusieurs méthodes Agile sont apparues: 1950, Kanban : modèle utilisé dans lindustrie et créé par Toyota, il sagit dune 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 laspect 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 lesprit 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é

9 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 lensemble jusquà la fin Cela implique un backlog construit de la sorte et qui nest pas fabriqué sur une idéologie technique Il y a une repasse permanente sur lensemble du code ce qui permet de tout adapter très vite

10 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 quun 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 nest 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

11 SCRUM Présentation de la méthode

12 Scrum Scrum est un ensemble doutils 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

13 LES RÔLES DANS SCRUM Le Scrum Master Il sassure 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 dentrée unique de léquipe

14 LES ARTEFACTS Scrum utilise quelques termes spécifiques à la méthode: User Story : il sagit de la description dune fonctionnalité dans le langage du client et sous la forme dun cas dutilisation Product backlog : il sagit 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. Cest 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

15 LES CÉRÉMONIES Sprint planning : la première réunion dun 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 quil a fait la veille, ce quil va faire dans la journée et les problèmes quil 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 sagit dun processus damé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 dun jeux de poker permettant dattribuer des points aux stories

16 COMMENT DÉMARRER EN AGILE? Retours dexpériences et prérequis

17 BIEN DÉMARRER UN PROJET EN AGILE Une méthode Agile par définition nimpose rien, elle est complètement adaptable à la politique de lentreprise, aux personnes Cependant, il existe certains prérequis qui permettent damé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 lexpérience sur la méthodologie

18


Télécharger ppt "Avoir des projets qui correspondent à leur client MÉTHODES AGILES & SCRUM Olivier Conq Juillet 2011 V1.0."

Présentations similaires


Annonces Google