09 – Backlogs spécialisés et structuration applicative

Un backlog unique ne permet pas de spécifier opérationnellement les préoccupations fonctionnelles, technologiques, organisationnelles, et encore moins stratégiques. Dans un mode devenu Volatile Incertain Complexe Ambigu, les backlogs se spécialisent puis deviennent reconfigurables et extensibles.

L’expression du besoin en mode « agile » (traitée dans le cartouche « 07 - Modèle de structuration des exigences »), se synthétise dans la notion de Backlog. Pour certains, le backlog se limite à un « parking » dans lequel se stockeront toutes les préoccupations en attente d’un éventuel traitement. Cette vision n’est pas fausse, mais simpliste quelle que soit l’envergure du développement. Dans cette 9ème chronique, les diverses formes de « Backlog » - qui traiteront de la construction ou des évolutions d’un système d’information adaptatif - ne s’appliquent pas uniquement aux projets majeurs lancés par de grandes organisations - même si en l’occurrence ces aspects deviennent dans leur cas incontournables. En effet, la nécessité vitale d’atteindre un objectif optimal en matière de différenciation concurrentielle nécessite désormais d’intégrer dans la construction de tous les développements les apports d’une « Continuous Exploration » (figure suivante) ; comme nous le recommande SAFe « Assume variability Préserve options » !

Trois phases structurantes pour un développement Agile

Une approche Agile n’interdit pas, si nécessaire, de se doter d’une vue d'ensemble en préalable au développement. Cette étape de formalisation - conceptuellement oubliée - se nomme désormais pudiquement Sprint 0. À partir d’une vision globale du problème à traiter, selon les projets, les méthodes Agiles comportent généralement trois phases d’importance variable (Cadrage, Conception, Réalisation), dans lesquelles se développent de réelles itérations (à l’exception de Scrum qui ne précise rien sur ces sujets). Même s’il s’avère encore lourdement détaillé dans les grandes organisations, le phasage du Sprint 0 se présente à minima structurellement ainsi :

Cadrage : Expression des besoins et exploration des solutions. Cette étape représente environ 20% du projet (en investissement, mais généralement beaucoup plus en délai).
Conception : Architecture fonctionnelle et aspects technologiques. Outre les équipes techniques, le métier et certains utilisateurs significatifs s’impliquent dans cette étape de conception globale. Ces acteurs du changement participent à l’affinage des classes d’exigences, puis valident le premier niveau de prototype présentant l’ergonomie applicative. Cette étape représente environ 20% du projet.
Solution : Acquisition ou construction de la solution. L’équipe Produit (Feature team) réalise l’application incrément par incrément. Le métier, assisté de l’utilisateur final, participe toujours activement aux spécifications détaillées et à la validation du développement. Cette étape représente environ 50 % du projet. Les recettes « en continu » font l’objet d’une « validation permanente ». Leur pertinence se confirme ensuite lors d’une démonstration à la fin de chaque Sprint. Cette intégration respecte la vision DevOps du « Continuous delivery ». Au final il s’agit donc d’officialiser une livraison opérationnelle dans une optique SAFe de « Release on demand ». Cette activité « permanente », incluse désormais dans la Solution et se finalisant dans la notion de « Rally Test Game » (cartouche 12), représente environ 10 % du projet.

Note : Dans les petits projets menés avec Scrum et/ou XP, il est fréquent que conception et développement fusionnent dans une seule phase, à l’exception des activités d’Exploration et de Planning qui les précèdent.

Un seul backlog s’avère totalement insuffisant

A l’aune d’une compréhension de la réelle complexité des développements, il s’avère préférable opérationnellement de considérer trois types de backlogs d’intérêt différent (justifiés par des usages spécifiques) :

Structuration hiérarchique du besoin - comme SAFe depuis 2011 le recommande dans ses visions Stratégiques, Financières, ou Organisationnelles des Portfolio, Larges solutions, Trains et Équipes.
Décomposition en « Classes d’exigences », traitées par des ressources distinctes - comme le prévoyait en 2007 PUMA Essentiel.
Niveau d’approfondissement de la solution - comme proposé formellement par PUMA en son temps, puis ensuite structurellement par SAFe.

De même que la carte n’est pas le territoire, le modèle n’est pas la préoccupation. En revanche, une carte fiable reste un outil pertinent pour se rendre d’un endroit à un autre, et c’est à l’identique que la simplification offerte par un modèle adapté permettra d’appréhender la complexité d’une préoccupation. Les modèles d’hier sont devenus les backlogs d’aujourd’hui (figure suivante).

