Introduction à l'Agilité

225
Introduction aux méthodes agiles B.Vinot

description

Une première vue d'ensemble des méthodes agiles

Transcript of Introduction à l'Agilité

Page 1: Introduction à l'Agilité

Introduction aux méthodes agiles

B.Vinot

Page 2: Introduction à l'Agilité

Plan du coursLes projets classiques

Le gantt-Les méthodes d’estimation-Les cycles de développement

Apports des technologies objet-La modélisation UML

Unify Process

L’agilité

IntroductionLe manifeste agile

Le lean

Panorama des méthodes agiles

Les rôles – les cycles

Déroulement d’un projetDéfinition des besoins - Méthode de planification agile

les itérations

La modélisation agile -La mêlée scrum ou le stand up meeting XP - Burndown chart- Calcul de la vélocité de l’équipe

Les outils agiles-TDD

Conclusions

Migration-Avantages-ROI- Les bilans

2

Page 3: Introduction à l'Agilité

Agilité : Définitions

• L’Agilité est l’habilité de créer et de répondre au changement dans le but d’avoir du succès dans un environnement d’affaires turbulent. - Jim Highsmith

• Certaines problématiques sont difficiles, certains individus sont difficiles. Les méthodes Agiles ne sont pas une garantie de succès. - Craig Larman

• Ce n’est pas la plus forte des espèces qui survit, ni la plus intelligente, mais celle qui s’adapte le mieux -Charles Darwin

• Intelligence = (2)Aptitude à s’adapter à une situation, à choisir en fonction des circonstances… - Larousse

3

Page 4: Introduction à l'Agilité

Les projets classiques

Le gantt

Les méthodes d’estimation

Les cycles de développement

4

Etes vous familier avec les cycles de dvp?

Page 5: Introduction à l'Agilité

Les méthodes prédictives

Réalise

Discute

Découpe

Planifie

Distribue

Chef de projet

Equipe1

Architecte dev1

Equipe2

dev2

Et le client?

5

Page 6: Introduction à l'Agilité

Estimer pour Planifier

• Ne pas faire tout seul

• Méthode des trois experts

• (min + 2 * Moyen + Max) /4

• Méthode des trois wagons

• Faire participer l’équipe

• Tenir compte de la complexité - Fibonacci

• Hiérarchiser les fonctions

• Relativiser : Cocomo

6

Page 7: Introduction à l'Agilité

Planifier avec Fibonacci

Plus c’est compliqué et plus ça …..Et si c’est encore plus compliquéalors ça ….. Encore plus

F(n) = F(n-2) + F(n-1)

7

Page 8: Introduction à l'Agilité

No. 8

• Comparer 2 à 2 chaque fonction

• A chaque comparaison est associé un poids variant entre 1 et 3 (1 signifiant peu de différence)

• Exemples :– F2 est plus importante que F1 avec un poids relatif de 1

– F4 est plus importante que F1 avec un poids relatif de 2

• Poids de la fonction 5 : – Somme de toutes les cases orangées (1+1+1+1)

• Poids de toutes les fonctions :

– Somme de tous les poids de fonction

• Poids relatif de la fonction 5 : – 4 / 27 = 14,80 %

• Hiérarchie des fonctions

F2 F3 F4 F5 F6

F1 F2 1 F1 3 F4 2 F5 1 F1 3 6

F2 F2 3 F4 2 F2 2 F6 1 6

F3 F4 1 F5 1 F3 2 2

F4 F5 1 F4 3 8

F5 F5 1 4

F6 1

27

29,66%

22,22%

22,22%

14,80%

7,40%

3,70%

F4

F1

F2

F5

F3

F6

Hiérarchiser les fonctions

8

Page 9: Introduction à l'Agilité

29,66%

22,22%

22,22%

14,80%

7,40%

3,70%

5%

20%

20%

15%

10%

30%

F4

F1

F2

F5

F3

F6

Coût

Poids

La fonction F4 représente 5 % du budget pour un poids de 29,66 %

n Intégrer cette fonction dans le périmètre minimal

• La fonction F6 représente 30 % du budget du projet pour un poids de 3,7 %

– Améliorer le coût de la solution, ou

– Supprimer la fonction du périmètre

Déterminer la valeur des fonctions

9

Page 10: Introduction à l'Agilité

Le Gantt

10

Cocomo

Page 11: Introduction à l'Agilité

Les cycles de DVP

Winston Royce1970

Addison Wesley1990

11

1980 : V1990 : Itératif

Page 12: Introduction à l'Agilité

Classique-Agile

12

Page 13: Introduction à l'Agilité

Une arnaque ?

1313

« La logique est l’art de s’enfoncer dans l’erreur avec confiance ». Joseph Wood Krutch

Madame Soleil

Page 14: Introduction à l'Agilité

UnifyProcess

14

Page 15: Introduction à l'Agilité

La gestion de projetClassique

Apports des technologies objet-Métriques

La modélisation UML

Unify Process

15

Page 16: Introduction à l'Agilité

Des preuves, des métriques(1)

16

Des chiffres, oui mais:• Simples• Pas inventés mais mesurés• Beaucoup, mais pas trop• Choisi, pas imposé

Ce qui compte ne peut pas toujours êtrecompté, et ce qui peut être compté necompte pas forcément - Einstein

Page 17: Introduction à l'Agilité

Apports des technologies Objet

17

17

11

81714

11

7

6

2

2

5

IncreasedProductivity

Cost savings

Improvedinterfaces

Software reuse

Improvedapplicationmaintenance

Encapsulateexistingapplications

Develop strategicapplicationsquickly

Developapplications asrevenue source

Access new OSand tools

Page 18: Introduction à l'Agilité

Des preuves, des métriques(2)Les métriques de McCabe

18

C++ C++ C++ C C C

V0 V1 V2 V0 V1 V2

Average Function LOC 6,66 6,2 6,11 29,62 32,5 37,11

Min Function LOC 2 1 1 3 3 3

Avg Cyclomatic Complex 1,66 1,59 1,59 5,88 6,25 6,56

Avg Comparison Complex 0,25 0,24 0,3 1,38 1,62 2,22

Avg Logic Flow Complex 1,91 1,83 1,89 7,25 7,88 8,78

Avg Function Complexity 3,69 3,59 3,7 9 9,62 10,56

eLoc/100 2,07 2,5 2,68 2,68 2,91 3,53

eLOC 207 250 268 268 291 353

Page 19: Introduction à l'Agilité

Des preuves, des métriques(3)

19

Page 20: Introduction à l'Agilité

Programmation fonctionnelle

20

Page 21: Introduction à l'Agilité

Programmation objet

21

Page 22: Introduction à l'Agilité

Les concepts Objet

• Abstraction : Classe

• Encapsulation

• Héritage

• Polymorphisme

22

Personne

-nom-age-poids

+Manger()+Travailler()+Anniversaire()

Dentiste

-adresseCabinet

+Travailler()

Boulanger

+Travailler()

Arracher des dents Faire du pain

// un petit pgPersonne pDentiste dBoulanger bp.Travailler()d.Travailler()b.Travailler()

// un petit pg (suite)p = dp.Travailler()p = bp.Travailler()

sac<Personne> leSac

For each p in leSacp.Travailler()

Page 23: Introduction à l'Agilité

La gestion de projetClassique

Apports des technologies objet

La modélisation UML

Unify Process

23

Page 24: Introduction à l'Agilité

UML : La genèse

Booch-93 Rumbaugh( OMT2)

Oct-950.8

Jacobson (use case - sdl)

Juillet-960.9

Janv-971.0

Nov-971.0

Sept-971.1 (OMG)

20001.4

DOC-PDF UML1.3 = 4,7MBDOC-PDF UML2.0 = 5.8 MB

20032.0

24

Page 25: Introduction à l'Agilité

Un modèle : Définition

Ce qui sert ou doit servir d’objet d’imitation pour faire ou reproduire quelque chose (petit robert)

Top Model 25

UML Contient

UML est un langage qui contient

• Des éléments de modélisation:

– Des classes

– Des packages

– Des méthodes

– Des Acteurs…..

• Des diagrammes

– Classes, UC, Automate, Activité, …..

Page 26: Introduction à l'Agilité

Les diagrammes UML

26

• Diagramme de use case• Diagramme de classes• Diagramme de structure• Diagramme d'objets• Diagramme dynamique

• Diagramme d'interaction • Diagramme de séquence• Diagramme de communication

• Automates• Diagramme d'activité

• Autres diagrammes• Composants et Déploiement

Page 27: Introduction à l'Agilité

Les diagrammes UML

27

Page 28: Introduction à l'Agilité

Diagramme de Use caseLes acteurs

Un acteur est un rôle d’un ou plusieurs objetssitués à l’extérieur du système et qui interagissentavec lui pour remplir une fonctionnalité donnée de ce système.Un acteur caractérise le rôle joué par un objet àl’extérieur du système.

Uti lisateur

• Un acteur parle au système (Acteur principal)• Le système peut parler à un acteur (Acteur secondaire)• Un acteur est :

• Un humain (via une IHM)• Du soft• Du hard• Le temps

28

Page 29: Introduction à l'Agilité

Diagramme de Use caseUse Case

Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui semanifeste par un ensemble de messages échangésentre le système et un ou plusieurs acteurs.

UtilisateurVerifierBonneMarche

CapteurTemperat

ure

29

faire qqchose

Acteur primaire Acteur secondaire

IHM

ProtocoleAPI

Une fonctionnalité interneAu système

Page 30: Introduction à l'Agilité

Diagramme de Use caseDescription d'un Use Case

• Titre et numérotation

• Résumé

• Les acteurs

– Acteur principal

– Acteurs secondaires

• Pré-conditions

• Description

• Exceptions

• Post-conditions

(3-5 pages)Ce n ’est pas une

description formelleMais doit être très détaillé

Ceci est l ’usagemais ne fait partiede la norme UML

30

Scenario

Page 31: Introduction à l'Agilité

Diagramme de Use Case

31

