LIVRE BLANC Commppr re ennddre tll ’’iinntté érrêêt …agilitealechelledesgrandesentreprises.eu/wp...Blanc-Agile-SI-v1.2.pdf · manager en mode agile une DSI de plusieurs

Livre Blanc « L’agilité pour les grandes entreprises Françaises » Page 1

LIVRE BLANC

CCoommpprreennddrree ll’’iinnttéérrêêtt ddee ll’’aaggiilliittéé

ppoouurr lleess ggrraannddeess eennttrreepprriisseess

FFrraannççaaiisseess

eett rrééuussssiirr ssaa mmiissee eenn œœuuvvrree

Rédigé par Stéphane BADREAU, Angel GARCIA et Didier JOLIOT


TABLE DES MATIERES 1 INTRODUCTION ............................................................................................................ 3

1.1 L’agilité, une nécessité ............................................................................................ 3

1.2 Pourquoi un Livre Blanc ? ....................................................................................... 3

1.3 Grille de lecture du document .................................................................................. 5

2 UNE ORGANISATION GLOBALE A ADOPTER ............................................................ 7

2.1 Comprendre l’agilité dans la cartographie des pratiques ......................................... 7

2.2 Agilité et Achats ...................................................................................................... 8

2.3 Agilité et Ressources Humaines .............................................................................. 9

2.4 Agilité et Métiers .................................................................................................... 10

2.5 Agilité et Directions des Systèmes d’Information ................................................... 10

2.6 Aspects relationnels de l’agilité ............................................................................. 14

3 UNE ORGANISATION DETAILLEE ............................................................................. 17

3.1 Les rôles dans une équipe agile ............................................................................ 17

3.2 Les rôles liés à la stratégie et les démarches agiles .............................................. 18

4 UN PILOTAGE DE LA DSI PAR LES BACKLOGS ....................................................... 21

4.1 Principes Kanban .................................................................................................. 21

4.2 Le backlog des équipes et les user stories ............................................................ 21

4.3 Le backlog programme (“backlog produit”) ............................................................ 23

4.4 Le backlog stratégique des epics .......................................................................... 24

4.5 Outillage des backlogs : quelques remarques ....................................................... 24

5 UN CYCLE COURT DE DEVELOPPEMENT ............................................................... 27

5.1 Objectifs d’un cycle court ...................................................................................... 27

5.2 Les meilleures pratiques en cycle en V ................................................................. 27

5.3 Point de vue des démarches agiles ....................................................................... 32

5.4 Analyse des deux cycles ....................................................................................... 37

5.5 Comparaison entre cycle long (en V) et cycle court (agile) .................................... 43

5.6 Agilité et tests : une nouvelle organisation ............................................................. 44

5.7 Remarques sur l’outillage ...................................................................................... 46

6 CONCLUSION ............................................................................................................. 49


1 INTRODUCTION

1.1 L’agilité, une nécessité

L’économie nécessite d’innover et d’aller de plus en plus vite dans un environnement mondialisé, où la compétitivité est le maître mot du management. L’arrivée du digital dans les entreprises implique une remise en cause des principes et pratiques en place depuis des décennies.

Il faut ainsi imaginer de nouvelles démarches pour concevoir les “bons produits”, ceux qui se distingueront par la pertinence de leurs fonctionnalités et leur adéquation aux besoins changeants des utilisateurs.

Il faut aussi réagir vite face aux attentes du marché et faire en sorte que les applications informatiques, qui sous-tendent les relations de l’entreprise avec son écosystème (clients, collaborateurs, partenaires, institutionnels …) soient mises en production plus rapidement, de manière périodique, petit à petit, en amélioration constante, selon les priorités du moment.

A de rares exceptions (cas des applications simples pouvant être réalisées en un seul bloc, dans un temps très limité et avec des besoins stables), finis les développements en “cycle en cascade” ou en “cycle en V”, il faut penser désormais développements itératifs et incrémentaux !

En conséquence, les effets tunnels souvent constatés dans les approches classiques (cf. les études du Standish Group) deviennent exclus et indésirables.

Si, pour diverses raisons, un projet devait être abandonné, alors les investissements en jeu seraient limités à ceux engagés depuis la dernière itération ou version du produit, tandis que l’application aura déjà servi.

On comprend par ces quelques rappels, énoncés de manière succincte, tout l’intérêt d’une approche agile.

1.2 Pourquoi un Livre Blanc ? Si l’objectif est clair (le pourquoi ?), la démarche (le comment ?) elle, n’est pas aisée à établir.

• Comme au tout début d’un cycle de l’évolution informatique, nous avons de multiples démarches agiles proposées et disponibles, il convient de les comprendre au mieux pour les mettre en œuvre ou pour s’en inspirer. Il convient aussi de rappeler, pour les opérationnels, les dernières approches du cycle traditionnel (dit cycle en V) pour comprendre les écarts avec l’approche agile, quitte à rectifier les idées fausses et s’engager sur les véritables pistes d’améliorations et de réformes.

De plus, et contrairement à ce qui peut être annoncé ou pensé ici ou là, on ne peut manager en mode agile une DSI de plusieurs dizaines de projets comme on manage un seul projet. Une pratique agile comme SCRUM (la plus connue au niveau d’une équipe de projet) ne suffit pas à elle seule ! Il y a des effets induits dits “à l’échelle” qui doivent être pris en considération.

En d’autres termes les relations inter-projets doivent elles-mêmes être fluidifiées et prises en compte dans le modèle que nous devons adopter. De quelle manière, en effet, peut-on faire mieux communiquer les équipes entre elles et maîtriser les adhérences entre les projets ?


• Les standards d’organisation interne pour des projets SI agiles (comme Scrum1) suffisent-ils pour que l’entreprise soit agile ? N’y-a-t-il pas une nécessité de disposer d’une vision plus globale (a minima au niveau des Directions Métiers de l’entreprise) pour que la DSI puisse rendre le service escompté ?

Autre point, si on regarde de plus près la mise en place de l’agilité dans une entreprise : elle repose, non seulement sur des principes organisationnels, mais aussi sur les valeurs fondatrices.

Comment ces valeurs, éthiquement souhaitables, peuvent-elles être vraiment partagées et pratiquées dans un contexte social tendu et une pression économique de plus en plus forte ? Quels sont les impacts de ces valeurs au niveau des échanges entre les clients, les fournisseurs et les sous-traitants ? Comment s’exprime encore le rôle du management ? Que veut dire aujourd’hui gouverner ? Quelles sont les réelles responsabilités et les devoirs des équipes ?

• Que veut dire encore “piloter” dans un cadre agile ? Que doit-on suivre et comment ? L’approche prédictive est abandonnée au profit d’une approche adaptative.

• A quoi cela sert-il de faire des itérations si globalement aucune amélioration de productivité n’est constatée ? Les avancées à la manière de “petits pas” peuvent devenir trop petites pour le temps d’incrément imparti (quelques semaines) … qu’elles en seront ridicules. Ou bien les itérations seront bien là … mais dans un rythme incompatible avec les principes du développement agile. On revient en effet dans ce cas à des versions nécessitant plusieurs mois de développement avant une mise en production... et ce n’est pas du tout ce qu’on vise !

A la lumière de ces réflexions, nous avons décidé de rédiger ce Livre Blanc afin d’aborder le sujet de l’agilité à l’échelle de l’entreprise en apportant notre vision de consultants expérimentés et proches du terrain. Ce document doit aider en particulier les grands comptes à opérer leur transformation vers un mode agile … Quelques soient nos parcours (venus du monde de l’industrie ou du système d’information, du cycle en V ou plongés directement dans un contexte agile) et nos compétences (stratégie, organisation, méthode, direction de projet, DSI …) nous y croyons… pourvu d’en éclairer sereinement et pédagogiquement le chemin !

Pour terminer cette introduction, nous pensons qu’un “Livre Blanc” s’est avéré la forme la plus adéquate pour faire écho à deux préoccupations :

• D’une part montrer que la France possède, sur le sujet organisationnel et méthodologique, à côté des initiatives numériques déjà présentes (French Tech, etc.), une expérience, des savoir-faire, et des pratiques qui méritent d’être mises en avant. Le droit de manifester n’est pas l’apanage d’une nation si puissante soit-elle et, même si nous reconnaissons très naturellement la contribution américaine et l’apport historique du Manifeste Agile2 pour le développement de logiciels (2001) !

• D’autre part montrer que la France, et plus particulièrement les grands comptes, ne

1 Scrum : https://www.scrumalliance.org/ 2 Manifeste Agile : http://agilemanifesto.org/iso/fr/manifesto.html

https://www.scrumalliance.org/

http://agilemanifesto.org/iso/fr/manifesto.html


peut se laisser décrocher en restant en retrait de ce mouvement, en étant trop timorée, en vivant sur ses acquis et sans se soucier de la compétitivité de ses entreprises …

Nous espérons que ce document leur fasse comprendre l’urgence de la situation et le besoin d’être accompagnés dans cette transformation… tout en respectant certaines de leurs cultures et de leurs spécificités.

1.3 Grille de lecture du document Ce Livre Blanc est composé des chapitres suivants :

➢ Un premier chapitre sur Une organisation globale à adopter. Il s’agit de choisir un “cadre de référence de l’agilité à l’échelle” à l’image du “Scaled Agile Framework”3, afin de bénéficier d’un appui au démarrage de la transformation.

➢ Un deuxième chapitre sur Une organisation détaillée. Le but de ce chapitre est d’expliquer quelques détails qui nous semblent utiles à connaître et de fournir des recommandations d’adaptation, par exemple sur les rôles à mettre en place. C’est aussi le moyen d’aborder concrètement les aspects relationnels, tant au niveau des individus dans l’entreprise que des entités internes de l’entreprise, ou encore entre partenaires. Il nous faut indiquer les dangers et les pièges à éviter (dès les aspects contractuels entre un client et un fournisseur ou sous-traitant, par exemple) et, bien entendu, préciser les grandes directives à adopter.

➢ Un troisième chapitre sur Un pilotage de la DSI par les backlogs4. C’est un chapitre destiné à insister sur la rigueur du pilotage dans l’agilité puisqu’il se situe à tous les niveaux et doit donner des vues cohérentes. Dans ce chapitre, nous identifierons également les objets à gérer et les orientations impératives des tableaux de bord à produire.

➢ Un quatrième chapitre sur Un Cycle court de développement. Ce dernier chapitre vise à indiquer les changements dans le cycle de vie traditionnel. Il couvre donc les différentes phases depuis l’émergence d’une “idée” (in fine un ou plusieurs projets) jusqu’à la mise en production d’une des itérations agiles. Il précise globalement les documents à produire et leur contenu, avec un triple objectif :

o Etre agile, donc productif o Répondre aux contraintes de maintenabilité et de qualité de service pour la

production o Expliquer les concepts nouveaux au regard des anciens, et les évolutions

apportées au traitement de ces derniers.

Nous nous sommes fixés pour but d’être pragmatique. Ce document doit être vu comme un guide et non pas comme un cours, être compact et non pas précis dans l’énoncé des solutions (d’autant que chaque entreprise aura des spécificités de mises en place à étudier). Dès lors :

3 Scaled Agile Framework : http://www.scaledagileframework.com/ 4 Backlog : liste priorisée des choses à faire dans un projet agile

http://www.scaledagileframework.com/


• Les deux premiers chapitres sont à lire par tous, mais sont essentiellement destinés aux DSI pour convaincre leurs Directions Générales des grandes lignes du changement à réaliser et, vis-à-vis de leurs équipes, pour leur indiquer la voie à suivre. Leur niveau de lecture différent permet de s’adapter au public visé.

• Le chapitre sur le pilotage de projet est destiné à tous les opérationnels de la DSI. Il explique l’organisation à mettre en place. Il sera aussi utile à ceux qui seront en charge de la coordination, la qualité et la communication (disons pour l’instant les “directeurs de projet” et “chefs de projet MOA/MOE” … même si ces termes bien connus sont remplacés par de nouveaux termes dans un contexte agile !).

• Le dernier chapitre est à lire par les équipes dans leur globalité et les éventuels coachs internes et/ou externes qui se chargent de l’accompagnement, du support et de la formation “méthodologique”.


2 UNE ORGANISATION GLOBALE A ADOPTER

2.1 Comprendre l’agilité dans la cartographie des pratiques

Pour saisir le sens de nos recommandations, il convient de repositionner les démarches agiles dans l’univers des pratiques, et de percevoir les frontières et les adhérences pouvant exister entre elles.

Pour cela, nous pouvons nous aider du schéma suivant qui situe différentes approches selon leurs objectifs.

Méthodes et gestion d’un produit digital

Ce Livre Blanc vise à rendre les solutions digitales plus agiles, c’est-à-dire la capacité à mettre à disposition au plus vite les applications auprès des utilisateurs, en répondant à leurs besoins prioritaires :

• En visant à la fois l’objectif de “Trouver le bon produit” (celui qui répond aux réels besoins des utilisateurs et qui satisfait leurs exigences) et l’objectif de “Bien le construire”. La recherche du bon produit doit faire partie intégrante de la préoccupation d’une démarche agile (et non pas se limiter à construire un logiciel rapidement … et où 80% des fonctions seront peu ou pas utilisées et où les clients ne trouveront pas les fonctions les plus attendues …).

• En s’intéressant à la DSI dans ses activités, mais aussi aux Directions qui l’aident nécessairement en lui donnant les moyens de bien construire le produit.


Nous reviendrons sur les différentes pratiques dans le dernier chapitre consacré au “cycle court”.

Regardons, pour le moment, les aspects de l’agilité qui touchent les Directions, hors tout aspect méthodologique, en rappelant l’importance de leur organisation.

2.2 Agilité et Achats La Direction des achats, s’occupant notamment de prestations informatiques, s’appuie traditionnellement, hormis la demande de régie, sur des forfaits. Ces forfaits sont bâtis après une phase d’avant-projet qui permet de cerner le besoin dans ses grandes lignes.

Les forfaits se fondent alors sur la production de livrables du cycle en V et les paiements sont généralement conditionnés par leur délai de livraison (on prévoit notamment d’éventuelles pénalités de retard).

En agilité, les productions vont se faire à un rythme plus rapide et leur contenu sera mis à jour régulièrement. La vérité à un instant “t”, où on prévoit que dans quelques mois on pourra réaliser et livrer telle fonctionnalité, peut être remise en cause par les changements de priorité et les évolutions de périmètre.

