ALM : Les cordonniers sont les plus mal chaussés

L’ALM (Application Lifecycle Management) dénomme des solutions du marché qui ont l’ambition de tout gérer : expression de besoin, spécification, code, tests, traçabilité entre tous ces aspects. J’approche l’ALM avec un postulat simple :

Les projets sont des entités organisationelles qui ont chacune besoin de son propre SI

Partant de là, je vois un parallèle (un peu abstrait) à faire entre :

• informatiser une entité organisationnelle (par exemple la direction commerciale / turbine à qui on fournit une série d’applications, plus ou moins liées, pour se gérer)
• informatiser un projet de développement informatique (fournir à un projet une série d’application, plus ou moins liées, pour se gérer)

Une sensation de déja vu, comme le chat noir dans Matrix.

Des échanges récents chez mon client actuel m’ont replongé dans mon passé. J’avais, à la demande d’un autre client, essayé d’utiliser Caliber RM (un outil de gestion d’exigence) pour outiller la traçabilité de bout en bout des projets (y compris stocker des risques ou des liens vers des cas de tests). Là, on aimerait utiliser la suite Atlassian (wiki confluence + gestionnaire de tickets jira) pour gérer tout, les scénarios de tests, etc…

Les objets métier d’un projet informatique

Un projet informatique (un minimum complexe) gère des objets « métier » : user story, backlog, scénarios de test, rapports d’exécution de test, bugs, … Il y a des principes d’associations entre ces objets, d’où la fameuse traçabilité : être par exemple capable de pouvoir dire qu’il n’y a plus aucun bug portant sur cette user story. Etre capable de dire que toutes les user stories de la release ont été testées (ça s’appelle chercher des trous dans la matrice de traçabilité).

La charrue avant les boeufs.

Sur un projet informatique, on commence par réfléchir au besoin, recenser les story, etc… Pourquoi ne pas faire pareil ? Commencer par recenser les user story de notre SI projet ?

En tant que développeur, je peux de manière transparente associer un commit à une user story et ou à un bug.

En tant que scrum master, je peux obtenir un rapport d’avancement des tests d’acceptance par le business.

En tant qu’ingénieur qualité, je peux obtenir un rapport d’exécution des tests automatisés et manuels pour chaque version

Etc…

Intégration entre les outils

A chaque fois, on se perd dans les détails de tel ou tel outil. Comme un projet se perdrait dans les détails d’intégration ou de flux entre outils.

Dans l’idéal, il faudrait une combinaison miracle d’outils, chacun étant accessible par service web, en consultation, en modification. Chacun étant capable d’accéder à d’autres outils par service web ( par exemple pour pouvoir sélectionner une user story dans le backlog afin de l’associer à un cas de test).

Mais n’est-ce pas un leurre ? Est-ce qu’on ne peut pas se contenter d’un champ en saisie libre où l’on mettrait l’identifiant de la story. C’est moins bien (risque d’erreur contrôlé a postériori), mais ça peut être tolérable dans certains cas.

Où est le product owner capable d’arbitrer ça ?

Alors il y a les grands comptes qui peuvent se permettre des suites (hors de prix). Et les autres qui bricolent, comme ils peuvent.

Spécifique

J’ai une tendance à préconiser du spécifique à chaque projet, par opposition à une « cellule transverse » qui spécifierait et mettrait en place la solution d’ALM pour tout le monde. Dans mon ancien client, j’avais connu des projets hardware + software, d’autres que software, d’autres de type EAI, bref des configurations qui faisaient que le besoin du projet en solution d’ALM était différent d’un projet à l’autre. Comme on aurait des besoins métiers différents entre des directions métier différentes. Quoi d’étonnant ?

Ca implique surtout d’articuler le besoin

• Les besoins au niveau de la direction des études : le product owner du SI des projets est le responsable outil/méthodes
• Le paramétrage de la solution retenu / les besoins spécifiques pour chaque projet : le product owner du SI du projet est le chef de projet/scrum master, avec arbitrages avec le responsable outil/méthodes (souci de capitalisation, d’homogénéité, …)

Rétrospectivement, mon ancien client avait adopté une démarche sensée au niveau entreprise

Analyser le besoin (outils/méthodes + représentants des Chefs de projet/Scrum Master)

1. Prioriser le besoin (idem)
2. Sélection des outils sur des critères comme l’ouverture par API, la facilité à synchroniser les données de référence, etc…
3. Faire un pilote, avec une première intégration des outils (avec le CP comme product owner)
4. Faire un deuxième pilote, avec une intégration différente (idem)
5. Capitaliser
6. Animer une communauté
7. Intégrer un budget « SI du projet » dans chaque budget de chaque projet.