Quand il s’agit de vivre les projets dans le quotidien d’une petite équipe, on se rend vite compte que malgré les intentions, la réalité terrain est bien loin des idéaux promus.
Va faire ta séance de «pair programming» et tes «scrum meeting» quand t’es tout seul à travailler sur plus de trois projets simultanés ! Impossible ? Peut-être pas, mais ça va nécessiter quelques adaptations, et c’est de ça dont il est question. Que l’on soit client ou développeur on a sûrement déjà été évangélisé par le marchand de méthodes agiles… Ce nom aujourd’hui sonne davantage comme une promesse de marchand de rêves que l’esprit du manifest originel.
Place aux recettes de «Maman» sur le thème des méthodes à Gilles.
Non pas pour se donner bonne conscience ou remplir les journées et tableurs d’un chef de projet fantoche! Pour mener a bien nos projets il faut :
Il n’existe pas à ma connaissance de méthodologie universelle et efficace dans tous les cas, il n’y a pas de recette miracle. Se borner à vouloir appliquer à la lettre les recommandations génériques des manuels de méthodologie serait une perte de temps et un échec en devenir. L’adaptation au contexte est bien plus important que la moyenne des résultats d’une solution.
La méthodologie peut nous fournir de la lisibilité et de la visibilité sur l’évolution d’un projet, nous donner des outils et réflexes qui vont avec. Elle ne garantit pas le succès d’un projet, c’est votre analyse et votre utilisation des informations et outils fournis par la méthodologie qui feront la différence.
Souvent, c’est là que vous vous dites, « ben… l’équipe c’est moi… ». Hé oui, il n’y a pas toujours une armée d’ingénieurs et chefs de projets ! Mais sur un projet on n’est pas seul pour autant, car vous allez endosser un ou plusieurs rôles d’une équipe qui sera composée a minima :
Dans des cas très rares ces rôles peuvent être tenus par la même personne, c’est le cas si vous développez l’application pour vos propres besoins. Malgré tout il faut bien veiller à vous organiser autour de ces deux rôles au minimum, ainsi le projet pourra évoluer et accueillir de nouveaux membres sans modifier l’organisation.
Dans la majorité des cas, il existe bien un demandeur qui est différent du producteur. Ce demandeur je l’appellerai par la suite « Client » (pour des raisons de simplicité), c’est le rôle le plus important dans la conduite d’un projet vers son objectif. Le client doit obligatoirement être intégré comme pilier de l’équipe, c’est un point critique qui peut éviter beaucoup de déconvenues.
Que vous soyez développeur ou client, vous ne pourrez plus prétendre être seul membre de l’équipe.
En tant que client l’investissement dans la conduite et le suivi d’un projet est capital.
L’impact des soins apportés au cahier des charges de votre projet se ressentira fortement sur le résultat obtenu et les délais.
Un besoin trop vague, un manque de consensus en interne et c’est un cycle de développement (même court) qui est perdu.
La feuille de route qui définit les priorités que vous vous êtes fixé doit absolument être à jour et maintenue régulièrement.
Le client est le rôle qui demande le plus d’implication dans la spécification fonctionnelle et la roadmap du produit. Il fournit une expression claire et pondérée des besoins et de leurs échéances.
C’est une des clefs du succès d’un produit :
Le client est aussi impliqué fortement dans les étapes test et de recettage où il devra comparer le réalisé avec son expression du besoin.
Communiquer une information à jour et capitaliser l’information, passe par l’utilisation d’outils adaptés à la conduite de projet. Chez Synbioz comme dans mes précédentes expériences nous utilisons Redmine, ce n’est qu’un choix parmi d’autre (taiga.io qui semble prometteur par exemple). Les exemples qui suivront s’appuieront sur Redmine, sont valables pour la plupart des solutions.
Utiliser Redmine nous permet de conserver ce qui constitue le projet dans un seul outil, l’information est disponible à tous les membres du projet (clients et développeurs), versionnée et historisée.
Une fois cet outil adopté, il faut réduire au strict minimum les informations qui circulent par d’autre médias, comme les mails et les messageries instantanées. Dans le cas contraire l’intérêt de centraliser l’information dans un tel outil s’en trouve fortement réduit. À moins de recopier vos mails dans l’outil, ce qui semble peu efficace.
D’une manière générale si :
Alors toute personne arrivant sur le projet ou ayant une interrogation sur celui-ci peut retrouver toutes les informations dans le même outil. C’est un aspect capital, car les équipes chez le client comme chez les développeurs peuvent être amenées à changer. L’agilité souvenez-vous c’est en grande partie une question d’adaptation au changement.
Voici une structure de base qui permet d’appliquer tous les bons conseils de cet article:
Une demande d’évolution est généralement formulée par le client. Une fois que le développement de celle-ci débute, les développeurs la subdivise en tâche (tracker tâche) enfant. Ce qui donne un indicateur d’avancement. Et permet de séparer dans des tickets différents la demande initiale des tâches exécutées pour son implémentation.
Au fur et à mesure que le développement avance, les développeurs ferment les tâches enfant. Une fois toutes fermées, cela signifie qu’elle est prête pour la phase de test avec le client. Une fois toutes les demandes d’une version fermées on peut conclure que celle-ci est livrable.
Les avantages d’un tel système sont que le client peut réordonner sa feuille de route ou obtenir un reporting de l’avancement en quelques clics.
Le projet n’aboutira pas s’il est mené d’une seule traite. Quel que soit la taille du projet il faudra plusieurs itérations pour parvenir au résultat souhaité.
Pour mieux s’y préparer, en tant que client il faut découper son projet en plusieurs livrables. Plusieurs versions qui peuvent être testées. Et dont la profondeur fonctionnelle s’étend à un rythme constant. Ces versions doivent être ordonnées dans l’ordre chronologique de leur livraison souhaitée.
Pour les développeurs, répartir les demandes d’évolution du prochain (ou premier) livrable client en plusieurs itérations (ou sprints).
La dimension des itérations, est constante sur toute la durée projet. C’est ce qui en fait une unité temporelle (qui lors des analyses nous donnera de visibilité sur la trajectoire du projet). Pour beaucoup de projets, des sprints de quinze jours sont suffisants. Sur des projets courts, un ou deux mois, une semaine est plus adapté (plus de boucles de feedback).
Chaque sprint ne doit contenir que ce que vous pensez qu’il est possible d’y réaliser. Cela veut dire qu’il va falloir estimer la charge de travail des tâches avant de les inclure dans l’itération. Le nombre de sprint final donne de précieux indices pour estimer la date de livraison de la version.
Avant de débuter une itération, il faut passer en revue les demandes qu’elle contient.
Du point de vue client, vous devez vous assurer que la demande n’a pas évolué de votre coté, que les explications sont suffisamment précises pour limiter les aller-retours.
Coté développeur, analysez scrupuleusement chaque demande:
Puis pour chaque interrogation lever les doutes avec le client. Il est important de procéder par écrit et d’utiliser le système de tickets, tous ces échanges viendront compléter la demande initiale qui deviendra solide et plus concrète.
A l’issue de chaque itération, une version de test est livrée au client.
En tant que client le moment est crucial, c’est lors de ces phases de test que vous pouvez comparer ce que vous avez en tête et ce que les développeurs ont compris.
Les estimations sont inexactes et subjectives ( 30 000 selon la police, 150 000 selon les manifestants… ), et ne doivent pas être prises pour argent comptant.
Certains Agilistes recommandent de ne pas compter en unité de temps. Même si c’est un principe qui a du sens, il n’est pas rare de devoir donner un chiffre représentatif du reste à faire au client.
On peux toujours annoncer un chiffre comme «Il reste environ 30 cacahuètes de travail pour terminer la version» tout le monde finira bien par reconvertir ça en temps calendaire. ( La formule pour transformer des cacahuètes en jours: ( nombre de cacahuètes / vélocité ) * nombre de jours dans un sprint )
Donc utilisez des ordres de grandeurs qui vous sont familiers, 1,2,3,5,8,13,21 … heures.
Pour estimer une tâche procédez comparativement à une tâche plus grosse et une plus petite. Il est bien sur évident que pour que l’estimation soit plus fiable il faut que la description du besoin soit précise.
Si vous n’arrivez toujours pas à estimer la quantité de travail c’est peut être que la demande est mal comprise ou trop grosse. Il faudra donc demander des détails ou la subdiviser.
Rédigé par le client, le cahier des charges plante le décor initial.
Mais il va vite falloir se séparer de ce document bureautique qui a permis de faire l’évaluation, car au cours du développement le client ayant une meilleure vision du produit aura besoin d’exprimer une vision révisée de son besoin.
Les demandes du cahier des charges initial devront être transformées en tickets d’évolutions (feature) dans votre outil de tracking. Ainsi pour chaque demande de précision de la part de l’équipe de développement et chaque réponse du client viendront compléter le ticket et son historique. Il est bien plus simple de mettre à jour la feuille de route en modifiant quelques tickets plutôt que de mettre à jour un document bureautique dont chacun possède une version différente.
Tous les documents échangés autour du projet, mais qui n’ont pas de rapport direct avec une demande d’évolution, sont conservés dans la partie Wiki et Fichiers du projet. ( process métier, documentation technique, illustrations )
Une très grande attention doit être portée à la partie documentation:
Depuis le point de vue client apporter tout contexte, documentation, diagrammes visant a mieux cerner le domaine du projet. Ils permettront aux développeurs de s’approprier plus facilement le domaine et d’éviter de répéter la même explication (avec parfois même quelques variantes). N’oubliez pas que ce qui vous semble évident dans le rôle du client, ne l’est pas nécessairement dans le rôle du développeur.
Du point de vue développeur apporter les diagrammes d’architecture, une documentation sommaire du modèle, de la procédure de déploiement… Tout ce que vous aimeriez trouver si vous veniez d’arriver sur le projet.
De la précision du cahier de charges on peut déduire un risque de dérapage, qu’il soit temporel, fonctionnel ou les deux à la fois. Une demande peu précise entrainera une estimation peu précise et une implémentation peu précise qui s’étendra sur plusieurs itérations.
J’ai déjà vu, presentée pour estimation, une demande d’évolution qui avait pour seule formulation « Planning: Refonte complète», en effet difficile d’estimer le temps que cela prendra ou la difficulté (environ une tonne de cacahuettes).
L’équipe (client et développeurs) doivent tout mettre en œuvre pour que les demandes soient précisées avant leurs arrivées en phase de développement.
Rien ne doit être laissé à l’oral et l’échange doit privilégier l’utilisation du système de tickets. Le passage à l’écrit force à raisonner en détail sur ce que l’on souhaite communiquer.
Concrètement au quotidien je constate une grosse différence, de l’ordre du facteur d’échelle entre les demandes d’évolution qui sont constituées de 120 caractères et celles qui font plus de 2000 caractères. La différence dans le délai de traitement et dans la fiabilité de réalisation est énorme, ne confondons pas twitter et expression de besoin !
C’est bien un dixième de ce que nous aurions à dire sur le sujet, mais l’essentiel est là !
« Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. »
Manifeste pour le développement Agile de logiciels
Le client au coeur de l’équipe du projet va dans le sens de la valorisation des individus et interactions, ainsi que la collaboration avec le client.
La boucle des itérations incrémentales, qui permet un retour client régulier sur le travail réalisé, assure la livraison de logiciels opérationnels.
L’adaptation au changement est encouragée et facilitée par l’accès centralisé et historisé à la feuille de route.
S’il reste une chose à retenir, c’est bien qu’il faut consigner le maximum d’informations par écrit et dans un outil adapté (non, pas MS Word …). C’est ce qui donne une base d’information vivante où les informations viennent complèter les autres plutôt que de les écraser…
L’équipe Synbioz.
Libres d’être ensemble.
