Pourquoi échouons-nous ?

Sur le Web d’aujourd’hui, nous nous appuyons sur les épaules de ceux qui nous ont précédés et construisons sur ce qu’ils ont créé.

L’échec vient du fait de ne pas reconnaître cela.

Si vous entrez un jour dans le département informatique de votre entreprise, rendez-vous à l'étage DevOps. Vous serez accueilli par une équipe de développeurs en sous-effectif, avec des écouteurs sur les oreilles et les yeux rougis par les écrans. Il y a de fortes chances qu'ils soient tellement concentrés qu'ils ne répondront même pas lorsqu'on leur posera une question.

Pourquoi sont-ils si intenses et si blasés ? J'ai vu des développeurs traditionnels être fiers de créer des applications à partir de zéro et de le faire eux-mêmes. Préférer le faire soi-même et construire à partir de zéro peut être formidable avec suffisamment de temps et de ressources, mais pour les petits projets avec un financement limité, c'est souvent la chute du projet. Lorsque des outils comme le low-code se présentent, les développeurs traditionnels ont tendance à les mépriser. Où est le défi !

Les applications créées à partir de zéro prennent une éternité. L'incapacité à compter sur le travail d'autres personnes peut rendre une création simple inutilement complexe. L'ironie est qu'il n'existe pas aujourd'hui d'application concrète qui ne s'appuie pas sur une bibliothèque prédéfinie dans Node.js ou Java.

En utilisant une plateforme low-code comme Mendix, qui vous permet de vous approvisionner sur une place de marché de Mendix- et les modules créés par la communauté sont du même concept qu'une bibliothèque Node.js pré-construite. Cela élimine la complexité inutile de la construction et vous permet simplement de livrer le résultat final.

Parfois, il n'existe rien de concret dont vous pouvez tirer parti. C'est alors que vous devez effectuer un codage long et complexe, et dans ces cas-là, vous voulez que ce code soit réutilisable par le reste de l'entreprise. Dans ce scénario, la plupart des entreprises investiraient encore du temps dans la création de composants réutilisables, et Mendix a essayé de rationaliser encore plus ce processus en créant un marché d'entreprise interne, où vous pouvez héberger chaque extension personnalisée, votre entreprise crée et partager des fonctionnalités entre les sites Web et les applications de votre entreprise, en toute sécurité avec la connaissance que votre propriété intellectuelle est protégée.

Code traditionnel vs code faible : un exemple pratique

Prenons l’idée de créer un processus d’intégration client numérique pour démontrer les différences.

Une entreprise demande à son équipe de développement de travailler sur une application qui sera utilisée pour l’intégration des clients.

L'application doit avoir les fonctionnalités suivantes :

• Une intégration à Dropbox pour stocker les données et documents des clients
• Une recherche d'adresse pour les adresses des clients
• La capacité de numériser des documents importants et d'en extraire des informations
• Une capacité à signer et à réviser numériquement des documents.

En les utilisant comme référence, l'analyste commercial de l'entreprise crée quatre user stories que ses équipes DevOps doivent exécuter.

1) En tant qu'utilisateur, je souhaite avoir une intégration avec Dropbox afin de pouvoir stocker les documents des clients dans le cloud.

2) En tant qu'utilisateur, je souhaite disposer d'une recherche d'adresse automatique afin de pouvoir trouver facilement l'adresse du client.

3) En tant qu'utilisateur, je souhaiterais pouvoir numériser des documents importants à l'aide de l'appareil photo de l'appareil.

4) En tant qu'utilisateur, je souhaite pouvoir consulter et signer numériquement des documents.

Comme il y a deux équipes au sein du département, sans aucun autre nouveau projet actif en cours, l'entreprise décide de permettre aux deux équipes de créer des applications et de les faire s'affronter lors d'un hackathon interne.

L'équipe 1 est une équipe low-code qui utilise principalement Mendix pour créer et héberger leurs applications. L'équipe est composée d'un développeur hautement qualifié, d'un comptable du service financier qui apprend à coder pendant son temps libre et d'un designer du service marketing qui est doué pour concevoir des sites Web et des applications.

L'équipe 2 est composée de trois développeurs traditionnels : un développeur Java, un développeur C# et un développeur Node.js. Dans les deux scénarios, les équipes ont également accès aux plus grandes parties prenantes traditionnelles de Scrum, comme les analystes QA et commerciaux.

Deux semaines plus tard, les deux équipes présentent leurs applications aux parties prenantes, chacune à son tour démontrant comment ses applications répondent aux user stories définies pour le défi. Et il y a un gagnant clair : l'équipe 1.

Après avoir examiné les candidatures, les juges les ont évaluées en fonction de chaque histoire d'utilisateur. Décryptons ce qu'ils ont vu.

