dette technique

S'accorder sur la définition de fini

S'accorder sur la définition de fini

Chapitre 8 : où l'on voit que c'est difficile de s'accorder sur la définition de fini

J’ai fini de ranger ma chambre ! …

Ne pas produire de déchets

Ne pas produire de déchets

Le problème, c'est la solution

Le principe 6 de la permaculture c’est : Ne pas produire de déchets Ce principe est illustré par le ver de terre, ce qui fait comprendre le titre comme ne pas produire de déchets à l’extérieur de l’écosystème. Les vers de terre de l’écosystème se chargent de recycler les déchets. Premier proverbe Le premier proverbe est : Pas de gaspillage, pas de manque. Holmgren utilise une définition de Bill Mollison, l’autre fondateur de la permaculture :

Scrum n'est pas une méthode de développement de logiciel

Mais c'est un truc agile

La semaine prochaine, c’est Agile tour Toulouse. Ma session Scrum ? mon scrotum ! a été retenue par les organisateurs. Après le Pays Basque et Rennes, ce sera ma dernière représentation. Parmi les raisons qui conduisent au scrotum, il y a la peur. Celle qui pousse les développeurs à produire de la dette technique alors qu’ils savent bien que c’est mal. Cette situation, due à la peur et aussi parfois à l’ignorance, est ce que Ron Jeffries qualifie de Dark Scrum.
Chapitre onze

Chapitre onze

La définition de fini constitue le chapitre 11 de la troisième édition

Dans la série Suppléments en ligne de mon livre sorti, pour la première édition, il y a 4 ans, voici la Définition de fini qui constitue le chapitre 11 de la troisième édition. Le résumé en fin du chapitre La définition de fini est la pratique qui permet d’obtenir le niveau de qualité attendu à la fin de chaque sprint, pour éviter d’accumuler de la dette technique. et aussi
Les types de story dans un backlog

Les types de story dans un backlog

Où il est question de story technique, un sujet controversé

La vocation du backlog étant de collecter tous les travaux de l’équipe qui apportent de la valeur, il n’est pas raisonnable de se limiter uniquement à ce qui est visible des parties prenantes. Cette présentation des types de story reprend l’idée de Backlog in Colors proposée par Philippe Kruchten (qu’on trouvera dans ses slides sur la dette technique dont je conseille la lecture; elle donne du sens à cette notion souvent vague).

Un peu de terrain

La dette technique est bien là

J’ai assisté aujourd’hui à 7 soutenances de stage d’étudiants de Master 2 de l’IUP ISI. Dans aucune d’entre elles n’a été mentionné Scrum ou agile. Des étudiants ont parfois fait du développement itératif, certains ont eu des réunions quotidiennes, guère plus. Ça remet les idées en place. Comme je baigne dans le mouvement agile, comme je rencontre des entreprises qui y passent ou en font déjà, j’ai parfois tendance à penser (et à dire) que l’agilité est devenue mainstream.

Symptômes de la dette technique

Dette technique serait-ce le nouveau nom de la (non) qualité ?

Suite à mon premier billet sur la dette technique nique nique, Olivier nous donne une idée pour la mesurer : Estimer l’écart de coût d’une histoire utilisateur entre l’instant présent et le début du projet Essayons. Il nous faut 2 histoires utilisateur de même taille. Par exemple lors d’une séance de Planning Poker, deux histoires qui ont été estimées toutes les 2 à n points. L’estimation a eu lieu au début du projet.

Dette technique, nique nique

Trois erreurs fréquentes sur la dette technique

Le terme dette technique revient pas mal en ce moment. On en parle dans les blogs et je l’entends même dans mon équipe. Il n’est pas récent : il vient d'un article de Ward Cunningham de 1992 pour une conférence OOPSLA. À l’époque, pas d’agile ! Mais du développement incrémental et orienté objet. Cunningham utilise l’analogie avec la dette financière pour mettre en évidence que, comme les intérêts s’accumulent progressivement lorsqu’on contracte une dette, le coût de développement augmente si le logiciel a des imperfections techniques.

Pas de points pour les bugs ?

Que faire des bugs relatifs à une user story et découverts dans un sprint postérieur à la réalisation de cette story ?

Ah, un post très intéressant et très concret d'Eric Lefèvre. J’ai lu la version française Comment gérer les bugs dans le backlog de sprint (on voit que c’est une traduction de l’anglais). Eric parle d’un problème qui se pose couramment, qu’est ce qu’on fait des bugs relatifs à une story et découverts après que cette story ait été considérée comme finie ? Sa position est de ne pas les estimer en points.