Retravailler sur des projets logiciels

La refonte du logiciel expliquée

La refonte du logiciel est le travail consécutif qui résulte de la modification des exigences, des conceptions, du code et des tests après que certains travaux ont déjà commencé. Pour la plupart des entreprises de logiciels, cela représente 30 à 501 TP3T de l'ensemble des activités. Nous excluons généralement la correction de bugs de la catégorie des refontes logicielles. Le rework décrit généralement le travail supplémentaire qui est une conséquence du « changement des exigences ».

Refonte du logiciel – bonne ou mauvaise

Certaines refontes peuvent être considérées comme un indicateur positif du fait que les commentaires des utilisateurs orientent le changement vers ce qui est nécessaire. C’est juste si les changements étaient imprévisibles. Cependant, les niveaux de retouche typiques sur les projets logiciels s'obstinent à environ 30-50% de tous les efforts. Cela coûte à la plupart des organisations beaucoup plus cher que prévu pour fournir des logiciels.

Comment la refonte des logiciels fait grimper les coûts

Un problème particulier avec la refonte d'un logiciel est qu'elle est plus lente ou moins productive que le développement initial. En d’autres termes, écrire du code du premier coup est plus rapide que modifier ce code pour faire autre chose. En utilisant une approche standard de mesure et de productivité des logiciels, nous pouvons suivre la productivité des équipes logicielles lors de la construction initiale et lors de la refonte. Les taux de construction typiques des développeurs sont d'environ 1 Point de fonction cosmique (CFP) par jour (plage typique : 0,7-2 CFP/jour) alors que la productivité en reprise est inférieure, à 0,75 CFP par jour.

Lorsqu'une retouche est nécessaire, vous engagez l'effort de faire le travail une première fois (1 jour pour 1 CFP) puis (1,5 jour supplémentaire par CFP) de le modifier. Le coût total devient donc 2,5 jours au lieu de 1 jour.

Cette explication simple montre à quel point des projets informatiques modestes peuvent se transformer en désastres budgétaires. En suivant tôt la qualité des exigences, la probabilité d’un désastre devient prévisible. De plus, en accordant plus d’attention aux exigences de qualité, les retouches antérieures peuvent être considérablement réduites.

Les causes profondes du remaniement

Lorsque nous prenons conscience qu'une fonctionnalité que nous construisons ou avons construite n'est pas correcte, une décision doit être prise quant à savoir si elle doit être laissée incorrecte ou si elle est corrigée. Plus cette découverte est faite plus tard dans le cycle de développement, plus les retouches, les perturbations et les retards sont importants. Peu importe que l'exigence soit le résultat d'une conversation, d'une user story écrite ou d'un document écrit plus détaillé. L’inexactitude ou la mauvaise communication est probablement la cause première de la refonte. Peut-être que l’exigence initiale a été mal comprise, mal interprétée ou mal communiquée, cela se résume à une mauvaise communication. Une mauvaise communication est parfois rejetée ou présentée à tort comme des « exigences changeantes » alors qu’en réalité ce n’est pas le cas.

La plupart des changements ne sont pas authentiques

Très occasionnellement, nous constatons un véritable changement inattendu dans les circonstances commerciales au cours d'un projet qui entraîne une modification des exigences. Cependant, la plupart des exigences sont connues ou connaissables à un stade précoce. De même, la plupart des décisions architecturales nécessaires pour satisfaire à ces exigences sont connaissables (d’emblée). Parfois, l'utilisateur dit « nous ne savons pas ce dont nous avons besoin jusqu'à ce que nous le voyions ». Pour découvrir ces exigences, il faut utiliser des techniques d'élicitation supplémentaires telles que le prototypage.

La grande majorité des « modifications des exigences », et donc des retouches, sont causées par un travail médiocre ou incomplet des exigences.

Quelques causes profondes de retouche liées aux exigences (une liste incomplète) :

