Mise en place de pratiques XP pour Cliquez pour modifier le style des sous-titres du masque Karine Sabatier www.karinesabatier.net
Karine Développeur Interaction Designer, Ergonome, Chef de projet Coach XP
But permettre aux marques & aux agences d assurer le succès de leurs opérations de marketing participatif
User Generated Content Co-création
Flash back
1996, Kent Beck, Ward Cunningham et Ron Jeffries travaillent chez Chrysler sur le projet «Chrysler Comprehensive Compensation» (1995) Smalltalk 1999, Kent Beck écrit son livre blanc «Extreme Programming Explained : embrace change»
Manifesto for agile software development (2001) Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://agilemanifesto.org/
Waterfall / cycle en V Expression de besoins Conception Développement Tests, recette & debuggage À 50% du temps total, le client ne voit statistiquement que 10% de son application. Et il ne sait pas dans quel état elle est.
Avec une méthodologie agile Expression de besoins Simplicité, user stories Pair programming Refactoring TDD, acceptance refactoring Demos, reviews, rétrospective s Conception Développement Tests, recette & debuggage i 1 i 2 i 3 À chaque itération, le produit est 100% fonctionnel. i n
Extreme programming?
5 valeurs Communication Feedback Simplicité Courage Respect
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
XP, pragmatique et humaniste Un ensemble de bonnes pratiques à généraliser Travailler mieux en structurant l équipe de manière auto-organisée en délivrant du code et un logiciel de qualité optimale (proche du zéro défaut) qui colle parfaitement à la vision du client le tout en reprenant plaisir à programmer Principe gagnant-gagnant
Ce que nous allons voir Le contexte Eyeka Pratiques mises en place et bénéfices Pratiques non mises en place et pourquoi (principaux freins)
Le Chaos Contexte
Contexte startup Un produit jeune aux contours flous Un business model fluctuant La pression des investisseurs Des deadlines serrées voire irréalistes Une équipe peu ou pas formée au framework Pénurie de ressources Ror => des conditions idéales pour l agilité
Contexte mais de bons outils Un framework (Ruby on Rails) très adapté mais sous-utilisé : Un framework avec des tests unitaires De la flexibilité : plugins, migrations, etc. Des outils de déploiement «agile»
La guerre Mise en place
pragmatique Mise en place Des besoins forts en formation de l équipe Une forte pression des actionnaires > besoin de ROI rapide Peu de temps donc une approche par «petits pas concrets»
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Un coach, un P.O. Mise en place Coach N a l autorité sur rien, est responsable de tout Éliminer les obstacles Fluidifier le travail Le Product Owner Le chef de produit (marketing)
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Mise en placec Collective Code Ownership Back to basics : un outil de versionning du code (Subversion puis git) Mais au delà de l'outil, surtout des règles d'or : Branches? Commits explicites! pas de commit tardif avant une livraison de code des commits liés au système de gestion de projet (Retrospectiva) => on gagne du temps. Les pratiques Phase 2 : les pratiques mises en mises place
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Convention over configuration Ruby on Rails : un framework MVC basé sur les conventions
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
les tests de recette Mise en place D abord manuels avec Selenium > l équipe est convaincue du bienfait des tests et consent à réorganiser son travail pour en écrire. manque de temps > isoler un senior pour coder les premiers tests automatisés Le coach «protège» son équipe pour qu'elle évalue le travail à faire en prenant en compte le temps d'écriture des tests.
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Mise en place TDD Chez Eyeka pour simplifier User Stories découpées en tâches Tâches > Tests unitaires User Stories > Tests d'acceptance Au bout de 3 mois, 47% de couverture de tests. Au bout de 6 mois, 70% de couverture de tests. A terme > 80%.
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Intégration continue Choisir le bon outil : un outil SIMPLE (cruisecontrol) Mettre en place des règles d or L équipe reste solidaire Priorité au build => pas d autre action tant que le build ne passe pas Mise en place
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Petites livraisons Mise en place Déploiement automatisé avec Capistrano (+recipes) Utilisation des migrations (spécifique à Ror mais indispensables à un bon déploiement) Des outils pour déployer rapidement sur 3 environnements Release hebdomadaire
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
Métaphores Lightbox, album, groupe, tag IPTC
Pair programming Mise en place
Pair programming Mise en place De la conception à quatre mains / 2 cerveaux Du code de meilleure qualité => davantage de tests passés sur du code conçu à 2 (http://www.cs.utah.edu/~lwilliam/papers/ieeesoftware.pdf) Des efforts plus soutenus : chaque binôme encourage l autre à être meilleur et à pousser le code jusqu à la perfection (on renonce à l effort plus facilement quand on est seul) Les limites : tous ne sont pas prêts à pair programmer car prône le retour à l humilité : face à l autre il faut accepter de montrer que l on peut ne pas tout savoir => appliqué uniquement avec les volontaires
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable
13 pratiques 1. Client sur site 2. Planning game 3. Collective code ownership 4. Convention over configuration 5. Tests de recette 6. TDD et tests unitaires 7. Intégration continue 8. Petites livraisons 9. Conception simple 10. Utilisation de métaphores 11. Pair programming 12. Refactoring 13. Rythme soutenable : failed!
Tenir le rythme Mise en place Un déploiement par semaine : difficile à tenir! Mais tenir le rythme est bénéfique: 1. un repère pour toute l'entreprise 2. un repère pour l équipe de dev 3. Permet de corriger beaucoup de choses et de ne pas traîner trop longtemps des bugs 4. Nous a obligé surtout à faire des choses simples! Eviter au maximum de reporter une livraison
Du scrum aussi : l équipe ensemble!
L équipe ensemble Mise en place Pour communiquer!!! Pour l espace informatif (un seul endroit centralisé) Pour des stand-ups informels et irréguliers Et surtout pour les imprévus et les crises
Les rituels! Mise en place La satisfaction (client et/ou équipe) et le plaisir de travailler ensemble sont des notions centrales à l agilité. Instaurer un rituel lors de chaque livraison, fêter les publications même difficiles, débriefer systématiquement après les publications désastreuses Communiquer vers le reste du monde pour que le travail effectué soit reconnu : formations mkt / démos / newsletters / soirées / etc. C est la partie la plus agréable, pourquoi s en priver?
Refactoring réécriture?
au bout de quelques mois Enfin on parle de refactoring! Enfin on nettoie le code (merci les tests)! Enfin on a le temps pour : suivre les évolutions du framework, faire de la veille technologique (git, merb, etc.)
En marque blanche on a tellement refactoré qu une nouvelle application allégée «spéciale marque blanche» est née
Les freins
Freins Les freins rencontrés Peu de support de la hiérarchie, une adoption sur preuves. Les tests : «les tests vont nous faire perdre du temps». Notre constat : Ils servent à l intégration continue Ils contiennent l intelligence métier de l application Ils permettent de se plonger plus facilement dans le code Ils servent de documentation Ils permettent de former les nouveaux Plus on en écrit, plus ça va vite
Les freins à la mise en oeuvre d XP Mise en place Le pair programming : «je paie 2 personnes pour faire la même chose?» Le compromis chez Eyeka : une personne (le coach) pair programme avec à peu près tout le monde : elle garde la vision globale du projet. Adoption d XP plus difficile sur du code vieillissant
Les freins Les freins L'intégration continue : peut être vécue comme une contrainte inutile. Or elle donne de bons indicateurs (activité / vélocité / refactoring) Ne pas se reposer uniquement sur elle pour déployer Elle est garante du fait que ce qui fonctionnait bien hier doit bien fonctionner aujourd'hui.
Les freins Les freins psychologiques La peur. Pour certains il a été difficile d accepter de «perdre le pouvoir» (CCO) Change la physionomie d une équipe : plus de spécialistes, plus de rétention d information, plus de querelles de chapelles Respect d'une discipline collective : ne s applique pas à tous les profils
Ce qui n a PAS été mis en place Code reviews Rythme de travail soutenable Daily stand-up (mais un Twice-a-week meeting) Peu de conventions de code car Ror en établit déjà beaucoup Pas de vrai TDD sauf pour 2 développeurs, les tests étaient écrits après coup
Bénéfices
Bénéfices Les bénéfices pour Eyeka la souplesse!! changement de business model tous les trimestres! communauté de promateurs vente de contenus (à la fotolia / istock) place de marché B2B place de marché B2C : relais des marques auprès de la communauté
Bénéfices Les bénéfices pour Eyeka Le pair programming comme formation continue A évité le cloisonnement > faire tourner les paires A permis de former beaucoup de «nouveaux» et de diffuser les compétences des «anciens» (paires complémentaires) A permis de promouvoir l écriture des tests (plus facile à deux!) A permis dans une petite équipe de maintenir un rythme soutenu de travail dans un contexte tendu «start-up»
Bénéfices Les bénéfices pour Eyeka TDD + Pair Programming = Coût supérieur à un seul programmeur MAIS le code est de meilleure qualité Moins de coûts de maintenance
Bénéfices Les bénéfices pour Eyeka la réactivité : le client étant au coeur du projet, on peut réajuster rapidement. Parfois trop rapidement... Maîtriser le code jetable
Bénéfices Les bénéfices pour Eyeka des coûts "constants" : une fois évaluée la vélocité d'une équipe, on sait dire avec précision ce qui peut être fait et pour quand. Et donc à quel coût. Sur des cycles courts (une semaine) marge d erreur très faible
Bénéfices Les bénéfices pour Eyeka Des développeurs heureux Le timing est connu (semaine) Le travail à faire est précis (user stories) Plus de polyvalence Meilleure connaissance de l application Un product owner heureux
Merci de votre attention Des questions?