Javascript is currently disabled. This site requires Javascript to function correctly. Please enable Javascript in your browser!

Performance de projet  > Estimation et suivi de projets agiles

Estimation de projets agiles-Notions de base

Dans le développement agile, les User Stories (US) sont utilisées pour capturer les exigences fonctionnelles du client et leur somme définit le produit à développer. La taille des US est basée sur la complexité relative de chaque User Story et elle est exprimée par une mesure appelée Story Points (SP).


 

Les User Stories sont priorisées selon plusieurs éléments, comme la valeur d’affaires ou leur complexité relative. Elles sont ensuite décomposées en éléments de travail (« Work Items ») qui sont regroupés et réalisés dans une itération appelée Sprint. Il faut mentionner qu’une User Story peut être réalisée dans plus d’un Sprint. Les efforts de chaque Work Item sont estimés avec un concept d’estimation basé sur les méthodes Delphi (Planning Poker) afin de planifier les efforts d’un Sprint. L’estimation de la taille (Story Points) est donc séparée de l’estimation des efforts (Planning Poker). Une fois les premiers Sprints terminés, on détermine la vélocité de l'équipe, c'est-à-dire le nombre de points qu'elle peut réaliser en un Sprint. La vélocité est réévaluée régulièrement. En mettant en relation la vélocité et le nombre de points à réaliser (le Backlog du produit), l’équipe peut estimer le nombre de Sprints nécessaires pour terminer le projet. On peut alors avoir une idée de la date de fin du projet/release.

Estimation agile-Limitations

La méthode agile a développé ses propres métriques d’estimation et de suivi d’avancement qui semblent donner de bons résultats et qui sont, selon les affirmations des acteurs principaux, très utiles pour les équipes agiles. Le portrait est cependant différent si l’on analyse ces métriques du point de vue des besoins au niveau de l’organisation.

    En effet, il n’y pas encore des méthodes standardisées d’estimation de projets agiles qui permettraient un suivi de la performance de projets agiles basé sur une méthode normalisée. Cela rend très difficile, voire impossible, la mesure et la comparaison de productivité de développement entre les projets d’une même organisation ainsi qu’entre les projets d’une organisation et ceux de l’industrie.

    Notre approche

    Notre solution pour estimation de projets agiles est basée sur la mesure de la taille fonctionnelle. Elle est standardisée, repose sur les exigences du client et permet à l’organisation d’estimer et de suivre la performance de ses projets sur une base comparable.  
    Elle est relativement facile à utiliser et peut être appliquée aux différents niveaux: Produit, Release et Itération/Sprint. La méthode est flexible, peut être adaptée à la réalité de chaque organisation et donne des résultats satisfaisants. Et, ce qui est le plus important, la méthode proposée respecte la philosophie fondamentale de développement et d'estimation agile.

    Nous pouvons vous aider à élaborer et à implanter les pratiques d’estimation de projets basées soit sur l’approche agile « standard » (Story Points, Planning poker, Vélocité, etc.) soit sur notre propre approche. En effet, l’approche RSM Techno reprend toutes les bonnes pratiques de l’estimation agile, mais avec une mesure standardisée. Cela vous permettra d’estimer la taille de Release (projet), de chaque User Story et de chaque itération (Sprint) et de comparer ces estimations entre différentes équipes ainsi que différents projets.

    L’estimation est automatisée à l'aide d'un outil et ne demande aucun effort additionnel de la part d’estimateur.

    Valeur acquise et projets agiles

    Lorsque nous parlons de la méthode de valeur acquise (MVA) et agile, il y a plus de questions que de réponses. La valeur acquise, peut-elle être appliquée aux projets agiles? Si oui, est-ce que le concept de la MVA doit être adapté afin de respecter les fondements de la méthode agile? Quel genre de mesures peut être utilisé pour suivre l’avancement et la performance des projets agiles, métriques traditionnelles(waterfall) ou métriques agiles?

    L’EVM a été habituellement appliquée au développement traditionnel de type Waterfall avec l'hypothèse que la portée (taille) du projet restera constante au cours du processus de développement. La méthode agile fonctionne dans un sens opposé: le temps est fixe et les exigences (taille) sont négociables. De nombreux partisans d'Agile pensent que MVA est trop rigide et pas assez souple pour embrasser les projets agiles. D'autre part, certains praticiens de la méthode de valeur acquise voir agile comme trop désordonné, voire non planifié et non respectueux de bonnes pratiques de gestion de projet.

    Nous croyons qu'Agile et MVA peuvent travailler ensemble. Mais pour le faire, les deux camps doivent remettre en question certains de leurs principes. Nous avons développé une approche qui définit les mesures de MVA qui peuvent être utilisées dans les projets agiles. Notre approche respecte les fondamentaux de ces deux méthodes; elle préserve les avantages de l’Agile et, en même temps, il bénéficie de la rigueur du concept de MVA. Les mesures proposées reposent sur les données produites par les membres de l’équipe agile et leur calcul est adapté au cycle de vie et à la terminologie de projet agile. Les termes agiles et les mesures MVA sont traduits afin de trouver la relation et la concordance entre eux. Les données agiles sont finalement présentées dans les rapports et dans les tableaux de bord dans une langue que les praticiens agiles ainsi que les gestionnaires du côté affaires peuvent facilement comprendre.

    La valeur acquise "agile", est-elle la "vraie" valeur acquise?

    Si l’on considère la valeur acquise telle comme standardisée par du Standard ANSI 745B, la réponse est « Non ». Mais, s’il on regarde les mesures de base de la valeur acquise, c.-à-d. la valeur de travail effectue, la valeur du travail planifié et le coût dépensé à l’heure actuel, elles ne sont pas tellement différentes par rapport à des mesures de l’approche agile. Elles peuvent avoir différentes appellations, elles peuvent être calculées de façon différente, mais fondamentalement, dans deux cas, elles doivent répondre aux mêmes questions : Qu’est-ce qu’on a planifié? - Qu’est qu’on a livré?-Combien on a dépensé?

    Alors,si la méthode peut bien répondre aux questions citées ci-haut, le nom de la méthode n’est pas vraiment important : MVA, MVA agile, Mesures agiles ou autre. Comme on le dit un proverbe chinois: "Peu importe la couleur d'un chat, ce qui compte, c'est qu'il attrape les souris."

    Asset 7