de l'agilité individuelle à l'intelligence...

De l'agilité individuelleà

l'intelligence collective

Thierry Cros @ http://agile.thierrycros.net

Xp Day France 2,3 mai 2007

Agilité individuelle et Intelligence collective

2

De l'agilité individuelleà l'intelligence collective Agile, Extreme Programming

Le pouvoir de l'intelligence collective

Développement Responsable Nécessité de rendre compte

Ethique, Savoir-Être Exemple : les accords toltèques

« l'Agilité individuelle » Ressources personnelles, exemple : CARA

Dépend de ...

Dépend de ...

Dépend de ...


3

De l'agilité individuelleà l'intelligence collective

Agile, Extreme Programming


4

Je suis Client et je souhaite...

Une valeur ajoutée plus vite !

Une maîtrise des variables du projet : Périmètre Coût Planning Qualité


5

Être Agile« Répondre aux changements » contraint le plan

La collaboration Client / SIplus efficace que le « contrat »

Le produit opérationneloffre un meilleur feedback(% documentation complète)

Les personnes plus importantes que les méthodes et outils


6

Extreme Programming

ExtremeProgramming

Les cycles s'accélèrent

Structure des matériaux

Environnementsde développementperformants

Matériau souple(software)

Feedback rapide à tous les étageséquipe

complète

ConstitutionActeurs, rôles

Valeurs

Pratiques


7

Installer uneUnité de création

Unité de Création organisée

en itérations

Demandes(user stories)

Livrables testés=

Valeur Ajoutée

Feedback Contrôle

{ X jetons }


8

L'intelligence collective

Plusieurs cerveaux valent mieux qu'un seul Equipe complète Propriété collective Vocabulaire commun ...

Histoire d'un apprenti samouraï :« Petit scarabée », déplace ce gros rocher !


9


Agile, XP

dépend de

Développement Responsable


10

Le développement Responsable

L'Agile commence à être perçu comme potentiellement efficace (succès XP Days...) XP est perçu comme techniquement possible (refactoring...) L'accent est mis sur les pratiques, pas les valeurs et principes

Traduction (partielle) du papier « What is more Extreme than XP ? » de Kent Beck


11

Développement Responsable : définitionsRendre compte

Responsabilité : nécessité de rendre compte

Blâme* : détournement de la responsabilité

Intégrité :

congruence, harmonie entre croyances et pratiques

* Exemple : C'est pas ma faute, c'est le manager, le client...


12

Niveaux logiques de Dilts-Bateson

Environnement

Pratiques - Actions

Capacités - Savoir-Faire

Valeurs, Croyances

Identité, Rôles

Transpersonnel : vision du monde

Bien-Être :congruence


13

DR : des questions simples

A qui dois-je rendre compte ?

De quoi suis-je responsable ?

Équilibre entre Tenter d'assumer

ses responsabilités (qui contribue à notre intégrité personnelle et professionnelle)

L'importance relative de nos engagements


14

Développement de systèmes

Dans mon job, à qui dois-je rendre compte ?

De quoi suis-je responsable ?

Comment puis-je au mieux assumer mes responsabilités ?


15

Objectifs et moyens du DR

Objectifs Optimiser la valeur

ajoutée Gérer les risques

Rythme durable

Vision Améliorer... Transparence

Moyens Feedback rapide

(cycles courts) Les risques sont

publiés Ressources

(temps...) Lever la tête... Compétences... Dire la vérité,

unité = story


16

Feedback concret et rapide

Ne pas réduire les délais brutalement

Améliorer la performance jusqu'à rendre ridicule un délai trop long

Changement de vision


17


Création deValeur

Estimer

Clarifier

Tester

ImplémenterConcevoir

Intégrer


18

L'important...

Développement... Responsable !

XP est la méthode, DR est le levier.

... Que feriez-vous si vous aviez à jouer avec votre argent ?

En dernière analyse : Être intègre ie harmonie des valeurs, croyances et pratiques


19



dépend de

L'éthique, le Savoir-Êtreexemple : les quatre accords toltèques


20

Ethique : une définition

« ...Critères pour juger les motifs et conséquencesd'un acte... »

Oups... Quid de l'esprit libertaire ?

Critères pour « Agir de manière responsable. »


21

Savoir-Être : Questions à (se) poserJe sais ce que l'on attend de moi

Projet agile = agile-attitude

J'aurai les moyens de faire Poste binôme, demande de l'aide...

Je sais ce que j'en retire (gains)

Je comprends les enjeux du projet

Quel est mon savoir-être ?


22

Un exemple : les quatre accords toltèques*Que votre parole soit impeccable

Parler avec intégritéQuoi qu'il arrive, n'en faites pas une

