Agilité, Tests Et Industrialisation

Agilité, Tests et industrialisationoù comment maîtriser votre business
Olivier Hoareau – PHPPRO
23 Septembre 2009
www.phppro.fr

A FAIRE
EN COURS
FINI
Tour de
Table
Intro
5’
10’
Equipe
Agile
UdD
30’
40’
What’s
Next ?
?
5’
30’

Qui suis-je ?
Animateur Méthodologies Agiles
Animateur Equipes Technique
Expert Certifié PHP 5
Consultant Indépendant (PHPPRO)
10 ans de développement Web/PHP/OSS
5 ans de projets Grands Comptes
2 ans de Coaching Agile
1 an de vie sur Bordeaux (Paris, Brussels…)
Bloggeur / AFUP / Conférencier

qui êtes-vous ?

A FAIRE
EN COURS
FINI
Tour de
Table
Intro
5’
10’
Equipe
Agile
UdD
30’
40’
What’s
Next ?
?
5’
30’

Vous, aujourd’hui…

Vous êtes plutôt…« On s’en sort déjà, ca marche »
Vous vendez (des applications)
Vous savez répondre à la plupart des besoins de vos clients
Vous avez créé vos processus (développement, livraison)
Vous avez un catalogue produits
Vous avez des compétences internes
…
Chez nous, ça marche !

ou alors…« On sait que l’on peut mieux faire »
Vous vendez (trop) cher
Vous ne gagnez pas tous les appels d’offres
Vous perdez de l’énergie
Vous perdez ou manquez de compétences
Vous avez des applications « legacy » et/ou « zombies »
Le mot « manuel » fait encore partie de votre quotidien
…
Oui, il y a peut être un peu de ça ?

Dans tous les cas…« La dure réalité de notre quotidien »
Les besoins du client changent
Les délais sont toujours trop court
Les développeurs n’en font toujours qu’à leur tête
Les acteurs projets ne parlent pas le même langage
Il faut prévoir une phase de recette dans le planning
Nécessité de faire des compromis pour gagner de l’argent
On perd du temps dans la rédaction / lecture des documents
…
C’est notre quotidien !

Prise de conscience:« Il faut améliorer nos pratiques pour maîtrisernos coûts, nos délais et la satisfaction client »
Pour ne paslivrer en retard
Pour ne pasperdre du temps en maintenance
Pour ne pasredévelopper toute l’appli
Pour cadrer nos développeurs
Pour faire et maintenir notre marge
Pour pouvoir planifier
Pour être compétitif
Oui !

Barrières:« Maîtriser, oui mais… »
Comment libérer l’innovation / l’imagination ?
Comment prendre en compte les compétences de chacun ?
Comment ne pas imposer ?
Comment contrôler ?
Comment éviter de perdre du temps ?
Comment ne pas tout remettre en question ?
Par où commencer ?
Comment ?

A FAIRE
EN COURS
FINI
Tour de
Table
Intro
5’
10’
Equipe
Agile
UdD
30’
40’
What’s
Next ?
?
5’
30’

Il était une fois une équipe …

qui acquis des valeurs fondamentales
Equipe
Application / Logiciel
Collaboration
Acceptation du changement
Source : Wikipédia, http://fr.wikipedia.org/wiki/M%C3%A9thode_agile

qui adhéra à la philosophie « agile »
Servir avant tout la satisfaction client
Livrer une application qui fonctionne / est utile
Travailler ensemble
Privilégiez les interactions entre les personnes
Collaborer plutôt que contractualiser
S’adapter constamment plutôt que suivre un plan
Livrer régulièrement, un logiciel n’est jamais fini
Faire (toujours le plus) simple
S’améliorer constamment (feedback)
Cultiver la motivation
Source : Agile Manifesto, http://agilemanifesto.org/

qui utilisa le vocabulaire « agile »
Itération / Sprint
Scrum / XP
Vélocité / Valeur
Backlog
Post-it
User Story
Planning game
Bilan / Retrospective
Stand Up Meeting / Daily Scrum
P.O : Product Owner/ S.M : Scrum Master
Utilisateur(s) / Client
Développeur(s)

qui mis en place une organisation « agile »
Les UTILISATEURS
Les DEVELOPPEURS
Le PRODUCT OWNER
Le SCRUM MASTER
Images empreintées à http://borisgloger.com

qui organisa son tempsen itérations fixes (ex: 2 semaines)
J0
Préparation contenu itération / Tableau des Posts-its
J1 … J10
Production des posts-its
J10
Démo
Bilan / Retrospective / Feedback
Pendant l’itération (planifié par post-it si possible)
Livraison / Déploiement de l’itération précédente
Atelier de conception improvisé
Traitements des bugs de prod (mode imprévu)

