Appliquer le principe du « pièce à pièce » au développement informatique permet de réduire les délais de façon très conséquente. La preuve par l’exemple…

Une équipe composée d’une dizaine de personnes est chargée de 4 applications utilisées dans des points de vente.

La problématique de l’équipe ? Respecter les dates de livraison

Le principal souci de l’équipe est qu’elle ne parvient pas à livrer tous ses projets d’évolution à la date initialement prévue.

Elle est organisée de la façon suivante : les analystes ont pour habitude de spécifier l’ensemble des évolutions d’une application pour chaque nouvelle version dans un document qu’ils transmettent ensuite aux développeurs, qui à leur tour vont tout développer et transmettre l’ensemble du soft à une équipe de tests qui va vérifier la conformité du développement par rapports aux besoins clients. L’ensemble des étapes prend en moyenne 4 mois, depuis le « go » jusqu’à la livraison pour mise en production.

Suite à un atelier de trois jours qui les sensibilise à l’intérêt de la production « pièce à pièce »*, les membres de l’équipe décident de procéder autrement et de tester une stratégie différente à l’occasion d’un nouveau projet impactant fortement l’ensemble des quatre applications.

Une fois que le besoin utilisateur est relativement stable, les analystes identifient les différents impacts sur les applications. Mais plutôt que d’envoyer aux développeurs un document unique par application contenant l’ensemble des modifications – comme ils le font habituellement – ils découpent les évolutions en « work packages ». Ils spécifient un à un ces « work packages » et les envoient au fil de l’eau aux développeurs. Ainsi au lieu d’avoir 4 gros documents, les développeurs en reçoivent 23 petits. De la même façon, dès qu’un développeur finalise un « work package », il informe l’équipe de tests qui va tout de suite dérouler le « test case » approprié et signaler à l’équipe de développement les éventuelles anomalies. Un flash meeting quotidien autour d’un management visuel permet de tenir informés tous les membres de l’équipe de l’avancement des « work packages » et des éventuels problèmes rencontrés par chacun.

Quel est l’impact de cette nouvelle façon de travailler ?

Cette stratégie a permis de lisser la charge de travail de chacun. En effet les développeurs ont reçu leurs premiers documents d’analyses dès la deuxième semaine du projet, ce qui représente un mois d’avance sur les délais habituels. Ayant pu commencer à développer plus tôt, ils ont ainsi évité une plus forte charge de travail à l’approche de la date de livraison. De la même façon, cela a permis aux analystes de ressentir moins de stress puisqu’ils ont pu eux aussi lisser la livraison de leurs spécifications. Ils ont notamment choisi de commencer par quelques « work packages » simples à spécifier afin d’alimenter tout de suite les équipes de développement.

L’autre avantage de cette stratégie, c’est que les évolutions des besoins utilisateurs qui sont arrivées durant la phase de développement ont pu être prises en compte plus facilement puisqu’elles n’impactaient qu’un nombre limité de « work packages » et non l’ensemble de l’application.

L’équipe a ainsi pour la première fois réussi à livrer une nouvelle version deux semaines avant la date initialement prévue, tout en prenant en compte des évolutions de besoin au cours de la phase de développement.

*Le pièce à pièce est l’un des fondamentaux de la production Lean.  Livrer au rythme du client aussi.