articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Méthodes, retours d’expérience, bonnes pratiques
The Scrum Framework
Lyssa Adkins qui se présente comme une coach de Coach Agile (les ScrumMasters par exemple), montre dans cette vidéo comment expliquer Scrum à quiconque en reprenant dans un graphique les principes clés de cette approche. Lyssa est l’auteur du livre Coaching Agile Teams.
The Wedding Cake
Elle va plus loin avec cette démonstration de comment expliquer très simplement les différences et les bénéfices qu’il y a à adopter une approche Agile.
http://kenschwaber.wordpress.com/2011/05/03/empiricism-the-act-of-making-decisions-based-on-what-is/
Par Ken Schwaber
L’empirisme est l’acte de prendre des décisions basé sur ce qui est. Scrum est un processus empirique, parfois décrit comme “l’art du possible.” Par cela, je veux dire que nous faisons du mieux nous pouvons avec ce que nous avons.
Un Propriétaire de Produit (« Product Owner ») planifie une version (« release ») basée sur toutes les informations actuellement disponibles. Il ou elle définisse les objectifs, les fonctionnalités et les capacités qui délivreront ces buts ainsi que le coût probable et la date de livraison. À partir de ce moment-là, le travail du Propriétaire de Produit est d’évaluer ce qui est possible vu les capacités de l’Équipe et de prendre les meilleures décisions pour atteindre l’objectif souhaité. Étant donné la nature de la technologie, des marchés, des besoins et des personnes, des compromis sont faits. Parfois le but ne peut pas être atteint pour un prix raisonnable. Parfois le but sera atteint, mais d’une manière différente de ce que le Propriétaire de Produit pensait initialement. C’est l’empirisme en pleine action.
L’Équipe (de développeurs) sur l’Équipe Scrum fait de même. Elle rencontre le Propriétaire de Produit et évalue ce que le Propriétaire de Produit voit comme les choses les plus importantes à faire ensuite. Si réalisées, celles-ci dirigeront le produit émergent dans la meilleure direction vers le but désiré. L’équipe choisit autant de choses qu’elle croit pouvoir en faire pendant le prochain Sprint. Le coût de l’équipe et la longueur de Sprint est fixe. Seule la quantité d’items du « Product Backlog » choisie peut varier. Le Propriétaire de Produit et l’Équipe définissent souvent un objectif pour le Sprint. C’est un sous-ensemble des objectifs de la version (« release »).
Quand l’équipe choisit des items lors d’une réunion de Planification de Sprint, elle s’engage à le faire pendant le Sprint.
Une définition « s’engager » est : « Se lier moralement par une promesse : Il s’est engagé à payer ses dettes dans les huit jours. » selon le Larousse. (ndlt)
Cela correspond à ma compréhension du mot s’engager, qui est une promesse, un engagement à un plan d’action.
Cependant, beaucoup d’équipes Scrum utilisent le mot « s’engager » comme si c’était « une garantie ». C’est un reste des méthodes en cascade, où une évaluation était un contrat. Cependant, cela résonne toujours dans les têtes de propriétaires de produit et des développeurs. J’ai trouvé équipes après équipes qui estiment qu’elles doivent tout faire pour respecter leur engagement. La victime est habituellement la qualité.
Je me demande si nous devrions échanger le mot « s’engager » pour celui de “prédire” ?Ceci pourrait donner la même impression que la présentatrice météo essayant de nous fournir les meilleures informations possibles. Elle fait avec que l’on connaît et avec la science de la météorologie. Elle ne fournit pas de garantie, mais quelque chose que nous pouvons utiliser pour prendre des décisions. Les prévisions sont également utilisées par les organisations de ventes. Peut-être cette clarification nous aidera-t-elle à comprendre qu’ « un engagement » dans Scrum est une promesse de faire de notre mieux avec ce que nous avons.
Si Philip Diab (former PMI Chair Person) devait identifier un seul outil, méthode ou processus qu’il faut maîtriser parfaitement pour les chefs de projet, ce serait la structure de découpage du projet (WBS).
J’ai plusieurs fois abordé ce sujet critique de la construction du WBS en management de projet, notamment dans les billets: « conseils pratiques sur le WBS/practical tips on WBS »; « 20 erreurs courantes faites par les chefs de projet nouveaux ou inexpérimentés Par Harold Kerzner, Ph. D., PMP » et « Dix Choses à regarder lors d’une revue de planning (d’échéancier) de projet ».
Cornelius Fichtner nous fournit ici un éclairage personnel et insiste sur la règle des 100% qui est trop souvent oubliée.
un chef de projet devrait-il se soucier de Politique de Bureau ?La « politique politicienne » qui n’a pour intérêt que de servir quelques personnes qui en usent et en abusent est elle négative et c’est souvent dans ce sens que l’on se réfère à la « politique de bureau » qui ne sert que quelques individus dans l’entreprise à des fins personnelles.
La sensibilité aux cultures et à la communication inter cultures est un élément clé de réussite des chefs de projet qui travaillent à l’international. Je pense que cette petite vidéo amusante vous rappellera des souvenirs de situations similaires qui vous sont arrivées. Lesquelles ?
composer des équipes comme si les personnes importaientLes projets sont avant tout une affaire de personnes. Alors que cette affirmation semble tomber sous l’évidence, elle est souvent incroyablement oubliée. L’homo economicus a longtemps été discrédité et a prouvé être beaucoup moins rationnel que beaucoup de philosophes le voudraient. Les gens ne sont pas universellement interchangeables et on ne peut pas s’attendre à ce qu’ils se comportent dans les limites logiques et prévisibles de leur intérêt personnel étroit, mais nous continuons à faire comme si c’était le cas. Comment nous fonctionnons dans une équipe est critique. La raison même d’existence des équipes est que nous ne pouvons pas réussir tout seul; nous avons besoin d’un peu d’aide, nous avons besoin de l’expertise de spécialistes et nous avons besoin des gens pour soulever des montagnes. Cependant, mettez plusieurs personnes dans une même pièce et les défis de communication, de collaboration, de confusion et de conflit adviennent rapidement.
La spécialisation dans Scrum est un sujet chaud depuis de nombreuses années. Les questions sur la spécialisation arrivent quand j’explique aux gens que d’après la définition de Scrum, une équipe doit être cross-fonctionnelle. Je recommande aussi aux membres d’être à 100 % dédiés à une équipe (ne pas être membres de multiples équipes). La plupart des personnes qui sont nouvelles sur Scrum l’acceptent sans considérer les implications. Parfois quelqu’un demandera : « mais alors, que fera la personne des tests au début du Sprint ? »
La Vélocité est une mesure de productivité souvent utilisée dans le développement de logiciel, en particulier avec les méthodes Agile.
PMI a créé une nouvelle liste de questions/réponses sur les certificationsBonjour, je pense que vous trouverez cette page « Certifications FAQs » fort utile si vous vous posez des questions sur les certifications proposées par le Project Management Institute.
Le 4 janvier, ESI International, a révélé ses 10 Premières Tendances Mondiales de Management de projet pour 2011. Des thèmes clefs qui incluent construire l’influence du chef de projet, l’accélération d’un nouveau leadership et des compétences de communication et l’utilisation accrue d’approches d’étude informelles comme des médias sociaux et la formation résultant de l’expérience.
Selon cet article, des bonnes priorités aux salaires plus élevés, le management de projet et les PMOs reçoivent enfin plus qu’un intérêt de pure forme dans beaucoup de sociétés.
ordre du jour de la session de lancement du projetIl est à noter qu’il y a diverses réunions de lancement de projet. Celle à laquelle se réfère cet article est interne à l’équipe projet. Elle a pour objectif principal d’établir les normes, partager la même vision des livrables, comprendre les rôles et responsabilités de chacun, avec un clair focus sur le mode de communication que l’on souhaite utiliser entre membres de cette équipe.
J’ai bien aimé dans cet article les cinq compétences que McKinsey a identifié comme étant au cœur du leadership:
1. trouver et donner une signification dans le travail
2. convertir des émotions telles que le stress et la peur en opportunités
3. savoir tirer partie de ses connections et de sa communauté
4. agir face aux risques
5. soutenir l’énergie qui est la force vive du changement
La réflexion disant que toute personne maîtrisant au moins une de ses compétences double sa capacité à conduire le changement me semble un peu excessive et l’autosatisfaction de ceux qui posséderaient les 5 tout autant. Pourtant….
écrit par Neil Stolovitsky de Genius Inside
Agile fait beaucoup de bruit actuellement dans les milieux de développement de logiciels. La méthode a été créée par des développeurs pour des développeurs. Son origine remonte à 10 ans lorsqu’un groupe de développeurs ont mis en place l’Agile Manifesto dans une station de ski dans l’Utah. Ce manifeste visait à établir pour les projets de développement de logiciels un système plus inclusif, démocratique et efficace. Il en a résulté plusieurs méthodologies Agile dont notamment Crystal Clear, Scrum et Extreme Programming, toutes créées afin de mettre en place des équipes de projet autonomes qui placent la responsabilité dans les mains de chaque personne qui touche le projet.
Ceci est une toute nouvelle approche de gestion des équipes de projet. Les groupes de développement de logiciels doivent être très prudents lorsqu’ils déploient Agile dans leur organisation, car les équipes sont en général habituées à être surveillées et guidées tout au long du projet. En réalité, il y a de nombreux points à considérer avant d’implémenter Agile afin d’être sûr que les changements proposés par Agile soient positifs et non négatifs par rapport au processus existant. Voici les cinq points les plus importants pour vous aider à déterminer si la méthode Agile est la bonne pour vos développeurs:
Une culture trop différente est l’une des raisons principales à l’échec d’un environnement de travail de gestion de projet. Les environnements Agile sont autonomes, ils font face aux clients et sont démocratiques par nature. Tous les groupes de développement cherchant à adopter Agile doivent avant tout se demander si ces principes sont en accord avec la culture et les valeurs de la société ? S’ils sont en complète opposition, les chances de réussite sont minimes. La dernière chose à faire est de démarrer du mauvais pied!
La plupart des environnements de travail en management de projet réussissent simplement avec une bonne adhésion du leadership. Même si la culture de la société est adéquate, Agile nécessite une adhésion complète depuis la base dès le départ. Chaque personne a un rôle à jouer: des clients aux développeurs, étant donné que chaque personne a sa part de responsabilité avec Agile.
Est-ce que votre société est prête pour un changement? Étant donné qu’Agile requiert un changement d’envergure, il est primordial qu’une stratégie de gestion du changement soit en place afin de minimiser les risques et d’assurer une transition en douceur entre l’ancienne et la nouvelle manière de faire les choses.
La méthodologie Agile nécessite une compréhension complète de sa philosophie et de son environnement de travail dès le début. Cette méthodologie nécessite la participation de tous les membres de l’équipe, il est important que chacun connaisse l’ensemble du processus ainsi que sa propre contribution. Toute autre approche risque de faire échouer son implémentation.
La base de l’efficacité des projets Agile est l’effort concerté de mise en place d’un système qui permette une collaboration efficace entre les parties prenantes internes et externes. Vous devez vous non seulement vous demander s’il existe dans votre société une stratégie de communication efficace, mais surtout vous devez être sûr que vos clients seront prêts à s’investir lourdement dans le développement de leurs projets.
Pour en savoir plus au sujet de la méthodologie Agile, regardez ce bref (6′) et récent web cast (ci-dessous en anglais) et livre blanc (en anglais également).
http://www.allaboutagile.com/10-good-reasons-to-do-agile-development/
by Kelly Waters
Voici 10 bonnes raisons d’appliquer les principes et pratiques de développement agiles …
1. RevenusLa nature itérative du développement Agile implique que des fonctionnalités sont livrées de façon incrémentale, ce qui permet de commencer à encaisser des revenus pendant que le produit continue d’être développé.
La recherche suggère qu’environ 80 % de tous les leaders du marché ont été les premiers à commercialiser sur ce marché. En sus d’un revenu plus élevé grâce à une livraison progressive, la philosophie de développement Agile supporte aussi la notion de sorties en avant-première et de versions régulières et les versions « perpétuellement bêta ».
Un principe clé de développement Agile est que les tests sont intégrés tout au long du cycle de vie. Ce qui permet une inspection régulière d’un produit fonctionnel en cours de développement. Cela permet au propriétaire de produit (le « product owner ») de faire des ajustements si nécessaire et donne à l’équipe de produit la primeur de tout problème de qualité.
Les principes de développement Agile encouragent la participation active des utilisateurs tout au long du développement du produit dans une approche collaborative très coopérative. Cela fournit une excellente visibilité aux principales parties prenantes, à la fois sur l’avancement du projet et sur le produit lui-même, ce qui aide à son tour à s’assurer que les attentes sont gérées efficacement.
De petites versions progressives donnent de la visibilité au « product owner » et à l’équipe produit pendant le développement, permettent d’identifier les problèmes au plus tôt et facilitent la réponse à ceux-ci. La visibilité claire dans le développement Agile aide à s’assurer que les décisions nécessaires peuvent être prises le plus tôt possible, pendant qu’il reste du temps pour apporter une différence substantielle sur le résultat.
Dans des projets de développement traditionnels, nous écrivons de grandes spécifications au préalable et disons ensuite aux responsables business combien il est coûteux de changer quoi que ce soit, particulièrement quant le projet avance. Dans la crainte de dérive du contenu et de projet interminable, nous résistons aux changements et faisons passer les personnes par un comité de contrôle des changements pour les réduire au minimum vital. Les principes de développement Agile sont différents. Dans le développement Agile, le changement est accepté. En fait, on s’y attend. Parce qu’une chose certaine dans la vie est le changement. Au lieu de cela la durée est fixe et les exigences apparaissent et se développent comme le produit est développé. Bien sûr, pour que cela fonctionne, il est impératif d’avoir des parties prenantes impliquées qui comprennent ce concept et prennent les décisions de compromis nécessaires, négociant le contenu existant pour un nouveau.
La susdite approche de durées fixes et besoins en évolution permet d’avoir un budget fixe. Le contenu du produit et ses fonctionnalités sont variables, plutôt que le coût.
8. Satisfaction du client/business La participation active d’un représentant des utilisateurs et/ou un propriétaire de produit (« product owner »), la forte visibilité du produit et de l’avancement et la flexibilité de changer quand le changement est nécessaire, créent un bien meilleur engagement du business et la satisfaction du client. C’est un bénéfice important qui peut créer des relations de travail beaucoup plus positives et durables.
Par-dessus tous les autres points, la capacité des besoins de développement Agile à émerger et à évoluer et la capacité d’embrasser le changement (avec le compromis approprié), fait que l’équipe construit le bon produit. Il est trop commun dans des projets plus traditionnels de livrer un projet « réussi » coté informatique et de constater que le produit n’est pas ce à quoi on s’attendait, dont on avait besoin ou que l’on espérait. Dans le développement Agile, l’accent est mis absolument sur la construction du bon produit.
L’engagement actif, la coopération et la collaboration font des équipes de développement agiles un endroit beaucoup plus agréable pour la plupart des personnes. Au lieu de grandes spécifications, nous discutons des besoins dans des ateliers. Au lieu des longs rapports d’avancement, nous collaborons autour d’un tableau des tâches, discutant du progrès. Au lieu des longs plans de projet et des Comités de Gestion de Changement, nous discutons de ce qui est juste pour le produit et le projet et le L’équipe est autorisée à prendre des décisions. Dans mon expérience, cela donne une approche beaucoup plus utile pour chacun. À son tour, cela aide à créer des équipes fortement motivées, à haute performance qui sont fortement coopératives.
Mais il y a des implications. Il n’existe rien de tel qu’un déjeuner à l’œil ! Et il n’y a aucune baguette magique pour le développement logiciel. Désolé, non, cela n’existe pas 🙂 En échange de tous ces avantages, vous obtenez moins de prévisibilité, le logiciel et les personnes restent complexes, vous ne pouvez plus blâmer quelqu’un d’autre si les choses ne se passent pas bien et cela exige généralement beaucoup plus d’engagement et d’effort de chaque personne impliquée – c’est-à-dire que la collaboration est encore plus importante.
Néanmoins, les bénéfices du développement Agile sont vraiment irrésistibles.
Une brève explication des termes les plus fréquemment rencontrés dans le développement en mode Agile.
http://blogs.pmi.org/blog/voices_on_project_management/2011/04/prioritizing-agile-project-req.html
par Bill Krebs
Dans la gestion de projet Agile, nous devons prioriser une liste de demandes pour la planification de version, d’itération et l’insertion de nouveaux besoins ou exigences. Mais il y a plusieurs techniques pour le faire.
Une des méthodes les plus populaires pour déterminer la priorité des demandes est l’approche dite « MoSCoW ». Cela signifie ‘ Must (Doit), Should (Devrait), Could (Pourrait), Won’t (ne fera pas). ‘ Le seul problème avec cette méthode est que d’habitude tout est un Must, ce qui ne permet pas une planification appropriée parce que les besoins ne sont pas nécessairement placés dans leur ordre de priorité.
Une autre méthode est le modèle de Kano, développé par le Professeur Noriaki Kano, qui s’efforce de satisfaire les exigences et de faire plaisir aux clients. Ce modèle dispose de quatre composants :
• Must haves (doit avoir) sont des éléments sans lesquels on ne peut livrer le produit.
• Dissatisfiers (générateurs d’insatisfaction) sont des choses que le produit ne doit pas inclure.
• Satisfiers (générateurs de satisfaction) incluent besoins pour lesquels plus vous en avez mieux le produit sera perçu. Comme un catalogue commercial dans lequel chaque fonctionnalité ajoute progressivement de la valeur.
• Delighters (générateurs de plaisir) amènent le produit plus loin que simplement répondre aux exigences vers l’augmentation de la satisfaction client et la recommandation par le client.
Plusieurs modèles de priorisation réunissent deux variables dans un tableau pondéré : fonctionnalités et clients. Chaque fonctionnalité est pondérée par sa valeur pour chaque client. La somme des poids multipliés par le score permet de voir quelles fonctionnalités sont en général les plus utiles pour un jeu de clients exigeants.
Quel que soit la technique utilisée, votre liste d’exigences de projet doit être triée de la plus grande à la plus faible valeur.
Quelles techniques utilisez-vous pour prioriser les besoins ?
1. PMI has selected PMI-Agile Certified Practitioner (PMI-ACP)SM as the name for the certification.
2. The PMI-ACP certification application is now open and available online at PMI.org.
To stay up-to-date on the PMI Agile Certification, please go to the Agile certification home page. If you have questions that cannot be answered by this information, please contact PMI Customer Care at customercare@pmi.org.
Voici une vidéo qui donne à réfléchir pour tous ceux qui sont actuellement chefs de projet dans le développement logiciel et qui commencent à adopter les méthodes et approches Agiles sur certains de leurs projets.
Lyssa Adkins nous confie quelques pensées radicalement opposées à ce que les chef de projet dans le modèle « en V » ou « en cascade » ont pu apprendre :
Se détacher du résultat, du livrable, pour se focaliser sur comment l’équipe travaille ensembleAu bout du compte, Lyssa mentionne que le coach Agile doit avoir 4 fonctions principales:
Agility and PMIPosted in Scrum par Ken Schwaber
Le Project Management Institute a récemment annoncé son programme d’incorporer l’agilité dans son programme de management de projet. J’accueille ceci bien sûr avec plaisir et attends avec impatience que PMI change de son approche précédente à une approche agile. Le test en sera, bien sûr, le succès des projets qui adhèrent à ses principes. Dans le passé, le succès de leur approche prédictive a été moins de 50 % de projets (à l’heure, sur la date, avec la fonctionnalité souhaitée). La plupart des méthodes agiles ont un taux de réussite beaucoup plus élevé, y compris le succès à arrêter très tôt des projets à faible retour sur investissement. Nous observerons et verrons si ceux qui emploient l’approche agile du PMI bénéficient de tels succès, ou au moins d’une amélioration du seuil des 50% 1,2,3.
Dans le passé, PMI a embrassé l’approche prédictive, mécanique du management de projet. Cela a été d’abord soutenu par Frederick Taylor dans “Principles of Scientific Management”, qui était la base de la chaîne de montage des Ford Model T. C’est une approche pour une fabrication prévisible, en grand volume et bon marché. Ses bénéfices s’obtiennent en éliminant toute imprévisibilité de l’espace des problèmes à travers la standardisation et la répétition. La planification parfaite, la formation et la répétabilité sont les recettes. Planifiez et répétez ensuite à maintes reprises. La mesure de succès est le taux de rendement, qui est souvent très proche de 100 %. La productivité est optimisée par des processus parfaits, un « workflow » invariable et l’utilisation optimisée des ressources (les personnes ou les machines).
Des processus agiles, travaillent en revanche au développement de produits complexes, où il y a une certaine répétabilité, mais il y a davantage de développement nouveau que d’ancien. Les produits doivent être inventés à nouveau à chaque fois avec les changements des besoins, les techniques et les capacités et la créativité des personnes. Dans ces situations, nous avons constaté que la planification à flux tendu, avec inspection fréquente et adaptation est exigée. Les risques sont managés et la prévisibilité créée en limitant la période de temps entre les événements de planification et en assurant la transparence de tous les artefacts. Nous avons aussi trouvé que la productivité, la qualité et la créativité sont énormément accrues si les personnes réalisant le travail planifient aussi leur propre travail. Elles ne sont pas gérées comme des ressources, mais comme des personnes qui peuvent faire de leur mieux quand elles comprennent comment faire le travail par elles-mêmes. L’auto-organisation et la transversalité fonctionnelle sont essentielles au succès de ces équipes.
Nous avons constaté que le rôle du chef de projet est contre-productif dans un travail complexe et créatif. La ligne de pensée du chef de projet, comme représenté par le plan de projet, contraint la créativité et l’intelligence de tous sur le projet à celle du plan, plutôt que d’engager l’intelligence de chacun au mieux afin de résoudre les problèmes.
Dans Scrum, nous avons supprimé le chef de projet. Le Propriétaire de Produit, ou le client, fournissent la planification à flux tendu en disant à l’équipe de développement ce qui est nécessaire, aussi fréquemment que chaque mois. L’équipe de développement se gère, fournissant autant de ce que veut le propriétaire de produit en produit utilisable que possible. Le résultat est la haute productivité, la créativité et l’engagement des clients.
Nous avons remplacé le chef de projet par le Scrum Master, qui gère le processus et aide le projet et l’organisation à passer aux pratiques agiles.
Comment PMI va combler la différence profonde dans la philosophie, la pensée, le leadership et le management entre son approche prédictive traditionnelle et la nouvelle approche empirique agile sera fascinant à observer. Comment PMI remodèlera le rôle de chef de projet sera un exercice d’agilité en lui-même. Personnellement, je souhaite le meilleur aux gens de PMI. Ils ont certainement besoin d’un meilleur taux de réussites que 50% pour regagner la confiance de leurs clients.
1. Tiré de “The Rise and Fall of the Chaos Report Figures”, janvier/février 2010 IEEE Software, J. Laurenz Eveleens et Chris Verhoef, Vrije Universiteit Amsterdam.
2. 2009/2010 Standish Chaos Report, Standish Group, indique :
3. En plus d’un taux de rendement bas (le taux de livraisons réussies), les statistiques indiquent aussi que plus de 60 % des fonctionnalités livrées ne seront que rarement ou jamais utilisées, une perte énorme de budget de support et de développement. Résultat de la non priorisation des besoins. http://en.wikipedia.org/wiki/Software_bloat, “Embonpoint Logiciel”.
PMI a publié le document que vous obtiendrez en cliquant sur l’image ci-contre pour nous fournir davantage de détails sur la Certification Agile. Les inscriptions débutent en mai pour les premières sessions d’examen en Septembre.
Vous y découvrirez notamment que l’examen consistera en 100 questions dont la moitié sur les outils et techniques Agiles et la seconde partie sur les compétences et connaissances Agile.
Coté outils et techniques, les aspects suivants seront couverts: Communications, Estimations, Planification, Suivi et Amélioration continue, Analyse et Design, Qualité et Tests, Compétences relationnelles, Priorisation, Management des risques, mesures et indicateurs, anamyse de la valeur.
Les compétences et connaissances sont organisés en domaines qui sont eux mêmes triés par niveau d’importance sur les projets agiles.
PMI nous propose également quelques pointeurs vers des documents et publications utiles pour préparer cet examen.
Une page dédiée sur le site PMI contient de nombreuses réponses aux questions que vous vous posez peut-être sur Agile.
La définition des « bonnes » estimations sur un projet est un savant mélange d’expérience, d’échanges entre experts, de comparaison par analogies, de calculs… Le Planning Poker est l’un des outils de la méthode Scrum qui permet à une équipe lors d’une réunion de planification de donner des estimations pour le développement d’une fonctionnalité.
Lors de la réunion, le product owner (directeur de produit), qui représente comme toujours le client, définit les priorités de développement des nouvelles fonctionnalités du produit logiciel. L’équipe projet doit donner des estimations d’efforts au product owner afin que celui-ci comprenne ce que va coûter chaque nouvelle fonctionnalité. Et c’est là qu’intervient le Planning Poker. Pour jouer au planning poker, l’équipe doit donc avoir la liste de fonctionnalités à livrer (le product backlog) et un jeu de cartes de planning poker.
Dans ce jeu de carte, au lieu de porter des valeurs entre le 2 et l’as, les cartes portent des valeurs qui sont plus pertinentes à l’évaluation de durée de tâches. Typiquement ces valeurs sont : 0, ½, 1, 2, 3, 5, 10, 20, 50, 100. Ces valeurs correspondent au nombre de jours qu’une fonctionnalité donnée prendrait à être développée.
La session de planning poker est habituellement facilitée par un modérateur qui est souvent le ScrumMaster ou bien le coach Agile de l’équipe, les participants sont donc le « product owner » et l’équipe de développement.
1. Le modérateur lit la description de l’histoire utilisateur (« user story ») ou fonctionnalité que l’équipe doit estimer. Le product owner peut fournir des clarifications sur la fonctionnalité. Chaque expert est doté d’un jeu de cartes.
2. Chaque expert choisit une carte dans son jeu qui correspond à son estimation initiale de l’effort de développement. Chaque expert pose sa carte à l’envers sur la table pour ne pas influencer les autres experts.
3. Quand toutes les évaluations sont sur la table, les cartes sont retournées.
4. S’il y a une palette très large entre les estimations, les experts qui ont suggéré les plus fortes et plus basses évaluations fournissent le raisonnement qui les a amené à ces valeurs.
5. Une fois que la discussion sur la palette d’estimations a été conduite, les étapes 2 à 4 sont répétées jusqu’à ce qu’un consensus soit atteint.
L’avantage principal du planning poker est d’encourager une discussion ouverte sur les estimations. Cela aide l’équipe à atteindre une proposition plus précise au lieu de compter sur l’avis d’un membre de l’équipe plus influent ou plus vocal que les autres. Cela permet aussi à l’équipe de bénéficier de l’expérience de tous les membres de l’équipe.
Les cartes de planning poker peuvent être créées à partir de zéro. Ce lien vous permettra d’imprimer vos propres cartes de planning poker: http://www.sprintplanning.com/planningpoker_cards_1.gif et celui-ci de jouer en ligne: Http://www.planningpoker.com/
Voici une brève vidéo qui explique comment est née cette méthode.
Check out the document entitled « Metrics for Agile Projects: Finding the Right Tools for the Job » on the ESI Website.It holds an interesting high level comparison of the metrics and tools available for PMs to track progress and communicate on it: Gantt charts, WBS, Burn Down Charts… It also gives a few hints on how to interpret these as they are quite different from the metrics of waterfall approaches.
Apprenez comment la Certification Agile PMI peut vous y aider.
Agile est un sujet d’importance croissante dans le management de projet. Le marché dénote cette tendance comme les pratiquants en management de projet embrassent Agile comme une technique pour gérer avec succès des projets.
À cause de ces changements dans l’environnement de management de projet, PMI développe une certification Agile.
Les leaders qui utilisent des techniques Agiles dans le management de projet ont conseillé PMI sur la meilleure façon de proposer une certification Agile pour servir des membres de projet et les organisations pour lesquelles ils travaillent.
PMI questionne régulièrement les chefs de projet pour mieux comprendre comment ils pratiquent le management de projet. Une statistique majeure qui est sortie de notre dernière enquête professionnelle est des pratiques standardisées de gestion de projet aboutissent à de meilleures performances de projet. Une des pratiques que PMI a surveillées depuis plusieurs dernières années est la croissance ininterrompue et de l’utilisation des pratiques Agiles dans le management de projet. Beaucoup de PMs ont ajouté Agile à leur « boîte à outils de management de projet » et l’utilisent comme une parmi de nombreuses de techniques de management de projets.
De plus, les organisations qui utilisent le management de projet pour servir leurs clients tant internes qu’externes voient de la valeur dans des méthodes Agiles pour livrer des projets à leurs clients plus rapidement. En conséquence, plus d’organisations et de bureaux de projet (PMOs) demandent à leurs chefs de projet d’appliquer des techniques Agiles. La recherche PMI a révélé que 68 % des organisations utilisant des pratiques Agiles verraient de la valeur dans une certification Agile pour des managers de projet. De plus, 63 % des recruteurs encourageraient leurs chefs de projet à passer une certification Agile.
Les chefs de projet qui utilisent des pratiques Agiles dans leurs projets, ou dont les organisations adoptent Les approches Agile dans le management de projet sont de bons candidats à la Certification Agile PMI.
Lisez les conditions d’admissibilité
PMI sert la profession de management de projet en fournissant les chefs de projet avec une sélection d’outils de techniques — et Agile est l’un de ceux-ci. Par exemple, ceux qui ont la certification PMP® et travaillent dans une organisation qui utilise des techniques Agiles, trouveront dans la Certification Agile une base de connaissances applicable des principes et des concepts Agiles.
Le pilote de Certification Agile PMI est ouvert au public et à tout pratiquant du management de projet qui réunit les pré-requis d’admissibilité. PMI cherche actuellement des candidats pour ce pilote et ils pourront s’inscrire en ligne ou sur papier pour la certification à partir de mai 2011. L’examen de Certification Agile PMI débutera pendant le troisième trimestre de 2011. Pour en savoir davantage sur ce pilote, lisez le Document de FAQS (FOIRE AUX QUESTIONS) sur la Certification Agile.
Pour recevoir des nouvelles de ce Pilote de Certification Agile PMI, envoyez un message en anglais à AgilePilot@PMI.org
Technical DebtLa dette technique et la dette de design sont des métaphores synonymes se référant aux conséquences finales d’une pauvre architecture logicielle et d’un développement logiciel à la va vite. La dette de code se réfère à la dette technique dans un code de programmation de logiciel.
Ward Cunningham a fait la comparaison entre la complexité technique et la dette dans un rapport de retour d’expérience 1992 :
La livraison du premier code ressemble au fait de s’endetter. Une petite dette accélère le développement tant est qu’elle soit remboursée promptement par une réécriture … Le danger se présente lorsque la dette n’est pas remboursée. Chaque minute passée sur du code pas tout à fait exact s’ajoute alors aux intérêts de cette dette. Des organisations entières d’ingénierie informatique peuvent parvenir à un blocage total sous le poids des dettes d’un développement non consolidé qu’il soit orienté objet ou pas.
Les développements réalisés en amont dans le projet peuvent augmenter le coût “du remboursement de la dette” à l’avenir. Une équipe devrait saisir les occasions, sur une base régulière de rembourser (ou régler) cette dette. Réservez un pourcentage de votre cycle de développement ou dédiez un cycle entier pour compléter ce travail. Si vous ne le faites pas, il reviendra vous hanter. Si votre bidouille de solution ne revient pas pour mordre l’équipe de développement, elle hantera probablement le « help desk », l’équipe de support, ou quelqu’un d’autre en aval.
Comme toute dette, vous vous trouvez devant l’obligation de la rembourser tôt ou tard. En tant qu’ancien Manager de Génie logiciel et maintenant que conseiller auprès de mes clients, j’ai vu (et vois) ce que la dette technique peut avoir comme impact sur la vélocité d’une équipe. Elle les prive de temps précieux, après coup. L’équipe de développement achète l’idée que faire les choses de la mauvaise manière, fait gagner du temps dans l’intérim et que cela justifie les risques et le coût total. C’est vraiment un processus de pensée à court terme. La dette technique ressemble à l’obtention d’un prêt d’usurier qui jetterait les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas absolument obligés de prendre le risque, ne le faites pas.
Soyez honnête avec votre client, votre équipe et vous-même. Évaluez votre travail et tenez vos estimations. Ne laissez pas quelqu’un d’autre vous dire combien de temps il faudra pour livrer un travail de qualité. Si vous y êtes forcés, vous devrez juste délivrer moins de travail. Donc, ne prenez pas de dette en premier lieu.
Plus sur la dette technique sur Wikipedia
Convaincre votre directeur financier (Chief Financial Officer: CFO) et autres cadres sup de votre société d’utiliser Scrum est en réalité très simple, dans la théorie. Essayez cette stratégie la prochaine fois vous devez aider des exécutifs à comprendre pourquoi Scrum est un processus important et utile pour le développement logiciel.
Selon mon expérience, les experts financiers et les directions sont très attentifs à savoir ce qui arrivera si de certaines situations se produisent et veulent souvent simuler des scénarios dans leur stratégie de management des risques.
La meilleure approche dans cette situation est d’exposer la valeur business que vous livrerez si le projet devait s’arrêter en cours d’exécution.
Il y a plusieurs raisons pour lesquelles des projets de développement de logiciel sont arrêtés avant leur date de fin :
En justifiant au management pourquoi utiliser utiliser Scrum il y a quelques années, nous avons posé cette question à la direction : Et si le projet devait être arrêté à environ 60 % de son effort ou calendrier ?
Pour cette démonstration, nous avons comparé deux projets. Le projet W, est exécuté dans une approche traditionnelle en cascade (Waterfall). Le projet S, utilise une approche agile.
Le projet W a un modèle de réalisation et une dépense typique par phase :
Comme vous pouvez voir, si on ordonne à l’équipe d’arrêter le développement à 60 % du parcours dans ce processus nous serons en réalité en plein milieu de l’écriture de code et de l’exécution de quelques tests système. Dans ce scénario, « la valeur » que le projet W délivre à la société est en fait un tas de documents d’analyse et un morceau de logiciel non testé.
Maintenant jetons un coup d’œil au modèle de dépense du Projet S, fonctionnant en mode Scrum:
Si le Projet S doit s’arrêter à 60 % en temps ou en effort dépensé, l’équipe aura déjà complété une bonne quantité de sprints et délivré un certain logiciel utilisable. Dans ce scénario, le projet S délivre une valeur réelle et des fonctionnalités utilisables (probablement environ 40 % à 50 % du produit total) au client.
Dans l’entretien avec la direction, nous avons utilisé un graphique sur la valeur acquise pour mieux illustrer notre point. Il inclut les suppositions suivantes :
Notre directeur financier et les autres cadres supérieurs ont décidé de commencer à utiliser Scrum pour nos développements de nouveaux produits parce qu’ils croient fermement que, d’une perspective de management des risques de la société, il vaut mieux utiliser Scrum qu’un développement par phase.
Par Bas Vodde
La spécialisation est un sujet chaud dans Scrum depuis de nombreuses années. Cette discussion surgit à chaque cours Scrum que je donne. C’est un sujet important et approprié pour une nouvelle équipe dans son premier Sprint.
La spécialisation arrive quand j’explique aux gens que d’après la définition de Scrum, une équipe doit être cross-fonctionnelle. Je recommande aussi aux membres d’être à 100 % dédiés à une équipe (ils ne sont pas membres de multiples équipes). La plupart des personnes qui sont nouvelles sur Scrum l’acceptent sans considérer les implications. Parfois quelqu’un demandera : « mais que fera la personne des tests au début du Sprint ? »
Il y a un couple de suppositions derrière cette question. La première supposition : le test peut seulement commencer après que le développement soit fait. Cette supposition courante n’est pas vraie. En adoptant des pratiques modernes comme l’ Acceptance Test-Driven Development, les tests commencent avant que le développement n’ait commencé. La deuxième supposition est qu’un spécialiste des tests peut seulement faire des tests. J’ai personnellement constaté qu’une plus grandes compétences des personnes est qu’elles peuvent apprendre de nouvelles choses! Aussi, je ne tiens pas non plus cette supposition pour être vraie.
La question peut être généralisée : « Que fait une personne avec la spécialisation bleue quand il n’y a aucun travail bleu ». « Bleu » pourrait être tester, développer l’interface utilisateur, coder en Java, en C, réaliser changements sur la base de données, écrire la documentation ou autres choses de la sorte. Cela arrive presque toujours dans une équipe utilisant Scrum. Pourquoi ? Regardons le scénario dans l’image ci-dessous.
Dans cette équipe, les membres de l’équipe sont spécialisés – rouge, vert, bleu, violet et noir. Tous les membres sont dédiés à cette équipe et ont une responsabilité partagée de réaliser tout le travail du Sprint Backlog. Le Product Owner choisit le travail sur la base de sa valeur pour le client. Si la priorité numéro 1 pour choisir le travail est la valeur pour le client, quelle chance y-a-t-il que le travail s’équilibre parfaitement sur les compétences dans l’équipe ? Dans la plupart des équipes avec lesquelles j’ai travaillé, la probabilité est proche de 0 %. Donc, dans la plupart des équipes (particulièrement dans les plus grandes organisations), il y a une disparité entre le travail à réaliser et les compétences de l’équipe.
C’est cette disparité qui amène les gens à dire : « Scrum nécessite des généralistes! »
Cette conclusion est incorrecte. Une disparité entre compétences et pré-requis ne signifie pas que chacun dans l’équipe doit pouvoir tout faire. C’est une erreur de raisonnement typique que de penser que le monde est binaire avec seulement deux possibilités : spécialiste ou généraliste.
La vérité est que « le spécialiste dans exactement un seul sujet » et le « généraliste » sont les extrêmes sur l’échelle de spécialisation. Il y a beaucoup de personnes entre ces deux extrêmes ! Par exemple, je peux être principalement un spécialiste bleu, mais je peux aussi savoir faire du violet et du noir. Je pourrais ne pas être aussi efficace que le super spécialiste violet, mais je me débrouillerai.
Quand une équipe prend vraiment la responsabilité partagée pour tout le travail d’un sprint cela crée le besoin d’équilibrer la spécialisation. Les personnes dans l’équipe doivent apprendre un peu de la spécialité de chacune des autres. Cela ne signifie pas que tous les membres de l’équipe doivent être des généralistes, mais plutôt que les membres s’éloignent de l’autre extrême – être spécialisé dans un unique domaine. Les membres de l’équipe apprennent de multiples spécialités, mais probablement jamais toutes.
Regardons celles-ci une par une :
Maximisez la spécialisation quand c’est possible
Si une équipe consiste en deux spécialistes bleus et deux spécialistes rouges et que le travail bleu est choisi, le spécialiste bleu fera probablement le travail. La plupart des équipes se rendent compte qu’il y a de la valeur dans la spécialisation, donc, quand nous pouvons utiliser la connaissance spécialisée des personnes, nous le faisons. De plus, les membres de l’équipe deviennent activement spécialistes sur des secteurs particuliers parce que cela augmente la productivité de l’équipe.
Opportunités de spécialisations multiples
« J’ai été un spécialiste bleu pendant beaucoup d’années. Au Sprint suivant un peu de travail bleu et un peu de rouge sont choisis. Les membres de l’équipe peuvent prendre le travail bleu pour que je puisse apprendre une nouvelle spécialisation rouge. » Beaucoup de personnes veulent activement apprendre de nouveaux secteurs. Cela garde le travail intéressant et leur connaissance fraîche. Dans une équipe qui équilibre la spécialisation l’opportunité d’étendre ma spécialisation devrait exister.
Opportunités de se concentrer sur une spécialisation
« Je me suis plongé dans rouge pour les derniers Sprints. J’avais toujours voulu être un spécialiste rouge. Donc, sur les Sprints suivants, si il y a du travail rouge, je voudrais le faire. » Les personnes à l’intérieur d’une équipe ne devraient pas être forcées d’apprendre une nouvelle spécialisation. Tant que leur connaissance crée la valeur pour le client, elles peuvent continuer à se concentrer sur leur spécialisation. L’équipe devra manager la situation quand il n’y a absolument aucun travail dans un secteur de spécialiste – d’habitude en cassant la spécialisation.
Apprentissage automatique
Si l’équipe consiste principalement en des spécialistes bleus et que les Sprints suivants ont principalement des besoins violets, l’équipe doit casser leurs spécialisations et apprendre le violet. Si le Sprint suivant est constitué principalement de besoins verts, ils devront casser de nouveau la spécialisation et apprendre le vert. Plus les secteurs de compétences dans les besoins changent plus l’équipe devient généraliste. Si le secteur de compétences dans les besoins ne change pas beaucoup alors l’équipe devient plus spécialisée.
Impact sur l’organisation
L’équilibre dans la spécialisation s’est produit dans chaque équipe Scrum avec laquelle j’ai travaillé. Cela cause souvent des conflits dans les premiers Sprints où les nouveaux membres de l’équipe crient « j’ai été bleu pendant des années ! Je ne ferai pas du violet ! » L’équipe devra résoudre ce conflit en apprenant comment travailler en équipe. Un bon ScrumMaster facilite la résolution de ces conflits dans l’équipe.
Les structures et les règles dans beaucoup d’organisations rendent le bon équilibre de la spécialisation plus difficile à trouver. Par exemple, si je suis le spécialiste bleu et sur un plan de carrière bleu et que j’ai un directeur fonctionnel bleu », alors voudrais-je apprendre le violet ? Probablement pas car ce serait nuisible à mon statut et ma carrière. De même, si j’ai pour objectif de performance de devenir encore plus bleu, alors sortir de ce secteur de spécialisation ne se produira pas.
Un autre obstacle commun consiste en ce quand l’organisation « se débrouille autour du goulot d’étranglement de spécialisation » en allouant à temps partiel les gens à de multiples équipes. Cela empire même la situation car il n’y aura aucune motivation du tout à casser les goulots d’étranglement de spécialisation dans ces organisations.
Les ScrumMasters doivent identifier ces dynamiques organisationnelles et essayer de les supprimer. C’est un travail difficile car il exige de changer l’organisation. Quand les obstacles organisationnels tombent, trouver le bon équilibre dans la spécialisation arrivera ‘automatiquement’ dans les équipes.
Une intéressante observation finale consiste en ce que cette même dynamique d’équipe s’applique au niveau organisationnel : les compétences nécessaires correspondent toujours mal aux compétences requises. Cela signifie que les organisations qui optimisent la spécialisation de leurs ressources humaines ne délivreront jamais par rapport à la valeur pour le client.
La Vélocité est une mesure de productivité souvent utilisée dans le développement de logiciel avec les méthodes Agile.
La terminologie suivante est utilisée dans le calcul et le suivi de la vélocité.
L’unité choisie par l’équipe pour mesurer la vélocité. Cela peut-être une unité réelle comme des heures ou des jours ou une unité abstraite comme des points de « user stories ». Chaque tâche dans le processus de développement logiciel devrait alors être estimée en termes de l’unité choisie.
L’intervalle est la durée de chaque itération dans le processus de développement logiciel pour lequel la vélocité est mesurée. La longueur d’un intervalle est déterminée par l’équipe. Le plus souvent, l’intervalle est une semaine, mais il peut aller jusqu’à un mois.
L’idée principale derrière la vélocité est de fournir une méthode simple et légère (agile) de mesurer l’allure à laquelle une équipe travaille et faciliter l’évaluation du temps nécessaire à produire des fonctionnalités supplémentaires dans un logiciel.
Pour calculer la vélocité, une équipe doit d’abord déterminer combien d’unités de travail valent chacune des tâches et la longueur de l’intervalle. La vélocité est donc mesurée en comptant le nombre d’unités de travail complétées dans un certain laps de temps, déterminé au démarrage du projet. Le suivi de la vélocité est le fait de mesurer de la vélocité réelle par rapport à la vélocité annoncée. Ce suivi de la vélocité fournit des informations qui permettent d’évaluer la performance d’une équipe dans le temps.
Pendant le développement, l’équipe doit faire un suivi des tâches complétées et, à la fin de l’intervalle, compter le nombre d’unités de travail complétées pendant l’intervalle. L’équipe note alors la vélocité calculée dans un diagramme ou sur un graphique.
La première semaine fournit peu de valeur, mais est essentielle pour établir une base de comparaison. Chaque semaine suivante, le suivi de la vélocité fournira de meilleures informations car l’équipe fournit de meilleures évaluations et devient plus familière de la méthodologie.
APM Group, qui propose déjà les certifications Prince 2 élargit son offre avec deux nouvelles certifications: Management de projet Agile et Earned Vamue Management (EVM).
Deux niveaux de qualification Agile Project Management sont prévues: « Foundation » et « Practitioner ». Seule la certification « Foundation » est pour l’heure disponible.
La certification EVM, est elle aussi pour le moment seulement disponible en version « Foundation » avec un test à choix multiples de 40 questions sur une heure couvrant votre compréhension de la terminologie et connaissance théoriques des méthodes de Management par la Valeur Acquise.
Si vous décidez de passer ces certifications, merci de nous donner vos retours d’expérience.
Le business moderne repose sur le multitâche pour réaliser le travail. Les salariés sont évalués sur leur capacité à travailler en parallèle sur de multiples tâches. Les professionnels de l’informatique sont habituellement assignés à de multiples projets. Avons-nous toujours fait cela ? Le multitâche marche-t-il ? Quels sont les impacts réels du multitâche ? Il y a une alternative ?
Monotâche serait le nom pour représenter comment nous avons eu l’habitude de travailler sur le logiciel avant le multitâche. Par multitâche, je veux vraiment dire « le travail en parallèle sur de multiples projets ». Le business moderne en est venu à appeler cela « multitâche » et à le considérer comme une stratégie pour une production plus efficace des employés. Nous faisons aussi du multitâche à une petite échelle dans nos vies quotidiennes, au travail et en dehors. Il y a des ressemblances à la fois sur comment nous le faisons et sur ce qu’il nous fait.
Quand nous présentons l’approche Agile (ou Scrum) à de nouvelles personnes, une des plus grandes pierres d’achoppement est l’idée que les équipes travaillent beaucoup beaucoup mieux quand leurs membres sont dédiés à l’équipe à plein temps. Ce n’est pas nouveau. Pendant des années nous avons assemblé « des équipes tigre (tiger team) » et « équipes de choc (swat teams) » pour traiter des problèmes spéciaux, souvent en temps de crise. Cependant, nos organisations en sont venues à préférer un modèle basé sur des individus organisés par silos de compétence assignés à de multiples projets en même temps. C’est devenu la solution de facto pour avoir un grand nombre de choses réalisées en même temps. On le considère comme étant l’utilisation la plus efficace « des ressources rares », c’est-à-dire pas suffisamment de personnes et toutes spécialisées.
Le modèle Agile retourne ce modèle sur sa tête. Formons des équipes de personnes concentrées sur un petit ensemble de choses à la fois. Au lieu de créer le travail et de faire passer les personnes au travers, nous créons les équipes de personnes et faisons passer le travail vers elles. Et nous tirons au lieu de pousser.
Le changement est difficile. Faire les choses de manière différente demande un objectif clair, une vision des bénéfices et du courage. Donc la résistance est naturelle; les personnes ne se sentent pas en sécurité quand les choses commencent à changer autour d’elles. Si nous pouvons faire un changement vers le mode « LEAN », nous pouvons démultiplier deux principes centraux « du respect pour les personnes » et « améliorer continuellement le système » pour définir un objectif, prévoir les bénéfices et entamer les premières étapes vers l’amélioration. Beaucoup de personnes entendent « LEAN » et pensent comment mieux faire ce que nous faisons déjà. « LEAN » dit aussi que nous pouvons souvent éliminer encore plus de gaspillage si nous arrêtons complètement de faire certaines choses, des activités de faible valeur.
Une personne qui travaille sur plus d’un projet encourt un coût à chaque passage d’un projet à l’autre. Le coût primaire est le temps requis pour changer de contexte. Nous savons que des interruptions simples comme un appel téléphonique peuvent coûter au moins 15 minutes de temps de récupération. Plus la tâche est complexe, plus il faut de temps pour effectuer le changement.
Si vous travaillez sur plus de deux projets à la fois le coût peut être encore plus élevé. Il peut s’être écoulé beaucoup de temps depuis que vous avez travaillé pour la dernière fois sur ce projet, demandant plus d’efforts pour vous souvenir d’où vous vous êtes arrêtés. Alternativement, si vous changez fréquemment, votre temps de commutation de contexte demandera une plus grande proportion de votre temps de travail.
Il y a des études qui montrent que les personnes sont assez douées pour des changements entre deux contextes sur de petites tâches. Sur une période de temps réduite, cela semble avoir un rapport avec nos deux hémisphères cérébraux. Jusqu’à un certain degré, nous pouvons travailler en parallèle sur deux tâches indépendantes. Pour de plus grands changements, nous devrions nous attendre à un certain coût de commutation. Jerry Weinberg a montré que le contexte s’intensifiant, si chaque tâche a une pénalité de 10 %, en réalité les coûts cumulés sont fréquemment plus hauts.
Quand une personne fait partie d’une équipe, traditionnelle ou Agile, il y a un coût additionnel de commutation. Quand un membre de l’équipe part pour faire une tâche non liée au travail de l’équipe, l’équipe souffre de l’absence du membre. Quand le membre absent revient, l’équipe passe du temps à l’aider à rattraper les événements qui se sont produits pendant son absence.
Mais, vous pouvez dire: « attendez un peu ». Une équipe Agile est transversale et occupée à faire toutes sortes d’activités chaque jour. Celles-ci incluent l’élaboration de besoins, l’analyse, le design, les tests et la programmation. N’est-ce pas du multitâche ? La réponse dépend de la portée de contexte. De vastes sauts de sujet et de technologie exigent plus de temps de commutation. Le cerveau est excellent avec les faibles changements d’activités. Sur une équipe resserrée, toutes les activités quotidiennes sont centrées sur une bande réduite de fonctions et technologies. Seulement quelques « storyboard » sont travaillés en même temps. Le contexte est étroit bien que l’éventail d’activités soit varié. De plus, Agile a un certain nombre de dispositifs pour garder le focus – la collaboration, les tableaux de tâche, le test automatisé, l’examen rétrospectif. Ce sont les larges sauts de contexte qui créent problèmes – d’autres projets, d’autres collaborateurs, d’autres parties prenantes.
Le cerveau humain est fort en multitâche interne. Il le fait tout le temps. Il le fait même la nuit. Il y a beaucoup de parties du cerveau qui fonctionnent ensemble et seules tout le temps. Sinon, nous ne pourrions pas fonctionner dans nos environnements complexes. La plupart du multitâche est subconscient – le filtrage d’apport sensoriel, l’intégration d’informations connectées, déplacer des données de la mémoire à court terme vers celle à long terme, maintenir le cœur et les poumons en marche.
Et nous faisons du multitâche extérieurement – conduire de la voiture tandis que nous naviguons et écoutons les informations de circulation, parler au téléphone pendant que nous dînons, planifier des vacances en sarclant le jardin. Quelques tâches comme plier le linge, marcher, etc. sont mécaniques et n’encourent pas de coût de commutation de tâche. D’autres comme de naviguer à travers un document en frappant des touches ou renommer une méthode peut être faites mécaniquement après quelque temps. Mais le travail de développement logiciel n’est pas si simple. Beaucoup de ce travail en multitâche automatique marche bien. Cependant, il a vraiment des limites.
La commutation de contexte de missions multi-projet modernes crée une nécessité potentielle de re-travail mental. L’intelligence humaine a deux sortes de mémoire séparées – à court terme (la mémoire de travail) et le long terme. Il y a des mécanismes pour déplacer des informations entre les deux. Il n’y a aucune garantie que tout est déplacé ou que les informations entrant sont les mêmes qui en reviendront plus tard. Nous éditons constamment nos mémoires, à chaque fois nous les rejouons. De nouvelles informations doivent résider dans la mémoire à court terme pendant un certain temps avant d’être déplacées dans la mémoire à long terme. Par exemple, le bachotage peut vous permettre d’obtenir une meilleure note mais vous risquez de vous rappeler peu de choses deux semaines plus tard. Simplement, il est possible que vous ne puissiez pas conserver les dernières choses sur lesquelles vous avez travaillé avant la commutation de contexte. Et celles-ci sont probablement les choses que vous voulez le plus vous rappeler quand vous revenez sur le projet.
Considérez :
Comment réduire la quantité de multitâche pour des personnes dans un contexte Agile ? Nous y avons mentionné quelques approches. Un environnement plus physique engage davantage de parties du cerveau, menant à la synthèse plus rapide et plus complète d’informations. Un effort plus concentré maintient une portée de contexte étroite. Des interactions humaines et un ScrumMaster pour faciliter certaines des interactions aideront à garder ce focus.
Quelques pratiques techniques modernes améliorent le focus, par exemple :
On connaît les arguments contre le multitâche depuis longtemps, cependant notre culture d’entreprise moderne est habituée à cette forme « d’équilibrage de charge » pour maximiser l’utilisation efficace de « ressources » humaines. Nous assemblons les équipes de personnes dans de libres groupements de fournisseurs de compétences travaillant à temps partiel sur plusieurs choses à la fois. Pouvez-vous construire une équipe à hautes performances à partir de membres à temps partiel ? comment en sommes-nous venus à penser qu’il est plus important que chacun semble être occupé tout le temps ?
Une des parties les plus difficiles d’apprendre est de devoir désapprendre les comportements actuels. C’est vrai pour les organisations autant que pour les individus, il est simplement difficile de faire le saut mental depuis ce que nous faisons maintenant à ce qui pourrait mieux fonctionner. Voici un argument visuel simple qui pourrait aider à guider un changement qui est non seulement plus facile sur les personnes, il a du sens financièrement.
Un scénario simple montré dans la Figure suivante comporte 4 personnes travaillant sur 3 projets courts. La dynamique est la même pour davantage de personnes et de plus grands projets. Dans le premier scénario, les gens font du multitâche sur 4 projets
La figure: Personnes en Multitâche
La figure qui suit montre un deuxième scénario dans lequel les mêmes personnes forment une seule équipe et complète les projets séquentiellement. Ce scénario fait la supposition très conservatrice qu’il n’y a aucun gain de productivité de teaming ou du nombre réduit de commutations de contexte. Remarquez que tous les projets sont achevés à la même date dans les deux scénarios, mais que 2 des 3 projets finissent plus tôt dans ce scénario. Imaginez les bénéfices financiers résultants.
La figure: Formez une Équipe pour Faire les Projets Séquentiellement
Avec la réduction de commutation de contexte et un modeste gain de 10 % dans la productivité en raison des synergies teaming, nous nous attendrions même à voir tous les projets finir plus tôt comme illustré dans la Figure suivante.
La figure : Une réalisation plus courte grâce au monotâche et aux synergies d’équipe
Johanna Rothman couvre ce sujet plus en détail dans : « Gérez Votre Portefeuille de Projet »
Si le multitâche est clairement mauvais, nous devrions ne jamais le faire, n’est-ce pas ? Alors comment le concilions-nous avec l’idée que « la variété est l’épice de vie » ? Des recherches sur le cerveau ont montré que la nouveauté est attractive – elle produit la dopamine, un neurotransmetteur qui nous fait en redemander. La réponse a un rapport avec le focus et la portée. Si la commutation de contexte est importante, le multitâche prend un droit de passage sur la personne et ses collaborateurs. Si la commutation est faible, elle convient à notre manière de penser et peut très bien marcher. Nous obtenons une dose de nouveauté suffisante dans un contexte d’équipe Agile en apprenant l’un de l’autre et en produisant d’autres bons neurotransmetteurs par nos achèvements et nos succès.
La commutation de contexte entre les projets prend du temps et est un coût pour l’organisation. Plus il y a de projets impliqués et plus ils sont complexes, plus le coût est élevé. En se concentrant sur une chose à la fois pendant une période plus longue, les individus peuvent travailler plus efficacement. En formant des équipes pour aborder des projets séquentiellement, nous pouvons réduire le coût de commutation de contexte et gagner encore davantage par des synergies d’équipe.
DantotsuPM.com 
