Savoir-faire et technologie

<p>D’ordinaire, les clients d’entreprises de <a href="https://www.spiria.com/fr/services/">services logiciels</a> ne se rendent pas compte qu’ils ont besoin d’aide en matière de stratégie produit. Ils pensent que la relation se résume simplement à la fourniture d’un document de spécifications et que le fournisseur livrera un produit basé sur ce document. Mais cet état d’esprit est en train de changer parce qu’il y a des produits vraiment formidables qui ne décollent pas, ou décollent, mais n’arrivent pas à affronter les innovations et les changements du marché.</p><p>Les bonnes idées ne manquent pas, mais la plupart d’entre elles ont du mal à s’imposer sur le marché. La stratégie de produit aide à éclaircir et à comprendre ce problème. Elle vous aidera à déterminer si les caractéristiques du produit ratent la cible ou si vous mesurez bien l’expérience utilisateur. Elle doit également analyser si votre plan de commercialisation correspond à votre produit ou si une innovation récente peut perturber votre marché. Une saine gestion de produits doit faciliter l’évaluation de la situation du moment et l’élaboration de stratégies visant à accroître les revenus de l’entreprise.</p><p>Les stratégies pour obtenir au plus tôt dans le processus de développement des réactions du marché ciblé aident à améliorer la qualité du produit livré, et le délai de mise sur le marché est bien maîtrisé dans un espace de production au rythme rapide. Bien que des erreurs de produit se produisent, l’objectif d’une bonne gestion de produit est de valider au plus tôt les hypothèses et de développer des stratégies pour réévaluer en continu la façon dont un produit répond aux besoins du marché.</p><p>Aujourd’hui, les stratèges produits sont chargés de concevoir les stratégies de groupes de discussion adéquates – quand les réunir, que demander, de quelle manière, comment obtenir des retours opérationnels, quelles données recueillir, qu’en faire et comment les utiliser au mieux.</p><p>Dans de nombreux cas, les taux de satisfaction de la clientèle sont inférieurs aux standards de l’industrie. Mais pour le savoir, l’entreprise doit connaître ces standards. Les stratèges produits peuvent vous aider à mesurer la satisfaction de vos clients et à identifier et classer par ordre de priorité les fonctionnalités qui amélioreront votre produit. Ils vous mènent au stade où vous pouvez prendre des décisions éclairées en fonction des données disponibles.</p><p>Pour les entreprises qui servent une clientèle diversifiée, les stratèges produits peuvent aider de deux façons. Ils créent des profils types et des scénarios utilisateurs afin de mieux identifier les caractéristiques qui atténueront les conflits de l’utilisateur. Et ils travaillent sur les requis qui s’adressent à des utilisateurs très différents, tant en matière de contenus que de calendrier (les adeptes précoces comme ceux qui s’opposent au changement).</p><p>Les attentes des clients finaux en matière de rapidité de mise à niveau des fonctionnalités sont plus élevées que ce que de nombreuses entreprises peuvent fournir, et si celles-ci ne réagissent pas à temps, elles risquent de perdre des parts de marché. Les stratèges produits aident à naviguer dans les aspects commerciaux et techniques d’une problématique. Ils sont capables d’identifier les difficultés techniques rencontrées par l’entreprise et de recommander des solutions susceptibles d’augmenter le chiffre d’affaires et de réduire les coûts.</p><p>Les consultants en gestion de produits peuvent être d’excellents partenaires pour résoudre des problèmes. Vous n’avez qu’à trouver le bon et par la suite, faites-lui confiance. Comme le dit Warren Buffett, «<i> Le prix est ce que vous payez. La valeur est ce que vous recevez. »</i></p>

<h2>N’importe qui peut faire les tests !</h2><p><i>« Quand on sait mieux, on fait mieux. »</i></p><p>C’est du moins ce qu’on dit. Oui, n’importe qui peut faire des tests, que vous soyez designer, développeur, gestionnaire de projet ou même PDG. Mais la question est de savoir si vous pouvez faire de l’assurance qualité comme le font les testeurs professionnels. Pouvez-vous affirmer en toute confiance que le produit ne se désintégrera pas lors de sa sortie ? Pouvez-vous mesurer et quantifier votre travail en tant que testeur ? Pouvez-vous garantir qu’un système global est en place pour gérer des scénarios complexes avec plusieurs modules ? Peu importe qui vous êtes ou quel rôle vous jouez, quand vous portez le chapeau du testeur, vous portez aussi celui de la responsabilité.</p><p>Les entreprises de premier plan de l’industrie des TI ont des <a href="https://www.spiria.com/fr/services/developpement-axe-performance/assurance-qualite-test-automatises/">services d’AQ spécialisés</a> pour s’assurer que leurs produits arrivent sur le marché du bon pied, avec le moins de problèmes de production possible, et que les clients reçoivent le meilleur service qui soit.</p><h2>C’est le jeu des blâmes !</h2><p><i>« Ce n’est pas une erreur de faire une erreur, mais c’est une erreur de répéter une erreur. »</i></p><p>Le travail de test est souvent mal compris. Lorsqu’un problème est détecté, qu’il s’agisse du design, du back-end, du front-end ou de la plateforme qui ne correspond pas aux requis, cela peut parfois être mal pris. Le travail d’un testeur est de trouver les défauts d’un système afin qu’ils puissent être corrigés avant la mise sur le marché. L’erreur est humaine et personne n’est à l’abri des erreurs ; nous commettons des erreurs dans notre compréhension, notre façon de travailler, notre perception de l’information, et notre façon de développer les choses. L’élaboration d’un <a href="https://www.spiria.com/fr/services/developpement-axe-performance/developpement-logiciel-sur-mesure/">produit logiciel</a> est un processus évolutif qui se bonifie avec le temps. Lorsque des problèmes sont découverts, ils ne doivent pas être considérés comme un échec personnel ; le seul but ici est de construire le bon produit et de le faire en équipe.</p><p>À l’occasion, les testeurs font aussi des erreurs, comme manquer des requis, ne pas bien les comprendre ou simplement négliger quelques petits détails pendant quand on se concentre sur des choses plus importantes. Blâmer ne sert à rien. Lorsque chacun connaît l’importance de son travail, qu’il reconnaît ses erreurs en tant que joueur d’équipe et qu’il s’efforce de s’améliorer, ce n’est qu’alors que l’on peut atteindre en tant qu’équipe un objectif commun.</p><h2>Tester, c’est ennuyeux !</h2><p><i>« Aucun travail n’est ennuyeux si vous savez vraiment ce que vous faites. »</i></p><p>Dans le monde du développement Agile, où le rythme ne ralentit jamais, il n’y a pas de temps pour s’ennuyer. Les tests itératifs ne donnent que peu le temps de respirer à travers les sprints. Travailler pour une entreprise de services, où les exigences des clients ne cessent d’évoluer, où l’on passe d’un projet à un autre en un mois (ou quelques jours), ne permet pas d’évoluer à moins de consacrer du temps à apprendre de nouveaux outils et à essayer d’utiliser stratégiquement les outils afin de réduire les coûts des tests. Il n’y a pas de fin à l’apprentissage et l’industrie d’aujourd’hui, avec ses exigences, exige des efforts supplémentaires pour rendre le travail moins compliqué.</p><h2>Tester dévore le budget !</h2><p><i>« Vous devez avoir un plan de match. Si vous ne visez aucune cible, vous n’en atteindrez aucune. »</i></p><p>Les tests devraient être un argument de vente pour les entreprises qui veulent croître et aller de l’avant. Livrer de la quantité n’est d’aucune utilité quand la qualité n’est pas au rendez-vous. De nos jours, on voit de tout sur le marché ; : main-d’œuvre bon marché, produits non standardisés qui ne résistent pas à l’épreuve du temps, promotion non éthique. Pour mettre votre produit sur le marché et le faire évoluer jusqu’à ce qu’il tienne toujours ses promesses, vous devez avoir le courage de le vendre sur la base qu’il est le meilleur et qu’il marche. Les tests ne rongent pas le budget, ils stabilisent le produit et augmentent sa durée de vie sur le marché.</p><h2>Tester est un travail ingrat !</h2><p>Il est rare d’entendre quelqu’un dire que son travail est ingrat, mais il arrive parfois que l’on croise des gens qui pensent de cette façon. La démolition systématique d’un produit en cours d’élaboration afin de le rendre plus résistant, jusqu’à ce qu’il devienne indestructible, demande beaucoup plus de détermination que la construction. Les testeurs doivent résister à une forte pression et des forces importantes, et ils ont moins de temps que ceux qui construisent. Pour atteindre des normes de qualité, il faut plus de force que vous ne le pensez. Mais en fin de compte, rien n’est plus gratifiant que de voir votre produit fonctionner de manière transparente tout en étant utilisé par des centaines, voire des milliers de personnes, leur facilitant la vie, une étape après l’autre.</p><p><i>« Beaucoup de gens vous disent que c’est un travail ingrat. Je n’ai jamais ressenti ça. C’est un honneur pour moi de rendre service. »</i></p>