Les Directions des achats qui n’intègrent pas ce nouveau mode de développement continuent de demander des propositions précises à leurs fournisseurs (par profil, par phase, par grandes fonctions, …), réparties sur plusieurs mois. Cela n’a plus de sens avec l’approche agile.

Les Directions des achats s’appuient aussi sur des contrats classiques qui s’avèrent inadaptés à la philosophie de développement agile puisque les fonctions requises peuvent changer et que les formes de documentation à transmettre peuvent évoluer en fonction de la démarche agile retenue.

Comment doivent évoluer les Directions des achats ? Quelles pistes sont possibles ?

a) Passer d’un mode de défiance à un mode de co-construction

Le cycle en V où vous avez d’un côté le client figeant en principe ses besoins et d’autre part le prestataire qui doit les respecter dans un temps contraint, avec une documentation lourde et imposée, n’est plus d’actualité. Il faut au contraire avoir une documentation plus opérationnelle et plus allégée sur des sujets où le besoin reste à éclaircir, les réponses à évaluer et à corriger en permanence auprès des clients.

L’objectif de concevoir et réaliser un produit qui satisfera le marché est fondamental et non négociable : seul ce résultat importe. L’agilité impose donc de reconsidérer les relations client-fournisseur pour réussir ce pari.

La voie adoptée consiste à admettre que client et fournisseur forment une seule et même équipe. L’équipe accepte le changement et souhaite travailler en courtes itérations. C’est une organisation centrée sur la co-construction et la confiance qu’il faut bâtir.


b) Revoir les modalités contractuelles et aboutir à un contrat de

développement agile

La proposition d’un fournisseur ne peut plus se fonder sur l’engagement à construire des fonctions prédéterminées, puisque l’innovation est le moteur du développement. Dès lors, il faut comprendre que des appels d’offre “agiles” qui demandent encore une réponse intégrant un planning précis n’ont plus de sens !

Les contrats agiles, eux, doivent offrir la possibilité d’être modifiés. Il faut privilégier l’engagement de moyens et partir d’une enveloppe budgétaire consensuelle. Une autre partie financière sera, elle, fonction de la satisfaction du client. Elle prendra ainsi en compte le suivi du déroulement de la prestation. Elle exigera des indicateurs sur le périmètre qui se dévoilera petit à petit. On pourra par exemple mesurer le nombre de user stories5 (sur lesquelles il y a eu consensus et accord sur leur planification) qui ont été effectivement produites ainsi que leur taux de succès (respect ou non par rapport aux sprints prévus, ou encore par rapport, in fine, aux releases annoncées).

c) Accélérer les procédures d’achat

Une DSI en mode agile ne peut pas se permettre d’attendre des moyens humains, matériels et logiciels qui ne viennent pas faute à des procédures et des négociations d’achat trop longues … toute l’activité d’un projet peut alors être bloquée et au point mort. Quelques exemples : achat de serveurs, achat de postes de travail, achat d’outil de test, renforcement d’équipe, négociation avec une web agency, etc.

Dans ce contexte, une vraie réflexion doit être menée pour que les processus de décision et de choix financiers soient réellement productifs :

o Etablissement de contrats cadre o Principes de négociation à temps contraint ou à limite financière déjà fixée o Diversification des choix. Par exemple, au lieu de restreindre les sous-

traitants à quelques grandes sociétés référencées, ouvrir davantage les possibilités aux PME, indépendants… quitte, pour simplifier, à encourager la formation de groupements et d’associations.

2.3 Agilité et Ressources Humaines Lorsque les projets manquent de ressources humaines ou de compétences, le temps d’attente entre la décision de recruter et le recrutement doit être limité, le plus court possible. Or parfois cela tourne au cauchemar et, là encore, l’agilité de la DSI perd tout son sens.

Il est ainsi impératif de mieux maîtriser les procédures d’embauche ou de recrutement interne pour les rendre plus efficaces. Par exemple, en anticipant des besoins en termes de RH, en recherchant des profils polyvalents et pluridisciplinaires, en identifiant les personnes en interne pouvant travailler dans un contexte agile …

5 User Story : Dans les pratiques agiles, une User Story est un récit utilisateur exprimé avec une phrase simple dans le langage de tous les jours permettant de décrire avec suffisamment de précision le contenu d'une fonctionnalité à développer.


2.4 Agilité et Métiers Les Directions Métiers représentent la connaissance de l’entreprise et sont composées de sachants. Les Maîtrises d’Ouvrage (Product Owners agiles) sont des intermédiaires entre les métiers et le reste de l’équipe “technique”, la Maîtrise d’Œuvre (MOE).

Si les Directions Métiers ne sont pas disponibles pour participer aux réunions et répondre aux questions des Product Owners, alors la MOE ne pourra pas commencer ses développements dans de bonnes conditions.

L’agilité requiert donc de, non seulement planifier les ressources SI (au sens large), mais aussi les ressources métiers (ceux au cœur des processus de l’entreprise, sans oublier ceux exerçant des activités de support ; les juristes ou les risques par exemple).

Nous verrons également que les Directions Métiers seront beaucoup plus sollicitées dans une approche agile, comparé à une approche classique.

2.5 Agilité et Directions des Systèmes d’Information Pour les Directions des Systèmes d’Information, deux niveaux sont à considérer :

a) Intégrer à l’agilité les relations entre “développeurs” et “opérations”

L’agilité considérée simplement au niveau de l’organisation intra-développeurs ne garantit pas l’agilité globale du projet informatique. Résumer l’agilité par SCRUM, pratique courante de développement agile, est une vue trop réductrice.

Le DevOps6 vise à aligner l'ensemble des équipes du système d'information sur un objectif commun, à commencer par les équipes de développement (Dev) chargées de faire évoluer le système d'information et les opérationnels (Ops) responsables des infrastructures (exploitants, administrateurs système, réseaux, bases de données, etc...).

DevOps est une démarche interne à la DSI et en phase avec l’agilité globale recherchée.

Prenons deux exemples.

o Le plus courant, d’abord, est de considérer au plus tôt, dès le développement, les contraintes de vérification de la non régression. En ce sens les études travaillent pour la qualité de l’exploitation et pour faciliter les travaux de correction.

o Par ailleurs, si les environnements de test, extraction ou copie d’une partie de l’environnement de production, ne sont pas prêts, alors les tests de développement ne pourront pas se faire ou être efficaces. Les études se tournent donc naturellement vers la production pour mieux connaître les

6 Devops est la concaténation des trois premières lettres du mot anglais development (développement) et de l'abréviation usuelle ops du mot anglais operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs contradictoires.


données et les performances constatées en production.

b) Choisir un “cadre d’agilité à l’échelle” pour la DSI

Plutôt que de partir d’une feuille blanche, la mise en place de l’agilité, visant essentiellement à bien gérer et construire des “fonctions” appréhendées par les métiers et s’exerçant dans le contexte d’une grande DSI, peut s’inspirer des recommandations de standards méthodologiques existants (“frameworks”). Même s’ils sont récents et en constante amélioration… ils ont le mérite d’exister, évitent de “tâtonner”, proposent un vocabulaire commun et sont reconnus à l’international.

Deux “frameworks” de l’agilité à l’échelle semblent s’imposer aujourd’hui : SAFe (Scaled Agile Framework) et LeSS (Large Scale Scrum). D’autres démarches existent (comme DAD, SoS ou Spotify) mais semblent plus marginales.

SAFe est le plus diffusé en France, notamment par le fait que les formations existent en France (bien qu’avec des supports en anglais) et sont dispensées par des organismes Français. Au niveau international, SAFe occupe 80% du marché (principalement aux US).

SAFe offre un cadre qui met en évidence des “couches organisationnelles” et qui parlent immédiatement aux grandes DSI. On y retrouve en effet :

o la stratégie, portée par une couche “portefeuille des programmes” avec notamment le rôle clé de la Direction, et une couche “flux de valeur” portée par l’architecture d’entreprise,

o l’opérationnel, porté par les programmes qui organisent, coordonnent, font des choix pour plusieurs projets,

o et les “équipes”, en fait les projets informatiques, sans que ce terme soit explicitement utilisé.

Même si ces couches ont des particularités de fonctionnement agiles, elles existent déjà plus ou moins dans les grandes organisations, et SAFe va justement donner des directives et des bonnes pratiques pour les faire fonctionner en interne et de manière fluide avec les autres couches organisationnelles.

LeSS propose un modèle qui est moins explicite mais qui laisse davantage d’initiatives. C’est probablement un cadre intéressant à étudier pour des DSI déjà expérimentées.

Dans la suite de ce Livre Blanc, nous allons privilégier SAFe pour illustrer et comprendre les concepts d’agilité à grande échelle sous-jacents.

Quelques points fondamentaux sur SAFe

S’il faut résumer le framework, disons que “l’agilité à grande échelle” met en évidence les points suivants :

1. Des couches organisationnelles qui reprennent les activités “traditionnelles”

(existant normalement dans les grandes DSI). Ce qui les diffère essentiellement dans leur fonctionnement avec le cycle en V c’est leur dynamique et leur pilotage.


2. Toutes les couches sont impactées par un rythme “agile” de remise en cause

régulier et permanent du programme. Les programmes nouveaux sont ainsi proposés et jugés plus souvent par les autorités en charge de la “stratégie” (Directions, aidées par l’architecture d’entreprise pour les impacts sur le SI). Les programmes définissent ensuite le contenu des “releases”, en prévoyant un rythme régulier et court de livraison (de 10 à 20 semaines). Les projets s’alignent tous, en dernier, sur ce rythme en découpant chaque release en “sprints” (de 2 à 4 semaines, et de 5 sprints). Cela se fait par une cérémonie de SAFe appelée “PI Planning” (en général sur 2 jours maximum, en présentiel).

3. Sur le fond, nous trouvons relativement peu de différence sur l’étude stratégique

des dossiers avec les bonnes pratiques déjà existantes, hormis (liste non exhaustive mais soulignant les différences fondamentales) :

- Les budgets (on estime et challenge des programmes et non pas des projets d’équipe)

- Les estimations elles-mêmes (méthodes nouvelles) - Une priorité entre programmes qui remet en avant une discipline pourtant

ancienne : l’analyse de la valeur métier.

Pour le découpage des programmes en “releases”, on utilise la notion de “features” (des buts qui se définissent à travers des situations métiers précisant l’utilisation des fonctionnalités). Enfin pour le développement des “features” en plusieurs sprints, les équipes utilisent le concept de “user story”. On raconte donc des histoires utilisateur, avec des possibilités d’usage ayant un vrai sens métier. Chaque user story pourra être développée et testée dans un sprint donné. L’incrément de produit, résultat de l’intégration de plusieurs user stories terminées pour la release, fera l’objet d’une démonstration.

4. Tout le défi de l’agilité consiste à tenir les délais et le périmètre d’un sprint car tout

grain de sable vient perturber les prévisions. Le pilotage doit donc être extrêmement plus précis qu’en cycle en V. Pour ce faire, chaque responsable au niveau d’une couche organisationnelle doit tenir à jour un “backlog” (une liste d’items priorisés correspondant à la vision du SI pour le niveau considéré) en cohérence avec les autres backlogs. Ceux-ci doivent à la fois être simples et montrer visuellement les éléments à développer et leur état d’avancement.

5. Le framework SAFe définit de nombreux rôles. Citons en particulier :

- le Business Owner (BO) qui est le représentant de la Direction Métier impulsant les orientations pour le développement,

- le responsable OPS, dénommé “Manager d’Agile Release Train” (mise en production et déploiement du Programme - les wagons du train symbolisant les projets des différentes équipes),

- le Product Manager (PM) qui orchestre le programme, - le Product Owner (PO) qui est en quelque sorte le responsable MOA …

faisant partie de l’équipe. - le Scrum Master (SM) qui est, en principe, un facilitateur pour la mise en

œuvre du framework vis-à-vis de l’équipe, il n’est pas un “chef”.


6. Du point de vue de la vie du programme, un certain nombre de rituels agiles

s’installent aux différents niveaux (PI Planning, et, pour l’équipe, ceux de SCRUM : les rétrospectives, les démonstrations, les daily scrum meetings …).

Mise en place de l’agilité à grande échelle : cas d’un déploiement SAFe

La démarche que nous préconisons est inspirée des recommandations générales et des retours d’expérience rencontrés en France.

Dans un premier temps, la DSI doit faire le choix de mettre en œuvre SAFe sur un périmètre de programme significatif, ni trop grand (le “nombre de Dunbar” explique qu’un programme ne peut dépasser 150 personnes), ni trop petit (au moins 3 équipes de 10 personnes). Dans l’idéal, nous pensons que l’expérimentation doit toucher entre 80 et 100 personnes (8 à 10 équipes) avant de déployer ce cadre méthodologique sur un périmètre plus large.

La DSI doit s’appuyer sur une démarche interne de gestion du changement en 5 phases se déroulant de manière concomitante :

1. Faire savoir auprès des collaborateurs de la DSI ce qu’est SAFe au moyen de vidéos, d’animations, d’articles de communication, de jeux, …

2. Former l’ensemble des collaborateurs à SAFe, tout d’abord en mettant en place plusieurs coachs internes certifiés (certification SAFe dite “SPC”), un par équipe. Ensuite, en déployant grâce aux coachs la formation “Leading SAFe” auprès des collaborateurs, en complément de formations classiques à SCRUM ou au management agile.

3. Démontrer l’intérêt de SAFe en organisant des retours d’expérience aussi bien sur le programme considéré que sur des études de cas externes.

4. Mettre en œuvre SAFe au-delà du programme pilote. 5. Outiller la mise en oeuvre de SAFe avec une activité d’organisation de moyens

: il faut adapter et automatiser la mise en œuvre de SAFe.

Sur ce dernier point il faut noter que SAFe n’entre pas dans les détails méthodologiques et d’outillage. Il y a donc nécessité d’une réflexion interne sur des sujets comme la réalité des besoins liés aux différents backlogs (ce que nous préciserons au chapitre 4) et la définition du cycle court agile (principes, documentation, degré d’automatisation, etc. dont nous verrons les axes essentiels au chapitre 5).


La démarche peut se schématiser ainsi (source Michel LEVASLOT - Pôle Emploi) :

On notera que le déploiement de SAFe dans une DSI doit être nécessairement opéré avec la collaboration des Métiers, en particulier en associant les “Business Owners” aux “PI Planning”.