1) En tant qu'utilisateur, je souhaite avoir une intégration avec Dropbox afin de pouvoir stocker les documents des clients dans le cloud.

L'équipe 1 a immédiatement reconnu qu'il y avait un module pré-construit disponible dans le Mendix  Marketplace. En s'appuyant sur ce concept, ils ont rapidement réussi à le mettre en place et à concentrer leur temps sur l'interface utilisateur et la documentation de leur code, ce qu'ils ont fait dans la vidéo.

L'équipe 2 a passé la majeure partie de son temps à essayer de comprendre les pages de documentation de Dropbox, et même si elle a produit une intégration fonctionnelle, l'interface utilisateur était grossière et maladroite.

2) En tant qu'utilisateur, je souhaite disposer d'une recherche d'adresse automatique afin de pouvoir trouver facilement l'adresse du client.

Une fois de plus, l'équipe 1 avait un module disponible en téléchargement et a pu le connecter rapidement, en se concentrant sur l'achèvement des fonctionnalités et de la documentation.

L'équipe 2 a eu du mal à décider quel service de recherche d'adresses utiliser. Ils avaient tous une préférence pour celui qui leur conviendrait le mieux et ont perdu du temps à décider. Finalement, ils ont réussi à le faire fonctionner grâce à Google, mais une fois de plus, l'équipe 1 n'était pas à la hauteur.

3) En tant qu'utilisateur, je souhaite pouvoir numériser des documents importants à l'aide de l'appareil photo de l'appareil.

L'équipe 2 savait à ce stade qu'elle était en retard et a fait appel à un expert du domaine pour l'aider. Si vous avez travaillé dans la gestion de projets logiciels, vous pouvez sentir le problème ici. Une loi célèbre dans le développement de logiciels est la loi Brookes qui stipule que « l'ajout de main-d'œuvre à un projet logiciel en retard le fait prendre du retard ». En faisant appel à un nouveau membre de l'équipe pour développer la fonction OCR, le nouveau membre aura besoin de temps pour rattraper son retard sur le projet, il aura également besoin de temps pour comprendre la base de code actuelle. Comme toujours, cela s'est avéré vrai et le projet a pris encore plus de retard.

L'équipe 1 a pu maintenir son rythme de développement. Elle a utilisé un module (oui, vous l'avez deviné) mis à sa disposition dans Mendix, et les low-coders sans expérience en reconnaissance d'images y sont parvenus rapidement, en s'appuyant sur leur membre le plus technique pour les mener à bien.

4) En tant qu'utilisateur, je souhaite pouvoir réviser et signer numériquement des documents.

Les deux équipes ont obtenu des résultats similaires pour cette user story, mais comme l'équipe low-code a pu exploiter son arme secrète (le comptable qui connaît le processus correct à suivre dans le système actuel), elle a pu éviter une erreur dans un flux utilisateur complexe. Il leur restait tellement de temps qu'elles ont pu également réaliser une vidéo sur ce sujet. L'équipe B ne l'a pas fait.

Mendix a donné à l'équipe A la possibilité de modéliser automatiquement le modèle de domaine de son application en téléchargeant la feuille de calcul existante, qui est automatiquement lue et recréée dans le modèle de domaine de son application. Enfin, l'équipe A a tiré parti Mendixla capacité de générer des aperçus génériques pour toutes les données requises, et grâce à cela, ils ont pu se concentrer sur toutes les intégrations critiques pour l'application.

Heure de décision

Les juges ont facilement sélectionné l’équipe 1 comme gagnante. Mais pourquoi ?

Fondamentalement, les deux équipes ont répondu aux mêmes exigences : il s'agit de la même technologie, traitée par le même fournisseur, et pourtant, l'équipe 1 a terminé en deux fois moins de temps et a passé le reste du temps à itérer et à peaufiner son produit. Voici ce qu'ils ont réussi à créer.

L'équipe a également atténué les modifications à apporter aux futurs modules utilisés. Par exemple, si la bibliothèque DocuSign nécessite des modifications, celles-ci seront gérées par le créateur du module sur la Marketplace, et l'équipe agile n'aura à refactoriser le code qu'en cas de modifications radicales après la mise à jour du module, qui auraient dû être gérées par le créateur du connecteur.

Il n’y a rien de mal à s’appuyer sur le travail des autres. C’est un progrès. Les personnes et les organisations qui ont créé ces modules et bibliothèques de code souhaitent que vous les utilisiez. Elles veulent vous épargner les maux de tête qu’elles ont connus, afin que vous puissiez vous concentrer sur la résolution de problèmes plus importants. L’avantage, c’est que vous pouvez les utiliser pour réorganiser votre expérience client et créer des processus d’intégration numérique des clients. Vous pouvez également les exploiter pour innover et moderniser un nombre illimité de systèmes et d’applications à un rythme que vous n’auriez jamais pu atteindre auparavant.