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.
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
La construction de produits formidables exige une compréhension profonde, emphatique de vos utilisateurs. De quoi ont-ils besoin ? Qu’est-ce qui les motive ? Quelle est leur expérience du produit ou processus spécifique ?
Dans ce billet, j’explique comment utiliser des Cartes d’Empathie et des interviews avec des utilisateurs pour construire cette compréhension.
À propos des Cartes d’Empathie
Les Cartes d’Empathie sont un outil simple et puissant pour construire une meilleure compréhension de vos utilisateurs. Il est pas étonnant qu’elles soient les basiques des UX-designers et généralement utilisées dans le Design Thinking. Le nom provient de “Empathie”, qui se réfère à la capacité de comprendre ce qu’une autre personne pense et ressent.
Vous pouvez créer une Carte d’Empathie commune à tous les utilisateurs, ou des cartes différentes pour de multiples segments ou utilisateurs individuels.
Dans tous les cas, les meilleures Cartes d’Empathie sont basées sur des données réelles. Pas sur des conjectures ou des suppositions que vous feriez dans votre équipe. Cela signifie qu’une bonne Carte d’Empathie exige de sortir de nos bureaux pour aller discuter avec de vrais utilisateurs en chair et en os.
Comment construire une Carte d’Empathie
Avec votre équipe (Scrum), identifiez des utilisateurs ou des clients que vous pouvez interviewer pendant 30 à 60 minutes. Si vous interviewez plusieurs personnes, essayez de trouver différents types d’utilisateurs. Incluez des utilisateurs insatisfaits chaque fois que possible. Leur perspective apporte souvent des vues qui vous questionneront.
CertYou est partenaire de DantotsuPM
Préparez l’interview avec votre équipe. Créez une liste de questions ouvertes qui vous aident à comprendre les utilisateurs. Bien que nous soyons au final intéressés par construire un bon produit, les Cartes d’Empathie ne sont pas destinées à évaluer seulement des idées de produit. Concentrez-vous sur l’utilisateur : Quel genre du travail fait-il ? Quels sont les défis auxquels il fait face dans son travail ? Qu’est-ce qui le frustre ? Qu’attendrait-il d’un nouveau produit ? La Carte d’Empathie affichée ci-dessus donne des idées des sortes de questions que vous pouvez poser.
Si c’est la première fois que vous allez interviewer des utilisateurs, il pourrait être avantageux de tester d’abord les interviews dans votre équipe. Pratiquez à tour de rôle en posant des questions ouvertes et en prenant des notes en même temps.
Interviewez les utilisateurs. Vous pouvez le faire avec l’équipe ou vous pouvez vous séparer en binômes. Assurez-vous que chacun dans l’équipe soit impliqué dans le processus. Prenez des notes pendant l’interview ou enregistrez-le (avec la permission de l’utilisateur, évidemment).
Quand vous avez fini de mener les interviews, réunissez votre équipe pour synthétiser l’information et en extraire les points clefs de compréhension des attentes. Utilisez de grands posters avec une Carte d’Empathie, capturez les compréhensions, les citations d’utilisateurs et leurs comportements sur des post-it et positionnez-les dans les secteurs correspondants sur la carte.
Quand vous avez fini de créer ces cartes, discutez-en en équipe. Que vous disent-elles ? Quelles compréhensions avez-nous recueillies ? Vous pouvez ou utiliser les cartes elles-mêmes comme point d’entrée à la génération d’idées ou vous pouvez poursuivre avec d’autres techniques (comme le brainstorming, la visualisation du parcours client, etc).
Comment faire une bonne utilisation des Cartes d’Empathie
Il n’est d’aucune utilité de construire une Carte d’Empathie que l’on ne regarde jamais. Les cartes d’empathie nous permettent de voir notre produit avec les yeux de nos utilisateurs. Cette perspective est facilement perdue au fil du temps, rendant d’autant plus important de garder les utilisateurs tangibles et visibles.
Ci-dessous, deux ou trois astuces :
Carte d’Empathie dans un cadre, par Paul Boag (Boagworld.com)
Les cartes d’Empathie peuvent facilement être métamorphosées en Personas. Un Persona est un utilisateur factice (ou parfois réel). Les Personas décrivent des caractéristiques majeures, des comportements et des attentes. Une façon de le faire est décrite ici.
Certaines équipes encadrent leurs Cartes d’Empathie et les placent quelque part bien en vues. J’ai une fois formé un groupe d’équipes chez ProRail à le faire. Ils ont aussi créé des Personas basés sur de vraies personnes et ont invité ces gens (de temps en temps) à suivre les Revues de Sprint.
En l’absence d’utilisateurs réels, les Personas et des Cartes d’Empathie sont utiles pendant la Planification ou les Revues de Sprint. Parce qu’ils rendent les utilisateurs tangibles et visibles, ils nous aident à regarder notre produit à travers leurs yeux. Comprendraient-ils cette nouvelle fonctionnalité ? L’aimeraient-ils ? Qu’est-ce qui pourrait être frustrant pour eux ?
Bonne chance dans la construction de vos Cartes d’Empathie!
Partagez ce que votre équipe a appris à travers ce processus lors de leur construction. Postez vos exemples de bonnes et vraies Cartes d’Empathie.
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
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
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
Quelqu’un qui a passé du temps dans le cycle de vie de développement de logiciel traditionnel peut certifier que le principe Agile d’accueillir des exigences changeantes peut s’avérer le plus difficile pour des organisations basculant vers Agile. Dans le cycle de vie traditionnel, changer les besoins génère de la frustration, de la colère, du désespoir et, dans certains cas, des frais d’avocats et des coûts additionnels.
CertYou est partenaire de DantotsuPM
Le mouvement Agile demande que les clients et les organisations de développement travaillent ensemble et embrassent le changement pour le plus grand bénéfice de l’utilisateur final. Ce niveau de transparence exige que les murs tombent entre clients et développeurs. Il nécessite aussi que le client reconnaisse l’impact que le changement aura sur le projet et le coût complémentaire du changement sur le budget de projet, ainsi qu’acquérir un meilleur niveau de compréhension du travail.
Le client et les développeurs atteignent une compréhension mutuelle
Dans une mauvaise mise en œuvre de Agile, les clients pensent qu’ils peuvent changer les exigences aussi souvent qu’ils le souhaitent et que le personnel de développement doit gérer ces changements. « Hé, vous avez dit que vous étiez Agiles, non ? »
Dans une bonne mise en œuvre, le client et le développement travaillent ensemble en étroite collaboration pour examiner et adapter le produit à chaque occasion possible. Comme le produit est revu fréquemment, le client et l’équipe maintiennent une compréhension partagée de l’état actuel du produit et de l’état actuel du marché. Quand le client change des exigences, le changement, son coût de mise en œuvre et son impact sur le projet dans son ensemble, sont mutuellement compris.
Jeff Sutherland utilise l’expression « Money for nothing and your change for free » (« l’Argent pour rien et votre changement gratuit ») quand il conseille des organisations sur la façon d’écrire des contrats Agiles (ndlt. Tiens, je ne savais pas que Jeff est fan de Dire Straits). En essence, on tient compte des deux côtés pour avoir une flexibilité maximale; l’équipe de développement tient compte d’exigences changeantes sans modifier le contrat ni charger des honoraires de modification et, en échange, le client consent à participer conjointement au processus Agile et au cycle de vie du développement de logiciel. Dans le cas où le client est satisfait avec moins de travail que prévu à l’origine, ils peuvent finir le contrat plus tôt, avec le paiement d’une partie prédéterminée du contrat restant.
Le changement est bon
La position est que le changement est bon. Il permet au client de satisfaire l’utilisateur final avec les fonctionnalités de plus forte valeur et de terminer le contrat au plus tôt. Il permet à l’entité de développement de recevoir la juste compensation pour livrer tôt et leur permet de se passer à l’opportunité suivante.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
« Accueillir des changements dans les exigences, même tard dans le développement » ne signifie pas que le propriétaire de produit, le « Product Owner », est libre d’ajuster les critères d’acceptation après que le sprint ait commencé. Les processus Agiles qui exploitent le changement pour y gagner un avantage compétitif devraient être mis en œuvre avant l’exécution de sprint. De l’avis de tous, il existe un processus pour terminer un sprint plus tôt; cependant, c’est rare.
Les processus agiles facilitent l’élaboration progressive, la décomposition, le raffinement de l’arriéré de produit, une approche incrémentale et la planification de sprint; Ils exploitent pleinement le changement tout en protégeant l’équipe.
partagez ce billet avec vos amis, collègues et relations professionnelles
La co-localisation est souvent considérée comme un activateur sinon un facteur critique de succès pour réussir le projet.
Alors que cela fait sens pour de petites équipes, comme nous prenons en charge de plus grands produits et projets, il n’est pas toujours faisable d’avoir tout le monde dans la même pièce. Les canaux de communication ne s’accroissent pas linéairement quand la taille d’une équipe grossit et à un certain point cela deviendra impossible d’un point de vue logistique immobilière ou d’une perspective d’efficacité.
Comme la taille d’une initiative grandit, la décomposition de la portée en composants ou lignes de fonction peut permettre la distribution de lots de travail auto-contenus à des équipes plus petites dont les membres pourraient être co-localisés pour réduire le besoin de constante communication. Avoir de telles équipes géographiquement distribuées ne devrait pas être un problème tant que l’on conserve l’opportunité de cérémonies telles que les Mêlée de Mêlées (Scrum of Scrum) pour manager les interdépendances, maintenir l’alignement dans la cadence des releases et remonter les obstacles partagés au bon niveau de résolution.
Livre sur Amazon
Avec une approche distribuée, il est souvent tentant d’utiliser un modèle de travail purement virtuel, particulièrement sur de grandes initiatives où il pourrait y avoir un coût important à rassembler tout le monde de temps à autre. Bien que cela fasse sens au niveau économique à court terme, l’avertissement de Simon Sinek « Leaders Eat Last » ne devrait pas être ignoré : “plus de gens deviennent abstraits, plus nous sommes capables de leur faire mal.”
Sinek fait référence aux expériences de Milgram au début des années 1960 où on a donné aux sujets d’étude l’opportunité de faire mal à quelqu’un d’autre. Alors que seulement 30 % de ces volontaires étaient capables de poursuivre l’expérience quand ils étaient témoins de la douleur (simulée) qu’ils causaient, 65 % étaient capables de le faire quand ils ne voyaient jamais à qui ils faisaient mal.
Notre problème très actuel de « cyber intimidation » est un autre brillant exemple de cela. Tandis que nous sommes toujours biologiquement des animaux sociaux, l’anonymat et la séparation créée par l’Internet et les plates-formes des médias sociaux réduit les impacts personnels d’infliger de la souffrance.
La confiance est aussi difficile à cultiver quand nous n’avons pas rencontré ceux avec qui nous travaillons. Bien que nous espérions que nos collaborateurs nous traiteront comme ils voudraient être traités, il est ardu de sentir psychologiquement en sécurité avec eux s’ils sont juste pour nous une adresse électronique ou un avatar de messagerie instantané. Comme Sinek l’a dit “La confiance ressemble à la lubrification. Elle réduit la friction et crée des conditions beaucoup plus propices à la performance.”
Nous pouvons avoir les différences d’opinions au travail, mais si nous avons rencontré et avons eu l’occasion de socialiser à l’extérieur du bureau, il est beaucoup plus facile de se voir et se traiter comme des êtres humains.
Économisez au besoin, mais n’éliminez pas d’opportunités pour vos équipes de se rencontrer en personne.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
L’expression “ Meilleure Pratique” fait partie de notre lexique depuis plus de ans. Elle est utilisée pour décrire quasiment tout : comment nous manageons les opérations, comment nous recrutons et licencions, comment traiter au mieux les patients atteints de maladie mortelle, comment nous dirigeons nos équipes sportives.
L’expression est devenue omniprésente. Mais y-a-t-il vraiment et réellement des pratiques « les meilleures » qui s’appliqueront dans tous les contextes pour toute organisation ?
Pratique et Contexte
Scott Ambler, qui est bien connu dans le monde Agile, challenge l’assomption qu’il peut y avoir une bonne pratique recommandée qui soit la meilleure dans tous les cas. Au lieu de cela, il propose une alternative, “la pratique contextuelle” dans laquelle la notion de ce qu’est « la meilleure » variera en fonction du contexte.
Le concept de la meilleure pratique, quand introduit dans notre lexique avait pour intention de capturer ce qui avait censément réalisé des résultats définis sur une base cohérente pour quelqu’un dans un certain contexte. Et là se trouve l’apparente simplicité et aussi son manque d’applicabilité directe ailleurs “quelqu’un dans un certain contexte”.
Tous nos contextes sont aussi différents que nous le sommes.
Scrum parle de « cérémonies » qui sont quelque peu la même chose que des pratiques – sauf que les cérémonies sont d’assez haut niveau, assez simples et il est facile de voir comment vous en respectez l’esprit et l’intention quand vous les appliquez sans être aussi doctrinaires que les promoteurs de la “meilleure pratique” le sont généralement . Quoique j’ai récemment vu un tweet disant “Nous sommes Agiles. Sauf quand on en vient à nos processus”. Je vous laisserai réfléchir sur ce tweet …
Agile dans un sens général est plus une question de comportements qu’autre chose. C’est quand nous essayons de faire Agile plutôt que démontrer de l’agilité que nous retrouvons nous-même dans ces débats et commençons à ajouter ce qui au mieux a potentiellement peu de valeur et au pire détruit notre capacité de faire preuve d’agilité.
CertYou est partenaire de DantotsuPM
Je crois que cette attention à ajouter des qualificatifs comme bonne ou meilleure empêche en fin de compte notre capacité de créer un écosystème agile.
“La meilleure Pratique” a-t-elle vu le jour ?
Ce qu’une personne peut penser être une « meilleure pratique », peut amener l’effet opposé pour quelqu’un d’autre dans un contexte différent.
Livre sur Amazon
David Marquet dans « Turn the Ship Around » raconte pendant ses discours que mettre en oeuvre certaines des pratiques on lui a appris pour les sous-marins nucléaires qu’il a été à l’origine formé pour commander, aurait été un échec sur celui qu’il a commandé. Heureusement, un membre de son équipage l’a alerté. Cette sorte d’effet inverse peut coûter des vies. Bien que les pratiques puissent avoir été « les meilleures » sur son premier commandement, elles auraient été catastrophiques sur son poste actuel. Le contexte avait changé. Pensez-y.
De la description du livre : “il a fait du bateau le plus mauvais le meilleur défiant l’approche de disciple-leader traditionnelle de la Marine américaine et mettant en œuvre au lieu de cela sa propre structure leader-leader.”
Rod Collins dans son livre, Wiki Management, décrit 50 pratiques différentes qu’un petit groupe de sociétés d’avant-garde utilise pour s’adapter à la vitesse du changement, plutôt qu’essayer de manager le changement.
Selon Collins :
“Comme les managers luttent pour aller aussi vite que les changements dans leur environnement, ils prennent de plus en plus conscience d’un problème très dérangeant. Ils découvrent que les méthodes et les pratiques qui délivraient toujours des résultats prévisibles de par le passé ne fonctionnent plus désormais.
Livre sur Amazon
Les prévisions deviennent soudainement incertaines comme de nouvelles technologies perturbatrices réorganisent radicalement les marchés. La réduction des coûts n’aboutit pas nécessairement des améliorations en efficacité et en productivité. Les méthodes analytiques prouvées sont maintenant trop lentes et inefficaces pour se maintenir à niveau avec un monde en rapide changement. Et mettre plus de contrôle semble mener les sociétés à perdre le contrôle et parfois leur business.
Dans un monde où le changement est une constante et les règles établies depuis longtemps semblent me plus travailler marcher, il n’est pas surprenant que beaucoup de managers se sentent dépassés par ce qui semble être complètement ingérable. ”
Collins a ajouté un avertissement sur ses cinquante pratiques que pas toutes fonctionneront dans tous les contextes et que même celles que vous considérez vraiment utiliser devront probablement être adaptées à votre contexte.
Remarquez qu’il n’a simplement utilisé le terme de « pratiques » dans qualificatif comme meilleures ou bonnes, seulement des pratiques. Se focaliser sur l’adoption et l’application de pratiques d’autres personnes se base sur le modèle de management hiérarchique traditionnel qui est fondé sur “ le leader omniscient” qui dit aux gens que faire.
Collins a aussi observé que beaucoup de questions challengeant les organisations modernes passent de problèmes discrets à des désordres holistiques. Les hiérarchies traditionnelles sont intrinsèquement inefficaces quand une rapidité de processus décisionnel est nécessaire pour manager à la vitesse des changements et résoudre ces désordres holistiques.
Ces désordres holistiques sont aussi beaucoup trop complexes pour que n’importe quel leader individuel puisse avoir toutes les réponses et solutions. De même ce serait de la folie pure que de supposer que nous pouvons prendre des pratiques inventées dans un contexte différent du nôtre et les appliquer sans plus de réflexion. Vous avez besoin de collaboration chez vos leaders et équipes pour co-créer les solutions qui peuvent marcher dans votre contexte.
Donc nous ne devrions pas perdre espoir en notre propre créativité et compréhension en appliquant simplement les pratiques d’autres personnes – c’est OK de considérer les avis et les idées d’autres (l’accent est mis sur le pluriel), mais si nous ne comprenons pas vraiment quelle est la pratique, comment l’appliquer, quand ne pas l’appliquer, ou si nous ne comprenons pas quand la pratique est faible ou inexistante dans un certain secteur compatible avec notre contexte, alors nous devenons ce que j’appelle un mouton de Panurge (Lemming Method). Nous suivons aveuglément quelque chose que nous ne comprenons fondamentalement pas.
Les qualificatifs ajoutent peu aux idées subjectives. Nous pouvons dire qu’une voiture est plus rapide qu’une autre en réalisant des mesures simples. Mais tant de choses peuvent affecter les résultats que nous obtenons du même jeu de pratiques utilisé par une autre équipe – même dans la même organisation – sans parler d’autres organisations et autres industries.
Nous avons besoin d’être capables de déterminer si incorporer les pratiques de quelqu’un d’autre dans notre propre cas nous apportera quelque chose de valeur.
Obtenons-nous de la valeur de cette pratique ?
Nous devrions toujours nous poser deux questions avant d’adopter les pratiques de quelqu’un d’autre :
Quelle valeur supplémentaire obtiendrai-je je n’ai pas déjà ?
Cela vaut-il le coût de mettre en œuvre cette pratique pour obtenir cette valeur additionnelle ?
Il y a des tas de pratiques de valeur égale ou d’une certaine valeur, sur n’importe quel sujet ou question à laquelle vous pouvez faire face. Il appartient à chaque personne ou équipe de trier comment adapter les pratiques des autres pour pouvoir les appliquer dans leur contexte pour obtenir quelque chose de plus auquel ils accordent de la valeur.
Ce sont des êtres humains, laissent les réfléchir!
Ester Derby a observé que “des adultes signent des contrats, choisissent des camarades de travail, élèvent des enfants et prennent toutes sortes de décisions importantes. Pourquoi nous attendons-nous à ce que ces mêmes adultes aient besoin de supervision rapprochée quand ils viennent travailler ?”
Bonne question !
Les pratiques qui fonctionnent pour une équipe, peuvent échouer misérablement pour une autre. Il peut y avoir quelques vérités générales, mais il n’y en a aucune d’absolue.
Les gens doivent être capables et être encouragé à utiliser leur propre jugement, créativité et compréhension dans le choix de ce qui pourrait aller dans leur contexte, en adaptant les pratiques d’autres personnes à leur situation. Qui sait ? Ils pourraient même en inventer de nouvelles mais seulement si vous, en tant que leader, désirez créer l’environnement dans lequel cela peut arriver.
Bien qu’il y ait des tas de pratiques que vous pouvez vouloir, c’est à vous et vos équipes de décider de manière collaborative ce qui est bon pour votre organisation et dans votre contexte. Et si ce n’est pas bon ? Ne l’utilisez pas. Ou créez vos propres pratiques. Maintenant il y a une réflexion.
Cela ne signifie pas que vous ne pouvez pas apprendre des autres en examinant leurs pratiques.
Cela signifie que vous et vos équipes devriez avoir tant la confiance que le courage de considérer la création de vos propres pratiques appropriées à la résolution de vos propres désordres. Ou bien, combiner des aspects de différentes pratiques avec vos propres adaptations. Et soyez prêts à rapidement faire des adaptations en fonction de ce que vous observez. Et faites preuve d’assez de confiance pour laisser vos équipes et leurs membres réaliser ces adaptations.
CSP est partenaire de DantotsuPM
L’idée de meilleures pratiques est née d’une ère qui se termine.
Celle des hiérarchies et du management traditionnels qui disent aux gens que faire, quand et comment le faire et pour combien de temps le faire. Pour un nombre croissant d’organisations, la rapidité des changements dans notre monde moderne écarte le fait de faire simplement ce que font tous les autres. De plus ce n’est pas très amusant non plus.
Amusez-vous avec vos pratiques, quelles qu’elles puissent être et partout où vous pourriez les trouver. Vous ne devez pas devenir un mouton de Panurge.
partagez ce billet avec vos amis, collègues et relations professionnelles
Décomposer les projets en périodes de temps limitées et connues comme les sprints ou itérations est souvent associé aux approches Agiles, mais peuvent aussi être utilisés pour délivrer par rapport à des exigences détaillées sur un projet complet selon l'(infâme) approche prédictive généralement nommée « en cascade ».
L’avantage est que cela aide à focaliser une équipe sur un jeu d’articles de travail petit, réalisable, et donnant aux parties prenantes de fréquentes occasions de réagir sur des lots de travail achevés en augmentant la transparence et l’objectivité des rapports d’avancement.
Les approches Agiles encouragent la priorisation de l’arriéré de travail et cela peut aussi être une bonne pratique en utilisant des sprints sur des projets traditionnels. Mais cette priorisation pourrait ne pas être suffisante de produire le niveau souhaité d’énergie et de focus de l’équipe. Alors, pourquoi ne pas mettre sur l’agenda permanent de l’équipe de définir des objectifs spécifiques à chaque cérémonie de planification de sprint ?
Les objectifs de sprint peuvent aider en :
Fournissant une mesure de progrès allant au-delà de la livraison d’individuels articles de travail de l’arriéré de produit. Des objectifs de sprint significatifs donnent des événements marquants à célébrer !
Donnant de la visibilité aux accomplissements qui dépassent la livraison du contenu planifié. Par exemple, terminer tous les articles de travail du sprint avec zéro défaut. Ou bien, compléter tous les engagements du sprint sans exiger d’heures supplémentaires de la part des membres d’équipe. Voici 2 choses qui méritent d’être célébrées.
Aidant l’alignement et le focus de l’équipe de livraison et des parties prenantes principales sur un objectif clairement partagé. Cela peut encourager l’autodiscipline dans l’équipe qui peut utiliser l’objectif de sprint comme un déterminant clé pour déterminer si un nouvel élément de travail proposé mérite ou pas d’entrer dans l’arriéré de sprint.
CertYou est partenaire de DantotsuPM
Les objectifs de sprint ne devraient pas être dictés, ils devraient plutôt émerger de la méthode globale de travail collectif de l’équipe et sont un bon contrôle de si l’équipe est alignée sur la vision complète du projet.
En définissant des buts, l’habituel acronyme SMART (Spécifique, Mesurable, Réalisable, Approprié et Temporel) peut être utilisé pour les évaluer et les affiner.
À la fin d’un sprint, la démonstration devrait inclure une présentation des objectifs et si vraiment ils ont été atteints et la cérémonie de rétrospective de l’équipe devrait inclure leur examen et l’identification d’idées d’objectifs pour améliorer les sprints futurs.
Comme l’a dit Albert Einstein: “si vous voulez vivre une vie heureuse, liez-la à un but, pas aux gens ni aux choses.”
Selon Lyssa Adkins, les coach Agile doivent pouvoir enseigner l’approche Agile à leurs équipes en moins de 10 minutes ! Voici ce qu’elle suggère de dire (en anglais).
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a beaucoup de fausses idées sur l’Arriéré de Produit. En fait, je dirais que c’est probablement l’artefact le moins bien compris de Scrum. Et cela peut causer de gros problèmes, pas seulement pour votre produit et son planning, mais pour vos développeurs également. Étant un propriétaire de produit et manager cette chose est un travail difficile et il est facile se tromper. Cet article dissipera certaines des fausses idées sur l’arriéré de produit.
L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs
Beaucoup de gens pense que l’arriéré de produit est essentiellement une grande liste d’histoires d’utilisateurs, classées de la plus haute à la plus faible priorité. Comme si vous aviez un grand tableau et chaque ligne dans le tableau était une histoire d’utilisateur, avec un identificateur, un nom et une description et c’est votre arriéré.
Cela semble agréable et simple, mais c’est un arriéré de produit épouvantable, pour nombre de raisons :
Les histoires ne sont reliées l’une à l’autre d’aucune façon significative
Il n’y a aucune dépendance entre les histoires
Les histoires sont non seulement sans rapport l’une avec l’autre mais elles ne sont liées à aucun horizon particulier ou version
Il n’y a aucune explication “de l’image plus grande” sur comment les histoires touchent au produit, ses fonctions et sa vision.
Un arriéré de produit est vraiment une feuille de route
Un bon arriéré de produit commence par une feuille de route, qui est une vue très de haut niveau de l’avenir du produit. Il y a évidemment beaucoup de choses que nous ne savons pas au commencement, mais un propriétaire de produit devrait commencer par une feuille de route et une vision de comment le produit pourrait se développer puis commencer à décomposer ce plan en des fonctionnalités ou des épopées et des versions ou des horizons.
Il s’agit d’une feuille de route
Cela vous permet de :
Rapprocher des histoires l’une de l’autre, via une fonction ou une épopée
Donner les dépendances entre histoires
Définir les fonctionnalités et épopées et quelle valeur elles fournissent et pourquoi vous les construisez.
Les fonctionnalités et épopées peuvent entrer dans l’arriéré. Et elles peuvent avoir leur propre description avec valeur, risque, bénéfices, dépendances et critères d’acceptation définis. Elles peuvent être évaluées et priorisées. Tout cela fournit “l’image plus grande”, la « big picture ». Si vous avez juste une liste d’histoires, comme quelqu’un l’a une fois dit, vous avez “un sac de feuilles, au lieu d’un arbre”.
Un arriéré de produit devrait être un arbre, pas un sac de feuilles
Donc vous voulez vraiment des histoires dans votre arriéré, mais vous voulez d’autres choses aussi. Et vous voulez que les histoires découlent de ces autres choses. Les histoires entrent en dernier, pas en premier.
Ainsi, si vous voulez un arbre :
Débutez avec une vision de produit et une feuille de route
Décomposez-les en fonctionnalités et épopées
Dressez la carte des fonctionnalités et des épopées sur des horizons ou des versions
Décomposez -les alors en histoires d’utilisateur.
C’est un grand sujet et qui mérite beaucoup plus de couverture. Je recommanderais que vous lisiez User Story Mapping par Jeff Patton si vous voulez en savoir davantage.
Vous n’avez pas besoin d’évaluer toutes les histoires de l’arriéré
Certaines personnes pensent que vous devez avoir des évaluations sur tout dans l’arriéré, parce qu’autrement les items ne sont pas prêts à être travaillés. C’est-à-dire, ils ne respectent pas votre définition de « Prêts » (Ready). Et avoir quelques histoires prêtes à engager est bon, vous n’avez pas besoin que tout l’arriéré soit prêt à être entrepris. Le fait est que certaines des choses dans l’arriéré pourraient ne pas être travaillées avant une longue période de temps. Certaines d’entre elles pourraient ne jamais être développées. Et c’est OK.
Souvenez-vous, votre arriéré est fondamentalement superflu. Pour être plus spécifique, c’est le gâchis de type « Inventaire » en Lean. C’est une pile de choses qui restent là à attendre. Sans faire quoi que ce soit, sans allant où que soit, sans ajouter aucune valeur. Vous pouvez dépenser beaucoup de temps à construire, définir et évaluer un énorme arriéré de choses. Ou vous pouvez dépenser ce temps à faire en réalité du travail. C’est-à-dire à construire un logiciel.
Trouvez le bon équilibre
Il existe un bon équilibre et le trouver n’est pas aisé. Si vous n’évaluez rien, vous ne savez pas combien de temps il faudra pour construire quoi que ce soit. Si vous évaluez tout, c’est beaucoup de travail. Je pense qu’il est bon d’utiliser un système « n+1 » ou « n+2”, où vous avez le prochain ou les 2 sprints suivants de travail bien défini et évalué et prêt à entreprendre. Ainsi, si vous entrez dans la planification de sprint, vous pouvez avoir une vue d’où vous allez vous rendre. Et si les choses changent et que vous décidez de prendre quelque chose d’autre dans l’arriéré qui est un peu plus loin, vous pouvez aussi le faire. Mais vous ne dépensez pas 90 % de votre temps en planification et estimations.
Mais comment faisons-nous la planification d’une version si nous n’avons pas évalué les histoires ?
Les gens se bloquent sur ce point, mais c’est très simple. Vous pouvez simplement utiliser des moyennes. Donc, vous avez les un ou deux sprints d’histoires évaluées et pour le reste de votre arriéré, vous pouvez juste utiliser des points d’histoire médians (pour cette équipe) pour chaque histoire. Si vous avez 50 points d’histoires dans vos deux sprints suivants, avec une moyenne de 6.2 points (ce ne sera probablement pas un nombre de Fibonacci). Vous avez 30 autres histoires dans votre arriéré. Donc votre taille d’arriéré de produit est de 186 (6.2 fois 30) plus 50 (vos sprints évalués) pour un total de 236. Vu ? Facile.
La vérité est, quelques histoires s’avéreront être plus grandes que la moyenne et certaines s’avéreront être plus petites et c’est OK. Parfois votre vitesse sera plus élevée, parfois plus lente et c’est OK. Si vous le pouvez, essayez de faire décomposer les histoires en tailles semblables, proches des 5 ou 8. Cela rend l’affaire plus simple et plus précise. Vous pouvez même faire des estimations approximatives pour des fonctionnalités où vous n’avez pas décomposer les histoires, avec des évaluations de niveau de fonctionnalité, ou en utilisant un nombre moyen d’histoires par fonctionnalité et en multipliant le tout.
Souvenez-vous, l’estimation n’est pas porteuse de tant de valeur en premier lieu. N’y investissez pas trop de temps. Parce que les incertitudes sur les bénéfices sont plus fortes que les incertitudes sur les dépenses.
Vous ne devriez pas mettre chaque idée à laquelle vous pouvez penser dans l’arriéré
Certains propriétaires de produit se lâchent un peu trop quand ils passent sur Agile et disent “Super, je peux mettre tout ce que je veux ici ! Étonnant !”. Et passer les 20 jours suivants à bourrer l’arriéré de plein de particules et des pièces aléatoires, comme des gosses dans une confiserie.
Ce n’est pas une bonne pratique. Souvenez-vous, les articles dans l’arriéré sont une forme de gâchis. Vous voulez une feuille de route claire et une vision pour votre produit, pas une grande liste aléatoire de blanchisserie “de choses qui pourraient être sympas”. L’arriéré devrait refléter votre vision et stratégie pour le produit. Il devrait être capable de prendre en compte des changements, mais ne l’exagérez pas et surinvestissez pas. Concentrez-vous sur votre sprint actuel et paire suivante de sprints. Essayer de penser beaucoup plus loin que cela est de la pure spéculation et n’apporte pas de valeur.
CertYou est partenaire de DantotsuPM
Vous pouvez aussi totalement enlever des choses de l’arriéré
Des personnes pensent qu’une fois que quelque chose entre à l’arriéré, il ne peut jamais en ressortir. Ils pourraient penser “quel serait le point d’ôter quelque chose de l’arriéré ? C’est juste une idée, c’est juste un item de contenu potentiel. Nous pourrions ne jamais le construire, mais il n’y a aucun mal à le garder là”. Il y en a, c’est du superflu. Il introduit de la confusion embrouille les choses. De nouveau, l’arriéré n’est pas une liste de blanchisserie, c’est une feuille de route des fonctionnalités par version et qui reflète une vision et une stratégie de produit. Tenez-le fermement et propre et à jour. N’ayez peur de supprimer des choses. Si vous voulez vraiment y revenir plus tard, vous pourrez probablement la déterrer ou y bien réfléchir de nouveau (les choses peuvent avoir changé et reprendre le besoin pourrait ne pas être une mauvaise chose de toute façon).
Les développeurs devraient avoir voix au chapitre dans l’arriéré de produit
Certains pensent que l’arriéré de produit est exclusivement le domaine du propriétaire de produit. Et c’est partiellement vrai, mais pas tout à fait. Le propriétaire de produit dit ce qui y entre et dans quel ordre. Il est responsable de l’arriéré de produit. Et généralement, les développeurs s’occupent de l’arriéré de sprint, puisque c’est leur domaine. Ils construisent la portée qui entre dans le sprint. Mais un propriétaire de produit avisé parle toujours à l’équipe comme il construit et manage l’arriéré.
Les développeurs comprennent de domaine technique du produit. Ils comprennent ce sur quoi d’autres équipes travaillent et quelles nouvelles technologies arrivent (au minimum, ils le devraient). Ils comprennent les risques techniques et les dépendances dans le travail. Donc la discussion sur l’arriéré de produit avec eux est extrêmement importante.
La planification de sprint devrait être un environnement “sans aucune surprise”. Personne ne devrait lever la main en lisant un article de l’arriéré et dire “qu’est-ce diable que cela ? Je n’ai même aucune idée de ce que cela signifie ». La planification de sprint devrait être le choix final de quels articles de portée bien définis et compris de l’équipe prêts pour entrer dans le sprint.
J’espère que cet article effacera quelques fausses idées sur l’arriéré de produit! C’est un sujet important, difficile et il existe beaucoup de lectures que vous pouvez faire si vous êtes intéressés par ce sujet.
partagez ce billet avec vos amis, collègues et relations professionnelles
Règles de base
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.
Vous ne pouvez pas être 100 % précis, n’y passez donc pas trop de temps. Personne ne connait l’avenir avec précision.
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.
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.
Pratique et Contexte
Donc nous ne devrions pas perdre espoir en notre propre créativité et compréhension en appliquant simplement les pratiques d’autres personnes – c’est OK de considérer les avis et les idées d’autres (l’accent est mis sur le pluriel), mais si nous ne comprenons pas vraiment quelle est la pratique, comment l’appliquer, quand ne pas l’appliquer, ou si nous ne comprenons pas quand la pratique est faible ou inexistante dans un certain secteur compatible avec notre contexte, alors nous devenons ce que j’appelle un mouton de Panurge (Lemming Method). Nous suivons aveuglément quelque chose que nous ne comprenons fondamentalement pas.
Nous devrions toujours nous poser deux questions avant d’adopter les pratiques de quelqu’un d’autre :
Bonne question !
DantotsuPM.com 
