XP+Scrum+DevOps

www.sooyoos.commercredi 18 mars 2015
DÉVELOPPEMENT
AGILE
1

2
CONSTAT EN 1994

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
POUR SITUER 1994

5

6
GESTION DE PROJET TRADITIONNELLE

7

8

Cahier des
charges
Etude des
besoins
Etude de
faisabilité
Développe
ment
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

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
SORTIE DU TUNNEL

13
Quand on montre l’application au client

14
PEUR DE LA CONFRONTATION AVEC LE CLIENT

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

16
RECHERCHE DE NOUVELLES MÉTHODOLOGIES

17

18
2001 – ÉCRITURE DU MANIFESTE AGILE

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
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
• 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
• 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
XP

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
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
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
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
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
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
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
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
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
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
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
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
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
SCRUM

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
RÔLES
•Product owner
•Scrummaster
•Développeurs
•Parties prenantes

40
APPROCHE ITÉRATIVE ET INCRÉMENTALE

41
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

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
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
Quand le Scrum Master protège poliment son équipe des
envahisseurs

46
LE BACKLOG

47
Visible des parties prenantes
Visible des développeurs
Ajoute de la valeur Rétablie de la valeur
CATÉGORIES D’UNE STORY

48
CYCLE DE VIE D’UNE STORY
Bac à
glace
PP+PO+E PO+E E PO+E PP+PO+E
PO

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
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
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
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
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
DEVOPS

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
Vision des sysadmin des développeurs

57
Quand un développeur touche à la prod

58
Quand on laisse un développeur administrer le serveur…

59
CULTURE DEVOPS

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
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
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
Quand … pour la première fois on déploie en devops une appli complète en mois de 2
minutes

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
AUTRES
Multiplier les sondes, et indices pour le monitoring
Monitoring et logs partagés
Viser la performance
Autoscaling
Sécurité automatisé

66
OUTILS AGILES
Taiga.io
Trello
Asana
Pivotaltracker
Wrike
Timeperformance

67
OUTILS DE BUG TRACKING
Redmine
Mantis
Trac
Jira

68
OUTILS DE VERSIONNING
GIT
SVN
Mercurial
Liquibase pour les schémas de BDD

69
CLIENTS GRAPHIQUE
Tortoisegit
Sourcetree
Ungit
Smartgit
Gitlab
Github
Bitbucket
Usvn

70
OUTILS DE PACKING, BUILD ET DÉPENDANCES
Composer
Npm
Ant
Rake

71
TASK RUNNERS
Grunt.js
Gulp.js
Brunch.io
Yeoman
Bower

72
OUTILS D’INTEGRATION CONTINUE
Jenkins
Gitlab CI
Hudson
Travis

73
GITLAB CI

74
OUTILS DE TESTING
Phpunit
Selenium
Casperjs + phantomjs
Jasmine
Karma

75
OUTILS D’ORCHESTRATION ET DEPLOIEMENT
Capistrano
Capifony
Rundeck
Actions en masses :
Func
mCollective

76
OUTILS DE CONFIGURATION
Chef
Puppet

77
OUTILS D’INFRASTRUCTURE VIRTUELLE
Virtualbox
Vagrant
Packer

78
OUTILS DE CONTAINER VIRTUELS

79
OUTILS POUR DOCKER
Kitematic
Boot2docker.io

80
MONITORING
ElasticSearch + Kibana
Collectd, Stats, JMXTrans, Metrics, Esper,
Ganglia, Graphite, Cube
Graylog2, Flume, Logstash

81
PAAS
Heroku
Openshift

82
IAAS
AWS
Rackspace
OVH

83
AdresseContact
Guillaume Sondag
01 48 06 80 82
guillaume@sooyoos.com
Sooyoos,
11 rue Oberkampd
75011 Paris
83

XP+Scrum+DevOps

Contenu connexe

Tendances

En vedette

Similaire à XP+Scrum+DevOps

XP+Scrum+DevOps