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

L’évolution dans le temps 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

Changer les mentalités changer les projets La 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

Les familles méthodologiques Cycle en V, CMMI, etc. Agile 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 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

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

Les méthodes Agiles Plusieurs 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é

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 sorte et qui n’est pas fabriqué sur une idéologie technique Il y a une repasse permanente sur l’ensemble du code ce qui permet de tout adapter très vite

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

Présentation de la méthode Scrum

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

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

Les artefacts Scrum 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

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

Comment démarrer en Agile? Retours d’expériences et prérequis Comment démarrer en Agile?

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