Création du product backlog

Créez votre product backlog en suivant les bonnes pratiques de Pega, y compris la DCO (Direct Capture of Objectives).

Une solution Pega repose sur deux concepts fondamentaux :

• Le parcours, qui décrit l'interaction qu'a un client avec une entreprise pour atteindre un objectif.
• Le Microjourney™, qui décrit les interactions qu'un type de client spécifique a par le biais d'un canal spécifique pour atteindre cet objectif.

Le processus de définition d'une solution commence par l'identification du Minimum Lovable Product (MLP)...

... le chemin le plus simple pour satisfaire votre client.

Ce MLP se compose d'un ou de plusieurs Microjourneys.

La première étape de la création d'une solution consiste à identifier les Microjourneys qu'elle doit faciliter.

Pour chaque parcours, la création d'une solution implique ainsi les étapes suivantes :

• Définir l'objectif du parcours client
• Identifier l'ensemble des personas qui visent cet objectif
• Identifier chaque canal par lequel les personas atteignent cet objectif
• Créer un tableau présentant les combinaisons valides de ces différentes informations

Si vous disposez déjà d'un backlog de type de dossier, l'onglet Work Backlog (illustré ici) vous présente automatiquement ces informations.

Si vous utilisez Pega Infinity™, les Microjourneys et les informations liées sont peut-être déjà enregistrés dans l'outil.

Par exemple, décomposez deux parcours en Microjourneys.

Votre client vous indique qu'il souhaite principalement permettre à ses clients :

• d'obtenir un premier prêt immobilier ;
• de refinancer leur prêt immobilier.

Les conversations avec votre client révèlent la liste des personas et canaux appropriés pour chaque parcours.

En échangeant avec le product owner et éventuellement d'autres experts issus de l'entreprise (les « subject matter experts » ou SME), vous découvrez quels personas utilisent quels canaux dans le contexte d'un parcours spécifique.

Créez un tableau de ces informations, comme celui présenté ici. Chaque ligne définit l'un de vos Microjourneys.

La seconde étape de la création d'une solution consiste à prioriser les Microjourneys identifiés.

La priorité d'un Microjourney dépend de trois attributs :

• Tout d'abord, la valeur métier du Microjourney :
  • Il s'agit de la valeur que présente pour l'entreprise l'objectif client qui est atteint par un persona par le biais d'un canal spécifique.
  • L'évaluation de cette valeur intervient généralement par des échanges avec le product owner.
• Ensuite, la difficulté estimée de l'implémentation du Microjourney :
  • L'évaluation de cette difficulté intervient généralement par des échanges avec le lead system architect (LSA) ou une autre ressource technique expérimentée.
• Enfin, l'estimation de l'effort nécessaire à l'implémentation du Microjourney :
  • Là aussi, cette clarification intervient généralement par des échanges avec le LSA ou une autre ressource technique expérimentée.

Pour déterminer la priorité des Microjourneys, vous devez ainsi associer leur valeur métier à leur simplicité d'implémentation prévue (combinaison de la difficulté et de l'effort nécessaire).

Chaque Microjourney doit alors faire partie de l'un des 4 groupes suivants :

• 1) Microjourneys présentant une valeur métier élevée et faciles à implémenter.
  • Ils présentent la priorité la plus élevée, car ils permettent de générer le plus de valeur possible en un minimum de temps.
  • Il s'agit donc de candidats de choix à l'inclusion dans la première version du MLP.
• 2) Microjourneys présentant une valeur métier élevée et difficiles à implémenter.
  • Ils présentent une priorité intermédiaire, car bien qu'ils soient moins faciles à mettre en œuvre que les Microjourneys du premier groupe, ils génèrent eux aussi une valeur métier importante.
  • Ils ne font généralement pas partie de la première version du MLP, mais sont pour la plupart inclus dans les versions qui la suivent.
• 3) Microjourneys présentant une valeur métier faible et faciles à implémenter.
  • Ils présentent une priorité faible, car leur valeur métier est limitée.
  • Ils sont toutefois souvent mis en œuvre, car la faiblesse de leur valeur peut être compensée par le faible nombre de ressources nécessaires.
