Comment faire une roadmap 3/5 : La capacité de l’équipe c’est quoi ?

Une équipe pour fonctionner a besoin d’un responsable, d’une mission et de moyens.

Partons du principe que la mission c’est la réalisation de tout ou partie de la roadmap.

Les moyens mis à disposition de l’équipe sont bien évidemment les locaux, les machines, le téléphone, des tickets restaurant, un salaire, une salle de gym, l’abonnement RATP et surtout du café à volonté ?

Plus sérieusement, dans les activités de création d’un logiciel ou d’un produit, les moyens ce sont les membres de l’équipe, leurs capacités intellectuelles et leurs compétences propres (techniques, management, organisation projet, métier par exemple).

Pour simplifier, je vais présupposer que les compétences de l’équipe sont bonnes et que j’ai réussi à recruter ou à m’entourer de freelances compétents (eh, eh, petite phrase pour faire un peu d’auto-promotion : il faillait bien qu’il y ait une page de pub ?, restez bien assis, cela recommence tout de suite après la ligne).

Comment l’équipe agile, elle-est structurée?

L’équipe, l’unité opérationnelle (la section pour reprendre la référence au président Eisenhower) est une équipe constituée autour des compétences suivantes (pour info et pour finir le clin d’œil militaire, certains utilisent maintenant le terme de SQUAD pour définir leurs équipes agiles) :

  • 1 Product Owner : garant du produit et de la roadmap (parfois affublé du rôle de Scrum Master également mais ce n’est pas conseillé par « Scrum by the book »)
  • 6 Développeurs : parfois il y a un Lead Dev qui lui aussi va être affublé du rôle de Scrum Master (mais cela peut être « n’importe qui »)
  • 3 QA / BA : même si, dans la théorie « Scrum by the book », hormis le PO, tout le monde est « Développeur », cela ne fonctionne pas toujours. Le PO peut se retrouver débordé et a besoin soit de testeurs, soit d’analystes pour l’aider dans sa tâche. Les QA / BA peuvent être des développeurs intéressés par l’automatisation de scénarios également.

Je ne vais pas rentrer dans le débat ici quant au rôle des QA / BAs par rapport aux développeurs ou de savoir si le Scrum Master « compte son temps ». Partons du principe qu’ils savent fonctionner ensemble de manière harmonieuse et ont des pratiques agiles évoluées. La répartition des rôles donne une idée des profils habituellement cherchés dans les équipes de développement et surtout d’une typologie habituellement utilisée.

Là encore, je n’ai pas de préférence à avoir un QA / BA de plus qu’un développeur ou à introduire formellement une personne à plein temps en tant que Scrum Master (encore que là, à plein temps, quelqu’un pour ne faire « que » les cérémonies agiles, je suis pas bien sûr ?).

Et enfin, quelle est la capacité de l’équipe ?

Revenons à la notion de capacité : si l’équipe a les compétences optimales et a une organisation bien rôdée (hypothèses fallacieuses…), chaque membre de l’équipe ne dispose en France que de :

217 jours de travail – 17 jours de formation / séminaires / autres activités & évènements exceptionnels = 200 jours par an
2000 jours par an et par équipe

Donc 2000 jours de travail efficace par an par équipe : j’entends là les parangons de l’abolition des 35h, les adeptes du « French bashing » ou les défenseurs des droits des salariés souhaitant le passage au 28h par semaine. Dans tous les cas, ce n’est pas le propos mais la France reste l’un des pays les plus productifs d’un part et d’autre part 2000 jours / an c’est plus facile à garder en tête ?

Si, en plus, l’équipe travaille sur des Sprints de 2 semaines (10 jours), cela signifie qu’elle peut encaisser 100 jours de travail par Sprint (dont 60 jours pour les développeurs)

Maintenant que l’on sait un peu mieux de quoi retourne la capacité, parlons de ce qu’il y a à faire : je rappelle que nous sommes partis avec une liste de choses à faire dans Excel. Comment faire pour savoir si ce qu’il y a à faire est en rapport avec la capacité de travail de l’équipe ?

A propos de l’auteur : Benoît Fillon

Lisez aussi :

Comment faire une roadmap 1/5 : Une roadmap c’est quoi ?

Comment faire une roadmap 2/5 : pour qui et pour quand ?

Comment faire une roadmap 4/5 : Comment évaluer la roadmap ?

Comment faire une roadmap 5/5 : J’ai fait une roadmap et après ?