L'approche "while you're in there" dit que si vous travaillez sur du code pour une histoire d'utilisateur qui s'avère avoir une dette technique, payez cette dette technique au cours de l'implémentation de la fonctionnalité décrite dans l'histoire d'utilisateur.
Au fil des ans, j'ai cessé de favoriser l'approche des histoires techniques pour soutenir l'approche "pendant que vous y êtes". La raison en est que chaque histoire d'utilisateur doit apporter de la valeur à la partie prenante. La partie prenante mentionnée dans la phrase précédente est, bien sûr, l'utilisateur final représenté par un persona, et l'utilisateur final ne voit pas directement la valeur d'une histoire technique. Nous payons donc la dette technique dans notre code pendant que nous sommes en train de mettre en œuvre une histoire d'utilisateur.
La plupart des entreprises ont le même point de vue que la plupart des projets logiciels en ce qui concerne les parties prenantes : il n'y a qu'un seul type de partie prenante. Pour les projets de logiciels, il s'agit de l'utilisateur final, et pour les entreprises, il s'agit de l'actionnaire. Existe-t-il vraiment un seul type de partie prenante pour les projets de logiciels et les entreprises ? L'un des principes fondamentaux du capitalisme conscient est qu'en reconnaissant qu'une entreprise a plusieurs types de parties prenantes et en apportant de la valeur à chacune d'entre elles, les entreprises peuvent connaître un plus grand succès et avoir un impact plus positif sur le monde.
Je ne vais pas présenter ici une thèse sur le capitalisme conscient, mais je vais mentionner que la société pour laquelle je travaille, Improving, pratique le capitalisme conscient, et que notre PDG Curtis Hite fait partie du conseil d'administration. Il vaut la peine de dresser la liste de ses convictions fondamentales :
1. Un objectif supérieur. Les entreprises devraient exister dans un but supérieur, et pas seulement pour faire du profit.
2. Orientation vers les parties prenantes. Reconnaître qu'une entreprise a plusieurs types de parties prenantes et qu'elle doit créer de la valeur pour chacune d'entre elles.
3. Leadership conscient. Les dirigeants conscients comprennent et adoptent l'objectif supérieur de l'entreprise et s'efforcent d'harmoniser les intérêts de toutes les parties prenantes.
4. Culture consciente. Une entreprise doit délibérément développer une culture qui promeut ses valeurs et son objectif d'une manière qui relie son personnel et ses parties prenantes.
Que se passerait-il si nous appliquions les principes du capitalisme conscient à un projet Scrum ? Appelons-le Scrum conscient.
Un projet Scrum conscient a un objectif supérieur, aligné sur l'entreprise, qui motive son existence et suscite l'enthousiasme des personnes qui y travaillent. Mon dernier projet à la NASA était un ensemble d'outils de planification des opérations spatiales dont l'objectif était de permettre des missions humaines dans l'espace lointain qui conduiraient finalement à l'habitation permanente d'autres mondes par l'homme. Trop grandiose ? Peut-être. Mais cela m'a donné envie d'aller travailler tous les jours ? Bien sûr que oui !
Avez-vous déjà travaillé sur un projet dirigé par une personne capable de communiquer son objectif supérieur d'une manière qui inspire les gens, et qui a créé une culture dans laquelle toutes les personnes impliquées dans le projet se sentaient comme une partie importante de quelque chose de beaucoup plus grand qu'elles-mêmes ? N'est-ce pas là votre projet préféré de tous les temps ? Le projet de boîte à outils de planification des opérations spatiales mentionné plus haut avait un tel leader, et il a été et restera toujours mon projet préféré.
Un projet Conscious Scrum reconnaît plusieurs types de parties prenantes. Quels sont les types de parties prenantes d'un projet logiciel ? Il peut y en avoir plusieurs, comme par exemple
Les utilisateurs finaux
Le responsable qui finance le projet
Les développeurs de logiciels
L'équipe d'assurance qualité
Le Scrum Master et le Product Owner
Les services de vente et de marketing
Les fournisseurs de bibliothèques logicielles, de cadres et d'outils utilisés dans le cadre du projet.
Il s'agit là de sept parties prenantes, et vous pouvez probablement en trouver d'autres. Un projet doit apporter de la valeur à chacun d'entre eux.
Que nous apprend Conscious Scrum sur la manière de gérer la dette technique ? Bien que l'approche "pendant que vous êtes là" ait de la valeur pour de petites quantités de dette technique qui peuvent être payées en une heure ou deux, l'approche "tech story" est la meilleure façon de payer une dette technique importante. Le fait de documenter la dette technique de cette manière facilite les discussions avec toutes les parties prenantes du projet concernées afin d'établir correctement les priorités.
Il n'est pas nécessaire d'entrer dans des discussions techniques pour y parvenir ; il suffit d'évaluer le coût du remboursement de la dette technique par rapport au coût de l'absence de remboursement. Comment les histoires techniques peuvent-elles apporter de la valeur à plusieurs types d'acteurs du projet ? Elles permettent au gestionnaire qui finance le projet d'économiser de l'argent. Jusqu'à quatre-vingt-dix pour cent des dépenses d'un projet ont lieu pendant la phase de maintenance (après la mise en production initiale). Dépenser un peu plus d'argent aujourd'hui pour rembourser la dette technique rapportera des dividendes plus tard.
Les utilisateurs finaux continuent de recevoir un flux de nouvelles fonctionnalités parce que le remboursement régulier de la dette technique maintient la base de code en meilleur état et suffisamment souple pour répondre aux nouvelles exigences, y compris les fonctionnalités auxquelles nous ne pouvons même pas encore penser.
Les développeurs de logiciels disposent d'une meilleure base de code, ce qui facilite l'ajout de nouvelles fonctionnalités. Le fait de travailler quotidiennement avec une bonne base de code accroît la satisfaction professionnelle et permet de retenir plus facilement les développeurs talentueux et d'attirer de nouveaux développeurs pour rejoindre l'équipe à l'avenir.
L'équipe d'assurance qualité subit moins de pression pour augmenter sa capacité de test afin de publier les histoires d'utilisateurs avant la fin du sprint, car un code défectueux résultant de la dette technique peut avoir des difficultés à passer ses tests et peut devoir être corrigé jusqu'à la dernière minute.
Le Scrum Master et le Product Owner bénéficient d'une meilleure visibilité sur le travail effectué, ce qui leur permet de calculer des valeurs de vélocité plus significatives et d'avoir une meilleure idée de l'état d'avancement du projet.
L'équipe de vente et de marketing voit également de la valeur dans les récits techniques parce qu'un flux régulier de nouvelles fonctionnalités permet de maintenir leur avantage concurrentiel, et se traduit par un meilleur produit à vendre et à promouvoir.
Scrum conscient nous amène à reconnaître et à générer de la valeur pour de multiples types de parties prenantes dans un projet logiciel, et les anecdotes techniques en font partie. Elle nous encourage également à trouver un but plus élevé pour notre travail, ce qui nous donne un plus grand sentiment de réussite et d'accomplissement.
Vous souhaitez en savoir plus sur Scrum ? Contactez nous ou consultez les nombreux cours que nous proposons chaque mois sur le sujet!
