Vous n’êtes pas connecté à Internet.
News 14103

Comment nous poursuivons le développement de notre logiciel

Notre croissance nous demande de trouver des manières agiles et intelligentes de nous adapter à tous les niveaux. L’organisation et l’architecture du logiciel doivent constamment évoluer. Cet article vous présente nos actualités et préoccupations.

Il y a bien trop longtemps que je ne vous ai pas donné un aperçu des travaux de développement de Digitec Galaxus. Peut-être certains lecteurs assidus se souviendront-ils de cet article:

Nous n’avons pas chômé. Notre département du développement est passé de cinq à douze équipes Scrum, ce qui n’est pas sans poser quelques problèmes qu’il s’agit de résoudre avec doigté. Mais nous sommes prêts à surmonter les multiples défis auxquels nous faisons face actuellement, et qui ne diminueront sans doute pas ces prochaines années.

Le développement rapide de notre département du développement nous demande de développer davantage notre développement… Logique, non?

Nos défis

  • Le passage de cinq à douze équipes Scrum cette dernière année
  • Une croissance continue de notre département du développement nous attend ces prochaines années
  • L’emploi de nouveaux collaborateurs nécessite une réorganisation de notre savoir-faire
  • Les exigences quant aux temps de réaction de l’application sont plus élevées (Performance matters)
  • Nous devons garantir notre évolutivité en vue d’une multiplication des commandes et des interactions avec les utilisateurs
  • Nous devons rendre la complexité transparente à l’aide de modules clairs (Bounded Contexts) et d’interfaces propres
  • Nous devons transférer la totalité de notre solution sur le cloud

Rendre la complexité maîtrisable

La complexité, c’est compliqué. Comme l’a dit Steve Jobs: «La simplicité peut être plus difficile que la complexité. Rendre ses pensées claires pour les simplifier demande beaucoup de travail». Simplifier les processus et les problèmes requiert non seulement des compétences techniques, mais aussi des connaissances approfondies des processus de l’entreprise. Lorsqu’un système est mal divisé, il augmente inutilement la complexité au lieu de la maîtriser. La modularisation est une bonne chose, mais ce n’est pas une panacée: même lorsqu’on crée des modules pertinents, la complexité de la solution dans son ensemble n’est pas réduite. Elle est simplement transférée aux interfaces entre les systèmes. Dans l’idéal, il existe un petit nombre d’interfaces les plus stables possible grâce auxquelles une équipe se concentre sur un seul module et n’a pas à se soucier du reste de l’application.

La complexité ne peut être réduite (en allemand) que si les exigences et les capacités du système sont réduites elles aussi. L’objectif premier n’est donc pas de la réduire, mais de la maîtriser.

Et comment la rend-on mieux maîtrisable?

Voici la théorie:

  • En effectuant un partitionnement. On divise le système complet en différentes parties qu’on laisse communiquer par le biais d’interfaces claires et les plus simples possible.
  • En établissant une hiérarchie explicite entre les parties du système, afin de pouvoir garder une vue d’ensemble du système, d’obtenir des dépendances et des interfaces évidentes, et de prioriser de manière claire.
  • En rendant les différentes parties du système autonomes afin de pouvoir se concentrer principalement sur les domaines de compétence respectifs.

Ce qui me semble important:

  • Éliminer les processus et étapes de travail inutiles qui n’apportent aucune plus-value au client. C’est un point essentiel. On a parfois tendance à tout compliquer et bureaucratiser.
  • Se concentrer sur le client. En retire-t-il des avantages? Ces avantages sont-ils proportionnels?
  • Voilà qui nous amène à la priorisation: une priorisation judicieuse nécessite une stratégie et une vision claires.
  • Chacun peut aider en dénonçant les processus compliqués et en abordant de manière ouverte les problèmes pertinents, sans chercher de nouveaux problèmes insignifiants.
  • Établir des hiérarchies plates et un travail collaboratif.
  • Les compétences devraient être réparties autant que possible à travers les équipes.
  • En cas de doute, on doit avoir la possibilité de prendre des décisions claires, même si tout le monde n’est pas d’accord. Sinon, on reste bloqués, alors qu’en fin de compte, presque chaque problème peut être résolu de différentes manières.
  • Soyons constructifs et optimistes, car les problèmes existent pour être résolus. Et les solutions font apparaître de nouveaux problèmes. C’est le cycle passionnant de tout ingénieur. 😉

Comment nous faisons face aux défis

