Un monde en disruption… par Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de Pmgs.
Stéphane Derouin
Incertitude, risques et difficulté à gérer la transformation
Complexité, (a)synchronie et accélération des temps
Primauté de l’innovation
Déferlement du Digital qui « rebat les cartes »
Nouvelles générations, nouveaux entrants
Le Vertical ne répond plus ni aux besoins ni aux attentes : « Servant Leadership »
Montée de l’interdépendance, du collaboratif, « monde en réseau »
Waterfall ?
Mode déterministe et planifié – on connaît le périmètre du projet qui est placé sous la responsabilité d’un Project Manager. Adapté lorsqu’il y un besoin important de contrôle des spécifications et de maîtrise du périmètre du projet
Exemples : projets de pont, d’autoroute, de centrale nucléaire
Partenaire de DantotsuPM et le calendrier 2017 est déjà disponible !
Agile ?
Mode incrémental et collaboratif. On ne connaît pas le périmètre du projet et il est animé par un Scrum Master. Innovation, R&D, rupture technologique. Adéquation avec les besoins mouvants du projet ou du client
Les «Story Points» sont une unité de mesure pour exprimer une évaluation de l’effort total qui sera exigé pour entièrement mettre en œuvre un article de l’arriéré de produit (du « Product Backlog ») ou autre travail.
Quand nous évaluons avec des «Story Points», nous assignons une valeur de point à chaque article de l’arriéré de produit. Les valeurs brutes que nous assignons sont sans importance. Ce qui importe sont les valeurs relatives. Une histoire qui est assignée un 2 devrait représenter deux fois plus qu’une histoire qui est assignée 1. Elle devrait aussi être les deux-tiers d’une histoire qui est évaluée à 3 «Story Points».
Au lieu d’assigner 1, 2 et 3, cette équipe pourrait avoir assigné 100, 200 et 300. Ou 1 million, 2 millions et 3 millions. Ce sont les valeurs relatives qui importent, pas les chiffres isolés.
Qu’est-ce qui entre dans un « Story Point » ?
Parce que les «Story Points» représentent l’effort pour développer une histoire utilisateur, l’évaluation d’une équipe doit inclure tout ce qui peut affecter l’effort.
Cela pourrait inclure :
Le travail pour faire
N’importe quel risque ou incertitude dans la réalisation du travail
La complexité du travail
En évaluant avec des «Story Points», assurez-vous de considérer chacun de ces facteurs. Voyons comment chacun impacte l’évaluation d’effort donnée pour l’histoire en question.
Le travail pour faire
Certainement, s’il y a plus à faire pour réaliser quelque chose, l’évaluation d’effort devrait être plus importante. Considérez le cas simple de développer deux pages Web. La première page a seulement un champ et une étiquette demandant à entrer à un nom. La deuxième page a 100 champs qui attendent aussi à être simplement remplis d’un peu de texte.
La deuxième page n’est en rien plus complexe. Il n’y a aucune interaction entre les champs et chacun d’eux n’est rien de plus qu’un peu de texte. Il n’y a aucun risque additionnel sur la deuxième page. La seule différence entre ces deux pages est qu’il y a plus à faire pour la deuxième page.
On devrait donc donner plus de «Story Points» à la deuxième page. Cela ne mérite probablement pas 100 fois plus de points bien qu’il y ait 100 fois plus de champs. Il y a, après tout, des économies d’échelle et peut-être que le développement de la deuxième page est seulement 2, 3 ou 10 fois autant d’efforts que la première page.
Risque et incertitude
« Image courtesy of Stuart Miles / FreeDigitalPhotos.net »
La quantité de risque et incertitude dans un article d’arriéré de produit devrait affecter l’estimation en «Story Points» donnée à l’article.
Si on demande à une équipe d’évaluer un article d’arriéré de produit et le demandant est peu clair sur ce qui sera nécessaire, cette incertitude devrait être reflétée dans l’évaluation.
Si l’exécution d’une fonction implique le changement d’un morceau particulier de code ancien, fragile et qui n’a aucun essai automatisé en place, ce risque devrait être reflété dans l’évaluation.
Complexité
On devrait aussi considérer la complexité lors d’une évaluation de «Story Points». Repensez à l’exemple précédent de développer une page Web avec 100 champs de texte insignifiants sans interactions entre eux.
Pensez maintenant à une autre page Web, elle aussi avec 100 champs. Mais certains sont des champs date avec des gadgets de calendrier qui s’affichent en surimpression. Certains sont des champs de texte formatés comme des numéros de téléphone ou des numéros de sécurité sociale. D’autres champs ont des validations comme avec des numéros de carte de crédit.
Cet écran exige aussi des interactions entre des champs. Si l’utilisateur saisit une Carte Visa, on montre un champ CVV à trois chiffres. Mais si l’utilisateur saisit une carte d’American Express, on montre un champ CVV à quatre chiffres.
Bien qu’il y ait toujours 100 champs sur cet écran, ces champs sont plus difficiles à mettre en œuvre. Ils sont plus complexes. Ils prendront plus de temps. Il y a plus de chance que le développeur fasse une erreur et doive repasser dessus et la corriger.
Cette complexité complémentaire devrait être reflétée dans l’évaluation fournie.
Considérez tous les facteurs : Travail, Risque et Incertitude et Complexité
Il peut sembler impossible de combiner ces trois facteurs en un chiffre et le fournir en tant qu’évaluation globale. C’est cependant possible parce que l’effort est le facteur d’unification. Les experts considèrent combien d’effort sera exigé pour réaliser le travail décrit dans un article d’arriéré de produit.
Les experts considèrent alors combien d’effort inclure pour prendre en compte le risque et l’incertitude inhérentes à l’article d’arriéré de produit. D’habitude, ceci est fait en considérant le risque d’apparition du problème et l’impact si le risque survient vraiment. Ainsi, par exemple, plus d’effort sera inclus dans l’évaluation pour un risque consommateur de temps qui va probablement arriver que pour un risque mineur et peu probable.
Les experts considèrent aussi la complexité du travail à faire. Le travail complexe exigera plus de réflexion, pourra exiger une expérimentation plus empirique, peut-être plus d’interactions avec le client, pourra prendre plus longtemps à valider et avoir besoin de plus de temps pour corriger des erreurs.
Ces trois facteurs doivent être combinés.
Considérez tout dans la définition de fini (« done »)
Une évaluation de «Story Points» doit inclure tout ce qui est impliqué dans l’obtention d’un article d’arriéré de produit entièrement fini. Si la définition d’une équipe de « fini » inclut la création des tests automatisés pour valider l’histoire (et ce serait une bonne idée), l’effort de créer ces tests devrait bien sûr être inclus dans l’évaluation de «Story Points».
Les «Story Points» peuvent être un concept complexe à saisir.
Mais l’effort de bien comprendre que les «Story Points» représentent tout l’effort nécessité par le travail, la complexité du travail et tout risque ou incertitude dans le travail le vaut tout aussi pleinement.
Essayez Bubble Plan !
Quels autres conseils prenez-vous en compte dans l’évaluation des « story points » ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
PRINCE2 Agile est une solution de management de projet qui combine les qualités de gouvernance et de management de PRINCE2 avec la flexibilité des concepts Agile.
Partenaire de DantotsuPM
PRINCE2 Agile a été construit de manière collaborative avec des experts PRINCE2 et des « Agilistes ».
Partenaire de DantotsuPM
PRINCE2 Agile couvre les approches Scrum, Kanban, Lean Startup et Cynefin et utilise les principes de PRINCE2 avec 5 comportements clés:
Transparence
Collaboration
Communication
Auto Organisation
Exploration
Partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Le succès du management de projet Agile se base sur des conditions indispensables : des chefs de projet et des équipes impliquées et adaptables, des points réguliers, d’étroites relations avec le client, et un sens de l’organisation incomparable.
Alexis Sgaros
Dans un projet, le changement est normal. Tel est le principe sur lequel se base le management de projet Agile. Un changement qui peut toucher le besoin du client ou les technologies disponibles par exemple, et auquel le chef de projet et son équipe projet doivent être capables de s’adapter. Une méthode de travail qui s’est imposée assez naturellement dans le monde du développement de logiciel, mais qui peine davantage dans d’autres secteurs. « C’est tout un ensemble de fondamentaux à remettre en cause en termes de culture d’entreprise », selon Alexis Sgaros, formateur consultant chez CSP Formation. Cela signifie qu’il faut être en relation proche avec le client tout au long de la vie du projet, afin de s’assurer qu’on ne s’écarte pas de son besoin. En fait, le client fait presque partie de l’équipe.
NQI est Partenaire de DantotsuPM
Une organisation renforcée et un pilotage serré
De son côté, « l’équipe doit être plus fortement responsabilisée. Le chef de projet devient davantage un coach qui laisse l’équipe s’auto-organiser. » Aux membres de se porter volontaires pour accomplir des tâches spécifiques, avec des points à organiser, quotidiennement dans la plupart des cas, afin d’éviter les doublons et oublis. Alexis Sgaros prévient que « comme la zone d’incertitude est plus forte, le pilotage doit être plus serré. On a souvent l’impression que le management de projet Agile est plus simple et demande moins de rigueur, mais en réalité, il en demande plus en termes d’organisation. » Et de sens des priorités, puisqu’il faut réagir instantanément pour traiter d’abord les changements les plus urgents.
CSP est partenaire de DantotsuPM
L’émergence des méthodes hybrides
Attention : Une clé de la gestion de projet Agile est de travailler avec une équipe entièrement dédiée au projet, et physiquement sur le même site, ce qui n’est pas le cas de tous les projets. Au final, Alexis Sgaros remarque que « on a de plus en plus tendance à voir apparaître des méthodes hybrides. Il n’est pas rare que certaines parties d’un projet soient gérées en mode normal et d’autres en agilité. Bien sûr, cela demande une forte ouverture d’esprit du chef de projet, qui doit accepter que tout le monde ne travaille pas de la même manière. »
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je me rends compte que le concept de Sprint Zéro est controversé. Et dans mes premiers temps en Agile, j’ai été étonné par l’importance accordée à ce sujet. Je pensais que nous aurions des sessions de transfert de connaissances au fil du travail, alors, pourquoi avoir un sprint séparé ? Mais plus tard j’ai compris l’importance du Sprint Zéro dans l’organisation où je travaille. Je ne prétendrai pas que toutes les équipes en ont besoin, mais voici pourquoi c’est utile pour nous.
Les questions abordées au Sprint Zéro s’appliquent à la release toute entière.
Nous pourrions l’appeler Sprint Initial, Itération Zéro, ou Sprint de démarrage.
Selon mon expérience, le Sprint Zéro est limité dans le temps à seulement une semaine.
Notre équipe passe en revue l’ensemble des items de la release et quel travail devrait être achevé dans chaque sprint. En passant en revue chaque article de sprint, l’équipe identifie les endroits pour lesquels nous ne connaissons pas suffisamment bien les exigences qu’elles soient matérielles, d’architecture, logicielles, ou techniques.
Après que l’équipe ait revu les épics (ndlt. groupe de User Stories pour fournir une valeur métier) et fonctions priorisés de l’arriéré de produit, nous devons les annoter et préparer les sessions de revue avec le product owner, le propriétaire de produit. Nous devons comprendre l’environnement et le code exigé pour les items de l’arriéré de produit, indépendamment de si le code sera simple ou complexe.
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)
La raison principale d’introduire un Sprint Zéro est que nous ne voulons pas inutilement prolonger le temps nécessaire aux sessions de revue ou de transfert de connaissance depuis le Sprint 1 jusqu’à la fin. Donc, nous prenons une semaine pour préparer notre équipe avant de démarrer sur des arriérés de sprint.
Grâce à Agile, on nous donne l’opportunité d’en apprendre beaucoup en peu de temps.
L’équipe avancera de façon calme, sans pression excessive.
CertYou est partenaire de DantotsuPM
Utilisez-vous un sprint 0 en début de release sur votre projet Agile? Pourquoi? Quels en sont pour vous les bénéfices et inconvénients ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
« Nos entreprises doivent devenir plus Agiles », certes, mais comment ?
L’émergence de la gestion de projet agile n’est qu’une première manifestation d’un phénomène socio-économique mondial touchant toutes les sphères d’activités des organisations, qu’elles soient privées ou publiques.
Relisez l’article de Claude Emond sur la gestion de projet Agile
L’environnement dans lequel les organisations de ce début de 21e siècle évoluent est de plus en plus volatile, incertain, complexe et ambigu (VUCA), et ce, en grande partie à cause des changements nombreux qui se matérialisent tout azimut. Pour bien fonctionner dans un tel environnement, tous les experts disent que nos entreprises doivent devenir plus agiles.
Mais être «plus agiles», qu’est ce que ça veut dire? Qu’est-ce que ça implique et requiert au juste? C’est ce que nous allons découvrir ensemble lors de cette conférence-atelier.
Conférenciers : Claude Émond et Charlotte Goudreault, associés principaux, coach et formateurs en agilité organisationnelle chez QualiScope Inc (précédent billet sur la gestion de projet Agile)
Le jeu d’introduction de pairs est une activité de développement de l’esprit d’équipe pour que les nouveaux membres de l’équipe en apprennent davantage les uns des autres. Une conversation rapide suivie par introduction par un pair fournit un mécanisme rapide de présenter chaque personne dans un grand groupe.
Avez-vous également expérimenté cet exercice « brise-glace » ?
Comment diriger l’activité
Divisez le grand groupe par paires. Demandez aux gens de se mettre avec quelqu’un qu’ils ne connaissent pas bien.
Demandez aux paires d’avoir une conversation rapide l’un de l’autre et informez-les que plus tard ils présenteront leur partenaire. Vous pouvez laisser la conversation ouverte, ou choisir quelques questions auxquelles répondre (comme : nom, lieu de naissance, rôle actuel, nourriture préférée, lieu de voyage préféré).
Faites le tour du grand groupe et laissez tout le monde présenter son alter-ego.
Microsoft est partenaire de DantotsuPM
Exemple
Paulo dit: « Je vous présente Amit. Il est né au Canada, mais sa famille est en Inde. Il aime la samba brésilienne et sa nourriture préférée est le hot-dog, plus particulièrement en assistant à une partie de base-ball. Il travaille actuellement comme … »
Essayez Bubble Plan !
Note: J’ai été surpris la première fois que l’on m’a invité à faire cet exercice dans le cadre d’une réorganisation et de la mise en place d’une nouvelle équipe de management.
Questions: Avez-vous également expérimenté cet exercice « brise-glace » ? En connaissez-vous d’autres ?
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.
En fait, je vais aller plus loin et poser une affirmation audacieuse :
Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.
En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.
« Les plans ne sont rien. La planification est tout. »
Ceci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.
Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.
Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :
Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.
Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?
Pourquoi les projets entrent-ils dans une telle spirale ?
Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information
Les projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :
Peu ou pas d’informations sur le travail qui a besoin d’être fait
Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)
Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).
Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:
« Aucun plan ne survit au contact avec l’ennemi. »
Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.
Les projets agiles planifient à plusieurs reprises par petits morceaux
Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).
Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :
Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
Pouvant être achevé en un sprint (qui est souvent de deux semaines).
Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.
Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.
Un si petit plan apporte-t-il vraiment de la valeur ?
Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».
Bien sûr, mais deux points :
Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.
Une grande partie de la valeur réside dans la Planification, pas dans le Plan.
Rappelez-vous la précédente citation de Eisenhower.
Les membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.
Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?
Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.
Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.
Get the book on Amazon
Déroulé de l’activité
Donnez à chaque participant un marqueur et un post-it
Demandez-leur de décrire leur sentiment (dans le contexte de la réunion) en un mot
Groupez les notes sur une grande page
Optionnellement, demandez si quelqu’un veut en dire plus sur leur mot choisi
Décrivez s’il vous plaît < le dernier sprint ou le mois passé ou vos sentiments sur XYZ > en un mot !
Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.
Microsoft est partenaire de DantotsuPM
I.N.V.E.S.T.
I – Indépendante
N– Négociable
V– de Valeur
E – Estimable
S – Suffisamment petite
T – Testable
Indépendante
Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.
Négociable
Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.
de Valeur
Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.
Estimable
Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».
Suffisamment petite
Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.
Testable
Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.
Découpage vertical ou horizontal
Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.
Des exemples de découpe de « User Stories »
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits
Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…
En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.
Et/ou
En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.
Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.
Découpage par flux de travail
revoir mon panier de courses
Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :
Fournir mes informations bancaires
En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.
En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
Recevoir une notification par SMS
En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.
D’autres méthodes
Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :
Visitez le blog Agilistic
par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
par options d’interaction / par plate-forme
par types de données ou paramètres
par scénarios de test
par rôles
par ‘j’optimisemaintenant ‘ contre ‘ j’optimise plus tard ‘
par compatibilité de navigateur
la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.
Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.
En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.
Partenaire de DantotsuPM
Premier terme Agile – Initiation
A few videos to get started on Agile, Scrum and Kanban
Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.
Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.
De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.
Partenaire de DantotsuPM
En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.
Second terme Agile – Work package (Lot de travail)
Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des frontières comprises et communicables.
Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.
Troisième terme Agile – Tolérance
Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.
Partenaire de DantotsuPM
Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.
Produit Viable Minimum (MVP)
La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.
Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.
Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
HP vient de publier les résultats d’une recherche qui tend à confirmer que Agile est devenue la norme dans les développements informatiques !
Les jeunes sont moteurs…
…et les plus âgés sont également favorables aux approches Agile car ils y voient un moyen de décloisonner les organisations et de mieux collaborer sur les projets.
Les uns comme les autres n’oublient pas en adoptant Agile les objectifs business que cette approche permet d’atteindre en matière de satisfaction client, délais de mise en production (« Time To Market ») et coûts totaux de développement.
En effet, cette étude conduite auprès de plus de 600 professionnels de l’informatique indique que bien que l’adoption de Agile n’est réellement débutée que depuis 5 ans, elle s’est répandue « à la vitesse grand V » comme le montre la courbe ci-dessous que vous trouverez dans le rapport complet.
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
It also aims to give context to the business analyst role beyond the individual project, in relation to organisational mission and strategy, and to give additional depth and guidance for the business analyst role.
AgileBA highlights techniques that can help the Agile business analyst support the organization in the formulation and reviewing of its strategies. Even if the project-level Agile BA is not directly involved in defining the organization’s strategies, they need to understand the way strategy is formulated and the factors and forces which affect it. This will give them the perspective to ensure that the projects they are involved in have objectives that align with, and support, the organization’s strategic goals.
Business Analysis is crucial to the success and competitiveness of organizations in today’s rapidly-changing environment, enabling the timely delivery of high value, cost-effective solutions. As the project world continues to change, the BA role will continue to be an evolutionary role: embracing Agile is a significant part of this evolution.
The guidance is aimed at aspiring, new and existing Business Analysts, whether new to working in an agile environment or experienced in agile practices. It will also support project managers and product owners working with (or within) agile project teams and other practitioners looking to understand the value and role of business analysts on agile projects.
DantotsuPM.com 