introduction
L’année dernière, notre équipe ici à insightsoftware.com, les fabricants de Hubble, est passée de Scrum à une approche de développement de logiciels Kanban. Dans mon dernier article sur Mind the Product, j’ai partagé mes idées sur notre transition car nous étions en plein dans le vif du sujet. Dans ce post de suivi, je veux partager quelques réflexions et conclusions plus développées de moi-même et de notre équipe de développement.
Retour sur 2017
Pouvoir évoluer en permanence mais sortir périodiquement a toujours été l’objectif de notre équipe. Comme la plupart des équipes de développement, nous savons à quel point cet objectif peut être difficile. Avant de passer à Kanban, nous avons établi une liste de priorités sur lesquelles nous voulions nous concentrer au cours de l’année. Chacune de ces priorités soutient notre objectif principal.
Avec notre objectif en tête, nos priorités début 2017 étaient:
- Avoir plusieurs équipes interfonctionnelles travaillant sur le même backlog de travail, ramassant les prochains éléments les plus précieux du backlog.
- Pour réduire le temps consacré aux tests de régression.
- Organiser des sessions occasionnelles de planification des fonctionnalités lorsque les équipes sont à court de travail.
Où nous sommes en 2018
Succès
En général, Kanban nous aide à gérer notre flux de travail, il est particulièrement utile de combiner le travail de nombreuses sources en un flux de travail échelonné sur plusieurs équipes.
- Équipe multiple, un carnet de commandes. Nous avons quatre équipes de produits travaillant sur le même arriéré de travail, y compris la correction des défauts et des éléments hautement prioritaires au fur et à mesure. Un chef de produit gère le backlog et définit les priorités. Les Scrum Masters aident à répartir le travail entre les équipes en fonction de la disponibilité de l’équipe. Toutes les équipes sont considérées comme égales!
- Réunions de planification ciblées. Nous organisons des réunions de planification uniquement lorsqu’une nouvelle fonctionnalité est prête à être introduite. Cela pourrait être une fois par mois ou plus fréquemment si une nouvelle fonction urgente est identifiée. Sinon, les équipes travaillent à partir du backlog partagé en ramassant les éléments prioritaires.
- Carnet technique de la dette. Au cours de la dernière année, nous avons accumulé une longue liste de dettes techniques – des corrections au cadre qui permettront de gagner du temps, mais qui n’apportent pas de valeur commerciale évidente. Nous avons convenu que les équipes passeront 10% de leur temps à travailler sur ces problèmes et pour rendre cela visible, nous avons créé un nouveau flux de travail sur notre tableau Kanban, afin que nous puissions voir s’il est vide. (Kanban Core Practice 1: «Visualize», Mike Woods, Kanban de l’intérieur, introduction de la partie I).
Adaptations
Tout en respectant les principes Kanban, nous avons dû faire quelques adaptations. La beauté de cette approche est qu’il est vraiment facile de le faire progressivement (Principe fondamental Kanban 1: «Commencez par ce que vous faites maintenant», Mike Woods, Kanban de l’intérieur, introduction de la partie I).
- Une équipe fait «Scrumban». Une équipe a travaillé sur un nouveau produit, qui a nécessité une quantité de recherche et d’enquête pour définir les histoires. Ils ont trouvé plus facile de réintroduire le travail dans Sprints afin qu’ils puissent définir une portée plus étroite pour un Sprint, plutôt que de travailler sur un backlog sans fin et variable.
- Tests d’automatisation en équipe. Nous avions auparavant une équipe distincte chargée de rédiger les tests d’automatisation. Bien que cela ait permis aux testeurs d’automatisation spécialisés de partager le travail de toutes les équipes, cela a empêché nos équipes de produits d’être entièrement interfonctionnelles. Les histoires n’étaient pas vraiment terminées lorsque les équipes en avaient fini avec elles, nous avons donc trouvé des bugs lors de l’écriture et de l’exécution des tests d’automatisation. Cela a souvent étendu nos tests de régression pré-version. Nous avons maintenant redistribué cette équipe parmi les équipes de produits, afin que chacune puisse s’approprier la livraison de l’histoire entièrement testée.
- Planification détaillée des versions. Nos collègues ont du mal à vendre de nouvelles fonctionnalités lorsqu’ils ne savent pas quand ils seront livrés. L’année dernière, nous sortions toutes les deux ou trois semaines afin d’améliorer la qualité et la stabilité du produit, mais nous ne pouvions jamais prédire dans quelle version une nouvelle fonctionnalité apparaîtrait. Maintenant, nous préparons un calendrier de sortie trimestriel qui comprend une version majeure avec tous les trucs nouveaux et passionnants et les versions mineures plus fréquentes pour balayer les corrections de bugs.
Prochaines étapes
Nos équipes auront besoin de beaucoup de soutien pour la transition vers les nouvelles structures. Nous aimerions diffuser les compétences de test d’automatisation, afin que tout le monde puisse les acquérir, bien que cela puisse rencontrer une certaine résistance car certains membres de l’équipe préfèrent s’en tenir à leurs compétences de base. Nous surveillerons de près notre capacité à respecter nos plans de livraison. Je veux montrer à l’équipe commerciale que Kanban fonctionne, mais nous devons livrer les marchandises de manière cohérente avant de pouvoir les gagner. En résumé, nous avons beaucoup appris, nous avons réussi et pouvons voir le potentiel de continuer avec Kanban car il nous aide à atteindre notre objectif final. J’ai hâte de partager plus de mises à jour concernant des versions de produits spécifiques au fil du temps et j’accueille vos commentaires ou questions!
