L’autre matin en arrivant à la Gare pour prendre le train, je vois des jeunes filles qui distribuent dans le froid des prospectus. Il s’agit d’un programme immobilier dont la construction va bientôt débuter en ville. Ces petites brochures montrent généralement quelques futurs appartements en situation. Un dessin idyllique trop beau pour être honnête représente votre futur immeuble dans une belle rue avec des arbres, aucuns immeubles aux alentours, des gens qui baladent un chien en chemisette, bref le cliché d’un monde parfait. Cela vous rassure, et vous tournez la page pour découvrir les différents appartements. Un crayonné un peu audacieux d’une blonde à forte poitrine entrain de nourrir un chat dans une cuisine, un plan de travail en marbre du Portugal, des volets électriques, vous vous voyez dans votre future cuisine… Toutes ces illustrations sont annotées d’un astérisque discret. Le petit texte en bas dit clairement « Photos non contractuelles, illustrations d’exemples, chiffres donnés à titre d’exemple ».
Dans la petite Startup où je travaille en ce moment, après un mois très Scrum, je me suis retrouvé à devoir créer un document d’architecture générale, suivi de spécifications techniques détaillées. Cela n’a pas été facile de se poser pendant une semaine, de sortir un plan détaillé, un chiffrage en jours-hommes, un planning « prévisionnel ». A tel point que si Luc qui travaille avec moi ne m’avait pas un peu forcé, j’aurai laissé tombé cette partie. Mon point de vue était de dire qu’il était inutile de perdre du temps à faire de la documentation… Grave erreur d’appréciation, caprice de consultant biberonné à la Scrum, je me rends compte que je n’étais plus objectif. Voici pourquoi.
Tout d’abord avant de débuter n’importe quel projet, il est nécessaire de réfléchir un minimum à l’architecture globale. Celui qui vous vend que faire du Scrum dès le démarrage fonctionne, a tord. Il est nécessaire de réaliser une phase d’amorçage, durant laquelle l’Agilité peut être utilisée, mais durant laquelle il est encore trop tôt pour parler de méthodes de développements. Un bon tableau blanc, un appareil photo pour prendre des photos de vos dessins sur ce tableau, un stock de feuille, des feutres de vos enfants de toutes les couleurs, un bon café, des gens avec vous pour challenger vos idées… vous devez passer par cette phase d’accouchement. C’est un business plan technique.
Réaliser un chiffrage… mon dieu. Moi qui bassine tout le monde en disant que les chiffres ne servent à rien, que le prédictif c’est bon pour Mr Marabout à la sortie du Métro Barbès… Je continue à croire cela. Je me rends compte aussi que pour mesurer les ressources nécessaires, communiquer nos besoins techniques, et ensuite pouvoir suivre le réalisé par rapport au prédictif, il faut chiffrer. Il ne faut pas tenter de chiffrer 234,4 jours mais simplement se rendre compte que, au vue du cahier des charges, 200 jours théoriques sont à prévoir. Ensuite nous avons découpé notre projet avec un chemin critique. Le travail que j’ai fait en décembre me permet de lever les points sur lesquels nous étions pas ou peu confiants. Ce réseau de PERT est un indicateur qui nous servira plus tard pour le séquencement de nos itérations. Nous allons faire du Scrum, mais nous avons aussi d’abord pensé à ce que nous voulions faire, en parlant exclusivement technique. Un peu comme un plan pour un architecte.
Viens ensuite la documentation. Celle-ci est un indicateur qui rassure les non-techniciens de l’équipe. Elle indique que nous avons marqué nos idées et nos discussions quelque part. Je pense que ce n’est pas complètement débile, que de capturer à un instant donné vos idées non ?
Si vous faîtes des prototypes ou des maquettes en Java, soignez la présentation. Prenez 20 minutes pour chercher une feuille de style et quelques icônes afin que votre prototype soit sympa. L’aspect compte énormément pour les personnes qui ne sont pas techniques. Elles regardent vos écrans, vous expliquez votre superbe intégration de Drools avec Grails, mais elle, elle ne voit que cette page HTML moche qui ressemble à un kleenex sale plutôt qu’à son futur site Internet.
Je vais vous parler de vous. Lorsque j’avais ce matin cette petite brochure sur ces futurs appartements dans ma ville, en fait j’ai été rassuré de voir la qualité de la cuisine, l’environnement, la belle façade du bâtiment. Du coup je ne me suis pas interrogé si le plombier a posé du PER ou du cuivre dans la salle de bain. Je ne me suis pas demandé s’il y aura des prises RJ45 dans le salon, si finalement les fenêtres sont en double ou triple vitrage. J’ai été rassuré par l’illustration. Je n’y connais rien en construction de bâtiment, je vous fais confiance. Par contre si votre immeuble de haute-qualité environnemental est moche, je ne l’achèterai pas. Et bien c’est peut-être la même chose entre vous, développeur, et votre client qui n’est pas développeur. Pensez-y.
Lorsque vous rédigez de la documentation, vous rassurez vos partenaires car vous montrez que vous avez pris le temps de capturer ce qui fera le coeur de la Startup. Cette documentation peut vous faire réfléchir sur le projet. Elle peut vous permettre de vous dire qu’il vous faut 5 développeurs. Je me rends compte que je suis entrain d’écrire un « Business Plan Technique » afin d’aller le présenter aux responsables de la Startup. Moi aussi je suis à la recherche de crédits-développeurs et de crédits-achats de machine. Et c’est finalement ces quelques documents écrits en une semaine qui vont me servir pour faire tout cela.
Alors oui nous ferons du Scrum, mais lorsque nous aurons une équipe. Et maintenant nous pouvons justifier qu’il faut 4 développeurs par exemple…
Suite de mes aventures au prochain numéro.
0 no like
Salut le touilleur,
Meilleurs voeux et le plein de réussite dans tes nouvelles aventures.
En 2010 j’avais pris comme résolution de ne pas être tout le temps d’accord avec toi.
Et bien c’est raté et une fois de plus je te soutiens dans ce que beaucoup appèleront « Scrum but » mais qui s’avère la pratique la plus pragmatique du moment.
J’ai fait un premier bilan sur la dizaine de projets Scrum que nous avons mené en 2009 et je m’aperçois que les projets les plus performants sont les forfaits agiles sur lesquels on a commencé par chiffrer puis spécifier avant d’accepter du changement au fil des sprints.
Je n’ai pas de chiffres divulgables pour l’instant mais je vais essayer d’en extraire.
Dernier point important souvent négligé dans le Manifeste Agile : « Working software over comprehensive documentation »
« Over » ne veut pas dire « à la place » mais « au dessus »
Donc le must reste un projet construit par sprints et documenté.
Just my 2 cents
Geoffray
oh mon dieu !
Attention, bientôt tu vas faire du RUP si ca se trouve !
Resiste ! ne tombe pas dans le coté obscure du management de projet 😉
Plus sérieusement, je pense que c’est important d’avoir cette bonne base pour commencer un projet et réussir les sprints à venir.
Samuel
Je trouve que ce qu’il en ressort tout de même c’est que tout ce travail est fait pour les autres et pas vraiment pour le projet.
Sans doute, ça ne peut pas être évité dans ton contexte.
Néanmoins, je me demande si les partenaires ne devraient pas faire l’effort de se passer de « jolies » documents qui au final ne servent pas le projet en lui-même.
Punaise, ça fait du bien un article du Touilleur. Ca motive ses troupes à bosser dans le bon sens! Je suis entièrement d’accord sur toute la ligne : le chiffrage macro, la doc pour rassurer la direction (juste ce qu’il faut – de toute façon, si quelqu’un du management la consulte, il la survolera à peine comme la pub pour tes apparts), la maquette soignée. Je dis oui et j’en redemande! Merci.