Traduit de Anglais vers Français - [Link].

com
 Livre de méthodologie d'analyse commerciale

Guide de l'analyste métier pour l'analyse des exigences, la conception Lean UX et

Gestion de projet dans les entreprises Lean et les startups Lean

* Y compris l'étude de cas du projet de développement de logiciels mobiles

 Copyright © 2015 EMRAH YAYICI

Tous les droits sont réservés.

Aucune partie de ce livre ne peut être reproduite ou transmise sous quelque forme ou par quelque
moyen que ce soit, électronique, mécanique, photocopie, enregistrement ou autre, sans
l'autorisation écrite préalable de l'éditeur.
A propos de l'auteur

Emrah Yayici est l'auteur du best-sellerLivre de mentor de l'analyste d'affaires etLivre

de mentorat sur la conception et l'utilisabilité UX. Il est l'un des associés directeurs
d'UXservices, BA-Works et Keytorc.

Il a débuté sa carrière en tant que consultant en technologie chez Arthur Andersen et

Accenture. Il a ensuite dirigé des projets mondiaux de transformation d'entreprise chez Beko-
Grundig Electronics.

Au cours de sa carrière, il a dirigé des équipes de projets multinationales et interfonctionnelles dans les
secteurs de la banque, de l'assurance, des télécommunications, des médias, de l'électronique grand
public et de l'informatique. Il partage maintenant son expérience sur l'analyse commerciale, le
développement commercial, le développement de produits, la conception de l'expérience client, la
conception UX, les tests d'utilisabilité et l'assurance qualité en publiant des articles et des livres, en
animant des sessions de formation et en prenant la parole lors de conférences.

Il contribue à l'UXPA (User Experience Professionals Association) en tant que

membre et à l'IIBA® (International Institute of Business Analysis) en tant que local
président de chapitre. Il a également contribué à l'ISTQB® (International Software Testing
Board) en tant qu'ancien membre du conseil international.
Préface

Les entreprises doivent développer des produits innovants et de haute qualité plus rapidement que
leurs concurrents pour créer des périodes de monopole temporaire avec une rentabilité maximale.
Cependant, ils ont généralement des délais serrés et des budgets limités pour les projets de
développement de nouveaux produits. Les dirigeants et les managers de la suite C veulent toujours
obtenir des résultats rapides et acceptent rarement de freiner le lancement d'un produit.

Pour relever ce défi, les entreprises performantes appliquent une approche « lean » à
chaque étape de leur cycle de vie de développement de produit (PDLC) : - Gestion de
l'architecture d'entreprise - Analyse stratégique et définition de la portée du produit

- Rassemblement des exigences

- Documentation des exigences

- Conception UX et convivialité

- Conception technique, développement et opérations

- Assurance qualité et tests

- Gestion de projet
Les techniques et principes des meilleures pratiques présentés dans ce livre peuvent être utilisés par un
large éventail de praticiens, y compris : - les analystes commerciaux

- entrepreneurs - consultants - chefs de produits

- propriétaires de produits

- spécialistes du marketing

- chefs de projet

- Designers UX
- développeurs, et

- Equipes QA

dans le développement de tout type de produits, allant des applications mobiles à

l'électronique grand public contenant une technologie logicielle.

Le livre comprend une étude de cas sur un projet de développement d'applications mobiles pour
montrer comment appliquer les principes et les techniques expliqués dans chaque chapitre.

Il existe une perception erronée selon laquelle l'approche Lean ne s'applique qu'aux start-ups et aux petites
entreprises qui ne disposent généralement pas de suffisamment de ressources techniques et financières pour
le développement de produits.

Au contraire, les cadres supérieurs et les gestionnaires d'entreprises de toutes tailles devraient appliquer
une approche allégée dans la transformation de leurs modèles d'exploitation d'entreprise pour :

- Encourager l'innovation,

- obtenir des délais de mise sur le marché plus rapides, et

- prévenir le gaspillage et améliorer la rentabilité.

Table des matières

1. Principes Lean pour réaliser l'innovation et accélérer la mise sur le marché

2. Gestion de l'architecture d'entreprise

3. Analyse stratégique et définition de la portée du produit

4. Quelle méthodologie est la meilleure pour l'approche Lean : Cascade ou Agile ?

5. Recueil des besoins

6. Documentation des exigences

7. Conception UX et convivialité

8. Conception technique et DevOps

9. Assurance qualité et tests

10. Gestion de projet

1. Principes Lean pour réaliser l'innovation et accélérer la mise sur le marché
Les entreprises doivent développer des produits innovants et de haute qualité plus rapidement que
leurs concurrents pour créer des périodes de monopole temporaire avec une rentabilité maximale.
Cependant, ils ont généralement des délais serrés et des budgets limités pour les projets de
développement de nouveaux produits.

Pour surmonter ce défi, les entreprises performantes appliquent une approche d'analyse
commerciale, de conception et de développement « lean » qui trouve son origine dans le système
de production automobile de Toyota.

Lean se concentre principalement sur l'élimination muda (déchets) tout au long du cycle de
développement du produit (PDLC) et en transférant les économies de ressources à des projets
innovants.

Gaspillage l'élimination peut être obtenue en injectant les principes lean suivants dans
l'ADN des entreprises :

1. Soyez axé sur la valeur

-Concentrez-vous sur la production résultats (valeur) plutôt que les sorties (livrables).
- Priorisez toujours les fonctionnalités du produit ; concentrez-vous sur les "incontournables" plutôt que sur les

"incontournables".

- Éliminer le gaspillage des fonctionnalités de produit à faible priorité qui ne sont pas essentielles pour
les clients.

2. Soyez centré sur le client

-Soyez comme le soleil mais pas comme la lune ; illuminez-vous avec la lumière de vos
propres clients au lieu de celle de vos concurrents. Concentrez-vous sur une plus
grande réactivité aux besoins de vos clients cibles au lieu de vous comparer à vos
concurrents.

- Soyez centré sur le client plutôt que sur le produit. Considérez les produits non pas comme un objectif
mais comme un outil pour répondre aux besoins de vos clients.

- Développer des produits autour de vos clients. Écoutez toujours attentivement la « voix de vos
clients » tout au long de PDLC. Mettre en place et maintenir une boucle continue de rétroaction des
clients.
- Interrogez les clients sur leurs besoins mais pas sur les solutions qu'ils proposent. Souvenez-vous
de la célèbre citation d'Henry Ford : « Si j'avais demandé aux gens ce qu'ils voulaient, ils auraient dit
des chevaux plus rapides.

3. Soyez itératif

-Commencez votre parcours de développement de produits par petites étapes. Pensez grand, mais commencez petit.

- Être patient; rappelez-vous que Rome ne s'est pas construite en un jour.

- Optez pour une évolution plutôt que pour une révolution : utilisez des prototypes pour recueillir les premières
réactions des clients. Lors de l'itération initiale, publiez une version de base du produit comprenant
uniquement les fonctionnalités hautement prioritaires. Dans les itérations suivantes, utilisez les commentaires
des clients des versions précédentes pour affiner le produit en ajoutant, en mettant à jour et même en
supprimant des fonctionnalités. Itérer jusqu'à ce que le produit réponde aux besoins de l'entreprise et des
clients.

4. Soyez simpliste

-Rappelez-vous que moins est beaucoup plus dans l'approche lean. Ne le compliquez pas.
- Concentrez-vous sur le « juste assez » et sur ce qui est vraiment nécessaire pour satisfaire les besoins des clients.

- Appréciez la réduction de la taille du produit en supprimant les fonctionnalités non essentielles, plutôt que de
l'augmenter avec des cloches et des sifflets.

- Lors de la détermination des caractéristiques du produit, pensez comme si vous décoriez une petite maison. Ne

faites pas en sorte que vos utilisateurs se sentent claustrophobes comme s'ils se trouvaient dans un petit espace

encombré avec beaucoup de meubles.

5. N'ayez pas peur des échecs précoces

-Rappelez-vous la célèbre citation du scientifique et auteur américain, le Dr James Jay

Horning : « Le bon jugement vient de l'expérience. L'expérience vient du mauvais
jugement."

- Soyez adaptatif, apprenez tôt des échecs des itérations initiales et utilisez cette expérience pour les
itérations ultérieures.

- Se concentrer sur Kaizen, ce qui signifie une amélioration continue, à tous les niveaux du PDLC en
utilisant les leçons apprises lors des itérations précédentes.
 6. Optimisez le flux de travail

-Agir « juste à temps » tout au long du PDLC. L'analyse des exigences et les artefacts de
conception représentent les inventaires WIP (work in process) dans le cycle de développement
du produit. Créez-les au bon moment et avec suffisamment de détails pour éviterDéchets au
niveau WIP.
2. Gestion de l'architecture d'entreprise
Selon l'approche Lean, chaque projet d'une entreprise doit soutenir les stratégies de
l'entreprise. En d'autres termes, les objectifs de chaque projet (exigences opérationnelles)
doivent être alignés sur les stratégies de l'entreprise. Sinon, les ressources de l'entreprise sont
enracinées dans la mauvaise direction, et cela se traduit pardéchets au niveau du portefeuille
de projets.

Pour assurer l'alignement stratégique et éviter le gaspillage, les demandes de toutes les unités
commerciales de l'entreprise pour des produits nouveaux et améliorés doivent être reçues, évaluées et
classées par ordre de priorité par un groupe de personnes dédié.

Dans les grandes entreprises qui créent des produits contenant une technologie logicielle, ce groupe
dédié peut être une équipe d'architecture d'entreprise distincte qui travaille en coordination avec les
dirigeants de l'entreprise pour comprendre les stratégies commerciales, évaluer les demandes des unités
commerciales par rapport à ces stratégies et diriger les équipes techniques dans la création de produits
qui répondent aux besoins des entreprises et des clients d'aujourd'hui et de demain.

Étant donné que le développement de produits prend un temps considérable, les architectes
d'entreprise doivent guider les équipes techniques dans la création d'une architecture technique
flexible qui peut servir à la fois les initiatives de développement de nouveaux produits d'aujourd'hui
et de demain. Sinon, les limitations techniques deviennent un goulot d'étranglement plutôt qu'un
catalyseur pour l'entreprise.

La profession d'architecture d'entreprise nécessite des connaissances commerciales, des compétences

techniques et la capacité de voir la situation dans son ensemble avec une vue d'ensemble. Par
conséquent, les personnes les plus aptes à occuper des postes en architecture d'entreprise sont des
analystes commerciaux, des chefs de produit et des chefs de projet expérimentés qui acquièrent
naturellement ces compétences dans le cadre de leur profession. Ainsi, dans les petites et moyennes
entreprises, les bureaux de gestion de projet (PMO), les équipes de gestion de produits ou une équipe
d'analystes commerciaux expérimentés devraient être chargés d'évaluer et de hiérarchiser les demandes
de développement/amélioration de produit de toutes les unités commerciales et d'assurer l'alignement
des processus commerciaux et techniques. architectures.

Tour de contrôle du trafic aérien

Chez nos clients, nous assistons à un nombre écrasant de demandes de développement de produits
nouveaux ou améliorés de la part des unités commerciales. Gérer ces demandes, c'est comme
gérer la tour de contrôle du trafic aérien dans un aéroport très achalandé.

Un grand nombre de demandes en attente dans le pipeline de gestion de la demande crée une
forte dette technique.

Malgré tout leur travail acharné, la plupart des départements techniques se voient reprocher de ne pas être en
mesure de répondre aux attentes des business units. Les unités commerciales reprochent principalement aux
services techniques de ne pas fournir assez rapidement des produits nouveaux ou améliorés.

Selon la théorie de la relativité d'Einstein, les observations que vous faites sur le temps diffèrent des
observations d'autres personnes qui se déplacent à des vitesses différentes. De même, les durées
des projets sont relatives pour les équipes techniques et les business units d'une même entreprise.
Alors que six mois seront considérés comme un délai difficile par la plupart des équipes techniques
pour développer un nouveau produit, il sera considéré comme une longue durée par les unités
commerciales.

S'ils sont livrés en retard, les projets de développement de produits perdent de leur importance pour
l'entreprise en raison de l'évolution rapide des conditions du marché et des fortes pressions de mise sur
le marché.

Si vous recherchez la cause profonde des latences des équipes techniques, vous verrez
qu'elles ne peuvent allouer qu'un temps limité au développement de nouveaux produits.
Ils passent la majorité de leur temps sur un nombre écrasant de demandes d'amélioration/
modification de produits existants pour "garder les lumières allumées".

Projets « Gardez les lumières allumées »

Un nombre élevé de ces demandes d'amélioration/modification démotive également les

