Agile, Scrum, mots fantaisistes pour écrire un logiciel qui offre
Quelle que soit la façon dont vous regardez les choses, d’une manière générale, les développeurs de logiciels d’applications métier ont une mauvaise réputation. Les systèmes sont presque inévitablement livrés en retard, voire pas du tout. L'utilisateur moyen d'une entreprise moyenne passera littéralement des heures chaque semaine à se plaindre des systèmes informatiques qu'il est obligé de supporter. « Pourquoi a-t-il fait ça ? », Qu'est-ce que ça veut dire ? sont quelques-unes des choses que j’entends quotidiennement.
J'ai passé des années à écrire des systèmes d'entreprise, la plupart des utilisateurs étaient positifs quant à ce qu'ils obtenaient et utilisaient. Des systèmes écrits selon une spécification initiale, testés à mort puis adaptés au fur et à mesure des besoins à un coût convenu si nécessaire. Un soutien continu pour le client et des revenus durables pour l'éditeur de logiciels constituaient une combinaison gagnante. La spécification initiale basée sur une analyse détaillée des exigences serait toujours un aperçu fonctionnel et ne contiendrait aucune spécificité du code, je pense que j'ai utilisé le pseudo-code une fois (quand j'écrivais des jeux). « C'est ce dont nous avons besoin » me suffisait généralement. En dehors de cela, il s'agissait de quelques maquettes d'interface utilisateur et de nombreuses conceptions de bases de données et c'est parti. La phase de test et de « peaufinage » du cycle de vie du développement était très importante. Les systèmes ont généralement été livrés à temps et ont fonctionné.
De nos jours (je n'aurais jamais pensé dire ça), tout ce qui concerne les systèmes est une question de planification, plus de planification et ensuite de réutilisabilité. Ce qui me semble si étranger, c'est qu'une grande partie de cette planification ne vise pas à répondre à une exigence fonctionnelle mais plutôt à détailler comment et pourquoi nous allons écrire ce que nous écrivons lorsque nous l'écrivons. J'espère que cela a du sens ? Pourquoi écrire quelque chose en 10 lignes que vous pourriez faire en 1000 au cas où vous « pourriez » avoir besoin de le réutiliser 2 ans plus tard ? Sur le plan personnel, je n'ai jamais rien écrit que je ne pourrais réécrire mieux 2 ans plus tard. J'apprends et m'améliore toujours, quand je repense à du code vieux de 12 mois, je grince souvent des dents. En regardant les offres d'emploi, il est facile de se perdre dans les méthodologies et les compétences recherchées. Est-il humainement possible qu'une seule personne sache autant de choses que je me demande souvent ? Une autre question est : produisent-ils un jour un produit ? Avec toute cette planification et cette inquiétude quant à la réutilisation du code, est-ce que quelque chose est fait ? Je connais une entreprise qui a embauché des développeurs universitaires tellement occupés à se concentrer sur le design qu'elle a fait faillite avant même qu'un produit ne soit presque prêt, sérieusement ! Combien de retards peut-on s’attendre à ce que les gens tolèrent, la phase de test n’y a jamais été un problème ! Pourquoi l'entreprise qui nous paie pour un produit devrait-elle payer pour du code qui sera utilisé encore et encore dans des projets ultérieurs et non pour elle ?
Ne vous méprenez pas, je ne dis pas que la planification est mauvaise, c'est une partie essentielle du développement des systèmes, mais ce n'est pas la seule. Peut-être que je suis de la vieille école, mais ce que j'apprécie, c'est d'écrire le système et de le faire fonctionner. Ok, je sais que les systèmes deviennent de plus en plus grands et complexes. Les grandes équipes de développeurs sont la norme. C'est juste que je pense que peu importe combien vous planifiez, visualisez et réfléchissez, quelque chose manquera toujours. Nous aspirons à des systèmes parfaits et impossibles, mais dans le pire des cas, nous ne fournissons aucun système. Vous ne me croyez pas ? Regardez Microsoft. Imaginez les heures de travail nécessaires à la planification de l'une de leurs applications ? À quelle fréquence un nouveau bug ou une nouvelle vulnérabilité est-il découvert ? Pourquoi n’ont-ils pas été examinés dès la phase de conception ? L’équipe de développement n’a même jamais pensé que la « vulnérabilité X » pourrait se produire. En termes simples, avec autre chose que le système le plus basique, il est presque impossible de planifier toutes les éventualités, aussi logique que vous soyez. Comment se fait-il qu’ils ne soient pas trouvés lors des tests ? La solution est-elle ici le développement à l'ancienne, moins de temps pour la planification (parler), plus de temps pour écrire et tester ? Moins de temps à vous soucier de la réutilisation du code, plus de temps à donner au client un produit fonctionnel ? Microsoft serait-il meilleur ou pire s'il passait moins de temps à planifier et plus de temps à tester ? Pour la défense de Microsoft, ils sont très doués pour les correctifs, je suppose qu'ils pourraient être considérés comme nous utilisant comme testeurs. Peut-être que s'ils passaient plus de temps à faire des tests appropriés, nous n'aurions pas besoin de les tester ?
Le pire exemple de planification excessive que je n’ai pas encore rencontré est celui d’un système financier que j’utilise quotidiennement. La mise en œuvre de ce système a coûté des millions de dollars, des années de planification et qui sait combien de consultants. Il est rédigé par l'un des plus grands acteurs de l'industrie du logiciel, adapté par un cabinet de conseil spécialisé en logiciels. Le résultat final est un système pratiquement inutilisable et proche d’être remplacé par un produit du commerce. C'est tellement grave au niveau le plus bas que même un clic de souris mal placé bloquera l'application. Je ne peux pas croire que ce système ait jamais été testé avant sa remise. Il a été livré très tard, la raison étant un « cycle de planification » plus long que prévu. Ce qu'il fait n'est pas si complexe, c'est juste qu'il a manifestement été planifié à un point tel que sa mise en œuvre a été précipitée après réflexion. Toute cette planification n'a même pas abouti à un système qui répondrait aux exigences fonctionnelles de base de ses utilisateurs, mais je suis sûr qu'ils réutiliseront ce code quelque part plus tard.
Quoi qu'il en soit, je viens de commencer un diplôme pour m'aider à comprendre pourquoi il est si important d'utiliser plusieurs stratégies de planification différentes. Pourquoi écrire en 1 jour ce que je pourrais passer un mois à faire « correctement » ? Je sais que je relis ceci dans quelques années et je me demande à quoi je pensais ; soit ça, soit je me dis « wow, c'est à ce moment-là que je finissais ce que j'écrivais ». Sérieusement, je suis sûr qu'à la fin, je réaliserai où je me trompe, en attendant, je vais continuer à écrire des applications en utilisant mon style RAD (je suis content qu'il ait un nom !) qui bien que ce ne soit pas du goût de tout le monde, cela me convient très bien.
nb Qui l'aurait deviné, mon approche du développement a un nom, elle est classée Méthodologie Agile ! Voici un excellent article qui explique Méthodologies Agiles en quelques détails.