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