2.6 Aspects relationnels de l’agilité Les structures énoncées et les rôles reposent sur... des hommes et des femmes. L’efficience du dispositif d’ensemble, quel que soit l’organisation, les méthodes, les outils, est donc dépendante étroitement de la qualité de leurs relations.

“Les deux choses les plus importantes n’apparaissent pas au bilan de l’entreprise :

sa réputation et ses hommes” Henry Ford

Le Manifeste Agile pour le développement de logiciels qui a unifié plusieurs démarches a bien perçu l’importance de ce point.

En effet, il suffit de lister les 4 valeurs de base de l’approche pour voir que la notion d’équipe est centrale, la collaboration est jugée fondamentale et l’acceptation du changement, liée là encore au comportement humain, est mise en avant.

Quant aux principes retenus pour réussir en agilité, on retiendra parmi les 12 principes énoncés, les suivants :

o Accueillir favorablement le changement o Construire des projets avec des individus motivés o Privilégier la conversation en face-à-face o Faire avancer le projet à un rythme soutenable et constant o Responsabiliser les équipes o Ajuster à intervalles réguliers le comportement de l’équipe et les processus

pour être plus efficace


Nous constatons que ces valeurs doivent être constamment rappelées, autant aux Directions qu’aux équipes opérationnelles.

Les Directions dans les grands comptes, dans leur rôle classique, submergent les équipes de réunions et de reporting. Dans un cadre agile, les itérations étant rapides, les résultats tangibles et démonstratifs, il s’avère que les comités de pilotage doivent être allégés et que les états d’avancement “officiels” doivent reprendre davantage de hauteur et être simplifiés.

Le rôle de la gouvernance change pour plus de stratégie, plus de coordination et plus d’organisation pour aider transversalement les équipes.

Il demeure, toutefois, que diriger, c’est décider. Cela s’applique toujours ! Dans le cas où un programme est en danger, la Direction se doit d’engager rapidement des actions, d’abord de coaching pour apporter le support nécessaire aux équipes, et/ou en demandant de mettre en place les conditions de correction.

Il ne s’agit pas de dire que les équipes sont totalement responsables et que la Direction n’a plus à intervenir. Il ne faut pas en effet culpabiliser à agir dans une situation extrême. La décision n’est pas un acte politiquement incorrect. Cela vaut mieux que de reporter la faute entièrement à l’équipe et de s’en exempter. Les concepts d’entreprise “libérée” ne suppriment pas cette régulation mais préconisent que la décision soit prise par l’équipe elle-même.

“Chaque fois que vous voyez une entreprise qui réussit,

dites-vous que c’est parce qu’un jour quelqu’un a pris une décision courageuse”

Peter Drucker

Les Directions ne doivent plus s’immiscer dans l’évaluation des charges et imposer de nouvelles fonctionnalités encore plus urgentes que celles décidées comme urgentes la semaine précédente. Un rythme d’itération et de remise en cause des priorités est fixé, il faut que chacun s’y tienne.

Les équipes, quant à elles, plébiscitent l’agilité par les avantages indéniables qu’elle leur procure : responsabilisation, motivation, amélioration continue, rythme soutenable …

Cependant, ce n’est pas non plus sans risques pour les aspects relationnels :

• La responsabilisation ne veut pas dire l’anarchie.

D’une part on sait que les équipes doivent avoir une indépendance mais qu’elle ne peut être totale. Il faut donc que les équipes soient conscientes des limites et acceptent les règles du jeu. Par exemple, le changement d’outillage ne peut se faire en un jour, les investissements ont nécessairement un coût …

D’autre part avoir des droits implique aussi d’avoir des devoirs… nous l’oublions trop souvent. Les équipes se doivent d’être transparentes. Il ne s’agit pas d’une posture mais d’une réalité qui, touchant la nature humaine au plus profond de soi, son égo, et ceci peut être difficile à accepter. Les équipes en difficulté devraient faire plus souvent appel à un coach pour les aider, les conseiller, les écouter …


or ce principe de bon sens est refusé par certains se considérant en échec et ayant peur d’être jugés par leur hiérarchie.

• L’euphorie de la responsabilisation et de la motivation ne doit pas conduire à l’aveuglement.

On voit des équipes trop sûres de leurs capacités et de leur vélocité qui les amènent à prendre en compte trop de fonctionnalités dans un sprint … In fine elles ne peuvent tenir leurs engagements et, de plus, tendent vers un rythme non soutenable !

• Les échanges en face à face restent du domaine des bonnes résolutions. Bien vite les mails réapparaissent … en masse.

Il n’est pas rare que la moyenne de lecture de ceux-ci soit de 2h par jour pour un collaborateur, pour peu qu’on ne donne pas les moyens de les contenir (plusieurs techniques se préoccupent de ce problème sociétal). Ceci fait fortement chuter la productivité et submerge les personnes par le nombre important d’informations, souvent parasites, à traiter.

Notons aussi que les équipes SCRUM doivent être théoriquement sur le même plateau. Dans les grandes entreprises, les équipes métiers, les équipes de conception et de développement, les équipes de test, et les entités liées à la production … sont souvent sur des plateaux distincts, et souvent à distance (sur d’autres sites). Le face à face est alors souvent remplacé par des audio ou des visio-conférences, moins efficaces que du présentiel.


3 UNE ORGANISATION DETAILLEE

3.1 Les rôles dans une équipe agile

Décrire le modèle des rôles dans la DSI de son entreprise

Mettre en œuvre une démarche agile à grande échelle comme SAFe n’entraîne pas nécessairement une remise à plat des métiers de la DSI traditionnelle. Souvent les « communautés », qui regroupent les membres des différentes disciplines existantes, ne sont pas remises en cause par l’introduction du nouveau cadre méthodologique, dans la mesure où un framework s’appuie sur des rôles précis, et non sur ces expertises.

Concrètement, vous pouvez élaborer un tableau de correspondance pour préciser quelle communauté peut le plus naturellement occuper un rôle dans l’agilité.

Exemple de tableau de correspondance avec SAFe (source Michel LEVASLOT - Pôle

Emploi)

Adapter le modèle à la DSI de son entreprise

Le rôle de Product Owner est communément défini dans les démarches agiles (SAFe, SCRUM …) comme responsable des choix métiers pour l’équipe et auprès du Product Manager. En ce sens, et contrairement à ce qui peut être dit, ce n’est pas l’extinction du rôle “MOA” cher aux projets Français. Au contraire il s’agit bien de sa reconnaissance internationale ! Le changement est organisationnel. Le “Product Owner” est désormais membre intégré de l’équipe chargée d’un projet de DSI. Cependant son rôle, lui, est conforté.

Ces projets proviendront :

o des Directions Métiers, pour des projets métiers avec une composante fonctionnelle forte, et où les besoins seront exprimés avec des “users stories”,

o et de la DSI pour des projets à connotation plus techniques où il n’y a pas de vraies “user stories” à proprement parlé. Il peut y avoir parallèlement, des évolutions strictement techniques (appelées “enabler stories” dans SAFe).

D’une manière générale, les frameworks laissent libres des choix d’assignation des rôles métiers. Ils rappellent simplement, par exemple, qu’un Product Owner doit avoir

Agile Team

Scrum Master

Product Ow ner

Release Train Engineer

Product Management

System Architect

Release Management

System Team

Production

Rôles “classiques” ⇒

Rôles “agiles” ⇓

IngénieurDéveloppeur Testeur Concepteur Chef de projet ArchitecteRelations

utilisateur


un certain nombre de qualités “techniques” (bonnes connaissances du marché et compétences informatiques de base pour avoir un dialogue avec les équipes projet) et humaines (ex: bonne communication, confiance, courage et autorité).

Toutefois si on prend le cas des Product Owner, et pour respecter le principe agile d’un rôle colocalisé avec les équipes de développement, on peut décider de faire tenir ce rôle par des “business analysts” (dont la compétence métier/organisationnelle est souvent prouvée, mais issus du pôle des MOA traditionnelles), mais aussi des personnes ayant d’autres rôles : des chefs de projets IT ou des concepteurs fonctionnels de la DSI ou des architectes métiers. Mais pour d’autres entreprises, sachant que le sens du business est prépondérant pour ce rôle, il pourra être plus pertinent que ce rôle soit occupé par des personnes provenant directement des Directions Métiers.

De même, pour le rôle de Product Manager. Il peut être pourvu par des responsables fonctionnels de la DSI (sachant néanmoins faire la différence entre besoin et solution). On privilégiera, cependant, des représentants MOA ou venant des Directions Métiers.

3.2 Les rôles liés à la stratégie et les démarches agiles

Les rôles Métiers Le Business Owner, comme nous l’avons dit, est le garant des choix proposés à la Direction. Un “Epic Owner” défend une idée métier, et, une fois validée, suit son avancement. Une “epic” va se retrouver potentiellement répartie sur plusieurs programmes et plusieurs releases. Dans SAFe, on parle à leur propos de “trains” pour expliquer ce découpage d’architecture et la prise en compte progressive des besoins dans le temps (à travers les différents “PI plannings”). Les frameworks, comme SAFe, privilégient l’approche “top down”. La Direction commence par recevoir des epics pour les valider ou non. En cas d’accord, les epics sont décomposées en features. Une feature est prise en compte par un “train” de programme et est réalisée au cours d’une release. Nous sommes donc bien dans une démarche d’analyse système qui va, de manière descendante, des éléments macroscopiques aux éléments plus détaillés. Cette pratique peut paraître déroutante dans certaines grandes entreprises qui veulent mettre en place l’agilité, donc poussant vers une plus grande responsabilisation des équipes. Ce choix d’organisation agile est en effet (et à tort) taxé comme une décision “rétrograde” et (donc pénalisante) car issue de pratiques traditionnelles. N’oublions pas que la gestion de portefeuille de projets peut déjà exister dans des contextes “non agiles”. En fait, comme il y a un travail d’architecture sur plusieurs couches dans SAFe, on voit bien que la Direction traite des décisions stratégiques tandis que les Programmes, puis les équipes par la suite, seront cadrés par les choix faits au niveau supérieur.


Cette démarche leur permettra donc de poser des exigences et des solutions à leur niveau plus local. Par exemple sur le fait de prendre en compte telle ou telle demande de détail, choisir entre telle ou telle option possible de spécification, ou encore de proposer une planification des sprints pour leur réalisation... et cela sans avoir à recourir à une validation très officielle (“comitologie” lourde) de la Direction. Au niveau programme, le Product Manager est bien le plus apte, souvent en toute autonomie par rapport à la Direction, à décider des choix opérationnels, tout en consultant les Product Owners. Il fait toutefois valider, de manière souple, ses décisions essentielles par “son” Business Owner. La Direction doit, non seulement suivre les travaux d’avancement et connaître les choix réalisés, mais continuer à intervenir sur des critères d’engagement financiers importants (un seuil est à fixer), ou si un choix stratégique nécessite son arbitrage (les avantages et inconvénients de scénarios demandent à être challengés). De même le Product Owner gère lui-même les choix fonctionnels, sans attendre les décisions de son Product Manager. Il faut comprendre que si la Direction continue de s’emparer de tous les sujets, stratégiques mais aussi de détail, il n’y aura aucune agilité, et un risque de goulot d’étranglement, voire de perte de temps. Il faut bien reconnaître que sur des choix très précis, les équipes sont davantage pertinentes que les grands décideurs.

Les rôles liés à l’architecture Généralement dans les frameworks agiles, c’est un principe descendant qui s’applique : les nouveaux programmes, les évolutions majeures ou les évolutions internes à un Programme sont étudiées par les architectes sur leur faisabilité, avec les Product Managers (et par-delà avec les Product Owners) pour en apprécier les impacts majeurs. Dans la réalité, parfois, les équipes apportent des évolutions et l’architecture n’est pas prise en compte comme elle le devrait ; elle est absente, elle est sous-estimée, elle arrive trop tard, ou elle se trouve sur le chemin critique. Le rôle des architectes SI (applicatifs et techniques), à notre sens, est donc à reconsidérer pour les rendre plus disponibles, plus audibles quand il s’agit de projets techniques (évolutions de fonctions applicatives à portée technique, évolutions matériels et réseaux). Pour les projets métiers, le backlog géré par le Product Manager, puis par le Product Owner, s’avère souvent l’outil suffisant pour comprendre les enjeux et estimer globalement les charges de développement (activité d’estimation restante, de toute manière, très approximative). La formalisation de l’architecture métier et fonctionnelle peut attendre les phases post-faisabilité et post “PI planning”. Cela n’empêche pas de faire participer les architectes à des réunions afin qu’ils apportent leur point de vue.

Les coachs agiles


Afin d’aider les Product Managers et les Product Owners, les “frameworks” ont prévu des coachs. Ceux-ci sont souvent intégrés aux équipes et leur apprennent essentiellement les pratiques telles que SCRUM. A grande échelle, on s’aperçoit qu’il faut aussi des coachs agiles plus expérimentés pour aider la direction de programmes, faire le lien avec la stratégie et les architectes, rencontrer les Directions RH ou achats, mettre en place le cycle court et les outils associés, aider à estimer les user stories, diffuser par l’exemple les pratiques de spécifications orientées tests, montrer comment obtenir des tests limités mais très efficaces, etc. Le rôle de coach agile devient un rôle vital et moteur auprès de l’organisation en général et des opérationnels en particulier. Pour autant, la condition essentielle pour être un bon coach agile, outre celle qui consiste à être reconnu comme un expert en agilité, c’est d’avoir une expérience crédible dans un contexte grand compte et une appréciation rapide des problématiques et des spécificités de l’agilité à grande échelle. Ceci étant bien plus complexe que dans une start-up d’une dizaine d’individus. Autrement dit, le coach agile dans une grande entreprise ne se résume pas à un rôle de formateur et d’accompagnateur. Le coach doit apporter une vraie valeur dans l’organisation, il construit et pilote attentivement la trajectoire de la transformation.


4 UN PILOTAGE DE LA DSI PAR LES BACKLOGS

4.1 Principes Kanban Un framework agile à grande échelle, nous l’avons vu précédemment avec SAFe, s’appuie sur des “couches d’organisation”. Il intègre également, pour chacune de ces couches, les principes du Lean (pour l’amélioration continue) et du Kanban (un système visuel de gestion des tâches). Le système Kanban (terme japonais désignant une « fiche » ou une « étiquette ») indique quoi produire, quand le produire et en quelle quantité. Kanban permet de suivre l’état d’avancement des éléments à produire au travers des tâches à réaliser, chacune des tâches étant dans un état défini (ex: en attente, en cours, terminée). L'analyse des tâches est consultable par tous les participants du projet, chacun prenant ses tâches depuis une file d'attente (ou “bac à sable”).

