Cette partie du cours est fortement inspirée par le MOOC Agile de Bertrand Meyer.

1. Le manifeste Agile

manifesto
Figure 1. Le manifeste Agile (http://agilemanifesto.org/)
il date de février 2001!

2. Les 17 auteurs

Les plus connus :

  • Ward Cunningham (Wiki)

  • Kent Beck (XP, JUnit)

  • Ken Schwaber et Jeff Sutherland (Scrum)

  • Alistair Cockburn

  • Martin Fowler

  • …​

3. Les 12 principes

12principles

Vous trouverez une version actualisée des principes sur Wikipedia :

  • fr https://fr.wikipedia.org/wiki/Manifeste_agile#Les_12_principes

  • https://en.wikipedia.org/wiki/Agile_software_development

    1. Customer satisfaction by early and continuous delivery of valuable software

    2. Welcome changing requirements, even in late development

    3. Working software is delivered frequently (weeks rather than months)

    4. Close, daily cooperation between business people and developers

    5. Projects are built around motivated individuals, who should be trusted

    6. Face-to-face conversation is the best form of communication (co-location)

    7. Working software is the principal measure of progress

    8. Sustainable development, able to maintain a constant pace

    9. Continuous attention to technical excellence and good design

    10. Simplicity—the art of maximizing the amount of work not done—is essential

    11. Best architectures, requirements, and designs emerge from self-organizing teams

    12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

4. Les valeurs agiles

Idées générales, qui précèdent aux principes.

Du manifesto lui-même :

  • Les individus et leurs interactions plus que les processus et les outils

  • Du logiciel qui fonctionne plus qu’une documentation exhaustive

  • La collaboration avec les clients plus que la négociation contractuelle

  • L’adaptation au changement plus que le suivi d’un plan

Ne pas oublier la petite phrase qui va avec :

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
— http://agilemanifesto.org/

Du MOOC Agile :

  • Nouveau rôle pour le manager (rôle réduit)

  • Pas d’étapes trop tôt ou trop importante (longues)

  • Développement itératifs (et donc continu)

  • Nouvelle façon de négocier (trade off)

  • Focus sur la qualité (et donc les tests)

5. Les principes

Plusieurs types :

  • Organisationnels / Managériaux

  • Techniques

5.1. Les bons principes NON AGILES!

  • Process, procédure et méthodes (critique ⇒ statique, imposée, ruptures entre phases)

  • Insister sur les exigences et leur qualités (critiques ⇒ ils évoluent, on ne les livrent pas, ils sont souvent des solutions plus que des besoins)

5.2. Les principes organisationnels

  • Le client au centre

  • Accepte le changement

  • Laisser l’équipe s’organiser

  • Maintenir un rythme durable

5.3. Les principes organisationnels (suite)

  • Produire du logiciel "minimaliste"

    • Les fonctionalités requises

    • et uniquement elles

    • ne développer que le code et les tests

YAGNI: You Ain’t Gonna Need It

5.4. Les principes techniques

  • Développer itérativement

  • Mettre en avant les tests (TDD)

    • Non regression

    • Test first (TDD)

  • Exprimer les exigences comme des scénarios

    • User stories

6. Les rôles

  • Product Owner

  • SCRUM Master

  • Team

Mais où est passé le chef de projet?!
Dans Scrum ⇒ pas de chef !

6.1. L’auto-organisation (dans l’équipe)

  • Spécialistes mais pas que

  • Transversalité : n’importe qui peut prendre n’importe quelle tâche

  • Sélection collective des objectifs pour l’itération

  • Affectation collective des tâches

  • Démonstration collective des résultats

6.2. Product Owner

  • Interface avec le client

  • Défini les caractéristiques du produit (features)

  • Priorise les features

  • Participe aux présentations du produit

6.3. Scrum master

  • S’assure que l’équipe applique correctement la méthode

  • S’assure que l’équipe est fonctionnelle

  • Facilite la coopération

  • Protège l’équipe

  • Aide à résoudre les problèmes et blocages

7. Les pratiques

  • Plannings

  • Meetings & Scrums

  • Retrospectives

  • TDD

7.1. Plannings

  • Planning poker

  • Scrum of Scrums

  • Storyboards

7.2. Meetings

  • Daily meetings

    • Matin généralement

    • "Stand-up" (<15')

    • Tout le monde participe

    • Engagements/Empêchements

  • Planning meetings

    • Sprint Backlog

  • Retrospective meeetings

    • Qu’est-ce qui a marché?

    • Qu’est-ce qui peut être amélioré?

  • Review meetings

    • On implique le client

7.3. Focus sur le Daily meeting

Les 3 questions classiques :

  • Qu’as-tu fait hier?

  • Que vas-tu faire aujourd’hui?

  • Vois-tu des obstacles à venir?

7.4. Développement

  • Pair programming

  • Mentor

  • Une seule base de code (vs. branching)

  • Code partagé

  • Garder l’optimisation pour la fin

  • Conception simple

  • Conception incrémentale

  • Refactoring

7.5. Release

  • Tôt et souvent

  • Continuous Integration

  • Petite, Incrémentale

  • Cycles hebdomadaires

7.6. Tests

  • Utiliser les standards

  • Systématiser les Tests Unitaires

  • TDD

8. Les artefacts

  • Product Backlog

  • User stories

  • Sprint Backlog

  • Burdown

8.1. Product Backlog

  • Propriété du Product Owner

  • Maintenu et "vivant" tout au long du projet

  • Ouvert

  • Contiens des backlog items

  • Inclue des estimations des business values

  • Inclue des estimations des efforts de développement

8.2. User stories

As a

…​

I want to

…​

So that

…​

Example of Story Card (source: https://mazoea.wordpress.com/agile/)

storycard

Bonne pratique (XP ⇒ INVEST):

  • Indépendante des autres histoires d’utilisateur (dans la mesure du possible)

  • Négociable (discutée avec l’équipe, notamment lors de l’estimation)

  • source de Valeur (porteuse d’une valeur client)

  • Estimable (elle peut être estimée par l’équipe)

  • (S)Courte (généralement une ou trois phrases environ)

  • D’une Taille appropriée (pouvoir être développée et testée au sein d’une itération)

Attributs :

  • Un numéro (Id)

  • Une importance/priorité client

  • Une estimation du coût (en points, temps, …​)

  • Une expression de la forme "En tant que …​ je souhaite …​ pour pouvoir …​

US
Figure 2. Exemple de carte pour User Story (http://www.agiliste.fr/guide-de-demarrage-scrum/)

Une activité populaire consiste à organiser les Stories sous forme d’une matrice et non d’une simple liste : c’est le Story Mapping.

Must, Should, Could, Wont ⇒ MoSCoW

storymap
Figure 3. Exemple de Story Map (http://www.agilegarden.fr/un-lancement-de-projet-ludique-et-productif/)

L’autre dimenstion de la matrice :

  • par flot (par dépendances entre stories)

mvp priorities
Figure 4. Exemple de Story Map par flot (http://blog.cayenneapps.com/2014/11/25/5-steps-to-building-minimum-viable-product-with-story-mapping/)

8.3. Storyboard

Example of storyboard (https://www.vikingcodeschool.com/software-engineering-basics/agile-development-with-xp-and-scrum)

agile story board

8.4. Vélocité

Attention, ce n’est pas une vitesse!

  • Number of items delivered

  • Burndown chart

8.5. Sprint Backlog

Juste un regroupement de User Stories, prisent dans le Product Backlog et traitées pour ce Sprint là.

8.6. Burndown

burndown inputs
Figure 5. Exemple d’inputs pour mon Burn-down (http://www.agiliste.fr/instruments-pilotage-projet/)
burndown
Figure 6. Exemple de Burn-down résultant (http://www.agiliste.fr/instruments-pilotage-projet/)
Pour tester vous-mêmes : https://docs.google.com/spreadsheets/d/17bppZL6IQoHXKHm0Cr5Q5yYrQivA9oTSB5fmo6ECsJs/edit#gid=6

9. Le déroulement

anime scrum overview blue
Figure 7. Déroulement type d’une approche agile (http://scrumprimer.org)

Quizz