XP+Scrum+DevOps

628 vues

Publié le

Publié dans : Internet
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
628
Sur SlideShare
0
Issues des intégrations
0
Intégrations
10
Actions
Partages
0
Téléchargements
11
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

XP+Scrum+DevOps

  1. 1. www.sooyoos.commercredi 18 mars 2015 DÉVELOPPEMENT AGILE 1
  2. 2. www.sooyoos.commercredi 18 mars 2015 2 CONSTAT EN 1994
  3. 3. www.sooyoos.commercredi 18 mars 2015 3 «  Laws of chaos » enquête de 1994 du « Standish Group » 31 % des projets informatiques sont arrêtés en cours de route, 52 % n’aboutissent qu’au prix d’un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu’il n’en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès.
  4. 4. www.sooyoos.commercredi 18 mars 2015 4 POUR SITUER 1994
  5. 5. www.sooyoos.commercredi 18 mars 2015 5
  6. 6. www.sooyoos.commercredi 18 mars 2015 6 GESTION DE PROJET TRADITIONNELLE
  7. 7. www.sooyoos.commercredi 18 mars 2015 7
  8. 8. www.sooyoos.commercredi 18 mars 2015 8
  9. 9. www.sooyoos.commercredi 18 mars 2015 Cahier des charges Etude des besoins Etude de faisabilité Développe ment Tests Validation Recette temps détails
  10. 10. www.sooyoos.commercredi 18 mars 2015 Peur Euphorie Inquiétude Panique Recherche des coupables Punition des innocents promotion de ceux qui n’ont pas trempé dans le projet temps détails
  11. 11. www.sooyoos.commercredi 18 mars 2015 11 • Mauvaise maitrise des délais dues à de nombreux facteurs non maitrisés • Contrainte d’un budget limité au détriment de la qualité • Aucune flexibilité en cours de développement • Evolutivité après livraison du produit non évalué • Mauvaise compréhension du besoin • Cahier des charges mal étudié ou incomplet car moins standard • Aucune visibilité sur le travail en cours • Fonctionnalités inutiles développées et finalisées • Effet tunnel LES PROBLÈME RENCONTRÉS SUR LE DÉVELOPPEMENT LOGICIEL
  12. 12. www.sooyoos.commercredi 18 mars 2015 12 SORTIE DU TUNNEL
  13. 13. www.sooyoos.commercredi 18 mars 2015 13 Quand on montre l’application au client
  14. 14. www.sooyoos.commercredi 18 mars 2015 14 PEUR DE LA CONFRONTATION AVEC LE CLIENT
  15. 15. www.sooyoos.commercredi 18 mars 2015 15 Quand l’équipe technique est obligée d’assister à une réunion avec le client
  16. 16. www.sooyoos.commercredi 18 mars 2015 16 RECHERCHE DE NOUVELLES MÉTHODOLOGIES
  17. 17. www.sooyoos.commercredi 18 mars 2015 17
  18. 18. www.sooyoos.commercredi 18 mars 2015 18 2001 – ÉCRITURE DU MANIFESTE AGILE
  19. 19. www.sooyoos.commercredi 18 mars 2015 19 AGILE MANIFESTO LES 4 VALEURS Nous découvrons de meilleures approches pourfaire du développementlogiciel, en en faisantnous même eten aidant les autres à en faire. G râce à ce travailnous en sommes arrivés à préféreretfavorise • 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. C ela signifie que bien qu'ilyaitde la valeurdans les items situés à droite, notre préférence se porte surles items qui se trouventsurla gauche.
  20. 20. www.sooyoos.commercredi 18 mars 2015 20 AGILE MANIFESTO LES 17 EXPERTS Kent Beck: inventeur de l’Extreme Programming avec Ward Cunningham et Ron Jeffries ; co fondateur de Junit avec Erich Gamma Ward Cunningham : inventeur du wiki Ken Schwaberet Jeff Sutherland : inventeur du scrum JimHighsmith : inventeur de la méthode ASD -Adaptive software development Alistair Cockburn : inventeur de la méthode Crystal clear Martin Fowler, Dave Thomas et Arie van Bennekum : inventeurs de la méthode DSDM – Dynamic System Development Method 2001 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
  21. 21. www.sooyoos.commercredi 18 mars 2015 21 • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. • Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client. • Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. • Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. • La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. AGILE MANIFESTO LES 12 PRINCIPES
  22. 22. www.sooyoos.commercredi 18 mars 2015 22 • Un logiciel opérationnel est la principale mesure d’avancement. • Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. • Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité. • La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. • Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. • À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. AGILE MANIFESTO LES 12 PRINCIPES
  23. 23. www.sooyoos.commercredi 18 mars 2015 23 XP
  24. 24. www.sooyoos.commercredi 18 mars 2015 24 EXTREME PROGRAMMING 1 996 : Reprise du projetC 3 qui étaiten échec après 1 8 mois de développement. Kent Beck : « C’était un mélange de préparation soigneuse et de panique » Faire des économies d’équipe et de temps sur la recette avec la mise en place de test en amont. Travail en tandem pour assurer la reprennabilité : « Si un programmeur parvient à communiquer clairement ses idées à un autre programmeur travaillant à ses côtés, il y a de grandes chances pour que celui qui vérifiera le programme deux ans plus tard n’ait aucun mal à le comprendre » 1 997 fin du projetC 3 etpublication de la méthode
  25. 25. www.sooyoos.commercredi 18 mars 2015 25 XP VS MÉTHODES TRADITIONNELLES Les méthodes agiles essayentde formaliserle bon sens etle pragmatisme que des équipes mettentdéjà en œuvre dans le cadre de projets dits traditionnels XP n’estpas l’ennemi d’UML XP peutcompléterdes méthodes traditionnelles.
  26. 26. www.sooyoos.commercredi 18 mars 2015 26 EXTREME PROGRAMMING XP pousse à l’extrême des principes simples Ilse définie comme : • une tentative de réconcilier l'humain avec la productivité • un mécanisme pour faciliter le changement social • une voie d'amélioration • une discipline de développement d'applications informatiques • un style de développement Son butprincipalestde réduire les coûts du changement.
  27. 27. www.sooyoos.commercredi 18 mars 2015 27 XP : LE CONSTAT Il faut rendre moins lourdes les démarches Diminuer les risques liés à l’utilisation de documents à rallonges illisibles. Equilibre entre « pas de démarche » et « trop de démarche » Focus sur le code bien commenté plutôt que des docs techniques Il faut changerles principes Etre adaptif plutôt que prédictif. Car le prédicat de base ou le contexte changent toujours. Priorité aux personnes plutôt qu’aux process, pour que le développement reste agréable.
  28. 28. www.sooyoos.commercredi 18 mars 2015 28 XP : LES VALEURS Communication Dans l’équipe : chacun doit tenir au courant les autres de l’état d’avancement dans son travail. Créer un esprit d’équipe, une dynamique de groupe. Commenter son code. Avec le client : Rapprocher le client et les développeurs. Intégrer le client dans le projet.
  29. 29. www.sooyoos.commercredi 18 mars 2015 29 XP : LES VALEURS Feedback Du client : Livrer régulièrement pour avoir des retours réguliers. La mise en place de tests unitaires permettent de détecter les bugs et les régressions. Le client aura tendance naturellement à féliciter l’avancement du projet. Les développeurs auront moins de crainte car toute divergence sera détectée rapidement De l’équipe : programmation en pair programming, critiques constructives et félicitations permettront aux équipes de monter en compétence naturellement.
  30. 30. www.sooyoos.commercredi 18 mars 2015 30 XP : LES VALEURS Simplicité Le Yagni (You ain't gonna need it : tu n’en aura pas besoin). Toujours chercher à supprimer l’inutile pour optimiser au maximum la productivité. Qu’elle est la solution la plus simple qui peut fonctionner ? il vaut mieux faire simple aujourd'hui, quitte à changer demain, plutôt que de faire tout de suite compliqué sans être absolument certain de l'utilité de ce que l'on développe Permet de faire des économies en moyenne, car la simplicité d'aujourd'hui revient moins cher et le surcoût éventuel. Rester précis, « le plus simple possible » ne veut pas dire « simpliste ». Ne jamais dupliquer du code.
  31. 31. www.sooyoos.commercredi 18 mars 2015 31 XP : LES VALEURS Courage Le client doit avoir le courage de donner des priorités à ses besoins, et dire quel besoin n’est finalement pas très clair. Le responsable doit avoir le courage de commencer le projet avant que tout ait été précisé clairement sur un document contractuel. Le développeur doit avoir le courage de jeter du code pour repartir sur de bonnes bases. Le développeur doit avoir le courage de laisser son binôme observer son travail et ses compétences.
  32. 32. www.sooyoos.commercredi 18 mars 2015 32 XP : MISE EN OEUVRE Diviserpourmieux régner Des réunions « planning game » permettent d’attaquer les fonctionnalités par petits lots. De nombreuses itérations. Définition des besoins pardes users stories Descriptions à l’image d’une bande dessinée (contenu simple et imagé) Aucune considération technique Usage de métaphore pour bien faire comprendre
  33. 33. www.sooyoos.commercredi 18 mars 2015 33 XP : MISE EN OEUVRE Estimations Estimation par user story. Estimation faite en unités arbitraires (XP units) Renégociations régulières Les estimations se préciseront au fur et à mesure des itérations
  34. 34. www.sooyoos.commercredi 18 mars 2015 34 XP : MISE EN OEUVRE TDD Test driven development. « Ecrire les tests puis coder : si vous ne le faites pas, vous n'êtes pas un Extreme Programmer » Fait partie de la documentation Automatisé 2 types de tests Tests fonctionnels (rédigé par le client à partir d’un language formel) Tests unitaires. Vérifie la qualité du développement.
  35. 35. www.sooyoos.commercredi 18 mars 2015 35 XP : MISE EN OEUVRE Code propre et efficace Conception la plus simple possible (simple design) surtout au début. La relecture du code doit être la plus aisée possible. Aucune duplication, principe du DRY (Don’t repeat Yourself) Refactoring régulier
  36. 36. www.sooyoos.commercredi 18 mars 2015 36 XP : MISE EN OEUVRE Organisation du développement Programmation en pair programming Une personne produit (driver), l’autre (partner) prend du recul, vérifie la cohérence globale, la conception et l’application d’XP Développeurs heureux Stand-up meeting Esprit d’équipe XP préconise de ne pas faire d’heures supp plus de deux semaines de suite.
  37. 37. www.sooyoos.commercredi 18 mars 2015 37 SCRUM
  38. 38. www.sooyoos.commercredi 18 mars 2015 38 SCREUM, SCRUME, SCROUME Scrum Signifie mêlée au rugby. Reprend les valeurs et l’esprit d’équipe du rugby et les adapte au projets de développement.
  39. 39. www.sooyoos.commercredi 18 mars 2015 39 RÔLES •Product owner •Scrummaster •Développeurs •Parties prenantes
  40. 40. www.sooyoos.commercredi 18 mars 2015 40 APPROCHE ITÉRATIVE ET INCRÉMENTALE
  41. 41. www.sooyoos.commercredi 18 mars 2015 41 APPROCHE ITÉRATIVE ET INCRÉMENTALE Timebox Sprint de même durées pour donner le rythme Pas de sprint extensibles Budget fixé Release On privilégie la release à date fixée à l’avance, avec l’objectif d’apporter le maximum de valeur.
  42. 42. www.sooyoos.commercredi 18 mars 2015 42 APPROCHE ITÉRATIVE ET INCRÉMENTALE
  43. 43. www.sooyoos.commercredi 18 mars 2015 43 LE PO : PRODUCT OWNER Il défend le produit avant tout Des responsabilités produit sans responsabilité hiérarchique Il définit le contenu du produit Il planifie la vie du produit Il doit être disponible et participer aux cérémoniaux Les compétences Maitrise des techniques de définition de produit Autorité pour prendre des décisions rapidement Capacité à détailler au bon moment Esprit ouvert au changement Aptitude à la négociation
  44. 44. www.sooyoos.commercredi 18 mars 2015 44 LE SM : SCRUM MASTER Ce n’est pas un chef de projet mais un facilitateur Vecteur progressiste capable d’entraîner ses co-équipiers vers plus d’auto-organisation Il doit : Veiller à l’application de scum Encourager l’équipe à apprendre et à progresser Eliminer les obstacles Inciter l’équipe à devenir pluridisciplinaire et auto-organisée Les compétences Maitriser scrum Aptitude à comprendre le fonctionnel et la technique Facilité à communiquer Capacité à guider Talent de médiateur (ne jamais s’opposer au PO) Ténacité (pour faire sauter les obstacles, il en faut) Inclination à la transparence Goût à être au service de l’équipe
  45. 45. www.sooyoos.commercredi 18 mars 2015 45 Quand le Scrum Master protège poliment son équipe des envahisseurs
  46. 46. www.sooyoos.commercredi 18 mars 2015 46 LE BACKLOG
  47. 47. www.sooyoos.commercredi 18 mars 2015 47 Visible des parties prenantes Visible des développeurs Ajoute de la valeur Rétablie de la valeur CATÉGORIES D’UNE STORY
  48. 48. www.sooyoos.commercredi 18 mars 2015 48 CYCLE DE VIE D’UNE STORY Bac à glace PP+PO+E PO+E E PO+E PP+PO+E PO
  49. 49. www.sooyoos.commercredi 18 mars 2015 49 RELEASE Composé de plusieurs sprints Définir les critères de fin de release Estimer les stories du backlog Planning poker : Fibonacci : 1, 2, 3, 4, 8, 13, 20
  50. 50. www.sooyoos.commercredi 18 mars 2015 50 SPRINT Engagements lors de la planification de sprint : •Conditions •Disponibilités pour ce sprint •But du sprint •Liste de stories Lancement de sprint : Prise des tâches Burndown chart
  51. 51. www.sooyoos.commercredi 18 mars 2015 51 SPRINT Standup meeting (XP), daily scrum meeting S’adapter pour réussir le sprint : • identifier les obstacles • préparer les discusions d’équipe • garder l’équipe concentrée sur l’objectif • évaluer l’avancement du travail en cours • préparer les travaux nécessaires pour finir les stories Les 3 questions : •Qu’ai-je fait depuis le dernier scrum •Que vais-je faire jusqu’au prochain scrum •Quels sont les obstacles qui me freinent dans mon travail ? Toute l’équipe participe au meeting
  52. 52. www.sooyoos.commercredi 18 mars 2015 52 REVUE DE SPRINT Plus grand nombre d’invités La revue montre le produit Collecter le feedback Calculer la vélocité Ajouter les prévisions
  53. 53. www.sooyoos.commercredi 18 mars 2015 53 RÉTROSPECTIVE DE SPRINT Inter équipe (avec PO) Un moment de réflexion collective L’équipe refait le match • Qu’est ce qui a bien fonctionné ? • Qu’est ce qui s’est mal passé ? • Qu’est ce que nous pouvons améliorer ? Ne pas hésiter à adapter scrum Ne pas en faire une séance de règlements de compte
  54. 54. www.sooyoos.commercredi 18 mars 2015 54 DEVOPS
  55. 55. www.sooyoos.commercredi 18 mars 2015 55 CULTURE DEVOPS Continuité de l’agilité Rapprochement du « développement » et de « l’opération » Aligner les objectifs et rapprocher 2 cultures en une seule Regrouper les équipes Environnement de développement et celui de production (problématiques de couts)
  56. 56. www.sooyoos.commercredi 18 mars 2015 56 Vision des sysadmin des développeurs
  57. 57. www.sooyoos.commercredi 18 mars 2015 57 Quand un développeur touche à la prod
  58. 58. www.sooyoos.commercredi 18 mars 2015 58 Quand on laisse un développeur administrer le serveur…
  59. 59. www.sooyoos.commercredi 18 mars 2015 59 CULTURE DEVOPS
  60. 60. www.sooyoos.commercredi 18 mars 2015 60 INTÉGRATION CONTINUE Compiler, tester et livrer régulièrement. • Le code source est géré dans un repository ( GIT, SVN, Mercurial) • Compiler et construire l’application de façon automatique • Ecrire des tests unitaires et fonctionnels et les exécuter régulièrement • Construire et packager l’application à intervalle régulier ou déclancher la construction après chaque commit.
  61. 61. www.sooyoos.commercredi 18 mars 2015 61 LIVRAISON CONTINUE Automatiser la livraison de l’application sur différents environnement tout au long de son cycle de vie : Dev, Integration, Recette, Production Environnements le plus proche possible de celui de production Le déploiement doit se faire sans modification de code. Déploiement 100% automatisé
  62. 62. www.sooyoos.commercredi 18 mars 2015 62 DÉPLOIEMENT CONTINUE Vient après la livraison continue, mais est déployé jusqu’en production. Nécessite une automatisation complète (possibilité de validation manuelle) Peut être fait sans interruption de service Certains grands sites déploient des dizaines de release par jour.
  63. 63. www.sooyoos.commercredi 18 mars 2015 63 Quand … pour la première fois on déploie en devops une appli complète en mois de 2 minutes
  64. 64. www.sooyoos.commercredi 18 mars 2015 64 AMÉLIORATION CONTINUE Tout automatiser mais sans répéter les mêmes erreurs. Récolter régulièrement des feedbacks Prendre uniquement les indicateurs permettant de réduire le time to market (pas de conflit)
  65. 65. www.sooyoos.commercredi 18 mars 2015 65 AUTRES Multiplier les sondes, et indices pour le monitoring Monitoring et logs partagés Viser la performance Autoscaling Sécurité automatisé
  66. 66. www.sooyoos.commercredi 18 mars 2015 66 OUTILS AGILES Taiga.io Trello Asana Pivotaltracker Wrike Timeperformance
  67. 67. www.sooyoos.commercredi 18 mars 2015 67 OUTILS DE BUG TRACKING Redmine Mantis Trac Jira
  68. 68. www.sooyoos.commercredi 18 mars 2015 68 OUTILS DE VERSIONNING GIT SVN Mercurial Liquibase pour les schémas de BDD
  69. 69. www.sooyoos.commercredi 18 mars 2015 69 CLIENTS GRAPHIQUE Tortoisegit Sourcetree Ungit Smartgit Gitlab Github Bitbucket Usvn
  70. 70. www.sooyoos.commercredi 18 mars 2015 70 OUTILS DE PACKING, BUILD ET DÉPENDANCES Composer Npm Ant Rake
  71. 71. www.sooyoos.commercredi 18 mars 2015 71 TASK RUNNERS Grunt.js Gulp.js Brunch.io Yeoman Bower
  72. 72. www.sooyoos.commercredi 18 mars 2015 72 OUTILS D’INTEGRATION CONTINUE Jenkins Gitlab CI Hudson Travis
  73. 73. www.sooyoos.commercredi 18 mars 2015 73 GITLAB CI
  74. 74. www.sooyoos.commercredi 18 mars 2015 74 OUTILS DE TESTING Phpunit Selenium Casperjs + phantomjs Jasmine Karma
  75. 75. www.sooyoos.commercredi 18 mars 2015 75 OUTILS D’ORCHESTRATION ET DEPLOIEMENT Capistrano Capifony Rundeck Actions en masses : Func mCollective
  76. 76. www.sooyoos.commercredi 18 mars 2015 76 OUTILS DE CONFIGURATION Chef Puppet
  77. 77. www.sooyoos.commercredi 18 mars 2015 77 OUTILS D’INFRASTRUCTURE VIRTUELLE Virtualbox Vagrant Packer
  78. 78. www.sooyoos.commercredi 18 mars 2015 78 OUTILS DE CONTAINER VIRTUELS
  79. 79. www.sooyoos.commercredi 18 mars 2015 79 OUTILS POUR DOCKER Kitematic Boot2docker.io
  80. 80. www.sooyoos.commercredi 18 mars 2015 80 MONITORING ElasticSearch + Kibana Collectd, Stats, JMXTrans, Metrics, Esper, Ganglia, Graphite, Cube Graylog2, Flume, Logstash
  81. 81. www.sooyoos.commercredi 18 mars 2015 81 PAAS Heroku Openshift
  82. 82. www.sooyoos.commercredi 18 mars 2015 82 IAAS AWS Rackspace OVH
  83. 83. www.sooyoos.commercredi 18 mars 2015 83 AdresseContact Guillaume Sondag 01 48 06 80 82 guillaume@sooyoos.com Sooyoos, 11 rue Oberkampd 75011 Paris 83

×