Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare une entreprise Scribd logo

CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?

•
•
F
florentpellet

Slides de la session de mars du CARA Lyon. Animé par Charles Bouttaz et Nicolas Ruffel. http://www.meetup.com/fr-FR/CARA-Lyon/events/228952996/

Diaporamas connexes

Les pratiques Scrum
Les pratiques ScrumLes pratiques Scrum
Les pratiques Scrum
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
 
Methodologie projet
Methodologie projet Methodologie projet
Methodologie projet
 
1  sur  20
Télécharger pour lire hors ligne
Software Craftsmanship : le chaînon manquant de l’agilité ? @CharlesBouttaz @NicoRuffel Photo John Alexander Calderon
Méthodes Agiles Management de projet ● Scrum ● Crystal Clear ● SAFe ● ... Développement ● Agile Unified Process - Disciplined Agile Delivery ● eXtreme Programming ● ...
Les manifestes AGILE les individus & leurs interactions > les processus et les outils collaboration avec les clients > négociation contractuelle adaptation au changement > le suivi d’un plan des logiciels opérationnels > documentation exhaustive CRAFTSMANSHIP communauté de professionnels + des partenariats productifs + l'ajout constant de la valeur + des logiciels bien conçus +
12 Principes 1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. 2. 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. 3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. 4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. 5. 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. 6. 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. 7. Un logiciel opérationnel est la principale mesure d’avancement. 8. 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. 9. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. 10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. 11. Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. 12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
Des pratiques, des techniques ! ● Clean Code ● Simple Design ● Refactoring ● SOLID ● Pair programming ● Integration continue ● DevOps ● Prog fonctionnelle ● Root cause analysis ● Conception Objet ● Livraison continue ● Mob programming ● TDD ● ATDD ● BDD ● DDD
Les pratiques ne sont que des outils ! ● Un outil est efficace dans dans un contexte donné ● “LA” solution parfaite n’existe pas ● Pragmatisme : “capacité à s’adapter aux contraintes de la réalité” ● Les valeurs & principes comme guide
Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
Tests automatisés, Test First, Test Driven Development TDD: 1/ écrire un test qui échoue pour ma fonctionnalité 2/ écrire l’implementation minimale qui fait passer le test 3/ refactoring -> GOTO 1 Intérêt ● Code testable ● Meilleur design* ● Documentation FEEDBACK
TDD façe a la dure réalité ● C’est difficile ! ○ Code Legacy hostile ○ Besoin de bonnes notions de design ● Les mauvais tests coûtent cher ○ pas expressifs, trop longs, trop liés a l’implémentation ● Les tests unitaires ne sont pas suffisants ● Difficile de “vendre“ le test unitaire COURAGE
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.
Intégration continue Chaque tâche de développement terminée est automatiquement compilée, testée et intégrée à l’application Les plus... ● Détection rapide des problèmes d'intégration ● La version courante est toujours disponible ● Tous les tests sont repassés à chaque tâche terminée FEEDBACK
La dure réalité de l’intégration continue Nouvelle organisation du travail Coût de l'automatisation ● Plateforme d’intégration ● Lien entre SCM et la plateforme ● Déploiement en un clic Construction de la suite de tests ● 10 minutes build ● Rapidité et fiabilité du feedback COURAGE
Accueillez positivement les changements de besoins, [...] pour donner un avantage compétitif au client. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. La simplicité [...] est essentielle.
Architecture “Big Design Up Front” : Avant le début du projet l’architecte prend toutes les décisions d’architecture et des technologies a utiliser. Ensuite les développeurs implémentent la vision de l’architecte. BDUF + Agile = Problèmes ● Nécessite des besoins fonctionnels figés ● Choix et décisions les plus impactants au pire moment ● Les erreurs coûtent cher
Design émergent Strict minimum d’architecture avant de commencer (macro & micro). Faire émerger le design au cours du dévelopement par des refactorings successifs. Refactoring = améliorer le code. ex: nommage, factorisation, cohésion, couplage, etc. Intérêt ● Maintenabilité ● Extensibilité ● Prendre les décisions quand on a le plus d’information SIMPLICITÉ
Design émergent face a la dure réalité ● Ne veut pas dire qu’on ne fait plus d’architecture ! ● Ne veut pas dire qu’on refait toute l’application a chaque feature ! ● Refactoring difficile à “vendre” : temps qui n’apporte pas de nouvelle feature COURAGE
Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. 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.
Travail en binôme Les tâches de conception / programmation sont abordées à deux FEEDBACK COMMUNICATION ● Transfert de connaissance ● Le développeur n’est pas seul face aux problèmes rencontrés Intérêt ● Meilleur design
La vérité sur le travail en binôme ● Difficile à vendre ● Organisation du travail si travail en binôme à la demande ● Choc culturel ● Equipe répartie / multi sites RESPECT
Être agile plutôt que faire de l’agile ! Les valeurs de eXtreme Programming ou les manifestes sont de bons refuges FEEDBACK COURAGE COMMUNICATION SIMPLICITÉ RESPECT

