Front, back, UI en scrum… Faux problème !

front back ui en scrum
front back ui en scrum

Front, back, UI en scrum. J’entends souvent parler d’un soucis de partage de travail entre les membres de l’équipe de développement : compétences front, compétences back, compétences UI…

Des pratiques qui se complexifient

Une estimation par compétence

Pour combler ces soucis là, les équipes parfois en viennent à faire une estimation par type de compétences en finissant par additionner le tout. Certaines vont jusqu’à créer une capacité de faire par corps de métier.

Bien que rien n’interdit de procéder comme cela en scrum, cette pratique amène souvent à de nouveaux soucis résultats :

  • le choix des user-stories se fait par rapport aux capacités de chaque membre
  • le choix des user-stories ne se fait plus par rapport à la valeur

Cependant, certaines équipes savent créer des objectifs de sprint de qualité et profite de quelques user-stories pour remplir le sprint. Mais il faut vraiment faire attention à ne pas combler les sprints de user-stories et en oublier les objectifs.

Au final, cette pratique d’estimation affinée ne va pas forcément à l’encontre du scrum contrairement à beaucoup de choses que j’ai pu entendre ; il faut juste faire attention aux pièges dans lesquels elle peut amener.

On fait des items par compétence

Certaines équipes finissent par créer des items par domaine de compétences. Je vois même parfois des équipes faire des items « test » pour le membre de l’équipe ayant des compétences de testeurs. Cependant ces items ne sont plus « INVEST » (I pour indépendante) et va mettre en péril votre fonctionnement scrum.

Cette pratique me dérange plus car elle amène une complexité incroyable dans la gestion du backlog et limite la vision du product owner sur celui-ci.

Est-ce interdit en scrum ? En étant pointilleux sur le scrum guide, pas forcément.

Les livraisons incrémentales d’un produit « Fini » assurent
la disponibilité d’une version potentiellement utile du produit fonctionnel.

scrum guide

Si nous livrons une API back (item à part) qui n’impacte pas le reste du produit et que le produit est toujours fonctionnel, rien ne vous interdit de le faire en soi.

L’interprétation du scrum guide est loin d’être évidente, voici d’ailleurs sa définition de l’incrément :

L’incrément est constitué des éléments du Backlog produit « Finis » pendant le sprint ainsi que de la valeur cumulative des incréments livrés dans les sprints précédents. À la fin d’un Sprint, le nouvel incrément doit être « Fini », ce qui implique qu’il doit être dans un état publiable et qu’il
correspond à la définition de « Fini » (Definition of Done) de l’équipe de développement. Un incrément est la partie d’un travail fait, qui prend en charge l’empirisme, et vérifiable à la fin du Sprint. L’incrément est un pas vers une vision ou un but. L’incrément doit être dans un état publiable, sans égard à la décision du Product Owner de le publier ou non.

scrum guide

Comme vous pouvez le voir, rien n’interdit de livrer des choses si elles sont testables, vérifiées et que l’incrément répond au Definition of Done. Livrer une « API » back alors que le front ne sera réalisé qu’au sprint suivant n’est pas forcément interdit par le scrum. Le « vérifiable » étant trop large, il peut être interprété de différentes façons.

Mais les Product Owner se retrouvent vite dans des grosses problématiques de gestion de backlog avec des items de type : front, back, UI… Ce n’est pas par hasard qu’un grand nombre de coachs agiles recommandent fortement l’utilisation de user-stories INVEST.

Et si votre problème était la sprint planning ?

En réalité, la sprint planning est souvent sous-estimée. Si nous disons qu’elle peut durer parfois jusqu’à 4h, ce n’est pas par hasard. Mais elle est souvent expédiée très vite par un grand nombre d’équipes.

Pourtant c’est elle qui va amener une organisation complète du sprint avec pour objectif de fournir un increment fonctionnel répondant aux objectifs de sprint.

Prenez le temps de définir le travail à faire, de laisser les différents rôles négocier et expliquer le travail à réaliser quitte à rentrer dans le détail. Pour un sprint de 2 semaines, l’équipe scrum a jusqu’à 4h pour réaliser le travail.

Proposez des travaux complémentaires

Mais si nous avons des développeurs front qui n’ont que un jour de travail estimé sur les deux semaines ? Prenez alors le temps de mettre en place des choses qui vont apporter au produit :

  • refactoring des éléments front
  • travail d’amélioration en collaboration avec le PO et les utilisateurs

En effet, il est toujours possible de faire mieux ; le produit bénéficiera de ces évolutions. Rien n’interdit ces acteurs de définir à ce moment là des travaux en collaboration avec différents acteurs.

D’ailleurs, il est tout a fait possible d’inviter des acteurs extérieurs à participer à cette sprint planning si ils peuvent aider dans la planification du travail à réaliser. Il n’est pas rare que le PO ait une bonne vision (ou il faut tout faire pour) des risques de voir des compétences

Conclusion Front, back, UI en scrum

En faisant une sprint planning de qualité et en prenant le temps de bien la faire, ces problèmes front/back/UI n’en seront plus. Cette cérémonie est souvent sous-estimée et l’accélérer amène souvent à ce type de problèmes.

[ Article lu 4 fois aujourd'hui ]
A propos Judicaël Paquet 490 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

1 Rétrolien / Ping

  1. La Sprint Planning - Blog Myagile Partner

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.