Actuellement, le principe hiérarchiquement structurant de SAFe s’avère indispensable aux développements majeurs mais manque d’une vision décomposée et spécialisée. En partant du bas de la « SAFe big picture », au niveau Team ou même Program, des backlogs fonctionnels et NFRs (Non Functional Requirements) peuvent suffirent. À partir des niveaux supérieurs (au niveau Large Solution et Portfolio), une spécialisation des backlogs basée sur la notion de classes d’exigences devient généralement indispensable (figure précédente).

Note : Ces backlogs spécialisés doivent être distincts car ce ne sont pas les mêmes ressources qui auront la responsabilité de réalisation et de mise en œuvre (d’où les 4 classes). Cet aspect n’est pas pris en compte par les frameworks actuels. En clair, il manque encore dans ce cas « un barreau à l’échelle ». On est loin de la vision simpliste de Scrum avec sa petite équipe qui va produire quelques fonctionnalités.

Tout est backlog et tout est Kanban

Dans la résolution des problématiques - même complexes – du développement d’applications, une approche structurellement simplifiée de l’expression des exigences résoudra bien des difficultés de formalisation. De même, la structuration d’un backlog en classes d’exigences, puis son découpage en fonction de la spécialisation des ressources qu’il engagera s’avère une nécessité absolue. Disposer d’un backlog « fonctionnel » (généralement une vision applicative) est une chose utile, mais cela ne doit pas masquer les aspects techniques et organisationnels (parfois de localisation géographique) sans oublier ceux réservés à la résolution de contraintes diverses - dont par exemple l’adaptation des ressources humaines impliquées dans tous les aspects d’une évolution souvent déstabilisante. Au-delà de cette vision holistique, opérationnellement, tout est Backlog (vision) puis l’accepté devient Kanban (roadmap).

Formalisation étendue des exigences

Pour une approche Agile légère et novatrice, mais consciente de la complexité fréquente des systèmes à automatiser, il est nécessaire de se référer à un document unique organisé en 4 classes d’exigences. À chaque réelle itération dans le sprint 0, et pour chaque préoccupation, ce document recueille toutes les informations sur les besoins et contraintes ; lesquels seront exprimés de plus en plus précisément jusqu’à être compréhensibles et évaluables par l’équipe de développement. La structure d’expression se présente ainsi : aspects Stratégie et Contraintes, aspects Fonctionnels, aspects Technologiques, aspects Organisationnels. Les quatre « aspects » ainsi distingués s’explorent dans l’ordre fondamental précisé. En revanche, et toute la complexité relative de l’opération - ainsi que sa pertinence - résident dans ce principe, ils doivent, afin de prendre en compte la globalité des interrelations et des dépendances induites, être appréhendés globalement et de manière aussi bien itérative qu’adaptative (figure suivante).

Afin de respecter le principe du « nécessaire et suffisant », ces descriptions (deux figures plus avant) s’organisent en 4 niveaux de profondeur itérative d’exploration : Vision, Cadrage, Objectif, Fonctionnalité. Cette formalisation - représentative d’une forme réellement Agile de l’expression des Exigences - se concrétise dans un simple modèle de document structuré par quatre classes de préoccupations. Les besoins sont, dans un premier temps, considérés comme des « Visions », pour devenir par affinement des « Cadrages », puis des « Objectifs » et finalement des « Fonctionnalités » distinctes. Ce dernier niveau de détail, incluant éventuellement les interfaces et leurs redevabilités, devient un point crucial en termes d’identification et de granularité dans le cadre d’une architecture orientée services. Dans les petits projets, un seul niveau du type « étape d’exploration de XP » peut s’avérer suffisant.

SWOT, la vision stratégique

Se situant bien en amont de la WSJF (priorisation opérationnelle traitée dans le cartouche 08), le SWOT fait partie des outils stratégiques qui contribuent à l'étude de la pertinence et de la cohérence d'une action. L’analyse ou matrice SWOT vise à préciser les objectifs de l'entreprise ou du projet puis à identifier les facteurs internes et externes favorables et défavorables à la réalisation de ces objectifs.

Strengths (Forces) : caractéristiques offrant un avantage concurrentiel.
Weaknesses (Faiblesses) : caractéristiques désavantageuses.
Opportunities (Opportunités) : éléments pertinents à exploiter.
Threats (Menaces) : éléments susceptibles de nuire à l'entreprise ou au projet.

Des objectifs opérationnels SMART

Note (source Wikipédia) : Les forces et les faiblesses sont souvent d'ordre interne, tandis que les opportunités et les menaces se concentrent généralement sur l'environnement extérieur.