Utilisateur

Appeler / numéro

Appeler / contact

Gerer les contacts

Préparer

Recevoir appel

Antenne HLR

Configurateur

GSM Envoyer<<include>>

A1

A2 A3

<<include>> <<include>>

B1

B2 B3

<<include>> <<include>>

<<include>>

Page 32: Introduction à l'Agilité

Utilisation des Use caseManger

Descriptions

Distribuer le comportement des fonctionnalitésaux méthodes des objets

32

Page 33: Introduction à l'Agilité

33

Use cases are wonderful but confusing. People, when asked to write them, do not know what to include or how to structure them. There is no published theory for them. This paper introduces a theory based on a small model of communication, distinguishing "goals" as a key element of use cases. The result is an easily used, scaleable, recursive model that provides benefits outside requirements gathering: goals and goal failures can be explicitly discussed and tracked; the goals structure is useful for project management, project tracking, staffing, and business process reengineering. The model and techniques described here have been applied and evaluated on a relatively large (50 work-year, 200 use-case) project.

Des mauvais UC

Page 34: Introduction à l'Agilité

Use Case : Exercice

34

Une société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit suivre les expéditions qui ne sont effectuées que si le paiement est OK.Les paiements se font par carte bancaire dans le cas d'internet et par chèquedans le cas de la poste. Les paiements sont validés par un système bancaireappartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de labase est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En casd'indisponibilité, une lettre doit être envoyé au client.

Page 35: Introduction à l'Agilité

Notion de stéréotypesUn stéréotype est une nouvelle classe d’un élément de modélisation qui est introduit au moment de la modélisation. Cela représente une sous classe d’un élémentde modélisation existant avec la même forme, mais avecune intention différente.

• Les stéréotypes font partie des mécanismes d’extensibilités, prévus par UML.

• Une interface est un stéréotype

• On peut stéréotyper les classes, les associations, les packages, …..• On peut associer un nouvel icône pour chaque nouveau stéréotype.

Z

<<nouveauStereotype>>

35

Page 36: Introduction à l'Agilité

Diagramme de classe

• Statique :

– Ne pas utiliser de verbes d'action pour relier les classes

– Une classe isolée est une classe inutile

– Doit être vrai tout le temps

– Représente LE programme

– On ne peut pas tout montrer sur un seul schéma

Un diagramme de classe montre la structure statiquedu modèle, les choses qui existent, leur structureinterne et les relations aux autres choses.

36

Les choses qui existent

Maison

GaragePersonne

Personne

Moto

Tricycle

Page 37: Introduction à l'Agilité

Diagramme de classeLes classes

37

UneClasse

-attributPrive+attributPublic#attributProtected+attributDeClasse+attributTypé: int+attributTypéInit: int = 56

+Operation()+OperationDeClasse()+OperationAvecParam(par1: int, par2: boolean): int+OperationAbstraite()

Page 38: Introduction à l'Agilité

L’héritage

Vehicule

+carteGrise-marque#nbPassagers

Avion

+ailes+reacteur[2]

Bateau

+moteurDiesel

L’héritage s ’appelle généralisation en UML

EST UN

Page 39: Introduction à l'Agilité

Les interfaces

39

FqqAble<<interface>>

+Fqq()

A

+Fqq()

Client

FqqAble

A

+Fqq()

Client

Une interface permet à un objet (le Client)De faire faire quelque chose (Fqq) à unObjet de type A, sans savoir qu’il est un A.Il sait seulement qu’il est de type FqqAble

On a remonté le niveau d’abstraction.On utilise une interface pour imposer à desClasses différentes d’implémenter une ouPlusieurs opérations.

Page 40: Introduction à l'Agilité

Les associationsLes associations représentent des relations structurelles entre classes d’objets. Une association symbolise une information dont la durée de vie n’est pas négligeable par rapport à la dynamique générale des objets instances des classes associées. La plupart des associations sont binaires, c’est-à-dire qu’elles connectent 2 classes. Certaines sont refléxives.

40

Personne

+f

+h

Voiture Roue4

Page 41: Introduction à l'Agilité

Diagramme de classe : Associations Personne Societe

Est Employée par

Nom d'association

Personne SocieteEst Employée par

-employeur-employe

Nom de rôle

SocietePersonne1..* 0..1

-employe -employeur

1..* 0..1Cardinalité-Multiplicité

Personne

employeur : Societe

Societe

employe : ListeOfPersonne

NavigabilitéSocietePersonne1..*

-employes

1..*

Societe

employes : Personne

Personne

41

Page 42: Introduction à l'Agilité

Diagramme de classeDépendance

Depenseri = Banque::GetInstance()->DonnerSolde();Acheter(i);Volerb = new Banque();i = b->DonnerSolde();Economiser (p : Banque)p->Deposer(10000);

42

Page 43: Introduction à l'Agilité

Diagramme de classe : Exercice1

Immeuble

Famille

Appartement

Pièce

Cuisine

Salon

Gardemanger

Chien

Chat

Animal

Bail

acte de propriété

Nourriture

Lapin

Whisky

Mariage

CompteBanquaire

Personne

43

Page 44: Introduction à l'Agilité

Diagramme de classe : Exercice2

44

Page 45: Introduction à l'Agilité

Diagramme dynamique

• Diagrammes d'interaction (Séquence collaboration) servent à montrer comment les objets parlent les uns aux autres.Ils montrent le déroulement d'un ou d'une partie d'un Use case(cas nominal, cas des exceptions, …)Un objet (l’émetteur) envoi un message à un autre (le récepteur).Le récepteur doit avoir une opération correspondante au message.

• Automates servent à montrer le comportement d'une classe qui réagit différemment selon son état.

• Activités montrent le déroulement d'une méthode d'une classe oucelui d'un Use case

45

Page 46: Introduction à l'Agilité

Diagramme de Séquence

46

: A1

: C1 : C2 : C3

new : C3Oper1()

Oper3()

Oper2()

Oper1()

C3()

<<create>>

Oper2()

Delete()

<<destroy>>

retour

Page 47: Introduction à l'Agilité

Diagramme de Séquence (UML2.0)

47

pour chaque employeloop

commercialalt

: FinMois

: Entreprise : Employe

: Commerciaux

CalculerSalaire()

CalculerSalaire()

CalculerCommission()

Entreprise

+CalculerSalaire()

Employe

+salaire

+CalculerSalaire()

Commerciaux

+commission

+CalculerCommission()

-lesEmployes

*

Page 48: Introduction à l'Agilité

Automate• Un automate est accroché à une classe et est composé d'états etde transitions. Les transitions permettent de passer d'un état àun autre …

Arret Marche

On

Off

Casse

Casse

48

Page 49: Introduction à l'Agilité

AutomateÉtat & Transition

Etat

entry/ Action1

exit/ Action2

on Ev1/ Action2

do/ Activité

E1 E2Ev1( a1,a2 )[ i == 0 ] / ActionDeTransition ^Cible.SendEv2(a3, a4)

Événement qui déclenche la transition

Garde

Action effectuée sur la transition

Envoie de Ev2 à un objet Cible

Action en entrant dans l'état

Action en sortant de l'état

Action déclenchée sur réception de Ev1

Activité

49Rmq : Le langage d’action (UML1.4) est remplacé par 50 types d’action

Page 50: Introduction à l'Agilité

Automate imbriqué

Arret

Marche

Lavage

Rinçage

Essorage

H

On

Lavage

Rinçage

Essorage

After15

After10

After5

PorteOuverte

HFermer

Off

Ouvrir[ cuve vide ]

Page 51: Introduction à l'Agilité

Automate : exercice

E1

ST1

entry: i = 0exit: i++

ST2

entry: i++exit: i++on E4: i ++

E1 / i++

ST3ST4

on E2: i = i - 2

E3[ i == 5 ]

E2

E1

E1

E3

E3

E1E3E1E3E1E2E1E2

E3

51

Page 52: Introduction à l'Agilité

La gestion de projetClassique

Apports des technologies objet

La modélisation UML

Unify Process

52

Page 53: Introduction à l'Agilité

UP : La base

PU est à base de composantsPU utilise UMLPU est piloté par les cas d’utilisationPU est centré sur l’architecturePU est itératif et incrémental

53

Page 54: Introduction à l'Agilité

UP & RUP

Unify Process (Énorme process pour tous)

RUP Rational Unify Process Process customisé à partir du UPC'est un outil (site web, customisable)

Custom

AirFranceUP

54

XUP

Page 55: Introduction à l'Agilité

RUP : Principes

55

OpenUP7 rôles (environ 45 pour RUP)20 artefacts (plus de 80 pour RUP)18 tâches (plus de 150 pour RUP)

Page 56: Introduction à l'Agilité

Les artefacts

• Activité de gestion de projet

– Comptes rendus, planning d’activité, ….

• Résultats

– Modèles

– Code source

– Spécifications

– …..

56

Page 57: Introduction à l'Agilité

Les rôles

• Les analystes (exigences)

• Les développeurs

• Les testeurs

• Les managers (gèrent le processus)

• Le chef de projet

• Les autres (Client, MOA, stakeholder, ….)

57

Page 58: Introduction à l'Agilité

Les activités

• Modélisation métier• Les Besoins• Analyse et conception• Implémentation• Tests• Déploiement• Gestion de configuration• Gestion du projet• Environnement

Etudié plus tard

58

Page 59: Introduction à l'Agilité

BPM

59

Page 60: Introduction à l'Agilité

Modélisation métierStéréotypes UP

Fournisseur

Les processLes objets de L’entreprise

Client

Les employés

business use case

60

Page 61: Introduction à l'Agilité

Organisation des modèles (UP)

61

Les sources

Les UC realization (Documentation)

Les composants (physiques et logiques)Les machines

Définition des besoins

PC

Composant1components

Composant1

C1C2

residents

C1 C2

VOPC

uc1

Page 62: Introduction à l'Agilité

Exemple d’un workflow

62

Page 63: Introduction à l'Agilité

Processus traditionnel