qui mis en œuvre des pratiques agiles*
Stand Up Meeting (10min: quotidien, même heure, debout)
Engagement / Responsabilisation
TDD : Test DrivenDevelopment
Pair Programming
« Commits » sur barre verte
Refactoring
Intégration Continue
Design Patterns
TDR : Test DrivenRequirements
LEAN : Amélioration des Processus
Dojo
…
* Pas forcément toutes les pratiques, et progressivement

qui s’auto-contrôla
Contrôles régulier des pratiques
BurndownChart Planning
Mise en place de règles Bilan  feedback  nouvelles règles
Couverture de Tests  Robustesse
Vérification du respect des conventions  Maintenabilité
Dojo et Revue de code  Evolutivité / Modularité / Réutilisabilité (Archi.)
…
Contrôles automatisés de l’application
Taille du code / répartition du code
Tests Unitaires
Tests fonctionnels
Tests de non-régressions
Tests d’intégrations
Tests d’IHM
…
Métriques

Source : ScrumAlliance, http://www.frenchsug.org
… avec des BurndownCharts

Source : http://www.typeoneerror.com
… en mesurant sa couverture de code

… en réalisant ses Bilans / Rétrospectives
Pointspositifs
Problèmesrencontrés
Actionsbénéfiques
à renouveler
Idéesà tester

qui s’outilla
Capitalisation Wiki (ex: Confluence)
Environnement de développement (ex: Zend Studio)
Gestion de sources (ex: Subversion)
Réutilisation / Framework (ex: Zend Framework)
Tests Unitaires (ex: PHPUnit)
Packaging / Automatisation (ex: Phing / PEAR)
Intégration Continue (ex: Hudson)
Tests Fonctionnels Exécutables (ex: Fitnesse)
Tests Graphiques (ex: Selenium)
Mesure du code (ex: PHPLoc, PHPCpd…)
Suivi évolutions / bugs (ex: JIRA)
…

qui améliora son architecture
Programmation Objet
Couche Services
Multi-contextes (web, batch, tests, …)
Design Patterns
Web services & REST
Découpage en modules
Testabilité (« Bouchonnabilité »)
Multi-base de données / BdDNon Relationnelles
Librairie technique interne
Librairie fonctionnelle interne
…

qui fit émerger etrespecta ses conventions
Sociales
Horaires
Engagements
Fichiers / Classes / Méthodes
Nommage
Encodage / Taille
Architecture
Grands Principes
Couches
Tests
…
« L’excellence attire l’excellence »

qui livra régulièrement des évolutions
T0
T0+1mois
T0+2mois
T0+3mois
T0+4mois
Livraison
Livraison
Livraison
Livraison
It.#1
It.#2
It.#5
It.#8
It.#0
It.#3
It.#4
It.#6
It.#7

inspiré d’une histoireSvraieS :
6

Ils « vivent » l’« agile »
1 Grand Compte Service Public – Projet de 25 dév. / 50 pers.
1 Acteur 1% Logement –Projet de 15 dév. / 30 pers.
1 Grand Compte Telecom – Projet de 4 dév. / 8 pers.
1 Startup Tchat Virtuel – Projet de 3 dév. / 6 pers.
1 Grand Compte Service Public – Projet de 4 dév. / 7 pers.
1 SSII Suisse – Projet de 1 dév. / 2 pers.
et vous ?

A FAIRE
EN COURS
FINI
Tour de
Table
Intro
5’
10’
Equipe
Agile
UdD
30’
40’
What’s
Next ?
?
5’
30’

Usine de Développement :Industrialisation PHP

Ma définition de l’industrialisation
INDUSTRIALISATION
MONO
MULTI
MA PRATIQUE
OUTILS
TECHNIQUES
PRATIQUES

Une vraie usine professionnelle
Capitalisation Wiki  Confluence
Environnement de développement  Eclipse,Zend Studio
Gestion de sources Subversion, Git
Réutilisation / Framework  Zend Framework, Symfony
Tests Unitaires PHPUnit
Packaging / Automatisation  Phing/ PEAR
Intégration Continue  Hudson, PHPUnderControl
Tests Fonctionnels Exécutables  Fitnesse
Tests Graphiques  Selenium
Mesure du code  PHPLoc, PHPCpd, Pdepend, CodeSniffer
Suivi évolutions / bugs  JIRA
…

Paramètres
T.U
Ce qui teste
LOGIQUE
Ce qui est testé
ENV / SYS
Ce qui interagie
Retours
Exceptions
Qu’est-ce qu’un test unitaire ?
Vérifie que l’envoie de
la liste des lettres
en recommandé
Electronique d’hier par
email fonctionne
Demande la liste des lettres
Recommandé à la BDD,
Construit et déclenche /
commande l’envoie d’email
Envoie des emails via le réseau
Exécute une requête sur la BDD
Lit / Ecrit dans des fichiers
…

TDD : Test DrivenDevelopment
« Test First » : coder le test avant le code
Construire / Designer le code « au fil de l’eau »
TDD : 3 fois plus de temps à développer, 10 fois moins de problème à l’arrivée.
Automatisation des T.U : base de l’usine de développement

