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

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

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

Qui suis-je ?

@xnopre xnopre.blogspot.com

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 ?


Et vous ?

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


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


Pourquoi cette session ?

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 ?"


Mes objectifs du jour

"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

…


Ingénierie agile : késako ?

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


Situation

Mais … ça ne marche pas !

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 !


Analyse

Gestion "agile" de projet : OK

Ingénierie agile ? …


Rappels > Cycle Scrum

Vision

Carnet

de produit

Carnet

d'itération

Itération 2 à 4 semaines

1 jour

Produit partiel

Potentiellement

utilisable


Rappels > Cycle Scrum

Specs Archi Développements Tests

• Méthodes séquentielle classique :

• Scrum :

Sprint 1

Specs

Archi

Dévt

Tests

Sprint 2

Specs

Archi

Dévt

Tests

Sprint 3

Specs

Archi

Dévt

Tests

Sprint 4

Specs

Archi

Dévt

Tests

...

Temps

Temps

BDD Serveur IHM


Rappels > Itératif et incrémental

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

?

?

?

?

?

?

?

?

?

?


Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * * Effort

"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, …

* * * * *

1/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

* * * * *

2/10

Gestion de versions (SNV)

Règles communes

?

?

?

?

?

?

?

?


Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * * Effort

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

* * * * *

3/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"

* * * * *

4/10


Règles communes

Industrialisation (Maven)

Repositories (Artifactory)

?

?

?

?

?

?


Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * * Effort

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


Précisions

Refactoring …

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

* * * * *

5/10


Règles communes



IDE (Eclipse)

?

?

?

?

?


Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * * Effort

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

* * * * *

6/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

* * * * *

7/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"

* * * * *

8/10


Règles communes



IDE (Eclipse)

Tests unitaires

Code testable

TDD

?

?


Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * * Effort

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

* * * * *

9/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 :

Outils : Jenkins, Hudson, CruiseControl, Continuum, …

Usages :

Build (compile et tests) toutes les 15'

Build complet nocturne

Autres opérations sur déclenchements manuels

* * * * *

10/10


Règles communes



IDE (Eclipse)

Tests unitaires

Code testable

TDD

Pair-programming



Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * * Effort

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


Conclusion

N'oubliez pas vos développeurs !


En résumé (technique)

Thème Conseil

Pratiques :

Règles communes, pair-programming,

coding-dojo, temps libre, …

Simple Ne pas hésiter !

Outillage :

IDE correct, configuré et maitrisé,

gestionnaire de sources, industrialisation,

intégration continue, …

Bon ROI Investir

Tests :

Unitaires, TDD, code testable, code

propre, architecture évolutive, …

Indispensable mais nécessite temps,

patience, formation, accompagnement


Questions ?!

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

Technology

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