41
LES MÉTHODES AGILES Khalid Nafil Email : knafi[email protected] Année universitaire : 2011/12 1

Methodes agiles

Embed Size (px)

Citation preview

LES MÉTHODES AGILES

Khalid NafilEmail : [email protected]

Année universitaire : 2011/12

1

Méthodes agiles

Introduction

Contexte de développement

Méthodologies

Approche Prédictive contre Adaptative

2

Introduction

Au cours des dernières années, Intérêt croissant pour les méthodes agiles (légères)

Alternatives aux méthodes classiques

Ont suscité l’intérêt de la communauté informatique

Orientées vers l’humain (people first)

3

Contexte de développement

Le développement informatique classique est de type “coder puis débuguer”

Les logiciels sont écrits sans plan

Longue phase de tests

Alternative : l’adoption des méthodologies

4

Les méthodologies

Imposent un processus rigoureux de développement

Objectif : rendre le développement plus prévisible et plus efficace

Maleureusement, elles ne débouchent pas sur un succès flagrant

Elles ne sont pas populaires

Elles sont qualifiées comme “bureaucratiques”5

...Les Méthodologies

L’avancement du développement est ralenti

On parle de méthodologies lourdes ou “monumentales methodologies”

6

...Les Méthodologies

...Un nouveau groupe de méthodologies est apparu :

Les méthodes agiles

7

Les Méthodes Agiles (Caractéristiques)

Moins orientés documentation

Orientées code

S’adaptent au changement

Orientées client plutôt que processus

8

Approche Prédictive contre Adaptative

Les méthodologies classiques s’inspirent des techniques d’ingénierie

Mise en avant de la planification avant la construction

On distingue entre conception et construction

9

Imprésivibilité des besoins

Les besoins, en développement logiciel, changent souvent

Les changements de besoins sont la norme

Que faire pour s’adapter ?

10

Adaptation aux besoins

Traiter les changements comme résultat d’une mauvaise analyse des besoins

Mettre en place des procédures pour limiter les changements après signature de l’utilisateur sur la base de ses besoins

11

...Adaptation aux besoins

En réalité, Fixer les besoins avec les utilisateurs du logiciel demande beaucoup d'énergie

Ce qui peut être un bon ensemble de besoins maintenant, n'est pas forcément bon dans six mois

12

PROBLÈME DE PRÉVISION

Est-il possible d’utiliser une méthode prédictive dans une situation imprévisible.

13

Contrôler un processus imprévisible

Processus adaptatifs

Les seuls plans stables sont des plans à court terme qui sont faits d'une seule itération

Développement itératif

Livraisons intégrées et testées

14

Durée des itérations

XP suggère une à trois semaines

SCRUM suggère un mois

Crystal étend plus la période

15

L’humain au centre du processus

Équipes de développement plug and play

Programmeurs comme professionnels responsables

Processus orienté vers l’individu

Leadership Métier

Processus Auto-Adaptatif

16

Équipe de développement

Dans l’approche classique

- Développer un processus où les personnes sont remplaçables

- Les rôles sont plus importants que les individus

• Les méthodes agiles rejettent cette notion de remplaçabilité

17

Équipe de développement

Les personnes sont le facteur le plus important dans le développement logiciel

L’individu compte avant tout

18

Les programmeurs sont des professionnels responsables

À la différence du Taylorisme

Reconnaître la compétence des programmeurs

Les personnes brillantes sont de plus en plus attirées par l’informatique

19

Processus orienté vers l’individu

Acceptation du processus plutôt que imposition du processus

Accepter un processus demande une motivation et l’implication de toute l’équipe

Seuls les développeurs peuvent choisir de suivre un développement adaptatif

Les développeurs doivent être capables de prendre toutes les décisions techniques

L’accès à un poste de management, signifie une perte rapide de compétences techniques

20

Rôle du leadership Métier

Les techniciens ne peuvent assumer l’ensemble du processus par eux mêmes

Requirent une assistance sur les besoins métiers

Besoin de contact rapproché et continu avec l’expertise métier