<p>En 2015, j’ai commencé comme développeur junior au sein d’une équipe de 10 personnes chez Spiria Toronto, anciennement DevBBQ. Ce fut un parcours fou, en montagnes russes, avec plein de gens étonnants et d’expériences mémorables qui furent l’occasion d’une grande croissance personnelle. Mais le plus important, c’est comment j’ai appris à devenir un meilleur développeur, à m’améliorer progressivement et à apporter une plus-value à l’entreprise avec mes compétences spécifiques. Cela dit, comme le dit le <a href="https://en.wikipedia.org/wiki/Ooh_La_La_(Faces_song)">grand classique</a> de Rod Stewart, « quand j’étais plus jeune, j’aurais aimé savoir ce que je sais maintenant ». Voici quelques leçons que j’ai apprises au cours des quatre dernières années.</p><h2>N’ayez pas peur de demander de l’aide</h2><p>Au début, j’hésitais à demander de l’aide à mes collègues. Je voulais avoir l’air compétent et faire croire que j’avais une bonne solution pour chaque problème particulier. Mais grâce à Kevin Zych, un de mes mentors, j’ai appris très tôt que cette notion était fondamentalement fausse. Au lieu de cela, la bonne approche consiste à demander conseil à un développeur senior, car elle tire parti de ses connaissances pour accélérer votre propre processus d’apprentissage. L’apport d’un développeur qui a déjà tout vu aide à résoudre les problèmes avec plus d’efficacité. Un autre énorme avantage de demander de l’aide est la possibilité d’examiner le problème d’un point de vue différent. C’est presque comme si une nouvelle connexion neuronale se formait dans votre cerveau, vous orientant vers une solution à laquelle vous n’auriez probablement jamais pensé par vous-même. J’ai eu la chance d’apprendre grâce à de grands mentors et de développer mes compétences plus rapidement que je ne l’aurais fait seul. Plus récemment, j’ai été de l’autre côté de la barrière, aidant d’autres développeurs à résoudre plus efficacement leurs problèmes. Cela m’a aidé à devenir un encore meilleur développeur, capable d’expliquer plus clairement les solutions.</p><h2>Pensez à l’avance à une solution</h2><p>Bien qu’il soit extrêmement bénéfique de demander de l’aide, ce n’est pas idéal si vous n’avez pas pensé au préalable à une solution potentielle. Faire ce travail de fond, c’est faire preuve de considération et de respect à l’égard du temps d’un autre développeur, en montrant que vous avez tenté de résoudre le problème par vous-même plutôt que de demander à être nourri à la cuillère pour trouver une solution. En fait, cela rend les autres développeurs plus disposés à vous aider. Avant de commencer quelque codage que ce soit, je développe une solution bien pensée à l’avance, en m’assurant qu’elle prend en compte les cas limites et les problèmes futurs. Ensuite, il s’agit simplement de valider ma solution et de mettre les doigts sur le clavier.</p><h2>Communication et collaboration</h2><p>Je venais d’un emploi où une seule personne prenait toutes les décisions, ce qui ne laissait pas beaucoup de place à la collaboration entre les membres de l’équipe. Le développement devrait être au contraire un travail d’équipe. La capacité de communiquer vos idées à un groupe de personnes ou même à un seul collègue est une compétence très importante à acquérir. Chacun, quel qu’il soit, a des informations précieuses à partager et doit être encouragé à s’exprimer, qu’il s’agisse d’explications d’estimations, de solutions, de demandes ou même des opinions. De plus, s’approprier vos solutions et se concentrer sur vos efforts au sein d’une équipe vous pousse vraiment à travailler à un haut niveau, surtout lorsque vous savez que vos collègues verront votre solution à un moment ou à un autre. Apprendre à communiquer, avec l’encouragement de mes pairs, m’a aidé à fournir de meilleures estimations et à arriver à de meilleures solutions en expliquant mes problèmes et mes réponses de façon concise.</p><p>Ce sont quelques-unes des leçons que j’ai apprises en tant que développeur junior, et je continue à les mettre à profit quotidiennement ! Elles ne sont peut-être pas applicables en permanence, mais j’aurais aimé les connaître quand j’ai fait mes débuts !</p><p>—</p><p>Besoin d’autres conseils ? Découvrez cet article écrit par Olivier Mageau-Pétrin de Spiria Gatineau : « <a href="https://www.spiria.com/fr/blogue/methodes-et-bonnes-pratiques/pour-en-finir-avec-le-junior/">Comment ne plus être un développeur “junior” ».</a></p>

<p>De nos jours, il devient de plus en plus difficile pour les entreprises de gérer leurs opérations sans applications, et la plupart de celles-ci sont exécutées sur des serveurs. Auparavant, chaque application avait besoin d’un serveur dédié pour fonctionner en toute sécurité et sans interruption. Pour s’assurer de ce bon fonctionnement, le service informatique devait se doter d’un serveur suffisamment puissant. Mais avant de mettre l’application en production, personne ne pouvait être vraiment sûr de ses besoins réels en puissance. Pour cette raison, le service informatique finissait la plupart du temps par acheter un serveur surpuissant qui ne serait utilisé qu’à 10 % ou moins de ses possibilités. C’était un grand gaspillage d’argent, d’espace et de temps.</p><p>Puis sont arrivées les machines virtuelles. Elles permettent d’exécuter en toute sécurité de nombreuses applications dans des environnements différents et sur un même serveur physique. Une nouvelle application n’est plus synonyme de nouvel achat matériel. Les serveurs qui n’utilisent qu’une petite partie de leur puissance peuvent finalement être utilisés au maximum de leur capacité ou presque. C’était un grand pas en avant pour l’univers informatique.</p><p>Mais rien n’est parfait et il y a toujours matière à parfaire. Les machines virtuelles consomment une bonne partie des ressources du serveur juste pour fonctionner. Elles doivent simuler un serveur physique avec tous ses composants : processeur central (CPU), mémoire vive, disque de stockage, carte réseau, etc. De plus, chaque machine virtuelle a besoin de son propre système d’exploitation, ce qui peut être une source de perte de performances, mais aussi de vulnérabilités logicielles.</p><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/6847069d513c65a40c35cfbe_vm-container.png" style="width: 100%;" alt="VMs vs Containers." title="VMs vs Containers."></p><p>Machine virtuelle (VM) et conteneur. Chaque conteneur fait appel au système d’exploitation du serveur hôte alors que chaque machine virtuelle héberge son propre système d’exploitation.</p><p>Par conséquent, il y a quelques années, la sphère Linux a commencé à travailler sur une nouvelle technologie qui est moins onéreuse et plus rapide : les conteneurs. Ils permettent d’isoler une application du monde extérieur sans avoir besoin d’un système d’exploitation dédié et d’un logiciel lourd pour simuler les composants physiques du serveur. Cela les rend plus rapides à exécuter et facilite la maintenance. Et ce n’est pas le seul avantage des conteneurs. Ils sont si rapides et petits que nous pouvons les utiliser pour diviser une application monolithique en plusieurs petits services qui communiquent entre eux. Chaque petit service peut ainsi fonctionner dans son propre conteneur, séparément des autres, afin qu’il puisse être entretenu ou réparé sans craindre de briser les autres parties.</p><p>Enfin, les conteneurs ont amélioré la plupart des services offerts par les machines virtuelles et sont plus adaptés à l’architecture logicielle moderne des microservices. Mais ils ne les remplacent cependant pas : bien souvent, nous les trouverons cohabitants côte à côte.</p><h2>Systèmes de conteneurisation</h2><ul> <li><a href="https://linuxcontainers.org/" target="_blank">Linux Containers</a> <ul> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxc/introduction/" target="_blank">LXC</a></li> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxd/introduction/" target="_blank">LXD</a></li> <li style="list-style-type: square;"><a href="https://linuxcontainers.org/lxcfs/introduction/" target="_blank">LXCFS</a></li> </ul> </li> <li><a href="https://www.docker.com/" target="_blank">Docker</a></li> <li><a href="https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/" target="_blank">Windows Server Containers</a></li></ul>