• Gros classeur sur l’étagère des développeurs

• … Ramasse la poussière …

• Difficile à comprendre et à utiliser, vu comme une surcharge (gaspillage)

63

Page 64: Introduction à l'Agilité

Motivation

64

70% 45%

Page 66: Introduction à l'Agilité

Le processus comme un produit

• Pas un simple livre, pas une autre OOAD méthode

• Fourni comme un site web (avec les sources)

• Constamment amélioré

• Base de connaissances

– Navigation graphique, moteur de recherche, index

– Guides, templates de documentation, aide à l’utilisation des outils

66

Page 67: Introduction à l'Agilité

67

Page 68: Introduction à l'Agilité

RUP : Ses forces

• Cadre générique

• Référentiel de bonnes pratiques;

• Gestion des risques dans les projets;

• Cadre propice à la réutilisation;

• Approche basée sur l’architecture;

• Traçabilité à partir des Uses Cases jusqu’au

déploiement.

68

Ex : IBM Tivoli ITUP

Page 69: Introduction à l'Agilité

RUP : Ses faiblesses

• Coût de personnalisation souvent élevé;

– Autres logiciels propriétaires (Rational) indispensables;

• Très axé processus :

– peu de place pour le code et la technologie ;

• Vision non évidente ni immédiate

DEVELAY IsabelleEDORH-A. SemehoGUIBOUT Nicolas

69

Page 70: Introduction à l'Agilité

RUP : Conclusion

• RUP considéré comme:

– un framework de processus génériques;

– un métaprocessus;

• Démarche itérative

– Réduction des risques;

• Facile à expliquer et à valider (les livrables);

• Finalement pas très populaire…DEVELAY IsabelleEDORH-A. SemehoGUIBOUT Nicolas

70

Page 71: Introduction à l'Agilité

L’Agilité

Introduction

Le lean software dvp

71

Page 72: Introduction à l'Agilité

Une petite vidéo

72

David Gageot –Directeur Technique –Valtech Technology

E:\Cours\Agilité\Video\Valtech) 40mn

Page 73: Introduction à l'Agilité

Qu’est ce qu’une méthode agile(1)

Deux caractéristiques fondamentales

– Adaptatives plutôt que prédictive

• Favorables au changement

• Planification plus souple– Faite par l’équipe et non imposée par le chef

– Orientée vers les personnes plutôt que vers les processus

• Travailler avec les spécifités de chacun

• Responsabilité, confiance

73

Page 74: Introduction à l'Agilité

Qu’est ce qu’une méthode agile(2)

• Délivrer rapidement et très fréquemment des versions opérationnelles, pour favoriser un feed-back client permanent

• Accueillir favorablement le changement• Assurer une coopération forte entre client et développeurs• Garder un haut niveau de motivation• Le fonctionnement de l’application est le premier indicateur

du projet• Garder un rythme soutenable• Viser l’excellence technique et la simplicité• Se remettre en cause régulièrement• Ecouter le client mais savoir dire non

74

Page 75: Introduction à l'Agilité

Les bureaux agiles

75

Important - Symbolique

Page 76: Introduction à l'Agilité

Le manifeste agile

76

Kent Beck XP-JunitWard Cunningham wikiJeff Sutherland scrum………

17 Personnes (2001)4 Valeurs12 principes

Nous découvrons de meilleuresfaçons de développer des

Logiciels en réalisant ce travail et en aidant les autres à le faire

Page 77: Introduction à l'Agilité

Manifeste agile : Les valeurs

• L'équipe (« Personnes et interaction plutôt que processus et outils »)Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale.

• L'application (« Logiciel fonctionnel plutôt que documentation complète »)La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Transformer la question : « avez-vous de la documentation ? » en « mais que recherchez-vous comme information ? »Commenter abondamment le code lui-même (si besoin)Transférer les compétences au sein de l'équipe (communication).

• La collaboration (« Collaboration avec le client plutôt que négociation de contrat »)Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.

• L'acceptation du changement (« Réagir au changement plutôt que suivre un plan »)La planification initiale et la structure du logiciel doivent être flexibles.Les premières versions du logiciel vont souvent provoquer des demandes d'évolution.

77

Page 78: Introduction à l'Agilité

Manifeste agile : Les 12 principes

1. Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.

2. Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.

3. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.

4. Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet.5. Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont

elles ont besoin, et croyez en leur capacité à faire le travail.6. La méthode la plus efficace de transmettre l'information est une conversation en face à face.7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.8. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires,

développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.9. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.10. La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.11. Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-

organisent.12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste

son comportement dans ce sens.

78

Page 79: Introduction à l'Agilité

Assemblé nationale (30-4-10)

• Ch. Vanneste (député du Nord)

– Etude Sofres : pourquoi travailler?

• Anglais des sous

• Allemands Epanouissement

• Français Contacts humains

• Direction HSBC : ce qui manque aux entreprises françaises:

– Innovation

– Responsabiliser les salariés

79

Page 80: Introduction à l'Agilité

L’Agilité

Introduction

Le lean software dvp

80

(1950)

Page 81: Introduction à l'Agilité

Lean : Philosophie

Le LEAN est principalement une approche managériale pour optimiser le système de production

– Optimiser la chaîne de création de valeur ajoutée(sous-traitants compris)

– Eliminer les gaspillages du flux de production– Push-Pull– Just in time (pas de code avant que le test le demande)

–Etre discipliné sur les prises de décision (Le plus tard possible)

– Volonté de perfection à chaque étape (Stopper la chaîne)– S’appuyer sur les facultés d’adaptation des individus (boite à

idées)

81

Page 82: Introduction à l'Agilité

Kanban

82

Page 83: Introduction à l'Agilité

Lean : Les 7 concepts

– Eliminer les gaspillages

– Améliorer le système

– La qualité de l’intérieur

– Reporter la décision

– Livrer rapidement

– Respecter les personnes

– Créer la connaissance

http://www.youtube.com/watch?v=Dl4dcLbNlgo&feature=related

83

Page 84: Introduction à l'Agilité

Lean : Gaspillage

Shigeo Shingo (1950)

1. Stock

2. Surproduction

3. Tâches inutiles

4. Déplacement

5. Transport

6. Attente

7. Défautshttp://www.tv4it.net/jusquou-le-lean-peutil-sappliquer-a-

linformatique--permalink-8907.aspx84

Page 85: Introduction à l'Agilité

Lean (LSD) : Gaspillage

Shigeo Shingo (1950)

1. Stock

2. Surproduction

3. Tâches inutiles

4. Déplacement

5. Transport

6. Attente

7. Défauts85

LSD : Mary Poppendieck (2003)

1. Travail non terminé2. Sur spécifications3. Processus…4. Changements de priorité,

changer de tâche5. Transmission d’informations6. Retards7. Défauts

Page 86: Introduction à l'Agilité

L’Agilité

Panorama des méthodes agiles

86

Page 87: Introduction à l'Agilité

Les méthodes agiles : Panorama

87

Page 88: Introduction à l'Agilité

Taille des projets

1-2 ans & 6-12 personnes Couper les projets

88

Page 89: Introduction à l'Agilité

Les méthodes agiles : Contraintes

89

Page 90: Introduction à l'Agilité

eXtremPrograming

• KentBeck (1996) Paye de Chrysler

• Les 4 valeurs de XP : CRSC

– Communication

– Retour-FeedBack

– Simplicité

– Courage

90

Page 91: Introduction à l'Agilité

CRSC

• Communication– Client-Equipe– Programmeur-Programmeur– Equipe-Extérieure (indicateurs du projet)

• Retour - Feedback– Livraison fréquente– VNR– Avancements objectifs– Le client est là

• Simplicité– pas de sur spécifications– Code toujours aussi petit et simple que possible

• Courage– De dire que on s’est trompé– De revenir en arrière– De faire du TU– D’annoncer les soucis

91

Page 92: Introduction à l'Agilité

B.Vinot

Les principes de base

• Seul le code source fait foi, il possède une odeur, appartient à l’équipe, il contient la doc

• L’important c’est le programmeur (ne pas dépasser 40H/S)• Faire le plus simple possible• Restructurer dès que nécessaire• Pratiquer la programmation par paire• Les spécifications sont des « histoires d’utilisateurs »• La planification est un jeu• Livrer fréquemment• Tester donc intégrer encore, toujours et tout le temps• Être courageux

Page 93: Introduction à l'Agilité

Les rôles ds XP(1)

93

• Développeur (100%)• travaille en binôme, communique• doit être autonome• a une double compétence : développeur – concepteur

• Client (25-75%)• doit apprendre à exprimer ses besoins sous forme de user stories• a à la fois le profil de l'utilisateur et une vision plus élevée sur le problème et

l'environnement du business• doit apprendre à écrire les cas de tests fonctionnels• est dans la salle

• Testeur (50%-100%)• a pour rôle d'aider le client à choisir et à écrire ses tests fonctionnels

• Tracker – Rapporteur (10-20% = 30 mn par développeur tous les 2 jours + qq réunions)• aide l'équipe à mieux estimer le temps nécessaire à l'implémentation de chaque

user story• contrôle la conformité de l'avancement au planning

Page 94: Introduction à l'Agilité

Les rôles ds XP(2)

94

• Coach (100% au début, puis 50%, puis 10%)• recadre le projet• ajuster les procédures agiles• doit intervenir de la manière la moins intrusive possible• ne doit pas s’occuper du projet• n’est pas là tout le temps

• Consultant – Expert (0-100%)• n'apporte pas de solution toute faite• apporte à l'équipe les connaissances nécessaires pour qu'elle résolve elle-même les

problèmes• doit être un formateur

• Manager (10-25%)• doit croire à l’agilité• apporte à l'équipe courage et confiance• C’est le chef hiérarchique• Demande des comptes

Page 95: Introduction à l'Agilité

95

Page 96: Introduction à l'Agilité

Combinaison des rôles ds XP

96

Rmq : si plusieurs clients, Ils doivent parler d’une seule voie

Page 97: Introduction à l'Agilité