21

Le processus Auto-AdaptatifLe processus, lui même, est sujet à l’adaptabilité

Faire des revues régulières du processus à la fin de chaque itération

Qu’est ce qu’on a bien fait ?

Qu’est ce qu’on a appris ?

Qu’est ce qu’on peut faire mieux ?

Qu’est ce qui nous inquiète/étonne ?

22

Le processus Auto-Adaptatif

Ces questions vont apporter des idées pour adapter le processus à partir de la prochaine itération

Le processus, alors, s’améliore et s’adapte de mieux en mieux à l’équipe qui l’utilise

23

Les MéthodologiesPlusieurs méthodes de type agiles existent

Se ressemblent et se distinguent

On peut citer :

XP

Crystal

Open Source

SCRUM

DFD

RUP 24

La méthode XP (eXtreme Programming)

La plus connue

Apparaît en 1999 par Ken Beck de Chrysler

25

La méthode XP

Marquée par ses quatre valeurs :

La communication

Le retour d’information

La simplicité

Le courage

26

La méthode XP

Les tests sont au coeur du développement

Les tests sont intégrés dans un processus de compilation et d’intégration continue

27

Les pratiques d’XP

XP décline ses valeurs en 13 pratiques, réparties sur 3 catégories :

• Programmation

• Collaboration

• Gestion de projet

28

La famille Crystal de méthodologies

Crée par Alistair Cockburn

Très fortement adaptable aux spécifités de chaque projet

Plusieurs principes doivent être partagés par l’ensemble de l’équipe

29

Principes de la famille Crystal

La communication et la collaboration entre les membres de l’équipe est omniprésente

Le nombre de membres de l’équipe ne peut dépasser 6 personnes

Toute l’équipe doit travailler dans la même pièce

Les diagrammes de modélisation doivent être élaborés en groupe et sur tableau blanc

La collaboration avec le client est étroite

Livrer fréquemment des parties exécutables30

Démarche de Crystal

Observer les utilisateurs dans leur travail pour bien identifier les besoins

Classer par ordre de priorité les différents cas d’utilisation en concertation avec les utilisateurs

Élaboration d’une ébauche de conception, impliquant les outils à utiliser

Élaborer le planning des itérations (itération de 2 à 3 mois)

Développement des itérations31

La méthode SCRUM

Scrum est une méthode agile pour la gestion de projets

Conçue pour améliorer la productivité dans les équipes

Développée en 1996, par J.Sutherland et K.Schwaber

32

Philosophie de la méthode SCRUM

Scrum, terme emprunté au rugby, veut dire mêlée

Processus centré sur une équipe soudée qui cherche à atteindre un but

33

Principes de SCRUM

Concentrer l’équipe, de manière itérative, sur un ensemble de fonctionnalités à réaliser

Une itération, appelée Sprint, dure 30 jours

Chaque Sprint a un but à atteindre

Un Sprint aboutit sur la livraison d’un produit partiel fonctionnel

La participation du client est déterminante pour le choix des priorités dans les fonctionnalités du logiciel

34

Rôles définis par SCRUM

Le Directeur de produit

Le ScrumMaster

l’Équipe

35

Les rôles dans SCRUM36

Directeur du produit

Représentant des clients et des utilisateurs

Définit l’ordre de développement des fonctionnalités

Décide sur les orientations importantes du projet

Travaille, de préférence, dans la même pièce que l’équipe

37

ScrumMaster

Veille sur la protection de l’équipe, des éléments perturbateurs, extérieurs à l’équipe

Veille à résoudre les problèmes non techniques

Veille à l’application des valeurs de Scrum

38

Équipe

Auto-gérée

Décisions prises ensemble

Contact direct avec le directeur de produit (product owner)

39

La planification de projet

Planification à trois niveaus :

Sprint : itération de 30 jours

Release/projet : regroupement d’itérations

Quotidien : réunion (srcum) de mise au point

40

Outils pour Scrum

Outils libres :

IceScrum (open source)

Outils propriétaires :

ScrumWorks

VersionOne

41