<p>Soyons clairs : dans ce contexte-ci, j’entends par « entreprise de services technologiques » une entreprise comme <a href="https://www.spiria.com/fr/">Spiria</a> – une entreprise qui offre des stratégies numériques, la conception et le développement d’applications modernes.</p><h2>Exposition à tous les secteurs d’activité</h2><p>En général, dans les entreprises de services, les développeurs sont rarement confinés à un seul secteur d’activité. Soins de santé, vente au détail, technologie financière, technologie marketing, et j’en passe : on touche à tout, et chaque secteur vient avec son propre lot d’expertises, de contraintes et de défis. Oui, il se peut que vous travailliez sur un seul projet ou pour un seul client pendant des mois, voire des années, mais normalement, les développeurs connaissent des changements dans leurs affectations. Ceux-ci ne sont pas si fréquents que le réajustement entre contextes différents devienne pénible, mais assez pour vous exposer à toute une palette de secteurs industriels, d’expertises sectorielles et de problématiques variées. Par ailleurs, en plus de votre propre projet, l’entreprise assume bien d’autres mandats en parallèle, ce qui vous donne autant d’occasions de tirer parti de l’expérience de vos collègues. Cette exposition vous permet de vous tenir au courant des besoins des entreprises et des différents secteurs, faisant de vous un meilleur développeur, capable de penser au-delà du code et de résoudre les problèmes plus efficacement.</p><h2>Défier l’obsolescence</h2><p>Comme développeur, l’exposition à la technologie est importante. Les grands développeurs (actuels ou en herbe) le recherchent par le biais de projets personnels (projet Open Source, produit/service en auto-entrepreneuriat…). La plupart des développeurs craignent toujours de se faire dépasser au fil de leur carrière. En effet, la technologie évolue par nature rapidement, et s’efforcer de la suivre, mois après mois, année après année, peut devenir essoufflant. Être dans une entreprise de services vous place dans un environnement où, chaque jour, des personnes aux vues similaires et aux compétences variées tentent de résoudre les problèmes de manière nouvelle, en utilisant des technologies différentes, avec des perspectives différentes et pour des secteurs d’activités différents. L’on n’est jamais à court d’aide, d’inspiration et de motivation pour garder les choses intéressantes.</p><h2>Gratification au-delà de la production de code</h2><p>Mon premier emploi, après cinq ans d’études en ingénierie logicielle, était dans un rôle de développement au sein d’une entreprise de services où j’ai rapidement acquis beaucoup d’expérience en relations interpersonnelles. Oui, il est important de pouvoir se concentrer sur son code, et penser en lignes d’instructions ; mais rencontrer les clients, les écouter parler de leurs besoins est ressourçant et stimulant. Voir leurs réactions à vos démonstrations, obtenir un retour direct sur votre performance comme développeur en observant leur réaction émotionnelle face à votre travail est une expérience gratifiante et riche en enseignements, qu’elle soit positive ou négative. Après tout, l’on développe pour des gens, et cette satisfaction personnelle peut dépasser celle de résoudre un problème d’ingénierie ou de fermer des tickets.</p><h2>Penser autrement</h2><p>Comme les entreprises de services travaillent toujours avec la contrainte d’un budget et contre la montre, les développeurs sont mis au défi de résoudre les problèmes d’une façon qui n’est peut-être pas immédiatement évidente. Par exemple, la solution qui coule de source ne cadre parfois pas avec le budget, et les développeurs doivent en trouver une autre qui respecte les besoins du projet et les exigences budgétaires. Les développeurs doivent chercher au-delà des bibliothèques et plug-ins disponibles, des morceaux de code de Stack Overflow. Aussi, trop souvent, les développeurs n’ont aucune idée de l’aspect commercial d’un projet, et les gestionnaires de projet se contentent d’annoncer des échéances sans expliquer ou justifier l’intensification du travail ou les dates de livraison serrées. Dans une entreprise de services, par contre, tout le monde est généralement conscient de l’état du budget et des indicateurs de performance de l’entreprise cliente. L’on ne peut qu’être motivé par cette transparence, et par le fait qu’on voit par soi-même la différence amenée par notre efficacité à résoudre les problèmes.</p><h2>Occasions de réseautage</h2><p>Si vous êtes du type entrepreneurial, vous allez aimer le fait qu’une entreprise de services vous permet de côtoyer de nombreux clients aux idées et aux besoins variés. Ce sont autant d’occasions, si vous le souhaitez, d’intégrer à votre réseau des personnes ayant noué un partenariat avec votre entreprise.</p><h2>À vous de voir</h2><p>Être développeur dans une entreprise de services, c’est travailler dans un environnement qui regorge d’occasions. Mais c’est aussi à vous de les saisir – elles ne seront pas distribuées d’office. Comme toujours, on en retire ce qu’on y cherche, en l’occurrence, tout ce que vous croyez être utile pour votre carrière. Le secteur des services est dynamique et exigeant ; ceux qui s’y investissent en retirent les dividendes de la satisfaction professionnelle et de la croissance personnelle.</p>

<p>Avec cet article, je souhaite illustrer à quel point la relation entre le Product Owner (PO) et l’équipe de développement est primordiale, et plus encore lorsque le PO est externe, du côté client. Les différences avec un PO interne sont nombreuses, mais parfois subtiles. Notez que je ne ferai aucune distinction entre les utilisateurs finaux internes et externes (développement d’outils internes par rapport à celui de produits logiciels) ; je pense que cela risquerait d’embrouiller les choses.</p><p>Pour tout dire, avant de cofonder Spiria en 2003, j’ai travaillé près d’une décennie sur des produits logiciels avec des PO internes, sauf qu’à l’époque, on les appelait simplement « chef de produit » ou « boss ». J’ai donc connu les deux côtés et peux offrir différentes perspectives.</p><h2>Jouer dans la même équipe</h2><p>Avec un PO interne, une appréciable différence est le sentiment généralement partagé que tout le monde joue dans la même équipe : c’est <i>nous</i>, l’équipe produit unie, contre <i>eux</i>, les hordes barbares qui frappent à la porte. Plus l’entreprise est petite, plus ce sentiment est important, particulièrement dans le cas de produits logiciels. Avec un PO externe, il y a souvent le danger que le <i>« nous contre eux »</i> se transforme en <i>nous</i> (le PO, le client) contre <i>eux</i> (l’équipe de développement, le prestataire de services).</p><p>De mon expérience de travail avec des clients externes, les projets les plus réussis ont toujours été réalisés avec une étroite collaboration entre le PO et l’équipe de développement, sans égard de la séparation client/fournisseur. En tant qu’équipe produit, <i>nous</i> avons fait des efforts concertés pour améliorer le produit final, y compris en reportant des fonctionnalités pour se concentrer sur la réduction de la dette technique, ou en faisant des coupes dans les coûts lorsque nécessaire.</p><p>De l’autre bord, lorsque le PO et l’équipe de développement ne travaillent pas complètement dans la même équipe, cela devient une partie de bras de fer permanente entre les deux. Avec le temps, l’équipe de développement s’impliquera moins dans le succès du projet et commencera à simplement obéir aux ordres du PO. Sur les projets à long terme, la qualité en souffrira, et des membres de l’équipe peuvent demander leur déplacement, ce qui est du gâchis pour le projet.</p><h2>Des avis qui comptent</h2><p>L’une des idées les plus fausses que j’ai entendues au sujet du travail avec un PO interne, c’est qu’on peut travailler comme on veut. Vous voulez passer de PHP à Node ? Pourquoi pas ! Ajouter un nouveau widget ? Bien sûr ! Vous avez vraiment besoin de rapports d’administrateurs avant de permettre à des usagers de se connecter ? Vous les avez.</p><p>Si les PO ne font que dire oui à tout, c’est qu’ils ne font pas un bon travail. Ils doivent orienter le projet dans la bonne direction, prioriser vraiment les idées et maintenir un contrôle serré du budget. Certains peuvent trouver qu’il est plus facile d’influencer un PO interne parce qu’ils sont du même camp, mais dans les entreprises bien gérées, les PO internes ont aussi des budgets et des délais à respecter.</p><p>D’un autre côté, les PO qui disent non à toutes les suggestions ne font sans doute pas non plus un très bon travail. Certes, vous avez parfois besoin de garder un contrôle très serré des fonctionnalités d’un MVP (<a href="https://www.spiria.com/fr/blogue/developpement-sur-mesure/le-pmv-la-strategie-gagnante-pour-etre-rapidement-sur-le-marche/">produit minimum viable</a>) en raison d’un salon professionnel à venir. Mais ce n’est pas toujours le cas. Et l’écoute des idées de tous les membres participe à la formation d’une équipe produit unie et fonctionnelle.</p><h2>Gestion de la dette technique</h2><p>J’admets qu’une version plus jeune de moi-même serait bien surprise à lire ce qui suit. Je considérais alors que toute dette technique était systématiquement mauvaise, que tout devait être conçu pour être à l’épreuve du futur, que tout devait être optimisé à la perfection et que tout devait être développé minutieusement comme il le faut.</p><p>Dans un monde idéal, peut-être. Nous avons sûrement passé beaucoup de temps à réusiner le code <i>(refactoring)</i> de fonctionnalités pratiquement pas utilisées ! Avec le temps, je me suis rendu compte qu’il n’y a parfois rien de mal à couper les coins ronds pour tester une fonctionnalité. Ce n’est pas aussi joli que ça pourrait l’être, mais c’est sans risque, ça ne vous donnera pas le cancer… Ensuite, laissez aller. Ajoutez une « story » de réusinage de code dans le « backlog » et passez à autre chose.</p><p>Il s’agit une fois de plus d’un exercice d’équilibre. De mon expérience, les PO externes ont tendance à être beaucoup moins indulgents à l’égard de la dette technique que les PO internes. « Déjà, pourquoi avez-vous laissé s’accumuler cette dette ? » Je ne saurais trop insister sur l’étroitesse de cette vision et comment cela peut mener à l’augmentation du temps de développement pour chacune des fonctionnalités demandées. Si vous n’avez qu’une seule chance pour coder quelque chose, vous voulez alors que ce soit d’emblée impeccable. Mais cela peut être du gaspillage si tout ce dont vous aviez besoin était de juste tester une fonctionnalité.</p><h2>Flexibilité du budget et des délais</h2><p>Avec un PO externe, il y a le sentiment que le budget est limité, alors qu’avec un PO et des développeurs relevant du même employeur, cela peut d’une façon ou d’une autre rendre le budget plus élastique. De même, avec un PO externe, des délais arbitraires deviennent par magie des dates gravées dans le marbre.</p><p>Il est cependant malheureux que cela se produise. Une possible cause est que les PO externes reçoivent généralement une copie de la facture de l’équipe de développement, et qu’ils sont ainsi incités à faire le suivi de projet en fonction de montants en dollars, alors que les PO internes se baseront avant tout sur le temps. Et parce que les délais arbitraires peuvent être modifiés, les budgets internes paraissent alors plus flexibles que les externes.</p><p>Cela dit, ça a pu être vrai avant, mais il y a de nos jours une pression accrue sur les PO internes pour qu’ils gèrent leurs projets avec la plus grande rigueur.</p><h2>Pour conclure</h2><p>Quel que soit le projet, un facteur clé pour s’assurer du succès est de faire travailler ensemble les membres de l’équipe produit (PO et équipe de développement). Chacun doit être conscient des délais, des contraintes et des objectifs du projet.</p><p>Lorsqu’il y a une bonne collaboration au sein d’une équipe produit, la dette technique demeure à un niveau raisonnable, les fonctionnalités sont classées par ordre de priorité, les délais sont respectés et le budget est maîtrisé. Et ceci reste vrai que le PO soit interne ou externe.</p>