4.2 Le backlog des équipes et les user stories Notion de backlog d’équipe

Au niveau le plus bas dans l’organisation, il faut mettre en place le plus rapidement possible, et à la charge de chaque Product Owner, un backlog de user stories, c’est-à-dire un carnet listant les user stories et leurs propriétés. Ce backlog permettra de réaliser des graphiques de suivi (en terminologie agile, on parlera notamment de burn-down chart et de burn-up chart).

Qu’est-ce qu’une user story ? Les démarches agiles introduisent ce concept sans beaucoup expliquer comment il intervient au milieu des vues traditionnelles métier et fonctionnel, ni son incidence sur le pilotage. Une “user story” est une histoire utilisateur contextualisée. Elle se rédige de la manière suivante :

En tant que <acteur>, je souhaite <verbe d’activité> afin de <objectif recherché>.

On notera bien que la user story apporte, par l’objectif qu’elle recherche, une valeur métier, une satisfaction du client dans son utilisation du SI et par rapport à ses besoins. Une user story peut être considérée comme une fonctionnalité (appelée aussi “fonction métier”) et donc un service rendu à “l’utilisateur”. Une fonction métier s’appuie sur un résultat final tangible pour l’utilisateur, pas sur des résultats intermédiaires de “sous-fonctions” internes. Ceci est très important à noter alors que, dans certaines DSI, la user story est vue comme un élément de développement par un seul projet. Il y a là une erreur et une confusion regrettable. Les grandes entreprises ont en effet, par exemple, des référentiels (GRC, Contrats,

https://fr.wikipedia.org/wiki/Analyse_des_t%C3%A2ches


Catalogue des offres, …) qui sont des projets fonctionnels à part entière mais sans valeur métier. Leurs “sous-fonctions” interviennent transversalement dans plusieurs user stories. Comme la user story doit être une vue utilisateur, alors, dans beaucoup de cas, elle est le résultat de plusieurs équipes de développement devant in fine intégrer leurs livrables logiciels. Par exemple, la user story “En tant que directeur d’agence, je souhaite valider la proposition faite à un prospect afin de m’assurer de sa conformité native.” nécessitera plusieurs équipes : la GRC qui détient les données de connaissance client, l’équipe du marketing pour la validation, l’équipe de gestion documentaire pour les documents de support à la vente, la GED pour les documents du prospect qui ont été recueillis, etc... Dès lors :

o soit la fonction métier peut être développée complètement dans un sprint, et il y a concordance entre les 2 notions,

o soit la fonction métier est “plus grande” qu’une user story, et dans ce cas il y a séparation entre les 2 notions (l’une, la user story, n’étant que partie de l’autre, la fonction métier). Cette séparation engendre plusieurs conséquences souvent mal maîtrisées par les équipes lorsqu’elles passent en mode agile.

Stratégies de raffinage d’une fonction métier en user stories Comment identifier les user stories (US) possibles d’une fonction métier exigeant plusieurs sprints ?

a) Une user story doit forcer la contextualisation de la fonction métier, en choisissant un acteur plus précis que la population initiale.

Ex : En tant que client (et non pas prospect), je souhaite consulter mon solde de compte afin de décider de nouvelles opérations. Nous avons trop d’affichages (donc trop de règles à développer). On restreint donc le contexte. “En tant que client PARTICULIER, je souhaite …”

b) Une user story peut aussi se simplifier sur l’activité à mener. Ex1 : “En tant que client particulier, je souhaite consulter mes comptes EPARGNE et …”. Ex 2 : “En tant que client particulier, je souhaite consulter mes comptes EPARGNE sans tri possible et …” En jouant sur les données et/ou sur les options fonctionnelles la user story s’allège.

Dans une nouvelle version (“release”), on peut donc venir compléter une fonction métier existante grâce à une user story qui “l’incrémente” : la user story nouvelle peut s’intégrer à celle existante, les spécificités occupant 20% ou moins de l’ensemble. Il faut donc :

- Suivre la production de la nouvelle user story au sein de l’architecture existante


: intégrer la user story dans la conception existante, la coder, la tester, etc... - … Mais aussi faire des tests de non régression de la fonction, à cause de la (des)

user story (stories) existante(s). Ce travail finit la mise en place d’une nouvelle user story, pas seulement lorsque tous ses tests propres et d’intégration aux autres user stories (tests d’homologation/recette) sont exécutés et corrects.

Il ne faut donc pas confondre ;

- la liste et l’avancement des user stories, - la liste et l’avancement des fonctions métiers à fabriquer.

Sauf à faire autant de fonctionnalités que de user stories, ce qui, dans les grandes entreprises, n’est pas réaliste vu le nombre d’acteurs et d’activités à gérer (dépendantes des types de produits par exemple … donc plusieurs centaines !). En résumé le backlog d’équipe catalogue les user stories et ne doit pas oublier les activités de non régression qui finalisent le travail.

4.3 Le backlog programme (“backlog produit”) A plus grosse maille que les user stories se trouvent les features. Souvent en Français on parle de “cas d’usage” également (notez cette équivalence pour la suite …). Ils sont gérés par les Product Managers de chaque Programme. Ils sont définis avant les PI Planning, qui identifient leurs user stories, par le Product Manager et ses Product Owners, avec la validation du Business Owner. Nous sommes bien dans une approche top-down. Donc les Product Managers doivent créer et maintenir leur “backlog produit” composé de features. Les backlogs des équipes viendront ensuite raffiner celui-ci, chaque feature se décomposant alors en user stories. Le backlog produit doit avoir un management visuel des features au sein des “releases”. C’est une vision opérationnelle qui explique la tactique envisagée par le Programme pour le déployer de manière progressive et régulière. Les features fixent un cadre aux user stories : on dit que les features imposent “un contexte”. Par exemple si “Simuler un crédit pour un client de type PART en agence” est perçue comme une feature, cela implique, sur la simulation, les contraintes suivantes :

- On vise uniquement les “crédits” (et pas une autre famille de produits comme l’épargne par exemple),

- On s’adresse au type de clients “client”, et non aux prospects et aux visiteurs non identifiés venant sur le site,

- Le marché “PART” associé au client est celui des “particuliers” - Le canal de vente est “l’agence”, avec pour acteur le “collaborateur” de la

banque. On s’aperçoit que dans un programme les Product Managers utilisent souvent les mêmes critères pour contextualiser les features. Nous pouvons utiliser le terme de “situations métiers” pour exhiber les choix et vérifier la complétude des features.


“Simuler une offre bancaire” propose ainsi des cas d’usage comme (liste non exhaustive) :

Les features doivent, enfin, être classées selon les “buts” auxquelles elles contribuent : c’est la carte appelée ”impact mapping” d’un programme qui sert principalement pour discuter avec la stratégie. Remarquez que l’identification des buts (nous préférons ce terme à celui d’impact agile qui porte, à notre sens, de la confusion …), avant de les associer aux cas d’usage, revient à construire une liste. Certains parlent du “backlog des buts”.

4.4 Le backlog stratégique des epics C’est le backlog du niveau portefeuille de programme, alimenté par les Epic Owners qui proposent des programmes ou des évolutions majeures de ceux-ci (les “epics”). C’est aussi, souvent à tort, le dernier backlog mis en place… On obtient grâce à lui le “Portefeuille des programmes” (et des projets qui leur sont associés), avec le soutien des architectes qui consolident, organisent et structurent les programmes (notamment les processus métiers et/ou l’architecture fonctionnelle). Son intérêt majeur est de prioriser les demandes à un haut niveau de granularité (“epics”, voire les demandes techniques “enabler stories”). Il faut donc leur associer les attributs qui conviennent. Les démarches agiles, et SAFe en particulier, préconisent souvent pour les epics d’estimer leur priorité par une formule : le WSJF (Weighted Shortest Job First). Ceci dit, la formule, si elle paraît judicieuse sur le plan des paramètres à évaluer, est plus discutable sur certains aspects (pourquoi des sommes de choses très variées et non pas des multiplications ? n’y-a-t-il pas un mélange dangereux ? est-ce utilisable si une epic est en dépendance avec d’autres ?). Quant aux estimations des paramètres eux-mêmes… il n’y a aucune formule magique… des bonnes pratiques et des retours d’expérience uniquement peuvent vous aider ! Vous pouvez aussi, bien entendu, utiliser dans un premier temps les techniques qui ont déjà fait leur preuve, comme par exemple MoSCoW (Must have, Should have, Could have, Won’t have), quitte à essayer le WSJF ensuite.

4.5 Outillage des backlogs : quelques remarques Sans entrer dans un inventaire des outils de gestion des backlogs et de leurs fonctionnalités, nous pouvons donner ici quelques recommandations générales.

Situations métiers du

contexte pour simulerfamille de produits type de client marché canal de vente acteur

S1 Crédits Client PART Agence Collaborateur

S2 Crédits Client PRO Agence Collaborateur

S3 Crédits Client PART Internet Internaute

S4 Crédits Prospect PART Internet Internaute

S5 Epargne Client PART Internet Internaute


Un contenu pertinent plus qu’un problème d’automatisation

L’outillage pour gérer les backlogs peut être une adaptation de vos outils existants ou un investissement dans de nouveaux outils dédiés à cette problématique. Pourtant, à partir de notre expérience, le souci est davantage lié au contenu et à la structure du backlog (point que nous verrons en fin de ce chapitre) plutôt qu’à l’outil proprement dit.

Des cas d’usage identifiés

Les backlogs doivent facilement se raffiner, depuis une epic en cours jusqu’aux user stories (en passant par les features). La cohérence et la traçabilité de contenu doivent être assurées. D’où l’idée d’un outillage unique et centralisé (de type “ALM - Application Lifecycle Management”) pour le pilotage de programme. Les restitutions fournies doivent avoir une haute qualité et personnalisables. En effet elles sont le support de la communication. En ce sens, l’outil Excel partagé qui pouvait sembler suffisant d’un point de vue fonctionnel est abandonné au profit d’outils dont les rapports aux utilisateurs sont plus conviviaux. On peut aussi exporter les données dans un outil de Datavisualisation. Les post-its, ou tout autre support visuel, peuvent bien continuer d’exister au sein des équipes. C’est pratique et rapide !

Un contenu réfléchi pour être exploité

A quoi sert un outil de pilotage de programme ? Les raisons essentielles sont :

- Permettre de comparer les estimations initiales et la réalité concernant l’avancement.

- Fournir à la Direction les réponses quant au déploiement des produits. Concernant les estimations des user stories (puis en cumulant, celles des features dans une release), la démarche fondée sur un sprint 0 de calibrage, et sur une user story de référence pour l’équipe, est pragmatique. Reste que le planning poker pour évaluer une nouvelle user story par rapport à la référence est un pis-aller. Rien n’est moins sûr… il faut faire confiance aux équipes qui apprendront avec le temps (en particulier grâce aux “rétrospectives” qui sont préconisées dans SAFe et qui sont des réunions d’amélioration continue issues du Lean). Pour les questions stratégiques liées au déploiement des produits, il faut dresser le constat qu’elles sont nombreuses et variées. On s’aperçoit qu’une réflexion globale et préliminaire sur les “situations métiers” du programme, et non pas uniquement prise plus tard au cas par cas sur chaque user story, doit exister. Lorsque vous découpez un besoin pour qu’il s’inscrive dans un sprint, c’est une problématique de délai de développement qui vous l’impose, mais vous devez aussi réfléchir au déploiement de la solution. La Direction a en effet des impératifs du genre : “peut-on déployer le produit X sur mobile dans le pays Y ?”. Dans l’énoncé d’une user story, vous avez une réponse à cette question si vous avez associé à la user story les valeurs de produit, de canal, et de pays qui la concerne. Mais cela ne suffit pas. Il faut ainsi :

- tracer les tests en faisant référence à ces paramètres pour s’assurer que la user story souhaitée est bien validée,


- et s’assurer de la non régression, c’est-à-dire du bon fonctionnement des user stories déjà existantes et attachées à la même fonction métier.

Il faut bien retenir que le backlog, pour être pertinent, n’est pas qu’une liste de composants strictement “informatiques”, mais bien une liste de choses à faire dans le cadre du projet. Il doit aussi associer aux items du backlog des attributs métiers pensés globalement, en fonction du programme et des déploiements envisagés qui doivent être flexibles.


5 UN CYCLE COURT DE DEVELOPPEMENT

5.1 Objectifs d’un cycle court

Le cycle court est la démarche agile à utiliser pour “développer” un logiciel, depuis la capture des besoins des utilisateurs jusqu’à la mise en production d’une version du logiciel. Nous voulons fournir ici une réflexion, plutôt destinée aux responsables “méthodes” des grands comptes et aux opérationnels MOA-MOE, afin de montrer les particularités agiles sur ce point et leurs conséquences par rapport au cycle en V traditionnel. En mode agile, il s’agit de :

- Tenir des délais très courts, souvent imposés par les marchés. - Produire un logiciel de qualité. C’est l’un des 12 principes agiles, et donc on ne

peut rechercher des compromis sur ce sujet, bien que des entreprises mal informées invitent à moins de tests et moins de contrôles … Il faut savoir que le terme “flaccid scrum” est utilisé pour identifier une pratique erronée de SCRUM dans laquelle la qualité logicielle est négligée et le produit développé accumule de la “dette technique”.

- Produire une documentation pour que le logiciel soit maintenable, sachant que dans les grandes entreprises les sous-traitants sont nombreux, avec leur propre culture et plongés dans un écosystème complexe.

Comment concilier, ce qui peut être paradoxal, une productivité encore plus forte qu’en cycle en V (effort rendu indispensable en cette période de crise) et les contraintes industrielles ? Nous allons aborder ce chapitre de la façon suivante :

- Rappeler le cadre des développements en cycle en V, en tenant compte des meilleures pratiques existantes, afin de bien apprécier, ensuite, les différences avec les démarches agiles et d’appréhender les chantiers à lancer dans le cadre d’une transformation.

- Décrire les différentes (nombreuses !) recommandations autour de l’agilité. - Comparer les deux approches et mettre en évidence les points communs, les

