Projet / Maintenance : Comment être agile ?

BalanceLe projet marguerite a commencé, mais nous devons toujours faire vivre le projet précédent : le projet Chardon (Oui, Marguerite et Chardon sont dans le même pré d’application :p) Comme son nom le sous-entend, le projet Chardon est un projet critique pour l’entreprise, mais c’est un aussi un projet épineux ;) Avec le P.O, nous nous sommes posés la question suivante : Le projet Marguerite va nous occuper pendant plusieurs mois. Il ne nous parait pas possible de ne rien livrer pendant cette période sur le projet Chardon : son Backlog contient une centaine d’item, certaines importantes d’un point de vue business ! Alors comment s’organiser ?1 équipe, 2 projets … 2 Backlog ! Pourquoi pas … Mais pendant combien de temps allons nous entretenir 2 Backlog ? Et bien, tant que le projet « Marguerite » restera un projet … Puis, lorsqu’il deviendra une application à maintenir, son Backlog fusionnera … Et rejoindra le Chardon :) Ok, pourquoi pas … Mais comment on fait 1 Sprint avec 2 backlog ? C’est pas gérable ! Mmm, et bien quelle est l’importance de Marguerite par rapport à Chardon ? 3 fois plus important d’un point de vue métier ? Alors nous allons faire 1 Sprint Chardon, et 3 Sprints Marguerite :)

Cette solution est une nouveauté pour nous : nous allons observer de près ce qu’elle provoque dans notre organisation. Peut-être allons nous rapidement déchanter. Et vous, qu’auriez-vous fait à notre place ?

5 Réponses à “Projet / Maintenance : Comment être agile ?”

  1. Colin Garriga-Salaün :

    Bonjour,

    si l’équipe est capable de vider le backlog plus vite que le PO n’est capable de le remplir, alors l’aventure me paraît tentante.

    Sinon mon expérience des équipes multiprojets est qu’il est difficile :
    - d’être pertinent fonctionnellement sur plusieurs projets à la fois,
    - de se refocaliser sur un projet que l’on avait laissé l’itération précédente.

    De plus, si l’on alterne deux projets itération par itération, le temps de correction d’anomalies constatées en démo passe de une itération à deux, et l’on est beaucoup moins réactif au client.

    Ce que j’ai pu voir (deux fois sur deux) c’est qu’au bout d’un moment l’équipe multiprojet décide de se diviser en plusieurs équipes dédiées.

    Attention ce n’est pas un conseil à suivre que je te donne ! Peut-être que ça fonctionnera très bien pour l’équipe dont tu fais partie. Mais si l’humeur est à la scission, dis-toi que c’est peut-être un mouvement naturel :)

    Bonne aventure !

  2. dibus :

    Bonjour Colin,
    Tout d’abord, merci pour la qualité de ce commentaire ! Je ne manquerai pas de « raconter » la suite de notre aventure :)

  3. Mathieu Petitdant :

    Bonjour,

    J’aurais tendance à aller vers le split en deux équipes, quitte à ce que le gens tournent à chaque Sprint si nécessaire.
    Où alors ne plus faire de Sprint ?… Avez-vous étudié la solution Kanban ?

    Est-ce qu’attendre 3 Sprints n’est pas trop long pour Chardon ? Surtout s’ils sont très piquants !!

  4. loulwa :

    j’ai 21 ans et je veux etre agile . comment faire ?

  5. dibus :

    Bonjour Loulwa,
    Si ton commentaire est un Spam, merci de t’abstenir.
    Sinon, peux-tu être un peu plus clair dans ta demande ?

Mettre un commentaire