[Process] Vis ma Vie de Projet à KNP - Part 2 : le démarrage d'un projet

Notre conférence “Vis ma vie de projet à KNP” a été retenue plusieurs fois cette année à divers événements. Cet article en résume le contenu et répond à la question : comment gère-t-on les projets chez KNP ? Première partie : Qui et Quoi ?

Evaluer un projet avant le démarrage

La première étape de validation est faite par Laetitia, la CEO, qui vérifie si le projet respecte nos pré-requis :

• le projet est dans notre sphère d’expertise : à savoir Symfony et/ou un framework Javascript : React, Angular ou Vue.js
• il est challengeant techniquement ou intéressant fonctionnellement : on aime beaucoup accompagner les porteurs de projet, ou les refontes en micro-services, ou bien encore les audits de performance,
• le client et le projet respectent nos valeurs : collaboration, transparence, qualité, recherche d'excellence technique et implication.

Si le projet est OK après ce premier filtre, un KNPDev l’analyse d’un point de vue technique. S’il y a du code existant, il évalue à quel point ce code est testé, découplé, propre, respectueux des standards et facilement extensible. S’il n’y a pas d’existant, il fait une analyse rapide des fonctionnalités. Cette phase est cruciale et il nous arrive parfois de dire NON à un client ou plutôt "NON pas comme ça tu vas dans le mur". On lui expliquera toujours pourquoi et bien sûr on lui proposera une solution.

Ce qui est sûr, c’est qu’on ne se lance pas dans un projet qu’on ne peut pas analyser ou estimer. Parfois on ne peut pas estimer parce qu’il n’y a pas de tests par exemple, tout ajout ou modification de fonctionnalité sera risqué et c’est la seule chose qu’on peut mesurer. Parfois on ne peut pas estimer parce que le besoin du client n’est pas assez clair pour lui et c’est tout autant risqué.
Dire non à un client n’est jamais simple, cette décision arrive au terme de plusieurs discussions internes. La beauté du “Non” ? Le client prend conscience qu’on prend vraiment soin d’analyser son projet et que c’est pour le bien de son application qu’on refuse d’intervenir en l’état.

C’est cette transparence et cette honnêteté que viennent chercher nos clients : certains reviennent vers nous après avoir essayé une autre agence (qui a fait des promesses qu’elle n’a pas pu tenir) et certains restent dès le début en sachant qu’on prendra vraiment soin de leur projet. Ensuite on vérifie à très grosse mailles si le dev nécessaire passe dans le budget du client. On fait une extreme quotation (évaluation en tailles de t-shirt). Ça marche, parce qu’on confie cette partie à des KNPDevs qui ont déjà beaucoup d’expérience, et qui savent évaluer combien de temps va mettre un e-commerce par rapport à une market-place… A l'issue de cette première estimation, s'il est déjà visible que toutes les fonctionnalités ne rentreront pas dans le budget, l'étape suivante est d'accompagner le client en lui proposant de travailler sur celles dont la valeur ajoutée est la plus importante, le MVP (Minimal Viable Product). Il s'agit ici de guider le client pour identifier ensemble les fonctionnalités qui vont rapidement permettre de tester la viabilité de son projet.

Le démarrage de projet

Les principes

Alors là, on va vous révéler nos secrets intimes :D Et on vous prévient aussi : Ça marche chez nous, car nous avons mis quelques années pour en arriver là. On a fait des essais, on a appris de nos erreurs et on continue à le faire, on tâche de transmettre aux nouvelles recrues notre vision d’un projet réussi, du rôle de chacun. Donc, il n’y a pas de secrets finalement. Une fois le projet validé par Laetitia et un KNPDev, les facilitatrices vont discuter et regarder le planning pour savoir qui pourrait travailler sur le projet. Nous avons quelques principes clé :

• À 2, c'est mieux : revue de code et pair programming ;) Être 2 permet également une meilleure efficacité en bénéficiant des bienfaits de la discussion dans les choix d’architecture et une résolution plus rapide des problèmes techniques rencontrés. Et puis enfin être 2 c’est s'assurer qu’il y ait toujours quelqu’un sur le projet, même en cas de congés ou de maladie par exemple et la transmission de connaissance de sécurité indispensable au client.
• on ne fait pas switcher un KNPDev sur un projet, sauf si c’est à sa demande. Changer de projet, voire alterner par-ci par-là entre plusieurs projets en mode multitâche a un énorme impact sur la productivité et sur la satisfaction en fin de journée. Donc 1 dev = 1 projet.
• on essaie d’avoir dans les équipes un ancien et un nouveau KNPDev pour garantir la transmission de nos standards et méthodes.

Le Kick off interne

Ensuite, nous faisons un KickOff interne : Cela ressemble à une rétrospective, chacun vide son sac. On parle librement de ce qui nous inquiète quand on entend parler du projet, en se basant sur nos échecs ou réussites dans les projets précédents. Une fois nos émotions mises à plat, on dresse une liste de toutes les tâches à faire sur ce projet. Il y a des tâches communes avec tous les projets, et d’autres spécifiques à ce projet d’après ce qu’on sait de son passif, du client, des intervenants extérieurs, etc. Et ce n’est qu’après qu’on attribue les tâches. Cette étape est cruciale. Les tâches sur un projet ne sont pas automatiquement distribuées selon les rôles de chacun, mais attribués par l’équipe elle même selon les forces et les faiblesses de chacun. Bien sûr, la facilitatrice ne codera jamais par contre :D

Le Sprint 0

Last but not least, le Sprint 0 avec le client. Une phase courte d'environ 3 jours, mais décisive pour le projet. Dès que nous avons le go (signature du contrat), nous créons la liste des fonctionnalités avec le client. Quand c’est une refonte, idem, on crée à nouveau une liste avec le client. La réponse “C’est identique à l’existant, il faut juste refaire le code” ne compte pas, une refonte est en réalité un puits de possibilités pour faire mieux au niveau du business. Le plus souvent nous utilisons trello et chaque fonctionnalité est écrite dans une carte. Souvent une phase de mockups fonctionnels est indispensable pour cerner et préciser au mieux le projet.

Sur le plan théorique, l'Agilité ne nécessite pas d'avoir toute la big picture au départ d'un projet dans la mesure où le client voudra certainement changer au moins une partie de son besoin de cours de route. Cependant, notre rôle est de pouvoir donner dès le départ à notre client un maximum de visibilité sur son budget et sur sa deadline. C'est pourquoi cette étape de sprint 0 est indispensable. Elle donne les grandes lignes du projet, sans entrer dans les détails, et ce qui en ressort n'est pas gravé dans le marbre. Le client pourra toujours modifier son besoin par la suite, mais nous avons dans le sprint 0 une information de base : au point de départ du projet, il y a ça à faire et cela prendra X de temps pour un budget de Y. A partir de là, les modification de backlog pourront être réévaluées et tout le monde comprend l'impact sur le temps et le budget.

Nous entrerons dans le détail de ce Sprint 0 dans un prochain article car il s'agit bien d'une étape clé de notre méthodologie. Et d'ailleurs cette étape est toujours en constante évolution et amélioration :)

Suite et fin : Part 3, le déroulement d'un projet