<p>Tout cela simplifie grandement la vie des ingénieurs de tests automatisés de nos jours. Mais cela signifie-t-il que nous pouvons automatiser tout ce que nous voulons ?</p><p>Oui et non : très souvent, l’automatisation est plus facile à dire qu’à faire. Les scénarios de tests qui étaient impossibles à automatiser il y a quelques années sont maintenant automatisables, mais ils peuvent requérir de considérables efforts, une certaine expertise et parfois même l’implication de l’équipe de développement. Ces facteurs peuvent rendre impraticable l’automatisation de tous les tests, d’où l’importance de déterminer dans quels cas les tests devraient être automatisés et si ça en vaut la peine. En effet, pour certains types de projets comme ceux à court terme, les tests automatisés n’ont tout simplement pas de sens. Cependant, ils sont le moteur de la livraison continue et des pratiques agiles.</p><p>Ce qui nous amène à la question suivante : quelle valeur ajoutée apporte tel ou tel scénario de test automatisé ? Est-ce que cela fera vraiment gagner du temps à tout le monde ? Cela nous donnera-t-il l’assurance que le code livré fonctionne et qu’il ne casse rien ? Je pense que c’est sans doute la considération la plus cruciale dans la définition et la sélection de ce que nous voulons automatiser dans notre processus.</p><p>Idéalement, cette décision devrait être prise par toute l’équipe, y compris les analystes d’affaires et les responsables du budget. Nous savons tous que la création de tests automatisés, comme la maintenance d’un système, n’est pas bon marché, de même que la maintenance ; mais si c’est important d’un point de vue d’affaires, alors vous obtiendrez le support nécessaire pour l’implémenter. Il est essentiel d’être agile dans ce processus : lorsque vous constatez que quelque chose tourne mal, arrêter dès les premières étapes pour réévaluer un projet vous permettra d’économiser beaucoup de temps, d’efforts et d’argent en fin de compte.</p><p>Exécuter des tests entièrement automatisés et simplement vérifier des rapports après est un rêve pour tout ingénieur AQ. Mais il est n’est pas possible pour l’instant d’automatiser tous les tests. Même dans les processus « entièrement » automatisés, où vous avez une multitude de tests, les développeurs consciencieux vérifient eux-mêmes les fonctionnalités et le code qu’ils veulent déployer. C’est ce qu’on appelle des tests manuels. Peut-être un jour aurons-nous une intelligence artificielle qui sera capable de trouver et/ou même de corriger tous les problèmes et bogues de l’application testée. Mais pour le moment, c’est encore une tâche intéressante et stimulante pour nous, les êtres humains.</p>

<h2>Le but</h2><p>J’ai récemment voulu mettre un combo-box à l’intérieur des éléments d’une table à multiples colonnes. Bien que la façon standard de procéder soit simple, les résultats ne sont pas satisfaisants. Je voulais améliorer la solution normale pour rendre l’expérience plus agréable pour l’utilisateur. J’ai commencé par chercher des solutions toutes faites sur Internet. Bien que j’ai trouvé quelques idées dans le <a href="https://wiki.qt.io/Combo_Boxes_in_Item_Views">wiki de Qt</a> et sur <a href="https://stackoverflow.com/questions/18831242/qt-start-editing-of-cell-after-one-click">Stack Overflow</a>, il n’y avait pas de solution complète qui fonctionne à ma satisfaction.</p><p>C’est pourquoi je veux partager la solution que j’ai finalement trouvée récemment. Voilà ce que je voulais faire et pourquoi.</p><p>1. <strong>Je voulais mettre un combo-box directement dans un tableau multicolonnes.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: afin de pouvoir changer rapidement une valeur pour un élément de la liste. Ce n’est en fait pas difficile et il y a des exemples directement dans la documentation de Qt.</p><p>2. <strong>Je voulais que le combo-box soit toujours visible.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: pour que l’utilisateur sache que l’élément peut être édité directement. Par défaut, Qt garde le combo-box caché. L’utilisateur doit double-cliquer sur l’élément pour afficher la liste déroulante. Ce n’est pas facile à découvrir par l’utilisateur normal. Le résultat est que l’utilisateur ne sait même pas qu’un élément est modifiable !</p><p>3. <strong>Je voulais que le combo-box affiche le contenu de la liste déroulante dès le premier clic.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: normalement, dans Qt, le premier clic est utilisé pour sélectionner l’élément dans la liste. D’autre part, pour un combo-box normal, le premier clic affiche son contenu. Cette différence de comportement fait que le combo-box intégré dans la table fonctionne différemment d’un combo-box en dehors d’une table. Cela semble anormal pour l’utilisateur.</p><p>4. <strong>Je voulais que le clic sur le combo-box sélectionne la ligne du tableau.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: normalement, le clic sur le combo-box serait absorbé par le combo-box et la ligne ne serait pas sélectionnée, ce qui semblerait étrange pour l’utilisateur.</p><p>5. <strong>Je voulais que le combo-box termine l’édition de l’élément dès que l’utilisateur sélectionne un élément.</strong></p><p style="margin-left: 1em;"><strong>Pourquoi </strong>: normalement, Qt laisse l’élément de la liste en mode édition jusqu’à ce que l’utilisateur s’en éloigne avec le clavier ou en cliquant ailleurs. Encore une fois, ceci est incohérent comparé à la façon dont les combo-box fonctionnent en dehors d’un tableau.</p><h2>La solution</h2><p>Voici comment chaque objectif est atteint.</p><p>1. <strong>Placez le combo-box directement dans le widget de la table multicolonne.</strong></p><p style="margin-left: 1em;"><strong>Comment</strong> : en utilisant un <code>QStyledItemDelegate</code> qui crée un combo-box comme éditeur. C’est du code Qt standard et il est expliqué dans le <a href="https://wiki.qt.io/Combo_Boxes_in_Item_Views">wiki Qt</a>.</p><p>2. <strong>Rendre le combo-box toujours visible.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: C’est aussi du code Qt standard : remplacer les fonctions <code>paint</code> et <code>sizeHint</code> du délégué. Le problème est que le code nécessaire n’est pas évident dans la documentation. En particulier, il n’est pas évident d’obtenir le style standard. Voir le code sur GitHub pour les détails.</p><p>3. <strong>Afficher le contenu de la liste déroulante au premier clic.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: Cela nécessite trois astuces. La première est d’augmenter la fonction <code>mousePressEvent</code> de la table. Ceci permet d’entrer en mode édition avec le premier clic de souris. Dans la fonction <code>mousePressEvent</code>, nous lançons une minuterie qui appelle la fonction d’édition du widget de table avec l’index de l’élément sélectionné. (L’utilisation d’une minuterie est nécessaire pour que l’astuce de sélection de la ligne fonctionne plus tard.) Le second est de présélectionner l’élément courant dans le combo-box avec un appel à <code>setCurrentIndex</code> dans la fonction <code>setEditorData</code> du délégué. Le troisième est d’appeler la fonction <code>showPopup</code> du combo-box pour qu’il affiche son contenu immédiatement, dans la fonction <code>setEditorData</code>.</p><p>4. <strong>Sélectionnez la ligne du tableau en cliquant sur la liste déroulante.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: nous devons à la fois sélectionner la ligne et lancer l’éditeur. C’est pourquoi nous retardons l’affichage de l’éditeur, sinon la sélection des lignes interférerait. Ainsi, dans la fonction <code>mousePressEvent</code>, nous appelons <code>setCurrentIndex</code> sur le modèle de sélection de table.</p><p>5. <strong>Terminez l’édition de l’élément dès que l’utilisateur sélectionne un élément.</strong></p><p style="margin-left: 1em;"><strong>Comment </strong>: Dans la fonction <code>createEditor</code> du délégué, quand nous créons le combo-box, nous nous connectons immédiatement à son signal <code>currentTextChanged</code>. La fonction connectée permet de valider les données et de terminer l’éditeur. Cela se fait en appelant la fonction <code>commitData</code> et la fonction <code>closeEditor</code> du délégué.</p><h2>Le code</h2><p>Le code C++ nécessaire pour avoir un combo-box toujours présent dans un widget de table est disponible dans ce <a href="https://github.com/pierrebai/QtComboBoxTableWidget">dépôt public sur GitHub</a>.</p><p>(L’exemple est fourni en tant que solution Visual Studio 2017.)</p>