What is Scrum? Jeff Sutherland

97

Qu’est ce que Scrum?• Pas une méthode• Pas un process• Pas un ensemble de procédures

• C’est un framework ouvert de dvpcomportant un ensemble de règles

• The rules are constraints on behavior that causea complex adaptative system to self organizeinto an intelligent state

• Il permet à une équipe moyenne de s’organiserpour travailler 10 fois mieux

Sutherland1993

Page 98: Introduction à l'Agilité

Scrum : Le cycle de vie

98

UCUser story

Planninggame

DVPTests

Page 99: Introduction à l'Agilité

Scrum : Backlog- BurnDown

99

Page 100: Introduction à l'Agilité

Scrum : Kanban

100

DoD

Bob: « Voilà j’ai terminé de développer ce module, c’est déployé ! »Gérard: « Ben je vois rien…? »Bob: « Ha en tout cas chez moi ça marche… »

Page 101: Introduction à l'Agilité

Definition Of DoneDéveloppement Migration des données (structures +

données)

Support IE7 + FF3 Test Seleniums écrits

Support IE6 Test Seleniums passé avec succès

Support “Navigateurs Home Page” Test Unitaires écrits

Déployé sur Staging Test Unitaires passé avec succès

Tests de régression ok (tous les tests passent)

Multilingue et traduction ok

Documentation (dossier d’hébergement,…)

Démarches à effectuer auprès de l’infrastructure (pour la Prod ou autres. Ex: url, connexion db,ftp,…)

Dépendance avec d’autres acteurs Visualiser sur le mur

Si la définition de « terminé » vous semble confuse Mettez au début un champ «définition de terminé» pour chaque US.

Page 102: Introduction à l'Agilité

TODO : Exo• Aujourd’hui je décide de laver ma voiture• En allant vers le garage, je remarque qu’il y a du courrier sur la table d’entrée• Je décide de jeter un œil au courrier avant de laver la voiture, il contient des factures et des publicités• Je jette les publicités dans la corbeille à papier et réalise que la corbeille est pleine• Je repose les factures sur la table car il faut que je vide la corbeille• Mais comme la poubelle est proche de la boîte aux lettres, je me dis que je pourrais économiser un trajet

en postant mes factures et je décide donc de préparer d’abord le règlement des factures• Je prends mon carnet de chèques et trouve sur le bureau la canette que j’avais commencé à boire.• Je me dis qu’il faut que j’enlève la canette pour ne pas la renverser accidentellement sur mes factures• Je remarque que la canette est tiède et qu’il vaudrait mieux la remettre au frigo pour la rafraîchir• En me dirigeant vers la cuisine, le vase sur le comptoir me saute aux yeux : les fleurs manquent d’eau• En posant la canette sur le comptoir, je manque d’écraser mes lunettes que je cherchais depuis ce matin• Je me dis que je devrais ranger mes lunettes … mais avant, j’ai le temps de donner à boire aux fleurs• Je repose mes lunettes sur le comptoir, remplis un pichet d’eau et soudain, j’aperçois la télécommande qui

traîne sur la table de la cuisine• Je me dis que ce soir je vais la chercher partout et que je ne me souviendrais plus qu’elle est dans la

cuisine• Je décide donc de la ranger au salon … mais avant, je vais donner à boire aux fleurs• Je remplis le vase au tiers car malheureusement je renverse beaucoup d’eau sur le sol• En allant chercher une serpillère, je remets la télécommande sur la table de la cuisine• Je nettoie le sol puis range la serpillère• De retour dans l’entrée … je me demande ce que j’avais l’intention de faire• Cela va ma revenir, en attendant, je vais lire mes mails• Mais avant je …

102

Page 103: Introduction à l'Agilité

TODO-> DoD : Exo

103

Faire qq chose------------------------Comment testerLe résultat------------------------Valeur = 0 - 5OUrgent = 0 – 5Estimation = 0-40

Todo – encours - fini

Page 104: Introduction à l'Agilité

Planning Game

104

Faire qq chose------------------------Comment testerLe résultat------------------------Valeur = 0 - 5OUrgent = 0 – 5Estimation = 0-40

Et Maintenant Estimer

Page 105: Introduction à l'Agilité

Kanban & US & DoD

105

Laver voiture------------------------Ma femme dit:« elle est propre »------------------------Val= 50 Urg=2 E=25

Vider corbeil------------------------Corbeil videRien par terre------------------------Val= 2 Urg=2 E= 2

Régler facture------------------------Chèques débités

------------------------Val= 5 Urg=1 E=40

Canette frigo------------------------Canette froide

------------------------Val= 2 Urg=5 E= 5

Arroser fleurs------------------------Le vase est plein d’

eau------------------------Val= 3 Urg=4 E=3

Ranger telecom.------------------------La telecom. est surLa table du salon------------------------Val= 5 Urg=4 E=1

Ranger lunettes------------------------Les lunettes sontDans la chambre------------------------Val= 1 Urg=2 E=1

Lire mail------------------------

------------------------Val= 2 Urg=2 E= 15

Et Maintenant Planifier

Page 106: Introduction à l'Agilité

Planification

106

Laver voiture------------------------Ma femme dit:« elle est propre »------------------------Val= 50 Urg=2 E=25

Vider corbeil------------------------Corbeil videRien par terre------------------------Val= 2 Urg=2 E= 2

Régler facture------------------------Chèques débités

------------------------Val= 5 Urg=1 E=40

Canette frigo------------------------Canette froide

------------------------Val= 2 Urg=5 E= 5

Arroser fleurs------------------------Le vase est plein d’

eau------------------------Val= 3 Urg=4 E=3

Ranger telecom.------------------------La telecom. est surLa table du salon------------------------Val= 5 Urg=4 E=1

Ranger lunettes------------------------Les lunettes sontDans la chambre------------------------Val= 1 Urg=2 E=1

Lire mail------------------------

------------------------Val= 2 Urg=2 E= 15

50/25 = 2 2/2 = 1 5/40 = 0,125 2/5 = 0,4

3/3= 1 5/1 = 5 1/1 = 1 2/15 = 0,13

Page 107: Introduction à l'Agilité

Les rôles dans Scrum(1)Directeur de produit : Client

• Le Directeur de produit, ou Product Owner en anglais, représente les clients et les utilisateurs. Ses responsabilités se bornent à l'établissement des limites du projets et de chaque itération.

• Il définit les fonctionnalités du produit. Voici une liste de ses responsabilités :

– Choisit la date et le contenu de la release

– Responsable du retour sur investissement

– Définit les priorités dans le backlog en fonction de la valeur « métier »

– Ajuste les fonctionnalités et les priorités à chaque sprint si nécessaire

SCRUM Master : Coach + Manager + tracker

• Le SCRUM Master représente le management du projet. Il interviens dans le cas ou une situation ou un événement peut empêcher ou retarder la progression du travail prévu. Ce n’est pas un maître.

• Voici quelques unes de ces caractéristiques :

– Responsable de faire appliquer par l’équipe les valeurs et les pratiques de Scrum

– Résout des problèmes, remédier aux imprévus

– S'assure que l'équipe est complètement fonctionnelle et productive

– Facilite une coopération poussée entre tous les rôles et fonctions

– Protège l'équipe des interférences extérieures 107

Page 108: Introduction à l'Agilité

Les rôles dans Scrum(2)Equipe SCRUM / SCRUM Team

• Une bonne équipe SCRUM est assez réduite et comporte finalement 5 à 10 personnes. L'échange est un atout primordial dans l'utilisation de SCRUM, il faut donc garder l'aspect dialogue au sein de son équipe de développement.

• Les caractéristiques d'une bonne équipe :

– Regroupant tous les rôles : Architecte, concepteur, développeur, spécialiste IHM, testeur, etc.

– A plein temps sur le projet, de préférence

– Exceptions possibles (administrateur, …)‏

– Organisation autonome

– Equipe cross-fonctionnelle

• La composition de l’équipe est fixe pendant un sprint

Il n’y a pas de chef de projet

• Le chef = PO + Equipe

108

Page 109: Introduction à l'Agilité

Scrum : Une release

109

Time Boxing

• Un sprint n’est pas un sprint• Sprint de début de release• Sprint de stabilisation• Le PO doit anticiper le sprint suivant• Un sprint = 40 tâches• Une tâche = 1-2 jours max• Un backlog = 50 US

Durée planif sprint:2*N (N = nb de semaines du sprint)

Page 110: Introduction à l'Agilité

Scrum : sprint

110http://www.axosoft.com/ontime/videos/scrum

Page 111: Introduction à l'Agilité

Le test Nokia

111

84

27,5

37,5

24,518

6457,5

67

14

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9

% des personnes ayant trouvé une des deux meilleures réponses

test nokia-ScrumBut

Q 1 : ItérationQ 2 : Pratique des testsQ 3 : SpécificationsQ 4 : Product OwnerQ 5 : Backlog de produitQ 6 : EstimationQ 7 : Sprint Burdown ChartQ 8 : Dérangement de l'équipeQ 9 : Équipe

Q 1 : Itération1. Pas d'itération2. Itération > 6 semaines3. Durée variable < 6 semaines4. Itération de durée fixe 6 semaines5. Itération de durée fixe 5 semaines6. Itération de durée fixe 4 semaines ou moins

Bas VodeJeff Sutherland

Page 112: Introduction à l'Agilité

Comparaison XP-ScrumXP (programmation) Scrum (process)

Client est ds la salle Oui NonReprésenté par le productOwner

Techniques de programmation

XP est le roi

Oui (Prog Objet) Junit Refactoring Binôme Simple

PeuTestGénération automatique, graphique, C , Javascript,….

Gestion de projet

Scrum est le roi

PeuTracker Planing game

Oui VelocitéBurnDown chart

Durée des itérations Autour de 2 semaines Autour d’un mois (En baisse)

Adaptable Pas pendant les 3 premières itérations

Oui

112Mélanger les deuxUn scrum meeting

H

PO

SCR

RUP

