La conception importe plus que la production

Publié par David Beaumier le mardi 16 juin 2015 à 10:17

« It’s not the production system that matters most, but the design system ». Du moins, c’est le point de vue de Toyota lorsque son système de production (le fameux TPS – Toyota Production System) est comparé à son système de conception, le TPDS pour Toyota Product Development System.

C’est sans doute pour cette raison que Toyota a toujours accepté de recevoir les représentants des autres manufacturiers dans ses usines. Toyota savait que son principal avantage compétitif se trouvait plutôt au niveau du système de conception de ses produits. Et oui, même si la conception est une activité hautement créative, le système à l’intérieur duquel cette conception se fait peut, à plusieurs égards, être standardisé.

It’s not enough to do your best; you must know what to do and then do your best.

- W Edward Deming

En développement logiciel, bien des équipes ont tendances à associer leur processus de développement à un système de production. Je crois qu’elles auraient plutôt avantage à faire comme Toyota et scinder en deux leur processus : la conception du logiciel et la production du logiciel. Ne vous méprenez-pas, je ne vous propose pas de revenir au développement en cascade!

Je vous propose plutôt d’utiliser l’analogie de la chaîne de montage pour regrouper les activités de construction (build), de vérification, de déploiement et de mise en production de votre logiciel. Le fameux DevOps, quoi. Le serveur d’intégration continue, avec son build, ses tests et vérifications et par la création du paquetage applicatif, joue en quelque sorte le rôle de l’usine. La partie déploiement, mise en œuvre et opérationnalisation du produit équivaut cycle de distribution, de vente et de service habituellement associé au réseau des concessionnaires.

Les activités en amont, incluant le « codage », sont en réalité des activités de conception. C’est seulement un fois que le serveur récupère le code depuis votre gestionnaire de sources que l’usine se met en branle. Tout ce qui se fait avant sert à définir les spécifications structurelles et comportementales de l’application (qu’il s’agisse de l’interface utilisateur ou de traitements d’affaires). Le code source, les schémas de bases de données et la configuration représent les spécifications requises pour bâtir le produit.

Ce n’est donc pas suffisant de mettre votre usine en marche. Vous devez vous assurer qu’elle produit la bonne chose! Heureusement, nous avons la chance en développement logiciel de ne pas avoir à gérer les contraintes physiques. Nous pouvons construire une seule fois le produit et le cloner aussi souvent que souhaité. Il nous est possible de changer ses spécifications, le bâtir et l’essayer en peu de temps et pour peu de frais. Cette flexibilité devrait donc nous permettre de nous concentrer sur le produit à bâtir plus que sur sa fabrication. Ce n’est pas que l’aspect DevOps ne soit pas important, c’est juste que ce n’est habituellement pas en premier lieu pour votre efficacité à bâtir et opérer qu’un client va adorer votre produit.

Ne perdez pas de vue le premier des principes du manifeste agile: le client sera satisfait par la livraison de fonctionnalités à valeur ajoutée.

Principe1 Manifesteagile

Un cadre de travail agile, tel que Scrum, a l’avantage d’offre un modèle itératif pour la conception de produits. Jumelé à un système de production efficace ça permet de réduire la boucle de rétroaction afin de valider que vous avez conçu les fonctionnalités requises pour que votre client atteigne ses objectifs d’affaires.

Et vous, est-ce que votre équipe se perçoit comme un groupe de conception de produits ou se voit-elle plutôt comme une équipe de fabrication?

blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.