<h2>Une période de démarrage trop furtive et sommaire</h2><p>Lorsqu’un nouveau projet démarre, tout paraît possible ! C’est la lune de miel, la nouveauté est enivrante, les possibilités sont infinies, l’excitation bat son comble. Quant à eux, les risques ne sont pas toujours perceptibles au premier regard et leur analyse exige temps et effort. C’est pourtant à ce moment critique qu’il faut leur accorder la plus grande importance puisque la gestion du risque est aussi la capacité à anticiper et à s’adapter à un écueil potentiel. Cela ne veut cependant pas dire qu’il faut craindre les rebondissements et obligatoirement tout prévoir, il faut un juste milieu.</p><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/684707d4439a2a19ef28c309_istock-97926924.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></p><p>Des rebondissements : oui, mais pas à n’importe quel prix ! © iStock.</p><p>Souvent appelée « Sprint 0 », « analyse », « conception », « découverte », peu importe le nom qu’on lui donne, cette étape est cruciale pour le projet. Elle permet de mettre la table, d’établir de bonnes bases, de prendre le temps de réfléchir et de préparer le projet à venir. Parmi les activités couramment incluses, nous trouvons l’élaboration des besoins du client, le raffinement du « backlog » de tâches à exécuter, la définition des critères de succès des « stories », la réalisation de maquettes fonctionnelles ou « wireframes », l’écriture du plan de test, la création d’environnements, la réalisation d’une démonstration de faisabilité ou encore d’études sur l’expérience utilisateur, etc.</p><p>De ce fait, comme dans toute nouvelle initiative, il y a souvent cet empressement naturel qui nous porte à vouloir rapidement entrer dans le vif du sujet. De plus, cette hâte peut être accentuée par des contraintes telles qu’un échéancier serré ou un budget limité. C’est ainsi que les premières étapes pourtant cruciales d’un projet se retrouvent très souvent escamotées et dépriorisées. Un manque de vision s’en suit alors et les risques de réécriture deviennent alors proéminents.</p><p>C’est un peu comme construire une maison en n’ayant fait ni plan ni inventaire des matériaux nécessaires. Il se pourrait que vous deviez par la suite déplacer un mur ou encore retourner souvent à la quincaillerie ou chez d’autres fournisseurs pour vous procurer le matériel nécessaire.</p><h3>Solution</h3><p style="background-color: #dadac5; padding: 9px 12px;">Il nous a été démontré maintes et maintes fois au cours de notre pratique, qu’avant même le début de l’exécution du projet, un effort de 15 à 20 % du montant total du projet devrait être accordé aux étapes préparatoires. Cela peut paraître un gros investissement pour peu en retour, mais détrompez-vous ! Cette étape vous fera suffisamment gagner sur l’efficacité de réalisation et limitera les efforts de réécriture à un point tel que vous serez convaincu de sa valeur. Faites-en l’essai par vous-même et vous verrez !</p><h2 style="padding-top: 3em;">Temps de réusinage de code non prévu dans le plan de projet initial</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/68470cb3407a89d812cee1b4_graphique-melissa.png" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></p><p>D'après <a href="https://twitter.com/johncutlefish/status/961840154385072128">John Cutler</a>.</p><p>Quel que soit l’échéancier d’un projet, un imprévu technologique majeur nous fait l’effet d’un ciel qui nous tombe sur la tête à 10 110 011 km/h !</p><p>Le réusinage (« refactoring ») fait partie des processus nécessaires à chaque itération/période de développement. Il consiste à retravailler le code source de façon à le normaliser et améliorer sa structure interne, sans modification du comportement externe du code. Il exclut donc tout ajout de fonctionnalités ou correction de bogues. Il rend le logiciel plus aisé à comprendre et à maintenir, il aide à repérer les bogues et accélère la programmation.</p><p>C’est un peu comme faire du ménage dans ses placards et bien organiser le contenu de ses tiroirs afin d’accueillir du nouveau contenu et de faire en sorte qu’il sera simple d’y accéder par la suite.</p><h3>Solutions</h3><p style="background-color: #dadac5; padding: 9px 12px;">Lorsqu’un projet est construit sur des bases existantes, soit avec l’utilisation du code qui ne vous appartient pas, soit avec du code hérité d’une technologie qui n’est plus prise en charge, il faudra prévoir du temps pour le réusinage de code.</p><p style="background-color: #dadac5; padding: 9px 12px;">Toutefois, même si votre projet débute à partir d’une planche à dessin vierge et que vous en êtes l’instigateur, on ne s’en sort pas ! Il faudra tout de même prévoir du réusinage assez rapidement dans le projet et le besoin sera plus accru avec l’évolution du projet et l’ajout de nouvelles fonctionnalités. Il faudra donc planifier dans les sprints de mi-projet et les avant-derniers sprints une part plus importante de réusinage. Notre pratique nous a démontré que 10 % de réusinage était normalement suffisant pour que le logiciel demeure facile à comprendre, à déboguer et à entretenir, en plus d’accélérer la programmation par la suite.</p><h2 style="padding-top: 3em;">Plusieurs ajouts et changements acceptés en cours de route sans signalement formel</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/684707daa0ed67c8acd19b47_dsc_0314-1.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="decorative"></p><p>© Spiria.</p><p>Bien que l’on pourrait croire qu’a priori un client sera nécessairement plus heureux si l’on fait plus que la demande originale et qu’on accepte tous les changements de dernière minute, il le sera moins s’il réalise que son projet est alors menacé par ces ajouts ou encore que ses contraintes budgétaires ne puissent plus être respectées. Il importe donc d’être transparent avec les clients, de documenter les changements et d’évaluer chaque demande pour ensuite prévenir le client des impacts financiers potentiels ou encore des conséquences que ceux-ci pourraient avoir sur l’échéancier du projet. Même lorsque l’impact vous paraît minime, il est important de le documenter et de le suivre, car un amoncellement de petits changements négligeables peut avoir un impact considérable sur votre projet si vous ne les suivez pas attentivement. Un océan est formé de nombreuses petites gouttes d’eau lui aussi !</p><h3>Solution</h3><p style="background-color: #dadac5; padding: 9px 12px;">Tenir un registre des changements, comme on tient un registre des risques, est une solution essentielle. On le met idéalement en ligne et on invite le client à le consulter chaque fois que l’on y ajoute du contenu. On priorise ensuite les demandes de façon à ne pas menacer l’objectif initial des sprints et du projet avec des éléments intéressants à avoir, mais non prioritaires. Pour certains gros projets, les demandes de changements sont si nombreuses qu’une rencontre hebdomadaire y est consacrée, possiblement jumelée avec celle du suivi de bogues et/ou des risques.</p><p>Pour conclure, c’est grâce à une solide expérience découlant d’un portefeuille de projets variés, une communication efficiente, une grande attention portée au transfert de connaissances, autant en développement qu’en gestion de projets, que l’on s’assure que les meilleures pratiques soient utilisées lors de croisades en terres numériques.</p><p>Je recommande fortement de tenir une liste de leçons apprises et l’historique des problèmes/solutions, puis d’assurer le partage des apprentissages à l’ensemble des communautés de pratique. Ceci permettra d’assurer une amélioration continue au sein des pratiques et de transformer le savoir individuel et collectif en apprentissage organisationnel. Dans le contexte concurrentiel que nous sommes aujourd’hui, une telle démarche pragmatique d’évolution est au cœur de ce que présente l’entreprise apprenante.</p>