En plus des éléments priorisés constitutifs des backlogs, la notion « d’objectif » basée sur la « Valeur ajoutée » n’est pas spécifiquement liée à l’Agile ou au Lean. Par contre, sa généralisation représente un intérêt particulier dans ces approches. En effet, quel est le meilleur moyen de constater non pas la production de fonctionnalités, mais l’atteinte d’un résultat concret pour évaluer la pertinence d’un travail souvent relativement abstrait ou ne permettant pas de générer immédiatement un feedback précis en termes de KPI. D’où l’intérêt des objectifs respectant la formulation « SMART » : spécifiques, complets, et ne requérant pas de détails supplémentaires pour être compris. Par ailleurs mesurables, ils permettent de vérifier l’état d’avancement du produit. Réalisables et acceptés comme tel, ces engagements suscitent rarement de remise en question. L’acronyme SMART, représente dans notre contexte un ensemble de critères :

S - Spécifique : non ambigu
M - Mesurable : quantifié ou qualifié
A - Acceptable : assez ambitieux pour susciter de l’intérêt
R - Réaliste : réalisable, faisable
T - Temporellement défini : quand ?

Code unique, documentation unique

Le backlog, cette nouvelle forme particulière de la spécification, remplace une partie des anciennes exigences documentaires. Un autre aspect non négligeable de l’agilité en matière de construction de système d’information consiste en une documentation technique unique de type « un seul code, donc un seul document ». La meilleure des informations de maintenance corrective comme évolutive se trouve naturellement à l’endroit où la fonctionnalité doit être modifiée si besoin est. Le principe, à l’extrême de son efficience, positionne donc l’ensemble de la documentation (à l’exception de celle dédiée à l’utilisateur et aux aspects organisationnels ou financiers) directement dans le fichier code source. Au final, c’est en fonction d’un contexte non négociable que le professionnel se laissera écarter de cette forme agile de documentation. Ainsi s’impose encore notre besoin de tout formaliser histoire de justifier - on se demande bien quoi - puisqu’au final le seul juge de l’efficience sera le BurnUp chart d’avancement du produit.

Priorisation des backlogs

Il est tout aussi courant de penser que seul le périmètre offre une variable d’ajustement. Quel délire ! Certaines applications ne supportent pas ce type d’amputation, et dans ce cas budget et/ou délai deviendront naturellement des variables. Pire, reporter dans un deuxième « lot » ou « développement » ce que l’on n’a pas réussi à faire dans le premier, ne serait-ce pas aussi jouer avec ces contraintes pour obtenir un périmètre cohérent ? Le vrai apport de l’agilité dans ce domaine de la planification fut la systématisation de la notion de priorisation par la valeur et de MVP. Cela se réalisait déjà naturellement avant mais manquait de justification théorique. En matière de variable d’ajustement, la première méthode incrémentale et itérative à la source du mouvement Agile, le RAD de James Martin en 1991, proposait le Design to cost ou le Time to market. À partir de 1994, j’introduisais le principe « Adaptatif » ainsi que les notions de « Qualité applicative » et de « Visibilité du projet » outillées dans Évaluateur RAD (Wikipédia).

Note : soyons clair, l’abêtissante simplicité du « périmètre variable » trouve ses limites dans la réalité d’une justification économique, et surtout, de nos jours, dans les exigences du MVP où la notion de « Minimum Viable » prend toute sa raison d’être.

En 1999, l’ensemble de ces avancées furent publiées par le Gartner Group dans un rapport de mise en œuvre. En 2008, afin de maîtriser opérationnellement le principe de modification majeure ou d’abandon de fonctionnalité produite ou en cours de production (interdit car non géré par Scrum), PUMA introduisait les fondements de la « Métrique des changements » qui fera l’objet du cartouche 11 de novembre. Conclusion, il y aura toujours la distinction entre performance projet et qualité produite (dont les intérêts sont le plus souvent antagonistes, surtout lorsque l’exécution implique des prestataires externes travaillant en mode forfait).

Note concernant Scrum : Si vous pensez vraiment qu’une méthode simpliste basée sur un lotissement élémentaire baptisé « sprint » va vous guider pour développer une application complexe ou transverse, vous allez avoir quelques soucis. Si vos dirigeants pensent dans le même temps que la montée à l’échelle de cette méthode se limitant à la Roue de Deming renommée « rétrospective » va rendre leur organisation agile, ce sont eux qui auront des soucis. Depuis l’arrivée de SAFe, il est enfin admis que le professionnalisme est de retour. Encore faudra-t-il former sérieusement les participants et non se contenter d’un mapping des nouveaux titres sur les anciennes fonctions.

