Agnès CREPET @agnes_crepetCyril LACÔTE @clacote13 aout 2011 TogoJUG - Lomé

L'agilité

Sommaire de la session

Introduction aux méthodes agiles

Retour d’expérience des méthodes agiles

Une pratique de l’agilité : Test Driven Development

Les outils de l’agilité

Film d'interviews - retours d'expériences

Introduction aux méthodes agiles

Standish Group CHAOS report : 2003

Bilan des projets informatiques

Seulement 1/3 des projets informatique

Réalisés dans les temps

Et dans les coûts impartis...

Projet réalisédans les coûts

et les délais : 34%

Projet abandonné : 15%

Projet en dépassement : 51%Moyenne du dépassement : +43%

Méthodologies projet classiques

Spécification des besoins

Analyse

Réalisation

Test

Recette

Démarrage

EffetTunnel

Effet Big-Bang

Fonctions utilisées d'un logiciel

Près de la moitiédes fonctionnalités

ne sont jamais utilisées !

Près de la moitiédes fonctionnalités

ne sont jamais utilisées !

% ch

an

ge

me

nt d

es

exig

en

ces

Taille du projet en points de fonctions

Evolution du besoin

Le besoin d'un logicield'entreprise évolue

jusqu'à 50%

Le besoin d'un logicield'entreprise évolue

jusqu'à 50%

L'inéluctable imperfection

Il devient nécessaire...

D'établir un dialogue avec l’utilisateur

Comprendre ce qu’il dit

Parler un langage qu’il comprend

L’impliquer dans la réussite du projet

Il devient nécessaire...

De s’appuyer sur des estimations fiables :

Un plan précis mais faux est non seulement inutile mais dangereux !

Une projection sur 3 semaines est fiable. Cette fiabilité décroit ensuite.

Compter les fonctions développées a plus de valeur qu’estimer un reste à faire

Il devient nécessaire...

D’optimiser le travail de l’équipe de développement

Faire ce qui est nécessaire et suffisant pour l’utilisateur

Minimiser les productions intermédiaires

Favoriser le partage des savoirs et des compétences

Le manifeste des méthodes agiles

Le manifeste des méthodes agiles

Août 2001, publication du manifeste des méthodes agiles

17 personnalités éminentes du développement :

• Ward Cunningham (Wiki)

• Kent Beck (eXtreme Programming)

• Ken Schwaber

• Jeff Sutherland (SCRUM)

• Alistair Cockburn

• Martin Fowler

Le manifeste des méthodes agiles

Les valeurs de l'agilité :

L’agilité se décline en 12 principes

« Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles »

« Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client »

L’agilité se décline en 12 principes

« Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte »

« Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet  »

L’agilité se décline en 12 principes

« Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail »

« La méthode la plus efficace pour transmettre l'information est une conversation en face à face »

L’agilité se décline en 12 principes

« Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet »

« Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment »

L’agilité se décline en 12 principes

« La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle »

« Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité »

L’agilité se décline en 12 principes

« Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent »

« À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens »

Emergence des méthodes agiles

Les nouvelles approches

Les solutions proposées sont :

Pilotées par le risque

itératives et incrémentales

Orienté Use-case

Orienté architecture

L’ approche n’est plus prédictive mais agile

Définition des méthodes dites agiles :

« Méthodes itératives à planification souple qui permettent l’adaptation aux changements de contexte et de spécifications d ’un projet »

Une pléthore de nouvelles approches

XP

Scrum

Kanban

Lean

…

Un retour d'expérience

… plutôt qu'un long discours méthodologique

DSI de 200 personnes, laboratoire pharmaceutique

Refonte du Système d’information (JEE, ESB, etc.)

10000 jours/homme

Intérêts de l’agilité pour ce projet :

introduire des demandes d’évolutions en cours de projet

faciliter l’acceptation des nouvelles solutions par les utilisateurs

Basé sur Scrum et Kanban

Contexte du projet

Scrum est un processus agile qui permet de produire la plus grande valeur métier dans la durée la plus courte

Du logiciel qui fonctionne est produit à chaque « sprint » (2 à 4 semaines) timebox

Le métier définit les priorités. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires

A chaque fin de sprint : release déployable et testable par les utilisateurs finaux

