Ingénierie agile : N’oubliez pas vos développeurs

Ingénierie agile,
outils et bonnes pratiques :
n'oubliez pas vos développeurs !
Xavier NOPRE – 08/11/2012

1

Qui suis-je ?
 Xavier NOPRE :
 Développeur logiciel Java & Web passionné depuis ~ 20 ans
 Pratique et partage l’agilité depuis 2007
 Indépendant. Missions :
 Développements sur mesure et accompagnement de projet
 En mode agile
 Coaching en agilité, Scrum, et ingénierie agile

@xnopre xnopre.blogspot.com

2 Ingénierie agile, outils et bonnes pratiques : n'oubliez pas vos développeurs - Xavier NOPRE

Et vous ?
 Agilité : novice ou expert ?
1. Je découvre, je n'y connais rien
2. Je connais les bases, je ne pratique pas encore
3. Je pratique un peu
4. Je pratique régulièrement (ex: un des rôles de Scrum)
5. Je maitrise, j'explique, je forme et accompagne

 Profils :
 Développeur
 Manager
 Formateur / coach
 Autre ?


Au programme

 Moi : (diapos)
 Introduction 3
 Rappels sur l'agilité 6
 Mise en situation et suivi des étapes
Exploration des outillages et méthodes 17

 Nous :
 Echanges autour de questions/réponses


Pourquoi cette session ?

 Issue de :
 Vécu personnel en tant que développeur
 Retour d'observations en tant que consultant
 Réflexions personnelles et échanges divers

  la technique est négligée dans les transitions agiles

 Contexte évoqué :
 Secteur du développement logiciel
 Ecosystème Java


Mes objectifs du jour
 Mettre en garde
 Pointer les difficultés (actuelles ou à venir)
 Lister une dizaine d'outils et pratiques
 Répondre à des attentes comme :
 "Je veux me lancer avec un maximum de chances"
 "Je sens que l'agilité ne fonctionne pas mais pourquoi ?"
 "C'est quoi TU, TDD, IoC, CI, … ?"
 "Comment tout cela peut-il s'articuler ?"
 "Par quoi je commence ?"
 "Combien ça coûte ?"


Ingénierie agile : késako ?
 "Ensemble de pratiques et d'outillages du génie logiciel
permettant de faire du développement agile" (XN)

 Tout ce qui est lié à la technique et aux pratiques :

 Tests unitaires
 TDD
 Intégration continue
 Industrialisation
 …


Situation
 Contexte :
 Nouveau projet et migration à l'agilité

 Scrum est en place :
Choix des acteurs PO et SM
Formations et coaching
Equipe stable et informée
Supports : backlogs, scrum board, …
Cérémonies : sprint planning, revue, démo, rétro

Mais … ça ne marche pas ! 


Analyse
 L'agilité : facile à comprendre, difficile à mettre en œuvre
 Scrum : n'est pas une "méthode" mais un cadre à adapter
 Très nombreuses raisons d'échec :
 Méthode trop adaptée = éloignement des valeurs et principes
 Manque d'informations (équipe et autour)
 Facteur humain
 Aspects techniques !

Gestion "agile" de projet : OK
Ingénierie agile ? …


Rappels > Cycle Scrum

Carnet Carnet
de produit d'itération
Vision
Itération
2 à 4 semaines

Produit partiel
1 jour Potentiellement
utilisable


Rappels > Cycle Scrum
• Méthodes séquentielle classique :

Specs Archi Développements Tests
BDD Serveur IHM
Temps
• Scrum :
Sprint 1 Sprint 2 Sprint 3 Sprint 4
 Specs  Specs  Specs  Specs
 Archi  Archi  Archi  Archi
t t t t ...
 Dév  Dév  Dév  Dév

 Tests  Tests  Tests  Tests

Temps


Rappels > Itératif et incrémental

http://www.infoq.com/news/2008/01/iterating-and-incrementing


Feuille de route
? *****
? *****
? *****
? *****
? *****
? *****
? *****
? *****
? *****
? *****
Effort

1/10
 "Equipe" = Travail collaboratif :
 Equipe pluri-disciplinaire
 Le code appartient à tous
 Partage du code
 Gestion centralisée
 Suivi des versions
Partage des sources *****

 Logiciel de gestion de version (Version Control System) :
 Subversion (SVN), ClearCase, CVS, …
 Git, Mercurial, …


2/10
 Code communs et partagé :
 Ecrit par les uns, lus par les autres
 Modifié par tous

Règles communes *****

 Règles communes de codage :
 Ecriture du code
 Formatage des sources
 Normes de nommages
 Outillage  Sonar


Feuille de route
Gestion de versions (SNV) *****
? *****
? *****
? *****
? *****
? *****
? *****
? *****
? *****
Effort

3/10
 Travail itératif :
 Déploiement pour tests intégration et fonctionnels
 Packaging et livraisons fréquentes

Industrialisation *****

 Outil de build pour industrialiser et automatiser :
 Ant + Ivy
 Maven :
 Gestion précise des dépendances et des versions
 Cycle de production intrinsèque
 Nombreux plugins
 Intégration IDE et autre outils


