Aller au contenu
gaetancottrez.dev

Comment bien démarrer un projet de développement ?

Published:le  à 05:00 | (16 min de lecture)
Comment bien démarrer un projet de développement ?

Table des matières

Ouvrir table des matières

Comment bien démarrer un projet de développement ?

70% des projets ont tendance à échouer. Et ce n’est pas moi qui invente ces statistiques. Quand on gratte un peu on constate que les choses sont diverses et vérifiées, mais elles ont toutes un point commun : elles peuvent être évitées si on a bien démarré le projet.

Et c’est justement ce dont je vais vous parler.  Même si vous êtes un développeur junior, vous devrez à un moment ou un autre acquérir les bons réflexes et les bonnes pratiques pour gérer un projet.

Je vais donc vous expliquer comment on gère nos projets où je travaille afin de vous inspirer et d’obtenir des bonnes méthodes pour maximiser vos chances de gérer votre projet.

CommitStrip créer la valeur du projet Source : http://www.commitstrip.com/fr/2017/02/15/what-matters-most-in-any-project

Étape 0 : L’avant-projet

J’aborde ce point volontairement, car il est essentiel pour la suite des opérations. Je parle notamment d’un point essentiel, c’est la première exposition du projet par le client. En général, c’est lors de votre première rencontre avec lui.

Il va un peu raconter sa vie en exposant son métier, ses enjeux et ce qu’il souhaite faire pour la suite. Il va vous raconter ses problématiques et le projet qu’il souhaite développer.

C’est à ce moment qu’il faut récolter un maximum d’informations sur ces demandes et ne pas hésiter au feeling de challenger (ouais j’aime bien ce mot) ses idées pour affiner le besoin ou mieux l’orienter.

À cette étape, on ne sait pas où cela nous mène, mais plus vite vous avez une idée du projet dans sa globalité et plus vite vous allez pouvoir soulever des questions.

Le meilleur moyen pour avoir une vue d’ensemble c’est de cartographier le projet du client avec les informations qu’il vous communique. Graphiquement c’est plus parlant et plus visuel pour se projeter. On utilise le MindMapping pour réaliser cet exercice.

Et il faut le faire même si le client fournit ses propres schémas.

C’est un bon moyen de vérifier que vous avez bien compris le projet dans son ensemble, mais surtout si votre client n’y connaît rien en informatique les schémas du client ne seront pas forcément les mêmes que vous.

Donc, retenez bien si vous êtes chargés de faire la première rencontre avec le client : cartographier son projet et ses besoins sous forme de schéma avec un logiciel de MindMapping par exemple.

Étape 1 : Constituer votre équipe

On va faire l’impasse sur la partie contrat et accord du client pour travailler avec vous pour réaliser son projet, car ce n’est pas le sujet. Le point de collaboration est trouvé et la première chose  à faire c’est de constituer l’équipe qui va travailler sur le projet.

Et je ne parle pas que des développeurs bien entendu. Designer, consultant ou expert technique. Toutes personnes susceptibles d’apporter de la valeur sur le projet doit en faire partie. Même si l’intervention est minime que ce soit un apport d’idées, un point de vue ou une expertise peuvent tellement faire la différence.

Faites un briefing du projet pour tout le monde

Déballez toutes les informations que vous avez récoltées à votre équipe et exposez la vision du projet à tout le monde. Expliquez les enjeux, la valeur à apporter et les problématiques que le client vous a communiquées. C’est pour moi, je pense, la partie la plus importante pour débuter un projet.

Expliquez dans sa globalité le projet à l’équipe même si certains ne feront qu’une infime partie. C’est un point que l’on peut être tenté de négliger en briefant simplement les personnes individuellement sur les tâches que l’on compte leur donner.

Pourquoi tout le monde doit bien connaître le projet ? Et bien pour plusieurs raisons qui peuvent paraître évidentes :

Mais la meilleure raison et celle qui aura le plus de valeur c’est que vous allez créer une conscience collective, une vraie machine à réfléchir.

Une équipe qui connaît la globalité du projet, ses enjeux et le but de celle-ci sera dopée en termes de productivité et de créativité plutôt que d’expliquer seulement une partie individuellement à chaque personne.

Potentiellement, chaque personne pourra soulever des problématiques et des questions sur le projet, mais aussi remettre en question certaines parties. C’est donc positif surtout au début du projet, car comme on dit mieux vaut prévenir que guérir.

Étape 2 : Mise en place de l’environnement de développement

