Processus Unifié…2.0

L’un des points forts du Processus Unifié, et plus généralement des méthodes Agiles, c’est qu’elles invitent aux revues, aux bilans, aux retrospectives… et ce qui est valable pour une itération ou sa propre activité, l’est aussi pour la méthode de développement elle même.
Ajuster à intervalles réguliers, son comportement, ses processus est d’ailleurs un des 12 principes de l’Agile Manifesto.
Jean Tabaka va même plus loin considérant le manque de « retrospective » comme l’une des principales causes d’echec dans l’adoption des méthodes Agiles par les organisations:

Agile is all about inspecting and adapting. When I walk into an organization to help it evaluate its adoption of agile, my first question is, « When was the last time you ran a retrospective, and what did you do with the recommendations from that meeting? » Agile adoption hungers for the nutrients that real retrospection brings

J’ai donc mis un point d’honneur à capitaliser:

  • Presque 2 ans à mettre en place la méthode (avec les bonnes personnes), à conduire le changement, à former puis à suivre en tant que tiers (ou en interne) son adoption dans les projets
  • Une réflexion permanente, des recherches, des lectures pour enrichir la méthode des meilleures pratiques Agiles (UP et une dose de SCRUM par exemple)
  • 3 mois d’interviews de chefs de projet, analystes, architectes et d’autres membres des équipes appliquant la méthode
  • Un focus tout particulier sur les activités liées aux tests au travers quelques formations

Au final, des points forts, des points faibles, des éléments inapropriés, non utilisés ou a contrario essentiels, le tout sans censure, pour aller de l’avant et améliorer nos propres pratiques …des résultats probants, des leviers sur lesquels s’appuyer mais aussi des difficultés.

Tout n’est pas si facile, mais je suis fier de cette version 2.0 (c’est à la mode !), et suis désormais totalement convaincu du bien fondé d’un Processus Unifié customisé, léger, ouvert et adaptable à des contextes variés (comme l’offshore par exemple).

1 Comment

  1. jc-QualityStreet
    à

    MàJ: Désolé Laurent mais ton commentaire a été supprimé …un clic inopportun au cours de ma lutte antispam. Pour les autres lecteurs, Laurent faisait le parallèle avec XP (eXtreme Programming) et soulignait l’interêt de son approche Test Driven Development

    Ma réponse à son commentaire qui elle n’a pas été supprimée: « Tout à fait Laurent, XP, sans doute la méthode Agile la plus connue avec Scrum, possede des techiques tout à fait pertinentes à intégrer dans le Processus Unifié. Je pense notamment à l’intégration continue, à la maîtrise des tests unitaires et aux user stories (chères à Mike Cohn) qui dans certains contextes peuvent s’avèrer beaucoup lègères que les Use Cases. J’ai d’ailleurs écrit un ou deux billets précisément la dessus.

    Globalement, le Processus Unifié (Jacobson, Booch, Rumbaugh 1999) est une excellente base de travail, bien documentée, qu’il faut évidemment customiser, parfois simplifier et adapter à son propre contexte dans une perspective Agile (c’est un peu la démarche de Scott Ambler de chez IBM). Les 12 principes de l’Agile Manifesto sont aussi une bonne source d’inspiration tout comme certaines techniques de SCRUM : le scrum daily meeting (chez moi ce serait plutôt 2 ou 3 fois par semaine, le burndown chart, les aides visuelles et la communication sur certaines valeurs (esprit d’équipe, engagement, courage …).

    Processus Unifié 2.0 … bon ce n’est que finalement que la version 2 de notre adaptation du Processus Unifié (une instantiation de la méthode au même titre que l’Agile Unified Process, Open UP…) avec un petit clin d’oeil à la tendance actuelle du Web … « 

Les commentaires sont fermés.