complémentarités ou les changements à conduire. Nous traiterons les aspects de réflexion et de construction du produit, hors les aspects organisationnels (rôles et valeurs) déjà évoqués précédemment et en reprenant les concepts (ex: user stories) tels qu’ils ont été déjà exposés.

5.2 Les meilleures pratiques en cycle en V Rappels sur le cycle “long” Nous pouvons schématiser le cycle “long” par le processus de développement suivant :

https://fr.wikipedia.org/wiki/Dette_technique


Etude d’Opportunité (EO) Tout projet de construction d’un produit doit démarrer par une étude d’opportunité. L’étude d’opportunité doit permettre de répondre aux questions suivantes (liste non exhaustive) :

- Que veut-on faire comme produit (en quelques mots) ? - Quels sont les enjeux à relever (le POURQUOI) ? - Comment allons-nous savoir objectivement (qualitativement/quantitativement)

s’ils ont été atteints ? Quels sont nos objectifs ? - Pourquoi est-il nécessaire de réaliser le produit ? - Quels risques prenons-nous si le produit n’est pas réalisé ? - Pourquoi est-ce important pour nous ? - Quels sont les impacts sur notre organisation ? - Quelles contraintes avons-nous ? - Qui va bénéficier du produit ?

En sortie, une fiche d’opportunité est présentée au comité de management du Portefeuille de Projets. Les résultats de l’étude doivent permettre de prendre la décision de poursuivre ou non.

Etude de Faisabilité (EF) A ce stade du cycle “long” différents scénarios industriels (partenaires producteurs/distributeurs, choix de progiciels ou non, choix de sous-traitants …) doivent être imaginés et analysés. L’analyse doit porter sur les aspects de gain, coût, impact, délai, RH, … Dans cette phase, un “Cahier des Charges préliminaire” doit être rédigé pour donner les objectifs principaux des utilisateurs du produit (chapitres centrés sur les “cas d’utilisation” de haut niveau), les évaluer et comprendre les grands enjeux à traiter (“buts” pour l’ingénierie des exigences).


Lorsque la décision de construire le produit est prise, il est nécessaire de définir une vision du produit. Cette vision sera l’objectif majeur à atteindre pour le projet. Un macro-planning est associé et calé sur les phases du cycle en V. En sortie de cette phase, nous avons, par conséquent, un Dossier d’EF et la décision de lancer le(s) projet(s) informatique(s) pour construire ou non le produit.

Définition des besoins Cette phase comporte plusieurs étapes :

• L’analyse du besoin qui consiste à révéler et identifier une insatisfaction, une opportunité, un problème ou d’un désir d’un utilisateur en relation avec un environnement. Le terme « besoin » est souvent utilisé dans les projets et ce qu’il représente reste vague. Une autre difficulté réside dans le fait que le besoin peut être mal exprimé ou pas exprimé du tout par les parties prenantes.

• L’expression des besoins proprement dite qui formalise le recueil des besoins, évalue les risques et priorise les besoins identifiés.

- A ce stade, de plus en plus, les projets de cycle en V doivent mettre à jour les processus. C’est un travail de scénarisation jusqu’à un niveau “tâche” (action d’un acteur justifiant sa connexion au SI, donc lui fournissant in fine un résultat métier, et répondant à un ou plusieurs “buts”).

- Les projets utilisent un outil spécialisé de “modélisation d’architecture métier”. En principe, ils commencent par la définition du contexte du système et l’identification des différentes sources d’exigences (les parties prenantes constituant les sources principales).

• La spécification des besoins : Pour chaque tâche identifiée (voire au niveau processus si elles sont communes), les MOA précisent (“élucident”) leurs “exigences” fonctionnelles et non fonctionnelles.

Les normes internationales (IEEE, CMMi, ISO) ont défini le terme exigence et, pour faire simple, distinguent :

• Les «exigences utilisateur» qui traduisent le problème à résoudre, l’opportunité à saisir, le besoin pour un utilisateur : c’est le domaine du problème.

• Et les «exigences système» qui définissent une solution abstraite, c’est le domaine de la solution.

Elles insistent aussi sur le fait que :

• Par définition, une exigence est une « caractéristique observable de l’extérieur d’une entité souhaitée » (Alan Davis). Par conséquent, une exigence n’est pas et ne doit pas être une description d’une solution concrète… on n’ouvre pas la boîte noire !

• Et, d’autre part, une “exigence utilisateur” est exprimée dans le langage de l’utilisateur et doit être reliée aux tâches (elle les détaille d’un point de vue “boîte noire”).

Du point de vue fonctionnel, les MOA restent donc au niveau du processus métier et des “règles métiers”. Les “exigences utilisateur” n’entrent pas dans les détails, mais


leur libellé doit être précis et explicite. Exemple d’exigence de type “règle métier” :

<RM 12>: Pour activer cette tâche, l’acteur doit pouvoir s’identifier préalablement avec un code de sécurité de niveau 2 conformément à notre norme interne. (inutile ici de donner toutes les règles qui en découlent …)

L’élucidation des exigences consiste donc à découvrir, rassembler, comprendre et consolider des informations (à partir des besoins) en vue de documenter les tâches d’utilisation (Front-Office) ou de mise en place (Back-Office) d’un système.

Spécifications Les spécifications générales visent à fournir une vue externe de la solution à développer. Le concept fondamental est la fonction métier (ou “fonctionnalité”, vue des métiers, pas dans le détail de “sous-fonctions”). C’est un regroupement des tâches quasi-similaires. Une fonction métier peut donc être assimilée à un cas d’utilisation (soit une tâche déjà désignée et unique, soit une généralisation de plusieurs tâches faisant l’objet de l’expression des besoins). Le concept de cas d’utilisation (« use case ») est très largement employé dans les organisations. Rappelons que le cas d’utilisation représente un objectif majeur pour un utilisateur d’un produit. L’approche par les cas d’utilisation est très intéressante car elle permet de structurer la documentation des besoins des utilisateurs. Nous pouvons imaginer de construire le plan d’un cahier des charges en appliquant la règle « 1 CU = 1 chapitre du Cahier des Charges ». Les notions de généralisation, d’extension et d’inclusion peuvent être utilisés pour documenter et structurer également l’expression des besoins. Les spécifications détaillées consistent, ensuite, à décrire chaque fonction du point de vue de l’utilisateur. Les MOA précisent les étapes du déroulement d’une séquence d’interactions telles qu’ils les perçoivent et indiquent pour chacune les règles de gestion qui s’appliquent, c’est-à-dire les règles de détail des règles métiers. Souvent les IHM sont identifiées et présentées à ce stade, sans attendre la conception. Exemple de règles de gestion :

RG12-1 : Le <mot de passe> à entrer doit comporter au moins 8 caractères. RG12-2 : Le <mot de passe> doit contenir au moins une lettre majuscule, une minuscule et un chiffre.

On notera que le libellé des règles de gestion (et même les titres des cas d’utilisation ou dans le contenu des règles métiers) doit permettre une compréhension unique, de manière non ambiguë de la documentation et ainsi éviter les mauvaises interprétations. Nous ne recommanderons donc jamais assez d’utiliser un glossaire et un gabarit de rédaction des exigences dans un projet. Le glossaire est un outil très efficace pour lutter contre les aléas d’utilisation du langage naturel. Pour rappel, un glossaire doit contenir a minima des termes et les définitions correspondantes, notamment ceux du


domaine métier. Il peut également contenir des exemples, des synonymes, des illustrations… bref toute information qui permettra de mieux comprendre le terme à définir. Le glossaire doit respecter quelques règles : il doit avoir une structure claire, il doit être unique, partagé, centralisé, accessible et validé, la responsabilité de sa mise à jour doit être établie, l’origine des termes doit être renseignée, son utilisation est obligatoire dans le projet. Le gabarit de rédaction des exigences n’est ni plus ni moins qu’un modèle type de phrase. Il constitue un modèle syntaxique pour une exigence. Remarque : D’un point de vue UML, chaque fonction métier identifiée (cas d’utilisation, simple ou de généralisation / extension / inclusion, suivant l’analyse fonctionnelle déjà réalisée) fait l’objet d’une “spécification de cas d’utilisation”. On retrouve en effet en interne :

• Un et un seul scénario nominal qui enchaîne les étapes “courantes”,

• Plusieurs scénarios alternatifs (de zéro à n) et plusieurs scénarios d’exception (de zéro à m) qui partent des étapes nominales et vont sur des étapes spécifiques (puis reviennent s’il faut vers des étapes nominales).

Les scénarios alternatifs décrivent une manière différente d’atteindre le but du cas d’utilisation, alors que le scénario d’exception décrit un déroulement qui ne permet pas l’atteinte de l’objectif du cas d’utilisation (les cas d’erreur).

Conception Ce sont les choix de construction de l’équipe MOE pour la solution envisagée, au point de vue des traitements (composants ou “webservices” des fonctions métiers) et des données (tables par exemple). Les IHM peuvent être éventuellement complétées ou précisées à ce stade du projet.

Codage et tests unitaires C’est la programmation et le test individuel de chaque composant logiciel.


Tests d’intégration Ce sont des tests MOE qui permettent de vérifier le bon fonctionnement logique entre les composants lorsque ces derniers sont assemblés pour former le logiciel complet. Ils se terminent souvent par des tests qui permettent de vérifier :

• chaque fonction métier avec tous ses composants,

• puis, globalement, la garantie par la MOE de l’ensemble de l’application livrée aux MOA.

Tests de validation Ce sont les tests MOA qui permettent en cycle en V de valider chaque fonction métier du point de vue des exigences utilisateur, puis leur enchaînement dans le projet. Le schéma de certification ISTQB, qui standardise le vocabulaire agile ou métier, propose le terme “tests systèmes”. Ces tests sont préparés par les projets, en s’assurant d’une couverture des exigences fonctionnelles et, à plus haut niveau les processus, pour avoir des conditions / observations documentées dans des cas de test. Ces derniers sont intégrés dans des “plans de test”.

On y trouve aussi des tests de responsabilité MOE couvrant les exigences non fonctionnelles, comme par exemple des tests de portabilité et de performance / charge.

Tests de recette Les tests de recette comportent :

• Des Tests de Bon Fonctionnement (TBF) pour s’assurer que les fonctions métiers fonctionnent correctement dans l’environnement le plus proche de la production.

• Des Tests d’Homologation Fonctionnelle (THF) pour vérifier les fonctions développées dans le cadre du projet avec d’éventuelles fonctions d’autres projets (typiquement ceux de processus en adhérence), ou des tests impossibles à faire précédemment du fait de restrictions techniques des environnements précédents.

• Et des Tests de Non Régression (TNR), alimentés au fur et à mesure du projet par les TBF et, si possible, automatisés.

ISTQB propose le terme “tests d’acceptation” qui leur correspond.

5.3 Point de vue des démarches agiles Nous avons présenté, dans le chapitre 2, les principales démarches qui, en agilité, contribuent à définir le bon produit et à bien le construire.


Reprenons succinctement les idées qu’elles développent, en nous contentant de voir les aspects méthodologiques (en complément aux aspects organisationnels déjà vus).

1. Lean Start-up

Cette démarche, connue par les travaux de E. Ries7, se situe clairement au démarrage d'une activité économique et du lancement d'un produit. Elle met en avant, notamment, la vérification de la validité des concepts. Parmi les conseils que la démarche fournit, on retiendra en effet, essentiellement, pour notre propos, que la création d'une entreprise ne doit pas seulement être pensée dans un bureau. Il faut sortir des stéréotypes et aller à la rencontre des "vrais" clients pour découvrir son marché. Autrement dit, il faut repenser les avant-projets et mettre le client au coeur de la réflexion, avant de lancer des développements agiles, c’est-à-dire itératifs et rapides, permettant l’expérimentation et l’apprentissage progressif, entre autres par des retours utilisateur fréquents.

2. Customer Development

Cette démarche, mise en place par Steve Gary Blank8, insiste surtout sur le fait que le modèle commercial d’une start-up doit être testé dans le monde réel, à travers “un produit minimum viable” (en anglais MVP) pour recueillir les commentaires des premiers clients (rétroaction, parties indésirables) et apporter les modifications nécessaires (fonctionnalités manquantes par exemple).

Le “modèle d’affaire”9 est alors possible et fondé sur les neuf items suivants :

• Partenaires clés

• Activités principales

• Ressources clés

• Propositions de valeur

• Relations clients

• Chaînes

• Segments de clientèle

• Structure des coûts

• Flux de revenus

Régulièrement lorsqu'une hypothèse est trouvée incorrecte, les entrepreneurs peuvent appliquer des stratégies de développement du client pour transformer l'erreur en un “pivot”. En tant que pivot, une hypothèse invalidée exige une stratégie d'apprentissage, et le modèle d'affaires peut être réécrit. Autrement dit, en termes traditionnels, nous dirions qu’il faut revenir sur l’étude d’opportunité pour réorienter le produit, en sondant les clients et en apprenant grâce à eux, par des livraisons de MVP réguliers.

La démarche se prolonge aujourd’hui pour la phase de déploiement (growth hacking).

7 Eric Ries, Lean startup. Adoptez l'innovation continue, Pearson, 2012 8 Steve Gary Blank : Les 4 étapes vers l’épiphanie - Kindle edition, 2013

9 Alexander Osterwalder : Business Model Canvas développé dès 2008 https://www.tuzzit.com/fr/createur/alexander_osterwalder


3. Design Thinking

Le Design Thinking est une démarche d’innovation et de recherche de solutions créatives. Elle est organisée et centrée sur l’humain. Sa particularité est qu’elle peut être déployée avant même qu’un quelconque cahier des charges soit établi, avant même que l’idée d’en établir un ait germée dans les esprits. En réalité avant même que la problématique à résoudre soit identifiée. Le Design Thinking se développe dans les années 70 avec un premier programme à l’Université de Stanford. C’est ensuite le MIT qui publie un premier ouvrage sur le sujet, puis la société IDEO la diffuse à travers le monde. De nombreuses écoles prennent le pas ces dernières années. Ainsi l’Université de Harvard la positionne comme formation prioritaire. Le terme Design emprunté à la langue anglaise précise qu’il s’agit avant tout de conception. La méthode s’inspire de l’approche multidisciplinaire des designers. L’approche prend sa source dans les enjeux stratégiques auxquels elle doit répondre. Par le prototypage, et de manière itérative et expérimentale, elle démultiplie les possibilités quelle confronte à 3 points de vues :