<h2>Concilier les exigences du travail et de la famille</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/6847084227510e29db8a05eb_julien-d.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Julien, analyste-programmeur et Scrum Master." title="Julien, analyste-programmeur et Scrum Master."></p><h3>Julien, développeur sénior</h3><p>Il y a toujours un moment où l’on doit concilier travail et vie personnelle. Que ce soit la livraison d’une nouvelle laveuse un mardi entre 9 et 17 heures, la visite d’un plombier pour un dégât d’eau dans la salle de bain, un rendez-vous chez le dentiste, la pose de pneus d’hiver ou encore cette rare fois où vous tombez malade. Il est toujours pratique de pouvoir ajuster l’horaire de sa journée, de manquer quelques heures pour les récupérer un autre jour ou de pouvoir travailler à l’occasion de la maison. Mais lorsque vous avez des enfants, c’est là que la réalité de la conciliation travail-famille vous devient essentielle. Il y a le transport des enfants au CPE et à la garderie qui vient gruger de précieuses minutes de votre journée. Les multiples rendez-vous de suivi chez le médecin et les vaccins au CLSC peuvent toujours se planifier, mais pas mal moins les appels de la garderie en fin de matinée qui vous demande de venir chercher votre enfant qui a (encore !) la gastro (et qui vous la donnera généreusement dans les prochains jours).</p><p>Si vous êtes moins chanceux, un de vos enfants peut avoir un problème mineur de santé qui demande des suivis annuels avec un chirurgien cranio-maxillo-facial, un ORL, un ophtalmologiste et un audiologiste. Ou encore, il pourrait avoir un retard de langage et devoir rencontrer un orthophoniste toutes les deux semaines. Ou bien un autre enfant pourrait avoir un problème cardiaque, être opéré à cœur ouvert très tôt dans sa vie et devoir faire des suivis constants chez le cardiologue. Et si vous êtes moi, vous vivez tout cela à la fois.</p><p>C’est là que vous comprenez la valeur d’un employeur qui vous offre cette conciliation travail-famille. Spiria demande à chacun d’être flexible. Mais Spiria sait aussi être flexible en offrant cette conciliation. Plus d’une fois, j’ai pu profiter de cette flexibilité pour pouvoir assurer mes responsabilités familiales. J’ai pu modifier mon horaire ou bien travailler de la maison. Mes coéquipiers ont pu m’aider à accomplir à temps mes tâches. Pour s’assurer qu’un projet ne prendrait pas de retard, j’ai même pu être remplacé lors d’une longue absence. Je n’ai jamais senti que c’était un problème que de pouvoir être accommodé pour prendre soin de ma famille. Il me suffit de prévenir dès que je suis au courant d’un possible dérangement et tout le monde s’adapte. Spiria écoute, fait preuve de compréhension et propose des solutions pour que vous puissiez passer au travers de votre semaine ou de votre année sans y laisser votre peau. Alors, après cette année particulièrement difficile et éprouvante pour moi, je ne peux que dire : merci !</p><h2>Aucun junior ne pourrait être aussi bien qu’ici</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/684708454f06d76dfc2e13f0_antoine-f.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Antoine, programmeur." title="Antoine, programmeur."></p><h3>Antoine, développeur</h3><p>Je n’ai jamais pensé à faire autre chose que travailler avec des ordinateurs. Je ne savais pas exactement ce que je ferais avec eux, mais j’ai toujours su, dès mon plus jeune âge, qu’ils seraient mes meilleurs amis. La technologie est ma première, deuxième, troisième et quatrième passion, c’est juste une partie de qui je suis, de mes amitiés et de ma vie en général.</p><p>Travail, ça me semble un mot étrange, je n’ai jamais vraiment eu l’impression que la programmation était un travail ! C’est juste ce que j’aime faire, et je suis payé pour le faire, qu’est-ce qui pourrait être encore mieux ? Eh bien, il y a une importante différence ! Coder, c’est quelque chose, travailler dans une entreprise en tant que codeur, c’est différent !</p><p>Les programmeurs sont trop souvent perçus comme des blocs monolithiques pouvant être déplacés de la zone A à la zone B, sans même s’interroger sur ce que leur lieu de travail leur apporte. Mais voici une nouvelle pour vous : nous ne sommes pas des robots, et, oui, nous nous soucions du bureau et de l’ambiance générale de notre lieu de travail ! Quelles sont les stacks avec lesquelles vous travaillez ? À quoi ressemblent les relations avec le patron ? D’autres collègues aiment-ils échanger et partager leurs connaissances ? Est-ce que les développeurs ne sont que des numéros ?</p><p>Du point de vue d’un junior, quand il s’agit de trouver un emploi dans l’industrie du logiciel, c’est vraiment comme une approche Tindr, glisser-déplacer-droite, glisser-déplacer-gauche… Messages sur LinkedIn, offres par courriel, etc. Pour ce qui est de la communication d’entreprise, les RH sont très bonnes pour attirer les jeunes talents avec une image qui dans les faits ne reflète pas la routine quotidienne. L’entreprise essaie de briller comme Google pour attirer l’attention, mais quand il s’agit du travail quotidien de base, la réalité prend le pas sur la projection d’images en couleurs. Ils se vantent de leur stack innovante, mais une fois que vous y êtes, ce n’est plus que du PHP et du code WordPress pitoyable.</p><p>En tant qu’entreprise, si vous mentez sur ce que vous êtes vraiment, vos nouveaux employés commenceront à se rendre compte qu’ils ont été trompés et iront à la recherche de nouveaux défis. Jamais vous ne pouvez dire à un développeur créatif : « Nous ne faisons que du PHP ici, donc adaptez-vous et rentrez dans le moule ». Nous sommes des esprits riches, nous avons besoin de défis et de stimulations, ou bien nous nous ennuyons et passons à autre chose.</p><p>Voilà un fait : si votre entreprise comprend vraiment l’industrie du logiciel, les développeurs seront dans une lune de miel sans fin avec leur travail ! Se lever le matin pour se rendre au bureau sera la meilleure chose qui puisse leur arriver dans la journée. Ma grand-mère me dit toujours que j’ai de la chance d’être heureux au travail, et, oui, je le suis vraiment.</p><p>D’après les sondages, peu de travailleurs aiment leur travail... Mais je ne suis pas l’un d’entre eux. Chaque matin, je me sens heureux de sortir du lit et d’aller travailler. C’est un objectif que mes parents ont passé toute leur vie à atteindre. Être au début de la vingtaine et être si heureux d’aller travailler est une chance, c’est difficile à expliquer, on ne peut le comprendre que si on le vit.</p><p>Spiria, vous fusionnez la créativité, la passion, l’honnêteté, l’intégrité et l’inclusivité dans un tout. Ce n’est pas qu’une image. Vous êtes vraiment ce que vous prêchez et je ne pourrais pas imaginer être plus heureux hors de vos murs. Une entreprise animée par l’amour d’écrire des logiciels et de repousser les limites ! Un c***** de grand merci ! Jamais un junior ne peut être plus heureux que là où je suis en ce moment.</p><p>De la tête et du cœur, merci. Avec amour.</p><h2>Ma voix est entendue et considérée</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/68470849090057c3ec21464d_jose-m.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Jose, analyste en assurance qualité." title="Jose, analyste en assurance qualité."></p><h3>Jose, analyste en assurance qualité</h3><p>En 2017, lors de mon entretien d’embauche avec Jean Godard et Guy Verville, il y avait l’esprit de l’entreprise qui passait à travers eux. J’avais l’impression d’équipes communautaires extraordinaires, le sentiment que le respect et la véritable sincérité étaient dans l’air. Tout était « Oui ».</p><p>J’ai posé de questions. « Puis-je développer mes compétences professionnelles dans cette entreprise ? » « Oui, et l’entreprise t’aidera. » « Mais mon français n’est pas si bon que ça, pouvez-vous m’aider avec ça aussi ? » « Oui, l’entreprise t’aidera. » « Si je démontre que je peux faire plus pour l’entreprise, me donnerez-vous l’occasion d’en faire plus ? » « Oui, l’entreprise t’aidera et t’orientera dans la bonne direction. » Tout ces « Oui » et surtout « l’entreprise t’aidera » a été pour moi un accueil des plus étonnants et cela signifie beaucoup. Et je trouve plus dans Spiria, bien plus. Des amis, des sourires… Je peux dire que ma famille est ici aussi.</p><p>L’entreprise possède quelque chose de rare à trouver, le sentiment et le fait que votre voix peut être entendue et être considérée. C’est une énorme motivation à être plus impliqué dans toutes les tâches, tout en sachant que vous n’êtes jamais seul et que l’aide est toujours là, il suffit de demander. Après plus d’un an et demi chez Spiria, je peux dire que le « Oui, et l’entreprise t’aidera » est plus fort que jamais. Il n’y a pas de limite à ce que je peux faire ou à ce que je veux être au sein de cette équipe extraordinaire. Je voudrais aussi aider les nouveaux arrivés ou les plus anciens à voir ce que je vois depuis le premier jour.</p><p>J’aimerais remercier sincèrement Jean Godard, Guy Verville, l’équipe d’AQ et les équipes de projets que j’ai côtoyées, pour toute cette aide. Comme je l’ai dit un jour : « Faire partie de l’équipe Spiria, c’est penser dans différentes langues, sourire de différentes manières, tout en se sentant bien avec des gens sympathiques autour, avec des amis. »</p><h2>Le plaisir et le bien-être au travail</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/6847084cbd0abd8d6ee146c8_sandra-f.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Sandra, chargée de projets." title="Sandra, chargée de projets."></p><h3>Sandra, chargée de projets</h3><p>Quand on y pense, je passe plus de temps au travail qu’avec ma famille. Pour moi, il était essentiel de trouver une entreprise dont les valeurs correspondent aux miennes et qui m’offre la possibilité d’évoluer professionnellement.</p><p>Pourquoi Spiria ? La diversité des projets et l’offre de services. Une chose est certaine, chez Spiria je ne manquerai jamais de défis ! Chaque projet est unique, tant au niveau de l’équipe que des technologies utilisées. Chaque solution numérique est développée vraiment sur mesure pour le client.</p><p>Dans le cadre des fonctions de mon travail, j’aime avoir une marge de manœuvre. J’aime être impliquée dans les décisions et ajouter ma couleur. Spiria accorde cette latitude aux employés. Également, l’entreprise offre toute une panoplie d’outils pour développer ses compétences, comme des cours de langue, un accès à des formations externes, des ateliers sur le développement personnel, des « foires du savoir », etc. Il y a de tout, et pour tous les goûts.</p><p>Aussi chez Spiria, on met en avant le « fun ». Le plaisir et le bien-être au travail sont au rendez-vous. Il y a une variété d’activités sociales, des « 4 à fun » en passant par le Noël des enfants à M. Crème Glacée, des paniers de fruits frais, de superbes locaux et des gens vraiment super ! On prend soin de ton corps comme de ton esprit...</p><p>Et on sait reconnaître mon travail. Que ce soit via le journal interne, l’écran d’annonces ou mon gestionnaire, on prend le temps de partager les bons coups par différents moyens. Et les moins bons, on n’a pas peur d’en parler pour éviter de les répéter à l’avenir.</p><p>C’est lorsque tu te lèves le matin et que tu es motivée à relever les défis que tu sais que le bonheur, eh bien, il est là...</p><h2>Un management disponible et à l’écoute</h2><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/6847084fbd0abd8d6ee14a0c_sergii-b-2.webp" style="width: 100%; border-style:solid; border-width:1px;" alt="Sergii, analyste en assurance qualité." title="Sergii, analyste en assurance qualité."></p><h3>Sergii, analyste en assurance qualité</h3><p>Spiria est la première entreprise où j’ai commencé à travailler après mon immigration au Canada. J’ai eu la chance de trouver cet emploi quelques semaines après mon arrivée. Avant, j’étais dans une entreprise qui développait son propre produit, ce qui signifiait travailler toujours sur le même projet. Spiria m’offre une expérience totalement différente : un environnement Agile, des projets intéressants pour des clients de différents secteurs d’activité et des possibilités de développement professionnel.</p><p>C’est une grande expérience que de travailler ici, dans cette période fascinante où l’entreprise est en pleine croissance, a une mission à mener à bien et une vision d’avenir. Construire la bonne structure, établir une matrice où chacun peut sentir qu’il contribue à quelque chose de grand et d’important.</p><p>L’une des plus grandes différences entre Spiria et mon expérience précédente, c’est l’approche du management. Lorsqu’une entreprise se développe et que les équipes s’agrandissent, vous ne voulez pas vous sentir perdu et oublié. Ce n’est pas le cas ici. Les gestionnaires sont toujours disponibles et heureux d’être à l’écoute. Ils sont ouverts à toute suggestion qui pourrait améliorer le processus de travail ou le moral de l’équipe. Il y a des rencontres régulières où vous pouvez vous exprimer, discuter de perfectionnement professionnel et des prochaines étapes, demander ou donner de la rétroaction, ou simplement parler de la façon dont vous avez passé votre fin de semaine et du plaisir que vous avez eu. Elles vous donnent l’impression d’être pris en charge et consolident les relations professionnelles.</p><p>J’apprécie également la confiance et la flexibilité : la possibilité de travailler à domicile, de venir au bureau avant ou après les heures de pointe, de rester à la maison en cas de circonstances imprévues. Toutes ces choses construisent une relation de confiance et d’honnêteté qui motive à être productif et à contribuer autant que possible.</p><p>Et bien sûr, je dois mentionner cette grande excitation lorsqu’un projet s’achève, et que vous avez le sentiment que la mission a été accomplie avec succès. Puis vient un autre sentiment : anticiper que le prochain projet pourrait être encore plus intéressant et stimulant, ce qui est génial !</p><p>Un lieu de travail agréable, du matériel performant, des avantages pour les employés, différentes activités sociales, la possibilité de passer du temps avec des collègues en dehors de l’environnement de travail et de nombreux autres petits détails créent l’impression générale que je suis au bon endroit. Et je ne parle pas du délicieux café et du réfrigérateur rempli de lait, de jus et de fruits, parce que c’est quelque chose qu’on doit avoir au bureau de nos jours.</p><p>Pour résumer tout cela, je peux juste dire que je suis un gars ukrainien qui se réjouit de sa vie chez Spiria, qui me donne tout ce dont j’ai besoin pour continuer mon développement professionnel et avoir du plaisir pendant cette période passionnante de ma vie.</p>