Je vais vous donner un aperçu de ce qui s’est passé ces 15 derniers mois et de ce que nous avons fait pour développer notre département du développement.

La spécialisation par domaine

Les équipes Scrum ont été clairement affectées à un domaine, c’est-à-dire un secteur tel que la logistique, la gestion de produit ou la boutique en ligne. Chaque équipe peut donc se spécialiser dans un secteur et développer des solutions toujours plus élégantes. Le secteur est généralement représenté par un département. L’équipe de développement collabore aussi étroitement que possible avec celui-ci afin de déterminer à l’aide de quelles ressources actuelles nous pourrons apporter la meilleure plus-value possible au client. Il faut que l’équipe soit la plus stable possible. Dans l’idéal, elle est si bien rodée qu’elle travaille en état de flow.

Des équipes interdisciplinaires

Une équipe n’est plus uniquement constituée de développeurs de logiciels. Elle devrait toujours réunir toutes les compétences nécessaires au domaine ou au sous-domaine. Ainsi, une équipe dédiée à notre boutique en ligne comprend un designer d’interaction et un développeur front end. Selon le contexte, elle fait également appel à un ingénieur en exigences système, un spécialiste en renseignements commerciaux ou un ingénieur de systèmes. Cela permet de réduire les interfaces et de raccourcir les voies de communication. L’équipe doit pouvoir travailler de manière autonome sans obstacle et ne pas être ralentie par des dépendances inutiles.

Coacher de nouvelles équipes

Les nouvelles équipes sont principalement constituées de nouveaux collaborateurs afin de les rendre aussi stables que possible et d’éviter de modifier sans cesse leur composition. Afin de faciliter l’acquisition du savoir-faire, elles sont accompagnées de manière spécialisée et méthodique par un coach: un développeur de logiciels habitué à notre environnement les suit durant un certain temps et répond à leurs questions. D’un point de vue méthodologique, un coach du secteur Scrum et développement de logiciels agile collabore avec l’équipe entière.

Les compétences et les responsabilités individuelles au sein des équipes

Afin de travailler dans l’esprit de l’entreprise, chaque collaborateur doit pouvoir accéder aux informations nécessaires. Qu’il s’agisse de notre stratégie, notre mission, notre vision ou encore les résultats du sondage mené auprès de nos collaborateurs, nous n’avons pratiquement plus aucune information qui ne soit pas accessible à tous. Ainsi, chacun peut vérifier que ce qu’il doit faire correspond à la stratégie de l’entreprise. Chacun doit savoir quelle prestation nous voulons livrer au client. Notre proposition de valeur est publique et transparente afin que chaque client puisse vérifier que la qualité de nos prestations s’y conforme.

Notre stratégie dans le cloud

Au vu des progrès technologiques actuels, nous pensons que l’avenir se jouera entièrement dans le cloud. De nouvelles fonctionnalités sont déjà proposées uniquement dans le cloud. Avec les milliards investis dans les diverses plateformes sur le cloud, ce phénomène continuera à s’accélérer. Et afin d’en profiter, nous misons sur plusieurs prestataires. La flexibilité et l’innovation que nous offrent les solutions sur le cloud sont des aspects décisifs. C’est la raison pour laquelle les nouveaux services sont uniquement développés sur le cloud. Même lorsque nous apportons des modifications à un secteur, nous les transférons autant que possible sur une plateforme cloud optimale. Certains de nos services ont déjà été mis en place sur la plateforme Google Cloud, sur Microsoft Azure et sur Elastic. Tous les éléments de l’application qui n’ont pas encore été adaptés continuent d’être exploités dans nos deux centres de données. On ne peut pas faire plus hybride que ça. Cela explique aussi pourquoi le DevOps gagne en importance, ce qui sera encore davantage le cas à l’avenir. En effet, dans le cloud, l’infrastructure devient une partie de l’application.

Aucun autre changement ne me vient à l’esprit pour le moment, et il est temps que je mette un point final à mon article. Je ferai en sorte que vous n’ayez pas à patienter plus d’un an avant ma prochaine contribution. Je risquerai aussi moins d’oublier certains changements.

Davantage d’informations sur le développement de notre logiciel

Vous souhaitez développer avec nous?

Nous voulons accélérer notre développement. Si vous avez été convaincu par notre vision et si vous êtes prêt à relever les nombreux défis que représente notre croissance, n’hésitez pas à répondre aux diverses offres d’emploi de notre département du développement.

