S'adapter au contexte... et vice versa

Dans cet article, paru en septembre 2000 dans "Langages et Systèmes", j'écrivais page 6 "Adopter XP implique des mutations". Il me semble que cela s'applique à l'agilité de façon plus générale.

Que la mise en oeuvre d'une approche agile tienne compte du contexte, de l'environnement, me parait être une nécessité. C'est d'ailleurs un principe d'XP : adaptation locale.

D'un autre côté, être agile correspond à un changement de rôles d'identités des personnes actives du projet. Le Chef de Projet MOA devient par exemple "Client" XP ou Product Owner Scrum. Ce n'est pas le même rôle. Dans cet ordre d'idée, laisser à penser qu'un Chef de Projet MOE se transforme naturellement en ScrumMaster ou Coach agile est à mon sens démagogique. Un peu comme un bon technicien ou ingénieur qui deviendrait naturellement bon manager... Ou un bon mathématicien qui deviendrait bon prof de mathématiques. D'autant plus que cela ne facilite pas la prise de conscience de la différence des rôles.

Cette différence de rôles, de pratiques,  de responsabilités... est due à un autre changement, encore plus profond : le projet lui-même change, dans le cadre d'une transition vers l'Agile. Pour être clair, le point focal n'est pas le projet, plutôt le produit. Habituellement, nous avons deux phases macro pour un produit :

1. Développement (y compris pré-étude), qui se concrétise par la mise en exploitation
2. Maintenance, bien souvent prise en charge par une équipe différente.

Dans une approche agile, centrée sur le système et les livraisons fréquentes, le schéma est :

1. Exploration ou "sprint 0"
2. Première version (à Tzéro + 3 mois par exemple)
3. Deuxième version (à + 3 mois...)
4. etc

Si l'Agile s'adapte au contexte, ce contexte - et les personnes qui le composent - s'adaptent à l'Agile. Il s'agit de "virer sa cutie" : de CP MOA on devient Product Owner, de Développeur on devient Extreme Developpeur, etc.

Agile... ou pas ?

Un lien vers un billet posté sur le site de l'asso SIGMAT : Agile... ou pas ?
Que signifie "être agile" ? Comment juger de la pertinence, de l'efficacité, de l'agilité si elle n'est pas véritablement déployée ?

L'agilité consiste en un changement de vision, de perception de ce qu'est un logiciel, de ce qu'est un "projet" de développement, de ce qu'est notre rôle dans ce "projet". Cela ne se fait pas simplement en le décretant ! D'où l'importance de bien démarrer, de bien comprendre les enjeux, les changements et la conduite de ces changements.

Soirée "Agile" à Marseille, le 17 mars

J'aurai le plaisir de participer à cette soirée, organisée par ViaXoft le 17 mars à partir de 18h00. Toutes les infos sur le blog "Esprit agile". 

Ce sera une bonne occasion de présenter l'Extreme Programming, Claude Aubry présentera Scrum.  Ces deux méthodes « phares » se consolident mutuellement : en 1996, Scrum apparaît avec une idée-force : « Un processus de développement de systèmes est imprévisible ». De fait, Scrum est alors un cycle itératif incrémental « court » : un mois. C'est tout Scrum.

L'Extreme Programming apparaît en 1999, via l'ouvrage phare de Kent Beck : Extreme Programming Explained. Si XP s'inspire de Scrum (itératif court), cette nouvelle approche est un véritable système, une constitution :

 - Rôles, Droits de chacun
 - Valeurs (Communication, Feedback, Simplicité, Courage, Respect) et Principes (adaptation locale, assumer la simplicité, voyager léger...)
 - Pratiques, qui se déclinent en :
 - Planification (Equipe complète, User stories, Tests-Client...)
 - Développement collectif (Rythme durable, intégration continue, métaphore...)
 - Fabrication du système (TDD, refactoring, conception émergente).

Scrum s'inspire alors de XP, une nouvelle version apparaît en 2004, qui intègre plusieurs apports.

Aujourd'hui, l'Extreme Programming offre cette palette de pratiques, pour la plupart indispensables à une véritable mise en oeuvre "agile" : tests-client, intégration continue...

 

l'Association SIGMAT

L'association SIGMAT est née. Vous souhaitez participer, partager vos expériences... et vos questions sur les méthodes agiles et leurs pratiques ? Consultez le site de l'asso.

Concepts objet et Conception : UML agile

Un article du site consacré à la  Conception objet avec UML .

• Ce qu'est la modélisation
• Les concepts objet
• Les principes de base d'une véritable conception objet 
• Structurel et Dynamique d'un système d'objets
• Consolidation réciproque de ces deux piliers de la conception (Structurel et Dynamique)

Un programme « objet » est constitué d'objets qui communiquent. Chacun assume une certaine  responsabilité dans ces échanges. C'est cela l'objet.

Modélisation agile : Expression de besoins avec les cas d'utilisation

Cet article : Expression de besoins agile du site Être Agile présente un processus d'expression de besoins basé sur les cas d'utilisation de l'UML. Le maintien du modèle (dans un modeleur) les différents rôles est également traité.

Les niveaux de cas d'utilisation, tels que formalisés par A.Cockburn, sont étudiés.