TheCodingMachine | TheCodingMachine

APPRÉHENDER LES RISQUES GRÂCE AU QUALITY ASSESSMENT (QA)

Posted on 20 novembre 201815 novembre 2021 by TheCodingMachine

« Réussir à améliorer la qualité et à inscrire durablement son entreprise dans une dynamique d’amélioration continue, ne peut pas être le fruit du hasard. »

Quel que soit votre projet, il existe des méthodologies pour anticiper les risques qui lui sont liés. Chez TheCodingMachine, nous préconisons de réaliser des QA (Quality Assessment) : dans cet article nous vous expliquons pourquoi il est important de réaliser cette étude en amont de tout projet.

QU’EST-CE QUE LE QA ?

Quality Assessment ou évaluation qualitative, est l’étude d’un projet et de tous les risques qu’il comporte.
Pour cela, vous devez tout d’abord constituer une équipe au sein de votre entreprise qui sera garante de ce suivi et qui rencontrera le chef de projet pour échanger sur les risques et les besoins de son projet.
Nous vous conseillons de faire cette première étape en présentiel, même si le télétravail est de plus en plus répandu ! En effet, il est plus simple et plus rapide de la réaliser en face à face.
Ainsi, réaliser un QA vous permettra de garantir la qualité des projets de votre entreprise.

POURQUOI METTRE EN PLACE UN QA ?

Le projet parfait n’existe pas, c’est une réalité. Mais en faisant un QA, vous pourrez vous en approcher au maximum. Grâce à cette étape clé, vous décèlerez les risques tout au long de votre projet pour mieux les maîtriser.
A l’issue de cette étape, votre chef de projet recevra un document de référence qui devra être conservé en interne. Ainsi, toutes vos équipes pourront les analyser afin d’améliorer leurs futurs projets.
Chez TheCodingMachine nous avons mis en place un outil : la QA Machine, pour nous aider à la réalisation de nos Quality Assessment.

LA QA MACHINE

C’est un outil qui permet de guider cette discussion afin d’évaluer les risques et de générer un compte rendu sous forme d’évaluation descriptive. Ce document de fin comprend tous les points clés du QA réparties en plusieurs parties :

Catégorisation des risques par rapport aux questions : qui, quoi, où, quand, comment, pourquoi ?
Préconisations et recommandations de solutions
Commentaires libres

Cela aidera le chef de projet à mieux analyser les risques à comprendre son client…

QA OR NOT QA ?

Nous avons réalisé une petite enquête, interne à TheCodingMachine. Dans celle-ci, nous avons comparé les premiers projets réalisés n’ayant pas donnés lieu à un QA aux projets plus récents qui, à l’inverse, ont été réalisés à l’aide d’un QA.
Dans cette enquête, nous avons ressorti les principaux risques rencontrés et voici les résultats que nous avons observés :

D’AUTRES FAÇONS DE RÉALISER UN QA

Voici quelques méthodes existantes pour vous accompagner dans cette démarche :

Les «5S », méthode basée sur la participation du personnel. https://bit.ly/2PFFMOW
La MRP (Méthodologie de résolution de problème) https://bit.ly/2nj2ptM
Le brainstorming
Le diagramme 5M (ou diagramme de causes/effets ou d’Hishikawa), qui permet de représenter de façon claire l’ensemble des causes qui amène aux risques
Le diagramme de Pareto qui met en évidence la loi des «80/20 »
Le classique QQOCCP (Quoi – Qui – Où – Quand – Comment – Combien – Pourquoi), qui permet de bien cadrer l’ensemble du projet
L’AMDEC (Analyse des Modes de Défaillance, de leurs Effets, et de leur Criticité). C’est la méthodologie que nous trouvons la plus intéressante chez TheCodingMachine. Elle propose un calcul de la criticité du projet et est réalisable sur différents supports comme un produit, un moyen ou un processus. Les grandes étapes de cette méthodologie sont montrées sur le schéma suivant:

Pour conclure, peu importe la méthode choisie pour réaliser votre QA il y a cinq étapes incontournables pour réussir votre projet :