affaire personnelleChacun est dans sa réalité

Ne faites pas de suppositionsS'exprimer, poser des questions

Faites toujours de votre mieuxEn fonction de votre énergie

* « Les quatre accords toltèques » Don Miguel Ruiz, éditions Jouvence


23


Savoir-Être

dépend de

« l'Agilité individuelle », ressources personnellesexemple : « CARA : un bijou pour l'Agile »


24

CARA : l'Agile-Attitude

Courage Valeur de l'XP Changer de vision*, de croyances,

de pratiques

Attention Être présent Ecouter activement Attention à soi, aux autres, aux variables

* C'est quoi un projet, un planning, un code-source... ?


25

CARA : l'Agile-Attitude

Responsabilité cf. Développement responsable Clé de l'adoption de l'Agile

Assertivité S'affirmer dans l'équipe Être à sa place et contribuer


26

De l'agilité individuelleà l'intelligence collectiveLes ressources personnelles

Exemple : CARA

Ethique, Savoir-Être Exemple : les accords toltèques

Développement Responsable Nécessité de rendre compte

Agile, Extreme Programming Le pouvoir de l'intelligence collective

Permet...

Permet...

Permet...


27

Pour finir... Agile, Extreme Programming

Intelligence collective & contraintes libératrices

Livrables à plus forte valeur ajoutée, plus vite

Bien-Être, Plaisir à développer, créer, contribuer au projet

Permet...

Et permet aussi

Il ne s'agit pas de « faire » agile, il s'agit d'être agile.


28


Thierry Cros @ http://agile.thierrycros.net


29

Fin


30

Les cercles vertueux1. Le client définit la valeur ajoutée 2. Le développeur

estime

3. Le client choisit 4. Le développeur

construit

Processus d’apprentissage : la construction influence l’estimation,les choix de specs (user stories) influencent la valeur ajoutée.


31

Premier cercle de maîtrise : maîtriser le projet

Planification Versions Fréquentes Tests-Client Équipe complète

Les pratiques se consolident mutuellement

Objectifs : Qualité de la production Amélioration de la

gestion projet (estimation, productivité)

Maîtriser le projet


32

Deuxième cercle de maîtrise : collectif projet

Rythme durable Vocabulaire commun Intégration continue Standards de codage

et Propriété collective

Le rythme durable est sous contrôle du management

Objectifs : Concrétiser le travail

d’équipe Autoriser la

planification


33

Troisième cercle de maîtrise : fabriquer le produit

Pilotage par les tests unitaires

Conception simple et amélioration par remaniement

Binôme

Les pratiques de développement

Objectifs : Autoriser le travail

collectif, les cycles courts, grâce à la souplesse du produit

Maintenir les variables du projet


34

XP : une méthode agile

Retrouvez cette présentation sur :

http://www.thierrycros.net/formation.html


35

Cartographie détaillée

Tests-Client

Rythme durable

Propriété collective

Troisième cercle : fabriquer le produit

Versions fréquentes

Améliorer par remaniement

Pilotage par les Tests

Équipe complète

Vocabulaire communWall Communication

A gentle introduction

Premier cercle : Planification

Deuxième cercle : « collectif projet »

Intégration continue

Conception simple

Binôme

La documentation dans XPXP et UML

Rôles dans XP

User Stories

3 niveaux de gestion

Standards

http://www.extremeprogramming.org/index.html


36

Principes essentiels de XP

Feed-back rapideAssumer la simplicitéChangement incrémentalAccueillir le changementTravail de qualité


37

Autres principes de XP Apprenez à

apprendre Petit investissement

de départ Jouez pour gagner Expérimentation

concrète Communication

ouverte et honnête

Travaillez avec l’instinct des personnes

Acceptez les responsabilités

Adaptation locale Voyagez léger Métriques honnêtes


38

Planification

Exploration Commitment Steering Apprécier ce que le système devrait faire

Le Client définit la release, le Développeur s’engage

Faire évoluer le plan par feed-back

2 mois maximum Une semaine Plusieurs années


39

Macro-planning Release : 2 à 6 mois Itération : 1 à 3 semaines plus de feedback

donc mieux gérable

Master PlanRelease


40

Version fréquentesFournir rapidement une valeur ajoutée

Réduire les délais pour améliorer la gestion de projet par feed-back rapide des utilisateurs


41

Plan Version Le client répartit les specs (user

stories) dans les itération en fonction de : Priorités, Points estimés Risques Vélocité

Le planning est adapté à l’humain : durées signifiantes


42

Vélocité Capacité de production d’une équipe dans

une itération, re évalué à chaque itération, affiché

Unité virtuelle : le « point » ou « jour estimé » Valeur : le total des points des demandes

