5 erreurs de planification courantes dans le développement logiciel

Il est difficile de prédire l'avenir, même s'il existe des méthodes spécifiques pour cela. La réalité est que même la planification d'un projet simple en développement logiciel représente un défi. Il y a beaucoup de choses à prendre en compte et tout autant de choses qui peuvent mal tourner. Il est prouvé que les choses tournent souvent mal lorsque les logiciels sont livrés uniquement sur la base de prévisions. Malheureusement, cela reste encore une habitude bien ancrée.

Les erreurs les plus courantes en développement logiciel :

1. La complexité du développement logiciel est souvent sous-estimée

Le développement logiciel est souvent comparé à la construction d'une maison. Cela semble être une bonne comparaison, car à première vue, les développeurs "construisent" quelque chose. Malheureusement, le développement logiciel diffère fondamentalement de la construction traditionnelle. Quand on applique ces méthodes de planification, des problèmes peuvent donc survenir.

Nassim Nicholas Taleb décrit dans son livre "The Black Swan" deux mondes différents : "Médiocristan" et "Extrêmistan". Ces deux mondes représentent deux types d'incertitude différents.

Pour démontrer cette différence, Taleb propose l'expérience suivante :
On sélectionne 1 000 personnes différentes dans la population. Ces personnes s'allongent ensuite tête-bêche les unes derrière les autres, formant ainsi une longue ligne.

Supposons que la taille moyenne d'une personne soit de 1,68 m. La ligne mesurerait donc environ 1 680 mètres. Une ligne deux fois plus longue (3 360 m) devrait alors être composée d'environ 2 000 personnes (ayant également une taille moyenne de 1,68 m).

Que se passerait-il si 1 000 personnes supplémentaires s'ajoutaient à la ligne existante ? Cette fois, on inclurait l'homme le plus grand du monde (Sultan Kösen, 2,51 m). Dans ce cas, on n'aurait besoin que de 1 999 personnes. Même après avoir intégré un tel scénario du pire dans la planification, il n'y a donc pas de grande différence avec notre calcul initial.

Essayons maintenant la même expérience – mais avec un autre calcul :

Cette fois, on sélectionne 1 000 personnes différentes dans la population et on recense le patrimoine de leurs familles respectives. Le patrimoine moyen d'une famille aux États-Unis est par exemple de 110 000 dollars. Pour ce groupe, cela représenterait un total de 110 000 000 dollars. Ensuite, on estime la taille de coffre-fort nécessaire pour contenir le patrimoine total de 2 000 personnes. On peut calculer cette taille relativement facilement en déterminant l'espace nécessaire pour le patrimoine de 1 000 personnes, puis en le doublant.

Prenons maintenant à nouveau 1 000 personnes, mais en incluant Bill Gates. Que pourrait-il se passer ? L'estimation initiale prévoyait un coffre pouvant contenir 220 000 000 dollars. Maintenant, on en a besoin d'un pour 77 500 000 000,00 dollars. Quelle différence fait ici un scénario du pire ?

Quel est le rapport entre ces expériences et le développement logiciel ?
Si tu as déjà de l'expérience en développement logiciel, tu as certainement rencontré un problème ou un autre que tu n'as pas pu résoudre. Peut-être un bug très difficile à corriger. Ou un problème technique que tu ne peux pas résoudre avec les outils disponibles. L'estimation initiale n'était pas juste un peu imprécise, mais présentait un écart de 10 %, 20 % ou 500 %. C'est le monde du développement logiciel. C'est "Extrêmistan" (deuxième expérience), où un incident ou un élément peut avoir un impact considérable sur le résultat.

La plupart des projets de construction appartiennent au monde de "Médiocristan" (la première expérience), où les écarts s'équilibrent dans l'ensemble. Répétons l'expérience avec des gratte-ciels choisis au hasard et alignons ces bâtiments comme des dominos. Maintenant, faisons entrer en jeu le plus haut bâtiment du monde, le Burj Khalifa. Le résultat final est-il le même que dans l'exemple avec la taille des personnes ou celui avec le patrimoine ?