analystes commerciaux, les chefs de produit, les développeurs et les chefs de projet car, au
lieu d'être impliqués dans des projets nouveaux et innovants, ils doivent passer leur temps
à combattre les produits existants.

Si le surcoût de ces demandes d'amélioration/modification n'est pas suivi

systématiquement, le coût total de possession des produits existants atteindra un
montant très élevé. Habituellement, ce montant total dépasse le remplacement du
produit existant par un nouveau et créeamélioration du produit / déchets au
niveau de la modification.

Parfois, les demandes d'amélioration/modification sont classées dans la même catégorie que
les demandes de maintenance. Cette approche est également inappropriée car la maintenance
est une catégorie différente et son objectif est d'assurer un fonctionnement continu
d'un produit plutôt que de valoriser ses attributs. Chaque produit doit avoir un suivi de
maintenance et d'amélioration/modification distinct pour identifier le meilleur moment pour le
remplacer totalement.

Le statut de ces demandes d'amélioration/modification doit être revu en permanence.

Certaines des demandes en attente dans le pipeline peuvent devenir obsolètes en raison
de l'évolution des conditions commerciales. Ces demandes obsolètes doivent être
identifiées et éliminées pour optimiser l'utilisation des ressources techniques et éviter le
gaspillage.

Étude de cas : projet de développement d'applications mobiles

