Agilite togo jug_final

997 views

Published on

Slides from our TogoJUG talk (Lomé - Togo) - 08/13/2011 - by agnes crepet & cyril lacote
About Agile Practices

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
997
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • effet tunnel   délai trop long entre l’expression des besoins et la mise en exploitation du système opérationnel.
  • « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles » C’est l’utilisateur qui décide ce qu’il faut faire Il faut l’impliquer tout au long de la réalisation « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client   » Le processus doit permettre une gestion continue des exigences
  • « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte » Il faut adopter un cycle itératif et incrémental « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet  » Les utilisateurs doivent être disponibles
  • « 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 » Il faut reconnaître le rôle du concepteur-développeur Il faut l’impliquer dans la réussite du projet « La méthode la plus efficace pour transmettre l'information est une conversation en face à face » Plutôt que de rédiger des documentations pénibles à écrire et à lire La documentation sert à capitaliser
  • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet » C’est d’autant plus fiable que l’estimation du reste à faire ne l’est pas! « Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment » Il faut éviter les coups de bourre en fin d’itération ou de projet C’est reconnaître que la fatigue finit par nuire au projet
  • « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle » YAGNI : You aren’t Gonna Need It ! KISS : Keep It Simple, Stupid DRY : Don’t repeat Yourself « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité » Les méthodes agiles visent à faire du logiciel de qualité Mobiliser du personnel compétent, former, soutenir
  • « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent » Donner beaucoup d’autonomie aux équipes Limiter l’impact des recommandations extérieures « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens » Le processus doit inclure des temps pour prendre du recul
  • Agilite togo jug_final

    1. 1. L'agilité Agnès CREPET @agnes_crepet Cyril LACÔTE @clacote 13 aout 2011 TogoJUG - Lomé
    2. 2. Sommaire de la session <ul><li>Introduction aux méthodes agiles </li></ul><ul><li>Retour d’expérience des méthodes agiles </li></ul><ul><li>Une pratique de l’agilité : Test Driven Development </li></ul><ul><li>Les outils de l’agilité </li></ul><ul><li>Film d'interviews - retours d'expériences </li></ul>
    3. 3. Introduction aux méthodes agiles
    4. 4. Bilan des projets informatiques <ul><li>Seulement 1/3 des projets informatique </li></ul><ul><ul><li>Réalisés dans les temps </li></ul></ul><ul><ul><li>Et dans les coûts impartis... </li></ul></ul>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. 5. Méthodologies projet classiques Spécification des besoins Analyse Réalisation Test Recette Démarrage Effet Tunnel Effet Big-Bang
    6. 6. Fonctions utilisées d'un logiciel Près de la moitié des fonctionnalités ne sont jamais utilisées !
    7. 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. 8. L'inéluctable imperfection
    9. 9. Il devient nécessaire... <ul><li>D'établir un dialogue avec l’utilisateur </li></ul><ul><ul><li>Comprendre ce qu’il dit </li></ul></ul><ul><ul><li>Parler un langage qu’il comprend </li></ul></ul><ul><ul><li>L’impliquer dans la réussite du projet </li></ul></ul>
    10. 10. Il devient nécessaire... <ul><li>De s’appuyer sur des estimations fiables : </li></ul><ul><ul><li>Un plan précis mais faux est non seulement inutile mais dangereux ! </li></ul></ul><ul><ul><li>Une projection sur 3 semaines est fiable. Cette fiabilité décroit ensuite. </li></ul></ul><ul><ul><li>Compter les fonctions développées a plus de valeur qu’estimer un reste à faire </li></ul></ul>
    11. 11. Il devient nécessaire... <ul><li>D’optimiser le travail de l’équipe de développement </li></ul><ul><ul><li>Faire ce qui est nécessaire et suffisant pour l’utilisateur </li></ul></ul><ul><ul><li>Minimiser les productions intermédiaires </li></ul></ul><ul><ul><li>Favoriser le partage des savoirs et des compétences </li></ul></ul>
    12. 12. <ul><li>Le manifeste des méthodes agiles </li></ul>
    13. 13. Le manifeste des méthodes agiles <ul><li>Août 2001, publication du manifeste des méthodes agiles </li></ul><ul><ul><li>17 personnalités éminentes du développement : </li></ul></ul><ul><ul><ul><li>Ward Cunningham (Wiki) </li></ul></ul></ul><ul><ul><ul><li>Kent Beck (eXtreme Programming) </li></ul></ul></ul><ul><ul><ul><li>Ken Schwaber </li></ul></ul></ul><ul><ul><ul><li>Jeff Sutherland (SCRUM) </li></ul></ul></ul><ul><ul><ul><li>Alistair Cockburn </li></ul></ul></ul><ul><ul><ul><li>Martin Fowler </li></ul></ul></ul>
    14. 14. Le manifeste des méthodes agiles <ul><li>Les valeurs de l'agilité : </li></ul>
    15. 15. L’agilité se décline en 12 principes <ul><li>« Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles » </li></ul>« 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. 16. L’agilité se décline en 12 principes <ul><li>« Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte » </li></ul>« Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet  »
    17. 17. L’agilité se décline en 12 principes <ul><li>« 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 » </li></ul>« La méthode la plus efficace pour transmettre l'information est une conversation en face à face »
    18. 18. L’agilité se décline en 12 principes <ul><li>« Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet » </li></ul>« Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment »
    19. 19. L’agilité se décline en 12 principes <ul><li>« La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle » </li></ul>« Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité »
    20. 20. L’agilité se décline en 12 principes <ul><li>« Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent » </li></ul>« À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens »
    21. 21. Emergence des méthodes agiles
    22. 22. Les nouvelles approches <ul><li>Les solutions proposées sont : </li></ul><ul><ul><li>Pilotées par le risque </li></ul></ul><ul><ul><li>itératives et incrémentales </li></ul></ul><ul><ul><li>Orienté Use-case </li></ul></ul><ul><ul><li>Orienté architecture </li></ul></ul><ul><li>L’ approche n’est plus prédictive mais agile </li></ul><ul><li>Définition des méthodes dites agiles : </li></ul><ul><li>« Méthodes itératives à planification souple qui permettent l’adaptation aux changements de contexte et de spécifications d ’un projet » </li></ul>
    23. 23. Une pléthore de nouvelles approches XP Scrum Kanban Lean …
    24. 24. Un retour d'expérience … plutôt qu'un long discours méthodologique
    25. 25. <ul><li>DSI de 200 personnes, laboratoire pharmaceutique </li></ul><ul><li>Refonte du Système d’information (JEE, ESB, etc.) </li></ul><ul><li>10000 jours/homme </li></ul><ul><li>Intérêts de l’agilité pour ce projet : </li></ul><ul><ul><li>introduire des demandes d’évolutions en cours de projet </li></ul></ul><ul><ul><li>faciliter l’acceptation des nouvelles solutions par les utilisateurs </li></ul></ul><ul><li>Basé sur Scrum et Kanban </li></ul>Contexte du projet
    26. 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. 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. 28. Processus itératif <ul><li>Des itérations d’un mois </li></ul><ul><ul><li>Mais cela peut varier en fonction des phase du projet </li></ul></ul><ul><ul><li>Scrum : sprint durée fixe </li></ul></ul><ul><ul><li>Kanban </li></ul></ul><ul><li>Des recettes utilisateurs à chaque fin d’itération </li></ul><ul><ul><li>En période pré-production : recette toutes les 2 / 3 semaines </li></ul></ul>Recette Utilisateur - janvier 2010
    29. 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. 30. Backlog de produit <ul><li>Backlog de produit = les exigences </li></ul><ul><li>En XP : User stories </li></ul><ul><li>Une entrée du backlog de produit est un Use Case UML (inspiré d’UP) </li></ul><ul><li>Un use Case déroulé sur 1 ou 2 itérations </li></ul><ul><ul><li>Scrum Kanban </li></ul></ul><ul><li>Priorités revues à chaque itération </li></ul><ul><li>Définies par le Product Owner </li></ul><ul><li>Mais également par le reste de l’équipe (différent de Scrum) </li></ul>Backlog de produit
    31. 31. Un backlog de produit <ul><li>Chaque UC, deux attributs : </li></ul><ul><ul><li>Une estimation en points arbitraires </li></ul></ul><ul><ul><ul><li>Pas encore de jours </li></ul></ul></ul><ul><ul><li>Une priorité (métier, risque technique identifié?) </li></ul></ul><ul><li>La liste peut évoluer au cours du projet </li></ul><ul><ul><li>Suite au recette utilisateur en fin d’itération </li></ul></ul>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. 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 <ul><li>Séances de planification itératives </li></ul><ul><li>Analyser et évaluer le backlog de produit </li></ul><ul><li>Définir le but de l’itération </li></ul>Plan <ul><li>Décider comment s'y prendre (conception) ‏ </li></ul><ul><li>Créer la liste des tâches à partir des éléments du backlog de produit </li></ul><ul><li>Estimer les tâches </li></ul>But de l’itération Liste des tâches dans JIRA
    33. 33. Planification Itérative en continue <ul><li>Sa disponibilité réelle pour l’itération à venir </li></ul><ul><li>Chaque membre 80% opérationnel sur des entrées du backlog </li></ul><ul><ul><li>20% restant : stand-up, refactoring, etc... </li></ul></ul><ul><li>La liste des tâches est créée collectivement </li></ul><ul><ul><li>Pas seulement par le ScrumMaster </li></ul></ul><ul><li>Expérimentation : peer-chiffrage </li></ul><ul><li>La conception de haut niveau est abordée </li></ul>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. 34. Vie du backlog de l’itération <ul><li>L'estimation du reste à faire est ajustée tous les jours </li></ul><ul><ul><li>Stand-up / JIRA </li></ul></ul><ul><li>Mise à jour du travail restant quand il est mieux connu </li></ul><ul><li>N'importe qui peut ajouter, supprimer ou changer la liste des tâches en stand-up </li></ul><ul><li>Si un travail n'est pas clair </li></ul><ul><ul><li>Définir une tâche avec plus de temps et la décomposer après </li></ul></ul>Burndown Chart Scrum
    35. 35. TDD Test Driven Development
    36. 36. Développement piloté par les tests <ul><li>On écrit les tests AVANT le code </li></ul><ul><li>Déroulement : </li></ul><ul><ul><li>Ecriture du test </li></ul></ul><ul><ul><li>Vérification de l'échec du test </li></ul></ul><ul><ul><ul><li>puisque le code n'existe pas encore </li></ul></ul></ul><ul><ul><li>Ecriture du code </li></ul></ul><ul><ul><li>Vérification du test </li></ul></ul><ul><ul><li>Refactoring </li></ul></ul><ul><ul><ul><li>amélioration en gardant les mêmes fonctionnalités : javadoc, commentaires… </li></ul></ul></ul>
    37. 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. 38. Intérêt du TDD <ul><li>Précisent les spécifications </li></ul><ul><ul><li>Les tests peuvent même être la documentation </li></ul></ul><ul><li>Force à réfléchir très tôt aux jeux de test </li></ul><ul><li>Force à designer du code testable </li></ul><ul><ul><li>Souvent plus simple, aux dépendances isolées </li></ul></ul><ul><ul><li>L'injection de dépendance y pousse naturellement </li></ul></ul><ul><li>Permet d'arrêter le travail au bon moment </li></ul><ul><ul><li>Quand les tests passent </li></ul></ul><ul><ul><li>Sans travail inutile </li></ul></ul>
    39. 39. L’outillage L'outillage de l'agilité
    40. 40. Sommaire <ul><li>Introduction </li></ul><ul><ul><li>Principes agiles impactant l’outillage </li></ul></ul><ul><li>Outils collaboratifs </li></ul><ul><ul><li>Gestion de sources </li></ul></ul><ul><ul><li>Bug Tracker </li></ul></ul><ul><li>Pour les développeurs </li></ul><ul><ul><li>Construction avec Maven </li></ul></ul><ul><ul><li>Tests avec des Mock Objects </li></ul></ul><ul><ul><li>Outils d’analyse de code </li></ul></ul><ul><li>Intégration continue </li></ul><ul><li>Conclusion </li></ul>
    41. 41. Pratiques agiles impactant l’outillage <ul><li>Pratiques UP </li></ul><ul><ul><li>Gérer les exigences </li></ul></ul><ul><ul><li>Modéliser graphiquement </li></ul></ul><ul><ul><li>Vérifier continuellement la qualité </li></ul></ul><ul><li>Pratiques XP </li></ul><ul><ul><li>TDD </li></ul></ul><ul><ul><li>Intégration continue </li></ul></ul><ul><ul><li>Refactoring </li></ul></ul><ul><ul><li>Convention de codage </li></ul></ul>
    42. 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. 43. Outils collaboratifs : gestion de sources <ul><li>Gestion de sources (SCM) </li></ul><ul><ul><li>Référentiel commun </li></ul></ul><ul><ul><li>Gestion de l’historique </li></ul></ul><ul><ul><ul><li>Pour la traçabilité </li></ul></ul></ul><ul><ul><ul><li>Et le retour arrière </li></ul></ul></ul><ul><ul><li>Commentaires de commit </li></ul></ul><ul><ul><li>Etiquetage de versions </li></ul></ul><ul><ul><li>Branches pour des développements en parallèle </li></ul></ul><ul><ul><li>Qu’on peut fusionner </li></ul></ul><ul><li>SVN, GIT </li></ul>
    44. 44. Gestion de sources : bonnes pratiques <ul><li>Tu te synchroniseras plusieurs fois par jour </li></ul><ul><li>Tu commiteras une fonctionnalité entière </li></ul><ul><li>Tu auras vérifié qu’elle fonctionne </li></ul><ul><li>Tu feras un commentaire de commit explicite </li></ul><ul><li>Tu feras même référence au n° de ticket/tâche/bug </li></ul>
    45. 45. Outils collaboratifs : Bug Tracker <ul><li>Mais aussi : </li></ul><ul><ul><li>Suivi de projet </li></ul></ul><ul><ul><li>Gestion des versions </li></ul></ul><ul><ul><li>Suivi des imputations </li></ul></ul><ul><ul><li>Et du reste-à-faire </li></ul></ul><ul><ul><li>Moteur de recherche </li></ul></ul><ul><ul><li>Et intégration SCM </li></ul></ul><ul><li>Quelques références : </li></ul><ul><ul><li>JIRA, BugZilla, Trac, … </li></ul></ul>
    46. 46. Outils collaboratifs : Bug Tracker <ul><li>Objectif : </li></ul><ul><ul><li>Tracer la vie de l’application </li></ul></ul><ul><li>Comment : </li></ul><ul><ul><li>Recueillir bugs, évolutions, tâches </li></ul></ul><ul><ul><li>Qualifier (criticité, commentaire, capture d’écran, fichier attaché, lien entre tâches, doublons) </li></ul></ul><ul><ul><li>Affecter à un responsable </li></ul></ul><ul><ul><li>Suivre dans un workflow </li></ul></ul><ul><ul><li>Notifier par mail </li></ul></ul>
    47. 47. Bug Tracker : bonnes pratiques <ul><li>Génial, y’a une StackTrace ! </li></ul><ul><li>Et les logs correspondants ! </li></ul><ul><li>Et même un scénario pour reproduire le problème ! </li></ul><ul><li>Tu essayeras d’estimer le reste à faire </li></ul>
    48. 48. La collaboration... mondiale ! <ul><li>Social Coding </li></ul><ul><ul><li>Cloud computing </li></ul></ul><ul><ul><li>SCM et BugTracker </li></ul></ul><ul><ul><li>Collaborer en OpenSource </li></ul></ul><ul><ul><li>Contributeurs du monde entier </li></ul></ul><ul><li>-> GitHub, BitBucket </li></ul><ul><li>Après l’exécution, même le DEV va dans le cloud </li></ul><ul><ul><li>Cloudbees, CloudIDE, ... </li></ul></ul>
    49. 49. L’outillage des développeurs : IDE <ul><li>Les développeurs… </li></ul><ul><ul><li>… voudraient automatiser les tâches répétitives </li></ul></ul><ul><ul><li>Parce qu’ils sont fainéants veulent être productifs </li></ul></ul><ul><ul><ul><li>Pour générer du code </li></ul></ul></ul><ul><ul><ul><li>Pour faire du refactoring </li></ul></ul></ul><ul><ul><ul><li>Pour documenter </li></ul></ul></ul><ul><li>-> IDE </li></ul><ul><ul><li>Eclipse, NetBeans, IntelliJ : ils sont tous classes! </li></ul></ul>
    50. 50. Pour les développeurs : construction <ul><li>Les développeurs… </li></ul><ul><ul><li>… souhaiteraient automatiser la génération des livrables </li></ul></ul><ul><ul><ul><li>Pour installer rapidement un poste de développement </li></ul></ul></ul><ul><ul><ul><li>Pour utiliser une nouvelle librairie super classe </li></ul></ul></ul><ul><ul><ul><li>Pour déployer 27 fois par jour… </li></ul></ul></ul><ul><ul><ul><li>… sur des environnements différents… </li></ul></ul></ul><ul><ul><ul><li>… sans galérer </li></ul></ul></ul><ul><li>-> Outil de construction (Maven, Gradle) </li></ul>
    51. 51. Construction : Maven <ul><li>Maven formalise l’intégration du projet </li></ul><ul><ul><li>En décrivant le QUOI plutôt que le COMMENT (Ant, anyone?) </li></ul></ul><ul><ul><li>Sur toutes ses étapes : </li></ul></ul><ul><ul><ul><li>De l’extraction des sources </li></ul></ul></ul><ul><ul><ul><li>Jusqu’au déploiement sur les plateformes cibles </li></ul></ul></ul><ul><ul><li>En centralisant toutes les données du projet : </li></ul></ul><ul><ul><ul><li>Version, Repository des sources, Dépendances </li></ul></ul></ul><ul><ul><ul><li>Rapports qualités, Acteurs </li></ul></ul></ul><ul><ul><li>Et en encourageant de bonnes pratiques : </li></ul></ul><ul><ul><ul><li>Normalisation de la structure </li></ul></ul></ul><ul><ul><ul><li>Versioning </li></ul></ul></ul><ul><ul><ul><li>Exécution des tests automatisés </li></ul></ul></ul>
    52. 52. Construction : Maven <ul><li>Des avantages, plein : </li></ul><ul><ul><li>Homogénéise l’intégration </li></ul></ul><ul><ul><li>Gestion des dépendances </li></ul></ul><ul><ul><ul><li>Téléchargement automatique des librairies </li></ul></ul></ul><ul><ul><ul><li>Depuis un référentiel public, ou privé (Archiva, Nexus, ...) </li></ul></ul></ul><ul><ul><li>Extensible par des plugins de construction </li></ul></ul><ul><ul><ul><li>Gérés par Maven, donc disponibles automatiquement </li></ul></ul></ul><ul><ul><li>Gestion automatisée des versions </li></ul></ul><ul><ul><ul><li>Incrément, Tag, Branche de maintenance </li></ul></ul></ul><ul><ul><li>Intégration continue facilitée </li></ul></ul>
    53. 53. Tests <ul><li>Les développeurs… </li></ul><ul><ul><li>… rêveraient d’avoir toute confiance dans leur commit </li></ul></ul><ul><ul><ul><li>Répondre au besoin, y compris sur ses cas limites </li></ul></ul></ul><ul><ul><ul><li>Sans introduire de régression </li></ul></ul></ul><ul><li>-> Tests unitaires et d’intégration </li></ul><ul><ul><li>Inutile d’en rappeler les bénéfices, non ? </li></ul></ul><ul><ul><li>Passons à l’exemple… </li></ul></ul><ul><li>Démo disponible sur GitHub : </li></ul><ul><ul><li>https://github.com/Fluor/TogoJUG </li></ul></ul>
    54. 54. Démo : tests avec mock-objects A TESTER SANS IMPLÉMENTATION !
    55. 55. Out ils de mesure de la qualité du code <ul><li>Les développeurs... </li></ul><ul><ul><li>Contrôleraient leur code en permanence </li></ul></ul><ul><ul><li>Pour qu’il soit maintenable, évolutif, documenté… </li></ul></ul><ul><ul><li>Grâce à des outils d’analyse automatisés </li></ul></ul><ul><ul><li>Permettant de produire rapidement du code de qualité </li></ul></ul><ul><li>-> Plugins </li></ul>
    56. 56. Outils de vérification du code <ul><li>Pour un code… </li></ul><ul><ul><li>Standard </li></ul></ul><ul><ul><ul><li>CheckStyle : vérification des conventions de codage </li></ul></ul></ul><ul><ul><li>Sans bugs courants </li></ul></ul><ul><ul><ul><li>FindBugs : recherche de bugs courants </li></ul></ul></ul><ul><ul><ul><li>PMD : recherche de bugs, de code mort </li></ul></ul></ul><ul><ul><li>Testé </li></ul></ul><ul><ul><ul><li>Surefire Report : rapports d'exécution de tests unitaires </li></ul></ul></ul><ul><ul><ul><li>Cobertura : rapports de couverture de tests </li></ul></ul></ul><ul><ul><li>Simple et maintenable </li></ul></ul><ul><ul><ul><li>JDepend : indicateurs sur le niveau de couplage </li></ul></ul></ul><ul><ul><ul><li>PMD CPD : recherche de code dupliqué </li></ul></ul></ul><ul><ul><ul><li>JavaNCSS : complexité cyclomatique </li></ul></ul></ul>
    57. 57. Intégration continue <ul><li>Les développeurs… </li></ul><ul><ul><li>… devraient détecter au plus tôt les régressions </li></ul></ul><ul><ul><ul><li>Etre notifié quand elles arrivent </li></ul></ul></ul><ul><ul><ul><li>Pour les corriger quand elles sont fraiches </li></ul></ul></ul><ul><ul><ul><li>Et avant qu’elles ne s’empilent </li></ul></ul></ul><ul><ul><ul><li>Pour être toujours prêt à livrer l’application </li></ul></ul></ul><ul><li>-> Intégration continue (Hudson, Jenkins) </li></ul>
    58. 58. Intégration continue <ul><li>Gestion de tâches programmées </li></ul><ul><li>Intégration </li></ul><ul><ul><li>Avec l'outil de gestion des sources </li></ul></ul><ul><ul><li>Avec l'outil de construction </li></ul></ul><ul><ul><li>Avec l'annuaire projet </li></ul></ul><ul><ul><li>Avec des outils d’analyse de la qualité </li></ul></ul><ul><ul><li>Donc trivial avec un projet Maven ! </li></ul></ul><ul><li>Remontée d'alertes </li></ul><ul><ul><li>Pour détecter les problèmes au plus tôt </li></ul></ul><ul><ul><li>Et les corriger au plus vite </li></ul></ul><ul><li>Consultation des rapports </li></ul>
    59. 59. Conclusion <ul><li>Il ne faut pas sur interpréter le principe agile : « Parier sur les hommes plutôt que le processus ou l’outillage » </li></ul><ul><ul><li>« Plutôt » ne signifie pas que l’outillage est accessoire </li></ul></ul><ul><li>Et vulgariser, former… </li></ul><ul><li>Les personnes de l’équipe doivent s’approprier la méthode </li></ul><ul><ul><li>Mieux que de l’imposer! </li></ul></ul><ul><ul><li>Appliquer les pratiques agiles qui semblent « pragmatiques » et adaptées à votre contexte </li></ul></ul><ul><li>« Ne pas développer de dépendance spécifique à une arme ou à une école de combat » </li></ul><ul><ul><li>Miyamoto Musachi, Samouraï du XVIIième siècle </li></ul></ul>
    60. 60. Lectures… <ul><li>Ken Schwaber </li></ul><ul><ul><li>ADM </li></ul></ul><ul><ul><li>Scrum présenté à OOPSLA 96 avec Sutherland </li></ul></ul><ul><ul><li>Auteur des 3 livres sur Scrum </li></ul></ul><ul><li>Agile and Iterative Development: A Manager’s Guide de Craig Larman </li></ul><ul><li>Agile Estimating and Planning de Mike Cohn </li></ul><ul><li>Agile Retrospectives d'Esther Derby et Diana Larsen </li></ul><ul><li>Agile Software Development Ecosystems de Jim Highsmith </li></ul><ul><li>User Stories Applied for Agile Software Development de Mike Cohn </li></ul><ul><li>Des articles toutes les semaines à www.scrumalliance.org </li></ul>
    61. 61. Où se renseigner ? <ul><li>www.mountaingoatsoftware.com/scrum </li></ul><ul><li>www.scrumalliance.org </li></ul><ul><li>www.controlchaos.com </li></ul><ul><li>[email_address] </li></ul><ul><li>En français : </li></ul><ul><ul><li>le groupe des utilisateurs de Scrum : www.frenchsug.org </li></ul></ul><ul><ul><li>http://fr.groups.yahoo.com/group/frenchsug </li></ul></ul><ul><ul><li>Scrum vs Kanban: </li></ul></ul><ul><ul><ul><li>http://www.fabrice-aimetti.fr/dotclear/public/mes-documents/Kanban-vs-Scrum-French.pdf </li></ul></ul></ul>
    62. 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

    ×