Blog
Retravailler sur des projets logiciels
Explication de la refonte du logiciel La retouche 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 retouches peuvent être considérées comme un indicateur positif indiquant 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 logiciels [...]
Mesurer la dette technique – Estimation et coûts
La signification 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 initialement prévue par Ward était assez étroite et [...]
Défauts des exigences – l’intérêt de les trouver tôt
Voici quelques indications sur l'intérêt de détecter les défauts des exigences avant la conception ou le codage. Pour une équipe de développement logiciel, il est très important de détecter les défauts tôt. Mieux encore, il est possible de les prévenir complètement. D'excellentes exigences constituent une forme efficace de prévention des défauts et de prévention des reprises. Une exigence ambiguë peut entraîner un gaspillage d'efforts considérable. En prêtant attention à la détection des défauts dans les exigences logicielles, les équipes subiront moins de gaspillage et livreront plus souvent correctement du premier coup. Les défauts surviennent avant le début du codage Les défauts surviennent dans les exigences et l'architecture avant même le début du codage. [...]
Fractionnement de l'histoire – Lignes directrices et conseils
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. [...]
Élicitation des exigences – Boostée par l’IA
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 [...]
Assurance qualité des user stories – automatisée
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 [...]