Identifier les risques grâce à un brainstorming avec votre l’équipe
Evaluer et hiérarchiser les risques su plus fort au plus faible afin d’avoir un aperçue global
Traiter les risques pour en éliminer un maximum ou du moins essayer de les minimiser
Suivre et contrôler les risques du projet qui peuvent évoluer tout au long du projet
Capitaliser et documenter les risques. Cette étape se réalise à la fin du projet afin de montrer les risques rencontrés, les solutions pour les traiter, savoir si ces solutions ont fonctionnées…

Donc mettre en place un QA vous permettra de réaliser vos projets plus rapidement et plus efficacement et ce grâce à une meilleure maîtrise de chaque phase de votre projet et une gestion des risques améliorée. Vous verrez très vite votre taux de réussite de projets s’accroître !

[Formation NOOB] Débugger sans peine !

Posted on 24 juillet 201821 mai 2021 by TheCodingMachine

Vous êtes chef de projet web junior ? Votre client fait face à un bug ?
Cette vidéo est faite pour vous : vous comprendrez la logique et les démarches à suivre pour débugger facilement votre application !

COMPRENDRE VOTRE CLIENT

Appel paniqué de votre client : plus rien ne fonctionne, plus rien ne va… panique générale !
Avant toute chose, il est essentiel de bien comprendre le message de votre client pour identifier correctement le problème à résoudre : vous devez écouter et reformuler le message de votre client.
Aussi, et bien que cela soit délicat, n’hésitez pas à le faire patienter… Vous devez bien identifier la nature du problème avant de vous lancer dans une correction hasardeuse.

METTRE EN PLACE UN OUTIL DE SUIVI DE BUG

Vous l’aurez compris, à ce stade, la communication avec votre client est essentielle. Pour ce faire, vous devez absolument utiliser un outil de suivi de bug, comme par exemple Mantis, Redmine ou Jira.
Quel qu’il soit, ce type d’outil est indispensable pour faciliter les échanges avec votre client, et ainsi permet d’améliorer la compréhension des problèmes à résoudre. Vous allez devoir poser de nombreuses questions sur les éléments à corriger : en découpant vos bugs en tâches, vous vous assurez de ne pas perdre le fil des actions à mener.
Il est capital d’instaurer ce type de procédure avec votre client et vous devez insister auprès de lui pour la mettre en place.

REPRODUIRE LE BUG EN LOCAL

Si vous avez le moindre doute sur le bug, ne commencez rien car vous risquez de passer à côté ! En effet, vous ne parviendrez pas à reproduire les anomalies si vous manquez d’informations, et ce malgré les efforts que vous fournirez.
Vous perdrez du temps et vous créerez une frustration tant du côté du client – qui va penser que vous n’avancez pas suffisamment vite – que du vôtre, car vous tenterez de reproduire en vain, un bug qui n’apparaît pas dans votre environnement.
Cette phase est donc elle aussi très importante : si vous ne reproduisez pas exactement le bug en local, vous allez passer à côté du bug ! Vous en corrigerez peut-être un autre, mais pas celui de votre client…
Le prérequis pour cette étape est d’être le plus proche de l’environnement sur lequel l’anomalie a été déclarée :

L’utilisation de la même branche git, ou une copie à jour
L’export/import de bases de données
L’ajout de fichiers ou d’images

Pensez à tout ce qu’il y a autour de votre projet, ce que vous avez construit mais aussi à toutes les possibilités de manipulation de votre client…

DU BUG À LA RÉSOLUTION, TOUTES LES ÉTAPES