• Des exigences mal formulées
• Exigences connues mais non déclarées (omissions)
• Incohérences dans un ensemble d’exigences.
• Exigences non déclarées qui auraient pu être découvertes grâce au prototypage (c'est-à-dire que l'utilisateur doit d'abord voir quelque chose)
• Besoins non déclarés qui auraient pu être découverts grâce à l'analyse
• Confusion entre objectifs métiers, exigences fonctionnelles et critères d’acceptation. (mauvaise articulation).
• Confusion entre fonctionnels, non fonctionnels, contraintes et tâches.
• Et peut-être la seule raison légitime de retravailler : des exigences inconnues et inconnaissables

Le remaniement reste répandu à des niveaux élevés – Justification

La plupart des études montreront que 30 à 50% de tous les efforts consacrés aux projets logiciels sont consacrés à des retouches. Il existe plusieurs raisons pour lesquelles les niveaux de retouche restent élevés. Certaines des raisons sont rarement discutées car elles peuvent être des vérités inconfortables.

Exigences incohérentes Normes de qualité

L'industrie ne parvient pas à se mettre d'accord sur ce qui constitue de bonnes exigences. L'IIBA est une organisation qui tente de promouvoir la qualité des exigences. Pour la plupart des gens, il n’existe pas de normes formelles concernant les exigences en matière de rédaction et la qualité est généralement faible.

Éviter les communications importantes

La plupart des développeurs aiment écrire du code, ils sont souvent introvertis et ne sont pas de grands communicateurs. L'interaction humaine n'est peut-être pas si facile pour eux et ils se contentent davantage de retravailler que d'avoir des conversations préalables sur ces exigences difficiles.

Les équipes de développeurs décrivent souvent le remaniement comme du « code de refactorisation ». Ils peuvent s’adapter à des exigences médiocres et utiliser l’excuse suivante : « nous sommes agiles, nous apprenons au fur et à mesure ». Ou encore, ils pourraient dire que les utilisateurs ne savaient pas ce qu'ils voulaient jusqu'à ce que nous le leur montrions. La première est une excuse pour « ne pas apprendre avant de partir » ; ce dernier problème est un problème résolu à moindre coût grâce au prototypage.

Aucune responsabilité pour les bonnes histoires d'utilisateurs

Les user stories sont le pilier de la communication d’une équipe agile sur ce qui doit être construit. Mais qui est responsable des user stories ? Qui est chargé de s’assurer qu’ils décrivent correctement un ensemble global de besoins qui fournissent des capacités précieuses ? Différentes équipes donnent des réponses différentes, certaines disent le propriétaire du produit, d'autres disent l'ensemble de l'équipe. Le manque de responsabilité claire peut conduire à des user stories de moindre qualité, ce qui à son tour conduit à des malentendus et à des remaniements. Qui est responsable de la qualité des user stories ? Encore une fois, nous obtenons des réponses incohérentes à ces questions. Revisiter la clarté d’une user story, est un travail fastidieux qui implique au moins trois membres de l’équipe (les trois amigos). Il s’agit d’un travail long et plutôt ennuyeux qui se déroule souvent de manière ponctuelle, voire unique. Idéalement, le besoin de ces séances est réduit en regroupant l'équipe. Avec le travail à distance, la colocalisation est pratiquement impossible. Dans certains cas, le propriétaire du produit est un représentant mandataire du véritable utilisateur et du véritable expert en la matière. Tout cela conduit à des exigences de qualité inférieures.

Des contrats qui augmentent les niveaux de retouche

Lorsque le développement de logiciels est externalisé. L’entreprise à laquelle le travail est sous-traité est généralement payée au taux journalier. Pour eux, plus il y a de jours travaillés, plus il y a de jours facturés. Il peut exister certains marqueurs contractuels qui encouragent superficiellement un travail efficace, mais ceux-ci manquent généralement de mordant. En fin de compte, il est généralement dans l’intérêt de l’organisation sous contrat d’engager des niveaux élevés de retouche. C’est pourquoi nous voyons souvent les pires exigences dans les engagements contractuels. D'après mon expérience, il existe une mascarade sur l'efficacité du travail. En réalité, la plupart des entrepreneurs sont incités à prolonger le projet et à vendre plus de jours-homme. Avec des exigences médiocres, les retouches sont nombreuses et davantage d’heures facturables sont inévitables. Si vous achetez un développement logiciel sous contrat, méfiez-vous.

Causes culturelles du remaniement

Si une exigence n'est pas claire, l'équipe doit vérifier sa compréhension avant de commencer le travail. Tout malentendu potentiel est susceptible d’entraîner des retouches. Dans certaines cultures, remettre en question les exigences du client est une conversation inconfortable qu'il préfère éviter. Au lieu de cela, l'équipe peut travailler sur des hypothèses et développer ces hypothèses. Ceci est particulièrement courant sur les contrats externalisés. Lorsque les exigences sont rédigées dans une langue qui n’est pas la langue maternelle de tous les membres de l’équipe, des malentendus (et donc des remaniements) sont très probables.

Réduire les reprises

Observer et quantifier le problème

À la fin de chaque sprint, demandez-vous quelle quantité de travail nous venons de faire, c'est-à-dire une refonte par rapport à un nouveau travail. Posez-vous ensuite la question : comment aurions-nous pu éviter cela. Enfin, enregistrez l'effort supplémentaire (c'est-à-dire le coût) résultant du fait que vous avez dû effectuer le travail plus d'une fois.

Adoptez des normes pour rédiger de bonnes exigences

Notre liste recommandée d’attributs de qualité est :

1. Clair
2. Concis
3. Orienté utilisateur
4. Testable
5. Mesurable
6. Cohérent
7. Complet
8. Unique
9. Précieux
10. Sans conception

À l'exception du #9 dans cette liste, ScopeMaster vérifie automatiquement vos exigences en matière de respect de ces attributs de qualité, vous n'avez donc pas à les vérifier manuellement. (Nous ne recommandons pas la liste INVEST car elle ne couvre pas toutes les caractéristiques ci-dessus que nous avons jugées importantes.)

Utiliser des outils qui améliorent les exigences

OK, nous avons donc construit ScopeMaster exactement dans ce but. En utilisant ScopeMaster, vous exposerez et résoudrez 9/10 des types de qualité courants répertoriés ci-dessus et à un rythme environ 10 fois plus rapide que si vous le faisiez manuellement. En bref, vous pouvez vous attendre à réduire considérablement les retouches en utilisant ScopeMaster pour vous aider à évaluer et affiner vos besoins. Il existe d'autres outils de QVScribe et même d'IBM Doors, mais ceux-ci ne font qu'effleurer la surface de ce que fait ScopeMaster.

Rédigez des contrats qui incitent à de faibles retouches

Il existe plusieurs manières de résoudre ce problème. Premièrement, il faut être parfaitement conscient qu’il s’agit d’une préoccupation. N'oubliez pas que la plupart des retouches sont évitables. Nous proposons un ensemble de recommandations contractuelles qui peuvent vous aider à façonner vos contrats de développement externalisé afin de minimiser la probabilité de retouches.

Quantification de la refonte

Nous avons vu que les retouches causées par de mauvaises exigences entraînent une augmentation de l'effort de 1x à 2,5x. Il s'agit en fait d'une estimation modeste, car lorsque vous changez de direction, la perturbation d'un bloc de code peut avoir un impact négatif sur d'autres parties de la base de code, entraînant des retouches encore plus poussées.

Prédire les défauts – Utiliser des chiffres pour réduire les retouches

Des études ont rassemblé des données sur la création ainsi que sur la suppression des défauts. Celles-ci ont montré que des défauts potentiels se produisent dans chacun des artefacts clés du développement logiciel : exigences, conception, code, tests. La conséquence est que nous connaissons les potentiels de défauts de chacun et donc combien de défauts nous devons éliminer jusqu’à atteindre une qualité satisfaisante. Encore une fois, en utilisant le dimensionnement standard, nous savons que les défauts potentiels typiques sont d'environ 5 défauts par CFP, dont 1 est susceptible de correspondre aux exigences. Nous savons également que la taille moyenne d'une user story est de 5,5 CFP, et nous avons donc un potentiel de défauts d'exigences de 5,5 par user story. Cela signifie qu'à moins que nous ne soyons proactifs, ces défauts 5,5 resteront et seront retravaillés plus tard. Des outils tels que ScopeMaster peuvent détecter environ 50% des défauts dans les exigences, soit 2 à 3 par user story. Cela réduit de moitié la cause probable de la retouche.

Écrit par Colin Hammond, 35 ans d'expérience en informatique et fondateur de ScopeMaster.