<p>Il fut une époque où l’assurance qualité était ni plus ni moins que le dernier filet de sécurité avant la livraison d’un <a href="https://www.spiria.com/fr/services/developpement-axe-performance/developpement-logiciel-sur-mesure/">produit logiciel</a>. Les développeurs poussaient du code, et l’assurance qualité trouvait les anomalies et le processus se répétait. La valeur de l’assurance qualité se mesurait alors en nombre d’anomalies détectées. Et celle du développeur était déterminée inversement par le nombre d’anomalies détectées par ligne de code produite.</p><p>Vous pouvez imaginer les discussions sans fin entre les équipes d’assurance qualité et de développement. On se battait du côté QA pour affirmer qu’il s’agissait un bogue, tandis que les développeurs (dont je faisais partie à l’époque) clamaient que c’était une « conception intentionnelle » pour ainsi ne pas perdre de points. Cela vous fait peut-être sourire, mais c’était comme ça.</p><p>Bien sûr, au fil du temps, cette atmosphère de rivalité a fait place à une plus grande compréhension mutuelle. Mais pas encore au point d’appeler ça de la coopération.</p><p>Revenons à notre réalité actuelle. Les bonnes pratiques du développement exigent la mise en place d’un processus de qualité en mode continu. Cela implique qu’il faut exécuter à chaque itération des tests de non-régression. Ainsi, avec une liste de tests qui croît continuellement au fur et à mesure du développement du produit, ces sessions de détection des régressions consument de plus en plus de temps. Il arrive finalement le moment où l’équipe d’assurance qualité passe plus de temps à exécuter des tests de non-régression qu’à exécuter les tests d’intégration. Ou pire, l’équipe n’ajoute plus de tests à la liste de régression afin de sécuriser du temps pour la validation des fonctionnalités ajoutées.</p><p>De plus, parallèlement à cette exigence de qualité continue, la communauté du développement logiciel s’accorde sur le fait que la grande majorité des anomalies (plus de 80 %) sont introduites lors de la création et de l’édition de modules logiciels. Avec un modèle où trop de temps est dépensé pour l’exécution des tests de non-régression, les anomalies sont malheureusement détectées lors des tests d’intégration, et ce, tard dans le cycle de réalisation (en fait trop tard).</p><p>Il faut prendre en compte le coût de la correction d’une anomalie qui peut être jusqu’à 30 fois supérieur si l’anomalie n’est détectée qu’à la fin des tests d’intégration et jusqu’à 80 fois si la détection se produit en production.</p><p><img src="https://cdn.prod.website-files.com/67c06f07cfba9b0adb43e16c/68470cb6407a89d812cee5ea_shift-left-graph-fr.png" style="width: 100%; border-style:solid; border-width:1px;" alt="Shift left testing." title="Shift left testing."></p><p>Il faut appliquer le principe du « décalage à gauche » (« Shift left testing ») parce qu’il est crucial de détecter les anomalies au plus près du moment où elles sont créées, c.-à-d. pendant l’écriture du code. Il faut rapprocher les deux « pics » et combler l’espace entre eux dans la figure ci-dessus (inspirée de la présentation « <a href="https://fr.slideshare.net/agilemtl/pas-dagilit-sans-qualit">Pas d’agilité sans qualité</a> » donnée par François Boretto d’Askida, à l’Agile Tour Montréal 2018).</p><p>C’est ici qu’entre en jeu l’évolution du rôle de l’assurance qualité : comment réaliser ce « Shift-left » ?</p><p>En premier lieu, les analystes en assurance qualité doivent participer en amont à l’élaboration des scénarios. Ceux-ci doivent être ouverts à la connaissance de plusieurs technologies, et doivent être impliqués et intégrés dans l’équipe de réalisation. Cette approche doit être soutenue et supportée par la direction et les gestionnaires. Il faut ensuite libérer les membres de l’assurance qualité des sessions de tests de non-régression, rendues accablantes.</p><p>Ainsi, nous avons besoin d’une équipe initiée à la stratégie DevOps qui maîtrise le concept du développement et de l’intégration continue. Nous ne parlons plus de testeurs, mais d’analystes en assurance qualité qui ont les compétences de nécessaires pour dresser une liste de tests fonctionnels critiques et d’automatiser ces tests. Les scripts peuvent être exécutés au développement et ensuite à chaque itération à titre de non-régression. Il ne reste qu’un seul temps à considérer, celui du développement des tests fonctionnels. Les tests de non-régression s’exécutent ensuite automatiquement à la fréquence désirée. Il va aussi de soi que les analystes doivent avoir les compétences nécessaires pour gérer et maintenir eux-mêmes un environnement de test.</p><p>Ces compétences requises en assurance qualité sont donc de plus en plus similaires à celles requises pour les développeurs. En fait, il faut être capable de tester, bien sûr, mais aussi de coder. Il y a fort à parier que les tests fonctionnels exécutés manuellement lors de la soumission de code sont appelés à disparaître pour la plupart. Il demeurera cependant toujours (un peu) de place pour les testeurs manuels, car tout ne peut pas et ne doit pas être automatisé. Mais les testeurs qui n’acquerront pas les compétences liées à l’automatisation des tests n’auront plus autant de valeur dans le cycle de développement qu’auparavant.</p><p>Ce que je retiens des articles que j’ai parcourus (<a href="https://www.quora.com/What-is-latest-technology-trends-in-Software-testing">exemple</a>), c’est qu’il devient prioritaire que les équipes d’assurance qualité s’enrichissent par le développement d’une expertise en automatisation des tests et l’acquisition des connaissances relatives à la rédaction de scripts. En faisant évoluer le rôle de l’assurance qualité dans cette direction, il s’avère que les tests de fonctionnalité sont disponibles tôt au début du cycle de réalisation sans compromettre la régularité de l’exécution des tests de non-régression.</p><p style="text-align: right;">Jean Godard, Ing.</p>