4/10
 Industrialisation et dépendances :
 "Artifacts" : livrables identifiés (groupId + artifactId + version)
 "repositories" : dépôts pour récupérer et déposer des livrables

Artifacts et repositories *****

 Gestionnaire de repositories :
 Artifactory, Nexus, Archiva
 Intérêts d'un dépôt interne :
 Proxy des dépôts publics internet
 Deploiement (Maven) de ses propres artifacts
 "Mavenisation" de livrables "non Maven"


Feuille de route
Industrialisation (Maven) *****
Repositories (Artifactory) *****
? *****
? *****
? *****
? *****
? *****
? *****
Effort

Précisions
 Développement "itératif" et "incrémental" :
 Développement "minimum" :
 Satisfaire les histoires de l'itération courante
 Prendre en compte la "vision" à long terme
 Suivre l'architecture "grande échelle" (modules, composants)
 Mais pas d'anticipations sur les besoins futurs
 Développements suivants :
 Satisfaire les histoires de la nouvelle itération
 Modifier le code existant pour qu'il puisse recevoir les nouveautés
 Implémenter les nouvelles fonctionnalités
Refactoring …


5/10
 Besoin de remanier son code (refactoring) :
 Renommages
 Extraction de méthodes, de classes
 Suppression de variables locales, de codes inutiles, …
 Prendre le moins de risque possibles …
IDE *****

 Un "bon" outil d'édition (IDE) :
 Eclipse, NetBeans, MS Visual Studio, IntelliJ IDEA, …
 Doit convenir à l'ensemble de l'équipe et correspondre aux
besoins
 Doit être bien configuré, pour tous les membres de l'équipe


Feuille de route
IDE (Eclipse) *****
? *****
? *****
? *****
? *****
? *****
Effort

6/10
 Refactoring :
 Ne pas casser l'existant , éviter les régressions
 Nouvelles fonctionnalités :
 Etre sûr de répondre au besoin
 Productivité et qualité :
 Tester rapidement des situations aux limites
Test unitaires *****

 Tests unitaires :
 Faire les "bons" tests
 Penser ROI !
 Voir les tests d'intégration et tests fonctionnels

7/10
 Tests unitaires :
 "Impossible sur mon code"
 Architecture et conception adaptée

Code testable *****

 Code testable :
 Principe "1 classe 1 rôle"  architecture très découpée
 Couplage lâche
 Injection de dépendances (outils ou manuelle)
 Interfaces & Mocks


8/10
 Tests unitaires : c'est dur !
 Mon code n'est pas testable
 Je ne sais pas comment tester

TDD *****

 TDD = "Test Driven Development"
 Principe = Ecrire les tests avant tout code de production
("Tests first")
 Plus facile d'écrire les tests avant que après le code de prod
 Permet de valider la compréhension du besoin
 Guide vers un code forcément "testable"


Feuille de route
IDE (Eclipse) *****
Tests unitaires *****
Code testable *****
TDD *****
? *****
? *****
Effort

9/10
 Les retours :
 "Tout ça n'est pas facile"
 "Par où commencer ?"
 "J'ai un bon exemple mais …"
Pair-programming *****

 Pair-programming :
 Principe : 2 développeurs devant 1 poste de travail
 Apports :
 Entraide, cohésion d'équipe
 Partage de connaissances, transferts de compétences
 Gain de productivité, qualité, meilleures solutions
 A bon escient, un peu chaque jour


10/10
 Constats et situations :
 Chaque développeur oublie de rejouer tous les tests unitaires
avant son commit : investissement  autant les jouer souvent
 Mon Product Owner veut un logiciel disponible très souvent
 Les intégrateurs me demandent d'automatiser le déploiement
en prod
Intégration continue * * * * *

 Intégration continue :
 Outils : Jenkins, Hudson, CruiseControl, Continuum, …
 Usages :
 Build (compile et tests) toutes les 15'
 Build complet nocturne
 Autres opérations sur déclenchements manuels

Feuille de route
IDE (Eclipse) *****
Tests unitaires *****
Code testable *****
TDD *****
Pair-programming *****
Intégration continue *****
Effort

Conclusion
 Agilité
 = révolution culturelle de l'entreprise
 = changements des rôles et de l'organisation
 = changements des habitudes et des relations

 Mais = aussi changements des pratiques et outillages techniques

 N'oubliez pas vos développeurs ! 


En résumé (technique)
Thème Conseil

Pratiques :
Règles communes, pair-programming, Simple  Ne pas hésiter !
coding-dojo, temps libre, …

Outillage :
IDE correct, configuré et maitrisé,
Bon ROI  Investir
gestionnaire de sources, industrialisation,
intégration continue, …

Tests :
Indispensable mais nécessite temps,
Unitaires, TDD, code testable, code
patience, formation, accompagnement
propre, architecture évolutive, …

Questions ?!


Ingénierie agile : N’oubliez pas vos développeurs

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (13)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Ingénierie agile : N’oubliez pas vos développeurs

Ähnlich wie Ingénierie agile : N’oubliez pas vos développeurs (20)