juin
14
Ken Schwaber à Jazoon : coûts totaux et retour sur investissement pour Scrum
Filed Under Conférences | Leave a Comment
Methods & Tools est le sponsor de nombreuses conférences, mais je ne trouve pas le temps de participer à la majorité d’entre elles. Au début du mois, j’ai suivi en partie Jazoon, un des principaux événements Java en Europe, qui se déroulait à Zürich. Ken Schwaber, un des « créateurs » de Scrum, a présenté une séance sur la dette technique. Ce fut un exposé intéressant, un peu gâché par une partie finale qui consistait à faire la publicité pour les cours des certifications offertes par Scrum.org.
Ken Schwaber a commencé par dire que l’on ne considérait souvent que les coûts de la phase de développement et non ceux encourus sur toute la durée de vie du système. De ce fait, on ignore l’impact de décisions à court terme sur un retour sur investissement basé sur le long terme. Celui-ci peut être mesuré par différents aspects, comme le nombre de fonctions de valeurs que propose l’application ou par l’absence de fonctionnalités sans intérêt.
Ken Schwaber à Jazoon
Figure 1. Ken Schwaber
Il présenta ensuite sa vision de la notion de qualité pour un développeur:
* je peux comprendre le logiciel
* je peux modifier le code sans effets secondaires
* je peux valider les fonctionnalités après une modification
Ceci conduit à un exercice où il demanda à l’assemblée de se mettre d’accord par petits groupes de voisins sur la définition de la notion de « terminé » (« done ») dans le contexte d’équipes multiples qui développaient un logiciel commun. Il demanda ensuite si la définition trouvée incluait :
* les tests de performance
* les tests de stabilité
* l’intégration avec les autres équipes
* les tests d’acceptation utilisateurs
* les inspections de code.
Son message est qu’il faut avoir une idée précise de ce qui est nécessaire pour livrer le logiciel à l’utilisateur, sinon vous risquez d’avoir la même « marche forcée » durant la phase de « stabilisation » d’un projet agile que pour un projet traditionnel. Il s’est souvenu d’une propre expérience pénible lors des débuts de Scrum lorsqu’il a dû expliquer à une utilisatrice que même s’il jugeait le sprint « terminé », il lui restait encore des choses à faire avant que l’utilisateur puisse prendre possession de l’application. Lorsque vous avez une différence entre les résultats des sprints et le vrai état de « terminé », vous augmentez à chaque sprint un passif caché qu’il faudra résorber avant de livrer l’application.
Nombre de défauts pour deux stratégies différentes
Figure 2. Nombre de défauts pour deux stratégies différentes
Le graphique ci-dessus montre l’évolution du nombre de défauts pour la même équipe de développement. Dans la première version, les tests d’intégrations n’étaient pas inclus dans les sprints. Le nombre de défauts découverts a augmenté fortement à la fin du projet. Pour la version suivante, l’équipe a pratiqué des tests d’intégration lors de chaque sprint. Le nombre des défauts découverts est resté sous contrôle et le projet a été terminé avant la date prévue de livraison.
« Nous n’avons pas assez de temps » est l’excuse souvent présentée par les équipes pour ne pas inclure les activités nécessaires durant les sprints. Ces mêmes activités devront cependant être réalisées plus tard avec un coût plus élevé. De plus, en accumulant du mauvais code on crée une dette technique qui ralentit la vitesse du projet. Ken Schwaber a défini Scrum comme une approche légère sans pratiques techniques. Ceci a été fait intentionnellement parce qu’on estimait que les développeurs étaient mieux à même de savoir ce qu’ils avaient à faire. A la grande surprise de Ken Schwaber, les trous techniques n’ont pas été remplis. Il a cité un sondage de Jeff Sutherland qui a découvert que 50% des projets qui se réclamaient de Scrum n’utilisaient pas une approche itérative et incrémentale. C’est ce que Martin Fowler appelle le « Flaccid Scrum« .
Ken Schwaber a utilisé les 10 dernières minutes de sa présentation (déjà écourtée par rapport à la durée prévue) pour présenter, je devrais plutôt dire « faire de la publicité pour « , les nouvelles certifications (Professional Scrum Developer) proposée par Scrum.org. Il a ainsi mentionné plusieurs cours proposés par un partenaire local. Ceci m’a donné l’impression que les aspects financiers liés aux certifications pourraient avoir été dans les raisons principales de son départ de la Scrum Alliance.
Toutes les présentations de la conférence sont disponibles sur le site web de Jazoon. Les vidéos de certains sessions devraient être disponibles à une date ultérieure sur l’excellent site Parleys.