Deux rôles importants dans l’équipe Scrum:

Product Owner et Scrum Master

Scrum en 100 mots

Scrum

Product Owner Scrum Master

Définit les fonctionnalités du produit

Définit les priorités dans le backlog en fonction de la valeur « métier »

Ajuste les fonctionnalités et les priorités à chaque itération si nécessaire

Teste les releases

Accepte ou rejette les résultats

Vulgarise les valeurs et les pratiques de Scrum

Contribue à améliorer les outils et les pratiques de l’ingénierie

Facilite une coopération poussée entre tous les rôles et fonctions

Protège l'équipe des interférences extérieures

Met l’accent sur la créativité et la gestion autonome des membres

Processus itératif

Des itérations d’un mois

Mais cela peut varier en fonction des phase du projet

Scrum : sprint durée fixe

Kanban

Des recettes utilisateurs à chaque fin d’itération

En période pré-production : recette toutes les 2 / 3 semaines

Recette Utilisateur - janvier 2010

AnnulerEmballage

Retour

Itération1 mois

Retour

But de l’itération

Liste destâches Produit partiel

livrable et testable

Backlogde produit

CouponsEmballage

Coupons

Annuler

24 heures

Une itération?

Backlog de produit

Backlog de produit

Backlog de produit

Backlog de produit = les exigences

En XP : User stories

Une entrée du backlog de produit est un Use Case UML (inspiré d’UP)

Un use Case déroulé sur 1 ou 2 itérations

Scrum Kanban

Priorités revues à chaque itération

Définies par le Product Owner

Mais également par le reste de l’équipe (différent de Scrum)

Un backlog de produit

Chaque UC, deux attributs :

Une estimation en points arbitraires

• Pas encore de jours

Une priorité (métier, risque technique identifié?)

UC Points

Priorité

Monitorer les lignes de préparation 10 5

Consulter une ligne de préparation 5 4

Lancer des fabrications 5 1

Pré-affecter la traçabilité 15 1

Editer les documents de fabrication 20 1

La liste peut évoluer au cours du projet

Suite au recette utilisateur en fin d’itération

Planification d’une itération

Périmètre • Séances de planification itératives• Analyser et évaluer le backlog de

produit• Définir le but de l’itération

Plan

• Décider comment s'y prendre (conception)

• Créer la liste des tâches à partir des éléments du backlog de produit

• Estimer les tâches

But de l’itérationBut de

l’itération

Liste des tâches

dans JIRA

Liste des tâches

dans JIRA

Conditionsmétier

Conditionsmétier

Capacitéde

l'équipe

Capacitéde

l'équipe

Backlogde

produit

Backlogde

produit

Complexité Technos

Complexité Technos

Produitactuel

Produitactuel

Planification d'une itération

Traçabilité pour

toute création ou

modification de

lots

Traçabilité pour

toute création ou

modification de

lots

Coder la couche de persistance (1 jour)Ecrire les test fixtures (0,5 jour)Coder la classe Ligne de Prep. (0,75 jour)Maj les tests de perf. (0,5 jour)

Planification Itérative en continue

Sa disponibilité réelle pour l’itération à venir

Chaque membre 80% opérationnel sur des entrées du backlog

20% restant : stand-up, refactoring, etc...

La liste des tâches est créée collectivement

Pas seulement par le ScrumMaster

Expérimentation : peer-chiffrage

La conception de haut niveau est abordée

Burndown Chart Scrum

Vie du backlog de l’itération

L'estimation du reste à faire est ajustée tous les jours

Stand-up / JIRA

Mise à jour du travail restant quand il est mieux connu

N'importe qui peut ajouter, supprimer ou changer la liste des tâches en stand-up

Si un travail n'est pas clair

Définir une tâche avec plus de temps et la décomposer après

TDDTest Driven Development

Développement piloté par les tests

On écrit les tests AVANT le code

Déroulement :

Ecriture du test

Vérification de l'échec du test

puisque le code n'existe pas encore

Ecriture du code

Vérification du test

Refactoring

amélioration en gardant les mêmes fonctionnalités : javadoc, commentaires…

Développement piloté par les tests

Codage du testCodage du test

CompilationCompilation

Correction des erreurs de compilation

Correction des erreurs de compilation