Vous devez dès le départ le décider et le mettre en place. Même si l’environnement peut légèrement changer en cours de projet, il est tout de même important de noter qu’il faut tout préparer dès le début pour pouvoir ensuite mettre le focus sur la réalisation et non sur sa mise en place.

Et je ne parle pas de langages de programmation là puisque cela a déjà été discuté normalement à la première étape et à l’élaboration du projet. Je parle bien entendu du cycle complet de développement que vous devez mettre en place pour votre projet.

Mettez en place votre stack en prenant en compte les choix du client

Vous devez donc penser à votre système d’intégration continue et de déploiement continu (CI/CD). Et vous devrez au préalable prendre des renseignements auprès de votre client concernant l’hébergement de tout cela.

Ce genre de système est très souvent hébergé dans le Cloud sans vraiment savoir où par moment. Et certains clients ont des restrictions concernant cela.

Il faut donc les prendre en compte et adapter votre environnement de développement en conséquence. Vous ne pourrez pas automatiser certaines choses comme vous pourriez le faire en temps normal.

Par exemple, l’un de nos clients veut absolument héberger ce que l’on fait sur son infrastructure réseau. Il aime avoir le contrôle et surtout il a une équipe informatique pour gérer cela. On ne peut pas faire du déploiement continu de manière traditionnelle et c’est donc manuel.

Il faut prendre ça en compte.

De plus, il est très à cheval sur la sécurité des données et nous ne pouvons pas faire du déploiement continu externe à son infrastructure pour nos Review App par exemple.

Bien entendu, profitez si vous êtes chargé de le faire de réserver et commander tout ce dont vous pourriez avoir besoin pour la production comme le nom de domaine, le serveur, etc.

Créez vos dépôts

Une fois que vous avez éclairci ce point avec le client et que savez ce que vous pouvez déployer dans le Cloud ou non, vous devez créer le ou les dépôts de code que vous allez utiliser pour votre projet.

Et je ne parle pas juste de créer votre dépôt sur Github avec un README vide. Je parle de créer un dépôt prêt à l’emploi.

Admettons que vous souhaitiez faire une application en Angular et que cette application soit déployée sur Heroku.

Vous êtes très bon élève et vous allez effectuer des tests unitaires et vous voulez faire en sorte que votre application soit déployée automatiquement lorsque tous les tests sont au vert. Vous allez utiliser un outil d’intégration continue comme CircleCI.

Et bien c’est le moment de tout configurer ce petit monde aux petits oignons. Vous allez créer un nouveau repository avec Angular de préinstallé dessus et vous allez connecter Heroku sur votre repository Github.

Vous allez ensuite configurer CircleCI suivant vos critères de développement que vous avez défini en équipe en veillant bien à faire en sorte que si les tests ne passent pas, le déploiement sur Heroku ne se fera pas.

Mine de rien, faire cela en tout début de projet va vous enlever une charge mentale pour attaquer votre projet, car suivant votre configuration, il faut prendre en compte que cette étape prenne plus ou moins du temps et être assez technique sur certains bords.

Étape 3 : La gestion de votre projet en méthode agile

On n’en a pas encore parlé, mais cette étape peut être effectuée avant l’étape 2 ou en même temps si vous avez plusieurs personnes sur le projet. Je parle bien entendu de gérer votre projet en méthode agile.

Pourquoi je fais cela avant la mise en place de l’infrastructure ?

Vous pouvez le faire avant l’étape 2 et inclure les tâches que vous devez faire pour mettre en place votre infrastructure dans votre outil de gestion de projet. Personnellement, je n’aime pas le faire, mais ce n’est que mon avis personnel.

Vous vous demandez peut-être pourquoi ? Tout simplement parce que ce ne sont pas des tâches concernant le projet.

Bien entendu, ces tâches sont intimement liées au projet, mais elles n’ont pas un but précis de la méthode agile où l’on doit définir des Users Stories en rapport à des fonctionnalités de l’application.

Mettre en place votre stack cela n’intéresse pas votre client et en plus cela peut fausser les statistiques des sprints du projet.

Mais ce n’est que mon avis donc ce n’est pas une mauvaise chose si vous le faites.

Créer votre projet dans votre outil de gestion de projet en incluant votre vision globale

Revenons à l’intérêt de cette étape. C’est là que vous allez créer votre nouveau projet dans votre outil de gestion de projet.

Nous utilisons dans notre cas Taiga remplit bien sa condition en terme de gestion de projet en méthode agile, mais qui on ne va pas se le cacher est très loin d’être parfait surtout au niveau ergonomique.

