Historique
Depuis des années, j’utilise une méthode pragmatique pour la
réalisation de logiciel, au sein et à destination de petites entreprises et
avec des petites équipes.
Dans ces contextes, j’avais toujours plusieurs
casquettes : chef de produit, chef de projet, responsable R&D,
programmeur senior.
Dans la suite de ce document, je résumerai ces rôles au
titre de « manager », un manager multi-casquettes,
multitâches…
Sans un système léger et automoteur, il
m’aurait été très difficile de m’en sortir.
Plus qu’une méthode « innovante et
révolutionnaire », il s’agit plutôt d’un assemblage de bonnes pratiques et
de pragmatisme. Elle a comme base principale la classique « Méthode
agile » mais adapté à des « mini-équipes » très polyvalentes.
Ayant beaucoup de rôles différents, il m’a fallu faire des
choix, établir des priorités.
Ce n’est pas la quantité de travail qui détermine la
réussite d’un projet mais plutôt sa qualité, son organisation, l’engagement de
son équipe et sa passion pour le produit.
Dans les différents rôles de management, j’ai fait l’impasse
sur un certain nombre de fonctions pour n’en garder que l’essentiel.
·
Chef de produit : inspiré par l’agile, pas de cahier
des charges à rallonge, juste des spécifications explicites courtes, les
fameuses « user stories » (au final, leur addition donne un cahier des
charges, mais à postériori).
·
Chef de projet : pas de planification, juste des
découpages de « User stories » en tâche et des estimations de priorités
dans celle-ci. Ces tâches permettent une autogestion de l’équipe de
développement, dirigée par les tâches et leurs priorités, mais d’ordre imposé.
Tasks-Driven & Task-Centric
Les tâches
Ma méthode est basée sur les tâches et sur l’autonomie de
l’équipe et de ses membres.
Le point principal est la possibilité, ou plutôt
l’obligation des développeurs de choisir eux-mêmes les tâches qu’ils souhaitent
réaliser, selon leurs inspirations, leurs compétences, leurs humeurs ou leurs ambitions.
Le libre choix des tâches donne une grande autonomie
aux membres de l’équipe et leur permet de moduler leurs efforts et aspirations
dans un but d’obtenir une plus grande productivité.
Lorsqu’un développeur choisi lui-même sa tâche, il va le
faire selon certains critères principaux:
·
Son intérêt pour le sujet de la tâche :
« Tiens
cette tâche à l’air intéressante, c’est vraiment dans mes cordes »
Exemple + :
bonne expertise sur le sujet => bonne productivité et satisfaction
Exemple - :
Challenge qui peut rater => mauvaise productivité et perte de confiance
·
Son état de fatigue et/ou de motivation :
« Je suis
crevé cette semaine, je vais me faire toutes les corrections d’orthographe et
d’alignement »
Exemple + :
choix de tâches courtes et rapide => maintien de la productivité
Exemple - :
Enfermement dans une tâche longue (défaut du concept ‘longue’) => baisse de
la productivité
Dans l’optique d’atteindre le but de toute équipe de
développement : Livrer un logiciel de qualité dans le délai fixé,
le libre-arbitre dans l’organisation individuelle permet de conserver une bonne
productivité et une bonne motivation quelque que soit l’état d’esprit et de
fatigue du développeur.
Dans ce contexte, le manager peut (je dirais même :
doit) lui-même réaliser des tâches, son score est affecté à l’équipe.
Le manager joue un rôle de support auprès de son équipe.
Planification
Elle n’existe pas en tant que tel. Seuls quelques jalons
peuvent être posés.
Comme j’utilise les grands principes de la méthode Agile,
mes jalons sont les dates de fin de sprint et de fin de release.
Je ne connais pas de projet qui respecte son délai parce qu’il
a été planifié, mais parce que son équipe s’est mobilisé sur un objectif
clair et collectif : le délai.
La planification détaillée de toutes les tâches est souvent
une façon pour tous les acteurs autour du projet de se rassurer.
Pour reprendre une citation de Rework : « Planifier, c’est
deviner ».
Philippe Limantour, en lisant ce document m’a fait les remarques
suivantes :
«
Sur des projets de développement plus lourds je ne partage pas trop l’avis
tranché sur le fait qu’un projet planifié ne tient pas ses délais.
La
clef selon moi – expérimentée sur des projets de développement avec des équipes
de plusieurs dizaines de développeurs, et des roadmaps de 6 mois avec un
maximum de 5 jours de retard – réside dans le travail de préparation. Une très
bonne analyse marketing détaillée dans un livrable de: ‘que veut le client’,
‘comment le fait-on technologiquement’, ‘quels choix in/out dans la prochaine roadmap’
est une clef du succès Ce travail est mené par une personne dédiée, en
collaboration avec le chef de projet en charge de l’équipe de développement, et
avec l’équipe commerciale. Une fois calé ce document, on n’en sort pas. Et un
responsable qualité à temps plein a contribué à mettre en place, et à suivre,
les processus qui permettent de suivre ce cadre qui a pour but de délivrer les
fonctionnalités majeures attendues par les clients, en temps et en heure. »
Le rôle du manager est d’animer et motiver l’équipe pour
tenir ces dates.
Mais, surtout, son rôle est de bien quantifier le nombre de
tâches et leurs difficultés pour qu’elles « rentrent » dans le sprint
ou release.
Le réalisme dans l’estimation du travail à fournir
est l’un des point-clefs du métier de manager d’équipe de développement.
« Je
pense savoir ce que je vais faire cette semaine, mais quels impondérables vont
me tomber dessus et changer tout mon beau planning ? »
Je préfère largement parler d’objectif, et de dates
d’objectif.
Le but : petits rappels
Le but de toute équipe de développement est de:
Livrer un logiciel de qualité dans le délai fixé
Seule l’obtention du but, de l’objectif compte, et
pour cela, seule la motivation, la mobilisation autour du but compte.
Même si, le choix, l’autonomie et le libre-arbitre sont les
bases de cette méthode, le manager doit pouvoir assigner et imposer ses choix
et décisions aux membres de l’équipe dans l’intérêt du projet et, surtout, dans
l’objectif d’atteindre le but.
Comment atteint-on le but : en terminant et en testant
toutes les tâches. Tout tourne autour des tâches.
Malgré une forme d’autogestion des développeurs, le manager
reste le manager, il est le garant du résultat final.
Nouvelle notion : le score
Pourquoi un score
Mon idée est que la motivation des membres de l’équipe peut
être animée et aiguillonnée par le score qu’ils réalisent sur une période
donnée (semaine, mois, release, sprint, etc… selon l’organisation choisie).
« Ma méthode » a ses limites, notamment dû au
manque de mesure et d’évaluation des membres de l’équipe. Et sans indicateur, il
n’y a pas d’axes d’amélioration, pas de détection proactive des
dysfonctionnements.
Cerise sur le gâteau, l’idée de score induit un petit esprit
de compétition que peut émuler une équipe, la faire progresser et être, par
exemple, le support à de mini évènements.
Utilisation du score
Par l’équipe
Un score minimum moyen (SMM) par membre de l’équipe
est fixé. Il faut également fixer un score minimum pour l’équipe afin de créer
un esprit d’équipe.
L’idéal est de fixer une récompense pour SMM atteint,
individuels et collectifs, récompensant en cela l’effort individuel et les
efforts collectifs. Cette différence « individuel/collectif » est
importante, un membre qui fournit de gros efforts et obtient un bon score n’a
pas à être pénalisé par le piètre résultat de l’équipe.
A l’inverse, si globalement, l’équipe a été bonne, tout le
monde doit être récompensé afin que personne ne se sente exclu, même s’il n’a
pas vraiment participé à l’effort collectif.
A chaque fin de période, une analyse du plus mauvais score
doit être faite, dans un esprit positif, afin d’aider le membre de l’équipe qui
l’a obtenu. Pourquoi ne pas utiliser la technique des 5 pourquoi pour
faire cette analyse ?
Il est nécessaire d’écarter des « mauvais
scores », les scores bas obtenus à cause d’éléments extérieurs ou
personnels (ex : absence pour maladie = mauvais score, mais l’équipe
n’y peut pas grand-chose).
Pour le manager
Il aide à l’estimation simple des tâches.
Le score est très comparable à la vélocité (basée sur les
points des user-stories), et permet donc son utilisation pour la planification
des sprints et des releases.
Définition d’un score
Le score d’une tâche est le résultat d’un calcul basé sur des
critères prédéfinis. Il sert à indiquer aux développeurs le nombre de points
qu’il va gagner en réalisant cette tâche.
Pour rester simple, il n’y a que trois critères avec trois
valeurs qui déterminent le score de la tâche.
L’expertise :
Facile= 1, Normal=3, Expert=5
La longueur de la tâche :
Courte=1, Normal=3, Longue=5
La priorité :
Non-urgent=1, Normal=3,
Urgent=5
Subjectivité de l’évaluation.
Elle est réelle, mais elle est limitée par le faible nombre
de choix et la transparence des choix. Les choix doivent être discutables par
n’importe quel membre de l’équipe en cas de désaccord, et à n’importe quel
moment du process, même quand il est fini. L’important est que ce désaccord
soit motivé.
Dans de rares cas, à l’instar du « planning
poker », le « scoring » peut-être collectif, en reprenant la
même méthode que le « planning poker », mais cette méthode doit
rester l’exception.
Le futur en conclusion
Les outils utilisables
Ils n’existent pas encore d’outil utilisable tel quel pour
la gestion basée sur les scores. Pour le task-driven, beaucoup d’outils sont
utilisables, je ne vais citer que ceux que j’ai utilisés ou évalués.
Le choix de TFS
Je trouve que l’intégration TFS/Visual Studio qui fait de
l’ensemble une plateforme redoutable de productivité et d’efficacité.
Ce que j’aime également dans TFS, c’est l’idée de pouvoir
lié le code aux « Workitems » et notamment les archivages
(check-out), c’est ce qui me manque dans Mantis, une ou des références sur des
bouts de code pour mieux expliquer des spécificités/tâches techniques.
TFS est un très bon contrôleur de source mais la gestion des
« Workitems » n’est trop adaptée à une gestion Task-driven et ne gère
pas les scores, c’est pourquoi je travaille sur une interface web et un
« process template » qui va bien coller avec ma méthode de travail.
D’où le projet ScrumPilot.
ScrumPilot
L’idée initiale
de ScrumPilot était un simple tableau de bord plus vivant et plus visuel que
celui qui est offert.
De fil en aiguille, j’en suis venu à lui ajouter des
fonctions de lecture de « workitems », projets, utilisateurs.
Et de me dire, qu’avec tout cela, ma meilleure connaissance
de la facétieuse API de TFS et un peu d’huile de coude, je devrais pouvoir
faire un mix entre Mantis/Asana, TFS, ma méthode et mes scores, pour donner un
vernis « petite équipes agiles centrées sur les tâches »
Il fera l’objet
d’un autre article plus détaillé quand je l’aurais peaufiné.
Aucun commentaire:
Enregistrer un commentaire