Le document présente une introduction aux méthodes agiles, soulignant l'importance de l'adaptation aux changements de besoins dans les projets informatiques et les principes fondamentaux des approches telles que Scrum et Kanban. Il met également en avant le développement piloté par les tests (TDD) et l'utilisation d'outils collaboratifs pour optimiser le travail d'équipe et améliorer la qualité des logiciels. Enfin, il insiste sur la nécessité d'une communication efficace et d'une auto-organisation au sein des équipes de développement.

1. L'agilité Agnès CREPET @agnes_crepet Cyril LACÔTE @clacote 13 aout 2011 TogoJUG - Lomé

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

3. Introduction aux méthodes agiles

4. Bilan des projets informatiques Seulement 1/3 des projets informatique Réalisés dans les temps Et dans les coûts impartis... Standish Group CHAOS report : 2003 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%

5. Méthodologies projet classiques Spécification des besoins Analyse Réalisation Test Recette Démarrage Effet Tunnel Effet Big-Bang

6. Fonctions utilisées d'un logiciel Près de la moitié des fonctionnalités ne sont jamais utilisées !

7. Evolution du besoin Le besoin d'un logiciel d'entreprise évolue jusqu'à 50% % changement des exigences Taille du projet en points de fonctions

8. L'inéluctable imperfection

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

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

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

12. Le manifeste des méthodes agiles

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

14. Le manifeste des méthodes agiles Les valeurs de l'agilité :

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

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

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

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

19. 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é »

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

21. Emergence des méthodes agiles

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

23. Une pléthore de nouvelles approches XP Scrum Kanban Lean …

24. Un retour d'expérience … plutôt qu'un long discours méthodologique

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

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

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

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

29. Une itération ? Backlog de produit Annuler Emballage Retour Itération 1 mois Retour But de l’itération Liste des tâches Produit partiel livrable et testable Coupons Emballage Coupons Annuler 24 heures

30. 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) Backlog de produit

31. Un backlog de produit Chaque UC, deux attributs : Une estimation en points arbitraires Pas encore de jours Une priorité (métier, risque technique identifié?) La liste peut évoluer au cours du projet Suite au recette utilisateur en fin d’itération 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

32. Planification d'une itération Planification d’une itération Conditions métier Capacité de l'équipe Backlog de produit Complexité Technos Produit actuel 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ération Liste des tâches dans JIRA

33. 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 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) ‏

34. 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 Burndown Chart Scrum

35. TDD Test Driven Development

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

37. Développement piloté par les tests Codage du test Compilation Correction des erreurs de compilation Lancement du test échec Ecriture du code Lancement du test Jusqu’à ce qu’il passe Refactor

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

39. L’outillage L'outillage de l'agilité

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

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

42. L'usine logicielle agile Plateforme collaborative Gestion de projet Gestion de sources Gestion de tickets Plateforme de tests Tests de performances Validation, recettes Plateforme d'intégration Intégration continue Tests Métriques Postes développeur IDE Tests unitaires Modélisation UML Gestion des exigences

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

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

45. 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, …

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

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

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

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

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

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

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

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

54. Démo : tests avec mock-objects A TESTER SANS IMPLÉMENTATION !

55. Out ils 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

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

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

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

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

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

61. Où se renseigner ? www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com [email_address] 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

62. Sources Traduction de Claude Aubry www.aubryconseil.com Certains Slides sont issus d’une présentation de Mike Cohn sous license libre www.mountaingoatsoftware.com