methodes agiles
TRANSCRIPT
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é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
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
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