Comment limi­ter les dérives de délais et budget dans un projet Scrum

Dans cette vidéo, nous allons voir quels méca­nismes on peut mettre en place, dans le cadre d’un projet Scrum, pour résis­ter au maxi­mum aux dérives de budget et de délais que l’on peut être amené à vivre sur un projet. Et vous allez décou­vrir que dans ce cas précis, les méthodes Agiles sont très effi­caces.

Extrait de la forma­tion « S’ini­tier à Scrum et décou­vrir les méthodes Agiles »

Fonc­tion­na­li­tés et product back­log

Ce méca­nisme repose sur un simple prin­cipe de troc. Au niveau du product back­log, dans lequel se trouvent des fonc­tion­na­li­tés triées et ordon­nan­cées. En haut on place des fonc­tion­na­li­tés qui ont une forte valeur ajou­tée et en bas, celles qui ont une faible valeur ajou­tée et qui coûtent poten­tiel­le­ment chères. Elles sont symbo­li­sées par des pouces repré­sen­tant le ROI ou retour sur inves­tis­se­ment, qui ne se chiffre pas forcé­ment en euros. Il s’agit d’un rapport de la valeur ajou­tée de chaque fonc­tion­na­lité sur son coût d’im­plé­men­ta­tion. Ce coût d’im­plé­men­ta­tion a été estimé par des séances de plan­ning poker. La fonc­tion A vaut 3 points, la fonc­tion Y un point, la fonc­tion C vaut 2 points, etc… On tire de toutes ces esti­ma­tions une somme totale qui va nous permettre d’es­ti­mer le coût global de la release par exemple. C’est ce qui est illus­tré dans ce schéma.

Faire face à l’ar­ri­vée de nouvelles idées

Que se passe-t-il quand une nouvelle idée arrive en cours de route ? Et c’est ce qui arrive souvent au moment des revues de Sprint, puisque c’est le moment où les utili­sa­teurs ou leurs repré­sen­tants se projettent dans l’usage de l’ap­pli­ca­tion. Et bizar­re­ment, c’est là que les idées viennent. Souvent de meilleures idées d’ailleurs, que celles qui étaient préa­la­ble­ment iden­ti­fiées au démar­rage du projet. Dans ce cas de figure là, ce qu’il se passe, c’est que l’équipe de déve­lop­pe­ment accepte que de nouvelles idées arrivent en cours de route. Le product owner va alors expliquer son idée et l’équipe de déve­lop­pe­ment va l’es­ti­mer. On voit ici que la nouvelle idée corres­pond à la fonc­tion K et l’équipe de déve­lop­pe­ment l’a esti­mée, elle vaut 3 points.

Un simple prin­cipe de troc

C’est le product owner lui-même qui va réali­ser le prin­cipe de troc. C’est à dire qu’il va aller cher­cher dans son product back­log, et il va surtout regar­der en bas de celui-ci, quelle est la fonc­tion­na­lité ou les fonc­tion­na­li­tés de faible valeur ajou­tée, dont la somme fait au moins 3 points, et va reti­rer cette fonc­tion­na­lité là. C’est comme cela que l’on est résis­tant aux dérives de budget et de délais que l’on peut vivre sur un projet. C’est comme cela aussi que l’on peut main­te­nir l’équipe stable, puisque vous le savez peut-être, mais rajou­ter des déve­lop­peurs dans une équipe est rare­ment une bonne solu­tion. En effet, il va falloir faire monter en compé­tence ces personnes, cela va sans doute même réduire la vélo­cité des équipes à court terme. Et peut-être même la réduire à long terme si la personne a fait un mauvais casting. Et du coup, la ou les personnes recru­tées ne conviennent pas au fonc­tion­ne­ment de l’équipe ou à la situa­tion et au contexte. Voilà comment on peut mettre en place un méca­nisme simple qui permet de résis­ter au maxi­mum aux dérives de délais et de budget sur un projet.