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

Notre conférence “Vis ma vie de projet à KNP” a été retenue plusieurs fois cette année à divers événements.  Dans cet article nous répondons à la question : comment gère-t-on les projets chez KNP ?

Partie 1 : Qui et Quoi ?

Partie 2 : le démarrage d'un projet

Déroulement du projet au quotidien

Vous l’aurez remarqué dans le démarrage du projet, et ça se confirme ci-dessous dans le déroulement au quotidien, la présence régulière du client est primordiale. Son implication dans la définition du besoin en répondant rapidement et précisément aux questions fonctionnelles des développeur est la garantie d’un projet réussi. Chez KNP nous n’utilisons pas systématiquement Scrum, mais nous nous servons, la plupart du temps de ces cérémonies afin de rythmer nos projet. Evidemment cet article n’est pas un cours sur Scrum donc nous ne rentrerons pas trop dans les détails ;)

A chaque début d’itération, l’équipe complète - développeurs, designer, client et scrum master - se réunit pour un sprint planning afin de choisir les cartes les plus prioritaires et les décrire encore plus en détail que ce qui a déjà été fait pendant le sprint 0.

Tous les jours à heure fixe, l’équipe de développement se réunit brièvement - avec ou sans le client, mais toujours avec la facilitatrice - pour se synchroniser. Qu’a-t-elle fait hier, que va-t-elle faire aujourd’hui et y a-t-il des obstacles ? Si elle utilise un burndown chart elle en profite pour le mettre à jour.

A chaque fin de sprint toutes les fonctionnalités finies au cours du sprint, évolutions ou corrections, sont livrées sur un environnement dédié. L’équipe de développement fait une démonstration du produit au client, qui peut d’ailleurs inviter d’autres parties prenantes pour avoir leur avis. Cette livraison constitue le livrable d’une itération. Afin de suivre l’avancement du projet, nous utilisons un burnup chart qui est mis à jour pendant cette réunion. Ce burnup chart permet de consolider et de visualiser l’avancée du projet dans sa globalité.

Afin d’assurer l’amélioration continue de la collaboration, toutes les 2 semaines environ, une rétrospective est faite avec toute l’équipe. Chacun donne son avis sur ce qui fonctionne bien, sur ce qui pourrait être amélioré et l’équipe se met d’accord sur un plan d’action concret pour le sprint suivant.

Facturation à l’heure pour plus de transparence

L’une de nos particularités est de facturer à l’heure. Cependant, plutôt que tracker les heures passées sur un projet, on part du principe qu’un•e développeur•se est sur son projet à 100%, et on retranche le cas échéant les heures qu’il/elle a pu passer sur autre chose : article de blog, préparation de formation ou conférence, quickfix ou code review sur un autre projet, aide technique à d’autres KNPeers ou mentoring d’une recrue, etc.

Nous utilisons une feuille de temps (un simple tableur Google doc), qui est partagée avec le client, afin de permettre une transparence et une confiance totales.

La fin du projet

A l’issue du dernier sprint, les développeurs arrêtent de développer sur ce projet mais restent à disposition si toutefois le client a des retours pendant sa recette de sprint.

Parfois, sur un long projet, nous organisons une rétrospective de fin de projet. Ça permet à l’équipe d’échanger les #LessonsLearned et de clore le projet de manière conviviale (avec une bière bien sûr).

Et l’après-projet

Une fois cette phase de recette terminée, que se passe-t-il ? Qu’en-est-il de la maintenance de l’application ? Que ce soit pour une application from scratch, ou pour un projet existant sur lequel nous sommes intervenus, en générale une équipe interne chez le client s’occupera de la maintenance de l’application après la livraison. Pour passer le relais, nous prévoyons toujours une passation, tant sur la technique (architecture, normes, etc.) que sur le fonctionnel du projet. Parfois même nos KNPeers intègrent l’équipe interne et travaillent directement avec.

De temps en temps nous nous occupons de la maintenance évolutive ou corrective mais pas dans le cadre d'un contrat de TMA contraignant et cher pour tout le monde : les demandes sont faites et réalisées avec une estimation indicative et facturées à l'heure. Le bon sens et le service client prime : pas besoin d'un contrat de TMA pour savoir qu'il faut intervenir rapidement pour un bug bloquant !

Voilà, maintenant vous connaissez tous nos secrets de fabrication pour un projet réussi : des clients impliqués, des développeurs et des facilitatrices heureux et une direction qui les soutient. Vous l’aurez compris, cette méthode n’est pas LA méthode magique qui marche à tous les coups, mais c’est celle qui fonctionne pour nous et nous la remettons en question régulièrement.

Et voici la vidéo du Printemps Agile 2017 à Caen - on adore les Kudos via Twitter !