• La désirabilité : ce qui donne envie d’acheter le produit ;

• La faisabilité : ce qui fait qu’il va fonctionner correctement ;

• La viabilité : ce qui va le rendre rentable. Pour, à l’équilibre de ces 3 points de vue, proposer de vivre une nouvelle expérience. Comme le prototypage, l’intérêt des différents acteurs, clients, partenaires, investisseurs,…, est intégré dès le départ. L’approche est largement collaborative pour co-concevoir et avancer dans le projet avec des acteurs qui s’engagent.


Son processus est basé sur 5 phases alternant divergence et convergence : 1. Empathize : pour s’immerger dans l’environnement ; 2. Define : pour définir la problématique de fond à aborder ; 3. Ideate : pour générer des idées et trouver une solution au problème ; 4. Prototype : pour construire et penser la solution avec l’utilisateur ; 5. Test : pour préparer son industrialisation.

Le Design Thinking est donc basé à la fois sur une réflexion profonde multidisciplinaire et sur une approche pragmatique de prototypage. L’approche permet de :

• Se mettre en condition pour être créatif ;

• Innover tout en proposant un cadre structurant qui limite les risques inhérents à l’innovation ;

• Appendre plus des utilisateurs et découvrir des opportunités ;

• Valider de potentielles solutions et résoudre des problèmes ;

• Faire émerger des besoins non identifiés ;

• Tester des solutions au travers des prototypes. Et au final d’améliorer les usages et d’imaginer de nouvelles expériences.

4. UX (Expérience Utilisateur)

La démarche UX préconise de qualifier le résultat (bénéfice) et le ressenti de l'utilisateur (expérience) lors d'une manipulation (utilisation provisoire ou récurrente) d'un objet fonctionnel ou d'une interface homme-machine (via une interface utilisateur) de manière heuristique par un ensemble de facteurs.

Les techniques de recueil de données nécessaires peuvent mélanger :

• La recherche utilisateur (identifier les attentes et les freins cognitifs) ;

• L'étude socio-culturelle (attentes et besoins face à l'environnement concurrentiel et à l'évolution des usages) ;

• La perception consommateur (réception/compréhension des messages, et impact de notoriété) ;

• La performance (données statistiques dynamiques relevées sur le dispositif, conversion) ;

• L'exposition (calendaire, médiatisation ou campagne de push des offres).

UX couvre donc :

• Les avant-projets pour compléter l’évaluation du MVP,

• Le développement itératif en faisant appel à des représentants clients (internes à l’entreprise ou mieux à des clients pilotes),


• Et, bien entendu, lors des déploiements.

5. Pratiques de construction agiles

a) SCRUM

SCRUM est fondé sur la conviction que le développement logiciel est une activité par nature non-déterministe et que l'ensemble des activités de réalisation d'un projet complexe ne peut être anticipé et planifié longtemps à l'avance. SCRUM propose de construire le produit en plusieurs itérations. Chaque version (« release ») nécessite donc plusieurs “sprints”, chacun donnant pour résultat “un incrément de produit”. D’un point de vue méthodologique, on retiendra, pour le cycle court, la nécessité de démonstrations et rétrospectives fréquentes et périodiques.

b) Lean Management Les valeurs agiles vont de pair avec les pratiques qui constituent le Lean Management. Cette dernière démarche est fondée sur “l'amélioration continue” (le Kaizen). Sa variante Lean Software Development reconnaît 7 principes agiles. Cela induit notamment des contraintes sur le cycle court, et principalement le besoin de :

• Evaluer la valeur métier des produits jusqu’aux user stories,

• Intégrer la qualité dès la conception.

c) Extreme Programming (XP) C’est une pratique agile centrée sur la réalisation d’une application informatique. Elle propose aussi des principes de gestion de projet qui ont fait l’objet des chapitres précédents. Retenons, pour notre problématique de construction du produit :

• Une phase d'exploration, avec un client sur site, détermine les scénarios « client » (parcours clients) qui seront fournis pendant cette itération. Chacun doit permettre un incrément court, d’effort soutenable. Les estimations se font par analogie (utilisation du “planning poker”).

• L'équipe transforme les scénarios en éléments à réaliser et en tests fonctionnels.

• Chaque développeur s'attribue des tâches de réalisation et les effectue avec un binôme. Il prévoit notamment une conception simple (centrée sur l’incrément en cours, pas les releases suivantes), un code de qualité, normé par des conventions de nommage, ses propres tests unitaires, avec possibilité de les rejouer lui-même ou par d’autres programmeurs.

• Immédiatement l’évolution d’itération est intégrée dans le produit complet, et lorsque tous les tests fonctionnels sont passés avec succès, si possible en mode automatisé, le produit est livré ; c’est la notion “d’intégration continue”.

https://fr.wikipedia.org/wiki/Kaizen

https://fr.wikipedia.org/wiki/Programmation_en_bin%C3%B4me

https://fr.wikipedia.org/wiki/Programmation_en_bin%C3%B4me


5.4 Analyse des deux cycles

5.4.1.1 Opportunités à saisir

Les avant-projets prennent une place beaucoup plus importante en mode agile que dans le cycle en V où ils sont les parents pauvres des méthodes. La place de l’analyse d’opportunité devient fondamentale avec les applications innovantes et l’organisation produit devient centrée sur l’utilisateur. La faisabilité n’est plus une phase à part entière car l’analyse d’opportunité réclame désormais des livrables qu’il faut faire valider par l’expérience et ainsi apprendre “en marchant”. Nous avons plutôt une phase dite “exploratoire” composée d’étapes itératives, dont le Design Thinking en est l’ossature principale.

5.4.1.2 Features, projets et cas d’usage de haut niveau

En démarche agile, on commence par des cas d’usage de niveau “features”. Ils sont choisis par le Product Manager, avec l’aide des Product Owners. Ce choix de priorisation se fait au niveau programme. Ces choix ne sont pas neutres du point de vue organisationnels. C’est en effet à travers les choix d’architecture réalisés (features métiers - cas d’utilisation de haut niveau, voire features pour des sujets “techniques”) que sont identifiés les projets, en essayant de les rendre les plus indépendants possibles les uns des autres. Par exemple l’UC « Simuler un crédit » sera sélectionné comme feature pour une version de produit. Comme tout UC, la feature possède un libellé très simple qui utilise le modèle de phrase suivant « <verbe> + <complément> ».

5.4.1.3 Approche processus métiers

Les frameworks agiles reconnaissent que l’approche Processus est une aide à la vision stratégique des SI de l’entreprise. Pour autant si les impacts d’une demande de programme ou d’évolution majeure d’un d’entre eux peuvent être appréhendés par de la documentation existante, il n’y a pas à les formaliser tant que les investigations centrées client ne sont pas terminées (au contraire ce serait une perte de temps du fait des changements permanents possibles). De plus les features qui sont ensuite envisagées peuvent aussi suffire à lancer les projets, sans attendre la formalisation précise des processus. Il suffit donc d’une “modélisation agile”, issue de XP. Préconisée par Scott Ambler10 ou Craig Larman11 elle déclare qu’il vaut mieux une documentation qui apporte pour le projet : une modélisation simple à appréhender (pas trop riche en notations pour chaque modèle), multiforme (plusieurs visions du problème : les données, les processus, les

10 Ambler, Scott (2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process. J. Wiley. 11 Larman Craig (2009), Scaling lean and agile development, Adisson Wesley

http://www.ambysoft.com/books/agileModeling.html

http://www.ambysoft.com/books/agileModeling.html


fonctions …), créée en mode participatif pour développer une compréhension commune, plutôt haut niveau (n’entrez pas dans les détails, laissez faire le code pour s’y substituer) mais exacte et cohérente. Il faut mettre fin à une modélisation dite “complète”12, complexe et figée. La documentation des nouveaux processus peut donc être initiée pour préparer le PI Planning, à partir des features sélectionnées (c’est-à-dire priorisées par le Product Manager). Elle servira à la communication pour montrer le périmètre métier de la release concernée et pour discuter des user stories.

5.4.1.4 Cas d’utilisation et user stories

Les features doivent ensuite être décomposées en stories (user stories, mais aussi enabler stories pour les sujets techniques). Celles-ci seront identifiées et réparties par sprint, donc estimées finement et planifiées dans le détail. Le but en agilité est donc de fournir assez vite des user stories comme point de départ des besoins pour le projet, sans perdre de temps à considérer le produit dans son entier et à anticiper sur les user stories repoussées dans une future release.

• Le terme “user story” peut désigner un cas d’utilisation “classique”. Par exemple on peut imaginer, pour reprendre l’exemple précédent, l’histoire utilisateur “simuler un crédit immobilier” pour un conseiller en agence bancaire. Toutefois il faut que le cas d’utilisation proposé puisse être réalisé (développé et testé …) en moins d’un délai de sprint. Ce délai est compris entre 2 semaines et 4 semaines, selon les choix de l’entreprise (sa capacité à faire et son envie de faire). Ce cas est donc possible mais rare.

• La portée d’un cas d’utilisation est cependant souvent plus large que celle d’une user story. Si la user story candidate est donc estimée à plus de temps que le délai de sprint de l’entreprise (cas le plus courant), il faut la “raffiner” en ayant une stratégie appropriée. Le cas d’utilisation initial donne lieu à plusieurs “vraies” user stories… Pour notre exemple, on pourrait avoir besoin d’identifier “simuler un crédit habitat pour un particulier”, “simuler un crédit d’investissement immobilier pour une entreprise”, etc.

Comme nous l’avons dit il existe plusieurs stratégies de raffinage (grooming) pour décomposer un cas d’utilisation en plusieurs user stories. On peut avoir, par exemple : ❖ la user story couvre le périmètre du scénario nominal complet du cas d’utilisation (on rappelle qu’un scénario de cas d’utilisation documente les différentes manières d’atteindre l’objectif du cas d’utilisation, typiquement en contextualisant simplement ses données d’entrée). Dans l’exemple “simuler un crédit habitat pour un particulier” c’est bien ce principe qui est choisi. L’utilisateur a bien une simulation de crédit comme résultat, mais uniquement s’il remplit les critères énoncés. ❖ la user story couvre le périmètre de quelques étapes d’un scénario ou d’une variante ou d’une extension de scénario (restriction de fonctionnalités ; par exemple une simulation sans possibilité d’impression)

12 à l'exclusion de certains domaines comme l'embarqué ou des systèmes critiques où la modélisation permet de vérifier et générer directement du code exécutable et exploitable.


❖ La user story couvre le périmètre d’un scénario non nominal (alternatif ou d’exception). Ex : simulation d’un crédit immobilier pour un PART non conforme ou non capable.

5.4.1.5 User stories et exigences

Dans une approche agile, il y a toujours des besoins à satisfaire et donc des exigences à élucider. Au regard du cas d’utilisation initial fourni par un Product Manager (“feature”), chaque user story issue du raffinage pourra être considérée soit comme une exigence de haut niveau, soit comme une technique d’élucidation. Chercher les user stories c’est donc débuter l’élucidation des exigences, même si le terme “exigence” n’apparaît (malheureusement !) que très rarement dans les démarches agiles. Dès ce stade, l’agilité insiste sur un point majeur : on fera d’abord l’essentiel, puis, si on a le temps et le budget, les cas particuliers. C’est le concept de “frugalité” qui s’applique aux user stories puis à leurs détails (on pourra ainsi faire d’abord une user story simple avant de la complexifier, par exemple en ajoutant des règles de contrôle).

5.4.1.6 Description d’une user story et exigences internes (règles)

Comment décrire alors une user story ? Il suffit de dire, dans un premier temps, que l’IHM doit respecter les exigences vues dans le maquettage (on fait alors référence à une pièce jointe pour voir la page web maquettée) pour signifier que les règles de surface (champ obligatoire ou non, format …) doivent être implémentées. De manière plus générale, les règles “évidentes” seront prises en compte par les MOE et documentées directement par le code. Il n’y a plus nécessité pour les MOA de les rédiger. La communication directe entre Product Owner et développeurs, au sein de la même équipe, doit permettre de diminuer la charge de documentation. L’intensité de l’activité d’ingénierie des exigences durant les spécifications générales, puis détaillée, et leur durée sont donc plus faibles. Les acteurs MOE de l’équipe sont responsabilisés puisque seule la documentation du code et les maquettes d’écran sont, en agilité, jugées suffisantes pour décrire ces règles de gestion dites “simples”.


5.4.1.7 Règles de gestion et agilité

Que dire maintenant des Règles de Gestion (RG), qui détaillent, elles, les “vraies” règles métiers (celles qui nécessitent une compétence de Product Owner) ? Elles doivent être énoncées en langage naturel, certes, mais en respectant une grammaire qui va permettre l’automatisation du test. C’est l’approche BDD (Behaviour-Driven Development) mise en avant dans des démarches agiles. Une RG “spécifiée orientée test” aura une forme générale distinguant conditions et observations, les informations en jeu (pour la recherche des données de test), et les logiques internes (ET/OU) permettant de générer facilement et méthodiquement (notion de couverture fonctionnelle des RG) les tests à partir d’une règle. Ce sera par exemple une grammaire permettant aux règles de gestion d’être interprétées par un testeur lors des tests systèmes (dédiés aux validations des Product Owner). Exemple montrant l’importance des alternatives (OU) et l’identification des données métiers.

Pour un <client> ayant un compte bancaire -- acteur ET le <solde initial du compte> est positif --- fin des pré-conditions ET le <client> retire une <somme de retrait> sur son compte --- saisie 1 ET ( (la <somme de retrait> est inférieure OU égale

au <solde initial du compte>) -- contrôle 1 OU la <somme de retrait> est inférieure à <solde du compte> + <découvert autorisé>) ) -- contrôle 2

Alors le <solde final de compte> doit être <solde initial> - <somme de retrait>

Il faut aussi savoir qu’un tel langage permet aussi de vérifier la complétude entre elles des RG rédigées, au lieu d’attendre les tests pour s’en apercevoir ! Le TDD (Test Driven Development) est une préconisation dérivée de XP et qui recommande de préparer aussi la recette de la user story en fin de spécification détaillée. On s’appuie sur la rédaction de règles “haut niveau” de la user story, qui analysent les résultats métiers obtenus (et rien qu’eux), et en considérant le libellé de la user story. On stipulera chaque règle “haut niveau” en langage formalisé (reprenant cette fois les user stories, leurs situations métiers et leurs résultats) ou en langage Gherkin, langages pseudo-naturels qui mériteraient d’être normalisés. Exemple Gherkin sur la user story “retirer de l’argent” pour un client en DAB :