Comment éviter de confondre "Extrêmistan" avec "Médiocristan" ? Il est important de comprendre dans les moindres détails la nature de la tâche que l'on planifie. Si l'effort de travail d'un élément individuel peut potentiellement s'écarter fortement de celui des autres éléments, il est conseillé d'utiliser des méthodes de planification appropriées. C'est pourquoi les méthodes de planification empiriques utilisées en Scrum sont plus adaptées aux projets d'"Extrêmistan".

2. Nous ne planifions pas l'imprévisible

Les tâches complexes nécessitent un autre type de gestion des risques. Dans la planification de projet habituelle, des marges sont prévues pour les incidents imprévisibles. On croit souvent que l'imprévisible s'équilibre, le temps perdu étant rattrapé par le temps gagné. Malheureusement, cela ne fonctionne pas dans le cas d'un travail complexe.

Dans ce projet, nous sommes confiants de pouvoir livrer à la date prévue. Mais supposons que les faits en arrière-plan soient les suivants :

• Tu es une dinde
• Le progrès suivi est ton poids
• Personne ne t'a parlé de Thanksgiving. Qu'arrive-t-il aux dindes à Thanksgiving ?
  Comment te sens-tu maintenant ?

Nassim Nicholas Taleb utilise cette métaphore dans son livre "The Black Swan" pour illustrer l'impact des incidents imprévisibles. La dinde n'a jamais entendu parler de Thanksgiving et aucune marge n'est prévue. Les incidents imprévisibles ne sont pas pris en compte dans la planification conventionnelle. Mais en développement logiciel, ils sont fréquents.

Comment éviter cette erreur ? Le cadre de Scrum prévoit que des parties individuelles du logiciel soient livrées à intervalles réguliers. Le risque est réduit en livrant tôt et souvent – et non par des marges planifiées. En cas d'incidents imprévisibles, on a la possibilité de se rabattre sur ce qui a été construit jusqu'alors.

3. Nous faisons souvent aux parties prenantes des promesses que nous ne pouvons pas tenir

Si nous savons que le développement logiciel est complexe et risqué, pourquoi ne pouvons-nous pas simplement le dire aux parties prenantes ? Pourquoi faisons-nous des promesses que nous ne pouvons pas tenir ? La réponse est que les dirigeants ont besoin de certitude. Ils fixent le budget, ils doivent être sûrs que toutes les activités sont planifiées, ils veulent une deadline et ils veulent bien sûr toutes les fonctionnalités souhaitées.

Mais des engagements gravés dans le marbre sont-ils nécessaires ?
La plupart des professionnels du secteur comprennent le risque. Ils comprennent aussi qu'ils doivent souvent prendre des risques pour obtenir des rendements et des bénéfices. Très souvent, le niveau de risque est directement lié au rendement potentiel. La plupart des entreprises préféreraient un rendement garanti. Mais elles savent que les gains de tels investissements sont si faibles qu'il ne vaut souvent pas la peine d'investir. Si tout le monde le sait, pourquoi tout le monde ne le fait-il pas ?

Si les parties prenantes comprennent le rapport risque-récompense (bénéfice), pourquoi ne pas suivre le même principe en développement logiciel ? À chaque nouvelle release, il y a un élément de récompense. Dans tout bon projet, il y a un calcul de rentabilité (Return on Investment (ROI)). Si une rentabilité significative est attendue dans un projet, alors les parties prenantes doivent s'attendre à un certain risque. Parle donc avec tes parties prenantes à ce sujet. Fais-leur prendre conscience qu'ils n'obtiendront peut-être pas tout ce qui était attendu au moment de la planification. C'est le risque en développement logiciel. Cela ne signifie pas qu'on ne peut pas limiter le risque. Mais une discussion honnête devrait absolument avoir lieu.

Si les parties prenantes veulent des engagements fermes de ta part, alors tu ne devrais prendre que ceux que tu peux tenir. Engage-toi à collaborer. Engage-toi à respecter le processus convenu. Engage-toi à travailler en mettant l'accent sur la qualité. Engage-toi à une vérification et une adaptation continues. Engage-toi à garantir la transparence.

