Upload
agnescrepet
View
635
Download
1
Embed Size (px)
DESCRIPTION
Slides from our TogoJUG talk (Lomé - Togo) - 08/13/2011 - by agnes crepet & cyril lacoteAbout Agile Practices
Citation preview
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
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