XP+Scrum+DevOps

www.sooyoos.commercredi 18 mars 2015

DÉVELOPPEMENT AGILE

1


CONSTAT EN 1994


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


POUR SITUER 1994



GESTION DE PROJET TRADITIONNELLE




Cahier des charges

Etude des besoins

Etude de faisabilité

Développement

Tests

Validation

Recette

temps

détails


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


• 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


SORTIE DU TUNNEL


Quand on montre l’application au client


PEUR DE LA CONFRONTATION AVEC LE CLIENT


Quand l’équipe technique est obligée d’assister à une réunion avec le client


RECHERCHE DE NOUVELLES MÉTHODOLOGIES



2001 – ÉCRITURE DU MANIFESTE AGILE


AGILE MANIFESTOLES 4 VALEURS

Nous découvrons de meilleures approches pour faire du développement logiciel, en en faisant nous même et en aidant les autres à en faire. G râce à ce travail nous en sommes arrivés à préférer et favorise

• 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'il y ait de la valeur dans les items situés à droite, notre préférence se porte sur les items qui se trouvent sur la gauche.


AGILE MANIFESTOLES 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 Schwaber et Jeff Sutherland : inventeur du scrum

Jim Highsmith : 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

2001Kent 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

• 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 MANIFESTOLES 12 PRINCIPES


• 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 MANIFESTOLES 12 PRINCIPES


XP


EXTREME PROGRAMMING1 996 : Reprise du projet C 3 qui était en é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 projet C 3 et publication de la méthode


XP VS MÉTHODES TRADITIONNELLES

Les méthodes agiles essayent de formaliser le bon sens et le pragmatisme que des équipes mettent déjà en œuvre dans le cadre de projets dits traditionnels

XP n’est pas l’ennemi d’UML

XP peut compléter des méthodes traditionnelles.


EXTREME PROGRAMMING

XP pousse à l’extrême des principes simplesIl se 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 but principal est de réduire les coûts du changement.


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 changer les 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.


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.


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.


XP : LES VALEURSSimplicité

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.


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.


XP : MISE EN OEUVRE

Diviser pour mieux régner

Des réunions « planning game » permettent d’attaquer les fonctionnalités par petits lots.De nombreuses itérations.

Définition des besoins par des users stories

Descriptions à l’image d’une bande dessinée (contenu simple et imagé)Aucune considération techniqueUsage de métaphore pour bien faire comprendre


XP : MISE EN OEUVRE

Estimations

Estimation par user story.Estimation faite en unités arbitraires (XP units)Renégociations régulièresLes estimations se préciseront au fur et à mesure des itérations


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 documentationAutomatisé

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.


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


XP : MISE EN OEUVRE

Organisation du développement

Programmation en pair programmingUne 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 meetingEsprit d’équipeXP préconise de ne pas faire d’heures supp plus de deux semaines de suite.


SCRUM


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.


RÔLES

•Product owner•Scrum master•Développeurs•Parties prenantes


APPROCHE ITÉRATIVE ET INCRÉMENTALE



Timebox

Sprint de même durées pour donner le rythmePas de sprint extensiblesBudget fixé

Release

On privilégie la release à date fixée à l’avance, avec l’objectif d’apporter le maximum de valeur.




LE PO : PRODUCT OWNER

Il défend le produit avant toutDes responsabilités produit sans responsabilité hiérarchique Il définit le contenu du produitIl planifie la vie du produitIl doit être disponible et participer aux cérémoniaux

Les compétences

Maitrise des techniques de définition de produitAutorité pour prendre des décisions rapidementCapacité à détailler au bon momentEsprit ouvert au changementAptitude à la négociation


LE SM : SCRUM MASTER

Ce n’est pas un chef de projet mais un facilitateurVecteur progressiste capable d’entraîner ses co-équipiers vers plus d’auto-organisationIl 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 scrumAptitude à comprendre le fonctionnel et la techniqueFacilité à communiquerCapacité à guiderTalent de médiateur (ne jamais s’opposer au PO) Ténacité (pour faire sauter les obstacles, il en faut)Inclination à la transparenceGoût à être au service de l’équipe


Quand le Scrum Master protège poliment son équipe des envahisseurs


LE BACKLOG


Visible des parties prenantes

Visible des développeurs

Ajoute de la valeur Rétablie de la valeur

CATÉGORIES D’UNE STORY


CYCLE DE VIE D’UNE STORY

Bac à glace

PP+PO+E PO+E E PO+E PP+PO+E

PO


RELEASE

Composé de plusieurs sprintsDéfinir les critères de fin de releaseEstimer les stories du backlogPlanning poker : Fibonacci : 1, 2, 3, 4, 8, 13, 20


SPRINTEngagements lors de la planification de sprint :•Conditions•Disponibilités pour ce sprint •But du sprint•Liste de stories Lancement de sprint : Prise des tâchesBurndown chart


SPRINT

Standup meeting (XP), daily scrum meetingS’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


REVUE DE SPRINT

Plus grand nombre d’invitésLa revue montre le produitCollecter le feedbackCalculer la vélocitéAjouter les prévisions


RÉTROSPECTIVE DE SPRINT

Inter équipe (avec PO)Un moment de réflexion collectiveL’é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 scrumNe pas en faire une séance de règlements de compte


DEVOPS


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 équipesEnvironnement de développement et celui de production (problématiques de couts)


Vision des sysadmin des développeurs


Quand un développeur touche à la prod


Quand on laisse un développeur administrer le serveur…


CULTURE DEVOPS


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.


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é


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.


Quand … pour la première fois on déploie en devops une appli complète en mois de 2 minutes


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)


AUTRES

Multiplier les sondes, et indices pour le monitoring

Monitoring et logs partagés

Viser la performance

Autoscaling

Sécurité automatisé


OUTILS AGILES

Taiga.ioTrelloAsanaPivotaltrackerWrikeTimeperformance


OUTILS DE BUG TRACKING

RedmineMantisTracJira


OUTILS DE VERSIONNING

GITSVNMercurialLiquibase pour les schémas de BDD


CLIENTS GRAPHIQUE

TortoisegitSourcetreeUngitSmartgit

GitlabGithubBitbucketUsvn


OUTILS DE PACKING, BUILD ET DÉPENDANCES

ComposerNpmAntRake


TASK RUNNERS

Grunt.jsGulp.jsBrunch.ioYeomanBower


OUTILS D’INTEGRATION CONTINUE

JenkinsGitlab CIHudsonTravis


GITLAB CI


OUTILS DE TESTING

PhpunitSeleniumCasperjs + phantomjsJasmineKarma


OUTILS D’ORCHESTRATION ET DEPLOIEMENT

CapistranoCapifonyRundeck

Actions en masses :FuncmCollective


OUTILS DE CONFIGURATION

ChefPuppet


OUTILS D’INFRASTRUCTURE VIRTUELLE

VirtualboxVagrantPacker


OUTILS DE CONTAINER VIRTUELS


OUTILS POUR DOCKER

KitematicBoot2docker.io


MONITORING

ElasticSearch + KibanaCollectd, Stats, JMXTrans, Metrics, Esper, Ganglia, Graphite, CubeGraylog2, Flume, Logstash


PAAS

HerokuOpenshift


IAAS

AWSRackspaceOVH


AdresseContactGuillaume Sondag01 48 06 80 [email protected]

Sooyoos,11 rue Oberkampd75011 Paris

83

Internet

XP+Scrum+DevOps