28 Janvier 2021
Les mêmes questions se posent toujours au lancement d’un nouveau projet d’applications web ou mobile !
Voyons quels sont les éléments de réussite à mettre en place pour délivrer rapidement les bonnes applications au bon moment. Dans un souci de clarté, nous nous attacherons aux quatre éléments suivants :
Avec la transformation numérique, les entreprises ont un besoin toujours plus important d’applications métier pour faciliter et améliorer leur fonctionnement. Mais avant d’entamer la réalisation des objectifs fonctionnels, il faut produire à moindre coût l’architecture logicielle et le code purement technique nécessaires à toute nouvelle application.
Le développement d’applications reste encore très artisanal. On développe tout à la main. C’est beaucoup trop long et beaucoup trop cher !
Les demandes pour de nouvelles applications sont pourtant en très forte hausse alors que les ressources disponibles sont en baisse.
Selon la Commission Européenne, 800000 postes n’ont pas été pourvus en Europe en 2020.
Le développement traditionnel d’application ne peut plus suivre le rythme ! Même avec des frameworks modernes comme .NET 5.
Selon la définition de Forrester, une plateforme low-code permet une livraison rapide des applications métier complexes avec un minimum de développement manuel et une configuration et un déploiement rapides.
Le principal avantage d’une génération low-code est bien sûr la vitesse et l’augmentation de la productivité qui en découle. On ne perd pas de temps à tout coder manuellement ! Avec ce type d’outils, les développeurs peuvent produire plus d’applications et cela, sans augmenter la taille de l’équipe informatique.
Aujourd’hui, la demande croissante pour de nouvelles applications oblige votre organisation à repenser son approche du développement d’applications d’entreprise. Les plateformes low-code contribuent à résoudre ce défi en permettant aux développeurs de créer rapidement et facilement des applications pertinentes qui auront un effet important sur vos résultats.
Depuis quelques années, on entend beaucoup parler de no-code. Ce serait l’étape ultime puisqu’il s’agirait de créer une application entière en se passant complètement du code. Et donc, des développeurs…
C’est déjà le cas… pour des choses relativement simples : une application mobile de consultation des données, des formulaires, des sites web particulièrement en Single Page Application.
Mais soyons clairs : pas d’ERP professionnel complet en no-code. Les applications d’entreprise, domaine d’intervention de Artza Technologies, nécessitent souvent des traitements complexes sur les données avec des règles de gestion fonctionnelle évoluées. Pour ce type d’application métier, le low-code est intéressant puisque permettant d’obtenir plus rapidement et avec moins d’effort une première version opérationnelle de l’application.
Le no-code semble prématuré. A moins que l’Intelligence Artificielle un jour…
La bonne gestion d’un programme d’application est l’art de rassembler des profils, de définir des responsabilités et des rôles, au sein d’une organisation commune. La méthode choisie doit vous fournir un cadre fort avec des règles, des instructions, des outils pour gérer efficacement l’ensemble de l’équipe projet.
Chaque année, VersionOne publie son rapport sur l’état de l’agilité dans le monde. On peut facilement en déduire les 5 principaux bénéfices.
La méthode à retenir pour un projet particulier doit être travaillée, raffinée et adaptée au contexte unique de votre projet.
Choisir de gérer votre projet en s’inspirant de Scrum est probablement une bonne décision…
Mais il ne suffit pas de le décider et il ne s’agit pas de l’imposer. La préparation agile de votre projet sera fort différente si la plupart des personnes ont déjà travaillé sur un projet géré en Scrum ou si, au contraire, quasiment personne n’est capable d’identifier le rôle de Product Owner.
Bien sûr, il est important de « faire agile » en organisant le projet autour des rituels, des cérémonies et des outils. Néanmoins, l’objectif est d’être agile, ce qui implique une prise de conscience individuelle et collective et permet d’atteindre en permanence les piliers de l’agilité que sont l’information et la transparence, l’inspection régulière et l’adaptation continue.
Le développement agile cherche à produire de la Valeur Métier décrite au moyen de Récits Utilisateur (US : User Story) :
Un écueil classique à éviter ici est le raccourci : l’agilité, c’est Scrum ; Scrum, c’est les Sprints ; les Sprints, c’est la phase de réalisation.
Scrum est une petite partie de l’agile ; les Sprints sont une petite partie de Scrum ; etc
L’écueil que nous mentionnons ci-dessus conduit souvent à une focalisation excessive de la phase de réalisation. Or, enfonçons une porte ouverte, la phase de réalisation se passera d’autant mieux que la phase de mûrissement aura été aboutie, fonctionnellement et techniquement.
Réussir la phase de mûrissement implique de rédiger des User Stories efficaces en insistant sur l’importance des critères d’acceptation qui sont un composant absolument essentiel dans la rédaction d’une User Story ou Récit Utilisateur.
Rédaction des critères d’acceptation avec le langage Gherkin
Une itération est une période durant laquelle des fonctionnalités et des récits sont implémentés techniquement. La durée des itérations est généralement comprise entre deux et quatre semaines : la durée doit être suffisante pour que l’équipe puisse produire un travail significatif et, en même temps, assez courte pour laisser place au changement.
Avoir défini une méthode sur son projet partagée et acceptée par toute l’équipe, c’est bien !
Avoir choisi une méthode de type agile en mêlant « faire agile » et « être agile », c’est encore mieux !
Néanmoins, la meilleure méthode du monde ne saurait être appliquée de façon optimale sans un outillage précis et rigoureux. Dans l’environnement Microsoft, il existe depuis une quinzaine d’années une gamme d’outils : TFS (Team Foundation Server), VSTS (Visual Studio Team System), Azure DevOps.
Azure DevOps se décline en version Services ou Server. Comment choisir entre ces deux versions (cloud ou sur site) ? Voyez 5 éléments pour vous guider !
Les grands services ci-dessus définissent la navigation dans Azure DevOps
Un projet créé dans Azure DevOps s’appuie sur un modèle de gestion de processus qui, par défaut, sont au nombre de quatre :
Parmi les ressources proposées par le projet Azure DevOps, on trouvera pour la gestion agile des éléments de travail (workitems) de différents types, des backlogs sur plusieurs niveaux (Epic/Epopée, Feature/Fonctionnalité, User Story / Récit Utilisateur), des tableaux Kanban et tout ce qui permet de configurer l’organisation agile du projet : les itérations, les zones et les équipes.
Chaque modèle de gestion de processus apporte ses types d’élément de travail.
Lorsqu’on a des modifications de masse à faire sur des éléments de travail, quel que soit le type, Excel prend en charge l’intégration des projets Azure DevOps. On peut ainsi très facilement gérer des listes d’éléments de travail.
Azure DevOps fournit des tableaux de bord pour chaque projet sur la base de catalogue de widgets prêts à l’emploi. C’est une fonctionnalité très utilisée qui permet la gestion de projet « en un clin d’œil » !
Le Wiki est une fonctionnalité apparue avec Team Foundation Server 2018 qui remplace avantageusement le site Sharepoint associé au projet des anciennes versions de TFS. Il n’est pas créé par défaut à la création du projet.
Grâce à une bibliothèque très riche d’extensions, il est facile d’ajouter dans Azure DevOps des fonctionnalités utiles. Par exemple, une extension pour gérer les rétrospectives agiles
Le principe de méthode DevOps est de rapprocher les équipes de développement (Dev) des équipes d’infrastructure et de production (Ops) en intégrant, dès la conception du projet, toute la chaîne : la conception de l’architecture logicielle et les développements, les tests, les contraintes d’infrastructure et les méthodes de production.
Une démarche DevOps, appelée aussi CI/CD (Continuous Integration / Continuous Deployment), inclut les étapes suivantes :
Azure DevOps, comme son nom l’indique d’ailleurs, propose toutes les fonctionnalités nécessaires pour la mise en place d’un démarche DevOps complète. Cela se passe dans la rubrique Pipelines (Builds & Déploiements) et Test Plans (gestion des tests fonctionnels).
On doit s’assurer régulièrement que l’ensemble du code-source archivé sur le référentiel central, par exemple les Repos Git, compile correctement et sans erreurs. La meilleure façon est de paramétrer des pipelines de Builds qui se déclencheront automatiquement, à un moment précisé par une date et une heure ou selon un événement. Tous les projets devraient posséder un type de build spécifique qui se déclenche lors d’un archivage dans le Repos de code : c’est la Build d’intégration continue ! En abrégé CI pour « Continuous Intégration ».
Bien sûr, on peut définir tout un tas de builds à vocation différente :
De manière générale, les tests constituent un élément de réussite absolument indispensable ! Tout simplement pour s’assurer qu’un livrable correspond au besoin selon plusieurs niveaux : fonctionnel, performance, sécurité, …
Les tests unitaires font partie des tests techniques et sont considérés comme une bonne pratique de l’agile eXtreme Programming. Ils sont écrits par les développeurs eux-mêmes et cherchent à couvrir une partie importante du code en vérifiant que chaque « unité » du code fonctionne correctement. La notion d’unité diffère selon le langage de programmation utilisé :
Les tests unitaires amènent à écrire du code plus propre et plus maintenable en encourageant à adopter les bonnes pratiques de conception (SOLID) et à écrire un code moins couplé.
La métrique de qualité pour les tests unitaires est la couverture de code qui indique un pourcentage de lignes de code appelées pendant l’exécution des tests unitaires :
En écrivant les tests après le code, nous aurons tendance à écrire des « happy path tests »
Le Test Driven Development (TDD) est une technique qui guide le développement en écrivant les tests (Martin Fowler). Il s’agit donc là d’écrire les tests unitaires avant le code selon les trois lois du TDD (Rober C. Martin) :
Les tests d’acceptation ou tests fonctionnels prouvent que le logiciel fonctionne conformément aux attentes de l’utilisateur. Ces tests traitent le logiciel comme une boite noire et vérifient les réponses reçues par l’utilisateur en fonction de ses actions. Comme souvent avec les tests, quel que soit leur type, il s’agit de vérifier que la réponse obtenue est bien la réponse attendue.
Les tests fonctionnels sont automatisés avec des outils comme Ranorex ou Selenium. Une fois entièrement automatisés, les tests fonctionnels peuvent être exécutés très facilement et très fréquemment dans des pipelines de Builds !
Azure DevOps, quel que soit le modèle de processus de gestion de projet choisi, propose trois types d’éléments de travail pour gérer les scenarios ou scenarii de tests :
Le Behavior Driven Development (BDD) est l’équivalent pour les tests fonctionnels du Test Driven Development (TDD) pour les tests unitaires. Le BDD étend le TDD et met en valeur l’aspect métier sous forme de scénarios compréhensibles par tous les acteurs d’un projet. Ces scénarios sont donc écrits avant le code et sont transformés en tests exécutables.
Le langage Gherkin est fortement recommandé pour l’écriture des scénarios ! Il s‘appuie sur la syntaxe GIVEN WHEN THEN ou, en français :
ETANT DONNÉ que je suis abonné et que je suis sur la page de recherche d’un ouvrage
LORSQUE je saisis l’auteur, le titre ou la référence
ALORS je peux consulter la liste des ouvrages correspondants triés par auteur
Pour aller plus loin sur les techniques de tests à adopter en environnement agile, voici un article complet sur les avantages et caractéristiques du TDD et du BDD
Que se passe-t-il à chaque déploiement ?
On peut lister les bonnes pratiques suivantes :
Arrivé au stade du choix des environnements pour les déploiements, l’architecture logicielle et le code sont produits au moins une première fois, la gestion agile du projet est en place et gérée par Azure DevOps qui assure également la démarche CI/CD. Idéalement donc, toutes les étapes du projet sont automatisées, notamment les Builds, les tests techniques et fonctionnels et les déploiements.
Les environnements à prévoir pour réussir son projet d’application sont toujours classés en trois grandes catégories :
On peut toujours trouver plein d’autres appellations : intégration, QA, Validation, Homologation, Re7MOE, Re7MOA, Qualif, Pré-prod, … Mais, normalement, on doit pouvoir se référer aux trois grandes catégories citées ci-dessus.
Première chose à garder à l’esprit : les environnements de Développement et de Recette doivent être le plus proche possible de l’environnement de Production.
Prenons par exemple la réalisation d’une application web avec .NET 5 et une base de données SQL Server. Les environnements pourront prendre l’une des trois formes suivantes :
L’environnement de développement d’une telle application en mode Cloud SaaS correspond à l’ensemble de ressources Azure suivant :
Evidemment, des ressources Azure sont potentiellement accessibles à tout le monde. On veillera donc à sécuriser les environnements Azure.
Pour réussir vos projets d’applications, il vous faut :