HELP : traduction interview InfoQ Don Reinertsen à LKFR13
alexis8nicolas
Pascal Venier
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes KanbanDevFr.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse kanbandevfr...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
Thomas Lissajoux
ckeromen
Dimitri BAELI
Bonjour,
Voici une version en HTML (via l'outillage de publication qui sera utilisé par InfoQ). Des relectures vont avoir lieu mais si vous voyez des soucis n'hésitez pas à le signaler. J'espère une publication dans les 2/3 semaines.
Merci Alexis !!
Dimitri
Don Reinertsen est consultant indépendant et auteur du Livre The Principles of Product Development Flow paru aux éditions Celeritas Publishing en 2009.
InfoQFR : Alexis pour InfoQFR. Aujourd’hui Don Reinertsen nous fait le plaisir de répondre à nos questions. Bonjour Don, pouvez-vous vous présenter ?
Don Reinertsen : (0:17) Bien sûr, je m’appelle Don Reinertsen, je suis consultant dans le domaine du développement de produits, depuis 30 ans déjà. Je travaille avec des personnes qui développent des logiciels ou d’autres types de produits. Mon travail met l’accent sur la manière de réduire les temps de cycle de développement. Depuis 15-20 ans, je me concentre sur comment bien utiliser, dans le domaine du développement produit, les idées qui ont émergées dans l’industrie et les chaînes de production. Je cherche les idées les plus avancées de ce domaine, et quand elles sont insuffisantes, je m’attache à en chercher d’autres.
InfoQFR : Que voulez-vous dire par « comment bien utiliser les idées » ?
Don Reinertsen : (1:17) Dans les chaînes de production, la plupart du temps, on cherche à éliminer la variabilité parce que quand on répète la même action un million de fois, on veut pouvoir le faire à chaque fois de la même façon. Dans ce domaine, c’est quand le produit ne change pas du tout qu’on peut gagner de l’argent. Dans le domaine du développement produit, c’est différent, si on ne change pas le produit, on n’ajoute pas de valeur. Le développement produit, c’est plutôt préparer des recettes pour de futurs produits, que de produire à la chaîne. Si la recette ne change pas, on ne crée pas de valeur. Donc l’idée que tout doit toujours rester figé ne fonctionne pas en développement produit. Ce dont on a besoin c’est de mettre en place des processus qui fonctionnent en présence de variabilité.
InfoQFR : Dans votre livre, vous explorez huit thèmes différents, pouvez-vous nous en dire plus ?
Don Reinertsen : (2:33) Ces 8 thèmes sont autant de façon d’expliquer aux lecteurs les différences fondamentales qui existent entre un développement produit traditionnel et un développement produit en flux. Le premier thème est celui de l’importance d’avoir un modèle économique et en particulier de connaître ce qu’est le coût du délai. Le concept de coût du délai nécessite de comparer les profits générés par le produit sur toute sa durée de vie entre le fait de l’avoir disponible aujourd’hui et de l’avoir disponible seulement dans 60 jours. La différence entre ces profits, aujourd’hui et 60 jours plus tard, est ce qu’on appelle le coût du délai. Quand on a la possibilité de faire un choix entre passer plus (ou moins) de temps ou faire plus (ou moins) de dépenses sur une fonctionnalité donnée, il est préférable de toujours vérifier si le coût du délai généré par le temps supplémentaire (ou économisé) vaut ce gain. Le coût du délai et le modèle économique sont toujours le point de départ, parce que le monde du développement produit connaît une telle variabilité et que les coûts du délai sont tellement différents, que sans cette analyse, tout le monde fait des erreurs.
InfoQFR : Pouvez-vous clarifier pour les français ce que vous voulez dire par développement produit, car en France c’est souvent compris comme étant uniquement le développement informatique, mais vous semblez l’utiliser dans une acception plus large ?
Don Reinertsen : (4:26) En effet, je travaille avec beaucoup d’industries différentes, des produits de consommation à l’aérospatial, en passant par l’informatique ou les appareils médicaux et pharmaceutiques. Le cycle de développement produit est le temps qui s’écoule entre la toute première identification du besoin du client jusqu’à ce que le produit soit développé et génère des profits parce que on a quelque chose à vendre. Le développement produit est l’ensemble des processus qui sont à l’œuvre pendant cette période. On peut dire que le développement produit est une course, pas une course où tout le monde part en même temps après le coup de sifflet, mais une course où l'on choisit quand on part. Certaines entreprises savent partir bien avant les autres parce qu’elles peuvent contacter leurs clients plus tôt, ou parce qu’elles prennent des décisions plus rapidement, ou parce qu’elles savent aligner leurs ressources plus rapidement. Plus courte sera la durée du processus de développement (analyse et fabrication), plus il y aura de possibilités d’améliorer le produit.
Peu importe de quel produit il s’agit, la plupart des pratiques de management que l’on doit utiliser, restent valables. Le modèle économique en est un bon exemple, je ne connais aucun produit qui n’en bénéficierait pas.
InfoQFR : Merci. Pouvez-vous nous en dire plus à propos des processus et du flux de travail en développement produit ? Avez-vous des conseils à donner sur comment gérer ce flux de travail ?
Don Reinertsen : (6:33) Quand on veut gérer le flux de travail dans le domaine du développement produit, on rencontre des difficultés très différentes d’une usine de production. En effet, sur une chaîne de production, ce qui circule d’un poste de travail à l’autre sont des objets physiques, on peut les voir, voir leur flux, voir la taille des lots dans le processus. Et donc tout ce qu’on a à faire c’est d’aller dans l’usine pour voir ce qui se passe. En développement produit, le flux c’est de l’information, qui est par essence invisible. Même en allant sur place et en cherchant les niveaux de stock, le flux auquel les stocks s’écoulent, ou encore la taille des lots, on ne voit rien. Et malheureusement, parce que c’est invisible, très peu de personne les ont gérés. Une des premières choses à faire est de montrer que le délai ne s’explique pas parce que les gens travaillent trop lentement, mais plutôt parce que les tâches restent bloquées dans les files d’attente invisibles, entre deux étapes du processus. Il faut rendre le travail visible, et particulièrement les files d’attente, pour commencer à vraiment comprendre le problème de flux.
InfoQFR : Ok donc la première étape est de rendre le travail visible et particulièrement les files d’attente. Que peut-on faire ensuite pour les gérer ?
Don Reinertsen : (8:13) En général, on commence par s’interroger sur la taille des files d’attente et, en utilisant un modèle économique plus un coût du délai adaptés à votre contexte, on peut calculer le coût généré par le temps d’attente. On crée ainsi l’opportunité de choisir entre un coût du délai de, par exemple, 30 jours d’attente, et l’effort pour supprimer ou réduire ce délai. On peut ensuite chercher les changements à faire dans le processus, par exemple peut-être que si j’avais un testeur de plus je pourrais réduire une file d’attente, quel est le coût d’un testeur supplémentaire, pour quelle diminution de coût du délai ? On est maintenant en position de proposer des arbitrages intelligibles par le manager en charge du périmètre : « j’ai besoin de tant d’argent pour tel bénéfice ». L’ordre logique à suivre est d’abord de trouver où sont les files d’attente puis de calculer leur coût, ensuite seulement, on peut commencer à améliorer les choses. Pour ce faire, je dirais que les deux techniques les plus efficaces sont la réduction de la taille des lots et l’utilisation de contraintes sur le travail en cours, souvent appelée systèmes kanban.
InfoQFR : Est-ce que ces deux techniques ont un lien avec votre conseil d’implémenter des boucles de feedback rapide au sein des processus de développement ? Pouvez-vous nous en dire plus ?
Don Reinertsen : (10:02) Dans le domaine du développement produit, l’un des bénéfices les plus importants de la réduction des tailles de lot est l’augmentation de la vitesse des feedbacks au sein d’un processus. Par taille de lot, je veux dire la quantité d’information qui circule en une fois entre deux étapes d’un processus. Les progrès qui ont été fait en automatisation des tests dans le domaine du développement informatique, en sont un bon exemple. Il y a 20 ans, un développeur informatique aurait codé 90 jours de suite avant de transmettre le logiciel aux tests, il aurait donc eu un feedback 90 jours après avoir écrit le code. Aujourd’hui dans les organisations modernes, les développeurs ont un feedback moins de 24 heures après avoir écrit le code. C’est un véritable bon en avant en terme de productivité car si le développeur fait une mauvaise hypothèse en terme de protocole, ou autre, il s’en rendra compte 24 heures après et corrigera. S’il n’a le feedback que 90 jours plus tard, cette mauvaise hypothèse se propagera à d’autres endroits du code et auprès d’autres personnes qui auront développé d’autres fonctionnalités dépendantes. Cet exemple illustre également comment on peut réduire la taille des lots : en réduisant les coûts de transaction. Il y a 20 ans, mettre en place un test pouvait prendre un ou deux jours. Mais il est impossible de tester toutes les 24 heures si la mise en place d’un test prend un jour. Aujourd’hui les progrès réalisés en automatisation de test ont diminué le coût de transaction et permettent de tester par très petits lots.
InfoQFR : Réduire la taille des lots et utiliser des contraintes de travail en cours permettent d’améliorer les choses, notamment parce que cela accélère les boucles de feedback. Que pouvons-nous faire concernant la priorisation des files d’attentes ? Quelles techniques recommendez-vous ? Qu’appelez-vous discipline de gestion des files d’attente (NDLR queuing discipline) ?
Don Reinertsen : (12:14) Par discipline de gestion des files d’attente (NDLR queuing discipline) je fais référence à l’ordre dans lequel on dépile les tâches d’une file d’attente. Une façon de faire classique, et largement utilisée en usine de production, est nommée FIFO, premier entré, premier sorti (NDLR First In First Out). FIFO est une excellente technique pour une chaîne de production car chaque produit doit être identique et cela importe peu l’ordre dans lequel les files d’attente sont dépilées. On ne gagne pas plus d’argent en prenant l’un plutôt que l’autre. Alors que dans le domaine du développement produit, les tâches ont un coût du délai très différent entre elles, on peut avoir un énorme impact économique en choisissant l’une plutôt que l’autre. L’un des exemples les plus simples que je puisse donner est celui des urgences d’un hôpital. Si on décide de gérer les urgences comme on gère une chaîne de production, on prendrait les patients dans l’ordre d’arrivée. Il y a fort à parier que dans cette situation, on n’hésiterait pas à traiter d’« espèce d’idiot » (NDLR en français dans l’interview) celui qui a conçu cela, en effet une attaque cardiaque pourrait parfois être traitée après une simple douleur à l’oreille. Il est beaucoup plus pertinent de prioriser sur la base du coût du délai. Et ainsi de prioriser les tâches avec coût du délai important (crise cardiaque) par rapport à celles avec coût du délai faible (douleur à l’oreille). On peut laisser les délais augmenter sur les tâches qui ont un faible coût du délai, mais surtout pas sur les tâches à coût du délai important ! La force de cette approche, c’est qu’avec la même demande et la même capacité, on obtiendra de biens meilleurs résultats économiques. Il arrive parfois de réduire les coûts du délai d’un facteur de 10 ou de 20. C’est un outil très important en développement produit, alors qu’il n’est absolument pas utilisé en usine de production.
InfoQFR : Merci. En guise de conclusion, pouvez-vous nous parler brièvement du thème de la décentralisation du contrôle ?
Don Reinertsen : (14:56) La décentralisation du contrôle est un thème qui connaît beaucoup d’intéret dans le monde des méthodes Agile, notamment à travers l’auto-organisation des équipes. Mais cette auto-organisation a ses limites, elle fonctionne bien à petite échelle quand les coûts et les bénéfices sont visibles localement par les équipes. Les coûts, les actions ou les efforts réalisés au sein d’une équipe doivent générer un bénéfice perceptible par cette même équipe. Quand on commence à regarder à plus grande échelle, les coûts et les bénéfices ne seront peut-être pas au sein de la même équipe, par exemple quelqu’un demandera l’ajout d’une fonctionnalité à un logiciel qui aidera une autre équipe que celle qui le développe. Il faut trouver des mécanismes pour encourager la résolution des problèmes à grande échelle, au-delà de l’auto-organisation promue par le mouvement Agile. C’est de ces mécanismes dont je parle sous le thème de la décentralisation du contrôle : augmenter la prise d’initiatives au niveau des équipes même (car c’est la seule solution pour être vraiment réactif) tout en gardant un alignement très fort au niveau de l’ensemble de l’organisation. J’utilise principalement des idées issues du domaine militaire pour illustrer ce thème et montrer comment développer un contrôle décentralisé.
InfoQFR : Merci beaucoup Don, avez-vous deux mots à ajouter à cet interview ?
Don Reinertsen : (16:41) Oui, mes deux mots sont « merci beaucoup » (NDLR en français dans le texte).
--
alexis8nicolas
Le mercredi 8 janvier 2014 14:21:39 UTC+1, alexis8nicolas a écrit :
Dimitri BAELI
On peut avoir le détail de l'explication sur le " coût du délai " levé par Nicolas Mereaux ?
Merci
Dimitri Baeli
christophe Keromen
On peut avoir le détail de l'explication sur le " coût du délai " levé par Nicolas Mereaux ?
Nicolas Mereaux
euh attention delay et delai n'ont pas le même sens en anglais ou en français, le premier a le sens de retard (oxford dictionary), l'autre a le sens de temps supplémentaire (larousse)
Sens 2 Sursis, temps supplémentaire. Synonyme prolongation Anglais extension (of deadline)
ça me parait quand même acceptable, i on remplace délai par les synonymes fournis par le dico ci-dessus : cout du "temps supplémentaire", cout de "la prolongation"
on parle bien de ça, cf. lexique
Christophe Keromen (33) 06 62 55 27 20
Accompagnement lean-agile
Certifié ScrumAlliance Scrum Professional
Co-auteur du "Petit guide de management lean à l’usage des équipes agiles"
www.ckti.com
christophe Keromen
@Christophe : comment aurais-tu formulé cette phrase pour être plus proche de ce que dit Don : "Dans ce domaine, c’est quand le produit ne change pas du tout qu’on peut gagner de l’argent."
De plus j'ai ajouté un court lexique comme proposé par Christophe, je le copie colle ici et n'hésitez pas à proposer des améliorations !
- **variabilité** : en développement produit, la matière première avec laquelle on travaille est l’information, or elle peut être très volatile. Les processus de développement produit doivent donc être efficaces en présence de variabilité.
- **coût du délai** : différence entre le profit d’un produit sur toute sa durée de vie si il était disponible maintenant et ce même profit si le produit n’est disponible que plus tard.
- **modèle économique** : définition de la valeur attendue par l’organisation, par exemple le profit, et sa variation dans le temps.
- **files d’attente** : accumulation de tâche entre deux étapes d’un processus.
- **taille des lots** : quantité d’information qui circule en une fois entre deux étapes d’un processus.
- **contraintes sur le travail en cours** : limiter la quantité de travail en cours soit de manière statique (systèmes kanban) soit de manière dynamique.
- **discipline de gestion des files d’attente** : ordre dans lequel on dépile les tâches d’une file d’attente.
- **décentralisation du contrôle** : augmenter la prise d’initiatives au niveau des équipes même, tout en gardant un alignement très fort au niveau de l’ensemble de l’organisation.
Dimitri BAELI
L'article est maintenant publié sur InfoQ. Merci a tous, et bravo Alexis !
http://www.infoq.com/fr/articles/interview_don_reinerstsen_lkfr_2013
Dimitri Baeli