La première chose à faire si vous faites face à un bug, c’est évidemment de consulter la console de votre navigateur. Lisez bien toutes les lignes de votre message d’erreur : si l’information n’est pas dans la première ligne, les suivantes vous diront probablement où se situe le problème !
Le message d’erreur ne vous dit rien ? Essayez de mettre un point d’arrêt dans votre navigateur, et essayer de débugger pas à pas.
Si vous ne trouvez toujours pas l’erreur, rendez-vous directement dans l’onglet Network : vous aurez une liste d’appels, en « Get » ou en « Post » qui vous permettra de rejouer facilement le test (évitez d’effacer votre cache à ce moment-là, sinon vous devrez recommencer tous vos appels).
Toujours pas de message clair ? Lisez les Logs PHP ! La plupart du temps vous aurez une trace complète – votre log d’erreurs – qui vous permettra d’identifier d’où vient le bug, vous pouvez ensuite identifier la fonction PHP et y accéder dans votre IDE.
Vous n’avez toujours pas de solution ? Ajoutez un point d’arrêt. À cet instant, XDebug vous aidera fortement car il vous permet d’aller lire l’état des variables quand vous faites votre appel.

Ce schéma vous paraît complexe ? Allez voir notre explication sur Youtube

BUG EN PROD, COMMENT LE TRAITER ?

Vous n’avez pas réussi à corriger le bug en local ? Testez ensuite sur le poste d’un de vos collaborateurs : mac, pc, navigateurs, versions différentes… Si le bug est reproduit, identifiez les différences qui vont vous permettre de le corriger.
Si vous n’arrivez toujours pas à traiter le bug, essayez de le faire sur un autre environnement de votre client (Dev, recette, préprod…).Attention, cela nécessite un certain nombre de manipulations qui peuvent impacter la solution de votre client.
Lisez les logs, vous aurez déjà 50 % de vos réponses ! S’ils ne donnent rien, vous pouvez en ajouter.

Encore sans réponse ? Reproduisez le problème en production, toujours avec l’accord de votre client, en faisant un dump de la base de données à un moment où l’activité est faible pour pouvoir faire les corrections. Une fois que tout est corrigé, n’oubliez pas d’annuler vos modifications.

ALLEZ PLUS LOIN AVEC XDEBUG

XDebug permet de faire un point d’arrêt sur votre projet, d’arrêter votre programme, d’éditer et voir vos variables au cours de l’exécution de vos tests.
L’installation dans un environnement LAMP est assez facile et consiste à voir s’il est actif dans le PHP info, et l’activer si nécessaire, sans oublier de l’ajouter dans votre IDE.
Sous Docker, notez que c’est XDebug qui va chercher votre IDE. Par exemple, PHP Storm autorise une machine à se connecter et ouvre un port sur lequel vous lui demandez de se connecter. Votre Docker ira se connecter sur le port ouvert par PHP Storm, et non l’inverse !

En pratique, près de 60 % des bugs sont des erreurs courantes, et donc faciles à corriger :

Quelle que soit l’application, pensez à purger vos caches: templates, anciennes versions…
Vérifiez la mise à jour de vos fichiers, et pas seulement le Git pull: branches git, Composer Install, build d’application Angular…
Vérifiez le jeu de données
Vérifiez que vous avez instancié vos classes

D’autres corrections peuvent être bien plus complexes que prévues…
N’oubliez pas de communiquer avec votre client à chaque action et chaque étape clé pour qu’il comprenne que vous êtes actifs !

La gestion de soi lors du sauvetage d’un projet

Posted on 31 mai 201821 mai 2021 by TheCodingMachine

Le diagnostic est sans appel, votre projet est planté. Pas de panique, TheCodingMachine vous apporte des solutions !

Poser le bon diagnostic résout une grande partie du problème, car une fois que les problèmes sont identifiés, il est possible de mettre en place un plan d’actions efficace.
Pour garantir un résultat fiable et sérieux, solliciter une société extérieure reste, à notre avis, la meilleure option (si vous choisissez cette solution, n’hésitez pas à nous appeler). Car la toute première étape consiste à se débarrasser des problèmes périphériques qui accompagnent inévitablement la dérive d’un projet et parasitent notre vision. Faire appel à un tiers qui est indépendant et sans a priori permet de dépassionner le débat.

L’importance du contexte

