Product Development : un groupe hétéroclite qui déteste la bureaucratie et apprend de ses erreurs
Dans les coulisses

Product Development : un groupe hétéroclite qui déteste la bureaucratie et apprend de ses erreurs

Stefan Müller
Zurich, le 31.05.2022
Traduction: Alassane Ndiaye

Chez Digitec Galaxus, nous développons nous-mêmes nos boutiques en ligne et notre système ERP. Actuellement, plus de 260 ingénieurs, Product Owners, Data Analysts et UX Designer répartis dans 35 équipes de développement travaillent à l'optimisation continue de nos processus. L'objectif est de générer de la valeur ajoutée pour nos clients de la manière la plus efficace et efficiente possible. Vous découvrirez dans cet article les aspects qui nous tiennent particulièrement à cœur.

Notre culture se caractérise par les valeurs d'entreprise coopératif, novateur, piratif, responsable et ambitieux. Ils constituent la base de notre collaboration.

Nous attachons une importance particulière à ce que tous les membres de l'entreprise, indépendamment de la hiérarchie, se rencontrent sur un pied d'égalité et se respectent mutuellement, et à ce que les opinions et les points de vue différents soient considérés positivement. Nous sommes ainsi libres de discuter des idées les plus folles et d'exprimer nos doutes sans complexe. Cette ouverture est une condition extrêmement importante pour développer des solutions intelligentes et innovantes et les mettre en œuvre avec détermination.

Il est également important pour nous d'aborder nos tâches et nos défis de manière proactive et responsable et de prendre les décisions nous-mêmes, dans la mesure du possible. Pour ce faire, il est essentiel de supprimer systématiquement les obstacles bureaucratiques inutiles et d'alléger les processus de décision.

Les erreurs se produisent pour que l'on puisse en tirer des leçons

En outre, une forte culture de l'apprentissage et de l'erreur nous tient à cœur : plus nous parvenons, en tant qu'organisation, à ne pas chercher les coupables et à ne pas les clouer au pilori en cas d'erreur, mais à tirer le maximum d'enseignements de ces erreurs, plus nous pouvons construire des connaissances. Et cela nous aide à développer des logiciels de manière efficace et efficiente. Les pratiques suivantes se sont révélées précieuses dans ce contexte :

  • nous soutenons les changements d'équipe temporaires, appelés DevXChanges. Ils nous permettent d'acquérir de l'expérience dans un autre contexte et d'élargir nos propres horizons.
  • toutes les deux semaines, les équipes de développement présentent leurs réalisations et leurs nouvelles connaissances à l'ensemble du département lors de la réunion DevInfo.
  • après des incidents majeurs, nous effectuons un post mortem. Le but est d'apprendre de nos erreurs et de réduire le risque de tomber à nouveau dans un piège similaire.
  • pour la formation continue personnelle, nous proposons divers cours internes sur les compétences professionnelles, sociales et leadership. Des exemples de sujets actuellement traités sont le Domain Driven Design, les méthodes agiles ou la gestion des conflits.

Processus de planification et de développement agile

Notre direction définit l'orientation stratégique de l'entreprise dans les objectifs annuels. Sur cette base, nos équipes de développement formulent des initiatives en étroite collaboration avec tous les secteurs d'activité. Une initiative décrit un projet de changement avec des objectifs clairs et des résultats vérifiables, qui contribue directement aux objectifs stratégiques. Une initiative doit pouvoir être mise en œuvre en quatre mois maximum. Cela nous permet d'apprendre vite et de réagir rapidement à l'évolution des priorités.

Dès que la mise en œuvre d'une initiative commence, elle est découpée en petits lots de travail, appelés épics et stories. Les stories sont ensuite priorisées et mises en œuvre dans les backlogs (ou listes des fonctionnalités) de produits des équipes de développement. Le développement se fait dans le cadre du framework Scrum, complété en partie par les pratiques Kanban.

De l'objectif stratégique de l'entreprise à la story dans le backlog de produit
De l'objectif stratégique de l'entreprise à la story dans le backlog de produit

Des équipes de développement spécialisées créent de la valeur ajoutée

Les équipes de développement se spécialisent dans un domaine d'activité particulier et sont chargées d'améliorer l'expérience client en développant à la fois les processus et les solutions techniques dans ce domaine. Afin de favoriser une organisation évolutive et un environnement de travail motivant, il est important pour nous de pouvoir prendre plusieurs décisions directement au sein d'une équipe. Grâce à la spécialisation, nous parvenons à développer en permanence au sein de l'équipe les connaissances détaillées nécessaires à cet effet, tant du point de vue des produits que de la technique. Une équipe est généralement composée de 6 à 9 personnes au total. Outre les développeuses et développeurs, chaque équipe dispose d'un Product Owner. Il est responsable de la priorisation du backlog de produit. Et puis il y a le·a chef·fe d'équipe. Il ou elle est responsable de la gestion du personnel, mais participe aussi activement au développement de la solution technique. La responsabilité de l'architecture logicielle incombe à l’équipe : Pour chaque initiative, un membre de l'équipe assume le rôle d'architecte de solutions et marque ainsi de son empreinte l'architecture des solutions mises en œuvre.