Pourquoi TDD ?
Tests oublié si à la fin
Fort impact positif sur le Design (Architecture)
M’oblige à développer le strict nécessaire
Plus robuste
Tests automatisables  intégration continue
M’oblige à être modulaire pour bouchonner
« Je n’ai plus peur de toucher le code »
« Je n’ai plus peur de supprimer du code »
…

Exemple TDD / PHPUnit
« Développer une méthode de récupération de la liste des commandes d’une date par webservice »

Je développe le test du cas simple…

…ensuite, le code pour faire passer le test

Je développe le test du cas d’erreur…
Test
… je refactore et développe le code
Code

TDD : une approche systématique
Test du cas nominal
Code du cas nominal
Test du cas d’erreur
Code du cas d’erreur
Test du / des cas aux limites
Code du / des cas aux limites
= Robustesse, Bouchon, Simplicité et Modularité

Testabilité du code PHP
Natif
PHP
Support
PHP
Web

Qu’est-ce qu’un test fonctionnel ?
Un test écrit dans un vocabulaire fonctionnel
Un test écrit de préférence par un fonctionnel
Un test décrivant une fonctionnalité
Un test non contraint, en apparence, par la technique
Un test lisible sans connaissances techniques
Un test de non regréssion des fonctionnalités
outils T.D.R = Test DRIVEN REQUIREMENTS

T.D.R : Quels avantages ?
Simple + Efficace : Wiki
Remplacement possible du CdC (Word  Wiki)
Visibilité temps réel sur l’accompli / non accompli
Tests de non régression temps réel / à la demande
Vecteur de formalisation des évolutions
Outil de démo / bilan de fin d’itération
Vocabulaire universel, i.e. « compris par tous »
Outil pour tester le comportement de l’application
OUTIL de PREDILECTION DE LA « MOA AGILE »

T.D.R : Les outils du marché
Fitnesse Open Source / Free
GreenPepper  Open Source / Commercial
Voir, en BehaviourDrivenDevelopment (dérivé) :
Jbehave
RobotFramework
…

DEV
BUILD
DEPLOY
INTEG
S.I.
Une usine de développement typique
© OCTO Technology - Université du Système d’Information
47
1
3
2
integ.myapp.com
*/2 * * * *
SVN
dev.myapp.com
TDD
on-demand
on-commit
RUN
PROJECT
T.U
6
nightly
Tracker+Backlog
on-demand
TDR
Qualité
1,5,7
nightly
(pre-)prod.myapp.com
REPORT
4

Construire sa Librairie commune
« à n’utiliser qu’en cas de besoin »
Librairie de composants techniques et/ou fonctionnels
Surcouche du framework choisi (ex: ZF)
Cache la complexité / Paradigme « convention over configuration »
Minimal, évolutif, réactif, en constante amélioration
Rationalisation arborescence fichiers
Gérer le tranverse : boostraps, conf, bdd…
Capitalisation / Factorisation
Si pas présent dans la lib, les équipes le développent
Contribuez à la lib via le SVN
Maintenu / Modéré
Conventions et critères qualité pour donner l’exemple

Les 10 commandements du développeur
Faire simple ET propre
Développer en TDD : le test d’abord, le code ensuite
Committer si tous les tests de l’application sont en succès
Respecter des conventions de codage connus en dehors de l'entreprise
Développer 1 fois, Réutiliser plusieurs fois
Tester unitairement toutes les fonctionnalités du coeur de l'application
Utiliser les comparaisons de valeurs ET de types (===, !==)
Réaliser systématiquement des implémentation mocks (bouchons)
Ne pas dépasser plus de 80 lignes aérées et commentées pour une fonction/méthode
Banir « l’écran noir » de mon quotidien
Bonus: Always have fun !

des questions ?

A FAIRE
EN COURS
FINI
Tour de
Table
Intro
5’
10’
Equipe
Agile
UdD
30’
40’
What’s
Next ?
?
5’
30’

Vos perspectives…
Boss
Geek
Alignement
Réactivité
Flexibilité
Adaptabilité
Réutilisabilité
Visibilité
Automatisation
Collaboratif
Mono / Multi
…
Maîtrise du déploiement
Dév. Procédurale  Objet*
Capitalisation interne
Bouchons / Testabilité
Intégration Continue
Modernité
Modularité
Evolutivité
Maintenabilité
…
* optimisée / efficace

Par où commencer
Se faire coacher (méthodo / technique)
Pour être pris en main / conseillé
Pour ne pas perdre du temps
Pour passer les obstacles en étant conscient
Pour choisir et mettre en place les bons outils
Pour faire par vous-même dès le début
Choisir un projet-test (1ère implémentation)
Pour appréhender / se roder
Pour avoir un succès à raconter / un exemple à suivre

Pour démarrer, vous pensez à…
un projet ?
une équipe ?
une mission ?
un client ?
une période ?