Réussir le sauvetage d’un projet nécessite de plonger au cœur du problème afin de dresser un tableau objectif de l’état du projet. Quels sont les problèmes ? Peuvent-ils être résolus rapidement ? Par qui et de quelle manière ?
Les solutions dépendent étroitement de l’état du projet : le projet est-il encore en développement ou bien en production. Elles dépendent aussi de la nature des problèmes : est-ce un problème technique ? Un problème concernant le périmètre ? Ces solutions dépendent évidemment de la taille du projet. Plus un projet est petit, plus il est simple de le reprendre depuis le début.
Un bon conseil : ne pas avoir peur … de supprimer le problème
Si les problèmes ont une origine technique, l’application développée a peu de chance d’être « sauvée ». Corriger des erreurs graves de conception de l’architecture est souvent très coûteux. A budget équivalent, il vaut mieux reprendre les développements techniques « from scratch ». L’analyse de l’existant doit donc être méticuleuse pour éviter de jeter une application qui pourrait être sauvée, mais également pour ne pas vouloir sauver cette application à tout prix et faire durer l’échec.

La définition du périmètre : facteur essentiel du sauvetage de projet

Posted on 11 décembre 201421 mai 2021 by TheCodingMachine

La peur du « pas assez » ou le périmètre à la dérive

La peur du « pas assez » est un symptôme fréquent. Dès l’origine du projet, le client définit un périmètre très vaste ou
exprime des besoins de plus en plus complexes au fur et à mesure du projet.Ce cas est fréquent lorsque le client souhaite lancer une nouvelle activité. Proposer de nombreuses fonctionnalités
donne l’impression rassurante d’offrir un service plus complet au client final. Dans la réalité, c’est souvent l’inverse. Il faut définir le périmètre le plus petit possible, tester rapidement et redéfinir le besoin en utilisant les retours utilisateurs ou bêta testeurs (« Pave the cow path »).
Définir un périmètre très vaste donne aussi l’impression trompeuse de coûter moins cher qu’un développement en
plusieurs étapes. Cela ne reste qu’un leurre. Au final, si de nombreuses fonctionnalités ne servent pas, le coût de ces
développements inutiles et de l’effort nécessaire pour les produire peut mener le projet vers l’échec. La dérive d’un périmètre peut aussi être attribuée à une mauvaise gestion de projet. Un prestataire en mauvaise position, comme par exemple dans le cas d’un retard important ou d’un problème de ressources, peut accepter des développements complémentaires en espérant conserver de bonnes relations avec son client. Il lui rend un mauvais service. En cumulant retard et nouveaux développements, le projet risque d’être encore plus long à
finaliser.

Le prix hameçon

Le prix proposé par le prestataire est volontairement bas afin de « hameçonner » le client. Un prestataire minimise volontairement le prix de la prestation afin de remporter le marché.
Au fil du projet, deux situations se présenteront :
• Les développements continuent car vous acceptez de nombreux avenants par rapport au prix initial
• Le projet est bloqué car vous ne souhaitez pas (ou ne pouvez pas) continuer à payer.
Ce « faux prix » peut fortement dégrader la relation que vous entretenez avec votre prestataire à mesure que le projet
avance.
Il est cependant nécessaire de faire la différence entre un acte délibéré (un prestataire qui hameçonne un client) et un périmètre qui évolue et grandit anormalement en cours de route (là, c’est un peu la faute du donneur d’ordre).

Méthode pour un sauvetage de projet efficient

Posted on 17 novembre 201321 mai 2021 by TheCodingMachine

Votre projet n’avance plus ? Il est dans une situation critique ?

Cet article se propose de vous donner les clés pour sauver un projet en distinguant différentes étapes :
1. Est-il possible de sauver le projet ?
2. Quelles sont les pistes pour résoudre les problèmes
humains ?
3. Comment résoudre les problèmes techniques ?

