Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013

Agilistes :

n'oubliez pas la technique !

Xavier NOPRE – 25/04/2013

Agilistes : n'oubliez pas la technique ! - Xavier NOPRE 2

Préambule

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 ingénierie agile, agilité et Scrum


Qui suis-je ?

@xnopre xnopre.blogspot.com

Moi :

Introduction & mise en situation

Rappels sur l'agilité & Scrum

Analyse d'une situation

Exploration des outillages et méthodes

Conclusion

Nous :

Echanges autour de questions/réponses

Mix-IT 2013 : "Agilistes : n'oubliez pas la technique !" - Xavier NOPRE 5

Au programme


Introduction

Pourquoi cette session ?

Constat : la technique est négligée dans les transitions agiles

Pour qui ?

Tous profils et tous niveaux, sauf …

Mes objectifs :

Pointer les difficultés, mettre en garde, être pratique, répondre

à des interrogations, …

Contexte technique :

Développement logiciel & écosystème Java

7

Contexte pour cette session ?

Agilistes : n'oubliez pas la technique ! - Xavier NOPRE

"Ensemble de pratiques et d'outillages du génie logiciel

permettant de faire du développement agile" (X. N.)

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

Tests unitaires

TDD

Intégration continue

Industrialisation

…

8

"Ingénierie agile" : késako ?



Mise en situation

Contexte :

Nouveau projet

Migration vers 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

10

Situation : prenons une équipe …



Rappels sur l'agilité & Scrum

12

Rappels > Cycle Scrum

Vision

Carnet

de produit

Carnet

d'itération

Itération 2 à 4 semaines

1 jour

Produit partiel

Potentiellement

utilisable


13

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

BDD Serveur IHM


14

Rappels > Incrémental / Itératif

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


15

Rappels > Incrémental et Itératif

http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa



Retour sur la

Mise en situation

&

analyses

L'agilité :

facile à comprendre, difficile à mettre en œuvre

17

Analyse > Généralités

Scrum :

n'est pas une "méthode" mais un cadre à adapter


18

Analyse > Raisons d'échecs

Très nombreuses raisons d'échec :

Méthode trop adaptée = éloignement des valeurs et principes

Manque de formation / d'informations (équipe et autour)

Rôles mal définis ou mal respectés

Mauvaise collecte des besoins

Mauvaise gestion du "terminé"

Facteurs humains

etc …


Et les aspects techniques !

19

Analyse > Et côté développement

Une "vision" du produit mais pas de détails anticipés

Besoin d'une architecture évolutive (agile)

Plus techniques de specs techniques

Autonomie technique, initiative, responsabilisation

Toutes les 3 semaines, livraison d'un produit partiel et utilisable

Développement itératif, incrémental, et transversal

Plus de "responsable" qualité

Responsabilisation collective et individuelle

La qualité devient un problème de tous les jours

…


20

Analyse > Bilan

Gestion "agile" de projet OK

Ingénierie agile ? …



Outils et méthodes :

feuille de route

?

?

?

?

?

?

?

?

?

?

22

Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

Effort


x

"Equipe" = Travail collaboratif :

Equipe pluri-disciplinaire

Le code appartient à tous, Partage du code

Gestion centralisée, Suivi des versions

23

Partage des sources

Logiciel de gestion de version (Version Control System) :

Git, Mercurial, …

Subversion (SVN), ClearCase, CVS, …

* * * * *


1

Code communs et partagé :

Ecrit par les uns, lus par les autres

Modifié par tous

24

Règles communes

Règles communes de codage :

Ecriture du code, Formatage des sources, Normes de nommages

Configurations identiques des outils (IDE)

Outillage : Sonar peut aider à vérifier les règles communes

* * * * *


2

Travail itératif en cycle court :

Packaging et livraisons fréquentes

Voire déploiement continue

25

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

Industrialisation versionning & dépendances :

"Artifacts" : livrables identifiés (groupId + artifactId + version)

"repositories" : dépôts pour récupérer et déposer des livrables

26

Dépôts (repositories)

Gestionnaire de repositories :

Artifactory, Nexus, Archiva

Intérêts d'un dépôt interne :

Proxy des dépôts publics internet

Déploiement (Maven) de ses propres artifacts

"Mavenisation" de livrables "non Maven"

* * * * *


4

Développement "itératif" et "incrémental" :

Développement "minimum" pour l'itération courante :

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 lors des itérations suivantes :

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

27

Précisions

Refactoring …


Niveau 1 : "cosmétique" & lisibilité :

Renommages, extraction de méthodes

Suppression de variables locales, de codes inutiles, …

Niveau 2 : "package" & testabilité :

Extraction de classes et interfaces

Déplacement de méthodes, …

Niveau 3 : "architectural" & évolutivité agile

Modification des grands principes retenus

Révision des modules ou composants, …

Mix-IT 2013 : "Agilistes : n'oubliez pas la technique !" - Xavier NOPRE 28

Refactorings

Besoin de Refactoring, notamment niveau 1

Prendre le moins de risque possibles …

Respecter les Règles communes

29

Un "bon" 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

Refactoring, notamment niveau 2 :

Ne pas casser l'existant , éviter les régressions

Nouvelles fonctionnalités : sûr de répondre au besoin

Productivité et qualité : tester rapidement des situations

aux limites

30

Test unitaires

automatisables

Tests unitaires :

Faire les "bons" tests

Automatisables, indépendants,

rapides, …

* * * * *


6

Notes

Penser ROI !

Voir les tests d'intégration

et tests fonctionnels

Tests unitaires :

"Impossible sur mon code", "mon contexte ne le permet pas", …

Architecture et conception inadaptées

31

Code testable

Code testable :

Principe "1 classe 1 rôle" architecture très découpée

Couplage lâche

Injection de dépendances (par framework ou manuelle)

Interfaces & Mocks

Apprentissage long

* * * * *


7

Tests unitaires : c'est dur !

Difficile sur du code existant, difficile à écrire après le code de

production, code non testable, …

32

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

* * * * *


8

Tests : apprentissage difficile

Besoin de fédérer une équipe pluri-disciplinaire

33

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, à temps partiel, un peu chaque jour

* * * * *


9

Les tests ne sont pas rejoués systématiquement

Il faut livrer et packager souvent

Voire déployer fréquemment

34


Intégration continue :

Outils : Jenkins, Hudson, CruiseControl, Continuum, …

Usages (pour commencer) :

Build (compile et tests) toutes les 15'

Build complet nocturne

Autres opérations sur déclenchements manuels

* * * * *


10

Gestion de versions (Git)

Règles communes

Industrialisation (Maven)

Repositories (Artifactory)

IDE (Eclipse)

Tests unitaires

Code testable

TDD

Pair-programming


35

Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

Effort


36

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

Faible investissement et bon ROI

Investir

Tests :

Unitaires, TDD, code testable, code

propre, architecture évolutive, …

Indispensable mais nécessite temps,

patience, formation, accompagnement


Je n'ai pas parlé de …

Agilité

= révolution culturelle de l'entreprise

= changements des rôles et de l'organisation

= changements des habitudes et des relations humaines

Mais = aussi changements des pratiques et outillages techniques

37

Conclusion

N'oubliez pas la technique !


38

Questions ?!


Documents

Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013