Agilité, processus et méthodologie, l’avis de François Tonic
Après notre premier article sur François Tonic et Programmez!, découvrez en la suite maintenant avec ce second opus axé sur l’Agilité, les nouvelles technologies et l’application des bonnes pratiques selon les structures et les équipes.
Scrum, DevOps, Agile, aucun des termes les plus usités ces derniers temps n’a été oblitéré par François. Lorsqu’on parle évolution du marché, le rapport à l’agilité et au Crafts est évident. Aussi, il paraissait évident que notre interlocuteur mette le ola dès le début en spécifiant bien que l’Agile n’est autre que le bon sens même et que, comme toute technologie et toute bonne pratique, il est important d’adapter au cas par cas plutôt que d’appliquer bêtement ce que l’on a entendu comme étant une « bonne pratique ». Evident certes, mais il est toujours bon de rappeler qu’appliquer Scrum ou DevOps de manière machinale ne donnera aucun résultat.
D’une certaine manière, c’est l’intelligence collective qui rentre en compte dans la prise de décision d’adopter ou non une méthodologie particulière : « Il faut savoir travailler les pratiques intelligemment. On peut voir cette évolution de prise de décision hâtive depuis les années 1990. Les approches de tests dès la conception n’auraient jamais dû sortir du métier. Il est évident que les tests auraient dû et devraient toujours être réalisés et pensés en amont. Il ne faut pas s’étonner qu’une partie des développeurs aujourd’hui prenne beaucoup de retard sur leur projet puisqu’on leur a appris à ne pas aimer les tests et à les considérer comme secondaire. C’est une énorme erreur ! » Sur ce point, Code Insider s’associe pleinement à François : un code sans tests, ce n’est pas normal et peut surtout s’avérer dangereux pour la maintenabilité du code. Et, depuis 1997 et son entrée dans le monde de l’informatique professionnel, le retour de François est agrémenté d’exemples en pagaille qui valide ses propos. Aurions-nous pu être en désaccord ? Certainement pas.
Point important relatif aux tests, leur création ne peut et ne doit pas être faite à la fin : « Si le test doit être fait alors que la prod est déjà lancée, le coût argent + temps devient trop élevé. Il faut nécessairement intégrer les tests en début de projet. » CQFD.
L’agilité ? Oui mais sans forcer !
Concernant l’Agilité, le ton est tout aussi dur et pertinent du côté de François Tonic, qui le répète : « Il n’est absolument pas conseillé de forcer les équipes à devenir Agile sans prendre le temps de valider les méthodologies et les outils selon les personnalités ainsi que d’analyser leur utilité en fonction du projet. En revanche, former les équipes avec pédagogie et les rassurer sur leur capacité à mettre en place un tel changement est essentiel. Aussi, le côté humain est extrêmement important, il faut valoriser l’homme pour valoriser le projet ». En sommes, le management prend ici sa forme la plus pure en valorisant l’humain avant la rentabilité potentielle directe.
Se pose alors la question de la pression client/entreprise qui – bien qu’ayant toujours existée – se révèle de plus en plus forte et : « à force de vouloir accélérer les choses comme réduire la sortie d’une nouvelle version de plusieurs semaines à plusieurs heures, un stress se créé au sein des équipes. L’Agile doit seulement être là pour fluidifier cet ensemble. C’est contreproductif et ridicule de donner des plannings qui ne sont pas tenables. Pour tenir un délai, le risque est alors de sacrifier ce qui n’est – bien malheureusement – plus considéré comme une priorité : les tests et la sécurité. C’est tout l’inverse de ce que l’on appelle les bonnes pratiques. Chercher à déployer un projet trop rapidement sans tenir compte de ces problématiques pose de nombreux soucis : un maximum de bugs, des défauts de conception de plus en plus complexes à corriger. La solution ? Il en existe plusieurs mais il est surtout primordial que les toutes les parties prenantes d’une entreprise, à commencer par les dirigeants, comprennent que l’on ne plus sacrifier du temps de conception au seul objectif de faire du profit rapidement. Cette façon de voir les choses est dépassée et contreproductive.»
Le développeur est le ‘coeur’ du projet
Le système est finalement rapidement un cercle vicieux puisque les clients mettent la pression sur la direction d’une entreprise qui la transmet à ses équipes de management, aux chefs de projet et finalement aux équipes techniques qui se retrouvent à faire, à contrecœur, du code sale et non scalable. Ce sont donc des notions de pédagogie et d’information qu’il est OBLIGATOIRE d’instaurer sur les hiérarchies dites verticales.
Prenons l’exemple du CTO chez Microsoft : comment faire pour que le ou les sponsors puissent se rendre compte de l’importance des tests et de la sécurité plutôt que de la rapidité de validation d’un projet. La réponse est simple, il faut expliquer les choses et les imager : « vous décidez de nous couper trois mois de conception, c’est autant de tests que nous ne ferons pas, les spéc seront bâclées et la sécurité en sera amoindrie. Par ailleurs, il faut aussi prendre conscience que sur des délais trop courts, la quantité de main d’œuvre est importante et qu’il faut alors adapter les tailles des équipes, intégrer de nouveaux développeurs et que ce sont des processus à risque pour la qualité du code ». Bref, expliquez au client directement ce que cela risque de créer comme décalage entre l’attente et la finalité du produit et que le coût final sera plus élevé en cas d’une volonté exacerbée de vouloir vendre au plus vite.
Attention tout de même, et le chef de presse qu’est François nous le rappelle, le cercle vicieux ne s’arrête pas au client mais bien à l’utilisateur final qui possède lui aussi sa responsabilité dans la situation actuelle : « Avec l’hyperconnecivité que l’on a, on veut tout, tout de suite. Si vous vous décidez à sortir des jeux avec de nombreuses versions évolutives, les cycles de développement vont être réduits et les développeurs vont se stresser seuls afin de sortir de nouveaux patchs et de nouvelles fonctions uniquement pour répondre aux désirs des utilisateurs finaux. Le développeur perd son rôle de maître du code et la qualité finale s’en ressentira forcément ce qui peut amener à des effets dramatiques sur le marketing, le business. »
Il faut remettre le développeur au cœur du processus et prendre en compte les besoins nécessaires de ce dernier afin d’accéder à un produit final aboutit et qui contentera tout le monde. Il suffit de prendre l’exemple du dernier film sur Sonic qui suscitait une forte demande. Une fois les premières images divulguées, la critique fut acerbe et il a fallu que les ingénieurs techniques se replongent sur la création graphique. L’échec marketing, commercial aurait pu être bien plus grave si les images n’avaient pas fuité. Finalement, l’erreur retombe sur les développeurs qui devaient pourtant sortir un produit impossible à sortir aussi vite sous la pression populaire.
Chacun, à son niveau, doit se sentir concerné, et déterminé ce qu’il souhaite réellement : un produit maintenable, propre et terminé ou une première version d’un produit qui n’aboutira que des mois plus tard dans sa version ultime à cause de bugs à répétition. Retrouvez d’ailleurs une explication sur les problématiques des agents de système dans le Progammez! N°234.
Enfin, terminons cette partie sur les facteurs de stress dû à une demande de processus courts en hypothétisant la fin de cette bataille des services. Afin de « casser cette logique de vouloir mettre des nouvelles versions aussi souvent rapidement », il est important de savoir qui va céder en premier puisque les limites du modèle ont désormais été atteintes. « Un développeur peut-il suivre la cadence ? Non ! Les développeurs vont avoir deux ou trois versions de retard car la vitesse de rendu est trop élevée. Il faut absolument que les langages et les frameworks évoluent aussi rapidement que les projets, ce qui n’est pas toujours le cas » nous confirme François.
Apprendre à adapter sa stratégie
Nous avons poursuivi l’entretien avec François, peu avare en explications et paroles, en s’intéressant de plus près à certaines méthodologies dites « Agiles », le TDD, le Pairing et l’eXtreme Programming, et à leur intégration dans différents types de structures et de management.
Nous avons débuté sur un sujet qui nous est cher : l’eXtreme Programming, et voici ce que nous avons pu conclure de nos échanges avec François sur ce sujet : « l’eXtreme Programming est très très intéressant dans son concept puisqu’il répond seulement à un type de besoins précis à l’intérieur du projet et qu’il permet d’aller très vite dans les POCs ; il reste une méthodologie peu, voire absolument non scalable dans une grosse boîte avec une productivité intense. Par ailleurs, cela nécessite que le PO ait une confiance aveugle en ses développeurs. Il faut donc que l’équipe et que chacun ait acquis un degré de maturité très important. Je conseillerai donc de ne pas tenter le Pairing ou l’XP avec n’importe quel développeur. » En effet, du fait de leur conceptualisation, le Pairing et l’XP répondent à des contraintes très précises et sur des itérations extrêmement courtes : prototypage / POC.
Appliqué ainsi, le Craftsmanship paraît évident pour ce type de projets. En sommes, François et nous, nous rejoignons sur le fait qu’il ne faut pas généraliser ces méthodes à toutes les équipes. A partir d’une vingtaine de personnes, il est presque impossible de mener au succès ce type de concept. L’ XP et le Pairing sont ainsi bien plus adaptés à une méthodologie dite de « startup » qui ont besoin de faire un POC vite et qui peuvent se permettre de posséder de petites équipes pour lesquelles le choix du ou des développeurs se fait au cas par cas et des profils intéressants peuvent aisément être trouvés. Dès lors qu’on attaque des projets à long termes avec des releases distantes, l’intérêt meurt. Si l’on se penche plus précisément sur le Pairing, d’autres questions sont à se poser : fonctionnent-on par feature ou par itération globale ? Une équipe dédiée à des fonctions précises ou une équipe « globale ». La question est donc plus orientée vers l’organisation et la logistique managériale. Pour le TDD, nous arrivons à des questions relativement semblables et notamment en termes de cycles itératifs où le questionnement des délais se pose.
Dans notre prochain épisode de cette série d’article, nous évoquerons avec François l’évolution qu’il souhaite donner à Programmez!, et parallèlement quels sont les principaux changements en termes de mentalité de développement, du développeur et des technologies qui seront particulièrement intéressants à suivre dans les prochains mois, les prochaines années.
Merci pour votre lecture, restez alerté en vous inscrivant à notre newsletter.