UP et une dose de SCRUM

Le Processus Unifié (UP) et SCRUM partagent une même démarche: itérative, incrémentale, pilotée par les risques, cadencée par le time boxing et par des livraisons fréquentes. Il s’agit de deux Méthodes Agiles, même si pour certaines instanciations d’UP il y a souvent débat et même si SCRUM possède incontestablement plus de légèreté et de dynamisme. Et c’est ce côté dynamique qui me semble trés pertinent.

On retrouve déjà dans le Processus Unifié pas mal d’éléments de SCRUM, mais dans une terminologie différente:

  • Backlog produit = « Liste des exigences », fonctionnelles ou non (ergonomiques, performance, sécurité …) (UP)
  • Backlog de Sprint = « Plan d’itération » (UP)
  • Produit partiel utilisable = « Prototype » en début de projet (phase d’Elaboration par exemple), ; « Produit » ensuite, (UP)
  • Revue de Sprint = « Réunion de fin d’itération » (UP)

Au sein de nos équipes, le pilotage par les risques est très apprécié mais le concept d’itération est ce qui est le mieux perçu (malgré certaines difficultés dans la pratique), tout comme les livraisons intermédiaires. Toutefois l’itération en elle-même me semble manquer de pêche (ça démarre fort, ça se termine pas mal, mais au milieu il y a comme un peu de flottement…)

Le remède ? pourquoi pas ces techniques issues de SCRUM que le chef de projet (un chef de projet agile et pas un ScrumMaster) s’approprierait:

  • Le scrum daily meeting (réunion d’équipe de 15 minutes maximum où chacun décrit où il en est…)
  • Le burndown chart (graphique d’avancement, non figé, permettant de constater trés facilement le « reste à faire » sur un sprint)
  • Les aides visuelles du SCRUM (par exemple, un grand tableau ou un mur distinguant les tâches en cours, celles non initiées et celles terminées, et des cartes pour chaque tâche à réaliser ; des cartes, un mur des choses que nous connaissons en Ergonomie des sites ou applications web)
  • La communication sur certaines valeurs (esprit d’équipe, engagement, courage …)

J’attends de mettre ça en pratique sur mes prochains projets.
Pour le reste, le Processus Unifié correspond davantage à nos besoins notamment au niveau de la description et de l’enchainement des disciplines et activités, de la définition des rôles (trop succincte à mon goût dans SCRUM) et du focus sur la qualité.

4 réflexions au sujet de « UP et une dose de SCRUM »

  1. claude aubry dit :

    Comme de toute façon le RUP (processus unifié) n’est qu’un cadre et doit toujours être adapté au contexte du projet ou de l’organisation, c’est une bonne idée de l’adapter en introduisant des bonnes pratiques de Scrum.

    Sur des projets nouveaux, avec une techno nouvelle aussi, je trouve utile de garder les phases du RUP et de ne faire du Scrum qu’à partir de la phase de construction.

  2. Merci Claude pour votre commentaire. Il s’agit du premier de ce blog. Effectivement UP propose un cadre formel des plus utiles; maintenant à nous d’être vigilant pour éviter les mauvaises interprétations, pour ne pas se laisser enfermer par ce cadre et pour rester « agile ».

    Nouveau projet et techno nouvelle, est-ce le seul cas où vous avez besoin d’un découpage en phases UP ?

  3. En gros quand on applique Scrum, il y a 3 phases. La première est l’équivalente de l’inception, la dernière de la transition. De mon point de vue avoir une phase d’élaboration distincte de la construction ne se justifie que si l’on est pas capable de mener des sprints avec résultats significatifs. Dans ce cas de résultats chaotiques, je suggère une phase d’élaboration.

  4. Pour ma part, j’utilise déjà depuis un certain temps la combinaison des deux méthodes.
    J’utilise UP pour la partie visible du projet qui permet de mettre en évidence une structure rassurante pour le client et les décideurs et je mène les itérations d’élaboration et de construction comme un sprint Scrum. Cela me permet de bénéficier de la productivité liée aux méthodes agiles et de limiter l’assignement de tâches unitaires individuelles. Je profite également d’introduire un certain nombre de bonne pratique XP dans le développement (développements pilotés par les tests, intégration continue, détections anticipées des défauts).
    Je continue à utiliser UML mais comme outil de communication plutôt que comme outil de documentation.

Les commentaires sont fermés.