Etant donné que j'ai un compte bancaire

Et que le solde de mon compte est de <soldeInitial> euros

Quand je retire <montant> euros sur mon compte

Alors mon solde doit être de <soldeFinal> euros


5.4.1.8 User story et fonction métier

Toute user story (US) suit un cycle de vie ; elle commence par être créée, puis elle passe en analyse, puis elle devient prête à être planifiée dans une itération (Definition of Ready), puis elle devient planifiée et enfin elle est devient terminée (Definition of Done). Ce cycle peut avoir des variantes. On voit par exemple le cycle : créé (todo), en analyse (on going), testée (au niveau du projet), homologuée (done : documentée et validée dans la version complète du produit). La durée de vie d’une US est courte et elle ne perdure pas au-delà de la livraison de la US. Il faut voir une US comme un élément de planification dans le développement du produit et non pas comme quelque chose sur laquelle on peut capitaliser. Rien n’empêche de trouver dans une itération ultérieure une autre US qui viendra contredire ou modifier ce qui a été fait dans une des itérations précédentes. En conclusion, les US ne sont pas pérennes et on ne peut donc pas capitaliser sur ces dernières. Au contraire, la fonction métier, qui est identifiée lors des spécifications générales, va rester comme l’élément fondamental et structurant pour les développeurs de l’équipe. Elle va éventuellement s’étendre en intégrant d’autres US. La vision des architectes d’entreprise, de plus, doit être claire et doit être la base documentaire de l’évolution du SI. Cette documentation d’architecture du produit est indispensable pour ne pas porter la confusion chez les développeurs qui assimileraient les besoins (US) aux éléments de conception. Elle doit comprendre :

• les processus et les tâches (cas d’utilisation du point de vue métier, sans chercher à généraliser, en respectant les activités métiers …),

• et les fonctions métiers (avec la volonté de rationaliser, pour les développeurs, les besoins exprimés grâce à des généralisations).

Remarque : Dans certains programmes, les epics et features ne sont pas des “macro UC”, mais des macro-histoires qui in fine se décomposent en mini histoires, les “user stories”. Il y a donc véritablement distinction à faire entre ces supports de la réflexion (à la charge des projets) et les éléments qui structurent et industrialisent la solution (à la charge des architectes). Ceci nous rappelle que les tâches ou les fonctions métier qu’il faut développer peuvent être utilisées par plusieurs histoires.

5.4.1.9 Exécution optimisée des tests

● Plans de tests optimisés Le nombre de règles de gestion dans le périmètre d’une user story peut être important et donc les tests de validation pourront être complexes et nombreux (plusieurs centaines de cas). Le langage formalisé va alors permettre, dès les règles rédigées, de faire des choix dits “de couverture fonctionnelle” pour tester plus ou moins la user story, selon sa criticité métier. Dès la construction des plans de test de validation, en fin de spécifications détaillées, on est en mesure de connaître le périmètre des tests, leur nombre et l’effort nécessaire


à leur réalisation … en respectant les contraintes liées aux criticités des user stories. On optimise ces plans de test en maîtrisant le nombre et la pertinence des tests. Le principe est pratiquement le même pour les tests de recette. On peut appliquer des principes pour les élaborer progressivement, selon des “taux de couverture fonctionnels” dédiés à la recette. Ils sont fondés sur le formalisme de spécification. Ainsi leur choix n’est pas aléatoire, mais en recherche de la meilleure pertinence, avec des critères d’arrêt bien identifiés. On en arrive même aujourd’hui à automatiser la génération des tests selon les efforts souhaitables (risques) et les capacités de test (ressources, outils, environnements et données) que l’on se donne dans la stratégie de test. ● Automatisation de l’exécution des tests de recette

Le langage Gherkin permet d’être interprété par certains outils de test (ex: FitNesse, Cucumber, Green Pepper), sans toutefois aider le Product Owner à sélectionner ses tests et à les limiter. Gherkin permet donc d’automatiser l’exécution des tests de non régression des user stories. Mais comme il n’y a pas contrôle sur leur génération proprement dite, leur nombre et leur pertinence restant de l’initiative du Product Owner, cette technique est très peu utilisée pour les tests de parcours (cas de test de bout-en-bout, de niveau features).


5.5 Comparaison entre cycle long (en V) et cycle court (agile)

Le tableau ci-dessous montre les différences principales entre les deux approches.

Cycle long en V Cycle court agile

Etude d’opportunité Exploration (avec Design Thinking) (fondée sur le périmètre restreint MVP,

centrée utilisateur et itérative, avec une étape organisationnelle intégrée)

Etude de faisabilité

Expression des besoins Design thinking Phase pour le produit entier (au-delà du MVP) mais pour le périmètre de la release considérée

et composée des étapes d’innovation suivantes : Empathie, Définition, Idéation, Prototype, Test

Identification des features et user stories de la release

Spécifications

- Générales recherche des fonctions métiers à partir des cas d’utilisation

- Détaillées Description des fonctions métiers comme étapes, règles métiers et règles de gestion

Spécifications

- Générales Recherche des fonctions à partir des US - Détaillées Description des fonctions métiers en étapes, « vraies » règles métiers et règles de gestion (le reste de la documentation dans le code), en langage pseudo-naturel prêt à être testé (TDD/BDD).

Conception Avec préparation de la stratégie de test et des environnements de test.

Préparation des plans de test manuellement et stockage manuel dans les référentiels de test

Conception Avec préparation de la stratégie de test et des environnements de test. Préparation des plans de test avec, si possible, moyens automatisés pour la génération des tests et leur stockage

Codage et tests unitaires Exécution des tests MOE

Codage et Tests unitaires Exécution des tests MOE + test des règles métiers simples, compréhensibles, sans beaucoup de risque d’oubli de règles énoncées.


Tests d’intégration Exécution des tests de bon

fonctionnement

Tests d’intégration Exécution des tests de bon fonctionnement

Tests de validation Tests d’acceptation Uniquement sur les vraies règles métiers et de gestion, sur des plans optimisés

(tests de couverture les plus pertinentes)

Tests de recette Tests de recette Tests de Non Régression le plus possible automatisés

Bien que l’agilité préconise la communication orale pour accélérer les développements, on constate qu’elle ne rejette pas toute documentation : elle la simplifie, elle la rend plus automatisable. Les agilistes ont ce dicton : “L’oral c’est fait pour se comprendre, l’écrit pour se souvenir”. Dans les deux approches, la qualité reste un objectif à atteindre. Enfin, il n’y a pas d’agilité sans amélioration continue. Le minimum c’est la rétrospective après livraison de la release.

5.6 Agilité et tests : une nouvelle organisation • Définition des règles métiers : les impératifs Le Product Owner se doit de bien spécifier ces règles qui sont la base des tests agiles, puis du code (on n’est plus à définir les tests après le code). Nous constatons qu’il vaut mieux anticiper, si possible, les spécifications par rapport au développement du sprint suivant. Cela permet, nous le verrons, de mieux planifier les tests et réaliser les derniers contrôles de faisabilité de ce sprint à venir. Dans un cycle en V, il y a des MOA pour l’analyse métier qui représentent en moyenne 20% des équipes de développement (sans compter des testeurs métiers qui peuvent alors amener les compétences “MOA” à représenter 30 et 50% de l’effectif MOE). Or le Product Owner est le seul rôle métier mis en avant par l’agilité au sein d’une équipe. Il ne peut cependant tout faire : la stratégie, la définition du produit, les règles métiers, les tests, la communication, etc. Ce constat, pourtant simple, n’est pas toujours compris par les grands comptes qui chargent alors le Product Owner de toutes les tâches en accompagnement métier des développeurs … On est en total déséquilibre au sein de l’équipe agile entre le PO et l’ensemble des concepteurs-programmeurs ! Cette organisation simpliste est dangereuse, le PO étant noyé sous les tâches diverses et de compétences trop variées. Au côté du Product Owner, qui décide des orientations business avec les Directions métiers et fournit du travail opérationnel (spécifications, plans de test par exemple), il n’y a pas que des développeurs. Il y a aussi des architectes (même présents ponctuellement), des analystes (“Business


Analysts”), et des testeurs métiers. L’agilité ne fait pas disparaître des besoins en ressources de compétences métiers, au contraire nous dirions qu’elle les amplifie. Il y a enfin, en théorie (car très peu d’organisations le mettent en place), le support du Programme et de son Product Manager pour toutes les tâches de coordination, de communication et de stratégie entre projets et entre métiers.

• Les tests de validation en mode agile L’agilité se concentre sur des “tests d’acceptation” des user stories. A bien y regarder, il s’agit en fait de tests de recette de ces US, qui pourront être réutilisés pour la non régression. C’est une vision boîte noire de l’US, puisque certains agilistes préconisent de réduire leur descriptif à une seule page. Que deviennent alors les tests de validation ? Il faut d’abord comprendre que le ratio entre tests de validation, qui vérifient les règles métiers d’US, et les tests de recette d’US, est de l’ordre de 10 contre 1. On observe que les tests “les plus courants” ne représentent qu’environ 10% de la totalité des tests métiers possibles pour une US. Ces tests de validation s’appuient sur une grammaire et des intentions plus précises que celles dictées par Gherkin et tiennent généralement, sans être verbeux, sur plusieurs pages. Ensuite, n’oublions pas que les tests de validation doivent parfois garantir le bon fonctionnement et la fluidité des enchaînements d’US, ce qu’on appelle souvent des “parcours clients”. Où sont-ils dans les démarches agiles ? C’est là où la description des parcours demeure nécessaire, en lien avec celle, plus générale, des processus. Certains outils de test, dits “Model Based Testing” (MBT) proposent cette approche de génération automatique de test à partir des spécifications “formelles” : modélisation de l’enchaînement d’US et spécifications internes d’US (sous forme d’enchaînement de règles de gestion). Nous préconisons, pour les aspects organisationnels :

• soit de faire effectuer ces tests par des binômes de développeurs-testeurs mais uniquement lorsque les US sont à faible valeur métier. Le principe de base que tout développeur ne peut auto-contrôler l’adéquation du code aux besoins reste vrai. Cette solution où le développeur n’est pas juge et partie est donc parfaitement acceptable.

• soit, et de préférence pour les spécifications à forte composante métier, par des testeurs spécialisés métiers au sein de l’équipe, voire dans une/plusieurs équipe(s) spécialisée(s) tests .

N’oublions pas que ces tests sont aussi un moyen de contrôler l’exhaustivité des règles. En effet les produits des grands comptes ont un large spectre de contraintes réglementaires et leur complétude interne (elles semblent “cohérentes”) peut néanmoins masquer des manques, malgré les précautions prises à la rédaction des US. Exemple : tous les cas d’achat de mon produit paraissent complets, mais le PO oublie celui de clients mineurs émancipés … point qui ne peut être détecté que par un sachant métier des règlements existants.

Précisons enfin que les tests de validation, par leur nombre, influent fortement sur les charges, et donc le respect des sprints. Beaucoup d’équipes s’en plaignent. Or le passage des règles métiers aux tests respecte des algorithmes MBT qui restent aujourd’hui trop confidentiels. Pourtant, grâce à eux, on pourrait obtenir une dérivation


progressive des tests ou décider de les restreindre, parfois de manière spectaculaire et en modérant cependant les risques encourus. Le test de validation doit donc ne pas être confondu avec le test de recette. Il s’avère que des outils simples de MBT (déjà existants) vont à l’avenir se développer pour précéder les automates d’exécution des tests qui, souvent, sont les seuls connus des équipes et forment le socle du discours DevOps. De façon pragmatique l’équipe agile (PO et développeurs) doit évaluer un effort global de test pour un sprint et dispatcher celui-ci sur les US. Il peut, en ayant les spécifications assez tôt, bénéficier d’indications pour les optimiser et choisir ainsi la meilleure couverture des risques pour le délai imparti (ou constater l’impossibilité de faire …).

• Les tests de recette en mode agile Les tests de recette permettent de tester dans un environnement le plus proche de la production. Ils visent donc les tests d’US les plus utilisées ou les plus risquées pour les métiers. Les tests de recette feront partie in fine des tests de non régression et seront automatisés. Ce point est bien traité avec Gherkin et les outils associés. Par contre, il faut aussi y ajouter des tests de parcours “pertinents” (sélectionnés parmi les tests de validation comme étant les plus représentatifs) et fondés sur une documentation simple, souvent graphique.

5.7 Remarques sur l’outillage Pour supporter le cycle court a-t-on besoin d’outils nouveaux ?

● Pour le pilotage, on voit apparaître une nouvelle génération d’outils collaboratifs fondés sur le suivi des backlogs : la liste des stories, leur vision dynamique dans les versions prévisionnelles (impact mapping), le Kanban des tâches affectées aux acteurs des parties prenantes. L’avantage de ces outils est l’ergonomie avec la forme agréable des restitutions visuelles et leur souplesse d’utilisation. Toutefois, et comme cela a été dit précédemment, il nous semble que le contenu des backlogs est plus important que leur aspect visuel, quitte à rester sur des solutions bureautiques simples… La seule exigence est que les documents soient partagés. Précisons, d’autre part, que s’il y a un coût d’achat pour un logiciel spécifique, il vaut mieux profiter de ses possibles fonctionnalités et donc faire un effort sur leur paramétrage. Toutes les parties prenantes doivent y trouver leurs informations. Ce changement devrait s’accélérer et déboucher sur des solutions de plus en plus déployées, mais il n’est pas un investissement absolument impératif pour débuter. Nous noterons que ces outils de pilotage peuvent intégrer les objets de backlog et les fiches d’anomalies de test. Ils peuvent aussi récupérer les scénarios de tests associés issus de générateurs de plans de test, ce qui condamnera in fine les référentiels distincts (et manuels) de plans de test.