Lancement du testéchec

Lancement du testéchecEcriture du codeEcriture du code

Lancement du testJusqu’à ce qu’il passe

Lancement du testJusqu’à ce qu’il passe

RefactorRefactor

Intérêt du TDD

Précisent les spécifications

Les tests peuvent même être la documentation

Force à réfléchir très tôt aux jeux de test

Force à designer du code testable

Souvent plus simple, aux dépendances isolées

L'injection de dépendance y pousse naturellement

Permet d'arrêter le travail au bon moment

Quand les tests passent

Sans travail inutile

L’outillage

L'outillage de l'agilité

Sommaire

Introduction

Principes agiles impactant l’outillage

Outils collaboratifs

Gestion de sources

Bug Tracker

Pour les développeurs

Construction avec Maven

Tests avec des Mock Objects

Outils d’analyse de code

Intégration continue

Conclusion

Pratiques agiles impactant l’outillage

Pratiques UP

Gérer les exigences

Modéliser graphiquement

Vérifier continuellement la qualité

Pratiques XP

TDD

Intégration continue

Refactoring

Convention de codage

L'usine logicielle agile

Plateforme collaborative

Gestion de projetGestion de sourcesGestion de tickets

Plateforme de tests

Tests de performancesValidation, recettes

Plateforme d'intégration

Intégration continueTests

Métriques

Postes développeur

IDETests unitaires

Modélisation UMLGestion des exigences

Outils collaboratifs : gestion de sources

Gestion de sources (SCM)

Référentiel commun

Gestion de l’historique

• Pour la traçabilité

• Et le retour arrière

Commentaires de commit

Etiquetage de versions

Branches pour des développements en parallèle

Qu’on peut fusionner

SVN, GIT

Gestion de sources : bonnes pratiques

Tu te synchroniseras plusieurs fois par jour

Tu commiteras une fonctionnalité entière

Tu auras vérifié qu’elle fonctionne

Tu feras un commentaire de commit explicite

Tu feras même référence au n° de ticket/tâche/bug

Outils collaboratifs : Bug Tracker

Mais aussi :

Suivi de projet

Gestion des versions

Suivi des imputations

Et du reste-à-faire

Moteur de recherche

Et intégration SCM

Quelques références :

JIRA, BugZilla, Trac, …

Outils collaboratifs : Bug Tracker

Objectif :

Tracer la vie de l’application

Comment :

Recueillir bugs, évolutions, tâches

Qualifier (criticité, commentaire, capture d’écran, fichier attaché, lien entre tâches, doublons)

Affecter à un responsable

Suivre dans un workflow

Notifier par mail

Bug Tracker : bonnes pratiques

Génial, y’a une StackTrace !

Et les logs correspondants !

Et même un scénario pour reproduire le problème !

Tu essayeras d’estimer le reste à faire

La collaboration... mondiale !

Social Coding

Cloud computing

SCM et BugTracker

Collaborer en OpenSource

Contributeurs du monde entier

→ GitHub, BitBucket

Après l’exécution, même le DEV va dans le cloud

Cloudbees, CloudIDE, ...

L’outillage des développeurs : IDE

Les développeurs…

… voudraient automatiser les tâches répétitives

Parce qu’ils sont fainéants veulent être productifs

• Pour générer du code

• Pour faire du refactoring

• Pour documenter

→ IDE

Eclipse, NetBeans, IntelliJ : ils sont tous classes!

Pour les développeurs : construction

Les développeurs…

…souhaiteraient automatiser la génération des livrables

• Pour installer rapidement un poste de développement

• Pour utiliser une nouvelle librairie super classe

• Pour déployer 27 fois par jour…

• …sur des environnements différents…

• …sans galérer

→ Outil de construction (Maven, Gradle)

Construction : Maven

Maven formalise l’intégration du projet

En décrivant le QUOI plutôt que le COMMENT (Ant, anyone?)

Sur toutes ses étapes :

• De l’extraction des sources

• Jusqu’au déploiement sur les plateformes cibles

En centralisant toutes les données du projet :

• Version, Repository des sources, Dépendances

• Rapports qualités, Acteurs

Et en encourageant de bonnes pratiques :

• Normalisation de la structure

• Versioning

• Exécution des tests automatisés