XP

Page 113: Introduction à l'Agilité

Feature Driven Development5 processes

113

Inventée par Peter Coad

Page 114: Introduction à l'Agilité

FDD : Les rôles

114

Principaux rôles

• Project manager

• Chief architect

• Domain experts

• Dev. manager

• Chief programmers

• Class owners

Autres rôlesRelease manager

Language guru

Build engineer

Tool smith

System admin

Testers

Deployers

Tech writers

Page 115: Introduction à l'Agilité

DSDM : Les principes

115

• implication active des utilisateurs• équipes autorisées à prendre des décisions• produit rendu tangible aussi souvent que possible• L'adéquation au besoin métier est le critère essentiel

pour l'acceptation des fournitures• Un développement itératif et incrémental permet de

converger vers une solution appropriée• Toute modification pendant la réalisation est réversible• besoins définis à un niveau de synthèse• tests intégrés pendant tout le cycle de vie• esprit de coopération entre tous

Page 116: Introduction à l'Agilité

DSDM : Le cycle de vie

116

Page 117: Introduction à l'Agilité

Les rôles ds DSDM

117

Sponsor exécutif : ManagerVisionnaire : ManagerUtilisateur ambassadeur : ClientUtilisateur conseiller : Client-TrackerChef de projet : ManagerCoordinateur technique : consultant - expertChef d’équipe : ManagerDéveloppeurFacilitateur : CoachRapporteur : Tracker

Page 118: Introduction à l'Agilité

Crystal

118

Méthodes créées par Alistair Cockburn (Expert UC)• Importance de la Communication et du feed-back client• Releases fréquentes• Deux grandes phases

• Conception et planning• Itérations

• Clear crystal : Adaptée à des équipes de 6-8 personnes maximum

Page 119: Introduction à l'Agilité

Le chef de projet Agile

119la qualité essentielle du leader sera le charisme plus que l’autorité.

Page 120: Introduction à l'Agilité

Le cycle de l’agilité

120

Les 3 rythmes :• Le rythme du projet• Le rythme de l’itération, qui définit les étapes de réalisation majeures du projet.• Le rythme journalier, qui montre la progression au sein de l’itération.

Ces rythmes suivent la même progression : • préparation,

• Une idée claire (sinon précise) de l’objectif à atteindre.• Une façon de vérifier que la réalisation atteint l’objectif.

• réalisation (laisser faire l’équipe)• retour d’expérience ,• adaptation.

Page 121: Introduction à l'Agilité

Mise en place du process• Version

– Temps fixe : 2-6mois (Préféré)contenu à définir– Contenu fixe durée à définir

• Itérations-Durée : fixe 1-6 semaines– Taille de l’équipe fixe

• Choix des indicateurs• Méthode

– Tests automatisés, Intégration continue– Moins de code, qualité, binôme, refactoring– Itérations courtes, commencer par 4 semaines, puis finir par 2– Implication du client , sur place à 25 ou 50%, représentant de la MOA

• local, personnes, outils,…• Ce processus évoluera dans le futur (adaptable par l’équipe à la fin de chaque

itération)

Chaque équipe a un process différent plus de process d’entreprise

121

Exemple : Une équipe de 5 personnes, des itérations de 10 jours, 5 itérations par Version

Page 122: Introduction à l'Agilité

L’Agilité – Déroulement d’un projet

Définition des besoins

UC-User Story

Planification

122

Page 123: Introduction à l'Agilité

MOE(Chef de projet)

Un Problème sur deux!

123

Client

Dev

Client

Dev

MOA(chefs)

Utilisateurs

AnalystesArchitectes

ExpertsProgrammeurs

testeurs

MOAD

Page 124: Introduction à l'Agilité

Une révolution

Ne pas tout étudier, mais commencer le plus vite possible

Faut-il toujours prendre un billet A-R?

40% à 70% des infos suffisent pour se lancer

• François 1° (Androuet du cerceau)

• Napoléon

• Colin Powell

124

Page 125: Introduction à l'Agilité

Définitions des besoins - DVP

125

Besoin global (10%) : Liste des UC ou US + Planification

Détail du 1° tiers : Scénario des UC – Discussion des USRéalisation du 1° tiers

Définition des besoins Réalisation : les itérations

It1

It2

It3

Détail du 2° tiersRéalisation du 2° tiersIntégration continueVNR

Détail du 3° tiersRéalisation et FinBilan

Page 126: Introduction à l'Agilité

Principe : une version

• Le client (ou PO) est dans la salle– Il propose une liste de fonctionnalités (Backlog)

• UC (sans donner les scénarios) ou User Story• Chaque US ou UC a une priorité donnée par le client

• Les programmeurs affectent un poids (en pt) à chacune des US (Backlog du produit)– Estimation des US en équipe (planning game)– Si estimation impossible, découper la US, ou bien discuter avec le client– Le client refait une passe sur les priorités

• On fait une découpe de la version en itérations• Démarrage de l’itération

– Ecriture des scénarios ou détails des user story– Découpe en tâches des US (Backlog du sprint)– Estimation des tâches en heure– Tests + Dvp + Tests– Bilan + Demo

• Maj du Backlog pour itération suivante

126

Page 127: Introduction à l'Agilité

User story

127

• Taille : carte postale• Affecte un ID automatique• Ecrite par le client• N’est qu’un résumé• Le reste est verbal• Affectation d’une priorité (une valeur)• Affectation sur une itération (voir partiel)• Ecriture des tests finaux (TR)

le client L’équipe de dvp

• Phase de Définition des besoins •Discussion avec le client• Affectation d’un coût• si estimation impossible

• Rediscuter avec le client• la décomposer en n US• la décomposer en tâches et estimer les tâches (Voir la suite)

• Phase de DVP (Iterations)• Découpage en tâches er estimation (H)• Prise de responsabilité d’un développeur pour une tâche• Réalisation en binôme• Ecritures des TU• Réalisation• Passage des TU• Passage des tests finaux (TR)

Les 3C• Card : une ou deux phrases• Conversation : verbale• Confirmation : test

Page 128: Introduction à l'Agilité

US : Recto

128

Page 129: Introduction à l'Agilité

US : Verso

129

Page 130: Introduction à l'Agilité

Planification d’une version

• Calculer la vélocité de l’équipe– Prendre une moyenne des derniers sprints– Pour la première fois :

• commencer l’estimation du sprint (ce qui nous donnera un nb de pt faisables en un sprint – voir plus loin)

• Méthode des 3 experts• Pif

• Répartir les US ds les sprints en commençant par les plus prioritaires• Ajustement des fins de sprint• Rajouter du mou

– 10% pour erreur d’estimation– 15% pour Bug, FeedBack des utilisateurs

• Tenir compte du calendrier (prévisible)• Tenir compte des changements des effectifs de l’équipe si prévu à l’avance• Prendre en compte les points de synchro avec d’autres équipes• Planning orienté utilisateur, sans garantie car il va être remanié

130

Page 131: Introduction à l'Agilité

BackLog de produit(1)

131

D’après la velocité : Une itération = 50 points 5 Itérations (sans engagement)

Page 132: Introduction à l'Agilité

BackLog de produit(2)

132

Page 133: Introduction à l'Agilité

BackLog de produit(3)

133

Beurdone - burndown

Méthode classique • RAF = Temps estimé – temps passéAgilité• RAF = Réestimation de la tâche• Simplement utiliser les états

(en cours-fini-…)

Page 134: Introduction à l'Agilité

Ice Scrum 2Excel

134

Un planning de version•Une version•3 Itérations•Chaque itération contient

des US

Rmq : on ne voit pas lespriorités (dommage)

Page 135: Introduction à l'Agilité

Une variante : Feature

135

Page 136: Introduction à l'Agilité

L’Agilité – Déroulement d’un projet

Les itérations

136

Page 137: Introduction à l'Agilité

Une itération• Découpe en tâches (Planning horizontal)• Estimation des tâches en heure• Planification du sprint (2-4H) : Equipe + PO• Rajouter du Mou (30%)• Affectation des tâches – Fabrication des binômes• 1-2 jours de modélisation (toute l’équipe)• DVP

– Préparation des tests– Coder en binôme et améliorer– Tester– Une réunion par jour (suivre ce que font les autres, …)

• Acceptation par le client• Un bilan Améliorer le process

137

Rmq : à la fin de la réunion de la planification du sprint, on doit avoir : Un but pour le sprint,Une liste des membres d'équipe (et de leur niveau d'engagement , si ce n'est pas 100%),Un backlog de sprint , une date bien pour la démonstration et uUne heure et un lieu bien définis pour la mêlée quotidienne.

Page 138: Introduction à l'Agilité

Les principes

• Modéliser agile ensemble• Se mettre en binôme• Ecrire les cas tests• Tester (NOK)• Coder

– Faire simple– Suivre l’avancement

• Tester (OK)• Une personne est responsable d’une tâche• Le code appartient à tout le monde

138

Page 139: Introduction à l'Agilité

La modélisation agile

• Il faut modéliser (1 jour sur 10)• Les modèles sont faux• Un modèle agile est une peinture, pas une

photographie• Modéliser à plusieurs, jamais seul• Moins de diagrammes de classe et plus de diagrammes