• 4) Pour finir, Microjourneys présentant une valeur métier faible et difficiles à implémenter.
  • Ces Microjourneys ne sont généralement jamais implémentés, car leur valeur métier est insuffisante pour justifier le coût élevé de leur implémentation.

La dernière étape de la définition de votre solution consiste à regrouper les Microjourneys en versions MLP.

La première version du MLP est généralement composée des Microjourneys présentant la valeur métier la plus élevée et les plus faciles à implémenter.

Si l'ensemble des Microjourneys de ce groupe peuvent être implémentés avant la date cible de la version, déployez la version plus tôt au lieu d'essayer de la compléter. L'objectif est de proposer une véritable valeur ajoutée dès que possible, et la valeur maximale est offerte par les Microjourneys du premier groupe.

Si l'implémentation de l'ensemble des Microjourneys haute priorité risque de dépasser la date cible de la version, définissez le contenu du MLP1 en commençant par le début de la liste des Microjourneys prioritaires et incluez autant de Microjourneys que possible pendant le temps à votre disposition.

Vous pourrez inclure les Microjourneys prioritaires qui n'ont pas pu être ajoutés au MLP1 dans une version ultérieure, peut-être très peu de temps après la première version.

Dans le cas de solutions simples, les Microjourneys peuvent généralement être implémentés directement dans Pega. Il n'est habituellement pas nécessaire de créer un product backlog pour les projets de portée limitée.

D'autres projets imposent en revanche de traduire les Microjourneys en backlog de projet qui sera exploité par une équipe de delivery.

De manière générale, un product backlog est nécessaire si le projet est :

• déployé en plusieurs versions ;
• destiné à une entreprise soumise à de fortes contraintes réglementaires.

Un backlog est nécessaire pour ces projets, car leur organisation est très complexe. Documentation et priorisation des besoins métier, gestion du travail sur de nombreuses versions par plusieurs équipes, prises en charge des artefacts associés pour répondre aux obligations réglementaires en matière d'audit... Toutes ces tâches impliquent une organisation plus solide que celle permise par l'approche basée sur un prototype suivie pour les solutions simples. Le product backlog est la réponse de la méthodologie Scrum aux besoins de ces projets plus complexes.

Pour créer un product backlog, vous devez tout d'abord créer un produit et une version pour le MLP1 dans Agile Studio.

Ce faisant, vous créerez aussi un backlog par défaut pour cette version.

Bien que les exemples suivants utilisent Agile Studio, Pega peut également communiquer avec d'autres outils de gestion de projet agiles, comme Jira ou Team Foundation Server, pour assurer la gestion de la livraison de votre solution.

Maintenant que vous avez créé votre product backlog, votre prochaine étape consiste à enregistrer vos parcours dans Agile Workbench et Agile Studio.

Dans Agile Workbench, un parcours est enregistré en tant que fonctionnalité (ou « feature ») de niveau 1. Vous pouvez en effet imbriquer des fonctionnalités. Un parcours se place tout en haut de cette hiérarchie.

Dans Agile Studio, enregistrez le parcours sous forme d'objectif dans le produit que vous venez de créer.

Maintenant que vous avez enregistré vos parcours dans les deux outils, il est temps d'enregistrer vos Microjourneys.

Dans Agile Workbench, un Microjourney est enregistré comme fonctionnalité de niveau 2. Il s'agit d'une fonctionnalité enfant de la fonctionnalité de niveau 1, qui représente le parcours parent.

Dans Agile Studio, enregistrez chaque Microjourney sous forme d'epic sous l'objectif représentant le parcours parent.

Dernière étape de ce processus : créer les User Stories qui implémentent les Microjourneys que vous avez identifiés jusqu'ici.

Ces Stories sont généralement créées dans Agile Workbench.

