Plusieurs documents et des pointeurs vers des formations et du développement personnel en ce mois estival où les lecteurs avaient peut-être plus de temps pour réfléchir à comment développer leurs propres capacités et compétences.
Si vous ne connaissez pas encore ce guide centré sur l’association du Lean Project Management et des projets de transformations organisationnelles, il n’est pas trop tard pour le lire !
Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie mais il y a 2 principes pour en déterminer la valeur optimale pour votre projet.
On me demande souvent, ‘Combien de temps devrait durer un Sprint pour mon équipe ?’ Et ‘le Sprint doit-il être de durée fixe ?’. Je constate qu’il ne suffit pas de répondre : « N’y réfléchissez-y pas trop longtemps. Si vous utilisez un environnement raisonnable et un langage de développement comme Java ou dot-net, utilisez une durée de Sprint de deux semaines. Cela semble marcher pour la plupart des équipes, mais certains utilisent une semaine ou trois semaines. Voyez simplement ce qui vous convient. »
Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie.
Deux principes sur la durée
Il y a deux principes pour déterminer la durée d’un Sprint.
Le Sprint ne devrait pas être changé après son démarrage.
Les Sprints devraient être de même durée.
Ne pas se mentir à soi-même ni à l’équipe
Je pense que la première règle est claire et directe. Ce serait tricher que de changer la durée du Sprint après qu’il ait commencé. Si l’équipe ferme les yeux sur le changement de la durée de Sprint, elle sera tentée de changer la définition de « Done » pour permettre certains changements de contenu. Ceci est une mauvaise chose: La chose correcte à faire est d’ajouter une autre histoire utilisateur (User story) à l’Arriéré de produit (Product Backlog).
Quant aux Sprints devant tous être de même durée, c’est un peu plus délicat. J’ai déjà dit qu’un Sprint de démarrage pourrait être de seulement une semaine, donc, clairement je ne suis pas totalement inflexible sur le fait que tous les Sprints devraient être de même durée. Puisqu’un Sprint est une boucle de retour d’information, l’équipe doit prendre en compte les parties prenantes. Avoir une durée de Sprint fixe donne aux parties prenantes un rythme constant pour les revues de livrables, ce qui est réconfortant et installe une routine familière. Cependant, avoir des durées de Sprint différentes pour des Sprints spécialisés, comme la prise en compte des périodes de fêtes (ou des vacances), ou une autre raison dont l’équipe et les parties prenantes peuvent convenir, ne me semble pas être une terriblement mauvaise chose.
Est-ce assez long ?
Un Sprint doit être assez long pour vraiment achever des histoires (user stories). C’est-à-dire l’équipe doit pouvoir amener ses histoires jusqu’à leur état fini (« done »). C’est une règle dans Scrum qu’un Sprint ne devrait jamais excéder un mois. En général, la longueur de Sprint devrait être approximativement de trois fois le temps nécessaire à analyser et réaliser totalement une histoire de taille moyenne. Ceci semble donner assez de flexibilité dans le système pour permettre à l’équipe de s’auto-organiser pour obtenir un travail fini. Mon expérience est qu’une histoire prend environ 2-3 jours pour une équipe typique qui est bien en place, donc une longueur de Sprint raisonnable est deux semaines. Cependant, les environnements sont différents; certains sont plus faciles (ou plus difficiles) que d’autres. Je m’attends donc à ce que les longueurs de Sprint d’une équipe varient largement en fonction de ces différences d’environnement.
Est-ce assez court ?
La durée de Sprint devrait être suffisamment courte pour que le changement d’avis sur les besoins soit plus lent que la durée du Sprint. C’est-à-dire, si la durée de Sprint est de deux semaines, l’équipe espère que les changements de besoins arrivent plus lentement que toutes les deux semaines. Ce qui veut dire que les parties prenantes peuvent attendre jusqu’à la fin du Sprint pour voir leur ‘nouveau truc’ délivré avant de vouloir le changer.
Dans l’environnement business actuel, il est typique que la modification de besoins soit trop rapide pour le Sprint. Il y a des bogues à réparer dans d’autres systèmes que l’équipe maintient, il y a des cas d’urgence partout dans l’organisation à fixer et les parties prenantes changent presque constamment d’avis sur ce qui est important. Ce sont autant de raisons pour que l’équipe raccourcisse la durée de Sprint ou celle du cycle de planification.
Des choses se produisent et les équipes développent des méthodes pour manager le fait que des besoins devraient être changés plus d’une fois par Sprint.
Soyez ouverts à re-planification
Parfois la durée de Sprint d’une équipe est juste trop longue pour que survivent les accords pris : la fréquence de changement des besoins est plus rapide que la longueur de Sprint ne peut le supporter. Il est tentant d’essayer de raccourcir les Sprints, mais peut-être n’est-ce pas faisable parce que les parties prenantes ne peuvent pas manager des revues plus fréquentes, ou parce que l’équipe ne peut pas développer plus rapidement.
Essayez Bubble Plan !
Que fait l’équipe ?
Scrum n’est rien sinon adaptatif. En fait, si l’équipe ne s’adapte pas pour respecter ses propres réalités, ce n’est pas du Scrum. Alors, adaptez-vous… l’équipe pourrait avoir des sessions de planification de Sprint plus fréquentes – peut-être une fois par semaine.
Par exemple, si l’équipe a une durée de Sprint de deux semaines, du lundi au vendredi deux semaines plus tard. Alors, l’équipe pourrait planifier chaque lundi, et non pas seulement un lundi sur deux. Le premier lundi l’équipe remplirait son Sprint à environ 80 % de sa capacité et le deuxième lundi les membres de l’équipe se poseraient la question : « qu’ajoutons-nous maintenant ? »
Je constate que beaucoup d’équipes se sont spontanément déplacées vers ce système, donc c’est un modèle connu qui est très efficace. Il devrait faire partie de la boîte à outils du ScrumMaster.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Eloge de la gentillesse de Emmanuel Jaffelin car « Les gens gentils sont en meilleure santé… »
People Styles at Work and Beyond par Robert Dorothy Bolton pour apprendre à reconnaitre la personnalité et les styles de comportement des gens et mieux travailler avec eux.
Les 5 clés pour prendre les bonnes décisions par Yann Coirault et Pia De Buchet, car loin d’être le seul fait de la raison, les décisions sont largement influencées par les émotions et l’intuition.
Political Dilemmas at Work de Gary Ranker, Mike Phipps, Colin Gautrey. Car, « Votre patron est parti et son successeur doit encore être nommé. Soudainement personne n’est tout à fait sûr de quoi faire », sauf VOUS.
Manager les e-comportements de Jean-Michel Rolland. Technopathe, technophile, technophobe… comment motiver les collaborateurs 2.0 ?
Right-Brain Project Management de Michael Aucouin qui explique comment nous prenons des décisions basées sur comment nous ressentons les résultats potentiels.
Techniques et innovation
PVaR – Project Value at Risk A new indicator for connecting risks to the most important questions in project management: when will the project be completed and at what cost?
Managing Software Debtde Chris Sterling car quand les délais sont trop compressés, ils seront néanmoins respectés mais au sacrifice du design, de la planification ou de la qualité, et il se peut alors que vous accumuliez une dette.
The Mythical Man-Month de Frederick Brooks. En général, les chefs de projets ont entendu parler de la loi de Brooks mais en connaissent-ils les détails.
La Chaîne Critique en Pratique par Isabelle ICORD, experte de la pratique de la Chaîne Critique et à l’origine des toutes premières implémentations pratiques de ce concept en France.
Un livre de référence sur ce sujet
The Lean Startup How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Le plus petit pas de Nicolas Gouy pour l’histoire d’une transformation Agile, Scrum et XP à grande échelle.
Talent Is Overrated de Geoffrey Colvin. Parce qu’être capable d’exécuter une activité n’est en rien une garantie que vous la ferez bien, et encore moins que vous vous y améliorez.
The Energy Bus de Jon Gordon pour générer plus d’énergie dans l’équipe projet que vous n’en consommez.
L’accordeur de talents de Jean Pierre Doly, pour de nouvelles organisations et nouvelles façons de travailler.
Booster l’intelligence collective de Olivier D’Herbemont car tous les jours on nous parle de l’Intelligence Collective, qui en rassemblant toute une communauté de personnes autour de défis complexes, engendre des résultats étonnants et novateurs. Mais qu’est-ce que cela signifie réellement?
La certification agile version PMI®, PMI-ACP®: Mon retour d’expérience, par Martial Bellec PMP, PgMP, PMI-ACP, C2MPC
Martial Bellec
Hello,
Le 25 Octobre, j’ai passé avec succès la certification PMI-ACP®, en candidat libre, c’était ma première tentative.
Pourquoi ?
Ce qui m’a motivé au départ, c’est que PMI a opté, non pas pour créer une méthodologie agile de plus, mais pour favoriser l’acquisition d’une bonne connaissance générale des méthodologies et une connaissance approfondie du fameux « mindset agile ».
Pour la préparation, j’ai passé environ 50 heures entre le 19 août et le 25 octobre
Partenaire de DantotsuPM
Cours
J’ai suivi un cours Scrum de 3 jours mais je suis resté sur ma faim pour la certification car je connaissais déjà Scrum. Le bon point néanmoins est que cette formation ouvre droit aux 21 heures de formation nécessaires au dossier PMI.
Je n’ai pas suivi de cours de préparation PMI-ACP®, les dates étaient trop tardives par rapport à mon objectif de passer en 2 mois.
Dossier
Concernant le dossier d’éligibilité, étant déjà PMP®, cela a été facile à remplir en mentionnant mes 3 projets agiles au cours des 2 dernières années.
Comme je dirige un projet agile en même temps, j’étais toujours en interrogation entre la vraie vie et la théorie, c’est très efficace comme toujours !
Le bouquin « PMI-ACP Exam Prep » de Mike Griffiths: je trouve qu’il ne prépare pas vraiment à l’examen mais il regorge de bonnes pratiques pas toujours connues : affinity estimation, Kano, Dreyfus, etc. et c’est donc une vraie référence facile à utiliser au quotidien, à avoir absolument même si on ne vise pas la certife,
Je déconseille le book des 1000 questions « PMI-ACP Exam Prep: 1000+ PMI-ACP Practice Questions with Detailed Solutions » pas fini et en mauvais anglais (du moins pour un Breton comme moi)
Révisions de dernière minute
J’ai passé le dimanche avant l’examen à faire des questions et à butiner toutes ces références qui se contredisent quelques fois…
L’examen
Il est moins important de bachoter que pour le PMP, car:
Pratiquement aucune question ne porte sur les définitions ou bonnes pratiques (les fameux ITTO « Inputs, Tools, Techniques and Outputs » du PMBOK Guide). Pour l’agile ça aurait pu être par exemple : dans une rétrospective, quel est l’agenda à suivre ? Data gathering, issues identification, prioritization and improvement plan. Mais rien de ça !
si vous voulez être testé sur vos connaissances des nombreux outils agiles : comment écrire un bon user story (INVEST), ou bien tenir votre backlog (DEEP), passez votre chemin ! Vous ne serez pas testé là-dessus non plus.
En revanche, pratiquement TOUTES les questions sont des questions situationnelles, ou les rôles sont (très habilement selon moi) intriqués.
Les situations décrivent n’importe qui concerné de près ou de loin par le projet agile
Agile practitioner
Product owner
Sponsor
Stakeholder
Project manager, qui est, selon la question Scrum master ou relais avec les execs
Les « objets » agiles sont toujours les mêmes et assez basiques : product backlog, risk, priority, value, kanban, Ishikawa… attention cependant au risk-adjusted backlog.
Dans une situation particulière, cette personne concernée par le projet Agile doit choisir parmi 4 possibilités ce qui est le mieux à faire immédiatement.
Comme tout est en anglais, chaque mot compte. Attention il faut avoir un bon niveau d’anglais, même si le vocabulaire est « globbish »… il faut savoir très rapidement en comprendre le sens.
Généralement, il reste 2 réponses entre lesquelles il est difficile de trancher mais en relisant patiemment, la bonne apparaît enfin et semble alors évidente.
J’ai répondu aux 120 questions en 2 heures 6. J’avais environ 30 questions marquées et j’ai pu également repasser en revue les 80 premières d’ici la fin des 3 heures allouées.
Les facteurs clefs de succès
Selon moi, il faut très bien comprendre le Agile manifesto et l’agile mindset et l’avoir déjà pratiqué sur des projets difficiles est un plus.
Je me suis entraîné à un memory dump de 5 minutes (pour occuper utilement les 15 premières minutes de l’examen qui sont en fait une démonstration de l’interface utilisateur PROMETRIC):
manifesto,
xp,
Kanban,
Scrum,
acronymes,
evm,
Dreyfus,
Shu ha ri,
lean principles
Mais ça a peu servi pendant l’examen, le seul avantage est que je vais désormais me servir de cette carte au quotidien !
En conclusion
Je recommande cette certification car elle complète très bien le PMP®. Elle est aussi plus exhaustive que la scrum alliance, car PMI a une approche GENERALISTE (très bonne culture agile et des méthodologies).
Je suis enfin intimement convaincu, dans un contexte client, que le chef de projet de demain devra fonctionner indifféremment en waterfall et/ou agile sans les opposer mais plutôt en comprenant finement les avantages et inconvénients des 2 dans la situation réelle.
Cette hybridation des méthodes est un vrai challenge pour notre profession et PMI-ACP® me semble être un incontournable sur cette route.
CertYou est partenaire de DantotsuPM
Note : PMI, PMP et PMI-ACP sont des marques déposées de Project Management Institute, Inc.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
PRINCE2 Agile est une solution de management de projet qui combine les qualités de gouvernance et de management de PRINCE2 avec la flexibilité des concepts Agile.
Partenaire de DantotsuPM
PRINCE2 Agile a été construit de manière collaborative avec des experts PRINCE2 et des « Agilistes ».
Partenaire de DantotsuPM
PRINCE2 Agile couvre les approches Scrum, Kanban, Lean Startup et Cynefin et utilise les principes de PRINCE2 avec 5 comportements clés:
Transparence
Collaboration
Communication
Auto Organisation
Exploration
Partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je me rends compte que le concept de Sprint Zéro est controversé. Et dans mes premiers temps en Agile, j’ai été étonné par l’importance accordée à ce sujet. Je pensais que nous aurions des sessions de transfert de connaissances au fil du travail, alors, pourquoi avoir un sprint séparé ? Mais plus tard j’ai compris l’importance du Sprint Zéro dans l’organisation où je travaille. Je ne prétendrai pas que toutes les équipes en ont besoin, mais voici pourquoi c’est utile pour nous.
Les questions abordées au Sprint Zéro s’appliquent à la release toute entière.
Nous pourrions l’appeler Sprint Initial, Itération Zéro, ou Sprint de démarrage.
Selon mon expérience, le Sprint Zéro est limité dans le temps à seulement une semaine.
Notre équipe passe en revue l’ensemble des items de la release et quel travail devrait être achevé dans chaque sprint. En passant en revue chaque article de sprint, l’équipe identifie les endroits pour lesquels nous ne connaissons pas suffisamment bien les exigences qu’elles soient matérielles, d’architecture, logicielles, ou techniques.
Après que l’équipe ait revu les épics (ndlt. groupe de User Stories pour fournir une valeur métier) et fonctions priorisés de l’arriéré de produit, nous devons les annoter et préparer les sessions de revue avec le product owner, le propriétaire de produit. Nous devons comprendre l’environnement et le code exigé pour les items de l’arriéré de produit, indépendamment de si le code sera simple ou complexe.
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)
La raison principale d’introduire un Sprint Zéro est que nous ne voulons pas inutilement prolonger le temps nécessaire aux sessions de revue ou de transfert de connaissance depuis le Sprint 1 jusqu’à la fin. Donc, nous prenons une semaine pour préparer notre équipe avant de démarrer sur des arriérés de sprint.
Grâce à Agile, on nous donne l’opportunité d’en apprendre beaucoup en peu de temps.
L’équipe avancera de façon calme, sans pression excessive.
CertYou est partenaire de DantotsuPM
Utilisez-vous un sprint 0 en début de release sur votre projet Agile? Pourquoi? Quels en sont pour vous les bénéfices et inconvénients ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.
En fait, je vais aller plus loin et poser une affirmation audacieuse :
Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.
En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.
« Les plans ne sont rien. La planification est tout. »
Ceci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.
Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.
Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :
Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.
Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?
Pourquoi les projets entrent-ils dans une telle spirale ?
Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information
Les projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :
Peu ou pas d’informations sur le travail qui a besoin d’être fait
Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)
Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).
Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:
« Aucun plan ne survit au contact avec l’ennemi. »
Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.
Les projets agiles planifient à plusieurs reprises par petits morceaux
Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).
Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :
Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
Pouvant être achevé en un sprint (qui est souvent de deux semaines).
Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.
Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.
Un si petit plan apporte-t-il vraiment de la valeur ?
Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».
Bien sûr, mais deux points :
Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.
Une grande partie de la valeur réside dans la Planification, pas dans le Plan.
Rappelez-vous la précédente citation de Eisenhower.
Les membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.
Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?
Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.
Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.
Microsoft est partenaire de DantotsuPM
I.N.V.E.S.T.
I – Indépendante
N– Négociable
V– de Valeur
E – Estimable
S – Suffisamment petite
T – Testable
Indépendante
Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.
Négociable
Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.
de Valeur
Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.
Estimable
Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».
Suffisamment petite
Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.
Testable
Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.
Découpage vertical ou horizontal
Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.
Des exemples de découpe de « User Stories »
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits
Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…
En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.
Et/ou
En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.
Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.
Découpage par flux de travail
revoir mon panier de courses
Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :
Fournir mes informations bancaires
En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.
En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
Recevoir une notification par SMS
En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.
D’autres méthodes
Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :
Visitez le blog Agilistic
par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
par options d’interaction / par plate-forme
par types de données ou paramètres
par scénarios de test
par rôles
par ‘j’optimisemaintenant ‘ contre ‘ j’optimise plus tard ‘
par compatibilité de navigateur
la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.
Ce billet m’a été inspiré par “The 6 not-so-obvious reasons a project plan fails” dont j’ai choisi de prendre le contrepied pour les transformer en raisons (ou conditions) de réussite !
En fait, les petits projets ont 10 fois plus de chances de réussirselon le rapport « Chaos Manifesto » et seront deux fois plus probablement dans les temps, dans le respect de leur budget et la livraison des fonctionnalités critiques attendues. Il n’est bien sûr aucunement garanti que tout petit projet réussisse…
Voici 6 des raisons pour lesquelles un petit projet ou au moins de taille raisonnable aura de meilleures chances de réussir
1. Des méthodes flexibles
soyez flexibles 🙂
Tous les projets, même petits, ont beaucoup de composants en mouvement. Si vous travaillez dans le marketing, les ressources humaines, l’informatique, la construction ou autre industrie, l’agilité et la flexibilité sont de réels atouts pour vos projets. Le chef de projet Agile qui s’est développé avec l’adoption de postures et principes tel le Manifeste Agile, avec des artefacts et méthodes comme Scrum et des solutions logicielles de management de projet plus collaboratives. Adopter des méthodes flexibles permet d’être mieux armé pour manager un projet dans l’environnement actuel qui est en perpétuelle et rapide transformation. Le projet managé avec Agile génèrera du revenu plus rapidement grâce à la livraison itérative de solutions certes incomplètes mais apportant de la valeur rapidement. De plus, les bénéfices seront également plus importants en bout de course car les fonctions non critiques ne seront probablement jamais développées avec ces approches.
2. Des solutions logicielles performantes
Un outil performant devra être mis en œuvre (même sur un projet de petite taille). Les coûts d’acquisition, de configuration et d’utilisation sont devenus plus abordables (en particulier dans le Cloud). Selon Information Week les sociétés à haute-performance comprennent l’importance des logiciels de planification de projets en matière d’efficacité et de performance. Leurs principaux critères de sélection sont la fiabilité, la facilité d’intégration et la facilité d’usage (la convivialité). Le bon logiciel devrait aussi converser de manière transparente avec les outils universels de l’entreprise comme la bureautique.
Microsoft est partenaire de DantotsuPM
3. Un travail efficace avec des équipes virtuelles
Avec des équipes travaillant à distance à distance, et souvent à l’échelle mondiale même dans les petites structures, sur des fuseaux horaires différents et des cultures variées, bien communiquer et bien manager le temps sont devenus plus critiques que jamais. Donner accès à des outils qui laissent des parties prenantes s’auto-manager et partager les derniers statuts, discussions et échéanciers de projet maintient tout le monde connecté et organisé.
Campana & Schott est partenaire de DantotsuPM
4. Un fort support du management
Avoir un sponsor exécutif avec un réel intérêt dans le projet, quelqu’un qui ira se battre pour votre projet du début à la fin, est un grand facteur (sinon le plus grand) dans le succès du projet. L’avoir est déjà bien, mais l’engager activement pour qu’il donne une direction claire et aide dans la résolution rapide des problèmes est encore mieux. Le manque de temps est souvent un problème. Aussi, avant le démarrage du projet, Le sponsor et le chef de projet devraient se rencontrer pour discuter des questions comme l’engagement de temps, les rapports d’avancement, les réunions, les mécanismes de remontée de problèmes, etc.
5. Un parfait alignement pas sur les objectifs et stratégies de l’organisation
Restons bien alignés sur la stratégie de l’entreprise.
Être bien aligné sur la stratégie business n’est pas aisé pour le projet. Cependant, c’est un impératif pour avoir de bonnes chances de réussite. Il est critique d’avoir une compréhension des priorités stratégiques clés de la société puis d’examiner le projet pour voir comment il se justifie par rapport à celles-ci. Ceci va aider à positionner le projet dans la liste des priorités de l’entreprise. En plus d’économiser un temps, des efforts et ressources précieux, cela aide aussi à obtenir le support exécutif nécessaire.
MPM est Partenaire de DantotsuPM
6. Une excellente communication
Le PMI® a constaté qu’une des causes majeures de réussite rapportée par les sociétés est une communication supérieure. La capacité à communiquer en temps réel avec les membres de l’équipe où qu’ils soient grâce aux logiciels de management de projet collaboratifs sécurise le succès d’un projet.
NQI est Partenaire de DantotsuPM
A chaque piège sa solution !
Du plus simple au plus complexe, il y a beaucoup de pièges qui peuvent emporter un projet. Mais pour chaque piège, il y a aussi une solution.
Les organisations ultra performantes ont compris qu’il n’y a pas de temps à perdre pour implémenter ces changements si nécessaires.
PMI is a registered mark of Project Management Institute, Inc.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.
En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.
Partenaire de DantotsuPM
Premier terme Agile – Initiation
A few videos to get started on Agile, Scrum and Kanban
Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.
Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.
De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.
Partenaire de DantotsuPM
En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.
Second terme Agile – Work package (Lot de travail)
Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des frontières comprises et communicables.
Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.
Troisième terme Agile – Tolérance
Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.
Partenaire de DantotsuPM
Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.
Produit Viable Minimum (MVP)
La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.
Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.
Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La technique Scrum of Scrums (SoS) sert à augmenter la portée de Scrum et autres techniques Agiles et les appliquer à de plus grands efforts. Sur le papier, le SoS est une simple extrapolation des réunions quotidiennes de Scrum ou stand-up meeting qui sont devenues le label de la pratique Agile. Une typique réunion debout se produit chaque jour pour que tous les membres de l’équipe puissent coordonner et planifier les activités du jour. Classiquement, l’équipe utilise la technique des trois questions pour organiser la réunion. De la même manière, une session Scrum of Scrums typique agit comme un focus pour aider à synchroniser une équipe d’équipes ou même plusieurs équipes d’équipes.
Il y a quatre basiques pour SoS qui doivent être compris avant toute adaptation.
1. Qui participe
Il y a deux écoles de pensée dans le choix des participants au SoS. La première (et plus commune) école suggère que le Scrum Master soit présent lors du SoS. Le Scaled Agile Framework Enterprise (SAFe) est un exemple d’une méthodologie qui met à profit le Scrum Master tant pendant l’événement de planification que pendant l’incrément de programme. Alors que le deuxième groupe adopte une approche plus égalitaire (probablement plus pragmatique) permettant à chaque équipe de choisir un participant qui peut le plus facilement transmettre ou comprendre que les problèmes actuels de l’équipe et du plus grand groupe à cet instant. Par exemple, si les décisions de conception sont primordiales, peut-être des membres de l’équipe avec la grande compréhension UX. Dans ce scénario, les participants varieraient au fil du temps.
2. Qui facilite
Pour de petits SoS, par exemple une poignée d’équipes co-localisées, une facilitation peut ne pas être exigée. Le SoS peut s’auto-organiser et exécuter la réunion avec peu de facilitation additionnelle. Cependant, comme le nombre de participants augmente (je limite les réunions SoS en utilisant la même règle 5 à 9 membres utilisée dans les équipes Scrum) ou comme la distribution géographique des membres s’accroit, la facilitation devient plus importante. Les facilitateurs aident l’équipe à utiliser la pratique du SoS, s’assurent que la logistique est en place et gèrent le temps. Dans de plus grands efforts, un Directeur de Programmes fournit souvent la facilitation, ou si vous pratiquez SAFe, le Release Train Engineer joue ce rôle de facilitateur.
3. Fréquence
Image courtesy of pakorn / FreeDigitalPhotos.net
Le Scrum of Scrums suit souvent le même modèle que la réunion quotidienne de Scrum/Stand-Up. Un deuxième modèle de fréquence est basée sur le niveau de risque; la fréquence des réunions SoS varient en fonction du besoin. Tôt dans un projet le SoS se tient quotidiennement comme les équipes se forment, se trouvent et que les premières décisions sont construites. La réunion SoS passe à deux fois par semaine au milieu du projet et revient ensuite à quotidienne comme une fin de release approche.
4. Format
Les réunions quotidiennes debout déroulent généralement la classique approche avec trois questions (Qu’ai-je fait ? Que vais-je faire ? Et quels sont mes points de blocage ?).
La réunion Scrum of Scrums suit généralement un format TRÈS SEMBLABLE avec chaque participant qui répond aux quatre questions suivantes :
Qu’est-ce que mon équipe a fait depuis la dernière réunion ?
Que fera-t-elle avant que nous ne nous rencontrions de nouveau ?
Mon équipe rencontre-t-elle des points de blocage ?
Mon équipe va-t-elle délivrer quelque chose qui est sur le chemin d’une autre équipe ?
La réunion suit la même approche : chaque participant interagit à tour de rôle avec les autres. Le facilitateur (si utilisé) ne devrait jamais être au centre de la réunion, et le SoS ne devrait pas dériver en une réunion de statut d’avancement.
Le stand-up quotidien et le SoS Sont des réunions très semblables. Les deux réunions sont tenues pour partager des informations, coordonner des activités et identifier des problèmes. Le périmètre de la réunion SoS est plus large qu’une seule équipe et cette réunion fournit la coordination et les activités de planification dans et transverses aux équipes.
partagez ce billet avec vos amis, collègues et relations professionnelles
Sur les 10 dernières années, aucune certification n’a autant raflé les premières places que celles en management de projet.
Dans les faits, ces certifications sont les plus recherchées par les recruteurs dans le monde entier.
Partenaire de DantotsuPM
Le monde est complexe et tout ou presque peut être considéré comme un projet.
Partenaire de DantotsuPM
Alors, si vous faites déjà partie de cette profession ou avez décidé de vous orienter vers celle-ci, quelles certifications briguer ? Les plus établies, comme les 3 premières ou bien celles en forte croissance comme Certified ScrumMaster ?
Selon Arvind Rongala de Invensis Learning, voici le top 10.
Scrum est depuis longtemps la plus populaire des approches Agile pour développement logiciel.
Amy Thompson
Mais de quoi s’agit-il vraiment ? À quoi ressemble une grande équipe Scrum? Scrum est-elle réellement la collection d’approches flexible, libre d’esprit et que l’on pense pouvoir adapter pour convenir à tout ce qui marche pour nos efforts ? Dans nos tentatives d’être ‘Agile’, avons-nous oublié les avantages de la structure et de la discipline ? Adaptons-nous Scrum un peu trop pour nous convenir et quel en est l’impact ?
J’ai travaillé avec beaucoup d’équipes Scrum et Kanban, y compris celles qui utilisent de plus lourdes méthodologies Agile comme SAFe et RUP et celles qui fonctionnent indépendamment au sein d’une organisation en cascade (Waterfall). Cependant, chaque fois que je travaille dans un nouvel endroit, je vois les mêmes problèmes encore et encore qui empêchent les équipes d’atteindre leur potentiel à être extrêmement performantes. Idem quand je participe à des réunions et conférences Agiles et parle aux gens de comment ils ont essayé de ‘devenir Agile’, mais que cela ne semble pas fonctionner pour eux.
Partenaire de DantotsuPM
Récemment, j’ai vu une tendance croissante des professionnels Agile à en arriver à la conclusion qu’une approche plus évangéliste parviendra plus probablement à amener le succès aux Business et équipes.
L’adhésion du management est essentielle, cependant que je voudrais concentrer ma discussion (vidéo en anglais ci-dessous) sur pourquoi je crois que la discipline, la routine, la structure et une compréhension minutieuse du processus Scrum sont clés à une grande équipe Scrum. Et aussi, expliquer que ceci ne signifie pas que l’équipe est étranglée dans sa créativité, ni contrôlées par leurs environnements, c’est en réalité tout le contraire … (voici le pointeur vers la présentation en pdf)
partagez ce billet avec vos amis, collègues et relations professionnelles
La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des responsabilités (dont le RACI est un exemple) sert à documenter les rôles et responsabilités de chacun dans le projet.
Si l’on vous pose cette question lors d’un entretien de recrutement ou bien si vous vous la posez au lancement d’un nouveau projet, voici quelques éléments constitutifs importants.
Même si nous n’en sommes souvent pas conscients, nous l’utilisons tous les jours. Dans le domaine professionnel, elle joue un rôle très important. C’est pour cela qu’il est important d’apprendre à bien décoder les expressions du visage, les gestes, etc.
Félicitations – on vient de vous donner l’occasion de manager un projet très novateur – si unique, en fait, que rien de semblable n’a jamais été essayé par votre organisation !
En fait, c’est la méthode qui importe le plus et dans le cas de cette exercice, une approche Agile basée sur des expérimentations rapides et répétées pour trouver la meilleure piste et l’exploiter pleinement.
L’ »étoile de mer » est une excellente activité lors de la collecte de données pour favoriser la réflexion autour des pratiques et de la valeur que l’équipe en retire. Elle aide des membres de l’équipe à comprendre la valeur perçue par chacun sur ces pratiques.
L’étoile de mer divise le tableau blanc en 5 zones :
Continuez à Faire – quelque chose que l’équipe réussit bien et dont vous reconnaissez la valeur.
Moins de – quelque chose de déjà fait; vous y constatez une certaine valeur, mais vous souhaitez le réduire un peu.
Plus de – quelque chose de déjà fait; et dont vous pensez qu’elle apportera encore plus de valeur si davantage utilisée.
Arrêter de Faire – quelque chose qui n’apporte pas de valeur, ou encore pire, qui empêche de progresser.
Commencer à Faire – une nouvelle idée, ou quelque chose vous avez vu marcher auparavant et que vous voudriez mettre sur la table de discussion.
Tous les ans, la Scrum Alliance réalise une enquête sur l’utilisation et les évolutions de Scrum et en résume les résultats dans le State of Scrum report.
On y trouve les taux d’adoption en entreprise (5000 réponses de 108 pays et 14 industries), les tendances actuelles, les prochaines évolutions telles que perçues par les pratiquants de la méthode.
Certaines statistiques sont révélatrices:
87% estiment que Scrum améliore la qualité de vie au travail
56% utilisent les cérémonies de Scrum avec discipline
71% pensent que leur utilisation de Scrum crée des tensions avec d’autres parties de l’organisation qui ne l’utilisent pas
59% of des ScrumMasters certifiés et 81% pensent que cela les aide à améliorer leurs pratiques
93% des projets Scrum supervisés par un PMO réussissent
L’essayer c’est l’adopter puisque 95% vont continuer à utiliser Scrum
mises à jour du « Scrum Guide »
Amenez-moi des solutions pas des problèmes : leadership versus management
Le Crowe « The PMI-ACP Exam: How to Pass on Your First Try »
New PMI Talent Triangle ! Download
Que trouve-t-on dans un plan de management des ressources humaines d’un projet ou programme ?
connaissez-vous l’histoire de la toute petite grenouille ?
que se passe-t-il si votre nouveau projet nécessite vraiment « d’avoir fait polytechnique » ?
connaissez-vous la technique du Speed Boat pour les rétrospectives Scrum et sessions sur les leçons apprises?
Voici un exemple de rétrospective de Sprint d’une petite d’équipe. D’abord l’équipe écrit les notes: les billets bleus.
Puis l’équipe discute vraiment de chaque note et ajoute les mesures à prendre: les billets jaunes.
Simple et efficace ?
DantotsuPM.com 