En tant que Propriétaire de Produit (« Product Owner ») pensez-vous jamais que …. ?
vous avez trop de travail et pas assez de temps.
vous avez trop de demandeurs criant pour que leurs besoins passent en premier.
vous n’avez jamais de temps pour adresser la dette technique ni l’innovation parce que le directeur commercial continue d’exiger de nouvelles fonctionnalités.
Livre sur Amazon
Bien prioriser les items dans l’arriéré de produit est l’une des difficultés que nous rencontrons très souvent. Avoir un arriéré correctement ordonné apporte de la valeur. Cela garantit que votre équipe travaille sur les articles les plus importants pour le business et que votre produit évolue dans la bonne direction. Votre travail le plus important de Propriétaire de Produit est de décider comment utiliser au mieux la capacité de votre équipe.
Nous avons une technique que nous enseignons aux Propriétaires de Produit pour les aider à accorder la bonne priorité aux différentes parties prenantes.
Le schéma ci-dessous montre une façon de représenter tout le travail possible sur 2 axes : le temps et qui le travail aide le plus.
Selon notre expérience, il est plus facile de faire tomber d’accord vos parties prenantes sur le fait que (par exemple) les fonctionnalités pour supporter les nouveaux clients devraient consommer au plus 50 % de votre bande passante ou qu’un item spécifique de la dette technique est plus important qu’une fonctionnalité client donnée. Une fois que vous avez un agrément sur le pourcentage de capacité à dépenser dans chaque secteur, vous pouvez demander aux parties prenantes de chacun des quadrants de donner leurs priorités par quadrant sur la meilleure façon d’utiliser leur part de la capacité disponible.
Faire l’exercice avec l’équipe puis élargir à d’autres
Passé et Business (Support)
Passé se réfère ici aux fonctions existantes ou aux clients existants. Business se réfère aux parties prenantes qui se préoccupent d’articles dont les clients se soucient le plus. Les articles de ce quadrant sont d’habitude appelés des articles de support ou de soutien. Cela pourrait être les corrections à des erreurs signalées par des clients, ou des améliorations mineures à une fonctionnalité déjà livrée pour rendre la vie plus facile au client existant. Les articles de ce quadrant ne vous font pas gagner de nouveaux clients, mais ils ont un impact sur la conservation et la satisfaction des clients existants. Aussi ce quart de cercle est-il souvent financé par la maintenance et des contrats de support, et peut en fait être un quadrant qui génère effectivement du revenu.
Futur et Business (Nouveau Business)
Ce quadrant est souvent le seul sur lequel les gens se concentrent, particulièrement s’il y a une grosse pression pour gagner de nouveaux clients. Les articles de ce quadrant ont pour objectif d’aider à attirer plus de clients dans l’avenir. Ce pourraient être de nouvelles fonctionnalités, permettre une montée en volume, ajouter une plate-forme supplémentaire destinée à servir un nouveau type d’utilisateurs.
Passé et Technique (Dette Technique)
C’est un quadrant trop souvent négligé. Essentiellement, ce sont les articles qui impactent l’équipe technique. La dette technique en est un bon exemple. Par exemple, une fonctionnalité pourrait avoir été mal écrite et être donc très fragile, générant des bogues chaque fois l’équipe travaille dessus. Habituellement, ces articles ne génèrent pas de revenu additionnel mais, si on les choisit bien, ils peuvent être de gros économiseurs de dépenses. Un autre exemple dans ce secteur pourrait être une chose qui fera gagner beaucoup de temps à l’équipe de support. Par exemple si votre personnel de support doit résoudre des problèmes complexes, capturer des informations complémentaires lors de la connexion pourrait être quelque chose qui les aidera à réduire le temps qu’ils dépensent dans leurs investigations.
Futur et Technique (Innovation Architecturale)
Ce quadrant est une projection dans le futur d’une vue technique. Souvent les architectes peuvent proposer des idées pour ce secteur. Peut-être qu’une nouvelle technologie est disponible qui simplifiera significativement votre produit. D’autres items pourraient être des mises à niveau de technologies existantes avant que celles que vous utilisez ne soient dépassées. Par exemple, mise à niveau sur la dernière version Java. Ces articles peuvent parfois rapporter du revenu additionnel, parce qu’ils attirent les clients, mais le plus souvent ce sont des réducteurs de coûts : la nouvelle technologie devrait rendre les développements plus faciles pour votre équipe.
Et ci cela pouvait aussi s’avérer utile comme approche générique pour prioriser un portefeuille de projets ?
Voici quelques conseils et suggestions pour vous aider à mieux utiliser cette technique.
Règles de base
Avant que le jeu ne démarre, l’équipe identifie une histoire de référence. La complexité, la durée et le risque associé à cette histoire sont compris de tous les membres d’équipe. On donne à l’histoire de référence une valeur numérique de 2 ou 3. Cette histoire sert de base de référence pour toutes les histoires à venir et est utilisée pour lui comparer le nouveau travail à réaliser.
Une histoire est discutée jusqu’à ce que tous les membres de l’équipe comprennent bien son contenu. En utilisant des cartes physiques ou des méthodes électroniques, les membres d’équipe choisissent un nombre de Fibonacci (1, 2, 3, 5, 8, 13, 21…). Cela représente le rapport entre la nouvelle d’histoire et l’histoire de référence. Cette « mise » de chaque membre d’équipe représente la complexité, la taille, la durée et le risque de la nouvelle histoire par rapport à l’ancienne. Par exemple, si une histoire de référence vaut 2 et que la nouvelle histoire est 4 fois plus grande, une mise de 8 serait choisie. Cachez vos cartes jusqu’à ce que ce soit le moment pour que tous les membres de l’équipe dévoilent en même temps leur estimation personnelle. Comparez les mises et discutez des différences entre elles. Répétez l’exercice jusqu’à ce que tous les membres d’équipe soient à au plus 1 niveau d’écart les uns des autres dans la séquence de Fibonacci. Accordez-vous sur le bon nombre au niveau de l’équipe.
Conseils et suggestions
Vous ne pouvez pas être 100 % précis, n’y passez donc pas trop de temps. Personne ne connait l’avenir avec précision.
Bien que vous ne puissiez pas prévoir l’avenir, vous constaterez que l’équipe est très précise et ses membres sont précis avec seulement très peu de temps investi.
N’y réfléchissez pas trop. Déterminez comment ils ressentent l’histoire. Parce que vous utilisez des tailles relatives, votre cerveau sait intuitivement le nombre sans trop y réfléchir. La conversation quant aux différentes évaluations donnera assez de profondeur pour évaluer plus précisément.
La séquence de Fibonacci a des espaces qui augmentent au fil de la suite de nombre. Utilisez ces espaces pour indiquer l’inconnu. Plus un travail est grand, plus il contient d’inconnus.
Considérez le risque dans le nombre. Utilisez des nombres plus élevés pour prendre en compte le risque en indiquant que le travail restera moindre que le nombre choisi. Le risque pousse l’estimation vers le haut.
Ne reprenez pas ni réparez vos évaluations qui étaient fausses. Vos erreurs entreront dans la moyenne après quelque temps.
La discussion est d’autant de valeur que l’évaluation. Le point du jeu est d’aligner, de communiquer, de comprendre et d’éliminer les fausses idées. Chacun devrait avoir une voix.
Utilisation l’option « ? » au lieu d’un nombre pour les histoires pour lesquelles vous êtes incapable de donner une évaluation. Cela devrait être plus confortable pour ceux qui ne sont pas en position de formuler une évaluation.
Tenez vos mises cachées jusqu’à ce qu’il soit temps de jouer.
Il y aura toujours quelqu’un qui basera sa mise sur celle de quelqu’un d’autre. Cela limite les possibilités de conversation.
De trop nombreuses organisations ont du mal ou même échouent purement et simplement à mettre en œuvre des structures pour accroitre leur niveau d’agilité.
Une des raisons est la rupture de culture entre une organisation traditionnelle et la culture agile. Mettre en place des structures de livraison Agiles seulement dans votre service informatique ne suffit pas.
Un aperçu de la méthode est téléchargeable en ligne
AXELOS a développé un cadre de référence qui prépare les gens au changement transformationnel en créant une culture d’agilité d’entreprise. La structure AgileSHIFT aide les organisations à réaliser un changement transformationnel, à adopter une mentalité ‘ survivre, rivaliser et prospérer. Elle aide à construire un pont entre l’état actuel et l’état cible (le Delta dans AgileSHIFT) en embrassant un ensemble d’approches agiles, structurées et hybrides à travers toute l’organisation. La déconnexion existante entre ‘Faire tourner la boite’ et ‘Changer le business’ disparaît (Run the Organization et Change the Organization).
Chaque personne est une activatrice de changement, encouragée et autorisée à faciliter cette évolution.
Le cadre de méthode AgileSHIFT explique pourquoi nous avons besoin de l’agilité d’entreprise. Il y a une rapidité d’occurrence des changements qui accélère : volatilité, incertitude, complexité, ambiguïté (VUCA). Le rôle de la technologie évolue de « supporté par la technologie » vers « la technologie au centre de tout » en passant par « facilité par la technologie » . L’écart augmente entre l’état actuel et désiré pour votre organisation. Les influences perturbatrices comme le travail à distance, le stockage dans le cloud, la présence en ligne, les marchés inefficaces et des événements totalement inattendus contribuent à ces évolutions forcées.
Pour leur faire face, nous devons adopter le cadre et la structure proposés par AgileSHIFT qui définissent l’agilité d’entreprise, ses principes et ses pratiques. L’agilité d’entreprise est la capacité d’une organisation à bouger et s’adapter rapidement pour répondre aux changements des clients et des besoins du marché.
Les cinq principes
Le Changement se produira aussi embrassez le statu quo
Challengez le statu quo
Développez un environnement où chacun ajoute de la valeur
Concentrez-vous sur la co-création de valeur pour le client
Adaptez votre approche
Les cinq pratiques
Planifiez d’être flexible et adaptable
Engagez avec les parties prenantes
Construisez des équipes collaboratives
Concentrez-vous sur la co-création de valeur
Mesurez cette valeur pour le client
Le comment (correspond à l’approche de livraison AgileSHIFT)
Il s’exprime dans la structure AgileSHIFT par les rôles, le « workflow » (flux de travail) AgileSHIFT, une approche itérative et des outils et techniques.
Il y a 3 rôles : l’équipe AgileSHIFT, le sponsor et le coach.
Une approche itérative simple y est expliquée mais selon la situation vous devrez choisir la bonne approche. Les outils et des techniques incluent les histoires client (User Stories) et les épopées (Epics), les estimations relatives et les points d’histoire, la liste des tâches et la « roadmap » (feuille de route) AgileSHIFT, l’essaim, kanban, des canevas et agendas.
Des téléchargements sont disponibles pour les deux derniers.
Pour montrer votre compréhension d’AgileSHIFT, une certification basique et de praticien seront possibles.
Dans l’image suivante, Henny Portman a positionné AgileSHIFT par rapport aux autres approches et méthodes.
Pour aller plus loin, un wébinaire en langue anglaise est proposé par Axelos
Pour des organisations tenant à adopter une nouvelle façon de travailler, voici cinq étapes clefs pour inspirer une transformation vraiment saine et Agile
‘Agile’ a été présentée comme un remède à bien des maux de l’entreprise, y compris comment surmonter la rigidité organisationnelle. Beaucoup d’organisations ‘rigides’ continuent à utiliser les systèmes du 20ème siècle de type commande-et-contrôle du sommet vers le bas, avec des processus onéreux de direction et un outillage qui incite à la conformité plutôt qu’à la créativité et la responsabilisation. Certains commencent aussi à « faire Agile » et « embrasser Agile » sans consensus clair sur la vraie définition de cette approche, ou comment Agile peut aider une société à réussir dans le monde actuel en constant mouvement.
encore une autre expression à la mode ?
Reconnaissons-le, Agile est devenu le mot à la mode, après ses prédécesseurs comme ‘synergie’. Pour ma part, je n’ai pas d’objection si Agile est mentionné avec un A majuscule. Ce dont je me soucie vraiment est d’appliquer des concepts Lean comme ‘inspecter et adapter’, ‘limiter le travail en cours’ et ‘éliminer les gaspillage’. Je veux utiliser dès aujourd’hui les meilleures pratiques dans le développement de produit pour accélérer les bonnes réactions des marchés, en augmentant quelque chose que j’appelle ‘le métabolisme organisationnel’.
CertYou est partenaire de DantotsuPM
Qu’est-ce que le métabolisme organisationnel ?
Dans la nature, c’est le processus chimique qui se produit dans des organismes vivants pour convertir l’alimentation en énergie tout en éliminant les gaspillages. Dans le monde des affaires, cela traduit par un système qui convertit des actifs, incluant l’argent, les personnes et le temps, en valeur pour le client, idéalement en réduisant au minimum les coûts déraisonnables (par exemple la bureaucratie).
Travailler plus intelligemment
Les pratiques existantes consistant à bosser simplement plus dur que la compétition ne suffiront pas. Nous faisons face à une nouvelle réalité où les clients s’attendent à des nouveautés en continu et des innovations sur ce qu’ils veulent et ce dont ils ont besoin. En particulier tout ce qui est facilité par le digital.
Pour rester à niveau et même prendre les devants sur les concurrents, les organisations doivent abandonner leur métabolisme lent en faveur d’un business du 21e siècle au pied léger, délivrant rapidement de la valeur.
Ils peuvent le faire en développant les personnes, processus et outils qui accélèrent le métabolisme de leurs sociétés. Les sociétés qui laisseront s’échapper cette nouvelle façon de travailler louperont des opportunités pendant que leurs concurrentes prendront de l’avance, laissant lzurs clients prêts à explorer des solutions alternatives.
1. Maintenez une vision claire et inspirante
une image claire de sa raison d’être et du résultat visé
Clairement définir les résultats attendus, tant pour votre organisation que dans la transformation agile de votre société, est essentiel, parce qu’avoir une mentalité Agile signifie être à l’aise avec le changement. Tandis que les tâches et la tactique changeront, la vision suprême devrait rester intacte.
Chaque société est différente, mais doit avoir une image claire de sa raison d’être et du résultat visé.
Demandez-vous : Quel est le résultat dont je me soucie et qu’est-ce que je demande en réalité aux gens de faire ? Une vision claire aidera à guider les pratiques qui doivent être mises en œuvre malgré les changements des marchés et les fluctuations des opérations internes.
2. Considérez la culture
Pour attirer et conserver les meilleurs personnes, vous devez créer un environnement dans lequel elles peuvent prospérer. Un environnement convenable est celui dans lequel la population d’employés est motivée, autonome et suit les meilleures pratiques qui délivrent de la valeur.
The best PMs are outstanding leaders
Les leaders devraient considérer : Comment est-ce que je supporte mes premières lignes d’employés ? Ils ont les positions à l’écoute de mes clients, ils s’engagent avec eux. Donner le pouvoir aux premières lignes de personnel rend plus facile pour l’organisation d’appréhender les changements et de s’y adapter.
Des organisations qui dirigent ‘du haut vers le bas‘ deviennent lentement des dinosaures et les organisations qui adoptent ce changement culturel d’autoriser la ligne frontale à prendre des responsabilités et fournit des boucles de réactions productives seront celles qui réussissent. De plus, les leaders doivent montrer l’exemple. Trop souvent, les leaders s’attendent à ce que leurs employés mettent en œuvre des pratiques Agiles sans changer leur propre comportement.
3. Processus de changement d’idée
Beaucoup de processus et systèmes commerciaux utilisés aujourd’hui ont été créés il y a des décennies, dans l’optique d’automatiser des processus commerciaux standards. Cependant, ces processus commerciaux standards ont été construits en adaptant des processus de fabrication de grand volume d’articles physiques.
Comme les sociétés améliorent leur métabolisme organisationnel, les leaders doivent repenser tous les processus et systèmes car ceux qui les ont faits avancer au 20ème siècle ne peuvent pas répondre aux exigences de retours plus rapides d’aujourd’hui.
Le lieu de travail actuel a besoin de processus pour la direction et la conformité mais aussi pour que les personnes gagnent en autonomie en reconnaissant la façon dont elles vivent et travaillent de nos jours.
4. Utilisez les meilleurs outils
Les bons outils peuvent amplifier la direction et la vision, enlevant les frictions qui trop souvent gênent la transformation. Les outils renforcent de bons processus et comportements, évaluent quantitativement les résultats désirables et soutiennent l’équipe pour faire les ajustements corrects. Même les sociétés les plus récentes souffrent d’un métabolisme lent si elles utilisent des outils et des systèmes dépassés. Qu’il s’agisse d’une plate-forme de développement de logiciel, du système de gestion des feuilles de temps, ou de la nouvelle plateforme collaborative, les outils modernes devraient réduire la charge de travail totale, pas l’augmenter.
5. Soyez ouvert à l’échec, apprenez et adaptez-vous
Les employés ne devraient pas avoir peur de perdre leurs emplois s’ils prennent un risque intelligent et échouent. Ce devrait être évident, mais ce n’est pas le cas dans la réalité de la plupart des sociétés. Un certain niveau d’échec est inévitable quand la culture, les processus et les structures d’une organisation changent fondamentalement.
Cela fait partie de l’innovation
Des risques calculés devraient être encouragés dans les sociétés modernes. La chose importante est d’apprendre de toute erreur et devenir plus intelligent. ‘La mise à l’épreuve et l’apprentissage’, pas ‘la perfection’, devraient être nouveau mantra.
Le business au 21ème siècle
L’accélération du métabolisme organisationnel exige d’avoir suffisamment de discipline pour examiner le système en entier, de la même façon qu’un athlète professionnel améliore continuellement ce qu’il mange, comment il s’entraine, les buts qu’il se fixe et l’attitude qu’il met en place pour devenir le meilleur du monde.
Les athlètes ‘ne courent pas sur place ’
Ils cherchent continuellement des améliorations et s’entrainent activement, mettant en œuvre les pratiques qui les verront franchir en premier la ligne d’arrivée.
De même, les sociétés doivent constamment s’efforcer de s’améliorer. La transformation est une difficulté mais elle est essentielle pour les sociétés qui veulent devenir et rester des succès.
Bien que ce ne soit pas toujours facile, quand des sociétés, des équipes et des individus font l’effort, ils sont dans une bien meilleure position pour rivaliser et délivrer pour leurs clients.
partagez ce billet avec vos amis, collègues et relations professionnelles
On y trouve aussi des détails sur les programmes Professional ScrumMaster et Professional Scrum Developer avec des tests payants en ligne pour valider votre niveau de connaissance de Scrum et des rôles des différents intervenants sur les projets Agiles.
Petite vidéo très vivante de Romain Couturier sur le rôle de Scrum Master
Avec l’essor massif de l’Agilité dans les organisations et plus particulièrement de la méthode Scrum, un nouveau rôle est apparu : Scrum Master. Peut-il développer ? Quelles sont ses missions ? Cette vidéo devrait vous permettre de faire le tri entre les mythes et réalités qui entourent ce rôle. En bonus vous repartirez avec quelques outils bien pratiques dans votre rôle quotidien de Scrum Master.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pas de surprise côté méthodes, SCRUMreste fortement majoritaire à plus de 50%, même si l’on commence à voir une percée des approches hybrides.
En ce qui concerne l’agilité à l’échelle, rien de très nouveau. SAFe continue de dominer. Même s’il n’est utilisé que dans moins du tiers des cas, SAFe distance cette année plus largement ses compétiteurs comme Scrum of Scrums.
Le point le plus positif selon moi du rapport est que les bénéfices attendus des projets Agiles sont au rendez-vous et dépassent même souvent les attentes des organisations.
Pour beaucoup des aspects pratiques de Scrum, la communication large-bande est exigée.
Pour le permettre, il est préférable que les membres d’équipe soient localisés géographiquement au même emplacement. La co-localisation permet des interactions tant formelles qu’informelles entre les membres de l’équipe. Cela fournit l’avantage d’avoir les membres d’équipe toujours à portée de main (et de voix) pour la coordination, la résolution de problèmes et pour apprendre.
Certains des bénéfices de la co-localisation
Les questions trouvent rapidement des réponses.
Les problèmes sont fixés dans l’instant et sur place.
Moins de friction entre les interactions.
La confiance est gagnée et allouée beaucoup plus rapidement.
CertYou est partenaire de DantotsuPM
Des outils de collaboration peuvent être utilisés pour les équipes co-localisées ou distribuées
1. Équipes co-localisées (c’est-à-dire, équipes travaillant dans le même bureau)
Avec Scrum, il est préférable d’avoir des équipes co-localisées. Si co-localisées, les modes préférés de communication incluent des interactions en face à face, des salles partagées ou War Rooms, des tableaux Scrum, des affichages muraux, des tables partagées, etc.
2. Équipes distribuées (c’est-à-dire, équipes travaillant dans emplacements géographiques/physiques différents)
Bien que des équipes co-localisées soient préférables, de temps en temps l’équipe Scrum peut devoir être distribuée pour des raisons d’externalisation, d’offshoring, de sites géographiques multiples, d’options de travail-à-la-maison, etc. Certains outils à utiliser pour une collaboration efficace avec des équipes distribuées incluent la communication par vidéo, la messagerie instantanée, les outils de chats, les médias sociaux, les écrans partagés et les outils logiciels qui digitalisent la fonctionnalité des tableaux Scrum, murs partagés, et cetera.
Coûts supplémentaires à prévoir impérativement
Si la co-localisation n’est pas possible et qu’il y a des équipes distribuées,des ressources complémentaires devront être consacrées à faciliter des communications.
Ainsi qu’à comprendre les différences culturelles, synchroniser le travail et favoriser le partage de connaissance.
partagez ce billet avec vos amis, collègues et relations professionnelles
Chacun a un Ikigai, c’est notre moteur intrinsèque. Vous devez le chercher et l’identifier pour découvrir votre source personnelle de valeur dans votre vie ou les choses qui rendent votre vie digne d’être vécue. La découverte de son Ikigai apporte le sens, le bonheur et la satisfaction.
Le Manifeste Agile, ses 4 valeurs et 12 principes, sont la conséquence de la frustration des entreprises dans les années 1990 sur le laps de temps entre l’expression des besoins de l’entreprise et la livraison technologique de la solution. Les besoins business et métier évoluent pendant cette période et le produit final ne répond jamais aux besoins du moment qui ont changé.
Cynefin parle de quatre types différents de problèmes ou domaines. Évident, Compliqué, Complexe et Chaotique. Nous aborderons ces premiers et couvrirons à la fin le Désordre.
Les débutants qui prennent leur premier job de management de projet ont besoin de quelqu’un pour les guider et les aider à passer l’environnement agité, cependant productif de ces tâches : un mentor.
Si vous êtes déjà un mentor de chef de projet, vous êtes déjà familiers avec cette situation; vous décelez les erreurs des débutants et êtes un peu frustré lorsqu’ils s’avèrent incapables d’accomplir le travail que l’on attend d’eux. Alors, vous appliquez les méthodes nécessaires pour les aider à sortir de leur tracas et à évoluer par eux-mêmes.
Si vous n’êtes pas encore un mentor de projet, mais voulez le devenir, voici quelques étapes pour vous assurer que votre protégé recevra autant de formation qu’il ou elle lui en faut pour survivre dans le management de projet.
Méta Projets Management est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a quelques années, Craig Brown qui anime le Melbourne Scrum User group a commencé à prôner que Scrum est une méthode universelle et non pas réservée uniquement aux projets de développement de logiciels.
Voici ce que je retiens encore aujourd’hui de la description qu’il donnait de Scrum et qui s’applique à tout projet :
1. Commencez avec un objectif. Puis, décomposez-le en étapes incrémentales.
2. Discutez des étapes avec l’équipe qui doit livrer la solution.
3. Définissez des périodes de temps standards (timebox) pour les itérations. Faites de votre mieux pour livrer quelque chose de valeur, utilisable et utile à chaque itération.
4. L’équipe prend ses « ordres » (ses priorités) du client au début de chaque itération et fait un rapport sur ce qui a été « fait » (totalement achevé) à la fin de chaque itération (Sprint Review).
5. L’équipe doit mettre du temps de coté au début de chaque itération pour planifier son travail (Sprint Planning).
6. L’équipe doit aussi mettre du temps de coté pour une brève session d’échanges chaque jour entre ses membres sur les progrès réalisés et les problèmes rencontrés (Daily Scrum).
7. L’équipe doit s’engager à l’amélioration continue et mettre du temps de coté à chaque itération pour réfléchir à ce qui est bien allé ou pas et identifier où l’on peut s’améliorer et comment (Sprint Retrospective).
8. La planification, la revue et les sessions de réflexion et réunions d’équipe quotidiennes doivent avoir lieu à des heures régulières pour aider l’équipe à trouver et tenir un rythme.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Essayez-vous de tout accomplir, seulement en vous consommant et finissant par vous sentir toujours plus en retard ?
S’il en est ainsi, vous n’êtes pas tout seul.
J’ai personnellement essayer cette technique et elle marche mais demande énormément de rigueur et d’attention. Les premiers temps, mes estimations de durée entre les choses grandes, moyennes et plus petites, étaient erronées et bien sûr il est souvent difficile d’avancer comme on le voudrait sur sa to-to Liste à cause des impondérables opérationnels de la vraie vie au travail.
Comment le manager ou le chef de projet devrait-il gérer un dominateur pendant une réunion d’équipe ?
Le Problème : Chacun a eu l’occasion de rencontrer “LE dominateur” (ou LA dominatrice).
C’est la personne dans le groupe qui semble s’approprier la discussion et ne plus laisser d’autres personnes s’exprimer. Parfois ce sont seulement des bavards trop prolifiques… …d’autres fois, ce sont des personnalités excessivement agressives qui pompent tout l’oxygène de la pièce.
Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.
Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue, de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.
Dans ce billet sont listés Dix Bénéfices du Management de Portefeuille de Projet qui aideront votre projet à recevoir l’attention qu’il mérite. Ces bénéfices sont aussi accompagnés par le Bureau de Management de Projets (Project Management Office / PMO) pour améliorer votre taux de succès dans les projets.
SMPP est Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Management de projet hybride, nouveaux guides du PMI, outils Microsoft… mais aussi se comporter en adulte furent les billet qui retinrent votre attention en Mai 2018 et que vous aimerez peut-être relire ou découvrir en cette période estivale plus calme.
Cet article publié il y a plusieurs années et repris à l’occasion du forum des régions PMI France 2018 a connu un regain de succès. C’est très mérité car les auteurs, Christine Rieu, Sylvain Gautier et Marc Burlereaux, avaient pris le temps de partager avec nous leur expérience de l’agilité et premières idées pour adopter une approche plus hybride.
L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet. En couplant une approche Lean à ces méthodes Agiles, nous supprimons en plus toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit.
Quand il avait 30 ans, le fondateur de l’Electronic Frontier Foundation (et parfois parolier de Grateful Dead) a rédigé une liste de ce qu’il a appelé « les Principes de Comportement Adulte ». Lesquels 5 ou 6 éliriez-vous dans cette liste pour votre propre éthique ? J’aime beaucoup 2,3,4,5,6,7,8…
À ce jour, vous êtes probablement déjà familiers de Microsoft Project. Sorti en 1990, Microsoft Project est devenu l’application par défaut pour les chefs de projets. Microsoft Planner est une solution de gestion de projet plus récente qui a été publiée en 2016 dans le cadre d’Office 365. Les deux applications nous laissent créer des plans, organiser et confier des tâches, partager des dossiers, communiquer avec des collègues et obtenir des mises à jour sur le progrès de notre équipe.
Alors, quelle solution devrions-nous utiliser ?le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français
Afin de soutenir l’éventail de plus en plus large des approches de réalisation de projets, PMI propose un PMBOK® Guide – Sixième édition accompagné du nouveau Guide de pratiques Agiles.
Quand le sujet de choisir son outil PPM devient un vrai casse-tête, que vous vous perdez devant la pléthore d’offres et que vous ne savez plus vraiment comment faire le bon choix…
Pas de panique, détendez-vous ! On vous dit tout !
SMPP est Partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des Responsabilités sert à documenter les rôles et responsabilités de chacun dans le projet.
Cet outil, qui prend la forme d’un tableau (qui croise la structure de décomposition du projet/WBS et les ressources de l’organisation) permet au chef de projet de lister les participants au projet ainsi que leur(s) responsabilité(s).
Le RACI est l’exemple de RAM le plus utilisé, a pour point de départ le croisement de la structure de découpage de projet ou SDP/WBS avec les ressources du projet.
« Qu’est-ce qui différencie les projets des activités régulières ? »: Lors de votre prochain entretien pour un job de chef de projet, cette question pourrait fort bien vous être posée.
Une lettre d’un chercheur en physique au Laboratoire Lawrence Livermore du nom de Tom Hirshfield. Tom y partageait quelques principes de base qu’il avait personnellement trouvés utile dans son travail et à utiliser comme bon vous semble dans le votre.
Voici quelques-unes des étapes sur lesquelles je plancherais pour préparer un plan à 90 jours que je pourrais proposer à mon futur employeur dès les premiers entretiens…
partagez ce billet avec vos amis, collègues et relations professionnelles
Qu’est-ce que le Scrum of Scrums et comment fonctionne-t-il dans le processus de développement de produit ?
La première chose à savoir sur le Scrum of Scrums est qu’il devient pertinent seulement pour de grands projets où de multiples équipes Scrum sont impliquées. Dans ce processus, les représentants d’équipes Scrum se rassemblent pour la réunion Scrum of Scrums à intervalles de temps prédéterminés ou chaque fois qu’il est nécessaire de collaborer et suivre leurs progrès, obstacles et dépendances respectifs à travers les multiples équipes Scrum.
Qui participe ?
Normalement, un membre de chaque équipe Scrum représentera son équipe dans la réunion Scrum of Scrums. Dans la plupart des cas, c’est le Scrum Master, mais de temps en temps quelqu’un d’autre peut représenter l’équipe. Une unique personne peut être nommée par l’équipe pour la représenter à chaque réunion Scrum of Scrums, ou bien le représentant peut changer au fil du temps, en fonction de qui peut remplir au mieux le rôle en raison des questions et circonstances actuelles. Chaque participant à la réunion devrait avoir la compréhension technique et être capable d’identifier des situations dans lesquelles les équipes pourraient causer obstacles ou retards les unes aux autres.
D’autres participants importants de réunion Scrum of Scrums incluent Scrum Master en chef et le Propriétaire de Produit en chef. Le but principal de la réunion Scrum of Scrums est de communiquer sur la progression entre des équipes multiples. Le Scrum Master en chef (ou n’importe quel Scrum Master qui faciliterait la réunion Scrum of Scrums), peut proposer un ordre du jour avant la réunion. Cela permet à chaque équipe de considérer les sujets de l’ordre du jour en préparant la réunion Scrum of Scrums.
De quoi discute-t-on ?
Tous les obstacles rencontrés par une équipe et qui peuvent aussi affecter d’autres équipes, devraient être remontés ainsi ils peuvent être discutés. De plus, si une équipe prend conscience d’un gros problème, changement ou risque qui peut impacter d’autres équipes, il devrait être communiqué lors de la réunion Scrum of Scrums.
Book on Amazon
Les productions des rétrospectives de Sprint peuvent aussi élever des problèmes qui pourraient impacter de multiples équipes Scrum et pourraient être utilisées lors de la réunion Scrum of Scrums. Ces réunions sont de préférence brèves (mais d’habitude non limitées dans le temps pour favoriser davantage d’échanges d’information entre les équipes) auxquelles se joint un représentant de chaque équipe Scrum pour partager le statut de son équipe. La réunion Scrum of Scrums se tient à intervalles prédéterminés ou quand demandé par des équipes Scrum. Ces réunions facilitent le partage en face-à-face d’informations entre des équipes Scrum différentes des difficultés, des dépendances et des risques qui doivent être étroitement contrôlés. Ceci aide les diverses équipes travaillant sur un grand projet à mieux coordonner et intégrer leur travail. C’est la responsabilité du Scrum Master en chef (ou tout autre Scrum Master qui facilite la réunion Scrum of Scrums) de s’assurer que tous les représentants ont un environnement contribuant à partager ouvertement et honnêtement l’information, y compris les réactions des représentants d’autres équipes. Pour de plus grands projets, impliquant un nombre significatif d’équipes, de multiples niveaux de ces réunions peuvent être implémentés. Chaque représentant d’équipe Scrum fournira à son tour les avancées de son équipe.
On donne d’habitude ces éléments en répondant à quatre questions spécifiques.
Sur quoi mon équipe a-t-elle travaillé depuis la dernière réunion ?
Que mon équipe fera-t-elle d’ici la prochaine réunion?
Quel reste-t-il à faire à mon équipe pour répondre aux attentes d’autres équipes ?
Que mon équipe va-t-elle faire qui pourrait impacter d’autres équipes ?
Les réponses à ces quatre questions fournissent l’information qui permet à chaque équipe de comprendre clairement le statut du travail de toutes les autres équipes. On recommande qu’une salle de réunion dédiée soit rendue disponible pour la réunion Scrum of Scrums, où tous les représentants d’équipes Scrum sont à l’aise.
Pour quels bénéfices ?
Dans le processus Scrum of Scrums, les meilleures pratiques pourraient être documentées sur la façon de conduire la réunion Scrum of Scrums et des suggestions incorporées dans le travail de projet d’équipes Scrum individuelles.
Il peut aussi y avoir une équipe d’experts du sujet qui peuvent aider le Scrum Master en chef à faciliter la réunion Scrum of Scrums.
L’une des productions importantes de la réunion Scrum of Scrums est la coordination du travail à travers des équipes Scrum multiples. C’est particulièrement important quand il y a des tâches avec des dépendances inter-équipes. Les incompatibilités et contradictions entre le travail et les livrables d’équipes différentes sont rapidement exposées.
Ce forum donne aussi aux équipes l’occasion de présenter leurs accomplissements et donner des retours à d’autres équipes.
En utilisant la réunion Scrum of Scrums, il y a de la collaboration à travers toute l’organisation par opposition à des personnes travaillant dans des équipes renfermées et concernées principalement par leurs responsabilités individuelles. La réunion Scrum of Scrums est un forum où les membres d’équipe Scrum ont l’occasion de discuter des problèmes impactant leur projet d’une manière transparente.
Le besoin de livrer chaque Sprint à l’heure force les équipes à confronter activement de telles questions au lieu de reporter à plus tard la recherche de résolution. Cette discussion et résolution opportunes de questions dans la réunion Scrum of Scrums améliorent énormément la coordination entre des équipes Scrum différentes et réduit aussi le besoin de refaire et retravailler. Les risques liés aux dépendances et délais de livraison sont aussi atténués.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Planning Poker est une façon commune de réaliser l’estimation des points d’histoire utilisateur. Il présente quelques avantages, mais aussi quelques problèmes.
Qu’est-ce que ce Planning Poker ?
Le Planning Poker est souvent utilisé dans des équipes Scrum (bien qu’il ne soit mentionné nulle part dans le guide Scrum selon la croyance populaire). Mike Cohn l’a popularisé dans son livre “Agile Estimating and Planning“. C’est une technique d’équipe pour collectivement estimer les points d’histoires d’utilisateur. (Pas sûr de ce que cela signifie ? Lisez le « guide to story point estimation »).
Si vous êtes déjà familiers du Planning Poker, n’hésitez pas à sauter directement plus bas “la planification d’alternatives au Planning Poker”. Sinon, continuez de lire pour une explication de comment cela fonctionne et pourquoi les gens l’utilisent.
CertYou est partenaire de DantotsuPM
Comment fonctionne-t-il ?
Disons que vous avez une équipe de sept ou huit personnes, qui ont environ une douzaine d’histoires d’utilisateur dans leur arriéré de produit qu’ils voudraient estimer. Pour le faire via le Planning Poker, chaque personne dans l’équipe aura une certaine méthode pour fournir un chiffre. C’est d’habitude via un sabot de cartes de poker, mais vous pourriez aussi utiliser une app sur votre téléphone. Les chiffres sont d’habitude des nombres de la suite de Fibonacci, une série où chaque nombre est la somme des deux nombres précédents. Donc cela donne 1, 2, 3, 5, 8, 13, 21, et cetera (on ne va d’habitude pas dépasser 21 parce que les histoires d’utilisateur ne devraient jamais être beaucoup plus grandes que d’autres).
L’équipe prend la première histoire de la liste et en discute un moment. Souvenez-vous, une histoire d’utilisateur est écrite comme une déclaration de problème. L’équipe réfléchit ensuite à combien de travail il faudrait pour répondre à cette déclaration de problème, c’est-à-dire mettre en œuvre une solution qui réalise le comportement décrit dans l’histoire.
Estimation de Planning Poker
Une fois que l’équipe est prête à estimer, chaque personne choisit un numéro de son jeu de cartes. Ils le font en silence. Puis, chaque personne révèle son évaluation en même temps.
La raison de procéder ainsi est que l’évaluation d’une personne ne devrait pas influencer l’évaluation d’une autre. Si chaque personne fournit son évaluation à son tour, la première personne pourrait choisir une grande (ou petite) estimation, qui pourrait faire changer d’avis d’autres personnes et ainsi biaiser leur évaluation. Le processus est destiné à permettre à chaque personne de fournir sa propre évaluation impartiale et honnête.
Bien sûr, les valeurs sont souvent différentes, ce qui signifie qu’une autre discussion démarre. Il y a parfois alors un autre round d’évaluation. Quelques puristes de Scrum insistent pour que l’équipe continue les rounds d’évaluation jusqu’à ce que chacun arrive au même nombre. Je pense que c’est de la folie et que cela encourage ce que le planning poker devrait empêcher : les gens « forçant » d’autres à être d’accord avec leur évaluation.
Je pense que cela devrait continuer jusqu’à ce qu’un consensus soit atteint, ce qui est d’habitude très clair (et PAS la même chose que la conformité, c’est-à-dire quand chacun a la même valeur). S’il y a une gamme d’évaluations consistant de 2, 2, 3, 3, 5, 5, l’estimation est de 3. Cela ne doit pas être une moyenne exacte, mais une médiane suffit. Et cela ne doit pas être mathématiquement précis. Les évaluations sont essentiellement des suppositions informées. Le processus d’évaluation n’est pas précis donc les évaluations ne le seront jamais et c’est ok.
Alors, pourquoi chercher des alternatives au Planning Poker?
Vous pourriez vous demander pourquoi vous voudriez des alternatives à le Planning Poker. Ce n’est pas un mauvais système, mais il a quelques problèmes.
Il est lent
Cela peut prendre une longue période de temps pour faire l’évaluation avec le Planning Poker. J’ai vu des sessions de deux ou trois heures et ce n’est pas amusant. Montrer ces cartes est au départ amusant mais cela devient usant vraiment rapidement. Tergiverser sur savoir si quelque chose vaut 2 ou 3 est ennuyeux et irritant et ce n’est pas une conversation de valeur.
Il distrait
La discussion sur quelle carte est bonne ou fausse peut distraire les gens d’une conversation de plus de valeur : la discussion de la solution. Particulièrement, pourquoi quelqu’un estime que quelque chose mérite 2 ou 3 par opposition à une autre valeur.
Il peut donner une fausse impression des estimations
Certaines personnes pensent que si vous faites ce jeu intelligemment, alors les évaluations elles-mêmes deviennent soudainement plus précises et donc de plus de valeur. C’est complètement faux. Le Planning Poker est une bonne façon d’atteindre un consensus sur des évaluations. Cela ne signifie pas qu’elles soient précises. Il est très possible pour un groupe de personnes d’être dans l’erreur à propos de quelque chose (particulièrement quelque chose de notoirement difficile à évaluer comme la complexité de développement de logiciel).
Les alternatives au Planning Poker
Il y a quelques alternatives que vous pouvez essayer si vous vous fatiguez du Planning Poker, ou pensez que cela pourrait être mieux.
Classement par taille de t-shirt
Au lieu des nombres (Fibonacci ou autres, vous pouvez utiliser des tailles de T-shirt. Petit, moyen, large, extra-large. Cela vous donne une plus petite gamme d’estimations possibles, ce qui signifie que vous obtiendrez moins de désaccords et moins de variance. Vous pourriez penser que les évaluations seront moins précises, mais je ne pense pas qu’elles le seront. Je constate que les tailles de t-shirt sont suffisantes. Vous aurez besoin de quelques références pour ces tailles; utilisez simplement des histoires ou des fonctions précédentes. (J’aime en réalité faire des évaluations de taille de t-shirt et aucune autre estimation d’histoire). Vous pourriez aussi utiliser un jeu plus réduit de nombres (1, 5, 8, 20) ou autre chose pour remplacer les tailles de t-shirt. Mais j’aime le fait que des nombres ne soient pas utilisés. Cela clarifie le fait que ce ne sont pas des mesures et elles ne sont pas précises.
Pour l’estimation précise, vous pouvez utiliser la technique du planning poker, ou la Technique « Affinity Mapping ».
Affinity Mapping
Vous pourriez être familiers avec la technique « Affinity Mapping » car elle est utilisée dans les Rétrospectives de Sprint. C’est une technique pour grouper ensemble des articles semblables. Commencez par créer une série d' »étiquettes » ou de « piles » sur la table : celles-ci pourraient être numérotés selon Fibonacci, ou les tailles de t-shirt, ou des catégories, ou quoi que ce soit. Puis, vous déposez les histoires sur la table comme des cartes. Ensuite, l’équipe déplace collectivement les cartes dans les piles pour les représenter selon leur estimation.
C’est une technique intéressante, peu commune et peu connue. C’est une manière efficace d’évaluer un grand nombre d’histoires dans un espace de temps très court. Commencez par définir vos points de référence (nombres de Fibonacci, tailles de t-shirt, etc). Créez des piles sur la table selon la technique « Affinity Mapping ». Ensuite, chaque personne est aléatoirement assignée un jeu d’histoires à estimer (peut-être en distribuant les histoires comme si elles étaient des cartes à jouer). Puis, à tour de rôle, chaque personne évalue en silence en plaçant une carte sur une des piles. Alternativement, une personne peut déplacer une carte d’une pile à une autre, si elle est convaincue qu’une estimation est incorrecte.
Continuez à faire ceci jusqu’à ce que toutes les cartes soient estimées. Si une carte est déplacée deux fois, ôtez-la de la table – elle aura besoin d’une discussion séparée après la réunion car il y a un fort désaccord sur son estimation.
L’avantage de cette technique est qu’une équipe peut évaluer beaucoup d’histoires en un très court laps de temps. A utiliser si l’on vous demande d’évaluer 100 histoires (même si je pense que c’est le signe d’un plus gros problème car vous devriez seulement évaluer un ou deux sprints d’histoires Utilisateurs à l’avance). L’inconvénient est que vous sautez ce qui est souvent la partie de plus de valeur : la discussion autour des histoires.
Aucune évaluation
D’autres personnes prennent une position plus extrême. Ils pensent que nous devrions nous débarrasser totalement des estimations ! C’est un mouvement qui est souvent identifié par le hashtag Twitter #NoEstimates. Il a été lancé il y a quelques années par quelqu’un appelé Woody Zuil et est principalement soutenu par un coach Agile nommé Vasco Duarte. Si vous voulez l’essayer, c’est facile : n’abandonnez pas seulement le Planning Poker, abandonnez aussi toute estimation. Vous pouvez alors faire deux ou trois choses :
Donnez une évaluation moyenne sur toutes les histoires (utilisez une moyenne historique, total ou roulant la moyenne des trois derniers sprints)
Oubliez les points d’histoire et utilisez juste le nombre d’histoires pour la planification
Oubliez le planning d’histoires et estimez par fonctionnalité, utilisant probablement des tailles de t-shirt / le nombre de sprints.
En ce qui me concerne, je tombe dans le dernier camp. Je ne pense pas que les évaluations d’histoire sont très forte valeur, bien que des évaluations de haut niveau de fonctionnalités soient utiles pour la planification de release (et j’ai constaté qu’elles sont souvent aussi ou plus précises qu’une somme d’évaluations de point d’histoire).
#NoEstimates est un sujet complexe et très controversé et qui mérite une discussion séparée.
Conclusion
Vous pouvez essayer ces techniques et voir ce qu’en pense l’équipe. Assurez-vous de les considérer comme des expériences et recueillez-en les données: L’équipe estime-t-elle que c’est mieux que le planning poker ? Les évaluations se sont-elles avérées de plus de valeur ?
Rappelez-vous que la chose qui a le plus de valeur dans une session d’estimation est d’habitude les conversations autour de la solution, pas les nombres estimés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Manifeste Agile, ses 4 valeurs et 12 principes, sont la conséquence de la frustration des entreprises dans les années 1990 sur le laps de temps entre l’expression des besoins de l’entreprise et la livraison technologique de la solution. Les besoins business et métier évoluent pendant cette période et le produit final ne répond jamais aux besoins du moment qui ont changé.
“Les individus et leurs interactions PLUS que les processus et les outils Des logiciels opérationnels PLUS qu’une documentation exhaustive La collaboration avec les clients PLUS que la négociation contractuelle L’adaptation au changement PLUS que le suivi d’un plan.”
Selon une étude de 2017 réalisée par VersionOne « State of Agile Report », 94% des organisations font de l’agilité.
Mais qu’est réellement Agile et qu’est ce que la méthodologie Agile ?
Le mot “Agile” fait référence à un groupe de différentes méthodologies et de cadres de travail basés sur le développement itératif, la livraison incrémentale, la planification continue, l’apprentissage continu et les équipes pluridisciplinaires auto-organisées.
Ce groupe de méthodologies Agile et de cadres de travail ont en commun les 12 principes Agiles fondamentaux décrits dans le Manifeste Agile. Le principal avantage pour les organisations adoptant une méthodologie Agile est la capacité de « s’adapter au changement », de le valoriser et de l’apprécier à sa juste valeur.
Certaines méthodologies Agile se concentrent clairement sur la livraison et le développement de logiciels, d’autres sont plus axées sur les projets de toutes sortes et peuvent être utilisées comme des méthodes de gestion de projet.
Le webinaire en replay de notre partenaire QRP International
Agile : Signification et Définition
Agile est un « terme générique » pour plusieurs méthodologies de développement (de logiciels) itératives et incrémentales. Ce qui est important dans les méthodologies agiles, c’est qu’elles sont toutes axées sur l’habilitation des personnes à collaborer et à prendre des décisions ensemble. Rapidement et efficacement.
La gestion de projet Agile décrit une approche itérative de la planification et de l’orientation des processus de projet. Cependant, Agile est un état d’esprit. Il n’existe pas une unique approche de gestion de projet Agile qui fonctionne dans toutes les situations; le terme général « Agile » représente plutôt une variété de méthodes et de pratiques qui s’alignent sur les valeurs présentes dans le manifeste Agile. Agile consiste à créer une culture dans laquelle les équipes Agile coopèrent et collaborent pour générer de la valeur.
Comme il n’existe PAS de solution universelle pour adopter ou mettre en œuvre une approche agile, il existe plusieurs types de méthodes Agiles (souvent appelées «cadres» ou « frameworks ») pour répondre aux besoins variés des différentes organisations et équipes.
Les membres des équipes Scrum, participants aux formations, collègues et parties prenantes diverses impliquées dans des projets de mise en œuvre Agiles/Scrum posent souvent les mêmes questions sur les histoires d’utilisateur (User Stories). Ci-dessous, une liste de questions et réponses que je partage avec vous. J’espère que ces informations seront utiles à quiconque veut en apprendre davantage sur les histoires d’utilisateur.
Q: Que sont les histoires d’utilisateur (User Stories) ?
Une histoire d’utilisateur est une brève description de tout besoin fonctionnel. Elle est écrite d’une perspective utilisateur pendant ou avant la priorisation de l’arriéré de produit (Product Backlog) ou une session de planification de Sprint (Sprint Planning). Une histoire peut inclure, mais n’est pas limitée à, une fonctionnalité avec ses caractéristiques et ses règles de gestion, des demandes d’amélioration, des corrections de bogue, l’installation d’infrastructure, ou une documentation technique. Les histoires d’utilisateur peuvent représenter presque n’importe quelle activité pendant le cycle de vie du développement logiciel.
Q: Comment les histoires d’utilisateur sont-elles apparues ?
Il n’y a aucune date spécifique ou événement rapportés sur l’origine des histoires d’utilisateur. Cependant, la littérature suggère que les histoires d’utilisateur ont évoluées pendant le processus de collecte et de mûrissement des besoins qui ont été à l’origine documentés sous forme de cas d’usage. Des « programmeurs extrêmes » à la fin des années 1990 ont rendu les histoires d’utilisateur populaires dans l’arène du développement logiciel. Des approches Agiles plus récentes, comme Scrum et Kanban, ont aidé à largement promouvoir l’usage massif les histoires d’utilisateur.
Q: Comment dois-je écrire une histoire d’utilisateur ?
Le format le plus populaire pour écrire des histoires d’utilisateur dans beaucoup d’approches Agiles est comme suit :
En tant qu’utilisateur (du système), je veux faire (action) pour que (les bénéfices à avoir cette fonctionnalité).
Par exemple, « En tant qu’étudiant, je veux voir mes notes pour connaitre ma performance. »
Q: Qui est responsable d’écrire les histoires d’utilisateur ?
Il n’y a aucun rôle spécifique responsable d’écrire une histoire d’utilisateur. Toute personne impliquée dans le processus de développement logiciel, des parties prenantes du métier aux membres de l’équipe Agiles, peut écrire des histoires d’utilisateur. Cependant, beaucoup d’histoires sont écrites pendant la session de revue de l’arriéré de produit par les membres de l’équipe de développement, comme les programmeurs, testeurs et analystes, ainsi que le propriétaire de produit (Product Owner).
Q: Quelles sont les qualités d’une bonne histoire d’utilisateur ?
Une histoire d’utilisateur idéale devrait être courte, simple et sans équivoque. Beaucoup de partisans Agiles considèrent le modèle de Bill Wake INVEST comme une base pour une bonne histoire.
Q: Les histoires d’utilisateur exigent-elles une approbation ?
qui approuve une histoire utilisateur ?
Contrairement aux exigences opérationnelles ou aux documents dans des approches de développement logicielles traditionnelles, aucun processus formel n’existe pour approuver des besoins dans un environnement Agile. Et les histoires d’utilisateur ne sont pas les seules fonctionnalités, donc ce sont les membres de l’équipe Agile qui acceptent les histoires quand la plupart d’entre eux sont confiants sur la capacité à livrer cette histoire en une itération. Tous les doutes sur une histoire d’utilisateur sont clarifiés par le propriétaire de produit dans le cadre de Scrum.
Q: Quels sont trois Cs des histoires d’utilisateur ?
En 2001, Ron Jeffries Proposé le concept de trois Cs : Carte (fiche), Conversation Et Confirmation, pour atteindre le consensus sur une histoire de la part des parties prenantes dans le cadre Agile.
La Carted’histoire est écrite sur une fiche, qui est souvent un Post-it®.
La Conversationest une série de discussions entre l’équipe de développement et les parties prenantes internes et externes pour comprendre la complexité et la valeur de l’histoire.
La Confirmationdoit s’assurer que la conversation tournant autour de l’histoire est parvenue à une conclusion.
Q: Quelles sont les différences entre un cas d’usage (Use Case) et une histoire d’utilisateur ?
Bien le cas d’usage et l’histoire d’utilisateur semblent semblables et que beaucoup de personnes les confondent comme une des façons de décrire des besoins, ils sont différents de bien des façons, comme suit :
Histoires d’utilisateur et tâches :
Les membres de l’équipe exécutent des tâches basées sur l’ensemble d’activités pour construire une fonctionnalité, comme exprimé dans l’histoire d’utilisateur. Par exemple, l’histoire d’utilisateur est: Comme un acheteur de mon futur domicile, je veux voir la liste de maisons dans mon voisinage pour que je puisse faire une liste des maisons candidates sélectionnées que je veux acheter.
Les tâches pour l’histoire pourraient être:
Codage, utilisation de la logique appropriée
Intégration d’APIs de recherche et de cartographie
Développement de scénarios de test
Intégration avec des sources de données
Finalisation de filtre de sélection
Les histoires d’utilisateur sont mesurées de manière relative avec des tailles comme S, M, L, XL, etc., ou en utilisant la séquence de Fibonacci : 1, 2, 3, 5, 8, 13 …, basée sur la complexité de développement des histoires. Les tâches sont toujours calculées en heures et sont basées sur le niveau d’effort que chaque membre doit fournir pour chacune des tâches.
CertYou est partenaire de DantotsuPM
Histoires d’utilisateur et épopées
Une épopée est un jeu de fonctionnalités qui ressemblent à une histoire au début, mais quand les membres de l’équipe commencent à l’analyser, ils constatent qu’elle pourrait être plus grande que précédemment envisagé. Donc ils doivent la décomposer en de multiples histoires. Une façon de différencier une épopée d’une histoire est en vérifiant qu’elle suit le modèle INVEST discuté plus tôt.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.
Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue, de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.
AVERTISSEMENT : que faire avant que vous n’adoptiez ces pratiques Agiles
N’adoptez pas de pratiques Agiles simplement pour suivre les foules.
Comprenez les bénéfices que vous tirerez à incorporer des pratiques Agiles. Vous économiserez du temps et de l’argent en obtenant des réactions des clients et en livrant le bon produit. Vous travaillerez plus intelligemment avec une communication accrue et transverse dans l’équipe et des pratiques de travail améliorées.
Discutez avec votre équipe et obtenez leur adhésion. Le changement sera un effort d’équipe et vous aurez besoin de leur collaboration et coopération. L’équipe entière doit être à bord. Vous ne pouvez pas réussir seul.
Partagez vos idées avec l’équipe sur pourquoi vous voulez le faire. Découvrez les idées et préoccupations de vos coéquipiers. Assurez-vous qu’ils sont ouverts à faire un essai. Vous devrez vous lancer avec leur appui, parce qu’ils font aussi partie du jeu.
Voici 3 pratiques Agiles que vous pouvez déjà commencer à utiliser:
1. Standup Quotidien
Bénéfices : transparence et communication accrues dans l’équipe.
Votre équipe aura une plus grande compréhension de la progression et des défis. Le chef de projet peut « mener » si nécessaire, mais les équipes Agiles s’auto-organisent et peuvent le faire elles-mêmes si le chef de projet n’est pas là.
Comment le faire : c’est une réunion très courte (15 minutes ou moins) qui donne chaque jour une occasion à l’équipe de faire un point et partager l’information.
Chaque membre d’équipe répond brièvement à ces trois questions :
Qu’avez-vous fait hier ?
Sur quoi travaillez-vous aujourd’hui ?
Y-a-t-il des obstacles vous empêchant de faire votre travail ?
Dans le Scrum traditionnel, le scrum master élimine les points de blocage, mais le chef de projet peut aussi le faire.
Avertissement : ce n’est pas une réunion de statut d’avancement de 30 minutes. Ce n’est pas une longue discussion sur les détails. Cela devrait plutôt être très court : 15 minutes ou moins. C’est un rendez-vous pour votre équipe chaque jour pour rester à niveau. Si l’équipe doit discuter de plus de détails, faites-le après le stand up.
Un de mes amis a suggéré à son chef qu’ils s’y essaient. Ils avaient des très longues réunions de statut de projet. Son patron a accepté et aimé l’idée. Mais au lieu que ce soient les membres de l’équipe qui aient une réunion quotidienne rapide, son chef la dirige. Pis encore, le stand up s’est métamorphosé en réunion de statut prolongée tous les jours : une situation pire qu’avant. Évitez la tentation de faire traîner le stand up. Tenez l’agenda et le rythme et gardez les longues conversations pour après le stand up.
2. La Rétrospective
Bénéfices : amélioration continue.
Votre équipe identifiera des façons de s’améliorer pendant le projet, plutôt que d’attendre jusqu’à ce que le projet soit fini. Vous y gagnerez les bénéfices d’améliorations continues tout au long du projet.
Comment le faire : à divers moments pendant le projet, l’équipe évalue son efficacité.
Livre sur Amazon
Il y a 3 questions clefs à poser :
Qu’est-ce qui a fonctionné bien pour nous ?
Qu’est-ce qui n’a pas bien marché ?
Que pouvons-nous faire différemment pour nous améliorer ?
Choisissez divers moments pendant le projet pour mettre en œuvre cette pratique Agile. Une fois que vous avez fait l’exercice et identifié des choses que vous pouvez améliorer, choisissez-en une ou deux à cibler les premières. Incorporez ces changements et voyez comment ça va. Répétez ensuite ce processus pendant le projet.
Votre équipe peut incorporer des améliorations tandis que le projet est toujours en voie de réalisation, plutôt qu’attendre jusqu’à ce que le projet soit fini.
Notez : Il doit y avoir un environnement de confiance et de soutien entre les membres de l’équipe. Ne critiquez personne pour des suggestions faites. Ne blâmez pas de membres pour des fautes, mais identifiez plutôt des façons de vous améliorer. Soyez ouvert à considérer les challenges comme des opportunités.
3. Démonstrations de logiciel au client
Bénéfices : transparence et collaboration avec le client.
Les clients bénéficient de voir le produit en l’état et en partageant leurs réactions. L’équipe obtient l’avantage de retours des client sur n’importe quels ajustements nécessaires.
Comment le faire : Démontrez un logiciel qui fonctionne au client à des points appropriés en cours de développement. N’attendez pas jusqu’à ce que tout ce soit prêt pour les tests d’acceptation de l’utilisateur final.
Ce n’est pas une présentation PowerPoint. Vous montrez le logiciel réel. Ne cherchez pas de tape à l’œil ni perfection. Votre but est de montrer au client comment le produit progresse et d’obtenir des réactions. Vous ne devez pas louer une énorme salle de conférences et faire des PowerPoint tapageur. Vous ne montrez pas de produit fini pour l’instant.
Gérez les attentes du client sur ce que vous montrez. Vous ne voulez pas les étonner s’ils s’attendaient à quelque chose d’autre. Assurez-vous qu’ils sont conscients que c’est un premier jet et pas le produit fini. Expliquez pourquoi vous le faites et ce que vous espérez y gagner.
CertYou est partenaire de DantotsuPM
C’est un Voyage
Adoptez un esprit de collaboration, de communication et d’amélioration continue. Faites-le avec respect pour tous vos membres d’équipe pendant que vous adoptez de nouvelles pratiques.
Soyez patient avec eux. Vous n’atteindrez pas tout de suite la perfection. Mais vous en bénéficierez et l’aimerez probablement, aussi.
Maintenant que nous avons vu ces 3 pratiques Agiles, vous pouvez probablement voir comment les utiliser même si vous ne vous lancez pas à fond dans Agile.
Il n’y a désormais plus aucune raison de vous sentir exclu. La prochaine fois que vos amis scrum masters parleront Agile, vous pourrez vous joindre à eux.
Dites-leur les façons dont votre équipe s’en sert pour s’améliorer et combien vos clients en sont heureux.
Et ces autres amis qui ne l’ont pas encore essayé ? Partager votre amitié en partageant cette information avec eux !
partagez ce billet avec vos amis, collègues et relations professionnelles
Grand problème : l’Humanité a besoin d’un éclairage bon marché, efficace pendant l’obscurité
1er mVP : Feu. Les gens ont observé comment la foudre des cieux pouvait enflammer des forêts et créer le feu. Après expérimentation, en frottant des bouts de bois entre eux, ils ont créé leur propre feu. Problème résolu. Mais le feu n’est pas particulièrement portable.
2ème mVP : Lampes à pétrole, Bougies et Lanternes à Gaz. Maintenant les gens pouvaient emporter la lumière avec eux quand ils se déplaçaient. Problème résolu. Mais les bougies et des lanternes à gaz ne sont pas particulièrement éclairantes et la plus légère brise les éteint.
3ème mVP : Ampoules incandescentes. Les premières ampoules étaient alimentées par batterie et plus fiables qu’une bougie vacillante. Problème résolu. Mais comme les villes ont grandi en taille, la demande pour un éclairage plus répandu a grandi. Le réseau national n’avait pas encore été construit.
4ème mVP : Électricité largement disponible. Pour transmettre l’électricité sur de longues distances, le courant alternatif et les transformateurs ont été développés. Des centrales électriques thermales ont été construites pour satisfaire la demande massive. Problème résolu. Mais comme la demande mondiale en électricité augmentait, des alternatives sont devenues nécessaires.
5ème mVP : Énergie solaire. Des ampoules de consommation en watts inférieures remplacent les ampoules incandescentes originales tandis que les panneaux solaires deviennent plus efficaces et meilleur marché à produire. Problème résolu. Mais les solutions solaires restent encore relativement chères et l’adoption trop faible pour être en position d’éteindre le réseau électrique.
6ème mVP : une Planète dont l’énergie provient seulement du soleil. Des batteries hautement efficaces peuvent être chargées par des panneaux solaires bon marché et omniprésents. À ce point il devient possible d’éliminer notre dépendance aux carburants fossiles. Nous n’y sommes pas encore tout à fait.
Méta Projets Management est partenaire de DantotsuPM
Elon Musk est un entrepreneur qui est exceptionnel dans son application du processus mVP en 3 étapes.
1. Commencez avec un produit simple résolvant un problème minuscule.
Il a lancé une voiture électrique en moins de 3 ans qui est devenue la voiture électrique la plus demandée au monde.
2. Continuez à itérer, en résolvant constamment des problèmes plus grands.
L’autonomie de la batterie continue de s’améliorer pour que les voitures aient davantage d’autonomie et améliore leurs performances: 100km/h en 2.28 secondes, la technologie de conduite sans chauffeur réduit les accidents, la seconde phase de Tesla introduit des bus et des camions électriques, la fusion de Tesla avec Solar City et l’achèvement de Gigafactory.
3. Communiquez constamment la vision du grand problème.
La vision suprême de Musk est une planète actionnée entièrement par le soleil et finalement habiter de multiples planètes. Il n’est pas le meilleur communicant du monde. Beaucoup de ses discours sont maladroits (il s’améliore avec le temps). Mais il a capturé l’attention du monde parce qu’il communique constamment sa vision, en livrant des mVPs tout au long de ce voyage.
Imaginez si Musk avait commencé à résoudre son grand problème en construisant d’abord la Gigafactory (avant Tesla et Solar City). Il pourrait avoir lancé un mVP qui produise 1 batterie par mois. Cette idée n’irait nulle part, parce qu’il ne nous aurait pas embarqué dans ce voyage depuis où nous nous trouvons maintenant vers où il voit que nous devons aller. Son mVP ne serait pas viable.
Les entrepreneurs font très souvent l’erreur de commencer par le grand problème. Ils livrent alors un mVP, mais le marché ne répond pas parce qu’ils ne nous ont pas embarqués sur le voyage exigé. Le résultat ? mVP non viable qui aboutit souvent à un flop.
Processus mVP en 3 étapes en pratique
Disons que vous ayez lancé votre produit. Une poignée de clients a signé pour votre première version. Votre outil de suivi vous dit qu’il y a des téléchargements. Mais vous remarquez aussi que l’engagement est très faible. Vos projections financières sont loin de l’utilisation que vous aviez prévue.
Contrairement à la croyance populaire, ce n’est pas un désastre.
La bonne nouvelle est que les gens adhèrent à une certaine partie de votre vision. C’est le premier pas dans la validation de votre marché. C’est à ce moment que le responsable de la stratégie produit doit sortir du bureau, parler aux clients et comprendre la situation :
Quelle est exactement la partie de votre vision qui a initialement capté leur attention ?
Qu’est-ce qui précisément rend votre produit difficile à utiliser pour atteindre la vision ?
Y a-t-il quelqu’un d’autre qui fait ceci mieux que vous? Que fait-il différemment ?
Le problème est-il que les clients veulent résoudre un problème différent de celui que vous adressez ?
C’est un processus systématique d’analyse et de compréhension du sens. C’est un processus scientifique qui se base sur des données et une métrique bien définie. Mais le processus est guidé par la vision de l’artiste qui imagine un futur meilleur plus enrichissant. Non seulement l’artiste voir l’avenir, mais il peut voir le chemin à parcourir pour atteindre cet avenir. Et il sait que les livraisons de mVPs sont comme des tremplins pour nous déplacer d’ici jusque là-bas.
C’est ma compréhension de ce que fait un Produit Viable Minimal qui est réellement Viable.
Quelle est la vôtre ?
partagez ce billet avec vos amis, collègues et relations professionnelles
The #AgileManifesto is the core of the Agile Movement.
It was written in February 2001 by software practitioners who found consensus around 4 values and 12 Agile principles.
The Agile Manifesto, its 4 values and 12 Agile Principles, were the consequences of industry frustration in the 1990s about the time lag between business requirements and the delivery of technology. Business and customer requisites changed during this lag time, and the final product did not meet the then current needs.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions OVER processes and tools Working software OVER comprehensive documentation Customer collaboration OVER contract negotiation Responding to change OVER following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
The 12 Agile Principles included in the Agile Manifesto describe a culture in which change is welcome, and the customer is the focus of the work.
vous avez trop de travail et pas assez de temps.
Passé se réfère ici aux fonctions existantes ou aux clients existants. Business se réfère aux parties prenantes qui se préoccupent d’articles dont les clients se soucient le plus. Les articles de ce quadrant sont d’habitude appelés des articles de support ou de soutien. Cela pourrait être les corrections à des erreurs signalées par des clients, ou des améliorations mineures à une fonctionnalité déjà livrée pour rendre la vie plus facile au client existant. Les articles de ce quadrant ne vous font pas gagner de nouveaux clients, mais ils ont un impact sur la conservation et la satisfaction des clients existants. Aussi ce quart de cercle est-il souvent financé par la maintenance et des contrats de support, et peut en fait être un quadrant qui génère effectivement du revenu.
Ce quadrant est souvent le seul sur lequel les gens se concentrent, particulièrement s’il y a une grosse pression pour gagner de nouveaux clients. Les articles de ce quadrant ont pour objectif d’aider à attirer plus de clients dans l’avenir. Ce pourraient être de nouvelles fonctionnalités, permettre une montée en volume, ajouter une plate-forme supplémentaire destinée à servir un nouveau type d’utilisateurs.
C’est un quadrant trop souvent négligé. Essentiellement, ce sont les articles qui impactent l’équipe technique. La dette technique en est un bon exemple. Par exemple, une fonctionnalité pourrait avoir été mal écrite et être donc très fragile, générant des bogues chaque fois l’équipe travaille dessus. Habituellement, ces articles ne génèrent pas de revenu additionnel mais, si on les choisit bien, ils peuvent être de gros économiseurs de dépenses. Un autre exemple dans ce secteur pourrait être une chose qui fera gagner beaucoup de temps à l’équipe de support. Par exemple si votre personnel de support doit résoudre des problèmes complexes, capturer des informations complémentaires lors de la connexion pourrait être quelque chose qui les aidera à réduire le temps qu’ils dépensent dans leurs investigations.
Ce quadrant est une projection dans le futur d’une vue technique. Souvent les architectes peuvent proposer des idées pour ce secteur. Peut-être qu’une nouvelle technologie est disponible qui simplifiera significativement votre produit. D’autres items pourraient être des mises à niveau de technologies existantes avant que celles que vous utilisez ne soient dépassées. Par exemple, mise à niveau sur la dernière version Java. Ces articles peuvent parfois rapporter du revenu additionnel, parce qu’ils attirent les clients, mais le plus souvent ce sont des réducteurs de coûts : la nouvelle technologie devrait rendre les développements plus faciles pour votre équipe.
DantotsuPM.com 
The #AgileManifesto is the core of the Agile Movement.
It was written in February 2001 by software practitioners who found consensus around 4 values and 12 Agile principles.