La différence entre le risque et une situation d’échec
Le risque est susceptible d’être géré. Il est donc possible de mener des actions correctives. A l’inverse, une situation d’échec est une accumulation de risques non gérés qui aboutissent souvent à un blocage global du projet.
Si vous vous posez la question de savoir si votre projet est totalement planté ou si vous êtes simplement en train de gérer un risque, vous êtes à une étape cruciale du développement de votre projet. En général, plus on se rend compte tard du plantage, plus c’est grave. Autrement dit, plus on accumule les risques au fur et à mesure du projet, plus le sauvetage s’annonce difficile !

Les dangers qui vous guettent !
Chaque étape d’un projet comporte des risques. La plupart des risquent qui menacent un projet sont connus à l’avance même si certains apparaissent dans des situations particulières parce que liés à une problématique unique.
Néanmoins, la manière de structurer la réponse aux besoins des utilisateurs (expression de besoin et cahier des charges) et le choix du prestataire constituent des étapes clés pour limiter tout débordement sur un projet à venir. Vous devrez y porter une attention particulière.
Si vous souhaitez en apprendre plus sur le sujet, n’hésitez pas à télécharger notre Livre blanc dédié :

Développement personnel : l’Holacratie comme modèle de management

Posted on 13 octobre 201315 novembre 2021 by TheCodingMachine

Dans notre vision d’une entreprise, le profit n’est pas la seule valeur. Nous estimons que le développement personnel harmonieux de chacun est essentiel.

L’esprit d’équipe, l’entraide et la confiance
L’implication de chaque individu se trouve dans la réussite collective. Ainsi, lorsqu’un collaborateur se trouve en difficulté, il lui suffit de l’exprimer pour trouver de l’aide auprès de ses collègues ou de son management. Pour nous, faire des efforts pour le groupe et réagir en équipe est primordial.

L’ambiance et le plaisir
Dans la continuité de l’esprit d’équipe, nous pensons que travailler dans une bonne ambiance participe à la valorisation du travail quotidien. Nous pensons que l’humour et le recul face à certaines situations permettent de libérer les esprits et de faciliter les échanges. Ainsi, bien que les missions s’effectuent dans le plus grand des sérieux, nos collaborateurs ne craignent pas les difficultés qu’ils peuvent être amenés à rencontrer.

La progression et l’épanouissement
Toujours dans l’objectif de donner du sens au travail de chacun et en conformité avec les valeurs que nous prônons, nous encourageons nos collaborateurs à évoluer en permanence. Ils sont totalement libres dans leurs choix et nous les incitons à apprendre de nouvelles techniques, à prendre de nouvelles responsabilités et à évoluer en termes de management.

Ainsi chacun est libre de proposer, d’argumenter ou de défendre des idées… mais tout le monde doit débattre. La seule limite est la bienveillance : c’est pour nous la définition d’un espace de travail ouvert, amical, responsable, favorisant l’éclosion d’idées nouvelles et productives.

A titre d’exemple, les Groupes de Travail (GT) sont des cellules qui organisent des projets de manière autonome. Les décisions sont prises de manière consensuelle, avec un périmètre de responsabilité défini en annexe.

Optimiser son site web

Posted on 30 septembre 201316 novembre 2021 by TheCodingMachine

Amazon indique que si le temps de chargement de la page augmente de 0,1 seconde, les ventes chutent de 1%. Vous qui n’avez pas optimisé votre site, IMAGINEZ CE QUE VOUS PERDEZ !

Pour une fois, arrêtez de vous demander si vous transformerez mieux en utilisant un bouton rouge pâle ou orange foncé, lancez-vous plutôt dans l’optimisation technique de votre site !

Voici une check-list simple ainsi que des explications pour optimiser votre site :

1. RÉDUIRE LE NOMBRE DE FICHIERS

Limiter le nombre de fichiers CSS et JS : il est possible de regrouper les fichiers CSS ou JS en un seul.
Regrouper les images – Sprite : il s’agit ici de regrouper les images qui sont fréquemment utiliseés dans le site en une seule. Cette technique s’appelle « Sprite ». En revanche, il faudra, via une feuille de style, afficher l’image en background et la positionner.

2. RÉDUIRE LA TAILLE DES FICHIERS

