Approche simple − impact élevé

Le marché des solutions logicielles est en mutation permanente. Ce qui est nouveau aujourd’hui peut déjà être obsolète demain. Pour réussir, une collaboration étroite et fluide est nécessaire entre le Développement et les unités d’affaires. Deux exemples en illustrent le fonctionnement pratique.

Les unités Business, Développement et Exploitation (en anglais Business, Development et Operations) sont les piliers du développement de produits moderne au sein de l’IT. L’approche BizDevOps cherche à combler les lacunes entre le Business et l’IT.

Le modèle DevOps s’est établi il y a un peu plus de dix ans, pour réduire le fossé qui existait entre le Développement et l’Exploitation du côté de l’IT. L’objectif était de rendre publics le plus tôt possible les nouveaux logiciels et les nouvelles fonctionnalités.

Mais souvent, une difficulté subsistait: les exigences posées par les unités d’affaires étaient généralement établies sans concertation avec l’IT. Les idées et besoins des unités spécialisées ne coïncidaient souvent pas avec les possibilités informatiques. Par conséquent, le temps gagné grâce à la meilleure collaboration entre l’Exploitation et le Développement était à nouveau perdu.

C’est pour répondre à ce défi que le modèle BizDevOps a été élaboré. Le Business, qui inclut les unités spécialisées et la Vente, se rapproche de l’IT afin de traduire les visions entrepreneuriales en solutions numériques. J’aimerais illustrer par deux exemples pratiques les effets concrets de cette approche.

Tout d’abord, un exemple de ce qu’il ne faut pas faire: il y a quelques années, alors que je venais de reprendre la fonction de Product Owner, mon bureau s’est vite retrouvé encombré de demandes soumises par d’autres gestionnaires de produits et que j’étais censé intégrer dans mon application. Les gestionnaires de produits m’ont assuré que ces demandes avaient été spécifiées et travaillées pendant plusieurs mois et ne devaient donc pas présenter de problème. Tout inexpérimenté que j’étais, j’ai accepté de les intégrer dans notre planification des sprints.

Pour faire court, ces demandes ont été vertement critiquées par les personnes présentes. La spécification mise sur la table était totalement dépourvue de sens car les requérants ne connaissaient pas nos systèmes. Il ne restait plus qu’à replanifier entièrement le tout avec les développeurs, afin d’aboutir à quelque chose de productif.

Et maintenant, un exemple d’une bonne manière de procéder − j’ai tiré des leçons de cette première expérience dans ma nouvelle fonction. Depuis ce jour, avant d’intégrer une demande dans la planification des sprints, je la soumets à nos développeurs, quelle que soit sa portée. De plus, je n’aborde pas ces entretiens avec une demande déjà ficelée. La plupart du temps, il s’agit plutôt d’une vision de ce que la demande peut satisfaire. Cela fait gagner du temps et de l’argent, et évite de nombreuses tensions. Une réunion idéale ne dure qu’une dizaine de minutes: je décris brièvement la demande et propose une solution, les développeurs s’en emparent immédiatement mais émettent leurs propres suggestions pour atteindre l’objectif de façon plus simple et efficace.

À mon sens, BizDevOps est une approche, ou un guide, que l’on peut mettre en place dans le cadre de différents modèles agiles. Qu’il s’agisse de Lean, SAFe, Scrum ou Kanban, la seule chose qui compte, c’est que toutes les parties soient impliquées dans la recherche de solutions.