Blog

La signification et l'origine de la « dette technique » La métaphore de la dette technique (TD) dans le contexte des logiciels a été inventée par Ward Cunningham qui travaillait à l'époque sur le codage d'un système financier. Il a utilisé la métaphore pour expliquer à ses collègues financiers le raisonnement pour refactoriser et réécrire des parties de codes à mesure que la connaissance des exigences évoluait. "En prenant des raccourcis et en fournissant du code qui n'est pas tout à fait adapté à la tâche de programmation du moment, une équipe de développement encourt du TD. Cette dette diminue la productivité. Cette perte de productivité est dans l'intérêt du TD." L'explication initiale prévue par Ward était assez [...]

Voici quelques aperçus de l’intérêt de détecter les défauts des exigences avant la conception ou le codage. Pour une équipe de développement de logiciels, il est très utile de détecter les défauts le plus tôt possible. Mieux encore, il s’agit de prévenir complètement les défauts. Des exigences excellentes constituent une forme efficace de prévention des défauts et de prévention des reprises. Une exigence ambiguë peut conduire à un gaspillage d’efforts substantiel. Des défauts surviennent avant le début du codage. Des défauts surviennent dans les exigences et l'architecture avant même le début du codage. Imaginons que nous sommes dans une entreprise d'assurance et que les gens d'affaires ont décidé qu'un système nouveau (ou modifié) [...]

Découpage de l'histoire - affinement jusqu'à une granularité optimale Une histoire apparemment petite peut s'avérer beaucoup plus grande que prévu. Ce n'est que par le raffinement ou le fractionnement de l'histoire que vous pourrez découvrir cela. Le fractionnement de l'histoire peut être effectué tôt ou juste avant le sprint précédent. Nous vous recommandons de le faire le plus tôt possible pour éviter les surprises tardives. Nous considérons le « découpage d’histoire » et le « raffinement d’histoire » comme des activités très similaires. Il s’agit d’optimiser la granularité de la user story écrite. Que sont les user stories ? Pour les équipes qui peuvent colocaliser, la user story peut être simplement un rappel d'une conversation. [...]

L'élicitation des exigences consiste à découvrir les exigences réelles de l'entreprise et les exigences système de toute entreprise logicielle. Il s’agit d’abord de découvrir ce qui est nécessaire, puis d’articuler les découvertes distillées en un artefact qui peut servir de base pour décrire ce qui doit être fait. Il est inhabituel que les véritables exigences métier (et les exigences système ultérieures) puissent être rapidement identifiées. Bien que l’élicitation des exigences soit parfois appelée collecte des exigences, cette expression est trompeuse. Les besoins réels ressemblent davantage à un trésor enfoui dans un champ qu'à des récoltes pouvant être récoltées. Parfois une indication de [...]

Voyons comment et pourquoi nous pourrions vouloir garantir la qualité des user stories. De mauvaises user stories conduisent à des réunions inutiles, du gaspillage et des retouches. Améliorer la user story le plus tôt possible dans le cycle de vie du développement est un moyen efficace de minimiser le gaspillage et les retouches. L'assurance qualité est une approche systématique visant à déterminer si un « produit » répond à des critères acceptables. Pour l’assurance qualité des user stories, nous devons d’abord définir à quoi ressemble le bien ? Quelle est la différence entre une bonne user stories (et un ensemble de user stories) et une mauvaise qualité. Pour le développement de logiciels agiles, nous avons tendance [...]