d’interaction (et en //)• Ne pas passer trop de temps avec les outils, faire du

reverse après coup• Modéliser pour soi même, pas pour faire de la

documentation

139

Page 140: Introduction à l'Agilité

Développement (1)

• Faire le plus simple possible

• Pas de conception Conception émergeante

• Pas de Doc uniquement pour satisfaire le process

• 1-2 jour de modélisation sur 10

• Binômes

• Personne n’est propriétaire du code Equipe

• CR journalier + le tracker

140

Page 141: Introduction à l'Agilité

Binômes

• Il y en a un qui fait le code pendant que l ’autre fait les tests

• Il y en a un qui code pendant que l’autre le surveille

• Il y en a un qui code pendant que l’autre se repose

• Il y en a un qui tient la souris, l ’autre a le clavier...

• Cela coûte forcément deux fois plus cher

• J ’ai mes habitudes de codage...

• J ’aime travailler tout seul

• Binômer, c’est multiplier les couts

par 2

141

Page 142: Introduction à l'Agilité

142

Page 143: Introduction à l'Agilité

Binômes

• Deux personnes travaillant ensemble pour concevoir, tester, coder...• Une seule machine (standardisée)

– un conducteur: manipule la machine, réalise le travail– un observateur: propose, conseille, vérifie, et réfléchi à la stratégie globale

• Changements de conducteur fréquents• Changements de binôme fréquents• Travail dense, exigeant, productif et efficace• L’un regarde le clavier, l’autre l’écran, et on discute• Celui qui ne sait pas faire, fait, l’autre lui apprend• TDD (l’un écrit un cas de test puis l’autre le programme, programmation

ping-pong)• La programmation en binôme est épuisante et ne devrait pas être

pratiquée toute la journée• Utiliser pour la montée en compétence des nouveaux entrants et pour les

développements pointus

143

Page 144: Introduction à l'Agilité

Qualités d’ ½ binôme

Ouverture d'esprit et remise en question

Courage (de se mettre à nu)

Communication active (pas de rétention d'information)

Respect de l'autre et de son travail

Capacité à tourner (tâches, fonctionnalités, personnes...)

A se rendre non indispensable

Durée d’un binôme = 1 jour, 1 tâche (pas toujours)

Travailler à deux

Savoir partager la gloire... Et les erreurs

il est « plus facile de former un débutant (à l'agilité) que de déformer un gourou ».

144

Page 145: Introduction à l'Agilité

Cycle de vie d’un binôme

145

Page 146: Introduction à l'Agilité

Développement (2)

• Faire le plus simplement possible– Faire simple mais pas simpliste– Pas de savants

• Ne pas prendre d’expert• Se méfier des architectes

– Problème des design patterns– Homogénéité de l’équipe avant tout– Les cimetières sont remplis de gens indispensables– Faire de la réorganisation de code

• Revue (binômes)• Une seule fois (DP Template method)• Refactoring (séparation des idées)• Interdit si pas de tests automatisés• Quand?

146

Page 147: Introduction à l'Agilité

Faire le plus simple possible (1)

• Ne pas faire de conception (la bourseMauvaise spéculation)

• Ecrire les tests d’abord• Ne pas faire de sur spécification, mais penser à demain• Ne pas choisir tout de suite une architecture

– Cela permet d’en tester plusieurs– Mais, ne pas la choisir trop tard!!!

• Ne pas mettre de commentaires, ni de lignes blanches de séparation mais couper en n parties

• Compliquer le code (ex DP)– Former, convaincre sinon ne pas faire– Nivèlement par le bas, mais tout le monde comprend

• Commencer simplement• Ecrire la solution la plus simple possible pour résoudre ce cas et que ce cas

« La vérité, ce n’est point ce qui démontre, mais ce qui simplifie »— Saint Exupéry.

147

Page 148: Introduction à l'Agilité

Faire le plus simple possible (2)

If (n == 0) return 0;If (n == 1) return 1;----------------------------------------------return n;-----------------------------------------------If (n<=1) return n;Return 1;-----------------------------------------------If (n<=1) return n;Return F (n-2) + F (n-1);-----------------------------------------------If (n < 0) erreur (TBD)If (n<=1) return n;Return F(n-2) + F(n-1);

148

Cas 0 et 1

Cas 0 et 1 remanié

Cas 0, 1, 2

Cas 0, 1, 2 remanié…Cas général…

Solution finale

Page 149: Introduction à l'Agilité

Conception émergeante

Exemple de conception émergeante sur un projet XP démarré en 2002, dans le cadre d’un grand

projet télécom.

Lancé au départ avec une équipe de trois développeurs, il occupait en 2005 plus

d’une vingtaine de développeurs, avec une application qui représentait quelques centaines de milliers de lignes de code, des milliers de classes, et environ 20.000 tests.

En 2003, nous avons extrait une partie “plateforme” gérée par une équipe dédiée ……

La plateforme continue d’évoluer, et le nombre d’équipes utilisatrices augmente.

Après six ans d’évolution, le code de l’application est toujours jugé propre.

Des blocs de code des fonctions,

des fonctions classes,

des classes modules,

des interfaces sont apparues pour découpler des modules,

Certaines portions du code “poussées” dans des fichiers de configuration, etc.

le meilleur moyen pour trouver ces erreurs est d’arrêter de penser au logiciel au niveau théorique de l’analyse et de la conception, mais plutôt de se lancer, de se salir les mains, et de commencer à construire le produit. Mike Cohn

149

Le Refactoring : la solution agile pour conserver un code évolutif

Page 150: Introduction à l'Agilité

Stand up meeting

150

• Tous les jours 15 mn• Toute l’équipe• Chacun doit dire (15/6 = 2mn30s)

• Les problèmes qu’il a eu la veille si ils ne sont pas résolus• Ce qu’il pense pouvoir faire aujourd’hui• Les problèmes rencontrés

• On est pas là pour résoudre les pb, mais • pour les faire connaitre, Les noter• prendre un RV ds la journée avec le sauveur• si il n’y a pas de sauveur, il faudra réestimer la tâche US.

• Mise à jour du planning journalier (Sprint) et de la liste des PB• Si plusieurs équipes scrum de scrum

Page 151: Introduction à l'Agilité

Stand up meeting : Objectifs

• Evaluer l'avancement du travail• Identifier les obstacles(problèmes) nuisant à la

progression: Quelque chose qui génère une perte de temps ou un gaspillage de ressources

• Garder l'équipe concentrée sur l'objectif du sprint• Améliorer l'esprit d'équipe (cette réunion donne

le sentiment commun de l’engagement)• Permettre une communication objective sur

l'avancement

151

Page 152: Introduction à l'Agilité

Stand up meeting : Les erreurs

• La réunion n'a pas lieu tous les jours

• la réunion commence en retard

• Tout le monde ne s'exprime pas

• Des personnes bavardent en aparté

• Une personne interrompt les autres

• On s'adresse uniquement au ScrumMaster

• On parle de choses sans rapport avec les tâches du sprint

• Essayer de résoudre un pb compliqué

152

Page 153: Introduction à l'Agilité

Les tâches à faire (le radiateur)

153

Page 154: Introduction à l'Agilité

Ice scrum : Kanban

154

Page 155: Introduction à l'Agilité

Cycle de vie d’une User Story

155

Dvp Client

Phrase+Priorité

Discussion

Estimation

ProductBacklog/iteration SprintBacklog

Definition Test

Ecriture du test

Découpe en Tâches

Affectation des tâches

Réalisation tâches

TU

Affectation des tâches

Réalisation tâches

TU

TI [OK]

[NOK]

Page 156: Introduction à l'Agilité

Déroulement du Sprint (Iter1)

156

Rmq : Total priorité = 42Le premier jour on a de disponible 5/42

(10% du projet) Le 6° Jour on a de dispo 10/42

(25% du projet)

Page 157: Introduction à l'Agilité

Vélocité

157

Vélocité = nb de points (estimation des US) réalisés pendant une itération

Page 158: Introduction à l'Agilité

BurnDown de Sprint (Iter1)

158

Vélocité = 48-34 =14 !!!

Page 159: Introduction à l'Agilité

Burndown du produit après Iter1

159

Vélocité = 14 !!!

Beurdone - burndown

Faire une démonstration au client de ce qui fonctionne (25% du projet)Faire un bilan de l’itération (Voir plus loin)

Page 160: Introduction à l'Agilité

Iteration2

160

Supposition : Pas de pb sur iter2 (50 points)Gain priorité pour le client = 4+3*3 = 13Total 10(iter1) + 13 = 23/42 (La moitié du projet)et on avance de 9 points sur la US10(reste 16-9= 7 points pour la finir)

Gain total de l’iter2 = 50 points (RAF = 230-50 = 180)

180

Vélocité = 50

Beurdone - burndown

Page 161: Introduction à l'Agilité

Iteration3

161

Supposition : Iter3US11 est terminée (4 points cout de 55)US10 est enfin OK (5 points cout 34)

mais pas propre!!!En avance us15 OK (4 points cout 21)Velocité = 55 + 34 + 21 = 110Total point 23(iter2) + 4 + 5 + 4= 36/42 Total RAF 180 – (55 + 34 + 21) = 70

Ré estimation

Page 162: Introduction à l'Agilité

Fin du projet

162

Vélocité moyenne = 41

Faire un bilan de fin de Version ou de fin de projet : IDEM (Voir plus loin)

Page 163: Introduction à l'Agilité

Graphe : BurnDown & velocité

163

0

50

100

150

200

250

300

1 2 3 4 5

rafTotal

rafInitial

0

50

100

150

200

250

300

1 2 3 4 5

raf

raf

rafInitial rafTotal

244 0

136 30

85 30

50 50

0 50

0

20

40

60

80

1 2 3 4

velocite

velocite

Rmq : Techn Story : Attention à garder le Backlog orienté métier (ex : Indexer une table)

Page 164: Introduction à l'Agilité

Les indicateurs

• Feature et US (UC) : Estimation taille en points et Utilité (Valeur, priorité) en points ou en €• Tâches : Estimation en heures• Vélocité : nb de points réalisés en un sprint• Mesures quotidiennes

– Nb d’heures RAF pour les tâches du sprint non finies– Nb de tâches et de US restant à finir pour ce sprint– Nb de points de US restant à finir pour ce sprint

• Mesures à chaque sprint– Capacité estimée au début du sprint– Vélocité réelle du sprint– L’utilité ajoutée pendant le sprint– Le Nb de US restant à faire ds le backlog (selon les états des US)– La taille (en point) du restant à faire ds le backlog. Pour la release seulement– Le nombre de points total ds le backlog, y compris ce qui est fini– Les tests (nombre, OK, Echec, Ecrits mais pas encore passés, ….)

• Mesure de fin de release– Idem mesure de sprint, en en faisant la somme

• Autres mesures – Nombre d’obstacle (trouvé, résolus, …)– Ressources consommées par le sprint– Qualité du code

164

Page 165: Introduction à l'Agilité

Montrer des diagrammes simples (1)

165

Page 166: Introduction à l'Agilité

Montrer des diagrammes simples (2)

166

Page 167: Introduction à l'Agilité

Cycle scrum : résumé

• http://vimeo.com/4587652 scrum vivant

• Bruxellesmobilitehttp://www.bruxellesmobilite.irisnet.be/

167

Page 168: Introduction à l'Agilité

Les bilans

168

• Bilan itération : Réunion des questions QQ (2-4H , Toute l’équipe + des muets)– Préparée par le scrum master– Qu’est ce qui a bien marché ?– Qu’est ce qui n’a pas marché ?– A-t-on besoin de qq chose ?– Que faut-il ne plus faire ?– Comment ça va-t-il bien (Le moral)?– Comment peut-on améliorer qq chose ?– Qu’est ce que vous gardez sur le cœur ?

• Bilan de release : Réunion CC (1-2 Jours , Toute l’équipe + hiérarchie)– Préparée par tous (montrer l’esprit d’équipe-ROI)– IdemQQ + pompeuse Demo– mais à la Campagne + Champagne– Faire cette réunion même en cas d’échec du projet (sans champagne)

Page 169: Introduction à l'Agilité

XP-GameUn projet

• User story

• Planning game

• Product backlog

• Itérations– Sprint backlog

– Stand up meeting

– Calcul de la vélocité

– Calcul de la satisfaction client

• Bilan

169

Page 170: Introduction à l'Agilité

L’Agilité

Les tests

TDD

170

Page 171: Introduction à l'Agilité

TDDTester pour vérifier n’est pas judicieux!!!

Tester pour spécifierSpécifications executablesProgrammation par contrat

(Bertrand Meyer)

Un test comprend plusieurs scénariosCas nominal, cas aux limites,….Le test remplace la documentation

TU (Programmeur+Outils+Tracker) TR (Client + programmeur)L’acceptation n’est faite que par le client

Tous les tests sont archivés et automatisés

171

Client Programmeur

Ecrire un scénario

Passer le test Ecrire le pg

[NOK]

[OK]

Passer le test [NOK]

Remanier le code

[OK]

Passer le test

[NOK]

[OK]

Ecrire un Test

Page 172: Introduction à l'Agilité

Qu’avez-vous testé aujourd’hui?

Valtech-Test (14mn)

172

BOF Yahoo!!!

Tester pour corriger Tester pour spécifier

Organiser des campagnes de test

Tester en permanenceIC

Spécialiser les métiers du test Partager les responsabilités des tests

Page 173: Introduction à l'Agilité

Les tests Automatisés

• TU1

• TU2

• TU3

• TU4

• TU5

TU

• tr1

• tr2

• tr3

• tr4TR

173

TestSuite OK/NOK

Page 174: Introduction à l'Agilité

Les types de tests

• Tests unitaires (X-UNIT)– AAA : Acteurs, Action, Assertions (5-20 pour un scénario)– Ecrire le programme de test (cas par cas)– Générer les classes et les méthodes nécessaires– Lancer le programme de test Echec– Ecrire le programme– Lancer le test jusqu’au Succès– Archiver le test ( TestSuite )– Ecrits par le programmeur

• Tests de recette– Des outils– IHM Textuelles (automatique)– Outils de test– Ecrits par le client (test de comportement, spécification exécutable)

• Tests d’IHM• Tests de charge, Tests temps réel,….

174RMQ : Ecrire et tester le programme avant de l’écrire (TTD)

Page 175: Introduction à l'Agilité

Junit : Ecriture du TestDOC

175

import junit.framework.TestCase;

public class TestFib extends TestCase {

private Calculette c ;

protected void setUp() throws Exception {c = new Calculette(); //Acteur}public void testFibNominal(){try{int i = c.Fib(0); //ActionassertTrue(i == 0); //Assertioni = c.Fib(1);assertEquals (i, 1);i = c.Fib(2);assertEquals (i, 1);i = c.Fib(21);assertEquals (i, 10946);}catch(Exception excpt){fail();}• }

public void testFibLimites(){try{c.Fib(-1);fail();}catch(Exception excpt){assertTrue (excpt.getMessage().equals

("Nb négatif interdit"));}try{c.Fib(51);fail();}catch(Exception excpt){assertTrue (excpt.getMessage().equals

("Nb superieur à 50 interdit"));}}

Calculette

+Fib(nb: int): int

Généré par JunitAvec un return 0;

Rmq : un test peut avoir 5-20 Assertions et une dizaine de cas de tests

Page 176: Introduction à l'Agilité

Junit : Passer le testNOK

176

Rmq :Le cas de test s’arrête au premier assert en échec.

Mais les autres tests sontexécutés

Page 177: Introduction à l'Agilité

Junit : Ecrire le programme

177

public class Calculette {

public int Fib(int n) throws Exception {if (n<0) throw new Exception("Nb négatifinterdit");if (n>50) throw new Exception("Nb superieurà 50 interdit");if (n <= 1) return n;return Fib(n-2) + Fib(n-1);

}}

RMQ : Commencer simplement (return 0, return 1, return n, ……)

Page 178: Introduction à l'Agilité

Junit : Passer le testOK

178

Page 179: Introduction à l'Agilité

Junit : TestSuite(1)

179

Calculette

+Fib(nb: int): int+SommeN(n: int): int

import junit.framework.TestCase;

import org.junit.Before;

public class TestSomme extends TestCase {private Calculette c ;@Beforepublic void setUp() throws Exception {c = new Calculette();}

public void testSommeNPremierNombre(){int i = c.SommeNPremierNombre(3);assertEquals (i, 6);i = c.SommeNPremierNombre(-10);assertEquals (i, -1);}

Page 180: Introduction à l'Agilité

Junit : TestSuite(2)

180

Page 181: Introduction à l'Agilité

TU : Bouchons & inversion des dépendances

181

A

+Fqq(b: B)

B

+Fac()

IB<<interface>>

+Fac()

PA-IB

B

+Fac()

A

+Fqq(b: B)

B

+Fac()

IB<<interface>>

+Fac()

Bouchon-TU

+Fac()

A

+Fqq(b: B)

B

+Fac()

: qq

: A b : B

Fqq(b): void

Fac(): void

Page 182: Introduction à l'Agilité

IHM DOS

182

CTRL

BlalalGfgdgghdghds

E1<<entity>>

E2<<entity>>

IHM

Page 183: Introduction à l'Agilité

Test IHM Web : Selenium

183Selenium.mov (2mn)

Page 184: Introduction à l'Agilité

Outil de test Temps réelChess

184TestTpsReel.wmv (5mn)

Page 185: Introduction à l'Agilité

Visual Studio 2010 (Vidéo 1H)

185

Page 186: Introduction à l'Agilité

L’Agilité

Les outils agiles

Voyager léger

186

Page 187: Introduction à l'Agilité

Les outils

• Gestion de la configuration

• Script de fabrication

• Des outils de DVP – avec du refactoring

– TU

• Des outils de tests (Selenium, Chess, visualStudio)

• UML (reverse)

• Gestion des changements

• Gestion de projet

187

Ne pas se faire ralentir par des outils. Jetez les

Page 188: Introduction à l'Agilité

Script de fabrication

• Makeall : executable

executable : file1.o file2.o

gcc -o executable file1.o file2.o

file1.o : file1.c file1.h

gcc -c file1.c

file2.o : file2.c file1.h file2.h

gcc -c file2.c

clean : rm file1.o file2.o executable core

• Ant http://wiki.apache.org/ant/FrontPage -

188

Page 189: Introduction à l'Agilité

Gestion de Configuration

DVP

Test

Intégration

Check inCheck out

189

Mode :• lock• merge

Page 190: Introduction à l'Agilité

Gestion conf : arborescence

190

S1 S2

S1.VF S1.VO

S1.VF.1

S1.VF.2

S1.VF.3

S2.1

S1

S2

R1.1

R1.2

R2

R1

Page 191: Introduction à l'Agilité

Gestion conf : Méthode de travail

191

: binomeA : binomeB

: System gest Conf

1 : CheckOut de la BD V1.0()

2 : Travail en local() 3 [mode != lock] : CheckOut de la BD V1.0()

4 : Travail en local()5 : Consolidation()

6 : CheckIn de la BD V1.1()

7 : Consolidation()

8 : Integration du travail de A()

9 : CheckIn V1.2()

V1.2 = V1.0 + WA + WB

V1.2 = V1.1 + WB

Page 192: Introduction à l'Agilité

Refactoring

100 fois sur le métier remettez votre ouvrage

192

Solution trop lourde

Architecture complexe

•Réparer avant de continuer•Faire le ménage tous les jours, puis faire un nettoyage de printemps.•Ne pas le faire si il n’y a pas de tests automatisés OK

Page 193: Introduction à l'Agilité

Refactoring• Supprimer le code mort (mettre en commentaire dans un 1° temps)• Rechercher les doublons (Equipe de base)

– Regrouper du code dans des fonctions– Transformer les fonctions en méthodes de classe– Regrouper les méthodes par héritage ou agrégation– Faites des classes génériques (Template)

• Remonter le niveau d’abstraction (classe abstraite et interface)• Utiliser les DP (Equipe moyenne)

– Regrouper les classes dans des packages et encapsuler (Façade)– Regrouper du code dans des fonctions (Template méthode)– Supprimer les variables globales (Singleton)– Supprimer les Switchs (State-Stratégie-….)– Surveiller le couplage (Mediateur)– Garder tout private (Memento, Commande, Visiteur, ….)– Utiliser le configurateur (Fabrique)

• Généraliser par fichier de configuration (.ini, XML)• Mais, Ne rien faire si pas de tests automatisés et complets OK

– Ne pas toucher aux TR– Mais Il va falloir réécrire, modifier des TU, ne pas le faire tant que les TR ne passent pas.

• Faites des mesures de la qualité (avant et après). Affichez les résultats• Passer à la programmation orientée aspect (Equipe de course)

193

Page 194: Introduction à l'Agilité

Refactoring

194

Page 195: Introduction à l'Agilité

Gestion des changements (1)

195

Utilisateur

Admin

Developpeur

Testeur

Login

Configurer

Liste des utilisateurs

Gerer un PB

Corriger un PB S'approprier un PB

Enregistrer un PB

Rechercher un PB

Page 196: Introduction à l'Agilité

Gestion des changements (2)

196

MySQL

Serveur Web

Client

Developpeur

Admin

Bug

Produit

DM

Avec XP, il n’y a plus de Bug !!!!!!

Page 197: Introduction à l'Agilité

Les Bugs

• Un bug est un défaut• Les défauts sont rares en XP !!!• Il peut provenir:

– Du client– Du programmeur

• Mais il manque un test– Ecrire le test avant de corriger le défaut– Si nécessaire en faire une US (priorité urgente) pour le

product backlog– …… Corriger le défaut

• Et surtout, chercher l’origine de l’origine du défaut, puis y remédier.

197

Page 198: Introduction à l'Agilité

Gestion des changementsBugzilla : Etats des DM

198Doit être intégré à la gestion de conf, doit contenir ce qu’il faut pour reproduire le Bug

Page 199: Introduction à l'Agilité

Gestion de projet

199

http://www.extremeplanner.com/tour/

Ice scrum

Excel/Gapps (gratuit)IceScrum (gratuit)ScrumWorks (version gratuite et pro payante)GreenHopper - plugin JIRA (payant)Agilo (version gratuite et pro payante)Pivotal Tracker (payant)Mingle (Payant)Banana Scrum (Saas payant)TargetProcess (payant)VersionOne (payant)Confluence ?E Scum de Microsoft ?

Page 200: Introduction à l'Agilité

L’Agilité

ConclusionsApplicabilité

ROIMigration

Forfait

200

Page 201: Introduction à l'Agilité

Applicabilité de l’agilité

201

Page 202: Introduction à l'Agilité

Agilité : Les avantages

202

Page 203: Introduction à l'Agilité

Retours d’expérience(1)

203

Chrysler (la paye)Métro de NewcastlePostes de supervision TGV Madrid-Barcelone

Page 205: Introduction à l'Agilité

Microsoft

205

Visual studio 2010 – Agile•2500 ingénieurs• 4 ans• 1.500.000 fichiers-lignes sources• 61H pour Fabriquer le produit• Equipes de 10-20 personnes• Point de synchro toutes les 6 semaines Jeff Beehler : VisualS tudio Chief of Staff

Page 206: Introduction à l'Agilité

Qui : Et les systèmes critiques?

• Un nouveau projet :Air Data Inertial Reference Unit. Ce dernier est un composant essentiel du système d'information (ADIRS), qui équipera les avions de la gamme A350 XWB.

• Partenaire de longue date du groupe Thales, AdaCoreaffirme dans un communiqué que ce nouveau projet « doit permettre des avancées dans le domaine du développement de systèmes critiques à travers un certain nombre d'innovations, dont l'utilisation de méthodes de développement agiles et de techniques de programmation orientée objet. »

206

Page 207: Introduction à l'Agilité

Retours d’expérience (2)

Gains sensibles :

• Diminution du volume de la documentation,

• Diminution des coûts de pilotage du projet,

• Diminution des efforts de validation des composants,

• Une plus grande productivité,

• Une capacité à intégrer beaucoup plus tardivement les changements demandés par la maîtrise d'ouvrage, et donc de livrer un produit plus proche du besoin du client.

Michel Perron, responsable du SI .

207

Page 208: Introduction à l'Agilité

Enquête(1)

L’enquête de VersionOne (2008 sur 2319 entreprises dans 80 pays), 7 points d’amélioration conséquent :

• Le changement est facilité• La productivité augmente• Les ressources humaines sont motivées• La qualité s’améliore• Les risques diminuent• Le « Time to market » se réduit• Cohérence entre développeur et utilisateur

208

Page 209: Introduction à l'Agilité

Enquête(2)

L’enquête du cabinet Forrester (2007, sur 70 entreprises ) 4 améliorations conséquentes:

• 49% d’entre elles ont constaté une diminution des coûts d’opération

• 83% d’entre elles ont constaté une amélioration de la satisfaction du client

• 88% d’entre elles ont constaté une augmentation du niveau de qualité

• 93% d’entre elles ont constaté une hausse de la productivité

209

Page 210: Introduction à l'Agilité

Googlism (1)

• 10 Choses que Google trouve vrai:

– 1 : S’occuper des utilisateurs et le reste viendra

• L’interface est claire et simple

• Chargement instantané des pages

• L’ordre des résultats n’est jamais vendu à personne

• Les publicités doivent aider le client et ne pas lui être désagréable

– 2: …….

210

Scrum AScrum BScrum C

Page 211: Introduction à l'Agilité

Googlism (2)

• Les gens ne doivent pas utiliser leur position hiérarchique pour obtenir ce qu’ils veulent. Ils doivent avoir de meilleurs arguments, basés sur des chiffres et l’expérience. La hiérarchie doit être utilisée en dernier ressort.

• Nous détestons la bureaucratie dans toutes ses formes. Un process peut être une bonne chose, mais il doit accélérer les choses, si ce n’est pas le cas jeter le.– Dire Oui

– Essayer

– Si mauvais, refuser

• 20% pour réfléchir, innover, ….

• Petites équipes peuvent faire de grandes choses

• Pas de polémiques, utiliser des chiffres

• Mesurer tout

• Un problème : ne pas se plaindre, mais le résoudre

• Ne faites pas qq chose de mauvais parce que vous êtes pressé. Si vous pensez gagner du temps en faisant du moins bon, arrêtez vous (Que du bon!!!)

211

Page 212: Introduction à l'Agilité

Googlism (3)

212

• Affecter des priorités

• Faire simple

• Dire non

• Ne pas propager : Ne créez pas des tâches, réunions ou email si ils vont couter aux autres plus que ce qu’ils valent (1000 personnes reçoivent 1 mail * 5 mn = ½ h*m)

• Soyez concret rapidement (Commencez petit, Itérez souvent)

• Don’t just kill project : learn from them

• Travaillez ensemble

• Soyez à l’écoute de ce qui se passe dans la compagnie (Zoogler)

• Partagez toutes vos informations ( Idées, projets, délais, ….)

• Les projets doivent être petits (4-6 personnes)

• Personne ne travaille tout seul. Les solitaires sont rarement très productifs ni heureux.

• Le plein temps est bien meilleur que le temps partiel.

Page 213: Introduction à l'Agilité

Communication

213

Ex : Comment communiquer sur un Wiki ou Zoogler

Page 214: Introduction à l'Agilité

Que du bon !!!

214

• Le syndrome de la décharge (idem pour le code)– ne pas commencer– ne pas continuer– Si qq commence, nettoyer tout de suite

• Un bon code :1. passe ses tests avec succès2. ne peut être mal utilisé (code détrompé)

• Programmation par contrat• LSD : Gestion préventive des défauts et Stop the line

3. ne contient pas de redondance4. exprime clairement l'intention5. est aussi court que possible (en dernier)

Page 215: Introduction à l'Agilité

Retour d’expérienceMigration

215

Page 216: Introduction à l'Agilité

Migration vers agilité

• La migration dure

• La migration douce

• La micro migration

216

Prendre un coachEtudier l’existantS’appuyer sur les rôlesSi nécessaire faire un trie dans les pratiquesAffecter les personnes aux rôlesDémarrer un projet piloteMonter en charge progressivement(une équipe de 4, puis rajouter un binôme…)S’adapterAugmenter le nb de projets

Niveau 0 : Script de fabrication et gestion de configuration_______________________________________________Niveau 1 : Tests automatisésNiveau 2 : Intégration continueNiveau 3 : Moins de codeNiveau 4 : Itérations courtesNiveau 5 : Implication du client

Page 217: Introduction à l'Agilité

Migration : Projet Scrum de transition

Créer un projet Scrum de transition (sans Product Owner):

• Les participants:– PDG (ou un dirigeant)

– Des experts méthodes et processus

– Le scrum master du premier projet pilote

– Un ou plusieurs consultants externes experts de ces transitions

• Les actions– Evaluer le contexte : Pourquoi faire du scrum (Vision)

– Faire un Backlog d’amélioration des pratiques

– Les prendre en compte, puis itérativement : Lever les obstacles:• Sur les pratiques scrum

• Venant des personnes

• Venant de l’organisation et de la gouvernance

• Outil et matériel

217

Evaluer le contexte

Préparer l’application

de scrum

Exécuter projet pilote

Diffuser dsl’organisation

Evaluer le niveau atteint

Page 218: Introduction à l'Agilité

Les 2 projets en //

Projet pilote

Projet

Migration

Evaluer le

contexte

Planifier

Release

Préparer

Sprint1

Sprint1

Sprint2

Sprint2

Sprint3

Sprint3

Dernier

Sprint

Sprint4 Diffuser

218

Page 219: Introduction à l'Agilité

Spécificité française

• Culture des organisations– Langue– Esprit cartésien– Peur de l'incertitude

• Gouvernance : séparation MOA/MOE• Modèle économique : grosses SSII sur des contrats au

forfait• Puissance de la hiérarchie et des diplômes--------------------------- MAIS ---------------------------------• Capacité des équipes : formation, esprit d'initiative,

aime la discussion et les contacts

219

Page 220: Introduction à l'Agilité

Agilité & Forfait(Livre blanc Valtech)

220http://www.tv4it.net/contractualiser-les-projets-agiles-la-quadrature-du-cercle--permalink-4232.aspx

Contre

Pour

Page 221: Introduction à l'Agilité

Bibliographie (livres)

221

Page 224: Introduction à l'Agilité

Conclusion

224