D’ailleurs, à l’heure où j’écris ces lignes, on benchmark pour changer d’outil.

Donc vous créez votre projet et vous allez commencer à créer vos grosses briques applicatives que vous avez normalement identifiées via votre vision globale.

Pour rappel en méthode agile SCRUM, une Epic permet de regrouper des Users Stories sous une même catégorie ou thématique.

Par exemple, vous pourriez avoir un Epic Ventes et avoir comme User Stories gestion des devis, gestions des commandes, gestion des factures et gestion des bons de livraison. Ce n’est qu’un exemple, mais vous voyez comment ça se passe.

Donner la vision du projet à votre client

Invitez votre client sur votre outil pour qu’il ait la même vue sur son projet que vous, mais également la vision globale que vous avez comprise et imaginé. Mais attention, n’invitez pas n’importe comment votre client sur votre plateforme.

N’oubliez pas que vous devez rester le maître de la gestion du projet et que si le client travaille avec vous c’est parce qu’il vous la délègue de manière indirecte. Vous êtes l’expert sur ce domaine et vous devez appuyer votre position.

C’est pour cela que vous devez faire en sorte qu’il n’est jamais le contrôle du projet, mais qu’il se sente accompagné et alerté sur l’avancée de celui-ci.

Expliquez donc bien comment vous allez gérer votre projet et ce que vous attendez de lui en lui indiquant la position qu’il aura dans le projet et lui rappeler sa plus-value. J’insiste vraiment sur ce point, car vous devez être ferme sur la gestion de votre projet.

Si votre client s’immisce dans votre rôle de chef de projet et qu’il essaie de le conduire, vous allez tout droit à l’échec, car vous aurez perdu le contrôle.

Votre client peut très savoir gérer un projet, mais a-t-il déjà géré un projet informatique ? Il est fort à parier que non sinon il n’aurait pas fait appel à vous, car souvent des personnes qui savent gérer des projets informatiques ont une équipe d’informaticien derrière eux.

Donc, n’oubliez jamais : gardez le contrôle.

Vous lui expliquerez votre outil lors de votre première réunion avec lui lors du lancement de votre projet.

Étape 4 : Réaliser autant d’ateliers qu’il y aura de fonctionnalités dans votre projet

J’aime bien ce mot atelier, car c’est exactement ce que vous devez faire. Réaliser des ateliers avec votre client. Le plus simple pour estimer le nombre d’ateliers à prévoir c’est de regarder votre liste d’Epic dans votre outil de gestion de projets.

C’est le bon indicateur qui va vous dire combien d’ateliers vous avez besoin. Essayez de les programmer dans un temps assez restreint c’est-à-dire sur un ou 2 mois maximum suivant l’ampleur du projet.

Profitez du premier atelier pour intégrer votre client sur votre outil de gestion de projets et de lui expliquer ce que vous attendez de lui.

Il est vraiment primordial de faire ses ateliers, car vous allez approfondir chaque partie du projet en détaillant exactement ce que vous devez effectuer.

C’est à ce moment-là que vous allez définir les Users Stories avec votre client. Oui votre client ne doit pas les définir seul.

Vous avez un rôle d’accompagnant sur le sujet. Nous seulement vous aurez la garantie qu’elles seront complètes, mais vous allez pouvoir créer une bonne interaction directe avec votre client en challengeant ses idées.

D’ailleurs, définir des Users Stories ça ne se fait pas n’importe comment pour avoir quelque chose de correct et surtout de complet.

Je vous invite très sérieusement à lire cet article tellement bien fait et partagé par l’un de mes collègues qui explique comment bien rédiger ses Users Stories. 3 groupes de mots qui vont aider et changer votre vie pour vos Users Stories : en tant que, je veux et afin de.

Ne négligez pas cette partie ! Un détail mal compris ou zappé et cela peut faire capoter votre projet en un rien de temps donc prenez votre temps et discuter en profondeur avec votre client.

Étape 5 : Estimez et définissez votre roadmap

Suivant votre mode de fonctionnement ou votre client, vous allez devoir effectuer un rétroplanning afin de vous projeter sur la durée du projet et de vous fixer des objectifs.

Et dans certains cas, vous allez définir votre roadmap au fil des semaines en fonction de la réalisation de vos sprints.

C’est notre manière de fonctionner pour le deuxième cas. Nous allons constituer nos sprints suivant l’avancée de notre travail et surtout estimer toutes nos Users Stories en point d’efforts.