Une User Story créée dans Agile Workbench est automatiquement synchronisée avec Agile Studio en temps réel et inversement. Ainsi, en matière de User Stories, Agile Workbench et Agile Studio sont toujours synchronisés.

Maintenant que vous êtes prêt à capturer les User Stories, comment devez-vous procéder ?

Selon l'approche de delivery de Pega, basée sur les parcours, la stratégie à privilégier pour la prise en compte et l'élaboration des User Stories passe par la Direct Capture of Objectives (DCO).

La DCO fait référence à la possibilité de prendre en compte directement et de manière visuelle les résultats métier tout en améliorant la façon dont le métier et le service informatique collaborent pour atteindre ces résultats.

Elle consiste à réunir le métier et le service informatique pour discuter d'une fonctionnalité ou d'une User Story, puis de créer une version initiale de cette fonctionnalité directement dans Pega pendant la discussion ou immédiatement après.

La DCO ne se limite pas à enregistrer les exigences dans une application Pega.

Il s'agit d'une technique d'élaboration de Stories qui vous permet de livrer de meilleures solutions plus rapidement.

Cette approche basée sur des modèles vous permet d'utiliser Pega Platform™ pour développer une solution de manière à la fois itérative et incrémentielle.

Il s'agit aussi d'un état d'esprit qui consiste à proposer de la valeur métier Microjourney par Microjourney tout en gardant en tête la feuille de route de l'entreprise.

C'est un processus à forte composante collaborative : de nombreux rôles ont l'opportunité d'y contribuer.

Équipe du projet :

• Le product owner est principalement responsable de la communication des informations sur chaque Story et de la fixation de leur priorité.
• Le business architect est responsable de la documentation de chaque Story et anime généralement les sessions de DCO.
• Le system architect doit s'assurer de comprendre les besoins métier de chaque Story pour permettre son implémentation.

Reste de l'entreprise :

• Les experts métier (SME) fournissent des informations complémentaires sur certaines Stories, souvent des détails spécifiques sur des processus métier qu'ils connaissent particulièrement bien.
• Le responsable des tests doit comprendre les aspects métier et technique de chaque Story pour pouvoir aider l'équipe de test à écrire des scénarios de test appropriés.
• L'architecte informatique fournit du contexte et une analyse des risques en lien avec la façon dont chaque Story doit être intégrée dans l'écosystème informatique de l'entreprise.

La DCO n'est pas ponctuelle. C'est une technique que vous utilisez fréquemment entre le début de votre projet et la disponibilité de votre solution.

Au cours de la phase de préparation (activités intervenant au début d'un projet), vous utilisez la DCO pour élaborer suffisamment de User Stories pour deux sprints. Ainsi, vous vous assurez que l'équipe delivery dispose de suffisamment de travail pour être occupée dès le début du projet.

Pendant la phase de création (build), vous continuez à utiliser la DCO pour élaborer les User Stories à implémenter dans les sprints suivants.

Vous utilisez également la DCO pour recueillir les feedbacks relatifs aux tâches effectuées dans la version actuelle.

La DCO n'est pas un outil. Elle est toutefois prise en charge par plusieurs outils de l'écosystème Pega.

App Studio vous permet de développer la vision d'une solution sous forme de modèle exécutable. Dès la première session de DCO, vos clients peuvent ainsi visualiser le framework de la solution qu'ils écrivent. Ils voient la solution prendre forme dans le framework sous forme d'application avec laquelle ils peuvent interagir dès le départ.

Integration Designer identifie clairement et facilement les besoins en données et le statut des points d'intégration correspondant à ces données. Il vous permet aussi de définir les types de données des entités métier, les data views sur lesquelles ils sont affichés et leurs systèmes d'enregistrement, et de générer des rapports sur ces sujets.

Agile Workbench vous permet d'enregistrer des Stories, des bugs et des feedbacks directement dans les studios Pega pendant les examens et les démonstrations. Les nouvelles Stories sont synchronisées automatiquement avec des outils de gestion de projets agiles comme Agile Studio.

Vérifiez vos connaissances avec l’interaction suivante.