Réduire la taille des images : il est préférable de réduire la taille des images ou d’utiliser des mécanismes automatiques de mise à l’échelle. Des outils en ligne permettent de compresser un peu plus vos images sans détériorer la qualité (par exemple www.smushit.com).
Limiter le poids des fichiers – Compression Gzip : les fichiers Html, Css et Javascript sont des fichiers texte. Ils sont donc particulièrement adaptés à une compression ZIP importante. Le temps nécessaire à cette décompression est négligeable pour le visiteur.
Limiter le poids des fichiers – Minimify : une autre possibilité pour limiter le poids de vos fichiers CSS et JavaScript est de les minimiser. La minimisation supprime les retours à la ligne, les tabulations ainsi que les commentaires. La plupart des bibliothèques Javascript sont disponibles en version « minimisée ».

3. … ET NE RIEN ENVOYER DU TOUT !

Date d’expiration d’une ressource : il existe, pour le serveur Apache, le mod_expire. Il ajoute un en‐tête HTTP «Expires» qui indique la date d’expiration d’une ressource au navigateur. Tant que cette date n’est pas atteinte, le navigateur utilisera directement les données qu’il a en cache. Il n’y a donc plus aucun temps d’attente. La stratégie la plus efficace est donc de mettre une durée de vie illimitée et de renommer la ressource lorsqu’elle est modifiée.
Gestion Etag : Par défaut, la balise HTTP ETag (entity tag) est activée, elle permet de ne pas télécharger 2 fois les mêmes fichiers. Chaque ressource statique (image, Css, Js…) possède un identifiant unique pour une date de modification donnée. Ainsi, lors d’un second chargement de la page, le navigateur enverra l’ETag au serveur qui répondra soit par un code 302 Found (trouvé donc non modifié) soit par un 200 OK (envoi du fichier). Ce système n’évite pas les allers‐retours client‐serveur mais il évite de renvoyer le contenu des fichiers, donc réduit la consommation de bande passante ainsi que les traitements effectués par le serveur.

ATTENTION : Si vous avez une architecture avec plusieurs serveurs, vous devez utiliser cette option avec précaution. Dans ce cas, l’Etag est différent pour chaque serveur. Il est possible que cette balise augmente la bande passante plutôt que la réduise. C’est pourquoi certains outils de mesures vous conseillent de la désactiver.

Gérer un pic d’audience

Posted on 30 septembre 201321 mai 2021 by TheCodingMachine

Un jour, vous passerez sur Télématin, vous serez à la une de MyLittleParis, vous lèverez des fonds, vous ferez de la pub avant le 20h et vous aurez une actu terrible reprise par l’AFP.

Ce jour là, « si vous n’avez rien préparé », VOTRE SERVEUR TOMBERA (et les espoirs de succès qui vont avec).

Trois étapes à suivre pour parer à ce type d’éventualités (déagréables !) et rendre votre architecture de plus en plus performante.

Dans la plupart des cas, deux types de problèmes peuvent survenir : soit le serveur web est saturée, soit il y a un engorgement au niveau de la base de données…

La première chose à faire est de gérer le cache (donc configurer correctement Apache pour mettre en cache les ressources statiques et APC pour le serveur PHP).
Ensuite, séparer le serveur web du serveur de données (on peut maintenant dupliquer les serveurs web ou s’attaquer aux problèmes liés à la base de données).
Multiplier les serveurs web ou améliorer les accès aux bases de données

Si les serveurs web sont saturés … il faudra d’abord, mettre du cache sur la base de données afin que de ne plus exécuter les mêmes requêtes plusieurs fois …

Si cela n’est pas suffisant, on peut également envisager de séparer la base de données :

si lecture = écriture (archi. Maître/Esclave
si lecture > écriture (on ajoute des esclaves)
si lecture < écriture (là, il va falloir réfléchir au NOSQL par exemple)

Nous espérons que vous passerez sur TéléMatin, que vous serez à la Une de MyLittlleParis et que l’AFP vous créera une actu terrible. Et si vous suivez ces différentes points, votre serveur ne tombera pas… Et votre notoriété non plus…