Développement Web

La Méthode à la carte

Vous pouvez composer votre offre à partir de nos divers forfaits qui, conjointement, vous proposent un accompagnement complet de l’idée au développement d’un “Produit Minimum Viable” à partir de 20.000€ H.T.

Le “Produit Minimum Viable”

Le produit minimum viable (ou MVP, de l’anglais : minimum viable product) est la version d’un produit qui permet d’obtenir un maximum de retours client avec un minimum d’effort: c’est la pré-première version de votre nouveau produit.

L’intérêt du produit minimum viable est d’évaluer la viabilité d’un nouveau modèle d’entreprise: il permet de commencer à servir ses premiers clients.

C'est une chose curieuse dans notre industrie: non seulement n'apprenons nous pas de nos erreurs, mais nous n'apprenons pas non plus de nos succès

La “Maitrise d’ouvrage Agile”

La maitrise d’ouvrage est une mission de communication et d’enquête de besoins dans un premier temps. Elle commence par la documentation des besoins au format Agile.

Concrètement, c’est un profil technico-commercial qui dont la responsabilité est la qualité de votre développement et qu’il réponde à vos attentes.

Deuxième partie de l’enquête auprès de l’équipe d’ingénieurs pour estimer chaque User Story en Story Point qui composent les Epics de manière collégiale: cela peut vite prendre toute la journée car une estimation n’est inscrite que si elle fait l’unanimité entre les développeurs !

Ce document vous servira à commencer un “Sprint de développement Agile” avec YourLabs Business Service et demander des devis à d’autres développeurs.

Il y a deux façons de construire une architecture logicielle: l'une est de la faire tellement simple qu'il n'y évidemment aucune faille, l'autre est de la faire si compliquée qu'il n'y a aucune faille évidente.

Les “Epics” et “User Stories”

Une “Histoire d’Usager” est une phrase définissant une fonctionnalité utilisée par un usager, par exemple: “L’Usager peut s’authentifier sur la plateforme”.

Une “Epique” est un ensemble d’User Stories qui vont ensemble, par exemple l’Epic “Authentification” implique les User Stories suivantes:

• l’usager peut créer un compte,
• l’usager peut s’authentifier
• l’usager peut refaire son mot de passe par mail en cas d’oubli,
• l’administrateur peut gérer les utilisateurs dans l’interface d’administration,

La documentation des besoins au format Agile est composée d’Epics et de User Stories (US).

Les “Story Points”

Le premier “point d’histoire” est attribué à la tache la plus simple, les autres sont User Stories obtiennent un nombre de Story Points proportionnels en terme de complexité.

Plusieurs User Stories peuvent être cumulées pour faire un Story Point si elles sont trop simples. Dans le cadre de l’Epic d’Authentification en exemple ci-dessus: l’ensemble des User Stories vaut 1 Story Point car c’est une démarche classique pour le développeur étant donné que l’authentification est un sujet vraiment vu et revu et il n’y a vraiment rien à inventer ici en règle générale.

Vous souhaitez plus de détails techniques sur notre méthode ?

Vous voulez apprendre le jargon des professionnels ?

Alors c’est parti !

Le “Continuous Delivery”

Un “Déploiement” est le fait de mettre du code au service d’utilisateurs, et peut nécessiter la mise à jour de données ou de structure de base de données: les “migrations”.

La “Livraison Continue” est une pratique qui consiste tout simplement à automatiser les déploiements: un développeur vous livre du code ? Vous n’avez plus qu’un bouton à cliquer pour le déployer sur votre site principal dit “de production” si vous êtes satisfaits des modifications.

Le “Test Driven Development” et ses amis

Un programme qui produit des résultats incorrects deux fois plus rapidement est infiniment plus lent

Lorsqu’un bug qui a été corrigé revient on l’appelle “une régression”. Comment s’en prémunir ? La première chose à faire n’est pas de juste corriger le bug car cela ne l’empêchera pas de revenir !

On commence par coder un deuxième mini-logiciel qui “reproduit” le bug: c’est à dire qu’il simule les conditions qui sont la cause du bug.

Puis, on exécute le deuxième logiciel et on vérifie qu’il plante: cela veut dire qu’il reproduit correctement le bug ! A ce moment là on peut commencer à développer un correctif.

Résultat: on se retrouve avec un correctif sur votre logiciel et un logiciel qui permet de détecter si le bug est toujours bien absent en un clin d’œil.

Quand on généralise cette pratique à l’ensemble de son code cela s’appelle le “Test-Driven Development” et c’est une pratique popularisée par l’“eXtreme Programming”.

Tout notre code de production est livré avec son équivalent en code de test, ce qui nous permet de savoir si on casse quelque chose ou pas à chaque fois qu’on veut modifier le code du projet !

La “Continuous Integration”

L’“Intégration Continue” est une pratique qui consiste à automatiser l’exécution du logiciel de test à chaque fois qu’un développeur veut modifier le code.

Si une modification casse un test alors le développeur est bloqué et ne peut pas envoyer les modifications en production: c’est une ligne de vie, un garde fou auquel on s’accroche pour éviter de chavirer quand on veut mettre votre code à jour.

Le code ne ment jamais, mais les commentaires parfois le font.

Nos Technologies de choix

Docker ou mieux, avec un nouveau projet CRUDLFA+ sur Django 3 (qu’on pratique depuis 2008) ainsi qu’une base de données PostgreSQL derrière un load balancer https Traefik.

Grace à uWSGI, le projet a déjà un cron, un spooler et un cache mémoire natif a disposition pour permettre d’orchestrer des calculs déclenchés de manière fantaisiste selon les besoins des porteurs de projets plus créatifs les uns que les autres n’est-ce-pas ?

Debugger est deux fois plus difficile que d'écrire du code, donc si vous écrivez du code aussi intelligemment que vous pouvez, vous n'êtes, par définition, pas assez intelligent pour le debugger.

BarCamp

Un “BarCamp” est une rencontre, une non-conférence ouverte, qui prend la forme d’ateliers-événements participatifs où le contenu est fourni par des participants.

C’est à dire qu’on se rencontre dans un contexte informel et qu’on échanges sur nos passions en informatique. Cultivons la connaissance qui se multiplie quand on la partage dans un cadre convivial et une ambiance ludique.