<p>Aujourd’hui, tous les sites Web publiés après 2013 en Ontario sont tenus d’être conformes au niveau A. Voici les exigences que j’ai trouvées plus souvent que d’autres négligées :</p><h2>1. Balisage sémantique (niveau A – 1.3.2)</h2><p>Le balisage sémantique est un terme sophistiqué pour une utilisation du HTML pleine de bon sens. Les en-têtes de pages et de sections doivent être entourés de balises d’en-tête (H1, H2, etc.). Un titre H1 ne doit être utilisé qu’une seule fois pour le titre de la page, mais les balises H2, H3, etc. peuvent être utilisées autant de fois que nécessaire.</p><p>Il est important d’utiliser une structure de titres et de paragraphes pour afficher le contenu parce que les lecteurs d’écran utilisent souvent ces titres structurés pour indiquer le début et la fin du contenu. Si une page n’a pas de titres, les utilisateurs ne verront ou n’entendront qu’un énorme mur de texte sans pause.</p><h3>Les « pauses thématiques »</h3><p>Lors du formatage du contenu en HTML, les changements de contexte peuvent être marqués par des « pauses thématiques », représentées par la balise HR. Ceci indique au lecteur d’écran qu’il devrait y avoir une pause lors de la lecture du texte et signifie également à l’utilisateur un changement de sujet, au lieu d’un texte en continu.</p><h3>Changements de langue</h3><p>Imaginez une voix synthétique anglaise lisant des mots français ou espagnols comme s’il s’agissait de mots anglais. L’indication des changements de langue garantit que le contenu est lu à haute voix avec précision par la technologie d’assistance, comme le lecteur d’écran.</p><p>Par exemple :</p><pre><code>&lt;span lang="EN"&gt;I love chocolate.&lt;/span&gt; </code></pre><h2>2. Formulaires et étiquettes de champs (niveau A – 3.3.2)</h2><p>Les formulaires doivent toujours être logiques et intuitifs, leurs champs correctement étiquetés et il est nécessaire de fournir des instructions claires. Les champs obligatoires doivent être indiqués et les étiquettes de champs doivent être présentes dans le code, même si elles ne sont pas visibles dans le design visuel.</p><pre><code>&lt;label for="courriel" class=”hidden”&gt;Adresse de courriel&lt;/label&gt; &lt;input class="form-control" id="courriel" name="courriel" type="text" placeholder="Adresse de courriel" /&gt; </code></pre><p>Une étiquette associée à une entrée sera prononcée par les lecteurs d’écran lorsque le champ sera sélectionné. Cela permet également à l’utilisateur de cliquer sur l’étiquette pour activer le contrôle.</p><h2>3. Liens : texte, couleur et focus (niveau A – 2.4.4)</h2><p>Les personnes avec un lecteur d’écran utilisent souvent une liste déroulante de tous les liens contenus dans une page. Il est important d’avoir des liens qui donnent le contexte approprié. Par exemple, une liste de liens « cliquez ici », « cliquez ici », etc. est désastreuse pour l’accessibilité. À la place, il est beaucoup plus clair pour les utilisateurs de fournir une contextualisation dans le texte du lien, par exemple : « Téléchargez le rapport annuel ».</p><h3>Survol et focus (niveau A – 1.4.1)</h3><p>L’état de survol d’un lien ne peut pas s’appuyer uniquement sur la couleur pour transmettre un sens. Il se peut qu’une personne daltonienne n’ait pas accès à l’information sur les couleurs, et les utilisateurs de lecteurs d’écran n’y auront pas accès non plus. À la place, ajoutez un soulignement en plus de la couleur qui aidera les utilisateurs à comprendre qu’il s’agit d’un lien.</p><h2>4. Inclure des descriptions d’images (niveau A – 1.1.1)</h2><p>L’ajout de texte alternatif aux images est souvent une réflexion après coup et aboutit à des descriptions d’images comme « image » et « nom de fichier.jpg », ce qui signifie que les utilisateurs passent à côté d’un élément clé de l’accessibilité.</p><p>Il est important d’avoir un texte descriptif pour les utilisateurs qui ne peuvent pas voir ces images. Une technique pour déterminer le texte alternatif d’une image serait de regrouper les images dans les trois catégories suivantes : simples, complexes ou décoratives.</p><h3>Simples</h3><p>Ces images sont des photographies, des icônes ou des logos, et le texte descriptif doit être succinct.</p><pre><code>&lt;img src="fleurs.jpg" alt="Fleurs dans un jardin." /&gt; </code></pre><h3>Complexes</h3><p>Ces images sont des diagrammes ou des graphiques et le texte descriptif sera plus détaillé.</p><pre><code>&lt;img src="diagram.jpg" alt="Figure 1. Taux d'utilisation des lecteurs d’écran au Canada" /&gt; </code></pre><h3>Décoratives</h3><p>Ces images sont purement décoratives, l’attribut <i>alt</i> est vide et un attribut de rôle indique <i>presentation</i>. Cela signifiera au lecteur d’écran d’ignorer l’image.</p><pre><code>&lt;img src="espacement.png" alt="" role="presentation" /&gt; </code></pre><h2>5. Navigation au clavier (niveau A – 2.1.1)</h2><p>L’une des caractéristiques les plus importantes de l’accessibilité est la possibilité de naviguer sur un site Web avec uniquement le clavier.</p><p>Les utilisateurs doivent pouvoir naviguer dans le contenu et les éléments de manière séquentielle et cohérente (niveau A – 2.4.3). En ajoutant un attribut <i>tabindex</i> de valeur 0 à un élément, cela |'insère dans l’ordre de tabulation en fonction de son emplacement dans le code source. Ceci permet également à n’importe quel élément d’avoir le focus.</p><p>L’état de focus doit être présent et cohérent pour tous les éléments de navigation (niveau AA – 2.4.7). C’est une bonne pratique lors de la création de composants personnalisés d’utiliser des éléments HTML « focalisables ». Cela vous permet de profiter de la fonctionnalité par défaut, autrement le focus au clavier et le support d’interactions doivent être fournis.</p><p>Enfin, l’ajout d’un lien de saut direct vers le contenu principal permet au lecteur d’écran de passer le bloc des éléments de navigation, évitant ainsi d’avoir à passer en revue chaque lien sur chaque page. (Niveau A 2.4.1.)</p><h3>Ressources sur l’accessibilité (en anglais)</h3><ul lang="en" xml:lang="en"> <li><a href="http://contrast-finder.tanaguru.com">Contrast Finder</a>.</li> <li><a href="https://www.powermapper.com/products/sortsite/">SortSite</a>, a one-click web site testing tool.</li> <li><a href="https://webaim.org">WebAIM</a>, training, certification and assistance</li></ul><h3>Sources</h3><ul lang="en" xml:lang="en"> <li>Ontario.ca: “<a href="https://www.ontario.ca/page/how-make-websites-accessible">How to make websites accessible</a>.”</li> <li><a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines (WCAG) 2.1</a>.</li> <li>Mozilla: “<a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility">Handling common accessibility problems</a>.”</li> <li>University of Washington: “<a href="https://www.washington.edu/accessibility/checklist/images/">Making Images Accessible</a>.”</li> <li>WebAIM: “<a href="https://webaim.org/techniques/keyboard/">Keyboard Accessibility</a>.”</li></ul>