Le document discute de la transition vers des méthodes agiles dans le développement logiciel, soulignant les limites des anciens modèles basés sur la production de masse et les processus en cascade. Il présente les caractéristiques et principes de l'agilité, en mettant l'accent sur l'importance des interactions humaines, de la réactivité et de la collaboration avec les clients. Des méthodes agiles populaires comme Scrum et Lean Software Development sont également abordées, décrivant leurs pratiques et origines.

1. Transition vers l’agilité
5 & 18 Octobre 2006
Greg Hutchings & Christophe Addinquy

2. Pourquoi l’agilité ?
Pourquoi l’ancien modèle est-il
inadapté…
« La logique est l’art de s’enfoncer dans l’erreur avec confiance »
Joseph Wood Krutch

3. L’ancien modèle: un paradigme inadapté
Production de masse
• Processus en cascade
• Plan détaillé
• Etapes prédéfinies
Développements de Préparer
nouveaux produits
• Approche empirique et Faire
expérimentale
• Processus évolutif et
adaptatif Adapter
3

4. Caractéristiques d’un projet classique
Projet classique
Ces caractéristiques peuvent
Etablir et suivre un plan s’appliquer (et s’appliquent
souvent !) à des
développements itératifs
Avancement défini par des
livrables intermédiaires
Assignement des tâches
Solution imposée
4

5. Des fonctions inutiles
Taux d’utilisation des fonctionnalités développées
sur les projets classiques [Johnson02]
5

6. Pourquoi l’agilité ?
Pourquoi elle est une réponse
« La logique est l’art de s’enfoncer dans l’erreur avec confiance »
Joseph Wood Krutch

7. Critères de succès des projets
Les facteurs de succès principaux [Standish98],
sur 23000 projets!
• Implication fréquente des utilisateurs
• Jalonnement fréquent
• Objets métier clairs
• Chef de projet expérimenté
• Support du management
7

8. Une recette magique ?
Q: What are the most exciting, promising software engineering idea techniques
on the horizon ?
R: « I don’t think that the promising ideas are on the horizon. They are already
here, and have been for years, but have not being used properly ».
David L. Parnas
Facteurs clés des environnements hyper-productifs:
• Développement itératif.
• Organisation simple, moins de rôles qu’à l’ordinaire (polyvalence).
• Equipe soudée et de petite taille
• L’architecte a été un développeur
• Forte composante communication
• Le noyau a été développé en premier, par une équipe très aguerrie.
8

9. L’agilité est le « nextbigthing » !
UML est un acquis, plus une innovation
 Il n’est plus une nouveauté que pour les « retardataires »
Elle est la solution à la crise chronique du logiciel (fonctionnalités /
coûts / délais)
Elle représente, non pas une évolution, mais un changement de
valeurs, par rapport aux processus classiques.
9

10. Qu’est-ce que l’agilité ?
« Just do it ! »
Nike

11. Des valeurs aux pratiques
Ce en quoi
nous croyons
Valeurs
Les lignes
directrices
Principes
La boite à
outils
Pratiques
11

12. Donner le rythme au projet
Priorité aux personnes et aux
interactions
• Plutôt que sur les processus et les outils
.L’accent est mis sur les individus, leur
expertise, l’esprit d’équipe plutôt que sur les
processus et les outils
Des applications fonctionnelles
opérationnelles
• Plutôt qu’une documentation pléthorique.
On privilégie le code testé
Collaboration avec le client
• Plutôt que négocier un contrat. Le client
devient un partenaire qui participe au projet
pour donner régulièrement son feedback
Réactivité au changement
• Plutôt que suivre un plan. Le planning est
flexible pour accepter les modifications
Voir le Manifeste agile, sur nécessaires.
www.agilealliance.org
12

13. Processus agile == solution miracle ?
Non ! « Process is a second order
effect ». Alistair Cockburn
De très loin, le facteur ayant le plus
d’influence sur la réussite des projets est
le facteur humain !
13

14. Les principes
•Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
• Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
•Deliver working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.
•Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
•The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation.
• Working software is the primary measure of progress. Agile processes promote sustainable
development.
•The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
•Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of
maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams. At regular
intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
14

15. Le marché aux pratiques
Une cause d’échec des méthodes agiles est la
tentation de « faire son marché » parmi les
pratiques
L’agilité est basée sur des valeurs et des
principes, plus que sur des pratiques
Les pratiques doivent êtres adaptées
 Utilisées si nécessaires
 Abandonnées lorsqu’elles n’apportent plus de valeur
 Adaptées lorsqu’elles ne correspondent pas au contexte
 « Inspect and adapt », principe des rétrospectives.
Se donner comme objectif d’adopter des pratiques
détourne de l’objectif final qui est la livraison du produit
fini
15

16. Adopter une méthode
agile
« I have a dream… »
Martin Luther King

17. Les principales méthodes agiles
Extreme Programming
Scrum
Lean Software Development
DSDM
Crystal
17

18. Ce qui émerge
18

19. Scrum (1 / 4)
Origine
• Basée sur les travaux de Nonaka et Takeuchi en 1986
• En 1993, Jeff Sutherland et Ken Schwaber ont
développé les pratiques initiales de Scrum.
Principales pratiques
• Élaboration et mise à jour d’un planning
produit (product backlog)
• Des itérations de 30 jours (sprint)
• Planification de chaque itération (sprint
backlog)
• Réunion d’avancement quotidienne (scrum
meeting)
• Isolement des développeurs (face au chaos
extérieur)
• Revue de fin d’itération (sprint review
meeting)
19

20. Scrum (2 / 4)
20

21. Scrum (3 / 4)
Organisation
• Des « feature teams » (et non des modules !)
 Une feature représente une tranche de fonctionalité utilisateur.
• Des équipes « cross-fonctionnelles »: la polyvalence est encouragée,
mais des experts peuvent exister
21

22. Scrum (4 / 4)
Les livres
22

23. Lean : Origines (1 / 3)
Le Toyota Production System
• L’agilité a vaincu le taylorisme
depuis le premier choc pétrolier !
23

24. Lean Software Development (2 / 3)
Les principes
• Traquer les déchets
• Effectuer les tâches en petits • Focalisation sur la
lots, à la demande production de valeur pour
les utilisateurs
• Voir le système dans son • Le manager est
intégralité (pas d’optimisation facilitateur
locale) • L’équipe est au cœur du
processus d’amélioration
• Retarder les décisions (laisser
les options ouvertes)
• Equipe soudée et motivée
(jelled team)
• Apprendre et améliorer le
processus en continu (Kaisen)
• Manager qui écoute et règle les
problèmes de son équipe
(Gemba).
24

25. Lean Software Development (3 / 3)
Les livres
25

26. Merci