Contenu connexe

CARA - Software Craftsmanship : le chaînon manquant de l’agilité ?

  • 1. Software Craftsmanship : le chaînon manquant de l’agilité ? @CharlesBouttaz @NicoRuffel Photo John Alexander Calderon
  • 2. Méthodes Agiles Management de projet ● Scrum ● Crystal Clear ● SAFe ● ... Développement ● Agile Unified Process - Disciplined Agile Delivery ● eXtreme Programming ● ...
  • 3. Les manifestes AGILE les individus & leurs interactions > les processus et les outils collaboration avec les clients > négociation contractuelle adaptation au changement > le suivi d’un plan des logiciels opérationnels > documentation exhaustive CRAFTSMANSHIP communauté de professionnels + des partenariats productifs + l'ajout constant de la valeur + des logiciels bien conçus +
  • 4. 12 Principes 1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. 2. 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. 3. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. 4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. 5. 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. 6. 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. 7. Un logiciel opérationnel est la principale mesure d’avancement. 8. 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. 9. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. 10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. 11. Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. 12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
  • 5. Des pratiques, des techniques ! ● Clean Code ● Simple Design ● Refactoring ● SOLID ● Pair programming ● Integration continue ● DevOps ● Prog fonctionnelle ● Root cause analysis ● Conception Objet ● Livraison continue ● Mob programming ● TDD ● ATDD ● BDD ● DDD
  • 6. Les pratiques ne sont que des outils ! ● Un outil est efficace dans dans un contexte donné ● “LA” solution parfaite n’existe pas ● Pragmatisme : “capacité à s’adapter aux contraintes de la réalité” ● Les valeurs & principes comme guide
  • 7. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • 8. Tests automatisés, Test First, Test Driven Development TDD: 1/ écrire un test qui échoue pour ma fonctionnalité 2/ écrire l’implementation minimale qui fait passer le test 3/ refactoring -> GOTO 1 Intérêt ● Code testable ● Meilleur design* ● Documentation FEEDBACK
  • 9. TDD façe a la dure réalité ● C’est difficile ! ○ Code Legacy hostile ○ Besoin de bonnes notions de design ● Les mauvais tests coûtent cher ○ pas expressifs, trop longs, trop liés a l’implémentation ● Les tests unitaires ne sont pas suffisants ● Difficile de “vendre“ le test unitaire COURAGE
  • 10. 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.
  • 11. Intégration continue Chaque tâche de développement terminée est automatiquement compilée, testée et intégrée à l’application Les plus... ● Détection rapide des problèmes d'intégration ● La version courante est toujours disponible ● Tous les tests sont repassés à chaque tâche terminée FEEDBACK
  • 12. La dure réalité de l’intégration continue Nouvelle organisation du travail Coût de l'automatisation ● Plateforme d’intégration ● Lien entre SCM et la plateforme ● Déploiement en un clic Construction de la suite de tests ● 10 minutes build ● Rapidité et fiabilité du feedback COURAGE
  • 13. Accueillez positivement les changements de besoins, [...] pour donner un avantage compétitif au client. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. La simplicité [...] est essentielle.
  • 14. Architecture “Big Design Up Front” : Avant le début du projet l’architecte prend toutes les décisions d’architecture et des technologies a utiliser. Ensuite les développeurs implémentent la vision de l’architecte. BDUF + Agile = Problèmes ● Nécessite des besoins fonctionnels figés ● Choix et décisions les plus impactants au pire moment ● Les erreurs coûtent cher
  • 15. Design émergent Strict minimum d’architecture avant de commencer (macro & micro). Faire émerger le design au cours du dévelopement par des refactorings successifs. Refactoring = améliorer le code. ex: nommage, factorisation, cohésion, couplage, etc. Intérêt ● Maintenabilité ● Extensibilité ● Prendre les décisions quand on a le plus d’information SIMPLICITÉ
  • 16. Design émergent face a la dure réalité ● Ne veut pas dire qu’on ne fait plus d’architecture ! ● Ne veut pas dire qu’on refait toute l’application a chaque feature ! ● Refactoring difficile à “vendre” : temps qui n’apporte pas de nouvelle feature COURAGE
  • 17. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. 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.
  • 18. Travail en binôme Les tâches de conception / programmation sont abordées à deux FEEDBACK COMMUNICATION ● Transfert de connaissance ● Le développeur n’est pas seul face aux problèmes rencontrés Intérêt ● Meilleur design
  • 19. La vérité sur le travail en binôme ● Difficile à vendre ● Organisation du travail si travail en binôme à la demande ● Choc culturel ● Equipe répartie / multi sites RESPECT
  • 20. Être agile plutôt que faire de l’agile ! Les valeurs de eXtreme Programming ou les manifestes sont de bons refuges FEEDBACK COURAGE COMMUNICATION SIMPLICITÉ RESPECT