Une CEC locale (société d'électronique grand public) a externalisé son processus de
collecte, de documentation et d'analyse des exigences à BA-Works.

Présentation de l'entreprise

Le CEC a vendu des téléviseurs, des haut-parleurs, des systèmes home cinéma et des lecteurs DVD via des revendeurs

indépendants. Ces magasins concessionnaires étaient également responsables de la livraison et de la réparation des

produits.

Le CEC a travaillé avec une société de centre d'appels externalisée qui n'était responsable
que du service client. Il n'y avait pas de ventes directes aux clients.

Le CEC gérait ses opérations d'approvisionnement, d'inventaire, de comptabilité et de vente sur un

système ERP et ses opérations de marketing sur un système CRM.

Besoin commercial

Le site Web de la CEC n'était utilisé que pour présenter des informations sur les produits et
les campagnes. Il n'y a eu aucune vente sur le canal Web. A cette époque, le CEC n'avait
pas d'application mobile.

Depuis deux ans, les prix réduits sur les sites de commerce électronique
poussent les clients de la CEC vers la concurrence.

Pour surmonter cette situation, le CMO (Chief Marketing Officer) du CEC envisageait de
créer les propres canaux de vente en ligne de l'entreprise. Le CMO prévoyait d'initier la
stratégie en ligne avec une application mobile. À cette époque, les autres sociétés
d'électronique grand public n'avaient pas d'applications mobiles pour cela.
marché local. Le CMO voulait faire du CEC la première entreprise d'électronique grand
public à utiliser le mobile comme canal de vente. Il a discuté de l'idée de l'application
mobile avec les membres de son équipe et leur a demandé d'aller de l'avant.

L'unité commerciale de marketing de l'entreprise a saisi cette demande dans le système de

gestion des demandes du CEC en tant que demande urgente hautement prioritaire. Ils ont
indiqué qu'ils souhaitaient lancer un canal de vente mobile plus tôt que leurs concurrents et
que le projet devait donc être achevé dans les deux mois au plus tard.

Dans les pages suivantes, l'approche Lean, telle qu'appliquée au développement et à la

sortie de l'application mobile du CEC, est expliquée en détail pour aider les lecteurs à
mieux comprendre le contenu pertinent de chaque chapitre du livre.
3. Analyse stratégique et définition de la portée du produit
L'approche Lean apporte un état d'esprit axé sur les objectifs et la valeur qui nécessite une vision
partagée entre toutes les parties prenantes du projet.

Les analystes commerciaux doivent commencer chaque projet en définissant les exigences
commerciales qui expliquent la vision et la proposition de valeur du produit. Les besoins de
l'entreprise doivent clairement répondrePourquoi les clients ont besoin de ce produit
spécifique.

Les analystes commerciaux doivent interroger les clients cibles au début du projet
et valider que les exigences commerciales définies peuvent résoudre les besoins
articulés des clients.

Une définition claire des besoins métiers en début de projet oriente toutes les parties
prenantes dans la même direction stratégique. Cela atténue le risque de dérive de la portée
due aux demandes de modification potentielles (CR), qui entraînent un gaspillage dû aux
retouches.

En fonction de la taille du projet, les exigences métier peuvent être définies dans différents
types de documents d'étendue du produit :

1. Document d'analyse de rentabilisation

Dans les projets à grande échelle (généralement appelés projets de type A) qui ont un impact au niveau de
l'entreprise, les exigences commerciales doivent être documentées dans un document d'analyse de
rentabilisation. Le document d'analyse de rentabilisation doit inclure : - Exigences commerciales : pour clarifier
pourquoi le nouveau produit est nécessaire

- Portée : pour définir et hiérarchiser les fonctionnalités du produit qui satisferont les objectifs et les
problèmes spécifiques des clients cibles

- Contexte : pour analyser avec quels autres produits et systèmes le produit fonctionnera
en intégration

- Analyse coût vs bénéfice : pour mieux comprendre la faisabilité du nouveau produit. La

faisabilité d'un nouveau produit doit être analysée en fonction du périmètre défini, car un
produit réalisable peut devenir irréalisable en fonction des fonctionnalités sélectionnées.

- Risques : pour identifier et atténuer les éventuelles conséquences négatives de la sortie du

nouveau produit.
2. Document sur la vision et la portée

Pour les projets de petite et moyenne envergure (généralement appelés projets de type B), les
exigences opérationnelles doivent être documentées dans un document de vision et de portée.
Ce document doit inclure les fonctionnalités du produit proposé qui seront livrées dans chaque
version et fournir des informations contextuelles qui montrent l'intégration de haut niveau du
produit avec d'autres produits et systèmes.

3. Document SOW (Énoncé des travaux)

Pour les demandes d'amélioration/modification (généralement appelées projets de type C) sur des
produits existants qui durent généralement moins d'un mois, il n'est pas nécessaire d'avoir une
analyse de rentabilisation ou un document de vision et de portée. Une explication claire du besoin
métier dans un document SOW d'une page est juste suffisante pour décrire l'étendue du travail. Ces
demandes sont mieux satisfaites par une approche plus agile sans trop de documentation.

Effet ondulant

Dans tout document de portée, les exigences commerciales doivent être définies dans des déclarations
spécifiques, axées sur un objectif, réalisables et parfaitement claires.

Une définition claire des exigences métier au début du projet est très importante,
car aux étapes ultérieures du projet, les exigences fonctionnelles, non
fonctionnelles et techniques, ainsi que les règles métier du produit doivent être
définies en cohérence avec les exigences métier. Une mauvaise définition des
exigences métier aura un effet d'entraînement négatif sur toutes ces exigences et
règles métier de bas niveau. Cela entraînera des déchets en raison d'un nombre
élevé de CR et de défauts.

Paradoxe du choix

Avoir de nombreuses fonctionnalités n'est pas un indicateur d'élégance ou de qualité dans le développement de

produits lean.

Au contraire, comme le décrit le psychologue Barry Schwartz dans son livre Paradoxe du
choix : pourquoi plus, c'est moins, la surcharge de choix crée une paralysie de la prise de
décision, de l'anxiété et du stress au lieu d'apporter plus de satisfaction aux clients.
Une approche allégée, offrant une "valeur maximale" avec "juste assez" de fonctionnalités, est
l'objectif ultime. La mise en place d'un processus formel de priorisation est l'une des conditions
préalables à l'application de cette approche.

Sans processus de priorisation, les unités commerciales se sentent libres de demander n'importe quelle
fonctionnalité du produit comme si le projet disposait de ressources illimitées. Les fonctionnalités
demandées par les business units doivent être hiérarchisées selon deux critères principaux : -la valeur
métier et,

- difficulté de mise en œuvre.

La valeur commerciale dépend de l'alignement d'une fonctionnalité sur les exigences commerciales et les
besoins des clients. Les éléments à haute valeur commerciale et à faible difficulté de mise en œuvre
doivent être classés comme hautement prioritaires, tandis que ceux à faible valeur commerciale et à
forte difficulté de mise en œuvre doivent être classés comme faible priorité.

Les autres fonctionnalités doivent être étiquetées comme étant de priorité moyenne et classées par ordre de
priorité en fonction de leur fréquence d'utilisation prévue. Les fonctionnalités de priorité moyenne peuvent
être réétiquetées comme haute priorité si elles ont une fréquence d'utilisation élevée. Sinon, ils se déplacent
vers le quadrant de faible priorité.

Délai de mise sur le marché

Lorsque le délai de mise sur le marché est critique pour le produit, le projet doit être classé comme un
projet « accéléré ». Dans ces projets accélérés et urgents, les analystes commerciaux et les responsables
doivent convaincre les unités commerciales de se concentrer sur les fonctionnalités "indispensables"
plutôt que sur les fonctionnalités "agréables à avoir" et essayer de générer des résultats de "juste valeur"
dans un manière itérative.

Règle 80/20

Indépendamment des contraintes de temps de mise sur le marché, les unités commerciales sont toujours désireuses

d'élargir la portée des produits en ajoutant des fonctionnalités intéressantes. Cependant, d'après notre expérience, la

majorité des utilisateurs n'utilisent qu'une minorité des fonctionnalités du produit. C'est une grande source de

déchets au niveau du périmètre.

Lorsque les unités commerciales insistent sur des fonctionnalités intéressantes et peu prioritaires,
les analystes commerciaux et les chefs de projet doivent leur rappeler la célèbre phrase du poème
de Voltaire « La Begueule » : « la perfection est l'ennemie du bien ». L'expression suggère que le fait
d'insister sur la perfection n'entraîne souvent aucune amélioration.

Analyse comparative et rétro-ingénierie

Les unités commerciales ont également tendance à élargir la gamme de produits en

comparant les produits des concurrents et en demandant toutes leurs fonctionnalités.

Bien que l'analyse comparative des produits des concurrents soit un moyen rapide de déterminer
les caractéristiques d'un produit, elle n'est pas appréciée à chaque phase du développement d'un
produit lean.

Dans une approche Lean, les parties prenantes du projet devraient examiner « quels
problèmes de mes clients cibles mon produit devrait-il résoudre » au lieu de « ce que font mes
concurrents ».

Une fois les fonctionnalités du produit définies, l'analyse comparative peut ensuite être utilisée pour accélérer les

phases ultérieures de développement du produit en explorant comment les concurrents implémentent des

fonctionnalités similaires sans réinventer la roue.

Il ne faut pas oublier non plus que même les meilleurs compétiteurs ne font pas toujours
les bonnes choses. Ainsi, l'analyse comparative peut également conduire à copier les
erreurs des concurrents. Dans l'un des projets BA-Works, notre équipe était chargée de
comparer les canaux d'interaction client d'une chaîne hôtelière mondiale avec ses
concurrents. Au cours de l'étude, notre équipe a remarqué que la majorité des concurrents
avaient de bonnes et de mauvaises choses en commun sur leurs canaux d'interaction avec
les clients (Web, centre d'appels, mobile et médias sociaux). C'était le résultat d'une
approche copier-coller. Bien que copier les concurrents soit un moyen rapide, les
entreprises doivent d'abord se concentrer sur la recherche de moyens de se différencier
en offrant la meilleure expérience client.

Version de base d'un produit

L'approche Lean suggère le flux suivant dans PDLC :

- Déployez la première version avec une version principale du produit et obtenez les commentaires
des clients le plus tôt possible.

- À chaque itération suivante, utilisez les commentaires des clients précédents pour affiner le produit en
ajoutant, mettant à jour et même en supprimant des fonctionnalités.

- Itérer jusqu'à ce que le produit réponde aux exigences de l'entreprise et aux besoins des clients.

La version de base d'un produit doit avoir un ensemble minimum de fonctionnalités qui peuvent
résoudre le problème principal des clients cibles. Des termes populaires tels que MVP (produit
viable minimum) et MMF (caractéristiques commercialisables minimales) sont utilisés pour définir
cette version de base du produit.

Par exemple, la version de base d'une voiture de golf devrait au moins avoir un moteur, des pneus, un
volant, des freins, des sièges et une boîte utilitaire. Lors de la première version, même ces fonctionnalités
de base limitées peuvent répondre au besoin de base du client en matière de transport sur un nouveau
terrain de golf. La décision d'ajouter des fonctionnalités intéressantes, telles que des porte-gobelets, des
glacières, des pare-brise chauffants et des systèmes audio, peut être prise ultérieurement en fonction
des commentaires des clients sur la version principale de la voiture.

Les fonctionnalités hautement prioritaires sur les documents d'étendue sont les meilleurs candidats pour la version

de base du produit. Des fonctionnalités de priorité moyenne et faible peuvent être ajoutées aux versions ultérieures

en fonction des commentaires des clients sur la version principale.

La priorité des fonctionnalités peut changer en fonction des commentaires des clients. Une fonctionnalité
initialement considérée comme de faible priorité peut ensuite devenir une fonctionnalité de haute
priorité. De même, une fonctionnalité de produit initialement considérée comme hautement prioritaire
peut devenir obsolète si elle n'apporte pas la valeur souhaitée aux clients.

Pour le projet d'application mobile CEC, les analystes commerciaux de BA-Works ont évalué
la demande de la business unit marketing. Ils ont marqué cette demande comme un projet de
type A qui a eu un impact au niveau de l'entreprise sur les canaux de vente. Ils ont été choqués
lorsqu'ils ont vu que l'unité commerciale de marketing prévoyait de lancer le produit seulement
deux mois plus tard.

Comme il s'agissait d'un projet de type A, les analystes ont travaillé avec l'unité d'affaires marketing pour
préparer un dossier d'affaires. Les détails du document d'analyse de rentabilisation étaient les suivants :
Le contexte

Nos analystes commerciaux ont analysé les systèmes existants tels que : -ERP (Enterprise
Resource Planning), -CRM (Customer Relationship Management), -CMS (Content
Management System) -Dealer Management System avec lesquels l'application mobile
devait être intégrée pour fournir les fonctionnalités proposées .

Analyse des coûts par rapport aux avantages

Selon l'analyse coûts-avantages, le projet d'application mobile avait une VAN positive
(valeur actualisée nette). Il serait amorti en moins de trois ans. Ce délai de
récupération était acceptable pour l'unité d'affaires marketing.
L'équipe du projet a également évalué les risques et défini la stratégie d'atténuation.
4. Quelle méthodologie est la meilleure pour l'approche Lean : Cascade ou Agile ?
Au niveau stratégique, une architecture d'entreprise et une gestion de la demande réussies
empêchent déchets au niveau du portefeuille en veillant à ce que les ressources de l'entreprise
soient utilisées pour les bons projets de développement de produits qui soutiennent les stratégies
de l'entreprise.

Pour prévenir déchets aux niveaux tactique et opérationnel, l'utilisation des ressources au sein
des projets doit également être optimisée. Ceci peut être réalisé en appliquant une
méthodologie appropriée dans chaque projet de développement de produit.

Loi d'entropie

Selon la théorie de la physique, tout dans l'univers a tendance à passer d'un état bien ordonné à un
état désordonné en raison de la loi de l'entropie. Ceci est également valable pour les projets de
développement de produits. Pour éviter le désordre et le chaos, les équipes de projet doivent
appliquer une méthodologie.

Cependant, certains managers tombent dans le piège de la sur-standardisation et

tentent d'appliquer la même méthodologie standard à tous leurs projets. Ils attribuent
même des noms voyants tels que Xagile, Waterscrum et Scrumfall à ces
méthodologies.

Étant donné que chaque projet a une dynamique différente, il est préférable d'appliquer une
méthodologie personnalisée qui correspond aux besoins spécifiques du projet plutôt qu'une
approche unique. Dans une majorité d'entreprises, les méthodologies les plus populaires sont
cascade et agile.

Cascade ou Agile ?

Selon la méthode dialectique en philosophie, "toutes choses contiennent en elles-mêmes

des contradictions dialectiques internes qui sont la cause première du mouvement, du
changement et du développement dans le monde". De même, les contradictions internes
et les inconvénients de la méthodologie en cascade ont été le moteur de l'adoption agile.

L'approche lean est généralement associée aux méthodologies agiles principalement en raison de
ses trois énoncés de manifeste :
1. "Un logiciel fonctionnel sur une documentation complète"

Dans Scrum, un cadre agile populaire, les exigences sont définies comme des histoires d'utilisateurs
courtes et simples (comme un «rôle», je veux un «objectif») sur le backlog de produit par un
représentant de l'unité commerciale (le propriétaire du produit). Cela minimise le niveau de
documentation et de bureaucratie observé dans les projets en cascade.

2. "Collaboration client sur négociation de contrat"

Dans les projets agiles, le propriétaire du produit et l'équipe de développement travaillent au même
endroit, ce qui crée un environnement de développement de produit plus collaboratif par rapport
aux projets en cascade.

3- « Répondre au changement suivant un plan » :

Dans les projets en cascade, le développement attend l'achèvement des phases d'analyse et de
conception. Ainsi, dans un projet d'un an, il faut au moins cinq à six mois en moyenne pour
arriver aux parties fonctionnelles d'un produit. Cette latence dans la livraison crée de l'anxiété
pour les unités commerciales qui sont impatientes de voir des résultats « rapides ». D'autre
part, l'équipe agile libère une partie fonctionnelle du produit dans une série de « sprints » de
deux à trois semaines sous la coordination d'un « scrum master ». La vélocité de l'équipe est
ajustée de manière itérative en analysant les burn-down charts des sprints précédents.

La livraison rapide de produits fonctionnels par les projets agiles, dès la première itération, apporte
confiance à toutes les parties prenantes et permet de recueillir rapidement les commentaires des
clients.

Dans les environnements commerciaux dynamiques dans lesquels le changement n'est pas
l'exception mais la norme, l'application de la méthodologie agile est plus significative, car la
cascade a une faible flexibilité pour les modifications des exigences. Toute modification
éventuelle des exigences a un impact sur l'analyse globale et les artefacts de conception. Dans
les environnements agiles, une modification des exigences n'a aucun effet sur les parties du
produit qui n'ont pas encore été analysées ou conçues.

Le propriétaire du produit et l'équipe de projet doivent mener des "sessions de toilettage"

régulières dans les projets agiles. L'objectif de ces sessions est de discuter des retours clients
des sprints précédents et de mettre à jour le backlog produit en supprimant les user stories qui
n'ont plus de proposition de valeur. Cela fait également de l'agilité une méthodologie plus
efficace dans les environnements commerciaux dynamiques.
Cependant, appliquer la méthodologie agile à chaque type de projet n'est pas une stratégie
correcte. Il est encore plus approprié de procéder à la chute d'eau lorsque :

- le produit a une intégration intensive entre ses composants ;

- la colocation des membres de l'équipe de projet n'est pas envisageable ;

- il n'est pas possible pour les membres de l'équipe de ne travailler que pour un seul projet à la
fois ; et

- la rotation du personnel est élevée, ce qui risque de faire perdre le savoir-faire du projet au cas où
des membres de l'équipe projet quitteraient l'entreprise.

Agile est itératif par nature. Bien que la cascade soit une méthodologie séquentielle, il est
toujours possible de la rendre plus itérative en

- augmenter le nombre de sorties,

- bénéficier de réunions de prototypage et de revues pour avoir des retours clients en

amont,

- minimiser le niveau de détail des documents d'exigences par une utilisation plus efficace des
diagrammes, et

- décomposer les exigences dans la bonne granularité pour améliorer la compréhensibilité et la

traçabilité.

Modèles quantiques vs déterministes

Les formulations d'Einstein et de Heisenberg sont les modèles les plus

dominants pour expliquer les lois de la physique. Einstein ne croyait pas au
hasard (indéterminisme), et il a résumé cela avec sa célèbre citation : "Comme je
l'ai dit tant de fois, Dieu ne joue pas aux dés avec le monde". D'autre part, le
modèle quantique de Heisenberg est basé sur le principe d'incertitude,
également appelé «principe d'indétermination».

Bien que ces deux théories soient complètement différentes, un physicien peut toujours les utiliser pour
effectuer des calculs précis dans différents cas. Alors qu'ils utilisent principalement les formulations
d'Einstein pour modéliser les particules atomiques se déplaçant à des vitesses proches de la vitesse de la
lumière, ils utilisent des formulations quantiques pour modéliser le comportement des particules
subatomiques.
Nous pouvons associer la méthodologie en cascade aux modèles déterministes d'Einstein et l'utiliser
pour des projets qui nécessitent une grande conception en amont dans des environnements
commerciaux relativement statiques. D'un autre côté, nous pouvons associer la méthodologie agile à
l'indéterminisme de la théorie quantique en raison de son succès dans des environnements
commerciaux dynamiques avec des conditions commerciales aléatoires.

Les managers ne doivent pas tomber dans une erreur "ou bien/ou bien" en sentant qu'ils doivent choisir
entre cascade ou agile. Pour certains projets, comprenant à la fois des conditions statiques et
dynamiques, même une stratégie hybride peut être formulée qui applique à la fois une méthodologie en
cascade et agile pour différentes phases au sein du même projet. La cascade peut être appliquée lors de
la phase initiale du projet pour publier les fonctionnalités de base hautement prioritaires d'un produit qui
a une architecture complexe de nombreux composants intégrés, et une méthodologie agile peut être
appliquée dans les phases ultérieures pour publier les fonctionnalités restantes de priorité moyenne et
faible. caractéristiques.

Pour le projet d'application mobile CEC, notre équipe a appliqué une méthodologie hybride
similaire. La cascade a été appliquée lors de la première phase du projet, qui a duré deux mois.
À ce stade, seules les fonctionnalités hautement prioritaires ont été développées et publiées
sur une version principale de l'application mobile.
La première phase du projet a été livrée dans les délais, en deux mois, et les
observations suivantes ont été faites concernant la version initiale du produit :

- Un canal de vente mobile a été lancé avant les concurrents.

- Le nombre de personnes ayant téléchargé l'application mobile CEC a été supérieur

aux attentes.

- Le nombre de clients qui ont utilisé l'application mobile pour voir et commander des produits
CEC était supérieur aux projections du document d'analyse de rentabilisation.

Ainsi, la business unit marketing de CEC a vérifié que l'application mobile était une bonne
idée. Même avec un nombre limité de fonctionnalités, le produit a généré une grande
valeur pour les clients de CEC et satisfait les exigences commerciales.

Sur la base de ces premiers résultats, la business unit marketing a décidé de lancer la
deuxième phase du projet pour mettre en place des fonctionnalités de priorité moyenne
prédéfinies sur le document de business case.
Dans la deuxième phase, l'équipe du projet a appliqué la méthodologie agile. Le chef de
projet a commencé à jouer le rôle de scrum master. Étant donné que l'équipe marketing
de CEC n'a pas pu affecter de représentant principal, l'analyste commercial le plus
expérimenté de l'équipe a joué le rôle de propriétaire de produit. Les autres analystes
commerciaux ont rejoint l'équipe agile avec les développeurs et les testeurs de logiciels.

Les fonctionnalités de priorité moyenne de l'application mobile ont été développées et

publiées en deux sprints, chacun d'eux ayant duré trois semaines.
Après avoir analysé les commentaires des clients et les journaux d'utilisation des applications
mobiles des sprints un et deux, l'unité commerciale marketing a observé que :

- Les clients ont définitivement vérifié les notes et les avis des autres clients avant d'acheter un
produit. Cette nouvelle fonctionnalité était également très utile pour écouter la voix du client,
ce qui n'était pas possible d'obtenir depuis le canal du revendeur.

- Au lieu de contacter le centre d'appels, les clients CEC utilisaient l'application mobile pour suivre
leurs commandes. Cela s'est traduit par des économies supplémentaires, grâce à la réduction des
coûts des centres d'appels externalisés.

CMO était heureux de voir que les fonctionnalités nouvellement ajoutées ont été amorties très
rapidement. Après analyse des logs d'utilisation et des études de cartographie des parcours clients, la
business unit marketing a décidé d'ajouter quelques fonctionnalités supplémentaires pour augmenter
encore le taux d'utilisation de l'application mobile.
Ces nouvelles fonctionnalités ont également été implémentées avec une méthodologie agile dans deux autres

sprints.
Après avoir analysé les commentaires des clients et les journaux d'utilisation des applications mobiles
des sprints trois et quatre, l'unité commerciale marketing a observé que :
- La fonctionnalité du produit qui envoyait des codes de réduction lorsque les clients se
connectaient à un produit CEC via l'application mobile CEC est devenue très populaire. Utilisé par un
grand nombre de clients, il a eu un impact positif sur les opportunités de ventes croisées et la
fidélité des clients.

- Les clients n'ont pas été aussi réactifs que prévu aux offres contextuelles envoyées via
l'application mobile. Ce fut une déception pour l'unité commerciale de marketing. L'unité
commerciale a décidé d'abandonner cette fonctionnalité, qui n'apportait pas une valeur
ajoutée remarquable.

- L'unité commerciale de marketing a également remarqué que certains clients jugeaient très
faible la qualité du service du concessionnaire, ce qui avait un impact négatif sur la décision
d'achat d'autres clients. L'équipe a décidé de résoudre ce problème comme suit : les clients
continueraient d'évaluer la qualité du service du concessionnaire via l'application mobile, mais
l'évaluation du client ne serait pas visible pour les autres clients. Il ne serait visible que par
l'équipe de direction du concessionnaire CEC.
5. Recueil des besoins
Les exigences de l'utilisateur, les exigences fonctionnelles, les exigences non
fonctionnelles et les règles métier du produit doivent être définies en cohérence avec les
exigences métier pour maintenir le projet sur la bonne voie et garantir l'adéquation
stratégique, utilisateur et technique du produit.

- Besoins de l'utilisateur : quels besoins/objectifs du client le produit doit-il atteindre ?

- Exigences fonctionnelles : quelles fonctionnalités le produit doit avoir pour répondre aux
exigences des utilisateurs

- Exigences non fonctionnelles : comment le produit doit fonctionner en termes d'attributs de qualité, tels
que la convivialité, les performances, la confidentialité et la sécurité

- Règles métier : principalement les conditions, les contraintes et les formules qui déterminent la
manière dont les exigences seront traitées par l'utilisateur et le produit

Si ces exigences utilisateur, fonctionnelles et non fonctionnelles, et les règles métier ne sont
pas cohérentes avec les exigences métier, les résultats du projet ne fourniront pas la valeur
souhaitée et ne répondront pas aux besoins des clients. Pour atténuer ce risque, les analystes
commerciaux doivent accorder la plus haute priorité à la traduction des besoins commerciaux
en exigences utilisateur correctes lors des réunions de collecte des exigences. Ils doivent se
concentrer sur la résolution des conflits concernant ces exigences avant de discuter des
aspects techniques du produit. Ils doivent toujours garder à l'esprit que « faire ce qu'il faut est
toujours plus important que le faire correctement ».

Les analystes métier doivent considérer positivement les conflits entre les parties prenantes du
projet lors de la phase de collecte des exigences. Si ces conflits ne sont pas discutés et résolus à
ce stade précoce du projet, ils apparaîtront plus tard comme des CR (demandes de
changement) à coût élevé lors des phases de développement et de test. Les CR sont la
principale source de déchets au PDLC car ils

- ne peut pas être planifié,

- entraîner une dérive du périmètre,

- provoquer une paralysie de l'analyse,

- générer des coûts cachés,

- sont pour la plupart urgents,

- ont des impacts à la fois directs et indirects sur diverses parties du produit, et

- peut entraîner une charge de test de régression.

Dans l'approche Lean, les analystes commerciaux doivent être conscients des facteurs qui
entraînent des CR et essayer de les prévenir. La raison principale des CR est les
« problèmes et lacunes dans le processus de collecte, de documentation et de gestion des
exigences ».

Ces types de CR doivent être évités de manière proactive en appliquant les meilleures
pratiques suivantes tout au long de la phase de collecte des exigences d'un projet de
développement de produit :

- Prendre conscience que l'innovation ne peut se faire au niveau technique. L'innovation consiste à formuler
des solutions qui répondent au mieux aux besoins des utilisateurs.

- Lors des réunions de collecte des besoins, soyez centré sur le client et demandez : "Quels sont les
besoins des clients et comment le nouveau produit y répondra-t-il ?" au lieu de demander « Quelles
devraient être les caractéristiques techniques du nouveau produit ? »

- Soyez ouvert d'esprit, trouvez des options de solutions alternatives et évitez les discussions
superficielles "soit/ou" sur les fonctionnalités du produit.

- Équilibrez le niveau de pensée créative par rapport à la pensée critique lors des réunions
de collecte des exigences. Au début du projet, soyez aussi créatif que possible. Mais
lorsque vous commencez une analyse détaillée des besoins, faites preuve d'esprit critique.
La pensée critique signifie poser les bonnes questions précises et les vérifier avant de
supposer qu'elles sont correctes.

- Lors des réunions, préparez-vous à dire non même aux bonnes idées des unités
commerciales si ces idées ne sont pas alignées sur les besoins commerciaux et utilisateurs
du produit.

- Bien que les analystes commerciaux et les chefs de projet puissent avoir un niveau de
connaissances commerciales et techniques suffisant, les équipes techniques doivent toujours être
invitées aux réunions de collecte des exigences afin de mieux évaluer la faisabilité technique des
exigences.

- N'essayez pas de trouver les réponses aux questions pourquoi (nous avons besoin du
produit), quoi (le produit fait), comment (le produit fait) et techniquement comment (le produit
fonctionne) au cours d'une seule réunion. Pour les projets à grande échelle, effectuez des
des sessions d'entretiens, de groupes de discussion et d'ateliers si votre projet n'est pas un
projet urgent et accéléré.

Aller à la Gemba

- N'écoutez pas la voix des clients uniquement des propriétaires de produits et des représentants
des unités commerciales. Des techniques d'élicitation, telles que l'observation, doivent être utilisées
pour observer les clients lors de l'utilisation des produits ou de leurs prototypes. Dans l'approche
Lean, cela est décrit comme "aller au gemba".

Oui-Hommes contre Non-Hommes

- Lors des réunions de recueil des besoins, préparez-vous à affronter à la fois les oui et les non des
business units. Les oui-hommes sont plus dangereux que les non-hommes. Ils sont silencieux et
amicaux lors des réunions de collecte des besoins, mais deviennent agressifs et extrêmement
exigeants plus tard lors des tests d'acceptation des utilisateurs. Bien que les nomen soient
généralement considérés comme des fauteurs de troubles, ils sont plus utiles pour identifier et
résoudre les conflits aux premières étapes du projet. La résolution de ces conflits précoces évite le
gaspillage dû à des demandes de modification coûteuses à des stades ultérieurs du projet de
développement de produit.

Perfectionnistes vs Overlookers

- Dans l'approche lean, les exigences recueillies auprès des personnes perfectionnistes et négligentes
doivent être analysées avec soin. Les perfectionnistes se concentrent généralement sur les détails des
caractéristiques des produits de faible priorité. D'un autre côté, les négligents peuvent induire l'équipe
de projet en erreur en sapant même les fonctionnalités hautement prioritaires du produit.

Une image vaut mieux que mille mots

- Bénéficiez du prototypage lors des réunions de recueil des besoins pour aider les
participants à visualiser les besoins dans leur tête.

Effet d'observateur quantique

- La manière de poser les questions lors des réunions de recueil des besoins est
également importante. L'effet d'observateur en mécanique quantique stipule que "par
l'acte de regarder, l'observateur affecte la réalité observée". De même, lors des
réunions de recueil des besoins, poser des questions de manière biaisée impacte
objectivité des réponses des participants.

- Lors des réunions de recueil des besoins, donner les bonnes réponses aux mauvaises questions
est plus dangereux que de donner les mauvaises réponses aux bonnes questions. Les mauvaises
questions induisent l'équipe en erreur, génèrent des conflits, font perdre du temps au projet et
entraînent un échec. Les analystes commerciaux doivent préparer des questions simples, objectives
et précises pour ces réunions.

Le conflit est une norme mais pas une exception

-Lors des réunions de collecte des exigences, n'ayez pas peur des conflits et des
négociations entre les participants. Plus il y a de conflits résolus à ce stade précoce,
moins il y a de RC pendant le projet.

- Essayer de clarifier l'ensemble des enjeux lors des réunions de recueil des besoins. Ne les reportez
pas en entrant dans une base de données des problèmes. La gestion des problèmes signifie
reporter les problèmes.

- Ne soyez pas désespéré lors des réunions de recueil des besoins lorsque le nombre
de conflits augmente et que les problèmes se compliquent. Dans ces moments-là,
pensez que le projet n'est pas sorcier comme à la NASA ou au CERN, et n'exagérez pas
ces situations. Au lieu d'abandonner tôt, souvenez-vous du conseil d'Henry Ford : « Il
n'y a pas de gros problèmes ; il y a juste beaucoup de petits problèmes.

- Appliquer la technique de la « décomposition fonctionnelle » pour diviser les problèmes en parties

plus petites et les résoudre un par un. Au besoin, bénéficiez de la technique des « cinq pourquoi »,
qui consiste à poser des questions de manière itérative comme base de la question suivante jusqu'à
trouver la cause première d'un problème particulier.

Effet papillon dans la théorie du chaos

-Lorsqu'une demande de changement est reçue, analysez son impact en amont et en aval sur
tous les niveaux d'exigences. Selon la théorie de l'effet papillon dans le chaos, un petit
changement à un endroit dans un système complexe peut entraîner des effets importants
ailleurs. Les détails de la formation d'un ouragan peuvent être influencés même par le
battement des ailes d'un papillon à un endroit précis plusieurs semaines plus tôt. Ceci est
également valable pour les CR. Une RC considérée comme mineure peut entraîner un effet
papillon sur de nombreux autres composants du produit et nécessiter un gros effort.
6. Documentation des exigences
Les fonctionnalités que les clients n'utilisent pas après la sortie sont une grande source de
gaspillage. La principale raison de ce problème est le manque d'orientation client lors de l'approche
traditionnelle d'analyse et de conception centrée sur le produit.

Définir les détails des besoins des utilisateurs en utilisant la technique du « cas d'utilisation » dans la
méthodologie en cascade et la technique de la « histoire d'utilisateur » dans la méthodologie agile aide
les équipes de projet à être plus centrées sur le client.

Technique de cas d'utilisation :

Dans l'analyse basée sur les cas d'utilisation de la méthodologie en cascade, les besoins des utilisateurs sont
définis en trois étapes :

1. Qui sont les acteurs ?

Les acteurs cibles sont définis.

2. Quels sont les objectifs (cas d'utilisation) des acteurs ?

Les besoins des utilisateurs (cas d'utilisation) correspondent aux objectifs des acteurs. Les cas d'utilisation sont
présentés sur un diagramme de cas d'utilisation, qui illustre également la portée de haut niveau.

Pour le projet de développement d'applications mobiles CEC, le diagramme de cas d'utilisation ci-
dessous a été défini :
3. Comment les acteurs atteindront-ils leurs objectifs ?

Dans la méthodologie en cascade, les activités des acteurs pour atteindre leurs objectifs peuvent être présentées sur

des documents de cas d'utilisation.

Comme mentionné précédemment, la portée de la première phase du projet d'application mobile

CEC comprenait uniquement les cas d'utilisation « Afficher et commander un produit » et
« Comparer les produits ». L'interaction des clients CEC avec l'application mobile pour atteindre ces
objectifs a été définie sur des documents de cas d'utilisation. Le cas d'utilisation "Afficher et
commander un produit" a été documenté comme suit :
Dans la documentation des cas d'utilisation, les meilleures pratiques suivantes doivent être prises en compte :
- Des scénarios sur le document de cas d'utilisation décrivent les activités des acteurs tout en
atteignant leurs objectifs.

- Chaque étape du scénario (activité) correspond à un besoin fonctionnel.

Lors de l'application de la technique des cas d'utilisation, il peut y avoir confusion sur la
différence entre un cas d'utilisation et une exigence fonctionnelle. En fait c'est assez simple.
Chaque cas d'utilisation représente un objectif particulier d'un acteur, tandis que les activités
pour atteindre cet objectif sont des exigences fonctionnelles.

Expliquons cette relation par une analogie : Si une bouteille est considérée comme un produit, « l'eau
potable » est un cas d'usage, puisqu'il s'agit d'un objectif d'un acteur dans l'utilisation de la bouteille.
Mais "ouvrir le bouchon de la bouteille" n'est pas un cas d'usage, car ce n'est pas un objectif particulier
de l'acteur. Les gens n'achètent pas de bouteilles pour ouvrir et fermer leurs bouchons. L'ouverture du
bouchon de la bouteille n'est qu'une exigence fonctionnelle pour atteindre l'objectif d'« eau potable ».

De même, "Afficher et commander un produit" est un cas d'utilisation pour l'application mobile
CEC, tandis que la "sélection de catégorie" est l'une des nombreuses exigences fonctionnelles
pour atteindre ce cas d'utilisation spécifique.

- Séparez les scénarios principaux, alternatifs et d'exception du cas d'utilisation.

Le scénario principal sur un document de cas d'utilisation représente le flux positif (chemin
heureux) des activités pour atteindre l'objectif de l'acteur dans des conditions normales.

Les scénarios alternatifs définissent d'autres manières possibles d'atteindre le même objectif.

Les scénarios d'exception définissent les activités de l'utilisateur dans des conditions exceptionnelles et
d'erreur.

Pour le cas d'utilisation "Afficher et commander un produit" dans l'application mobile

CEC, si la recherche d'un article en naviguant dans les catégories est décrite dans le
scénario principal, les activités discrètes nécessaires pour trouver cet article à l'aide de
la fonctionnalité "Rechercher" doivent être défini dans un scénario alternatif.
L'interaction entre le client et l'application mobile CEC lorsque le client tente de
commander un article en rupture de stock doit être définie comme un scénario
d'exception.

- Définir les scénarios d'exception séparément des scénarios alternatifs.

Des scénarios alternatifs peuvent inclure des conditions intéressantes qui peuvent être
reporté aux prochaines versions, au cas où il y aurait une latence dans le projet. Cependant, les
scénarios d'exception incluent des conditions d'erreur et doivent être implémentés dans tous les
cas.

- Utiliser des documents de cas visant à répondre Quel (fonctionnalités nécessaires pour
répondre aux besoins des utilisateurs) et comment (exigences non fonctionnelles et règles
métier).

Clarifier le techniquement comment (dynamique technique interne) la question n'est pas l'objectif
d'un document de cas d'utilisation. Par conséquent, n'incluez pas de détails techniques dans les
documents de cas d'utilisation. Selon le principe « juste à temps » de l'approche Lean, les exigences
techniques doivent être définies ultérieurement dans un document de conception technique
séparé.

- Définissez des scénarios de cas d'utilisation avec le point de vue des utilisateurs, mais n'incluez pas les détails de

l'interface utilisateur. Ces détails sont définis ultérieurement sur les prototypes et dans les annotations de l'interface

utilisateur basées sur les définitions de scénarios de cas d'utilisation.

Par exemple, "le client sélectionne une catégorie en cliquant sur les boutons au milieu de l'écran"
est une mauvaise définition d'activité de scénario. "Le client sélectionne une catégorie" est juste
suffisant.

- Outre les exigences fonctionnelles, définissez également les exigences non fonctionnelles, les règles
métier et les hypothèses sur les documents de cas d'utilisation.

- Définir des règles métier de manière paramétrique.

Cela permettra à l'équipe de projet de concevoir, développer et modifier facilement les règles métier en
cas de besoin.

Par exemple, dans le cas d'utilisation « Afficher et commander un produit », « L'utilisateur est
averti par un message indiquant qu'une commission de 1 % sera facturée pour les livraisons
express » est une définition d'exigence fonctionnelle erronée. Au lieu de cela, il doit être défini
comme "L'utilisateur est averti par un message indiquant qu'un taux de commission sera
facturé pour les livraisons express (BR1)." Les règles métier dans ce scénario doivent être
définies dans la section des règles métier du même document de cas d'utilisation. La règle
métier dans cet exemple doit être définie comme suit :

BR1 : Commission de livraison express = 1 %

- Définir les exigences non fonctionnelles, telles que la convivialité, les performances et la confidentialité,
pour chaque cas d'utilisation de manière vérifiable (testable).

Par exemple, "Une fois que le client a confirmé le paiement, un rapport de confirmation de
commande doit s'afficher rapidement" n'est pas une définition correcte des exigences de
performance. Il doit être défini comme suit : "Une fois que le client a confirmé le paiement, un
rapport de confirmation de commande doit s'afficher dans les deux secondes."

- Limiter les hypothèses aux conditions dans lesquelles l'utilisateur n'a aucun contrôle.

Par exemple, « les données de disponibilité des produits reçues du module d'inventaire ERP sont à
jour et exactes » peut être une hypothèse pour le cas d'utilisation « Afficher et commander un
produit ». Mais « les articles qui seront commandés par le client sont en stock » n'est pas une
hypothèse correcte. Le comportement du client et de l'application mobile CEC, au cas où le client
tente de commander un article en rupture de stock, doit être défini comme un scénario d'exception
sur le document de cas d'utilisation. Sinon, des hypothèses non clarifiées créeront de nombreux
problèmes au niveau de la conception de l'interface utilisateur, de la conception technique et des
étapes de développement et entraîneront un gaspillage dû à un travail imprévu.

- Bénéficiez d'organigrammes pour visualiser des scénarios de cas d'utilisation.

Dans l'histoire, les gens ont d'abord utilisé des dessins pour communiquer entre eux. Même après
l'invention des lettres, ils ont continué à utiliser le dessin comme moyen facile de s'exprimer. De
même, l'utilisation de diagrammes tels que des organigrammes est un moyen efficace de visualiser
des scénarios de cas d'utilisation et de clarifier les ambiguïtés dans les définitions d'exigences
narratives sur du texte en clair, des documents de cas d'utilisation

Les organigrammes sont utiles pour modéliser et décrire les flux de travail avec des conventions de
création de diagrammes simples. Un organigramme doit être créé pour chaque cas d'utilisation.
Chaque branche d'un organigramme représente le scénario principal, alternatif ou d'exception d'un
cas d'utilisation.

L'organigramme ci-dessous représente le cas d'utilisation "Afficher et commander un produit" de

l'application mobile CEC. Les branches du graphique montrent des scénarios de ce cas d'utilisation
spécifique.
Technique des histoires d'utilisateurs

Contrairement à la cascade, la méthodologie agile se concentre sur « les produits fonctionnels plutôt que
sur une documentation complète ».

Dans Scrum, les exigences sont définies comme des histoires d'utilisateurs courtes et simples (En tant que
"rôle", je veux un "objectif") en parallèle avec la déclaration de manifeste ci-dessus.

Comme mentionné précédemment, la méthodologie agile scrum a été appliquée à la deuxième

phase du projet d'application mobile CEC. Au lieu de documents de cas d'utilisation détaillés, de
simples user stories ont été définies à cette phase.

Certaines des histoires d'utilisateurs incluses dans le carnet de produit du projet d'application
mobile CEC étaient les suivantes :

- En tant qu'utilisateur, je peux commenter les produits CEC afin que d'autres clients puissent
connaître mon expérience.

- En tant qu'utilisateur, je peux évaluer les produits CEC afin que d'autres utilisateurs puissent
bénéficier de mon avis dans leurs décisions d'achat.

- En tant qu'utilisateur, je peux voir les commentaires et les évaluations des clients publiés via
l'application mobile, également sur la page Web CEC, afin que je puisse prendre une meilleure
décision dans la sélection des produits.

- En tant qu'utilisateur, je peux rechercher l'adresse des magasins revendeurs CEC les plus proches afin
d'aller voir les produits que je compte acheter.

- En tant qu'utilisateur, je peux suivre l'état d'une commande afin de pouvoir organiser mon temps pour
la livraison du produit à mon domicile.

- En tant qu'utilisateur, je peux annuler ma commande sur l'application mobile afin de ne pas avoir
pour contacter le centre d'appels.

- En tant qu'utilisateur, je peux obtenir des offres promotionnelles sur l'application mobile lorsque je suis
à proximité d'un point de vente afin de pouvoir visiter le magasin et voir le produit à un prix réduit.

- En tant qu'utilisateur, je peux obtenir des coupons de réduction lorsque je me connecte à un produit CEC via
une application mobile afin de pouvoir les utiliser pour payer moins cher mes achats ultérieurs.

- En tant qu'utilisateur, je peux également me connecter à l'application mobile CEC avec mes comptes de
réseaux sociaux afin de pouvoir facilement publier des informations sur les produits CEC.

Les user stories sont légères par rapport aux cas d'utilisation. Pour rendre les user stories plus
spécifiques et descriptives pour l'équipe de développement, des critères d'acceptation doivent
être définis pour chaque user story. Les critères d'acceptation doivent également inclure les
exigences non fonctionnelles et les règles métier associées à chaque user story.

Certains des critères d'acceptation définis pour le projet d'application mobile CEC étaient
les suivants :
Avons-nous toujours besoin d'analystes métier dans les projets agiles ?
Les user stories sont définies et priorisées sur le backlog produit par un représentant
de la business unit (product owner). Il ou elle est la voix du client. Dans la formulation
théorique, il n'y a pas besoin d'analystes métier ou de leurs documents d'exigences
détaillés car le propriétaire du produit et l'équipe de développement agile, composée
de développeurs et de spécialistes de l'assurance qualité (AQ), travaillent ensemble au
même endroit sous la coordination d'un scrum master. .

Cependant, dans la pratique, il y a quelques difficultés à réaliser ce cadre

théorique.

Les Product Owners (manquant de connaissances techniques) ont des difficultés à parler le
même langage avec les équipes techniques (avec peu ou pas de connaissances métier). Cela
rend plus difficile la traduction des besoins de l'entreprise en exigences.

De plus, les propriétaires de produits peuvent rarement passer suffisamment de temps avec
l'équipe agile pendant les périodes chargées de leur propre service, ce qui rend la situation encore
plus difficile.

Pour éviter ces problèmes, les analystes métier ont commencé à jouer le rôle de Product
Owner ou ont été impliqués dans l'équipe technique qui était composée uniquement de
développeurs et de spécialistes QA.

Qu'il s'agisse d'une méthodologie en cascade ou agile, les meilleures pratiques suivantes doivent être
appliquées dans la documentation des exigences pour éviter le gaspillage et assurer la meilleure
communication entre les parties prenantes du projet :

Principe Lean du "juste assez"

L'un des principaux objectifs de l'approche Lean est d'éliminer le gaspillage en réduisant
l'inventaire des travaux en cours (WIP). Chez PDLC, les documents d'analyse et de conception
inutilement longs représentent WIP. Pour minimiser les travaux en cours et éliminer le
gaspillage, les documents d'analyse et de conception doivent être "juste suffisants". Ils doivent
être concis sans surcharge d'informations. Ils ne doivent inclure que ce qui est absolument
nécessaire.

Comme l'exprime la phrase "Une image vaut mille mots", les diagrammes d'analyse métier, tels que
les diagrammes de cas d'utilisation, les organigrammes et les diagrammes de contexte, doivent être
utilisés pour réduire la surcharge d'informations sur les documents d'exigences.

Lors de la phase de documentation des exigences, l'objectif ne doit pas être de produire des
documents fantaisistes et des diagrammes élégants qui ne seront lus par personne d'autre
que l'analyste d'affaires qui l'a préparé. Au lieu de cela, l'objectif devrait être de créer des
produits qui répondent au mieux aux besoins de l'entreprise et des clients en utilisant des
documents d'exigences et des diagrammes comme outils.

Nous avons besoin de documents d'exigences pendant le projet pour traduire les besoins de
l'entreprise et des clients en exigences pour une meilleure compréhension des développeurs,
et après le projet pour les utiliser comme référentiel d'exigences lors des futures
améliorations/modifications des produits.

Le niveau de détail des documents doit être calibré en fonction des besoins et des conditions
spécifiques du projet afin de satisfaire au mieux les objectifs ci-dessus.

Si le niveau de détail des documents est trop faible, il existe un risque de définition incomplète
des exigences. Dans ce cas, les équipes techniques doivent deviner les caractéristiques du
produit. Ils créent des produits qui manquent aux exigences critiques, ce qui déclenche un
cercle vicieux de CR (demandes de modification). Et parfois, ils intègrent des fonctionnalités
supplémentaires qui ne sont pas incluses dans les documents d'exigences, pensant que les
clients seront ravis de les voir. Cette situation est appelée « placage à l'or ». Les CR et le placage
à l'or sont des facteurs qui entraînent une dérive de la portée et donc des déchets au cours du
projet.

Dans la vie quotidienne, ce serait le chaos s'il n'y avait pas de règles de gouvernance. Par exemple, bien
que les feux de signalisation semblent nous ralentir, la circulation serait bloquée sans eux. Les
documents d'exigence sont comme les feux de circulation dans les grandes villes. Si nous ne les utilisons
pas, le projet démarre rapidement mais est bloqué à un stade ultérieur. Cependant, dans les petites
villes, nous n'avons pas besoin de placer des feux de circulation partout. De même, dans les projets à
petite échelle, nous n'avons pas besoin d'utiliser des documents d'exigences très détaillés.

Lorsque les membres de l'équipe se trouvent à des endroits discrets, cela peut limiter la
collaboration entre les parties prenantes du projet. Le même problème peut être observé sur des
projets externalisés. Dans ces situations, le niveau de détail des documents doit être augmenté
pour assurer la clarté et l'exactitude des exigences.

Les documents préparés lors de la phase d'analyse et de conception du projet servent

également de référentiel d'exigences. Cela rend le déploiement des futures
améliorations et modifications du produit beaucoup plus facile et plus rapide. Ainsi, les
documents d'exigences doivent être tenus à jour même après le projet pour servir de
référentiel d'exigences en cas de besoin lors de modifications futures des produits.
Cela fera gagner beaucoup de temps à l'équipe de projet responsable des travaux
ultérieurs d'amélioration/modification et évitera un gaspillage considérable dans
l'avenir.
Principe Lean du "juste à temps"

Au PDLC,

- la réponse à la question "techniquement comment" (configuration requise) dépend de la

réponse de

- la question « comment » (exigences non fonctionnelles et règles métier), qui

dépend de la réponse de

- la question « quoi » (besoin utilisateur, besoin fonctionnel), qui dépend

de la réponse de
- la question « pourquoi » (besoins de l'entreprise).

Selon le principe du « juste à temps » dans l'approche lean, ces questions doivent recevoir
des réponses dans l'ordre et doivent être définies sur des documents séparés.

Premièrement, les exigences commerciales et les exigences des utilisateurs doivent être définies et
répertoriées dans des documents d'analyse de rentabilisation ou de vision et de portée ; Ensuite, les
exigences fonctionnelles, les exigences non fonctionnelles et les règles métier doivent être
documentées sur des documents de cas d'utilisation ou des user stories, selon la méthodologie
choisie. Ensuite, les exigences du système doivent être documentées sur les documents de
conception technique. Les définir dans un seul document d'exigences créera beaucoup de
complexité et de confusion pour les unités commerciales et les équipes techniques.
7. Conception UX et convivialité
La meilleure expérience utilisateur (UX) sur un produit ne peut être obtenue que si l'utilisabilité est
également positionnée comme une exigence incontournable tout au long du processus d'analyse et de
conception, en plus de la fonctionnalité et des préoccupations esthétiques visuelles.

L'utilisabilité est le critère qui détermine la facilité d'utilisation d'un produit pour ses utilisateurs. Même s'il est
très élégant et doté de grandes fonctionnalités, un produit ne peut répondre pleinement aux besoins de ses
utilisateurs que s'il est utilisable. Ainsi, les fonctionnalités inutilisées des produits créent une énorme quantité
de déchets.

Approche de Gaudi

Tout au long de l'histoire de la conception architecturale, Gaudi a été l'architecte le

plus célèbre avec son approche de conception architecturale centrée sur l'utilisateur.
Durant son enfance, Gaudi a souffert d'une mauvaise santé. Cette situation l'a
empêché d'aller à l'école et il a passé la plupart de son temps dans la nature. Ses
observations de la nature ont inspiré sa démarche de conception, qui peut se résumer
ainsi : « Le grand livre toujours ouvert, et qu'il faut s'efforcer de lire, c'est celui de la
Nature. En utilisant cette philosophie, il a conçu des bâtiments au «style organique»,
qui sont ensuite devenus un standard important en architecture.

Humanisation des produits

Un autre homme a révolutionné l'industrie de la haute technologie d'une manière similaire. En

plaçant les utilisateurs au centre du processus d'analyse et de conception, Steve Jobs a dirigé
l'innovation des produits électroniques grand public les plus utilisables jamais créés.

Il a réussi à créer des utilisateurs naturels de ses produits. Même les enfants peuvent utiliser les
appareils mobiles de son entreprise avec des gestes similaires à leur comportement naturel. Cette
nouvelle approche de conception a fait de son entreprise la plus performante de l'industrie de la haute
technologie.

Après le succès de cette approche, on s'est rendu compte que l'humanisation des produits n'est pas
nécessairement obtenue par des caractéristiques anthropomorphiques mais principalement en
garantissant l'utilisabilité.

Construire des interfaces utilisateur autour des utilisateurs

Une approche de conception UX allégée, à la fois centrée sur l'utilisateur et itérative, doit être appliquée
pour garantir la convivialité d'un nouveau produit.

A. Identifier les profils d'utilisateurs

« Concevoir pour tout le monde » n'est pas une stratégie réalisable et efficace en termes de convivialité.
Les interfaces d'un produit sont utilisables si elles conviennent à ses utilisateurs. Ainsi, la conception de
l'interface utilisateur d'un produit doit être basée sur le profil de ses groupes d'utilisateurs cibles. Le
profilage peut être effectué en fonction de diverses caractéristiques des utilisateurs, telles que :

- âge,

- le genre,

- éducation,

- le niveau de confort d'utilisation de l'ordinateur,

- niveau de confort du smartphone, et

- fond d'affaires.
Pour le projet d'application mobile CEC, le profilage des clients était le
suivant :
Un moyen efficace de comprendre les profils des utilisateurs lors des sessions de collecte
des besoins consiste à demander aux utilisateurs leur avis sur les produits existants. Les
commentaires des utilisateurs peuvent être interprétés pour comprendre leurs propres
capacités et faiblesses. Cela nous rappelle une citation du célèbre philosophe Spinoza : « Si
Pierre raconte quelque chose sur Paul, on en apprend plus sur Pierre que sur Paul.

En plus des entretiens et des réunions de groupe de discussion avec les utilisateurs, les concepteurs UX
doivent également mener des techniques d'analyse de terrain, telles que l'observation et l'analyse des
tâches de l'utilisateur, pour observer les utilisateurs dans leur propre contexte, puis les profiler en
conséquence.

B. Définir les personas et leurs modèles mentaux

Un autre aspect important de l'orientation utilisateur est la conception émotionnelle. Les êtres humains
jugent les produits en fonction des capacités logiques de leur cerveau gauche et des capacités
émotionnelles de leur cerveau droit. Et la plupart du temps, l'émotion est le critère principal dans leurs
jugements pour acheter un produit.

En accord avec leurs émotions, les utilisateurs créent d'abord un modèle mental des produits qu'ils
utilisent. Ce modèle les guide tout au long de leur expérience avec le produit. Par conséquent, les
conceptions d'interface utilisateur doivent être basées sur le modèle mental des utilisateurs plutôt
que sur celui des concepteurs.

Les personas, qui sont des personnages imaginaires représentatifs, sont le meilleur moyen de
définir les modèles mentaux de divers profils d'utilisateurs et de prédire leur interaction attendue
avec le produit et leur comportement sur les interfaces utilisateur. Bien qu'il puisse y avoir plusieurs
profils d'utilisateurs pour un produit, les concepteurs UX doivent limiter le nombre de personas à
trois (ou quatre au maximum dans les cas extrêmes) pour éviter de tomber dans le piège du
« concevoir pour tout le monde ». Une description de personnage doit inclure un nom, une photo,
des informations démographiques et une section de scénario.

Pour le projet d'application mobile CEC, l'équipe UX a défini les deux personas suivants
après avoir analysé les profils des utilisateurs et travaillé avec la business unit marketing.
C. Conception d'interactions

Dans l'approche de conception lean UX, répondre aux besoins des utilisateurs avec un nombre minimum
d'étapes sur les interfaces utilisateur du produit est très apprécié. Ceci peut être réalisé par une bonne
conception de l'interaction.

"L'architecture commence là où l'ingénierie se termine" —Walter Gropius

S'ils sont bien définis, les organigrammes visualisant les scénarios de cas d'utilisation constituent une base parfaite

pour l'interaction de conception des utilisateurs avec le produit.

Lors de la conception de l'interaction, les cases des branches de l'organigramme sont regroupées dans
des conteneurs. Ces conteneurs (boîtes en pointillés) deviennent une fenêtre d'interface utilisateur
principale, une boîte de dialogue ou une boîte de message. Ou plusieurs conteneurs se combinent et
forment une seule interface utilisateur. Les liens entre les conteneurs d'organigramme deviennent des
éléments de navigation, tels que des liens. Cette méthode, qui repose principalement sur le
regroupement des exigences, permet de limiter le risque de manquer une fonctionnalité
sur les interfaces utilisateur du produit. Il évite également les décalages entre le flux des scénarios
de cas d'utilisation et le flux des interfaces utilisateur, et garantit la convivialité.

Pour le projet d'application mobile CEC, des organigrammes ont été utilisés pour la conception
d'interaction comme suit :

[Link] des informations

Les interfaces utilisateur des produits sont composées non seulement d'exigences fonctionnelles
(tâches) mais aussi d'exigences de contenu.
Par conséquent, parallèlement à la conception de l'interaction (basée sur les exigences
fonctionnelles), l'architecture de l'information (basée sur les exigences de contenu) doit également
être conçue. L'objectif principal de la conception de l'architecture de l'information est d'identifier les
exigences de contenu, de définir les catégories de contenu et de finaliser les structures de
navigation des interfaces utilisateur d'un produit en utilisant des techniques telles que le tri des
cartes et les wireframes.

Dans l'approche Lean, le contenu des interfaces utilisateur d'un produit doit avoir deux
attributs principaux :

1. Concis
- Avoir des déclarations courtes et précises

- Ne laissez aucune place à une mauvaise interprétation

- Avoir un contenu simple et exprimé avec un minimum de mots. Cette citation de

Mark Twain décrit très bien cette situation : « Je n'ai pas eu le temps d'écrire une
courte lettre, alors j'en ai écrit une longue à la place.

2. Utile
- Le contenu des interfaces utilisateur doit supprimer la friction du produit avec ses utilisateurs. Les
interfaces utilisateur doivent parler la langue des utilisateurs, pas celle des équipes techniques.

- Plutôt que d'offrir une approche unique, le contenu doit répondre aux besoins d'information
des personnes cibles. Les représentants de Persona doivent avoir le sentiment que le contenu
des interfaces utilisateur du produit est créé spécialement pour eux.

- Le contenu doit avoir des liens clairs et des CTA (appels à l'action) qui aident les
utilisateurs à naviguer intuitivement sans trop réfléchir.

Tri des cartes

Si le contenu n'est pas regroupé correctement, les utilisateurs auront du mal à trouver ce qu'ils
recherchent sur les interfaces utilisateur du produit. Il s'agit d'un type courant de défaut
d'utilisation.

Le tri des cartes est une technique d'architecture de l'information efficace pour empêcher ce
risque. Il est utilisé pour catégoriser le contenu.

Dans la technique de tri de cartes, les éléments de contenu sont écrits sur des cartes et les utilisateurs qui

représentent des personnages sont invités à regrouper ces éléments.

En utilisant une étude de tri de cartes, la structure des catégories de produits de l'application mobile
CEC a été définie comme suit :

E. Conception de l'interface utilisateur

Les concepteurs UX convertissent les conceptions d'interaction et les architectures d'information en interfaces
utilisateur de produits en appliquant les principes de conception UX et d'utilisabilité.

Même les concepteurs les plus expérimentés ne peuvent pas produire la conception optimale dès le
premier essai. Une bonne conception est le résultat de plusieurs itérations. L'itération est un cycle
consistant à faire quelque chose, à le tester, à l'améliorer et à le retester.

Faire des itérations sur le produit final est une approche très coûteuse. Parce qu'à
chaque itération, les composants techniques du produit doivent être modifiés et
retestés, alors que changer le prototype est beaucoup plus simple et rapide que de
changer le produit final.

Dans l'approche Lean, l'équipe de projet et les clients doivent fréquemment se

réunir et évaluer la fonctionnalité et la convivialité du produit dès les premiers
prototypes.
Des outils de prototypage récents permettent de modéliser les produits et de les simuler de
manière interactive. Ils autorisent les actions de l'utilisateur, telles que la navigation entre les
interfaces, la sélection d'options et la réception de notifications par des messages d'erreur. Grâce à
ces fonctionnalités interactives, les défauts liés à la fonctionnalité et à l'utilisabilité peuvent être
détectés et corrigés dès les premières étapes du projet sans attendre les tests d'acceptation des
utilisateurs sur le produit final.

Par cette approche itérative, un nombre élevé de RC peut être évité. De plus, la détection
précoce des défauts, sans attendre les tests tardifs d'acceptation par l'utilisateur, réduit le coût
de leur réparation et élimine le gaspillage.

Dans l'approche Lean, les prototypes sont également considérés comme des stocks de travaux en cours.
Ainsi, au lieu de modéliser chaque interface utilisateur et de créer du gaspillage, les concepteurs UX
devraient créer les prototypes d'interfaces utilisateur correspondant uniquement aux fonctionnalités
prioritaires les plus fréquemment utilisées.

Pour le projet d'application mobile CEC, l'équipe BA-Works n'a simulé que les interfaces utilisateur
des fonctionnalités de produit hautement prioritaires qui ont été développées avec l'approche en
cascade lors de la première phase du projet. Pour atteindre la simplicité, les interfaces utilisateur de
l'application mobile comprenaient tout ce dont les utilisateurs avaient besoin et rien de superflu.

Le fait d'avoir des conceptions d'interaction basées sur des cas d'utilisation et des organigrammes
bien préparés a permis à l'équipe de projet de créer facilement des prototypes de fonctionnalités
hautement prioritaires qui constituaient la version principale du produit. L'équipe a détecté et
corrigé les défauts liés à la fonctionnalité et à l'utilisabilité dès le début du prototype avant de le
commercialiser. Cela a permis d'éviter une quantité considérable de déchets dus aux CR potentiels.
Avons-nous besoin de prototypes dans les projets agiles ?

Comme mentionné précédemment, la méthodologie agile a été appliquée à la deuxième phase du

projet d'application mobile CEC. Pour minimiser l'inventaire WIP, notre équipe n'a pas créé de
prototype de user stories. Au lieu de cela, des parties fonctionnelles de l'application mobile
correspondant aux user stories ont été utilisées pour les tests fonctionnels et d'utilisabilité.

Pour les projets agiles, si les user stories ont le bon niveau de granularité et sont atomiques,
les parties fonctionnelles du produit peuvent être développées rapidement et utilisées pour
tests fonctionnels et d'utilisabilité au lieu de passer plus de temps pour le prototypage.

Dessins parfaits de Picasso

Lors du prototypage, les concepteurs UX et les analystes commerciaux peuvent hésiter lorsqu'ils
envisagent de se comporter comme un artisan ou un artiste. Jusqu'à la Renaissance, la majorité des
architectes concevaient leurs artefacts avec une approche artisanale. L'esthétique était toujours
importante pour les architectes, mais leur principale préoccupation était de concevoir des
bâtiments, des ponts et des fontaines qui répondaient le mieux aux besoins du public. Après
l'impact de la liberté et de la créativité de la Renaissance, les architectes ont commencé à se
comporter davantage comme des artistes et se sont concentrés sur la conception de pièces plus
esthétiques.

Au lieu d'essayer de créer des conceptions parfaites pour Picasso avec une approche artistique, les
analystes commerciaux et les concepteurs UX devraient toujours se comporter comme des artisans lors
du prototypage. Ils doivent se concentrer sur la satisfaction des besoins fonctionnels des clients de la
manière la plus utilisable, laissant les préoccupations esthétiques aux concepteurs visuels. En résumé, ils
doivent créer des prototypes qui montrent principalement comment les interfaces utilisateur du produit
interagiront avec les utilisateurs sans ses cloches et sifflets visuels.

Moins est Beaucoup En savoir plus sur l'approche Lean

Avec l'approche Lean, les interfaces utilisateur des produits doivent être conçues suffisamment
simples pour ne laisser aucun besoin d'apprendre à utiliser le produit. Les meilleures interfaces
utilisateur sont simplistes et intuitives, sur lesquelles les utilisateurs peuvent facilement trouver ce
qu'ils recherchent et effectuer leurs tâches avec un minimum d'efforts et d'erreurs.

De l'autre côté, des interfaces chargées et bruyantes rendent l'expérience compliquée pour les
utilisateurs. Ce type de conception peut être facilement créé en répartissant les spécifications
fonctionnelles de manière aléatoire sur différentes parties des interfaces utilisateur sans trop de
réflexion sur la conception.

Le footballeur légendaire Johan Cruyff a dit un jour : « Le football est simple. Mais rien n'est plus
difficile que de jouer au football simple. De même, il n'est pas si facile de créer des conceptions
d'interface utilisateur simplistes et intuitives. Les conceptions simplistes nécessitent du temps et
des efforts supplémentaires.

Le secret pour atteindre la simplicité dans le design est mieux expliqué dans la
citation du célèbre romancier Antoine de Saint Exupéry : "Un designer sait qu'il a
atteint la perfection non pas quand il n'y a plus rien à ajouter, mais quand il n'y a
plus rien à enlever".
Cependant, dans la simplification des interfaces utilisateur, il faut aussi retenir une citation
d'Einstein pour prévenir le risque de fausse simplicité : « Tout doit être rendu aussi simple
que possible, mais pas plus simple. Les parties inutiles de l'interface utilisateur doivent être
supprimées pour simplifier les interfaces, à moins que la suppression de ces parties
supprime toute fonctionnalité du produit.

Cartographie du parcours client

Pour le projet d'application mobile CEC, notre équipe a appliqué une technique d'évaluation de
l'expérience client appelée cartographie du parcours client en plus des méthodes
traditionnelles de test d'utilisabilité.

La cartographie du parcours client était un outil efficace pour visualiser et évaluer

l'expérience de bout en bout des clients CEC à différents points de contact. Du point de
vue des clients, leur expérience, leurs émotions et leur niveau de satisfaction à chaque
étape du parcours ont été visualisés.
En plus d'explorer les domaines d'amélioration des canaux d'interaction, cette étude a
également aidé l'équipe à déterminer si la valeur souhaitée était créée pour les clients à
chaque point de contact.

Par exemple, lors de la deuxième phase du projet, les fonctionnalités supplémentaires suivantes ont
été identifiées comme résultat de l'étude de cartographie du parcours client :

- Les clients doivent être en mesure d'évaluer et de commenter la qualité du service du revendeur après
la livraison et l'installation des produits.

- Les commentaires et évaluations des clients sur les produits CEC publiés via
l'application mobile doivent également être affichés sur la page Web.
8. Conception technique et DevOps
Refactoring et tolérance aux changements futurs

En raison de la nature itérative de l'approche Lean, l'architecture technique d'un produit doit permettre
des révisions avec des fonctionnalités nouvelles et mises à jour dans les versions ultérieures.

Au cours du développement itératif, si le produit a une intégration intensive entre ses composants,
les événements suivants se produisent :

L'équipe livre les parties A et B du produit sans aucun problème majeur lors des premières
itérations. Néanmoins, l'équipe se rend compte qu'elle doit apporter des modifications aux
parties A et B tout en travaillant sur la partie C car elle a des points d'intégration avec ces
parties. En d'autres termes, A et B doivent être refactorisés bien qu'ils aient déjà été publiés.

Refactoriser signifie changer l'architecture technique existante d'un produit sans changer
son comportement, et c'est toujours plus difficile que de développer à partir de zéro. Ces
allers-retours avec des efforts de refactorisation difficiles rendent la construction et la
livraison du produit avec des composants intégrés encore plus difficiles lors des itérations
ultérieures.

Architectures spaghettis

Ces efforts de refactorisation fréquents nécessitent d'excellentes compétences en conception

et développement d'architecture au sein de l'équipe technique. Que la méthodologie choisie
soit agile ou en cascade, les architectes doivent formuler une conception d'architecture
technique très flexible. Sinon, l'architecture ressemblera davantage à des spaghettis avec des
ajouts et des mises à jour aux itérations suivantes. Cela se traduira par un produit fragile avec
des problèmes de performances, de sécurité, de prévisibilité et de fiabilité.

Modèles de données flexibles

Pour construire une architecture technique hautement flexible, le modèle de données du produit
doit être paramétrique et flexible. De cette façon, les besoins excessifs de migration et de
conversion de données, dus aux nouvelles exigences transactionnelles et de reporting, peuvent être
évités.

Lors de la phase de recueil des besoins du projet d'application mobile CEC,

l'équipe BA-Works a défini les exigences de reporting. Ils comprenaient :

- Part du canal mobile dans le chiffre d'affaires total

- Chiffre d'affaires du canal mobile par concessionnaire

- Chiffre d'affaires du canal mobile par catégorie de produit

- Chiffre d'affaires du canal mobile par produit

- Taux de conversion montrant combien de clients ont commandé un produit lorsqu'ils ont
utilisé l'application mobile

- Efficacité des notifications de campagne contextuelles affichées sur l'application

mobile.

Pour créer une architecture technique flexible, les analystes commerciaux de BA-Works ont pris en
compte tous les besoins transactionnels et de reporting de l'application mobile CEC lors de la
conception de son modèle de données, illustré ci-dessous.

Performances et fiabilité
Dans l'approche lean, l'élégance d'un produit ne se limite pas seulement à ses aspects
visuels. Un produit élégant est celui qui propose une valeur maximale à ses clients avec
le plus haut niveau de fiabilité et de performance. Le principal facteur de fragilité d'un
produit est sa complexité technique. Cela est généralement dû à l'intégration d'un
nombre excessif de fonctionnalités dans un produit dont la capacité matérielle est
limitée.

Une des solutions à ce problème est de construire une architecture technique ouverte
permettant au produit de communiquer avec d'autres produits en transmettant des
données entre eux et en partageant leurs fonctionnalités complémentaires. De cette façon,
un seul produit n'a pas à inclure toutes ces fonctionnalités. Ce type d'architecture
technique ouverte est le principal moteur des capacités des technologies portables qui
vont au-delà de leurs propres capacités.

Par exemple, les utilisateurs d'un compteur de pas simple et portable peuvent également gérer leur régime

alimentaire et leurs programmes d'entraînement personnels via ses interfaces mobiles en se connectant à d'autres

produits tels que des balances électroniques et des appareils de fitness.

Big Data

Avec le temps, les données générées par les produits peuvent atteindre une grande échelle. Ce niveau de
données ne peut pas y être stocké en raison de la capacité matérielle limitée. Pour surmonter ce défi, les
données peuvent être stockées et gérées sur le cloud. Cependant, cela ne fera que créer un gaspillage au
niveau des données, à moins que les entreprises n'utilisent les technologies du Big Data pour générer des
informations précieuses pour les utilisateurs de leurs produits.

Par exemple, les compteurs de pas portables mentionnés précédemment fournissent des informations utiles et motivantes,

telles que la comparaison des statistiques d'activité et de régime alimentaire de l'utilisateur avec les résultats d'autres

utilisateurs. Ils effectuent également une analyse en temps réel des données d'activité quotidienne et de régime alimentaire

de l'utilisateur et envoient des notifications au cas où ils ne pourraient pas atteindre les niveaux cibles. De telles informations

sur les données volumineuses enrichissent la proposition de valeur de ces produits, qu'il s'agisse de simples compteurs de

pas ou d'assistants de vie sains.

DevOps

En raison de la nature itérative de l'approche Lean, le produit est mis en ligne en plusieurs
versions. Parfois, les produits développés dans les délais prévus ne peuvent pas être
publiés à temps en raison de problèmes de déploiement.
Pour atténuer les risques de déploiement, tels que les latences, les taux d'échec élevés et les longs
délais de réparation et de récupération, les équipes opérationnelles doivent commencer à travailler
avec les équipes techniques lors de la conception et du développement des produits et être
toujours synchronisées avec elles. Sinon, le déploiement sera toujours un goulot d'étranglement et
créeradéchets de niveau opérationnel à chaque sortie du produit.
9. Assurance qualité et tests
Dans l'approche Lean, les défauts du produit entraînent un gaspillage au niveau de la qualité en raison du temps et

des ressources consacrés à les trouver, les réparer et les retester.

Pour éliminer ce type de gaspillage, les principes des organismes mondiaux d'assurance
qualité et de test, tels que l'ISTQB® (International Software Testing Qualifications Board),
doivent être appliqués dans le cycle de vie du développement du produit :

Les tests montrent la présence de défauts.

Les tests montrent la présence de défauts mais ne peuvent pas prouver l'absence de défauts. Les
efforts de test réduisent le nombre de défauts non découverts sur le produit mais ne peuvent
prétendre à zéro défaut.

Dans l'approche lean, l'équilibre entre le délai de mise sur le marché et la qualité du produit doit être
bien établi. Bien que cela ne soit pas souhaité, un produit peut même être mis en service avec des
défauts de faible priorité au cas où le délai de mise sur le marché serait très critique. Cela se produit
généralement lors de la première itération d'un projet afin de publier un produit plus tôt que les
concurrents. Ces défauts peuvent ensuite être corrigés lors d'itérations ultérieures.

Un test exhaustif est impossible.

Il n'est pas possible de tester chaque partie d'un produit en raison des limites de temps et de
ressources. Dans l'approche Lean, les efforts de test doivent se concentrer sur les zones à haut
risque plutôt que sur des tests exhaustifs. La hiérarchisation des risques doit être effectuée en
fonction de l'impact potentiel et des niveaux de probabilité. De cette façon, le gaspillage dû à des
efforts de test excessifs peut être évité.
Pour la plupart des projets, les documents d'exigences sont utilisés comme base pour les cas de
test. Cependant, les cas de test ne doivent pas seulement contenir des scénarios positifs sur les
documents d'exigences ; elles doivent également couvrir les conditions d'essai négatives. Ces
conditions de test négatives peuvent être identifiées en appliquant des techniques de test basées
sur les risques, telles que FMEA (Failure Mode and Effect Analysis).

L'application de techniques de test de boîte noire, telles que le partitionnement d'équivalence, la valeur
limite et l'analyse combinatoire, permet d'obtenir une couverture de test suffisante avec un minimum de
données de test. Ces techniques évitent le gaspillage en éliminant le besoin de données de test
excessives.

Premiers tests

Le cycle de vie du développement produit est comme un fleuve avec des exigences à sa source. Si
vous ne pouvez pas nettoyer la rivière à sa source, vous aurez une rivière sale qui coule en bas de la
colline. Une approche réactive plutôt que proactive pour nettoyer la rivière augmentera les coûts et
les risques de façon exponentielle.

En raison de la gravité de cette situation, les équipes d'assurance qualité doivent être plus
proactives et commencer les tests le plus tôt possible au cours du cycle de développement du
produit. La résolution des défauts précoces évite le gaspillage dû à des correctifs coûteux à des
étapes ultérieures. Sans attendre le développement du produit final, les tests doivent être
lancés tôt par des revues sur les documents d'exigences et des tests utilisateurs sur
prototypes. Ce faisant, les défauts liés à la fonctionnalité et à l'utilisabilité peuvent être
facilement détectés et corrigés dès les premières phases du projet.

Paradoxe des pesticides

Si les mêmes types de tests sont répétés encore et encore, le même ensemble de cas de
test n'aidera plus à trouver de nouveaux défauts sur le produit. Pour surmonter ce
«paradoxe des pesticides», les cas de test doivent être régulièrement revus et mis à jour.
Ainsi, le gaspillage dû à des efforts de test inefficaces sera évité.

Pour garantir une couverture suffisante, les équipes d'assurance qualité doivent constituer la base de test en
fonction des exigences et des règles métier sur les documents d'analyse et les combiner avec des conditions de
test basées sur les risques.

Au cours de la première phase du projet d'application mobile CEC, le scénario de test "Afficher et
commander un produit" a été défini comme suit en fonction des scénarios principaux, alternatifs et
d'exception du document de cas d'utilisation concerné :
Comme le montre l'exemple ci-dessus, les documents de cas d'utilisation qui ont des scénarios détaillés
constituent une bonne base pour les cas de test. Lorsque la méthodologie agile est appliquée,
cependant, les user stories et leurs critères d'acceptation n'ont pas ce niveau de détail. Pour garantir une
couverture de test suffisante, les équipes d'assurance qualité des projets agiles doivent travailler en
étroite collaboration avec les propriétaires de produits et les autres représentants des unités
commerciales pendant les tests.

Tests automatisés

Dans l'approche itérative du lean, ajouter de nouveaux composants à un produit en direct sans
affecter ses pièces déjà publiées revient à changer le pneu d'une voiture pendant qu'elle roule.

Cette approche de développement itérative nécessite des tests de régression complets des
composants du produit qui ont déjà été publiés dans les itérations précédentes. Pour assurer une
couverture de test suffisante, les pièces avec des points d'intégration directs et indirects doivent
être retestées. Cela apporte une énorme quantité d'efforts de test supplémentaires. Tester les
mêmes composants manuellement et de manière répétitive est à la fois chronophage et peu
pratique. Pour rendre ce processus plus efficace, des suites de tests de régression automatisées
peuvent être créées.

Cependant, l'automatisation elle-même est un projet difficile. Les chefs de projet doivent considérer
le temps nécessaire à la mise en œuvre des outils d'automatisation comme un élément de risque
distinct dans chaque projet. Ils ne doivent pas utiliser un outil d'automatisation pour la première
fois dans un projet urgent et prioritaire. L'équipe doit se concentrer sur le projet,
au lieu d'allouer son temps limité à la mise en œuvre de l'outil. Les chefs de projet doivent
se rappeler que la haute direction tient toujours compte du score mais pas de la façon
dont l'équipe a joué pendant le match.

Dans un processus de test de régression automatisé, les procédures de test sont capturées sous forme de scripts de

test lors du premier cycle de test, puis exécutées automatiquement lors des cycles de test suivants. Cependant,

l'automatisation des tests n'est pas un moyen magique de trouver des défauts en appuyant sur un seul bouton. La

plupart du temps, des problèmes techniques surviennent sur les outils d'automatisation des tests lors de la

génération des scripts de test. La résolution de ces problèmes nécessite des compétences techniques avancées. Pour

cette raison, l'automatisation des tests devrait toujours relever de la responsabilité des équipes techniques

d'assurance qualité plutôt que des analystes commerciaux.

Dans certaines circonstances, les tests manuels deviennent plus efficaces que les tests automatisés ;
il faut beaucoup plus de temps pour générer des scripts de test automatisés que pour exécuter des
cas de test manuellement. Surtout dans les projets urgents et urgents, cela se traduit par une
situation étrange de codage autour des bogues au lieu de les trouver et de les corriger. Les chefs de
projet et les responsables AQ doivent considérer ce problème comme un risque du projet. Ils
doivent atténuer ce risque en déterminant le bon niveau d'automatisation des tests.

Vaisselle
Ces dernières années, nous avons commencé à voir une autre catégorie de
« matériel » (comme le matériel et les logiciels). Cette catégorie s'appellevaisselle. Shelfware
représente le logiciel d'automatisation qui se trouve sur les étagères de l'entreprise sans être
utilisé par une seule personne.

Les étagères causent une énorme quantité de déchets au niveau de l'outil. Dans certaines entreprises
publiques, les coûts élevés de licence et de support payés pour des étagères inutiles sont même devenus
un problème étudié lors des audits internes.

Pour éviter la situation des étagères, les gestionnaires doivent savoir que les outils d'automatisation
sont des assistants mais pas des magiciens. Ils ont des limites. Ils ne peuvent qu'aider l'équipe de
projet à faire son travail de manière plus pratique en automatisant certaines tâches, mais pas
toutes. Si la maturité du processus d'AQ de l'organisation est à un bon niveau, l'automatisation le
rend meilleur ; sinon, l'automatisation peut même l'aggraver. Par conséquent, les responsables
doivent d'abord se concentrer sur l'amélioration de leurs compétences en matière d'assurance
qualité et de test, puis donner le feu vert à l'initiative d'automatisation. Si l'équipe n'a que peu
connaissance des méthodes et des techniques de test, l'automatisation n'apportera que des problèmes
supplémentaires plutôt que des avantages.

UAT est le dernier point de filtrage des défauts.

Même avec l'existence d'une équipe QA distincte, les analystes commerciaux devraient être
chargés de coordonner et de guider les unités commerciales pendant les UAT (tests
d'acceptation des utilisateurs). L'UAT est l'étape finale pour valider les exigences et assurer la
satisfaction des besoins commerciaux du nouveau produit. Si l'UAT n'est pas mené
efficacement, les utilisateurs finaux trouveront des défauts après la publication, ce qui
entraînera une perte d'argent et de réputation.

Pour augmenter l'efficacité de l'UAT, les utilisateurs doivent d'abord effectuer des tests basés
sur l'expérience sans exécuter de cas de test. Ensuite, un autre cycle UAT doit être organisé
pour assurer une couverture de test suffisante en exécutant des cas UAT. Les analystes métier
peuvent préparer des cas UAT en simplifiant les cas de test générés par les équipes QA.

Normalement, la formation des utilisateurs doit être dispensée après l'UAT si le nouveau produit
remplace un produit existant. Les utilisateurs pourront tester le produit de manière plus
indépendante et impartiale. Mais, si le produit est nouveau, la formation des utilisateurs doit être
effectuée avant l'UAT. Sinon, les utilisateurs auront des difficultés à utiliser le produit, qui est
complètement nouveau pour eux, ce qui se traduira par des taux de couverture des tests plus
faibles et des durées d'UAT plus longues.
10. Gestion de projet
Alors que les chefs de projet sont responsables de portée du projet gestion, les analystes
commerciaux sont responsables de portée du produit la gestion.

La portée du produit représente les fonctionnalités du produit pour répondre aux besoins de
l'entreprise et des utilisateurs, tandis que la portée du projet est définie comme le travail qui
doit être accompli pour créer et publier le produit avec ces fonctionnalités spécifiées. Par
conséquent, afin de définir correctement la portée du projet, le chef de projet doit aider les
analystes commerciaux à définir une portée de produit claire et correcte alignée sur les
besoins de l'entreprise et des utilisateurs. Sinon, les ressources sont enracinées dans la
mauvaise direction, et cela se traduit pardéchets au niveau du projet.

Piège de sortie

Outre la gestion de la portée, la gestion du temps et des coûts sont les autres domaines de
connaissances critiques en gestion de projet. Parfois, la pression pour respecter les objectifs de
temps et de budget peut amener les chefs de projet à se concentrer davantage sur la
génération de résultats (livrables) que sur les résultats (valeur). Cependant, si les exigences ne
peuvent être satisfaites, le projet ne sera pas couronné de succès même s'il est achevé dans les
délais et dans les limites du budget. Pour éviter ce piège du « résultat » et assurer la livraison
de « résultats » à valeur ajoutée, les chefs de projet doivent toujours travailler en collaboration
avec les analystes commerciaux pour assurer la création de valeur à chaque étape du projet. Ils
doivent garder toutes les parties prenantes du projet connectées tout au long du cycle de
développement du produit.

Pour y parvenir, les chefs de projet doivent gérer le projet sur le terrain. Certains chefs
de projet passent la plupart de leur temps au PMO (bureau de gestion de projet) au
lieu d'assister à des réunions de collecte des exigences, d'examiner les documents
d'exigences et de participer à des sessions de test.

Dans l'approche Lean, les chefs de projet doivent se rendre au gemba et avoir une
communication à haut débit avec les parties prenantes du projet et les clients tout au long
du cycle de développement du produit.

Optimisation complète au lieu de sous-optimisation

L'approche Lean vise à supprimer les freins et contrepoids au sein du projet

parties prenantes pour assurer la collaboration.

Bien que la séparation des tâches soit importante pour gérer la responsabilité entre les membres de
l'équipe, elle ne doit pas entraîner de cloisonnement.

Les silos se forment généralement en raison de la microgestion d'équipes distinctes telles que des
analystes commerciaux, des concepteurs, des développeurs et des spécialistes de l'assurance
qualité. La microgestion se traduit par une sous-optimisation des objectifs de chaque groupe avec
des KPI (indicateurs clés de performance) axés sur les résultats, tels que le nombre d'exigences
documentées, le nombre de défauts trouvés ou le nombre de codes construits. Mais dans
l'approche lean, les KPI visent à optimiser les objectifs de toute l'équipe. Par exemple, des KPI tels
que "le nombre d'exigences utilisateur satisfaites lors d'une version spécifique" ou "le pourcentage
d'objectifs d'exigences commerciales atteints lors de la première version" aideront le chef de projet
à garder chaque partie prenante du projet motivée dans la même direction pour générer la valeur
souhaitée pour les clients. .

En appliquant l'approche Lean pour la première fois, les chefs de projet doivent se
rappeler que "ce n'est pas la force des vagues qui façonne les rochers, mais c'est leur
persistance". Ainsi, au lieu d'abandonner tôt, ils devraient continuellement motiver
leurs équipes à appliquer les principes et techniques lean à leurs projets en gérant tout
type de résistance interne.

Fin de l'histoire à la société CEC

Grâce à l'application de l'approche Lean au projet de développement d'applications

mobiles CEC, l'équipe de projet a réussi à être axée sur la valeur, centrée sur le
client et itérative tout au long du projet. Cela a aidé la société CEC à satisfaire tous
les objectifs du projet ci-dessous :

- Se différencier en ayant un canal mobile plus tôt que toutes les autres entreprises
d'électronique grand public

- Être innovant dans la création d'un canal de vente mobile avec des fonctionnalités directement
axées sur les besoins des clients CEC

- Éviter le gaspillage en n'investissant que dans les fonctionnalités qui étaient vraiment nécessaires

- Améliorer l'échelle qui était autrefois limitée au nombre et à la visibilité des concessionnaires

- Satisfaire l'unité commerciale marketing en publiant l'application mobile au moment où

elle l'a demandé
- Soyez conscient des risques tôt et atténuez-les rapidement

Le projet a été achevé dans les délais à la grande satisfaction de tous les intervenants
du projet. Pour ce projet, la haute direction a réalisé les avantages de l'approche Lean
et a décidé d'appliquer cette approche à tous les autres projets.
Indice