Un processus Agile enrichi ?

22 08 2006

Ivar Jacobson, personne influente dans le processus UP et dans UML, nous annonce sur son site le lancement du processus EssUp, pour Esssential Unified Process. Une courte présentation vante ses mérites et ses nouveautés. C’est vrai qu’il y a de l’idée dedans, de bonnes idées même.

A l’heure de la fin de mon stage, je commence à douter de certains concepts des méthodes Agiles, et notamment le paradigme de la “super-équipe”, où les développeurs sont des gens qui regorgent d’esprit d’équipe et d’enthousiasme, des gens intelligents, aptes à la discussion technique polémique, à l’analyse rationnelle des alternatives possibles ; bref des développeurs parfaits. Ils sont surtout capables de s’adapter au mieux à toutes les situations et tous les contextes. Et là, j’ai vraiment des doutes. Un développeur (au sens large), par définition, aime bien que les choses soient bien cadrées : je dois faire ceci à tel moment, produire cela, et j’utilise telle technique pour y arriver. Mais en même temps, il ne faut pas qu’il ait trop de contraintes, sinon ça ne lui plaît plus. Et puis il a ses habitudes, ses envies, et il veut aussi faire ce qui l’intéresse au moment où ça l’intéresse. Comme disent les marseillais : fas cagat.

Mais revenons à EssUP. Il me semble que ce processus reprend un certain nombre de principes des méthodes Agiles, mais en mieux “cadré”. En effet, il a été bâti à partir de l’expérience de trois approches différentes de projets informatiques : CMMI (amélioration de processus), RUP (processus ultra-cadré), et Méthodes Agiles (freestyle ;) ). Et l’idée phare, assez novatrice, c’est qu’au lieu de tenter de définir le processus-ultime-de-la-mort-qui-tue (RUP), ou le processus-que-l’équipe-elle-fait-tout-parfaitement (Agile), on va utiliser un processus basique, itératif (ça on en a vraiment besoin, c’est prouvé) qu’on va enrichir de bonnes (?) pratiques en fonction des besoins du projet.

Ils apellent ça Separation of Concerns (SOC pour les intimes), encore décrit comme Aspect-Oriented Thinking. Littéralement, on se dit que ça parle de “séparation des considérations”, des façons d’aborder les différents aspects d’un projet. Après approfondissement de la question, on utilise en fait des pratiques, indépendantes les unes des autres, que l’on assemble dynamiquement pour se construire son propre processus bien adapté au projet. Cette idée, elle existe pourtant déjà dans les méthodes Agiles, et plus précisément dans Scrum, puisqu’on ne précise pas comment doit être réalisé le logiciel à l’intérieur de chaque sprint : l’équipe détermine (ou plutôt est censée déterminer) quelles techniques/pratiques elle va utiliser pour produire son logiciel.

Mais pour moi, ce qu’apporte vraiment EssUP, c’est l’approche et l’organisation des pratiques. En effet, l’idée directrice est de connaître l’indispensable, le coeur de chaque pratique, et au besoin, suivant le projet et la situation, l’approfondir et l’appliquer au projet. Ces pratiques sont ainsi organisées en “familles” (Architecture, Itération, UseCase, Composant, Modèle, Produit, Processus, et Equipe), et chacune est décrite en deux niveaux. Le premier niveau concerne l’essentiel, et il est représenté sous forme d’une fiche imprimée ou virtuelle. Cette fiche propose ensuite des références sur des documents et outils plus détaillés pour approfondir la pratique, et atteindre ainsi le deuxième niveau de précision.

Qu’est-ce qui est bien là-dedans ? On donne de la vie au processus. Manipuler des fiches synthétiques permet d’avoir une vue pertinente pour adapter le processus au projet, de bien s’organiser avec le niveau de précision adapté à cela. Et une fois qu’on veut appliquer le processus, on dispose des informations détaillées pour être prêt à passer à l’action. Les fiches peuvent être annotées, modifiées, ou créées pour une circonstance donnée. J’imagine bien un tableau dans la salle de l’équipe, avec des fiches épinglées qui modélisent le processus appliqué. Et au besoin, d’une itération sur l’autre, on adapte les concepts utilisés pour agir au mieux.

En résumé, EssUp conserve la flexibilité des méthodes Agiles tout en fournissant le niveau de détail de UP à la demande, et en permettant de faire évoluer sa propre démarche de développement. Pour moi, c’est une méthode Agile en plus “cadrée”, et j’en reviens au paragraphe sur la “super-équipe” : il faut pouvoir laisser à l’équipe la souplesse de décider comment organiser son travail au niveau global, mais en lui fournissant des guides sur la bonne façon de le réaliser, sinon ça risque de partir dans tous les sens…

 

Quelques citations intéressantes en vrac, mais dans l’ordre :

  •  Tout le monde reconnaît le besoin de processus pour améliorer la façon dont les logiciels sont développés. Tout le monde reconnaît le besoin d’agilité, de flexibilité et d’adaptabilité [et de] qualité. UP est devenu trop lourd, [CMMI] nécessite trop de travail contraignant, et le camp Agile a promis trop de choses. Nous avons besoin de changer fondamentalement notre façon de concevoir, configurer, enseigner, adopter et déployer les processus.
  • En partant d’une plateforme générique, vous décrivez votre propre processus en utilisant une technique très simple [...]. Vous prenez ce dont vous avez besoin et ce dont vous pensez que votre organisation pourra l’adopter sans prendre de risques majeurs.
  • Nous avons appris au fil des ans que très peu de gens lisaient réellement les documents de processus, que ce soit dans un livre ou sur le web. [...] Fournissons-en la véritable essence et laissons-les apprendre le reste de la façon qu’ils veulent.
  • [EssUP] ne rend explicite que l’essentiel. Le reste est soit tacite soit référencé depuis l’essentiel.
  • [EssUp] sépare deux genres d’artefacts : les alphas et les bétas. Les bétas sont l’évidence des alphas. [Exemples d'alphas : projet, système implémenté, backlog, risques. Exemples de bétas : Projet>>plan de projet, plan d'itération - Backlog>>liste de fonctionnalités, liste d'évolutions/bugs]. Alors que les alphas sont stables et indépendants du processus, les bétas peuvent être différents en fonction des pratiques que vous avez choisi d’utiliser. [Cette séparation] réduit la documentation du projet au minimum. Nous pouvons discuter précisément de quelle quantité de documentation nous allons produire.
  • Vous pouvez adopter toutes les pratiques, seulement celles dont vous avez besoin, une seule pratique, ou une portion de pratique. Vous pouvez mélanger et faire correspondre les pratiques pour répondre à vos besoins, écrire vos propre pratiques pour étendre le processus [...].
  • Les fiches amène le processus à la vie et le rendent plus visible qu’un site web ou un livre statiques.

Actions

Informations

Laisser un commentaire

Vous devez être connecté pour poster un commentaire




Parse error: syntax error, unexpected '/' in /mnt/106/sda/6/e/prog13/wp-content/themes/freshy/footer.php on line 18