traitées (terminées) dans l’itération précédente.

Par défaut : total des jours de travail de l’équipe, divisé par 2 ou 3 (facteur de charge)


43

Specs complètes ? Identifiant de spec : Client

Sa priorité Client Son estimation Développeur Ses Tests-Client Client

Les infos (écrit, oral) qui permettent de comprendre et tester Tous

Client sur site ou représentant


44

Tester pour se forger une opinion

Feedback du système Spécifications Non-régression Test de « fin »

Demande

Tests-client[ok]

Utilisateur face à son système

Itération


45

Micro-Planning Dans l’itération Unité = actions

(max 2 jours – découper) Infos de gestion au quotidien :

Stand Up Meeting Auto-gestion, wall-communication Le scope d’une itération est mis à jour

avant qu’une demande ne soit traitée


46

Plan Itération A partir des specs+Tests-Client, création de

la liste de tâches initiale, auto-répartition L’occasion de revoir le Plan Version, priorités Contenu

Specs (users stories) TA KO dans l’IT précédente Impact

Attention aux changements de dernière minute et à l’optimisme invraisemblable

Process d’amélioration permanente


47

Stand Up Meeting Court (~ ¼ heure) et quotidien Debout pour rester court Actions – qui, état – Consommé & RàP Exposer les + et – Prévoir qui-quand traiter les questions Le CP utilise ces infos pour son

reportingEspace de communication formalisé


48

Tests Client ou Tests d’Acceptance

Format simple, Bristol A5 Lié à une user story, les T.A. forment les

specs détaillées. Test fonctionnel : normal, erreur, limite… Test non fonctionnel : précision, fiabilité,

performance, robustesse… Automatisable Une métrique: TA OK / Total TA


49

T.A. et process Écrits avant le développement Le développeur reçoit les T.A, fait ce

qu’il faut pour les faire passer sur sa machine, il a alors terminé (mesure de la complétude)

Ensuite passage en val; le testeur vérifie aussi la non-régression


50

Cas de TestSuite de tests

Cas de Test Fond : i demande,

titre, environnement de test (login, droits, data…), procédure, résultat attendu

Forme : le plus simple, facilement accessible

Suite de Test Chaque jour une

suite de tests : nouvelles réalisations en val et non-régression

Date, Qui, id Test, résultat commenté

Archive papier ? Affiché

Un code non testé n’existe pas.


51

Test SuiteSchéma de principe

OKKOxxxD21-2OKOKxxxD21-1xxOKxxD20-2

NR OKNR OKOKxxD20-1xxOKKOxD18-3

NR OKNR OKNR OKOKxD18-2xxxOKxD18-1

J5J4J3J2J1ID Test


52

Équipe complètePlateau projet

Pièce projet Confort des équipiers Communication

client / développeur Tables : demandes,

CRC Cards… Wall-communication

Une équipe XP

Managers

Clients Développeurs


53

La « wall-communication » Les murs : vecteurs de

communication Release Plan Itération Plan Liste d’actions Schémas, diagrammes Métriques

Vélocité TA OK / Total TA

…


54

« Affichage autorisé »

Ajouter la méthode (MD) 1h / 2h Créer la classeModifier la table…

V = 10


55

Expression de BesoinsQui doit exprimer les besoins ?

Les rédiger ? User Story ou Use Case de UML ?

lourdeur des use cases (diag de séquence…)

« Piloté par les cas d’utilisation », en fait par les besoins, les scénarios

Client sur Site


56

User story Bristol format ~A5 Unité de gestion du

projet Identifiant de specs :

Tests d’Acceptance Communication

Quelques lignes Écrit manuellement Priorité, Estimation

Le taux est saisi à la volée, lorsque on veut ajouter un

produit à un devis

7++

4


57

Dynamique des User Stories (1)

Écrit par le client Unité de gestion du

projet Déclencheur de

discussion Créateur de tests de

validation


produit à un devis

7


58


Discussion précisions

Priorité donnée par le clientLe taux est saisi à la volée,

lorsque on veut ajouter un produit à un devis

7++


59


Estimation en « points » donnée par le développeur

Ces éléments sont à la base de la planification


produit à un devis

7++

4


60


La User story est répartie dans une itération par le client

Le développeur utilise la carte pendant l’itération

Une U.S. est un « ordre de production »


produit à un devis

7++

4


61


Estimation : entre une et trois semaines

En pratique : table des user stories…

… puis archivage


produit à un devis

7++

4


62

Un guide : Conception simple« quelle est la conception la plus simple

qui puisse fonctionner ? »

« YAGNI » You Ain’t Gonna Need It

Le guide : « le plus simple possible »


63