Construction : Maven

Des avantages, plein :

Homogénéise l’intégration

Gestion des dépendances

• Téléchargement automatique des librairies

• Depuis un référentiel public, ou privé (Archiva, Nexus, ...)

Extensible par des plugins de construction

• Gérés par Maven, donc disponibles automatiquement

Gestion automatisée des versions

• Incrément, Tag, Branche de maintenance

Intégration continue facilitée

Tests

Les développeurs…

… rêveraient d’avoir toute confiance dans leur commit

• Répondre au besoin, y compris sur ses cas limites

• Sans introduire de régression

→ Tests unitaires et d’intégration

Inutile d’en rappeler les bénéfices, non ?

Passons à l’exemple…

Démo disponible sur GitHub :

https://github.com/Fluor/TogoJUG

Démo : tests avec mock-objects

A TESTER

SANS IMPLÉMENTATION !

Outils de mesure de la qualité du code

Les développeurs...

Contrôleraient leur code en permanence

Pour qu’il soit maintenable, évolutif, documenté…

Grâce à des outils d’analyse automatisés

Permettant de produire rapidement du code de qualité

→ Plugins

Outils de vérification du code

Pour un code…

Standard

• CheckStyle : vérification des conventions de codage

Sans bugs courants

• FindBugs : recherche de bugs courants

• PMD : recherche de bugs, de code mort

Testé

• Surefire Report : rapports d'exécution de tests unitaires

• Cobertura : rapports de couverture de tests

Simple et maintenable

• JDepend : indicateurs sur le niveau de couplage

• PMD CPD : recherche de code dupliqué

• JavaNCSS : complexité cyclomatique

Intégration continue

Les développeurs…

… devraient détecter au plus tôt les régressions

• Etre notifié quand elles arrivent

• Pour les corriger quand elles sont fraiches

• Et avant qu’elles ne s’empilent

• Pour être toujours prêt à livrer l’application

→ Intégration continue (Hudson, Jenkins)

Intégration continue

Gestion de tâches programmées

Intégration

Avec l'outil de gestion des sources

Avec l'outil de construction

Avec l'annuaire projet

Avec des outils d’analyse de la qualité

Donc trivial avec un projet Maven !

Remontée d'alertes

Pour détecter les problèmes au plus tôt

Et les corriger au plus vite

Consultation des rapports

Conclusion

Il ne faut pas sur interpréter le principe agile : « Parier sur les hommes plutôt que le processus ou l’outillage »

« Plutôt » ne signifie pas que l’outillage est accessoire

Et vulgariser, former…

Les personnes de l’équipe doivent s’approprier la méthode

Mieux que de l’imposer!

Appliquer les pratiques agiles qui semblent « pragmatiques » et adaptées à votre contexte

« Ne pas développer de dépendance spécifique à une arme ou à une école de combat »

Miyamoto Musachi, Samouraï du XVIIième siècle

Lectures…

Ken Schwaber

ADM

Scrum présenté à OOPSLA 96 avec Sutherland

Auteur des 3 livres sur Scrum

Agile and Iterative Development: A Manager’s Guide de Craig Larman

Agile Estimating and Planning de Mike Cohn

Agile Retrospectives d'Esther Derby et Diana Larsen

Agile Software Development Ecosystems de Jim Highsmith

User Stories Applied for Agile Software Development de Mike Cohn

Des articles toutes les semaines à www.scrumalliance.org

Où se renseigner ?

www.mountaingoatsoftware.com/scrum

www.scrumalliance.org

www.controlchaos.com

scrumdevelopment@yahoogroups.com

En français :

le groupe des utilisateurs de Scrum : www.frenchsug.org

http://fr.groups.yahoo.com/group/frenchsug

Scrum vs Kanban:

http://www.fabrice-aimetti.fr/dotclear/public/mes-documents/Kanban-vs-Scrum-French.pdf

Sources

Traduction de Claude Aubrywww.aubryconseil.com

Traduction de Claude Aubrywww.aubryconseil.com

Certains Slides sont issus d’une présentation de Mike Cohn sous license libre

www.mountaingoatsoftware.com

Certains Slides sont issus d’une présentation de Mike Cohn sous license libre

www.mountaingoatsoftware.com