Plusieurs équipes forment ensemble une zone. Le tableau ci-dessous donne un aperçu général des responsabilités des zones et l'image présente les différentes équipes par zone.

Nos équipes et nos zones
Nos équipes et nos zones

Feed-back rapide grâce à la continuous delivery

Il est important pour nous de pouvoir intégrer rapidement et fréquemment les modifications mises en œuvre dans l'environnement de production (continuous delivery). Cela se fait en général après chaque story mise en œuvre, donc plusieurs fois par jour. Cela nous permet d'éviter les grandes sorties et d'obtenir un feed-back rapide si quelque chose ne fonctionne pas comme prévu. En outre, les clients peuvent bénéficier immédiatement des améliorations. Des tests automatisés dans le cadre du processus de sortie augmentent la probabilité que d'éventuels bugs soient détectés et corrigés à temps. Et si quelque chose nous échappe, nous serions heureux de recevoir vos commentaires dans la communauté.

Le cycle DevOps présente toutes les étapes nécessaires pour la sortie fréquente des versions.
Le cycle DevOps présente toutes les étapes nécessaires pour la sortie fréquente des versions.

L'architecture logicielle modulaire permet une répartition claire des responsabilités

Nous misons sur une architecture modulaire avec des interfaces aussi légères et stables que possible entre les différents composants logiciels. Chaque composant correspond à une partie de notre domaine d'activité et est placé sous la responsabilité d'une équipe désignée. Nous nous assurons ainsi que toutes les équipes se concentrent sur leur domaine de responsabilité et ne se gênent pas mutuellement lors de la mise en œuvre de nouvelles fonctionnalités.

Un composant logiciel vit dans un module (micro-service) ou dans un monolithe modulaire. Actuellement, il existe plus de 50 modules (un ou deux par équipe). Notre pile technologique repose principalement sur .NET Core, MS SQL Server et MongoDB. Pour le front-end de la boutique en ligne, nous utilisons React avec Next.js et GraphQL. Les modules et le monolithe sont exploités dans un cluster Kubernetes. Pour la communication asynchrone, nous utilisons la messagerie (Kafka et Azure Service Bus). Vous trouverez notre Tech-Radar complet ici.

Les composants logiciels et leurs interactions
Les composants logiciels et leurs interactions

Des normes intelligentes

Les équipes de la zone « Platform & SysOps » mettent tout en œuvre pour que les autres équipes de développement puissent travailler le plus efficacement possible. Elles le font en proposant des solutions standardisées pour des thèmes transversaux et questions d'infrastructure. Il s'agirait par exemple d'un modèle de module, d'un cluster Kubernetes, d'une solution d'observabilité centrale (logging, suivi, alerte) ou d'une Database-as-a-Service pour nos techniques de persistance standard (SQL-Server et MongoDb). L'objectif est de faciliter la compréhension et l'utilisation par les équipes de développement de ces services de plateforme, faire en sorte qu'il reste suffisamment de place pour le développement de fonctionnalités ayant un impact sur le client.

Avez-vous des questions ou envie d'améliorer nos magasins et nos processus ? N’hésitez pas à poser vos questions dans la colonne des commentaires.

Nous visons en permanence à renforcer nos équipes. Vous trouverez nos offres d'emploi actuelles sur notre portail emploi.

Pour en savoir plus sur diversité de nos équipes :

  • Dans les coulissesInformatique

    Team Isotopes: Die Speed Demons des Engineerings

  • Dans les coulissesInformatique

    Team KickAss: Arbeit da, wo es weh tut

  • Dans les coulissesInformatique

    Team Spectre: les acteurs de l'ombre

  • Dans les coulisses

    Keine künstliche ohne menschliche Intelligenz

Cet article plaît à 55 personne(s)


User Avatar
User Avatar

Ma passion, c'est la technologie et les personnes qui se cachent derrière. J'aime trouver des solutions simples à des problèmes complexes avec des gens cools. Je profite de mon temps libre avec ma famille et en faisant du sport.


Ces articles pourraient aussi vous intéresser

  • Skeleton Loader

    Skeleton Loader

  • Skeleton Loader

    Skeleton Loader

  • Skeleton Loader

    Skeleton Loader