User
Cool: construire des ponts entre le monde réel et le monde de l’information. Pas cool: prendre sa voiture pour aller faire ses courses. Ma vie est «en ligne» et l’ère de l’information ma patrie.

Commentaires 14

User Athrandir

Ein Kompliment an alle Entwickler, Architekten und Designer bei Digitec. Die Nutzung Eurer Plattform macht nicht nur Spass sondern ist auch Inspiration. Man merkt als Nutzer sofort, dass hier Hingabe dahinter steckt - deshalb auch der Vorsprung gegenüber den Plattformen globaler Mitbewerber.

11.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.

User juhahartmann

12 Teams mit Scrum? Vielleicht bald Zeit auf SAFe umzusteigen ;)

09.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User raphaelrenaud

Ist schon Realität: digitec.ch/de/page/wie-entw...

09.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.

User reinhold86

Wie gross sind denn eure Scrum Teams?

09.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User Oliver Herren

Die sind zwischen fünf und neun Personen gross.

10.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.

User Krono

Echt cool!
Die mobile Seite von digitec Seite solltet ihr aber bald mal ziemlich stark verbessern. Mühsam zum benutzen...

17.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.

User ianazch90

What technologies are you using (programming language(s), framework,...)?

03.11.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User witold.baryluk

Looking at job offerings it looks to be mostly C#, ASP.NET, MS SQL. I have no idea how well it scales, but is probably costly in the long run. And moving this to cloud is probably limited. For the frontend, I have no idea. Would be nice to have so ideas about architecture, caches, load balancing, etc. (I see static content is mostly stored in Akamai caches).

14.11.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User Tobias Käppeli

Like Witold.baryluk said. We mostly use C# ASP.NET and MSSQL.
Other technologies we use are:
- Javascript. The frontend team wants to go an isomorphic approach in the future.
- .NET Core for our newer projects
- Elasticsearch, Logstash, Kibana for search, filtering and as key/value store.
- MSSQL for all relational databases and as Datawarehouse
- Azure Service Bus is coming soon as new messaging service
- Application Insights for Logging
- Akamai as CDN
- BigQuery, DataProc, Datastore, Dataflow in the Google Cloud

For Development we use:
- Visual Studio 2017 or Rider
- Visual Studio Team Services for Git Repositories and Continuous Integration
- NDepend and SonarQube for code analysis

@Witold.baryluk the move to the cloud is getting a lot easier when we migrate more of our code to .NET Core and start using Containers for those workloads. The recently released version 2.0 of the .NET Standard should help here.

hier 18:48
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.

User zilti

"Die Komplexität kann nur reduziert werden, wenn auch die Anforderungen und die Fähigkeiten des Systems reduziert werden." - Ein Trugschluss! Komplexität zeugt von unpassenden Herangehensweisen, nicht von Systemanforderungen.

11.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User daniel.tobler

Ich unterscheide zwischen Komplexität, die Anforderungen geschuldet ist und "Accidential Complexity". Für erstere gilt das Zitat im Titel. Die zweite Art der Komplexität, die ich auch häufig antreffe stammt von falschen oder falsch angewandten Technologien, Unwissen, falschen Wissen, von "gut gemeint" und Realisierung von Anforderungen, welche gar nie Anforderungen waren oder dessen Funktion dann doch nie gebraucht wurde.

22.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User jacksuisse

Sprachlich sollte man differenzieren zwischen komplex und kompliziert. Dann gibt es da auch keine Missverständnisse. Für den richtigen Umgang mit Letzterem braucht man vor allem Kompetenz.

14.11.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

User rg

Die Unterscheidung zwischen kompliziert und komplex ist uns wohl bewusst. Sowie in einem System eine gewissen Anzahl von Menschen stecken, ist es komplex. Ein Online-Shop im E-Commerce ist korrekt formuliert ein soziotechnisches Ökosystem. Es interagiert mit den Benutzern in vielfacher Weise und spricht den Menschen auch emotional an. Daher ist dieses System an sich schon komplex. Kompliziert ist zum Beispiel die Aufbereitung der Bestellungen in Versandeinheiten. Dies ist ein Algorithmus.

hier 08:18
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.

User XXXXXX

"Die Softwarebranche ist binär. Du bist dir Eins oder die Null. Lebendig oder Tod" - Start Ups

10.10.2017
Signaler un abus

Vous devez être connecté pour signaler un abus.

Vous devez être connecté pour répondre à un commentaire.


Veuillez vous connecter.

Vous devez être connecté pour écrire un commentaire.

Corporate logo