Méthodes Agiles & SCRUM

1. Méthodes Agiles & SCRUM Avoir des projets qui correspondent à leur client Olivier Conq Juillet 2011 V1.0

2. L’état des lieux des projets informatiques Etat des lieux

3. L’état des projets Statistiques Les causes de l’échec • 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

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

5. Changer les mentalitéschanger 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

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

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

8. 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, eXtremeProgramming(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 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

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

11. Présentation de la méthode Scrum

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

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

14. 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 productbacklog • 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 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 productbacklog. Cette réunion est organisée autour d’un jeux de poker permettant d’attribuer des points aux stories

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

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