● L’exploration et le Design Thinking utilisent fortement, bien entendu, les outils de prototypage rapide (maquettage des IHM, modèles ou impression 3D), de créativité, d'intelligence collective et de collaboration. ● Les outils de cartographie (qui forme le référentiel d’architecture) demeurent pour décrire et afficher les processus et les tâches de l’architecture métier (issus du Design Thinking, mais sans que la contrainte de mise à jour soit trop forte). Les cas d’utilisation jugés comme fonctions métiers sont représentés par ces mêmes outils, grâce à leur éditeur d’architecture fonctionnelle et de modélisation. ● Pour les spécifications détaillées, les éditeurs de spécifications orientées tests (comme avec le BDD) restent marginaux. Pourtant, leurs textes peuvent aider à la compréhension TDD des développements à réaliser, permettent les analyses d’impact, et in fine amènent à l’automatisation des plans de test car les règles décrites sont utilisées par des générateurs des tests (de type MBT). Certains de ces outils existent et commencent à se répandre dans les grands comptes. Ils sont encore rares et incomplets sur certains aspects, mais ils permettent cependant de produire les tests les plus optimisés (non pas des milliers mais les plus pertinents, avec parfois un facteur 10 avec ceux estimés …), compatibles avec les capacités à faire, et limitant au maximum les risques de laisser passer en production des anomalies. Comme nous l’avons dit ils sont couplés aux outils de pilotage. C’est donc manifestement une voie très intéressante d’avenir sur laquelle il faut investir. ● L’exécution des tests devient industrielle pour les Tests de Non Régression (TNR). Les automates de TNR, connus depuis longtemps, deviennent plus faciles d’utilisation (même s’ils sont souvent aux mains d’équipes spécialisées) et se diffusent bien. Toutefois, plutôt que de croire aux sirènes du marketing logiciel, gardons à l’esprit que ces tests, bien qu’ils vérifient les scripts les plus utilisés, ne représentent en fait, généralement, que 2 à 5% des tests exécutés manuellement par les équipes de test car ils ont un coût et n’ont d’intérêt qu’une fois leurs spécifications stabilisées. De plus ils ne vérifient que des user stories, donc des composants très petits, qui ne garantissent pas que les cas d’usage sont totalement corrects de bout en bout.


En résumé on peut schématiser la cartographie des outils du cycle court de la manière suivante :


6 CONCLUSION Agilité et opportunités pour les grandes entreprises Françaises Alors que nous avons signalé au début de notre Livre Blanc la nécessité de mettre en place les pratiques agiles au sein des grands groupes Français, nous constatons les points suivants.

1. Un retard et un déficit de compétitivité

Le mouvement agile, issu des start-up, gagne les grandes entreprises du CAC40. Parti comme une vague lente, prudente, et un objet de curiosité, il semble aujourd’hui être irrésistible, bien qu’il soit appréhendé sous des formes très variées, parfois loin des standards agiles. Nous recommandons de vérifier les conditions requises pour l’agilité : instabilité des sujets, spécifications laissant place à l’innovation (et non pas fortement réglementées et contraintes). Beaucoup de grandes entreprises se lancent sans discernement vers l’agilité alors qu’elle ne s’y prête pas ou mérite une adaptation. Ainsi le cycle en V que l’on connaît, avec de lentes itérations et des activités menées traditionnellement (expressions de besoins et spécifications très documentées, tests préparés en cours de codage, …) peut, dans certains cas, suffire. L’agilité apporte aussi des idées qui, même dans un cadre cycle en V, permettent de repenser nos méthodes quel que soit “le rythme adopté” (ex: le pilotage de projet, démonstration/maquettage pour dialoguer au plus vite avec les métiers, démarrage au plus tôt des plans de test). Lorsque le passage à l’agilité est décidé, il donne lieu parfois à un déploiement désordonné, limité à quelques équipes SCRUM et à la mise en place de quelques rituels (daily scrum meeting par exemple), sans changer l’organisation (en interne ou hors DSI), sans préparer suffisamment l’émergence de ses valeurs (acculturation), sans modifier fondamentalement le cycle de développement et sans remettre en cause les outils existants. Or, nous l’avons vu, une vision de haut niveau et la plus large possible est nécessaire… au risque, sinon, de rencontrer de sévères désillusions. Ce ne sont pas les principes qui s’avèrent mis en échec, mais leur mise en place.

2. Des freins à l’essor de l’agilité dans les grandes entreprises

On peut citer les constats suivants :

• Le middle management ne voit plus son rôle.

• La Direction n’est pas assez sensibilisée au passage à l’agilité et personne ne semble assumer la responsabilité du choix.

• Une fois un sponsor nommé, celui-ci n’a pas les capacités à mener sa tâche. Le sponsor peut avoir une vision métier mais celui-ci peut être trop peu formé aux valeurs et principes de l’agilité pour la défendre. Il se pourrait aussi que le sponsor ne puisse assumer aucune responsabilité ou décision en contradiction avec les pratiques existantes, de peur de se mettre à dos l’ensemble des autres départements. Bref, l’aspect politique prendra le pas sur la nécessité de l’approche opérationnelle et la nécessaire transformation à assurer.

• L’absence de coach expérimenté se fait sentir lors de la phase de déploiement de l’agilité. La compétence du coach doit non seulement être sanctionnée par d’éventuelles certifications agiles mais aussi par ses retours d’expérience de


l’agilité. Nous pouvons ajouter qu’il lui faut une connaissance des pratiques internes aux grandes entreprises (rites de communication en particulier), nécessairement plus complexes (même s’il s’agit de les transformer) que dans une start-up.

3. Des atouts pour les grandes entreprises Françaises

• La répartition des rôles MOA-MOE est culturellement ancrée dans les projets Français. Celle-ci ne disparaîtra pas du jour au lendemain (les uns pour s’occuper du produit métier, les autres pour les développer) mais les rôles de Product Owners et Scrum Master, qui ne sont pas totalement méconnus aujourd’hui, viseront à gommer les barrières qui les séparent aujourd’hui trop fortement.

• Les équipes Françaises sont prêtes et motivées par le changement du fait des difficultés rencontrées par l’approche “cycle en V” dans les grandes organisations, de l’aura de la culture de la Silicon Valley auprès des jeunes opérationnels, et de success stories de quelques start-up Françaises.

• Des valeurs qui parlent aux jeunes générations et aux nouveaux diplômés. Ceux-ci sont baignés dans un pays depuis de nombreuses années en crise et manquent de repère. Ils trouvent donc dans le cadre de travail agile une manière de s’épanouir et une possibilité de se sentir utile à l’entreprise et à la société.

• Le mouvement agile est relativement actif en France. De nombreuses associations ont vu le jour ces dernières années et des événements fréquents et périodiques sont organisés partout en France.

• Une culture traditionnelle de rigueur, acquise dans les écoles, qui est sous-utilisée dans les grandes organisations et qui redevient, contrairement à ce qui est dit ou pensé, indispensable pour organiser et piloter les projets agiles.

4. Une stratégie pour les entreprises Françaises

Tout comme l’approche French Tech a revivifié nos start-up, nous pouvons mettre en place une agilité à la Française, prenant en compte nos différences et nos talents. Elle pourrait même être à l’échelle Européenne, à l’image de la coopération ayant mené à la réussite d’Airbus. C’est en s’appropriant la démarche que nous pourrons impulser la dynamique et avoir une meilleure communication. Pour cela il faut :

• Former nos jeunes à cette démarche, tant du point de vue des pratiques opérationnelles utiles aux équipes (cycle court, pratique SCRUM) que du pilotage par les backlogs (identification des features et US, suivi Kanban) des Product Owners et Product Managers.

• Former aussi les différents personnels aux approches innovantes, créatives et de rupture qui contribuent et facilitent la transformation.

• Donner une homogénéité à ce cursus (un standard Français voire Européen) et non subir les certifications américaines, ou, pour le moins, réapparaître activement au cœur du mouvement.

• Reprendre le métier Product Owner (un analyste) comme MOA intégrée à l’équipe et avec une culture d’architecture. Celle-ci, à notre sens, doit être mieux perçue des démarches agiles et ainsi mieux permettre aux entreprises


avancées dans ce domaine de poursuivre dans cette voie d’amélioration (l’architecture est la clé de voûte de l’industrialisation du logiciel).

• Prendre aussi davantage de responsabilité dans les démarches automatisées de test, depuis leurs spécifications en passant par leur génération et aboutissant à leur exécution.

Nécessité de l’agilité et de la maîtrise des risques L’agilité est un sujet qui émerge dans les grands comptes Français. Agilistes très tôt convaincus, experts expérimentés du cycle en V et immergés depuis longtemps dans les contextes de grandes DSI, Managers, nous pensons que ces démarches, pour les avoir pratiquées, sont bénéfiques pour la satisfaction des utilisateurs des applications et le “time-to-market” si cher aux dirigeants. Toutefois, ce déploiement pose des problèmes dans les grands comptes. Des erreurs sont observées, non pas liées aux pratiques nouvelles et encore parfois instables, mais liées à leur mise en place et à la compréhension des valeurs et principes agiles. Sans être exhaustif, voici quelques exemples d’idées reçues et d’erreurs :

• Croire que l’agilité c’est l’absence de toute documentation.

• Se lancer seul, sans expérience et sans cadre de référence.

• Avoir une gouvernance molle. Il faut “être doux avec les personnes et dur avec les problèmes”. La responsabilisation à tous les niveaux implique des droits et des devoirs.

• Penser que seule la DSI est impliquée.

• Ne pas réellement changer ses méthodes, procédures et outils existants, s’en tenir aux seules pratiques organisationnelles de SCRUM, et avoir ainsi la conviction que les itérations agiles suffisent à améliorer la productivité des projets. Prenez de la hauteur !

• Sous-estimer la logistique et l’organisation nécessaires au déploiement d’une démarche agile à grande échelle.

• Ne pas avoir un vrai plan de déploiement de l’agilité et de surveillance du projet de transformation.

Ce Livre Blanc a été écrit par des professionnels consultants qui sont sur le terrain et qui espèrent une réaction des grandes entreprises Françaises sur ce sujet, ainsi que la prise de conscience et l’impulsion nécessaire des pouvoirs publics. Pour les Directions Générales qui nous liront, nous pouvons leur donner quelques recommandations :

• Mettre en place un cadre agile, comme SAFe par exemple, pour structurer l’organisation, quitte à l’adapter à son écosystème.

• Mettre en place un cycle court de développement pour gagner de la productivité dans les itérations : on se doit toujours de s’améliorer et donner les moyens aux équipes, par des formations, du support, du coaching et de nouveaux outils, pour qu’elles gagnent en réactivité.

• Lancer un programme pilote de taille raisonnable mais suffisamment significatif pour l’entreprise.

• Mesurer régulièrement les résultats et capitaliser (par exemple sur la vélocité des équipes et les problèmes rencontrés).


L’agilité est un vrai défi pour la compétitivité des entreprises Françaises. Si nous l’avons ciblée sur nos grands comptes, c’est bien pour les sensibiliser et arriver à progresser dans un monde où la concurrence est sévère et sans pitié. Nous avons des atouts pour réussir, pourvu que les managers et les pouvoirs publics aient une vraie prise de conscience de s’organiser, réagir, innover, former… bref, travailler ensemble. La réaction doit apparaître dès aujourd’hui. Ne pas le faire c’est prendre le risque sur nos emplois, perdre notre indépendance et notre rang sur la scène informatique mondiale, se voir écarter de projets internationaux, et ternir l’avenir de notre jeunesse.


Glossaire

Terme Traduction Définition

Backlog Carnet Liste priorisée des choses à faire dans un projet agile, notamment liées aux éléments constitutifs du produit

Epic Epopée Histoire utilisateur de grande maille (décomposée en « features » puis en « stories »)

Feature Fonctionnalité Fonctionnalité qui contribue à un but et qui se décompose en « user stories ».

Framework Cadre (de référence) Ensemble de techniques, d'outils et de méthodes constituant un standards méthodologique

Release Version Une version, en mode agile, constitue un état du produit à déployer après une série de sprints de développement.

User story Histoire utilisateur Histoire qui apporte de la valeur à une ou plusieurs parties prenantes qui utilisent le produit.

Abréviation Signification

ALM Application Lifecycle Management

BDD Behaviour-Driven Development

LeSS Large Scale Scrum

MBT Model Based Testing

MVP Minimum Viable Product

SAFe Scaled Agile Framework

TDD Test Driven Development

TNR Tests de Non Régression

US User Story

UX User eXperience


Auteurs

Stéphane BADREAU

Consultant et formateur senior au sein du cabinet de conseil COMPLIANCE Consulting, Stéphane possède une expertise reconnue en ingénierie des exigences et ingénierie système & logiciel. Depuis de nombreuses années, il intervient dans des contextes très variés aussi bien dans l’industrie que pour les systèmes d’information. De plus en plus, il est amené à coacher des équipes en phase de transition vers l’agilité. Stéphane est certifié Scrum PO, SAFe Agilist et IREB-CPRE. Il est co-auteur d’un ouvrage sur l’ingénierie des exigences paru aux éditions Dunod, président du SPECIEF et animateur de nombreuses communautés sur les réseaux sociaux.

Angel GARCIA

Consultant sénior et Ingénieur Informatique SI et développement logiciel diplômé du Conservatoire National des Arts et Métiers, Angel poursuit depuis plus de 20 ans une même ligne directrice, la conception : des logiciels, des systèmes, des processus et maintenant de l'innovation de rupture avec le Design Thinking. Son expérience de l'agilité a débuté avec une startup télécom, puis dans la recherche, dans l'entreprenariat et depuis quelques années auprès de grandes entreprises des télécoms, de la banque, de aéronautique et du spatial. Il mène aussi d'autres activités : maker et co-fondateur du FabLabSud31, formateur à l'Université de Toulouse ou Président de l'association des élèves et anciens du Cnam de Midi-Pyrénées.

Didier JOLIOT

Après avoir été durant 10 ans chargé de l’intégration puis responsable qualité de logiciels embarqués AIRBUS, Didier JOLIOT a été consultant pour le management de logiciels industriels hautement critiques. Depuis plus de 25 ans il est coach AMOA dans le domaine Banque-Assurances. Avec une certification SPMPO SAFe et une expérience forte de plus de 5 ans dans l’agilité à grande échelle, il aide les Directions de programmes (multi-projets), à formaliser des besoins précis et cohérents, piloter le backlog produit, préparer et industrialiser les tests. Il est auteur de 4 livres sur les avant-projets, l’architecture métier (processus) et fonctionnelle ainsi que sur l’automatisation des plans de tests des SI complexes (Model Based Testing et approche Devops).

Documents

LIVRE BLANC Commppr re ennddre tll ’’iinntté érrêêt …agilitealechelledesgrandesentreprises.eu/wp...Blanc-Agile-SI-v1.2.pdf · manager en mode agile une DSI de plusieurs