Architecture Agile, une gestion d’interactions

Je ne comptais pas aborder le sujet de l’Architecture d’entreprise agile dans Continuous Sprint 0. Mais sinon, où le faire, à moins de lancer une nouvelle série de communications en 2020. D’ailleurs mon échec à faire passer ce message en 2007 avec PUMA Entreprise aurait dû me vacciner des tentatives de promouvoir des idées à ce sujet. Peu importe les causes (mauvais côté de l’Atlantique, absence de réseau personnel, désintérêt d’universitaires trop éloignés des réalités d’entreprise… ?) Choisissez vous-même. En revanche le résultat est là, rien de concret en termes de réelle « Architecture » - ou plutôt d’interrelations entre les éléments d’une architecture simple mais suffisante pour générer des communications déterminantes en termes d’agilité. Celle-ci, à l’échelle de l’organisation, nécessite une vision modélisée guide du processus de transformation. L’opération globale ne peut être la simple somme de plusieurs préoccupations (même supportée par des applications) mais doit s’appuyer - opérationnellement - sur le triptyque conceptuel de la figure suivante et sur la maîtrise opérationnelle de son architecture sommaire (MI = Modèle d’Interactions).

Conclusion

Les backlogs présentés se situent à la convergence des problématiques d’évolution de l’entreprise. Ils permettent l’instanciation rationnelle et consensuelle d’une expression des besoins généralement complexifiée par l’implication de multiples prescripteurs dans la prise en compte de multiples classes d’exigences : métier, technologie, contraintes légales, écologiques, économiques et humaines, etc. Si leur mise en oeuvre induit des gains significatifs comme la réduction des délais de production et l’accroissement de la qualité applicative, le plus important demeure l’impact organisationnel où leur utilisation dépasse notablement la simple production d’une solution, aussi performante ou utile soit-elle. La définition et la mise en œuvre de ces « perspectives » s’avèrent alors de puissants moyens d’enrichissement des modes de travail. En transformant les relations interpersonnelles conflictuelles en échanges et en partages de la responsabilité, ils facilitent la fluidification des communications ainsi que l’adoption du savoir-être coopératif. Entre la notion de conception émergente et de livraison en itération permanente d’une part, et les contraintes des cycles incrémentaux d’autre part, ils se focalisent sur la fourniture précoce d’un résultat tangible testable de type « fonctionnalité logicielle approuvée par le métier et l’utilisateur ». Pour sa part, SAFe, se présente et se constate comme un framework de développement de produit ou de service (et non une méthode). SAFe détermine le quand, le comment et avec qui, mais pas le pourquoi. Selon moi, Dean Leffingwell avait certainement ses raisons en se limitant ainsi (comme Ken Schwaber avec Scrum). Le contenu du Sprint 0, le chaînon manquant des approches agiles actuelles s’avère un piège de flou et d’enlisante complexité dans lequel les vendeurs de méthode ont tout à perdre sans y avoir en contrepartie grand-chose à gagner.

Au final, même si paraîtra abstrait en l’occurrence, je me remémore un dialogue du film Matrix, et plus particulièrement la réflexion du Mérovingien à Néo, lequel cherche la clé d’une porte dont il ne connaît pas la destination, ni ce quelle dissimule, ni même pourquoi il doit la franchir : « Le choix n'est rien qu'une illusion, créée pour séparer ceux qui ont le pouvoir de ceux qui ne l'ont pas … Notre seul espoir consiste à comprendre le Pourquoi. Pourquoi est la vraie source de pouvoir. Sans lui vous êtes paralysé. Et c'est ainsi que vous venez vers moi, sans Pourquoi, donc sans pouvoir. Rien qu'un maillon de la chaîne. » Cette vision sensibilise à ce que devrait être la raison de la recherche actuelle d’agilité, et surtout nous ouvre les yeux sur un autre « trou noir de la méthode ». Ce lieu qui serait pourtant susceptible de nous offrir le « Pourquoi » de notre quête, se nomme « Architecture d’Entreprise Agile », un concept éminemment opérationnel qui plonge au cœur de l’anticipation rationnelle de l’évolution en nous offrant la clé du « pourquoi ». Les backlogs recensent alors le « comment », et plus tard les Kanbans précisent le « quand » et le « qui ».

____________________

Pour info, si l’histoire de l’agilité et les raisons de ma proposition Continuous Sprint 0 vous intéressent, voici mon avis sur le sujet dans un interview de Martine Otter Présidente d’honneur d’ADELI, une « société savante » dont les membres œuvrent depuis des décennies comme « Explorateurs des espaces numériques »