La Conception dans XP

Conception évolutive contrôlée≠

Grosse conception du début

Conception Simple

Tests Unitaires

Refactoring

Quick Design Session


64

« Agile » contre « lourd » Méthodes « agiles »

Le minimum Ajouter si

nécessaire des éléments à la méthode

Projets petits ou moyens

Méthodes lourdes Le maximum Dégraisser la

méthode si suffisant Gros projets

www.agilealliance.orgwww.xprogramming.com

www.rational.com/rup

http://www.agilealliance.org/


65

Deux « joueurs » Client

Fixe les besoins Donne une priorité N’intervient pas sur

les estimations

Développeur Réalise Estime N’intervient pas sur

les besoins ni leurs priorités


66

MétaphoreVocabulaire commun

Communiquer par métaphore l’architecture du système

Exemple typique : Client/ServeurDesign Patterns: bridge…

« C’est un site de e-commerce, basé sur un 3-tiers, le client gère son chariot électronique… »


67

TestsTests fonctionnels (tests-client),

de validationTests unitairesTestFirstDesignOutils : xUnit cppUnit, unit…

utPLSQL, Objecteering

Le développeur écrit les tests avant le codePas de test avant = pas de XP


68

Tests Unitaires « Tester avant de coder » Nécessairement automatisé dans des

« suites » de tests Confort offert par les tests écrits avant Moyen indispensable pour le

refactoring Écrire les tests participe de la

conception


69

xUnit Outils graphiques

ou non TestRunner TestSuite TestCase

C++ Java Javascript Ada Perl Delphi … www.xprogramming.com

www.junit.org


70

CRC CardsComplémentaire de l’UMLFavorise la communicationCentré sur l’essentiel de l’objet :

Responsabilités des objets (des classes) Collaboration entre objets

Quick Design Session


71

Séquence typique Ecriture des tests de

la méthode Add() Ecriture de Add() Validation par les

tests Ecriture des tests de Substract()

…

Class Calculateur {public int Add();public int Substract();public int Multiply();public int Divide();

};


72

Refactoring Améliorer la conception d’un code existant Lié à la conception objet Aspect réaliste du développement aujourd’hui Rendu possible par les tests et la souplesse

des matériaux Un site de référence :

www.refactoring.com


73

Binôme,Propriété collective

Pair programming

- Relecture « extrême »- Évite les gourous indispensables- Un minimum d’apprentissage de « binôme »

Propriété collective

- Pas de fichier réservé à un développeur- Travail d’équipe


74

Intégration continueUne fois par jour minimumAméliore le feedback du systèmeFacilite la détection

et la correction de bugProcédure simple pour éviter les

collisionsAutorise les tests-client


75

Rythme durableTrop de travail

= problème structurel ou conjoncturel ?

Pas plus de deux semaines de suite de surcharge

Le management offre sa « couverture aérienne »


76

Client sur sitePour en finir avec les tabous sur les

« besoins » des utilisateursParce que le client doit avoir le courage

de participer au projet……Il doit définir

- les besoins - leurs priorités


77

Standards de codageParce que le code est une partie

essentielle de la documentationPour faciliter « collective ownership »

et « pair programming »


78

Documents dans XPUser storyTest client, Test unitaire (source)Code (source)MétriquesPlus tout document qui s’avère

indispensable, exigé par le client, par exemple architecture avec UML


79

Outils dans XPEnvironnement confortable :

éditeurs, compilateurs…Gestionnaire de configurationStations de travail adaptées

à « binôme »


80

XP et Processus unifié

Cycles de vie compatibles

Itératif, incrémental Piloté par les besoins Centré « architecture »

Gestion différente des besoins, de la communication

Autre vision de l’architecture et de la conception

Lourd contre agile…


81

XP et UMLPas d’incompatibilitéDiagrammes jetables Instinct des personnesGénération de code :

le modèle devient le codeVigilance par rapport aux Ateliers de

Génie Logiciel (CASE Tools)


82

Rôles dans XP Client : il bénéficie de la valeur ajoutée par le

produit, il définit les besoins et leurs priorités Développeur : il estime et réalise le produit Coach : responsable du process Tracker : métriques, mémoire de l’équipe Testeur : passe tous les tests régulièrement Consultant : spécialiste, occasionnel Big boss : confiance en l’équipe, courage

face aux changements induits par XP


83

Où se documenterOuvrages

Kent Beck «XP explained » (XPE) et « Planning XP »

Addison-WesleyRon Jeffries « XP installed » (XPI) Addison-Wesley

« Extreme Programming », Eyrolles

Web siteshttp://agile.thierrycros.net « Liens »


84

Retrouvez cette présentation sur :http://agile.thierrycros.net