Vous l’aurez donc compris une fois notre sprint défini, c’est à ce moment-là et uniquement à ce moment-là que l’on va commencer à coder et pas avant.

Quand nous commençons à avoir quelques choses de concret à montrer à notre client et surtout s’il y a vraiment une plus-value à le faire, nous prenons le temps de lui montrer.

Autrement le client a tout le temps une vue d’ensemble sur la réalisation et l’avancée du projet. Il peut consulter la réalisation du sprint en cours, mais aussi voir les états d’avancements directement sur les Epics.

Autre chose que je vous conseille c’est de définir les sprints avec votre client pour entretenir la relation avec votre client et le faire participer de manière indirecte.

Je ne vais pas m’attarder sur cette dernière étape, car sinon cet article ne s’appellerez pas comment bien démarrer un projet.

Epilogue

Voilà j’espère que cela va vous aider à pouvoir bien démarrer vos projets de développement. Cela a l’air simple quand on le lit, mais ça ne l’est pas bien entendu. Cela demande du temps et de l’énergie à mettre tout cela en oeuvre.

Mais en tous cas vous avez un bon exemple où vous pouvez vous inspirer pour faire votre propre liste de choses à faire pour démarrer vos projets.

Je vais juste terminer cet article avec 2 conseils qui pourront vous aider et que la plupart des gens peuvent rencontrer pendant la gestion d’un projet et devinez quoi cela concerne votre client.

Votre client, la plus grande variable de votre projet

Je vous expliquer comment bien démarrer un projet et comment nous les démarrons où je travaille. En respectant ses étapes, il est sûr que vous maximiserez vos chances de réussir le démarrage de votre projet ainsi que sa réussite.

Mais il est sûr que nous n’arrivons pas à gérer nos projets comme on le voudrait et je l’ai déjà indiqué dans certaines de ces étapes.

La seule variable que vous ne maîtrisez pas et qui sera différente d’un projet à un autre c’est votre client.

Certains vont adhérer facilement et rapidement à votre façon et votre vision de gérer un projet alors que d’autres ce sera l’inverse. Très souvent ce sont des clients qui n’y connaissent rien en informatique et qui aiment tout contrôler et tout faire.

Il n’y a pas de recette miracle et au risque de me répétez comme j’ai dit plus haut, vous devez être ferme, mais courtois, mais bien expliquer à votre client que c’est VOUS qui gérer le projet et pas lui. Sinon quel intérêt de vous solliciter à la réalisation de son projet ?

Et suivant votre interlocuteur vous devrez trouver les arguments et les bons mots pour lui expliquer. Gardez en tête que c’est vous l’expert dans votre domaine et pas votre client.

Vous savez ce qui fonctionne et ce qui ne fonctionne pas et il ne faut pas avoir peur de dire à votre client que si votre façon de travailler ne lui convient pas, il ne sert à rien de collaborer ensemble sur son projet.

Vous devez faire en sorte de placer votre client au centre du projet pour qu’il apporte son expertise métier, que vous allez implémenter dans son projet et uniquement cela c’est tout.

Schématiser la chose en prenant l’exemple d’une voiture. La voiture c’est le projet, votre client c’est le carburant et vous êtes le conducteur. Et les rôles doivent rester comme cela tout le long du projet.

N’ayez pas peur de votre client

Est-ce cela vous arrive de ne pas vouloir faire répétez à quelqu’un ce qu’il vient de dire au risque de passer pour un imbécile ? Cela m’arrive souvent et j’ai encore du mal à le faire, mais je me fais violence.

Si vous n’avez pas compris quelques choses que votre client vous explique, vous ne devez pas hésiter à lui faire répéter plusieurs fois si nécessaire.

Car cela peut être un problème de compréhension de votre part, mais également un problème d’explications de votre interlocuteur.

N’oubliez pas que vous découvrez peut-être un nouveau métier, un nouveau domaine et de nouveaux termes, il est donc normal que vous ne puissiez pas comprendre tout du premier coup.

Ne pas solliciter votre client à vous réexpliquer quelques choses vous ouvre un risque de passer à côté d’une information essentielle que vous devrez peut être payé plus tard sous forme d’une erreur ou d’un oubli.

Donc, n’ayez pas peur de votre client et faites-le répéter.

Partager cet article :

Vous pourriez aussi aimer ❤️

Github Copilot : Mon avis après 2 mois d'utilisation

Github Copilot : Mon avis après 2 mois d'utilisation

Comment être productif en programmation ?

Comment être productif en programmation ?