agilistes : n'oubliez pas la technique ! - agile france - 23/05/2013

Agilistes :

n'oubliez pas la technique !

par Xavier NOPRE

23/05/2013 - 16h-17h - Salle 6

#AgileFrance

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

Préambule

Xavier NOPRE :

Développeur Agiliste Indépendant

Développeur :

Applications Java-WEB SaaS sur mesure

Clients finaux

Contrat agile

Formations, coaching, accompagnement :

Ingénierie agile, agilité, Scrum

Développement Java & WEB (HTML, CSS, JS, …)


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

ScrumMaster ou Product Owner

Manager

Formateur / coach

Autre ?

4

Et vous ?

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

Moi :

Introduction

Rappels sur l'agilité & Scrum

Mise en situation et Analyse

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

Basée sur :

Mon expérience personnelle

Accompagnement d'équipes

Constat :

La technique est négligée dans les transitions agiles

Contexte technique :

Développement logiciel & écosystème Java

Sur mon blog : "Développement logiciel agile : informations sur l'outillage" :

http://xnopre.blogspot.fr/2012/09/developpement-logiciel-agile_13.html

7

Contexte pour cette session ?


coach

dev







"Ensemble de pratiques et d'outillages

dans l'édition logicielle

permettant de faire du développement agile"

Xavier NOPRE

8

"Ingénierie agile" : késako ?



Rappels sur l'agilité & Scrum

10

Rappels > Cycle Scrum

Vision

Carnet

de produit

Carnet

d'itération

Itération 2 à 4 semaines

1 jour

Produit partiel

Potentiellement

utilisable


!!! !!!

!!!

11

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


12

Rappels > Incrémental / Itératif 1/2

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


13

Rappels > Incrémental et Itératif 2/2

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



Mise en situation

&

analyses

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

15

Situation : prenons une équipe …


L'agilité :

facile à comprendre, difficile à mettre en œuvre

16

Analyse > Généralités

Scrum :

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


17

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 …

etc …


Et les aspects techniques !

18

Analyse > Et côté développement 1/3

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

Plus de cahier des charges (initial et fixe)

Plus de specs détaillées

Ne pas anticiper les "détails"

Besoin d'une conception évolutive (agile)

Faire émerger une architecture

Pas de régressions

…


19


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

utilisable

Développement incrémental :

on avance par petits blocs fonctionnels

Développement itératif :

un bloc fonctionnel est finalisé sur plusieurs itérations

Développement transversal

quotidiennement, on implémente sur toutes les couches

Livraisons fréquentes

Packaging facile

…


20


Equipe auto-organisée et pluri-disciplinaire

Plus de chef,

"Plus de responsable"

Plus de spécialistes (technos, couches, qualité, tests, …)

Autonomie technique & initiatives

Responsabilisation collective et individuelle

Choix techniques et technologiques

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

…


21

Analyse > Bilan

Gestion "agile" de projet OK

Ingénierie agile ? …



Outils et méthodes :

feuille de route

Que puis-je apporter à mon équipe "qui n'a rien" ?

Choix d'une dizaine d'outils et pratiques "de base"


Feuille de route : objectif

coach dev

?

?

?

?

?

?

?

?

?

?

24

Feuille de route : format

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

Effort


x

"Equipe" = Travail collaboratif :

Equipe pluri-disciplinaire

Le code appartient à tous, Partage du code

Gestion centralisée, Suivi des versions

25

Partage des sources

Logiciel de gestion de version (Version Control System) :

Git, Mercurial, …

Subversion (SVN), ClearCase, CVS, …

* * * * *


1

coach dev

Code communs et partagé :

Ecrit par les uns, lus par les autres

Modifié par tous

26

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

coach dev

Travail itératif en cycle court :

Packaging et livraisons fréquentes

Voire déploiement continue

27

Industrialisation/

Automatisation

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

coach dev

Industrialisation versionning & dépendances :

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

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

28

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

coach dev


Pause "précisions"

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

30

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


Refactorings


On reprend …

Besoin de Refactoring, notamment niveau 1

Prendre le moins de risque possibles …

Respecter les Règles communes

33

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 ( IDE unique …)

Doit être bien configuré, pour tous les membres de l'équipe

* * * * *


5

coach dev

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

34

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

coach dev

Tests unitaires :

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

Architecture et conception inadaptées

35

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

coach dev

Tests unitaires : c'est dur !

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

production, code non testable, …

36

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

coach dev

Tests : apprentissage difficile

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

37

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

coach dev

Les tests ne sont pas rejoués systématiquement

Il faut livrer et packager souvent

Voire déployer fréquemment

38

Intégration continue

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

coach dev

Gestion de versions (Git)

Règles communes

Industrialisation (Maven)

Repositories (Artifactory)

IDE (Eclipse)

Tests unitaires

Code testable

TDD

Pair-programming

Intégration continue

39

Feuille de route

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

* * * * *

Effort


40

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


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

41

Conclusion

N'oubliez pas la technique !


Je n'ai pas parlé de :

Revue de code

Coding-dojo (Kata et Randori)

Frameworks et Librairies

Temps libre R&D

Prototype vs Produit

Autres langages et autres éco-système (ex : JavaScript)

Bug tracker

Réduction dette technique

…

42

Et encore …


43

Questions ?!


agilistes : n'oubliez pas la technique ! - agile france - 23/05/2013

Technology