L'agilité en solitaire c'est difficile 2/2

Dans ce billet, je vais vous donner ma recette pour réussir un projet en solitaire. Il complète un précédent billet sur le même sujet, où je décrivais les problèmes que j’ai rencontrés. Je rappelle le contexte de ma situation : je travaille dans une SSII Bordelaise. J’ai effectué plusieurs missions en solitaire. Je vais essayer de lister l’ensemble des points qui me paraissent important pour réussir :

###Participez activement à l’avant vente

Notre métier consiste trop souvent à réaliser un produit, vendu par un commercial sans expertise technique, pour un client qui ne connait pas notre métier

Votre entreprise a intérêt à vous faire participer à l’avant vente. La réponse à appel d’offre est plus technique, plus pertinente, plus proche du désir du client. Vous pouvez directement ouvrir les hostilités avec votre chef en précisant que dans le temps indiqué et en consommant de l’extasie, vous ne ferez que 50% du projet. Qui mieux que vous, êtes plus à même de juger du temps nécessaire à la réalisation du projet ?

3 mois pour un projet

###Réalisez-vous même vos users stories

A partir du cahier des charges du client, découper votre travail en users stories. Prenez un moment en début de projet pour classer vos fonctionnalités par ordre d’importance pour le client (Jouer le rôle de product owner). Réitérer l’expérience quelque temps après le début du projet, autant de fois que nécessaire.

###Alertez rapidement

Essayer d’estimer vous-même la durée du projet. Utilisez vos users stories pour réaliser un burndown chart (représentation graphique du temps de travail qu’il reste à faire). Puis alertez votre responsable. Le meilleur moment pour le faire ? Après 25% du temps du projet, vous avez une meilleure vision du projet : votre burdown chart est pertinent. Et vous avez assez de matière pour justifier vos inquiétudes.

burdown chart

###Développez avec les tests

Je me suis longuement demandé si ça valait le coup ! Pourquoi ne pas faire des tests d’intégration directement ? Puis j’ai arrêté de boire. Le développement piloté par les tests est la démarche qui me permet de réaliser moins de documentation technique, de réaliser un produit de meilleur qualité, plus proche du réel besoin du client. Elle me permet de dormir la nuit, de répondre à des questions du client par des affirmations.

En solitaire vous n’avez pas le droit à l’erreur, la pression est plus forte.

Si vous n’êtes pas sûr qu’un seul mousqueton suffise, rajoutez en un!

###N’abandonnez jamais vos tests

Il est très facile de tomber du côté obscurs de la force : n’abandonner jamais les tests ! Durant votre projet vous serez peut être amené à changer et refaire des tests parce qu’une fonctionnalité a changé.

###Feedback du client, soyez malin !

Le retour d’expérience (feedback) du client est très important. Vous êtes seul, votre projet a potentiellement plus de problèmes. Il faut donc anticiper la phase d’intégration finale. Elle sera douloureuse. Essayer d’obtenir le plus de retours de votre client, en lui faisant comprendre que le logiciel comportera moins de fonctionnalités. C’est un sujet délicat. Parlez-en à votre responsable hiérarchique avant d’en parler au client. Votre commercial peut aussi à ce moment vous aider à faire avaler la pilule. Mettez en avant la qualité du logiciel et son acuité face à son utilisation réelle. Si le feedback est difficile, vous êtes dans la merde ! Obtenez au moins une réunion en début de projet. A ce moment, proposez le logiciel en version pré-beta avec une interface graphique. Vous obtiendrez forcément un retour du client, l’interface ne plaisant pas complètement. Profitez en à ce moment pour poser quelques questions pertinentes sur le produit et ses fonctionnalités (savoir si le bouton de validation doit être rouge ou bleu, on s’en fiche un peu). Attention à ce moment, faites preuve de diplomatie.

relecture: merci à Chalou