"Es-tu prêt ?"
Je suis aussi prêt que possible, me dis-je en passant une dernière fois en revue ma liste de contrôle mentale.
Pilote: Lacets, cuissardes, sangle de poitrine, gants, radio, mentonnière, vérifiés.
Lignes: Toutes libres et non obstruées, la gauche sur la droite pour que je puisse tourner du côté que je préfère, vérifié.
Aile: Le bord d'attaque est ouvert et bien réparti en forme de fer à cheval.
Vent: Une légère brise se lève, un peu trop faible pour un décollage en marche arrière. Je décide d'attendre quelques minutes.
"Choisissez votre moment".
Je fais un signe de tête à l'instructeur en regardant la girouette. Au bout d'une minute, je sens le vent se lever un peu. La girouette a l'air bien. J'attends quelques secondes pour voir si cela dure. C'est le cas.
Vent: vérifier.
L'espace aérien: Aucun autre planeur ne vole à proximité du décollage et aucun autre planeur n'est prêt à décoller.
Je respire profondément... "START !", je tire les élévateurs A vers moi. L'aile se gonfle en s'élevant. Je lâche les élévateurs et tire sur les freins pour l'arrêter au-dessus de moi. La forme de l'aile me semble familière, c'est bien. Il n'y a pas de nœuds visibles, excellent. Une rafale de vent fait légèrement tourner l'aile. Elle n'est plus centrée au-dessus de moi. Dois-je interrompre le vol ? Je freine pour orienter l'aile vers l'avant et je fais deux pas pour me replacer sous l'aile. L'aile se stabilise. Je maintiens l'aile dans cette position pendant une ou deux secondes pour vérifier que je contrôle bien la situation. L'aile étant stabilisée, tous les signaux sont maintenant au vert. Tout en maintenant une pression constante sur les freins, je me tourne de 180 degrés. Après un court sprint, je sens les cuissardes se resserrer alors que l'aile m'arrache du sol.
Je vole.
Vous l'avez deviné, j'ai un hobby risqué. Cela signifie que je prends des risques, n'est-ce pas ? Eh bien, oui, en quelque sorte. Mais aussi, non ! En tant que parapentiste, je consacre beaucoup d'énergie à atténuer les risques. Grâce à une solide préparation et en gardant des marges saines, je ramène le risque à un niveau acceptable. C'est pourquoi il serait préférable de parler de gestionnaire des risques.
Consultez nos offres d'emploi
Pas de risque, pas d'affaires
Cela m'amène au sujet qui nous occupe, à savoir la gestion des risques dans le développement de logiciels. Plus précisément, comment gérer nos risques afin de pouvoir déployer des améliorations en toute confiance et sans stress ? Après tout, le déploiement d'un logiciel est un peu comme un décollage en parapente. Dans les deux cas, les risques sont susceptibles de se matérialiser en problèmes réels.
Malheureusement, la seule façon d'éliminer tous les risques est de les éviter complètement. Arrêter le parapente ou, de manière équivalente, arrêter le déploiement d'améliorations logicielles. Le premier est en fait un choix valable. Pour ce qui est du second, nous devrons nous accommoder de certains risques. Mais nous pouvons toujours réduire les risques, alors comment faisons-nous chez Easy LMS ?
Malheureusement, la seule façon d'éliminer tous les risques est de les éviter complètement
Qu'est-ce que le risque ?
Un risque est un événement ayant une probabilité de se produire et un impact particulier (négatif). La combinaison de la probabilité et de l'impact détermine le niveau de risque. Ainsi, un événement qui a une forte probabilité de se produire et un impact (négatif) important est un risque élevé. Un événement qui a peu de chances de se produire et dont l'impact est très limité est un risque faible. Si la probabilité et/ou l'impact augmentent, le risque augmente, et inversement.
Gestion des risques
Le risque étant une combinaison de probabilité et d'impact, il s'ensuit que pour réduire un risque, il est possible de le faire :
Par exemple, en tant que parapentiste, considérons le risque que je m'écrase parce que je décolle avec un méchant nœud dans mes suspentes. Parmi d'autres mesures, je réduis ce risque en.. :
La combinaison de toutes ces mesures me donne suffisamment de confiance pour courir joyeusement vers le bord de la montagne. J'ai confiance en ma préparation, mes compétences, mon équipement et mes décisions. Le risque est toujours présent, mais je l'ai réduit à un niveau que je suis prêt à accepter. En parapente, le décollage sera toujours un moment de tension pour moi. Je dois être vigilant. Mais je ne suis pas stressé.
De même, nous avons mis en place des mesures chez Easy LMS pour gérer les risques et garder notre calme. Considérons le risque d'introduire des bogues dans le système lors du lancement d'une nouvelle fonctionnalité. Les deux façons dont nous minimisons ce risque sont les suivantes :
Easy LMS a mis en place des mesures pour gérer les risques et garder son calme.
Comment ces mesures nous aident-elles chez Easy LMS ?
Développement piloté par les tests (TDD)
Le développement piloté par les tests, ou TDD, est une pratique qui consiste à écrire un test automatisé pour le comportement souhaité d'une nouvelle fonctionnalité avant d'écrire le code de la fonctionnalité elle-même. Le TDD permet de réduire le risque d'introduction de bogues de la manière suivante :
En testant le comportement dans des tests automatiques, les erreurs ont plus de chances d'être détectées pendant le développement.
Les erreurs sont détectées plus tôt dans le processus de développement en écrivant des tests avant d'écrire le code.
En écrivant des tests avant d'écrire le code, le développeur est obligé de réfléchir à la manière de tester le comportement souhaité indépendamment du code final.
Écrire un code testable, c'est un peu comme écrire un livre facile à lire. Il oblige le développeur à appliquer une structure au code. En conséquence, un code testable tend à être un code maintenable.
En suivant religieusement le TDD, nous construisons une suite de tests au fil du temps, comprenant tous les tests écrits dans le passé. Avant le déploiement, nous exécutons tous ces tests. Si notre nouvelle fonctionnalité pose un problème avec la fonctionnalité existante, nous le saurons.
De cette manière, le TDD permet de réduire considérablement la probabilité d'introduire des bogues dans le système.
Petites itérations
Chez Easy LMS, nous travaillons par petites itérations, en publiant souvent de petits changements. Nous effectuons souvent un ou deux déploiements par jour. Nous procédons par petites étapes, même lorsque nous introduisons une fonctionnalité importante. Cela nous aide de la manière suivante :
Nous recevons un retour d'information de la part des clients bien plus tôt que si nous devions attendre qu'une fonctionnalité soit complètement "terminée" avant de la déployer. Sur la base de ces premiers retours, nous pouvons facilement changer de direction si nécessaire.
Il est beaucoup plus facile de se remettre d'une erreur si la différence avec la dernière version stable est faible.
Les itérations courtes sont plus faciles à planifier et à gérer. Une équipe ne peut tout simplement pas prendre de retard sur le calendrier pendant une période de temps significative. Cela réduit le stress et empêche les équipes de ressentir le besoin de faire des économies.
Le déploiement quotidien crée une forte impulsion vers un processus de déploiement plus rationalisé et plus fiable. Si ce n'était pas le cas, nous ressentirions la douleur quotidiennement.
Ainsi, les itérations courtes permettent de réduire la probabilité et l'impact de l'introduction de bogues dans le système.
Le TDD et le travail par petites itérations nous donnent confiance. Nous sommes renforcés dans notre conviction que ce que nous sommes sur le point de déployer fonctionne. S'il y a des problèmes, ils seront mineurs.
Les itérations courtes sont plus faciles à planifier et à gérer
Les tests unitaires sont verts, vérifiez.
Je déplace le ticket vers "En cours d'examen AQ", ce qui déclenche automatiquement un déploiement vers notre environnement staging.
Quelques jours auparavant, nous avons déployé un petit changement dans les statuts affichés dans la vue d'ensemble des participants à plusieurs endroits de l'application. Cette modification était censée permettre aux statuts de refléter plus précisément l'état d'un participant.
C'était peut-être plus juste, mais c'était aussi plus confus. Les clients qui considéraient la nouvelle situation à travers les anciennes lentilles avaient l'impression que les invitations n'étaient pas envoyées.
Les tests d'acceptation deviennent verts, vérifiez.
Cela fonctionne comme prévu, vérifiez.
Je bois une gorgée de café et consulte mes messages pendant que le déploiement s'exécute. Je réfléchis à la manière dont le changement devrait aider nos clients. Nous prendrons contact avec le service d'assistance dans un jour. Nous nous attendons à ce que les clients ne contactent plus le service d'assistance au sujet de ce statut. Si nous recevons plus de commentaires, je suis certain que nous aurons un autre déploiement prêt cette semaine pour améliorer encore notre application et répondre aux besoins de nos clients.
Après quelques minutes, la dernière étape du déploiement devient verte.
Nous volons.
Consultez nos offres d'emploi