Parle avec les parties prenantes du risque et de la récompense et explique-leur que la création d'un nouveau logiciel suit le même principe. Discute des mesures d'atténuation des risques qui peuvent être appliquées. Et n'engage-toi que sur ce que tu peux vraiment accomplir.

4. Nous donnons souvent aux parties prenantes l'impression que certains travaux sont gratuits

Quand nous promettons à nos parties prenantes certaines fonctionnalités à un moment donné et pour un budget donné, ils pensent avoir payé et acheté ces fonctionnalités. En tant que développeur, tu t'es engagé à livrer ces fonctionnalités. Le risque est maintenant que les parties prenantes pensent qu'aucun coût supplémentaire ne les attend. Ils ont déjà payé et croient que toutes les fonctionnalités supplémentaires sont incluses dans le prix. La seule chose qui les préoccupe, ce sont les coûts d'éventuelles modifications. Dans son livre "Predictably Irrational", Dan Ariely décrit le changement de comportement humain quand quelque chose est gratuit :

"Partout il y a des avantages et des inconvénients, mais quand quelque chose est gratuit, on oublie les inconvénients."
Si tes parties prenantes comprennent qu'aucune fonctionnalité n'est garantie tant qu'elle n'est pas terminée, ils s'impliqueront plus souvent, prendront des décisions et feront des compromis. Ils insisteront pour que les fonctionnalités importantes soient terminées en premier, puis les moins importantes. Ils seront moins enclins à consacrer beaucoup d'efforts à des fonctionnalités qui ne sont pas si importantes.

Il faut donc rappeler régulièrement à ses parties prenantes qu'il n'y a aucune garantie qu'une fonctionnalité soit livrée comme prévu tant qu'elle n'a pas été effectivement livrée.

Pour la priorisation, il faut collaborer en permanence avec les parties prenantes pendant le projet. Les Sprint Reviews Scrum donnent régulièrement aux parties prenantes l'occasion de vérifier l'avancement du processus, de discuter des travaux à venir et de définir les priorités.

5. Nous n'agissons pas de manière professionnelle

Imagine que tu aies une opération des yeux. L'ophtalmologiste sait que cette opération comporte un risque de 10 % de complications et qu'au lieu d'une amélioration, la cécité pourrait en résulter. Le médecin décide de te cacher cette information. Il croit qu'il pourrait sinon perdre ta commande. Imagine maintenant que tu te fasses opérer et que tu perdes la vue. Puis tu découvres que l'ophtalmologiste connaissait ce risque mais ne t'en a pas informé. Il devrait s'attendre à de sérieuses conséquences. Ce n'est certainement pas la façon de faire qu'on attendrait d'un professionnel.

Serait-ce mieux si l'ophtalmologiste avertissait du risque mais disait ensuite : "Ne t'inquiète pas, je suis un très bon ophtalmologiste et je te garantis que rien ne se passera." Est-ce plus professionnel ?

Ce scénario se répète constamment dans les projets de développement logiciel. Nous mentons à nos parties prenantes. La raison pour laquelle nous mentons peut être mauvaise (amener les parties prenantes à signer le contrat), bonne (rassurer les parties prenantes) ou nous nous mentons simplement à nous-mêmes. Le résultat reste le même : c'est extrêmement non professionnel !

Pour éviter cette erreur, il faut être honnête, même si c'est difficile. Cela donne aux parties prenantes la possibilité de reconnaître les risques et de planifier en conséquence. Un professionnel utilise et promeut les fondements empiriques de Scrum et aide ainsi les parties prenantes à mieux gérer les risques.

Résumé : Erreurs de planification en développement logiciel

Il est difficile de prédire l'avenir. Quand nous planifions un développement logiciel complexe, nous commettons de nombreuses erreurs qui conduisent souvent à un faible taux de réussite. L'utilisation de Scrum permet d'éviter de telles erreurs.

Ce texte provient du blog de Steve Porter et a été traduit par nos soins en français.

Que fait un Product Owner ?

=> Apprends-en plus sur les tâches et responsabilités des Product Owners.

La réunion de Sprint Planning

=> Déroulement et conseils importants pour les Product Owners sur le Sprint Planning