Gestion de portefeuille et programmation agile

Lorsque Kent Beck a articulé pour la première fois les principes de la programmation agile, il a été le fer de lance du plus grand changement de méthodologie logicielle de ces vingt dernières années, et donc peut-être de tous les temps dans un art aussi jeune. Comme je ne peux espérer améliorer son exposition des principes synergiques de l'Extreme Programming, je voudrais expliquer comment la programmation agile est liée à la gestion de portefeuille et en particulier au besoin critique de donner aux cadres la transparence sur le statut d'un projet logiciel. Voici plus d'informations sur la gestion de portefeuille et la programmation agile.

Comme l'écrivent Pat Durbin et Terry Doerscher au chapitre 2 de leur récent ouvrage Taming Change with Portfolio Management sous le titre "The Elusive Nature of Knowledge Work" :

Le travail de connaissance est difficile à planifier, à estimer et à réaliser. Contrairement au travail physique tel que la construction ou l'assemblage de composants, les activités basées sur la connaissance sont souvent des entreprises uniques en leur genre, sans comparaison historique directe à des fins d'estimation. Le travail basé sur la connaissance manque également d'indicateurs discernables de progrès.

Le concept de Velocity dans la programmation extrême, ou programmation agile, est une tentative de fournir un indicateur discernable de la progression des projets logiciels.  Il répond à une question simple mais cruciale pour un dirigeant d'une entreprise de logiciels :

Sommes-nous près d'avoir terminé ?

Cela permet donc de répondre à la question la plus intéressante :

Quel est le meilleur compromis entre ce que nous voulons (notre demande) et ce que nous pouvons faire dans un laps de temps donné (notre capacité) ?

La vélocité est la quantité de travail accomplie par une équipe dans une période de temps fixe, mais répétitive, appelée un Sprint. À Planview, nous utilisons des sprints de deux semaines. Cependant, la complexité des tâches de programmation, appelées Histoires, varie considérablement, de sorte que vous ne pouvez pas simplement compter les tâches. Vous mesurez plutôt la complexité d'une tâche accomplie dans une mesure abstraite. Chez Planview, nous appelons cette mesure Story Points, mais vous pouvez les appeler "complexitrons" ou ce que vous voulez. Chaque tâche doit être estimée de manière cohérente dans ces Story Points.

Si vous mesurez le nombre de Story Points achevés dans plusieurs sprints par une équipe particulière, vous disposez de la meilleure mesure encore conçue pour prédire la quantité de travail qui sera achevée avec succès dans le prochain Sprint par cette équipe. Si vous avez estimé toutes les tâches en Story Points, vous pouvez prévoir, avec une précision raisonnable, quand le projet sera terminé. Pour un dirigeant, un gestionnaire de portefeuille ou un chef de projet, cette transparence permet une bonne prise de décision.

Il existe toutefois quelques clés subtiles en matière d'estimation, de Story Points et de vélocité que l'expérience nous a enseignées :

• Toute l'équipe participe à l'estimation.
• L'estimation d'une histoire ne doit jamais changer une fois qu'elle est décidée. Le temps peut montrer que l'estimation est erronée, mais modifier l'estimation revient à dire à un débiteur qu'il doit deux fois plus que ce qui avait été convenu précédemment, sans raison.
• Une histoire peut être divisée en plusieurs histoires plus petites, mais les Story Points, comme l'argent, l'énergie et l'élan, doivent être conservés.
• Les estimations faites rapidement, en se fiant aux pensées ineffables d'un programmeur compétent, sont à peu près aussi bonnes que les estimations détaillées.
• Attendez-vous à ce que la vélocité dans un sprint donné varie d'environ 40% autour d'une moyenne de plusieurs sprints.
• L'écriture d'une histoire est un art, mais ce n'est pas un art noir. Une équipe et son chef de produit devraient être en mesure d'écrire 15 histoires raisonnables en une heure. La perfection n'est pas meilleure que le "suffisamment bon". Ne permettez pas que le parfait devienne l'ennemi du bien.
• Lorsque les programmeurs ne sont pas d'accord sur les estimations, résolvez le désaccord par consensus et discussion.
• "Fait" signifie "Libérable". Une tâche n'est pas terminée tant qu'elle n'est pas libérable. Vous n'êtes peut-être pas prêt à expédier une seule histoire, mais si cette histoire n'est pas réalisée au niveau de qualité exigé par vos clients, elle ne compte tout simplement pas...

Articles similaires

Gestion de portefeuille de produits La gestion de portefeuille de produits à l'ère du numérique [Webinar]. 1 septembre 2017

Gestion du portefeuille de produits C'est officiel ! Le point de vue de Gartner sur la convergence de la gestion du portefeuille de produits et de la gestion du cycle de vie des produits 8 mars 2017

Gestion du portefeuille de produits, vision et tendances Le 2018 L'enquête sur la gestion du portefeuille de produits met en lumière les entreprises les plus performantes [Vidéo]. 19 juin 2018