Les deux communautés, Agile et Kata, ne sont pas nouvelles. Ils ont des décennies d’expérience et de preuves de succès. Il y a des années, lorsque j’ai commencé à chercher de meilleures façons de diriger les transformations agiles, je suis tombé sur le Toyota Kata et j’ai construit un pont entre ces approches. Vous pourriez dire que le Agile Kata en lui-même est nouveau, mais les utilisateurs exploitent la richesse des expériences et des succès de deux communautés. L’intersection où Agile et Kata se rencontrent est nouvelle. Je l’ai nommé « Agile Kata » pour la rendre plus facile à référencer et à identifier.
À quoi sert l’Agile Kata ?
Agile Kata est un modèle pour aider les organisations à créer et à accroître l’agilité de l’entreprise. Comparativement, Agile Kata est appliqué au niveau organisationnel comme Scrum et Kanban le sont au niveau de l’équipe. Vous pouvez utiliser Agile Kata pour piloter une transformation agile, créer une culture agile ou conduire un changement organisationnel.
Si vous cherchez de meilleurs moyens d’augmenter l’agilité de votre entreprise avec Agile Kata
Consultez le livre blanc Agile Kata white paper sur www.agilekata.org.
Ne forcez pas l’agilité sur chaque projet que vous exécutez simplement parce que les méthodologies agiles et itératives sont « à la mode ». Pour réussir avec agile, assurez-vous que vos projets sont de bons candidats agiles.
Voici les questions à vous poser avant de sélectionner une approche agile pour un projet.
Le projet est-il suffisamment important pour que les bonnes personnes s’y consacrent ?
Agile produit des résultats rapidement, ce qui nécessite un gros investissement de temps pour les membres de votre équipe. Les équipes agiles sont composées de gens du business et de personnes techniques qui sont essentiels à vos opérations commerciales. Assurez-vous qu’ils ont suffisamment de temps pour contribuer à votre projet. Cela nécessite souvent des compromis difficiles entre le travail de projet et les opérations.
Les membres de votre équipe ont-ils suffisamment de profondeur et d’étendue de connaissances ?
Ce qui rend les méthodologies agiles agiles, c’est la réactivité à l’évolution des besoins. Les experts du métier travaillent en étroite collaboration avec les experts de l’équipe technique pour fournir ce qui est nécessaire -> rapidement. Pour cela, votre équipe a besoin d’une connaissance approfondie des domaines métiers et techniques touchés par le projet. L’équipe réévalue constamment les besoins business du projet aux niveaux du produit, les fonctionnalités macros et micros et la priorité du besoin.
Votre sponsor a-t-il un état d’esprit agile ?
La réactivité agile à l’évolution des conditions business et son approche apprentissage sont très différents des méthodes de projet traditionnelles.
Votre sponsor doit être à l’aise avec l’évolution des besoins et des priorités de l’entreprise, prêt à participer à des revues fréquentes du produit en pleine évolution et prêt à intervenir pour obtenir les ressources agiles dont le projet a besoin.
Votre équipe peut-elle être co-localisée ou virtuellement co-localisée ?
Agile implique un dialogue profond, interactif et souvent dérangeant, qui nécessite l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de votre équipe de projet si possible. Si vous ne pouvez pas, simulez la co-localisation avec les meilleurs outils vidéo et audio que vous pouvez obtenir.
Y a-t-il une synergie entre les membres business/métiers et technique de votre équipe ?
L’agilité nécessite le dévouement d’experts business et techniques qui soient ouverts aux nouvelles idées et se soutiennent mutuellement. Vous avez besoin d’un coach agile qui comprend et peut gérer la dynamique humaine, et qui peut favoriser un environnement où les membres de l’équipe partagent facilement leurs idées et leurs préoccupations. Pour réussir, une équipe agile doit bien s’entendre.
Le produit peut-il être construit de manière itérative ?
Les meilleures qualités d’Agile proviennent de la fourniture de parties utilisables de la solution tout en apprenant de chaque itération. Bien que ce soit plus courant avec les produits logiciels, d’autres produits peuvent également être fabriqués de cette façon. Avec un peu de créativité, les déménagements, les déploiements de processus et même certains projets de construction peuvent être produits par étapes itératives.
Les mêmes leçons sont capturées projets après projets, mais rien ne change !
Un obstacle majeur à la livraison est l’incapacité des équipes de direction et de développement à apprendre des erreurs commises dans le passé. En n’appliquant pas les apprentissages, les équipes sont coincées dans un cycle semblable à celui de la journée de la marmotte où des problèmes similaires continuent de se produire, les mêmes leçons sont capturées projets après projets, mais rien ne change.
Inutile de dire que cela m’a rendu (plus) cynique. Mais hier, j’ai été témoin de quelque chose qui me donne de l’espoir pour certaines organisations.
Vivant au Canada, l’une des façons dont beaucoup d’entre nous marquent le changement de saison est de changer les pneus sur nos véhicules. Lorsque les températures commencent à être régulièrement basses, le caoutchouc des pneus toutes saisons ou été durcit comme du marbre et vous n’avez plus une adhérence sûre sur les routes.
Au Québec, les conducteurs sont tenus d’installer des pneus d’hiver, mais cela reste facultatif en Ontario. Quoi qu’il en soit, de nombreux conducteurs ontariens accordent la priorité à la sécurité plutôt qu’à la frugalité en changeant leurs pneus au mois de novembre.
J’avais pris rendez-vous avec mon association automobile locale pour qu’un mécanicien vienne chez moi pour changer les pneus de mon véhicule électrique.
Pour ceux d’entre vous qui ne sont pas familiers avec les conceptions des véhicules électriques, la batterie est positionnée normalement sur toute la longueur de la voiture et elle est située sous le véhicule. En conséquence, il faut faire attention lors de l’utilisation d’un cric pour élever la voiture car une pression excessive pourrait causer de graves dommages à la batterie. Et comme la batterie d’un véhicule électrique peut représenter jusqu’à 50% du coût de la voiture, la plupart des propriétaires voudraient éviter d’encourir des dommages dus à une négligence de leur part !
Lorsque le mécanicien est arrivé, il n’avait pas d’entretoise nécessaire pour créer un tampon entre le cric et le dessous de la voiture. Je lui ai expliqué que je ne le laisserais pas soulever la voiture sans cela, alors il a appelé son central. La personne s’est emparée du problème et l’a rappelé quelques minutes plus tard pour lui faire savoir qu’il pouvait récupérer un ensemble de dispositifs de protection dans un magasin de pièces automobiles situé à proximité. Le mécanicien est parti et est revenu peu de temps après et a terminé les travaux comme prévu.
Application et systématisation immédiate de la leçon apprise !
Je m’attendais à ce que la personne au central, le dispatcher ait autorisé l’achat d’un seul jeu d’entretoises pour le camion de ce mécanicien. Cependant, alors que je payais la facture, le mécanicien m’a dit que le dispatcher avait contacté le magasin de pièces automobiles et avait passé une commande de suffisamment d’appareils pour que chacun des camions de l’association automobile soit correctement équipé.
Intégrez la leçon apprise dans la formation de tous les managers de projets.
Lorsque vous identifiez une leçon sur votre projet, il est bon que vous puissiez l’appliquer peu de temps après. Mais pourquoi ne pas aller plus loin et trouver un moyen de s’assurer que cela fasse partie des normes et des pratiques de votre organisation ?
Les leçons que nous apprenons vraiment sont celles qui empêchent quiconque dans notre entreprise de répéter les erreurs que nous avons commises.
QRP est partenaire de DantotsuPM, visitez cette page pour en apprendre davantage
Précédents billets sur les leçons apprises / lessons learned
Les projets repoussent toujours les limites, combinant des éléments, des idées et des efforts pour faire quelque chose qui n’a jamais été fait auparavant, pas tout à fait comme nous le faisons ici et actuellement.
Et donc, parfois les projets audacieux ne parviennent pas à respecter leurs échéances. Même si nous construisons des systèmes et intégrons des marges de temps, parfois cela ne fonctionne pas.
Quelques réflexions
#1 – N’attendez pas la dernière minute.
Les vœux pieux sont parfois confondus avec l’optimisme, mais vous saviez probablement plus de quatre jours avant la date limite que vous n’alliez pas répondre aux attentes. Si les gens construisent des dépendances autour de vos promesses, alors attendre que vous n’ayez plus le choix ne fait qu’aggraver la situation. Parce que non seulement vous êtes en retard, mais vous le cachiez.
#2 – Ne minimisez pas le problème.
Vous êtes en retard. Clairement. Alors dites-le. Fort et (pas tout à fait) avec fierté.
En reconnaissant la promesse originale et en étant clair que vous êtes conscient de l’échec, vous aidez les personnes qui comptaient sur vous à se sentir entendues et respectées.
#3 – Créez des alternatives.
Ce n’est pas toujours possible, mais quand c’est le cas, cela conduit généralement à de meilleures relations. Si une compagnie aérienne ne peut pas avoir un avion à un certain endroit à un certain moment, cela va grandement contribuer si elle fait le travail de trouver une nouvelle proposition pour les 100 personnes qui ont incommodées, au lieu de mettre cette charge sur elles, une par une.
#4 – Il y a une différence entre observer les dégâts (et travailler pour améliorer la situation) et accepter la honte et le blâme.
Il est clair que l’avenir n’est pas clair et que des choses surviennent.
Téléchargez ce guide sur le site de notre partenaire Virage Group
#5 – En bref, il n’y a pas de bon moyen de faire en sorte qu’une échéance manquée n’ait aucun impact pour la personne qui comptait sur vous.
Que des gens comptent sur vous est un cadeau. Si vous voulez qu’on compte sur vous la prochaine fois, mieux vaut investir au plus tôt et souvent dans le respect de cette échéance, puis, dans les rares cas où ce n’est pas suffisant, traitez vos clients avec le respect que vous aimeriez recevoir dans une situation similaire.
Il y a de plus en plus de projets dans votre organisation et vous ne savez quelle méthode ou approche choisir pour le prochain ?
Travailler en mode projets est devenue la norme dans de nombreuses situations : digitalisation, innovation, développement de nouveaux produits et services, changement dans les organisations, télétravail généralisé, besoins de gains de productivité, amélioration de la qualité…
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Les projets sont au cœur de nos entreprises et organisations. Cependant, derrière la notion du travail en mode projets, se cachent plusieurs méthodologies qui ont leurs supporters et leurs détracteurs. Souvent, ceux-ci sont extrêmement convaincus de détenir la seule et unique bonne méthodo : Prédictive/Cycle en V/Classique/Séquentielle ou bien Adaptative/Itérative/Agile, voire hybride…
Comment vous repérer dans ces approches et surtout choisir celles qui correspondent le mieux à vos besoins, votre contexte, votre culture d’entreprise, vos spécificités ?
Les systèmes et les sociétés organisés ont besoin de délais. Il serait impossible de construire efficacement une maison si les sous-traitants pouvaient livrer leurs biens ou services quand cela leur convenait. Les studios de cinéma et les éditeurs de livres planifient leurs sorties des mois à l’avance pour permettre aux équipes de distribution de planifier leur travail. Le logiciel dépend de sous-systèmes qui doivent être en place avant que l’ensemble du programme puisse fonctionner.
En plus de la valeur créée par des livrables synchronisés, il existe également des coûts réels. Pas seulement le coût organisationnel d’une échéance manquée, mais les dommages importants à la réputation ou à la marque qui se produisent lorsqu’une promesse n’est pas tenue. Et il y a un coût humain : le stress et la tension qui découlent du fait de travailler pour tenir une promesse que nous n’aurions peut-être pas faite personnellement, ou qui pourrait être plus difficile parce que quelqu’un d’autre n’a pas exécuté sa partie du boulot.
Dans la course ouverte à l’attention et aux engagements, les normes sur les délais ont vacillé. Depuis quarante ans, Saturday Night Live se déroule à 23h30. Non pas, comme le dit son créateur, parce qu’il est prêt, mais parce qu’il est 23h30. C’est l’engagement.
Sur Kickstarter, ce genre de date butoir sacro-sainte est en effet rare. « Ce chargeur sera expédié dans six semaines ! » disent-ils, alors qu’en fait, c’était il y a plus d’un an et sans date d’expédition en vue. Ou avec des investisseurs en capital-risque et d’autres bailleurs de fonds. « Nous allons battre de trois mois la concurrence pour l’ouverture sur le marché. » Parfois, on a l’impression que si l’entreprise n’apporte pas de vœux pieux à la table, elle ne sera pas financée. Compte tenu de ce choix, il n’est pas étonnant que les gens soient désespérés. Les vœux pieux ne s’appellent peut-être pas mentir, mais c’est le cas. Nous devrions mieux le savoir.
Gagner la réputation d’être quelqu’un (un pigiste, un spécialiste du marketing, une entreprise, un leader) qui ne manque pas une échéance est précieux.
Et cela n’arrive pas simplement parce que vous évitez de dormir et travaillez comme un fou. Ceci serait le dernier recours de quelqu’un qui n’est pas doué pour la planification.
Voici quelques principes de base qui pourraient vous aider avec la partie planification.
Si vous êtes en concurrence dans une industrie où la seule façon de « gagner » est de mentir sur les délais, réalisez qu’être en concurrence dans cette industrie est un choix et acceptez que vous allez manquer des échéances et que vous devrez faire face aux frais émotionnels qui en découlent.
Sachant que c’est un choix, envisagez de choisir une industrie différente, une industrie où le respect des délais est attendu et où vous pouvez obtenir satisfaction en créant de la valeur pour les autres en tenant vos promesses.
Ne comptez pas sur de faux délais comme une forme d’incitation. Cela ne fonctionnera pas de la même manière sur tout le monde, ce qui signifie que certaines personnes vous prendront au mot et livreront à temps, tandis que d’autres supposeront qu’il s’agissait simplement d’une ligne directrice. Il est plus efficace d’être clair et d’aider les gens à comprendre dès le départ ce que vous entendez par échéance. Le garçon a crié au loup mais les villageois ne sont pas venus.
En même même temps, n’utilisez pas les délais internes comme une composante garantie pour vos promesses externes. Un projet sans marges de temps est certain d’être en retard. Pas seulement susceptible d’être en retard, mais certain. De meilleurs marges font de meilleures échéances.
Acceptez le fait que livrer quelque chose à une certaine date coûte plus cher que de la livrer à chaque fois qu’elle est prête. En conséquence, vous devriez facturer plus, peut-être beaucoup plus, pour la valeur que crée votre promesse d’une date butoir. Puis, dépensez cet argent pour vous assurer que la date butoir n’est pas manquée.
Les délais ne sont pas respectés par les gens qui « font de leur mieux ». Le respect d’une date limite nécessite une approche systémique des dépendances, des marges de temps et de la planification de scénarios. Si vous coupez régulièrement les angles ou que vous vous épuisez pour respecter les délais, vous avez un problème de système.
L’antidote à la dérive de contenu n’est pas l’élagage occasionnel. C’est épuisant émotionnellement et une bataille perdue d’avance. La réponse est de restructurer activement la spécification du besoin, en supprimant ou en ajoutant des blocs entiers de travail. « Ce sera dans la prochaine version », est une réponse tout à fait acceptable, en particulier lorsque les gens ont besoin que cette version soit expédiée à temps.
Quels sont les jalons auxquels vous allez livrer et nourrir une attente positive ?
Une seule et unique échéance est une échéance qui ne sera certainement pas respectée. Mais si vous pouvez décomposer votre grande échéance en dix ou quinze jalons intermédiaires, vous verrez vos progrès bien avant qu’il ne soit trop tard pour faire quelque chose à ce sujet.
Le Mythical Person-Month est un sérieux piège. Neuf personnes, travaillant ensemble en parfaite harmonie, ne savent pas faire un bébé en un mois. Mettre plus de gens sur un projet ne l’accélère souvent pas. Au moment où
Livre sur Amazon
vous commencez à résoudre un problème de délai de cette façon, il est peut-être déjà trop tard. L’alternative est de doter chaque composant de votre projet du bon nombre de personnes et d’avoir autant de composants en cours d’exécution en parallèle que possible.
Les goulots d’étranglement sont utiles, jusqu’à ce qu’ils ne le soient pas. Si vous n’avez besoin que d’une seule personne pour approuver chaque élément de votre projet, il est peu probable que vous puissiez exécuter autant de choses en parallèle que possible. L’alternative est d’avoir une spécification rigoureuse créée à l’avance, dans laquelle de nombreuses normes sont approuvées avant même de commencer le travail.
Les discussions sur les délais se transforment souvent en question de confiance, de honte et d’effort. Ce n’est pas aussi utile que de séparer les conversations sur la structure du système et les données de celles sur l’engagement et le punch.
Les problèmes cachés ne s’améliorent pas. Dans un monde hyper-connecté, il n’y a aucune raison technique pour que le chef de projet ne sache pas ce que l’équipe sur le terrain sait de l’état du projet.
Comme la plupart des choses qui comptent, respecter les délais est une compétence, et comme c’est une compétence, nous pouvons l’apprendre.
partagez ce billet avec vos amis, collègues et relations professionnelles
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard.
Ceci est un dysfonctionnement courant dans de nombreuses équipes Scrum, et en particulier dans les Agile Release Trains de SAFe où les équipes opèrent sur un horizon de planification de 3 à 5 sprints. Il en résulte un antipattern souvent appelé « Planification Tetris. » C’est extrêmement nocif, et voici pourquoi.
Bien que le plan de fonctionnalités ci-dessus semble être parfaitement optimisé, la réalité semble souvent différente : tous les articles génèrent de la valeur plus tard qu’ils le pourraient potentiellement; à un coût plus élevé, en demandant plus de temps et avec une efficacité moindre !
Accumulation des travaux en cours
La Planification Tetris conduit souvent des personnes à commencer à travailler sur plusieurs items dans un Sprint, puis de les terminer dans un Sprint plus tard. C’est efficace sur le plan des ressources (c-à-d. maximiser l’utilisation du temps disponible), mais pas du débit (c-à-d. maximiser le rythme auquel la valeur est générée).
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Cela mène à une augmentation du travail en cours, ce qui est un problème pour de multiples raisons
Déni de valeur
Tout comme dans l’exemple de diagramme ci-dessus, « Fonctionnalité 1 » et « Fonctionnalité 2 » pourraient chacun être finis en un seul Sprint. Et encore, Fonctionnalité 1 ne fournit aucune valeur dans Sprint 1, et Fonctionnalité 2 n’a aucune valeur dans Sprint 2. Donc, nous perdons 1 Sprint de mise sur le marché sur Fonctionnalité 1 (notre plus haute priorité) – et sur Fonctionnalité 2 aussi :
Un exemple parfait de la façon dont l’utilisation optimale de l’équipe fait arriver la valeur plus tard !
Perte d’argent
Imaginez maintenant que chaque fonctionnalité coûte moins cher qu’elle ne le vaut (ce qu’elle devrait, sinon elle ne vaudrait pas la peine d’être développée) et vous voyez que l’efficacité « économisée » d’avoir travaillé sur les caractéristiques 3 et 4 avant de terminer la caractéristique 1 coûte à l’entreprise plus d’argent que les bénéfices cumulés.
Perte d’efficacité
Vous pouvez argumenter que « différentes personnes travaillent sur les fonctionnalités, donc il n’y a pas de multitâche. »
Oui, et Non. Que se passe-t-il vraiment ?
Le Sprint Planning du Sprint 1 doit discuter de 3 caractéristiques : 1, 3 et 4. Cela signifie que toute l’équipe discute de trois sujets différents (dont aucun ne sera livré dans ce Sprint). La même chose se produit dans les réunions journalières et les revues. Et peut-être aussi au niveau du code source. Les interférences des fonctionnalités peuvent également alourdir la complexité de la configuration technique, des processus de déploiement et autres.
L’équipe devient plus lente, donc moins efficace.
Ajout de risques inutiles
Livre sur Amazon
Dans les statistiques, il y a un phénomène appelé « la probabilité élevée d’événements à faible probabilité ». Permettez-moi d’expliquer brièvement : Il y a une quantité infinie d’événements presque totalement improbables, mais malheureusement, l’infini élevé divisé par l’infini faible est encore un nombre proche de : Quelque chose va arriver. Vous ne savez tout simplement pas quoi, ni quand, alors vous ne pouvez pas vous préparer ni en atténuer les effets. Comme vous ne savez pas quel aspect de votre plan sera touché lorsqu’un risque frappe, vous serez toujours pris par surprise.
En quoi est-ce un plus gros problème dans la planification de Tetris que dans la livraison séquentielle ?
Effet massif de répercussions en chaine
Certains effets « dominos » sont quasiment impossibles à arrêter.
Lorsque vous travaillez sur un sujet et qu’un événement touche toute votre équipe, vous avez à communiquer sur un problème. Lorsque la même chose se produit alors que vous travaillez sur de multiples sujets, tous sont touchés, et vous générez un effet de répercussion en chaine beaucoup plus fort.
Mesures d’atténuation complexes
Comme plusieurs sujets sont en cours de traitement, vous vous retrouvez soudainement à limiter l’impact sur plusieurs sujets. Et cela signifie des efforts d’atténuation multiples : moins de temps pour travailler, et en même temps un risque plus élevé que toutes les mesures d’atténuation ne réussissent pas. Vous vous retrouvez avec une probabilité plus élevée de ne pas être en mesure de revenir sur les rails !
Conséquences chaotiques
L’effet des répercussions en chaine dans l’organisation et des mesures d’atténuation pourraient entraîner des conséquences imprévues qui sont encore plus difficiles à prévoir que l’événement déclencheur. Dans de nombreux cas, la seule solution possible est de dire stop et de marquer tous les sujets commencés comme retardés, puis d’essayer de réparer la casse à partir de là.
Préparez vous à l’échec
Relisez ce billet sur la Loi de Parkinson
Il y a la Loi de Parkinson – « Le travail s’étend toujours pour remplir la quantité de temps disponible« . C’est souvent utilisé comme argument pour commencer un autre sujet, parce qu’il arrête le sur-investissement et garde les gens concentrés.
Mais il y a aussi la Loi des moyennes : « Les plans basés sur les moyennes échouent la moitié du temps. »
Cette dernière fait de la planification Tetris une approche suicidaire d’un point de vue business : Elle enclenche un cercle vicieux.
Échec prévisible
Parce qu’il n’y a pas de marge de temps intégrée dans la planification Tetris, le plan à mi-parcours échouera automatiquement dès qu’une seule fonctionnalité s’avère plus complexe que prévue. Plus les fonctionnalités font partie de notre pile Tetris, plus il est probable qu’au moins l’une d’entre elles échouera. Et l’équipe sera généralement blâmée pour cela. Pour cette raison, nous nous retrouvons avec…
Des estimations prudentes
Les équipes doivent insérer des zones tampons dans leurs estimations de fonctionnalités afin de réduire la probabilité de défaillance. Lorsqu’un plan Tetris s’étend sur plusieurs sprints, il se peut que certaines fonctionnalités ne soient pas « prêtes » à être implémentées pendant le sprint lorsque la marge de manœuvre serait disponible – donc nous nous retrouvons avec la Loi de Parkinson, les estimations gonflées ne réduisent pas les probabilités d’échec.
Un débit en baisse
À ce stade, La loi de Parkinson se combine avec le défaut des moyennes pour mettre l’équipe KO. Indépendamment de la manière conservatrice dont les estimations ont été construites, l’équipe finira toujours par échouer la moitié du temps. La conséquence est que le débit business continue de diminuer (Jusqu’à un fond intéressant : quand un Sprint ne contient qu’une seule caractéristique !)
Étranglement de l’équipe
Examinons maintenant l’impact psychologique de la Planification Tetris.
Pas d’espace pour la créativité
Je n’ai jamais vu une organisation où le marketing produits était heureux que les développeurs ajoutent des « espaces créatifs » dans un plan Tetris. Il s’agit de lancer fonctionnalité, après fonctionnalité, après fonctionnalité, sans pause, sans pause. Lorsqu’une fonctionnalité est terminée, une autre est déjà en cours. Il n’y a pas de place pour la créativité.
Pas d’espace pour la croissance des personnes
Le seul résultat opérationnel pertinent dans les plans Tetris est généralement la valeur opérationnelle fournie.
Il ne tient pas compte du fait que les développeurs sont le capital humain de l’organisation, et leur croissance accroît la capacité de l’organisation à offrir de la valeur.
Surtout dans notre industrie technologique en rapide évolution, ne pas croître équivaut à reculer jusqu’à ce que finalement, l’équipe ne soit plus compétitive.
Pas de place pour l’amélioration
Je conseille souvent que les développeurs devraient prendre un certain temps pour regarder le travail « fait » pour réfléchir à comment il aurait pu être mieux fait, et de transformer cette meilleure façon en action. Avec Planning Tetris, cette opportunité n’existe pas car il y a toujours une autre fonctionnalité en attente et améliorer quelque chose qui existe est toujours moins important que de livrer la prochaine grande chose. Cela finit souvent dans des produits ratés qui ne sont pas un plaisir ni pour les développeurs ni pour les clients !
Maintenant… et alors ?
Le fait que la planification Tetris soit une mauvaise idée devrait être évident.
Mais alors, quelle est la meilleure façon ? pouvez-vous vous demander.
Cela semble incroyablement simpliste, parce que c’est aussi simple que cela.
Livre sur Amazon
Réduisez la quantité de fonctionnalités sur lesquelles l’équipe travaille en parallèle au minimum absolu. Cela minimise le rayon de l’explosion.
Au lieu d’avoir des gens en parallèle de multiples sujets, laissez les gens « inefficaces », « peu qualifiés » prendre des parties plus faciles du travail pour améliorer leur capacité. Cela réduit l’impact des événements à faible probabilité et donne à chacun de l’air pour respirer.
Donnez du mou dans les sprints. La résilience acquise peut absorber l’impact. Elle réduit également le besoin d’estimations gonflées, contre la loi de Parkinson et le défaut des moyennes. Elle donne également aux gens de l’air pour respirer.
Tirez : Soyez d’accord sur l’approche Pull-Forward. Lorsque l’équipe se sent sous chargée, elle peut toujours ramener les sujets futurs dans ces temps d’inactivité. Personne ne se plaint quand un sujet est fini à l’avance, tout le monde se plaint quand quelque chose arrive en retard. Le Pull-Forward n’a pas d’effets de répercussions en chaine ou de conséquences chaotiques.
Ok, trop de mots, alors pour faire court
Séquencez.
Donnez du mou.
Tirez.
Tous les problèmes mentionnés dans cet article sont alors résolus.
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
Les outils de planification vous aident et cependant, comme toute autre technologie, ils peuvent vous être défavorables. Déjouez ces principaux pièges !
Comme un couteau tranchant pour un chef, un outil de planification est un élément indispensable pour un manager de projet.
Les outils de planification, comme toute technologie, peuvent aider ou blesser.
Voici cinq conseils pour utiliser votre outil de planification de projet avec moins de drama.
#1 – Utilisez un modèle ou réutilisez un plan réussi
Bien que les projets soient uniques, ils sont rarement totalement différents des projets antérieurs. Utilisez un modèle de projet ou copiez et modifiez un échéancier d’un projet passé qui a bien fonctionné. Vous pouvez gagner du temps, tirer parti du succès de ces échéanciers et capturer des tâches que vous pourriez autrement négliger.
#2 – Gardez simples les relations entre les tâches
La relation directe entre taches de type finish-to-start fonctionne la plupart du temps et c’est la plus facile à comprendre pour les gens.
Utilisez cette relation simple à moins qu’il n’y ait une raison pressante pour le start-to-start ou finish-to-finish.
#3 – Personnalisez le calendrier et les heures/jours par défaut
Les paramètres de calendrier que vous utilisez doivent correspondre aux horaires de travail de votre organisation et des membres de votre équipe, sinon votre échéancier ne sera pas exact. N’oubliez pas d’ajouter les jours fériés et autres jours non travaillés comme les périodes de maintenance des locaux à votre calendrier de projet. De plus, envisagez d’ajuster les heures par défaut par journée ou autres paramètres du calendrier pour tenir compte du temps de travail réel du projet. Bien qu’une journée de travail de 8 heures soit courante, les membres de l’équipe travaillent rarement 8 heures sur vos tâches de projet. Des réunions d’équipe, d’autres travaux de projet et opérationnels sont souvent nécessaires. Vous pouvez changer le nombre d’heures par journée travaillée à 6 ou même moins en fonction de votre environnement. Ou vous pouvez affecter des personnes à temps partiel sur leurs tâches. Parlez aux membres de votre équipe de ce qui est réaliste.
#4 – Simplifiez les affectations de ressources
La gestion et la modification des affectations de ressources sont d’énormes sources de problèmes de planification. Une pratique exemplaire consiste à répartir le travail du projet afin que les tâches soient plus courtes que vos périodes de reporting et ont seulement une ou deux ressources affectées. Avec de telles tâches, il est beaucoup plus facile de créer des affectations de ressources et de les modifier une fois le travail commencé.
#5 – Formez les gens à utiliser l’outil de planification
Les outils de planification vous aident à produire des rapports faciles à comprendre. Parfois, les gens croient qu’ils peuvent modifier vos plannings ou produire des rapports de projet sans aucune formation. C’est une recette pour des rapports inexacts, des problèmes de management des attentes et une migraine pour le chef de projet ! Assurez-vous que toutes les personnes qui utiliseront l’outil de planification pour tenir à jour l’échéancier et produire des rapports soient correctement formées.
Visitez le site de notre partenaire Virage Group
partagez ce billet avec vos amis, collègues et relations professionnelles
À mesure que les technologies d’Intelligence Artificielle (IA) deviennent de plus en plus courantes dans l’entreprise, quelles compétences vous distinguent ? Personnes individuelles et équipes informatiques, concentrez-vous sur ces quatre !
4 Artificial Intelligence (AI) skills IT pros must have
L’Intelligence Artificielle (IA) est sans doute devenue un terme courant dans les entreprises modernes. À l’heure actuelle, la plupart des entreprises ont adopté un type d’initiative commerciale qui inclut l’IA dans leur transformation numérique.
L’intelligence artificielle est un terme large, mais une grande partie de la recherche et du développement actuels se concentre sur l’apprentissage automatique (Machine Learning /ML), une sous-discipline grâce à laquelle les machines apprennent à partir de données plutôt que d’être explicitement programmées.
Surveillez vos compétences en IA
L’IA et le ML ciblant un large éventail d’utilisateurs d’entreprise, les professionnels de l’informatique doivent développer de nouvelles compétences pour réussir dans ce domaine émergent. En voici quatre exemples.
#1 – Recadrez les problèmes business depuis le contexte des données
Une compréhension de l’entreprise et de ses problèmes les plus urgents est une compétence transcendante pour tout professionnel de l’informatique. Cependant, les projets axés sur l’IA nécessitent que les solutions soient cadrées et rationalisées dans le contexte des données directement ou indirectement disponibles pour l’entreprise.
La question essentielle est de savoir si ces données ont le potentiel de résoudre le problème business en question. Bien que la réponse ne soit pas toujours immédiatement évidente, elle commence par une hypothèse issue d’une analyse préalable ou peut-être simplement basée sur l’intuition. Par exemple, une entreprise qui connaît un fort taux de désabonnement de sa clientèle pourrait émettre l’hypothèse que les changements récents dans l’activité commerciale pourraient prédire l’attrition future.
#2 – Soignez votre ingénierie des données
La plupart des entreprises disposent d’une abondance de données, mais leur exploitation pour des projets d’IA / ML peut être difficile. La préparation des données pour l’analyse et l’apprentissage automatique est généralement la partie essentielle et la plupart des organisations ne comprennent pas l’investissement requis pendant cette phase.
De plus en plus, les entreprises réalisent l’importance de créer des systèmes et des processus qui automatisent l’acquisition, la transformation et la livraison de données aux organisations impliquées dans des projets d’analyse et d’IA / ML. Ces entreprises comprennent que les données doivent être un actif de première classe au même titre que le code et que les principes fondamentaux du génie logiciel doivent être appliqués de la même manière.
Alors que tous les professionnels de l’informatique devraient avoir des compétences de base en transformation des données, nous verrons probablement l’émergence d’équipes d’ingénierie des données centralisées dont l’objectif principal est de développer et de déployer des pipelines de données automatisés qui fournissent des données de haute qualité à grande échelle.
#3 – Apprenez les outils et langages pour le Machine Learning
Les outils et l’infrastructure pour l’apprentissage automatique ont radicalement évolué au cours de la dernière décennie, à la fois dans les offres open source et commerciales. L’accès aux technologies de pointe autrefois réservé aux chercheurs et aux praticiens les plus élitistes a été démocratisé, avec des chaînes d’outils et des services entièrement intégrés de la part de tous les principaux fournisseurs de cloud.
Divers langages de programmation sont utilisés pour l’apprentissage automatique, mais Python est le plus courant. Une grande partie de son succès est due à une communauté active et dynamique ainsi qu’à la disponibilité de bibliothèques qui implémentent pratiquement tous les algorithmes populaires.
Un projet qui aurait pu autrefois nécessiter un scientifique des données peut maintenant être réalisé par des professionnels de l’informatique.
La différenciation des compétences entre les data scientists et les ingénieurs logiciels s’est estompée ces dernières années en raison des progrès et de l’accessibilité des outils. Un projet qui aurait pu autrefois nécessiter un scientifique des données peut maintenant être réalisé par des professionnels de l’informatique.
#4 – Évaluez les performances du modèle
La technologie de sélection des modèles, en particulier avec les chaînes d’outils intégrées des fournisseurs de cloud populaires, évolue à un point tel que certaines décisions laborieuses souvent prises par les scientifiques des données sont désormais prises automatiquement dans les logiciels. Un exemple clair est la sélection d’un modèle qui donne les meilleures performances tout en se généralisant bien.
Consultez notre introduction sur 10 termes clés de l’intelligence artificielle pour les responsables informatiques et les chefs d’entreprise Cheat sheet: AI glossary
Même si ces outils deviennent plus évolués, les professionnels de l’informatique doivent avoir une compréhension générale des concepts d’apprentissage automatique, en particulier dans l’évaluation des performances du modèle et la corrélation entre la sélection des fonctionnalités et la qualité prédictive.
Bénéficiez pleinement de l’Intelligence Artificielle et du Machine Learning
Tirer parti de l’Intelligence Artificielle et du Machine Learningpour améliorer les résultats business devient rapidement un enjeu central pour les entreprises modernes alors qu’elles naviguent dans les initiatives de transformation numérique. L’adoption de ces technologies en évolution oblige les organisations informatiques à développer de nouvelles compétences visant à utiliser les données pour résoudre les problèmes de l’entreprise. Pour mieux équiper les organisations engagées dans des projets d’IA, les équipes informatiques doivent également mettre en œuvre de nouveaux systèmes et processus qui automatisent l’acquisition, la transformation et la livraison des données.
Une variété de ressources sont disponibles en ligne pour aider les professionnels de l’informatique à acquérir les compétences en IA et en ML dont ils ont besoin. Coursera.org propose un excellent introductory course qui enseigne les principes fondamentaux du Machine Learning. En outre, tous les principaux fournisseurs de cloud, y compris AWS, Azure et Google, proposent une formation pour leurs services d’IA et leurs chaînes d’outils intégrées. Bien que bon nombre de ces cours en ligne soient gratuits, certains, comme les programmes de certification, comportent des frais.
Pour en apprendre davantage sur l’intelligence artificielle
A travers ce livre blanc, le partenaire de ce blog, CSP DOCENDI, vous propose de faire le point sur les manières d’ajuster votre gestion de projet pour faire face au contexte actuel.
Il est aujourd’hui indispensable pour un chef de projet de développer sa flexibilité afin de s’adapter au mieux aux environnements changeants et faire face à l’imprévu.
Téléchargez gratuitement ce livre blanc
Réussir le pilotage en transverse, piloter le changement, adapter sa stratégie de management, ou encore développer une culture projet dans l’entreprise sont autant de défis actuels rendant la pratique du management de projet de plus en plus difficile.
La flexibilité devient donc une compétence indispensable pour faire face à l’imprévu.
Vous trouverez dans cette boîte à outils un rappel des bonnes pratiques ainsi que des outils digitaux pour répondre aux enjeux de pilotage et de centralisation de l’information.
Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance.Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.
Mesurable.
La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.
Atteignable
Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.
Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.
Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.
Réaliste
Une approche pratique de comment planifier et implémenter le changement
En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.
Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.
La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.
Temporel – contraint par le Temps
L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.
QRP est partenaire de DantotsuPM, visitez leur site et leur blog
partagez ce billet avec vos amis, collègues et relations professionnelles
En donnant une formation PRINCE2 ® (majoritairement) à des managers de projet, il y avait deux élèves travaillant dans l’événementiel qui m’ont dit
Nous ne sommes pas vraiment des managers de projet; on nous a juste envoyés suivre le cours.
Cependant, quand les deux personnes m’ont expliqué leurs rôles au travail, ce qu’elles ont décrits était de l’activité standard de management de projet.
C’était un instant d’illumination pour chacun sur le cours car les gens pensent souvent seulement à leur « travail » ou une « tache à faire » quand ils dirigent en réalité des projets. A l’inverse, d’autres qualifient inexactement une partie standard d’activités opérationnelles de projet.
Des professionnels comme des coordonnateurs d’événements, des designers d’intérieur, des commerciaux ne se qualifieraient pas spontanément de chefs de projet, mais c’est ce qu’ils font et les compétences contenues dans PRINCE2 sont ce dont ils ont besoin.
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées
La valeur d’une méthode de management de projet
Selon PRINCE2, un projet est une organisation provisoire créée dans le but de livrer des produits selon un cas d’affaires agréé.
Livre sur Amazon
Ainsi, par exemple, un manager d’événement doit comprendre les exigences de l’événement, estimer des coûts, traiter avec des fournisseurs et mettre toutes les pièces en place selon le budget et les contraintes de temps et s’assurer que tout problème le jour J est résolu à la satisfaction du client.
Cette approche suit un cycle de vie de projet et ceci fait de la société d’organisation d’événements une organisation orientée projets et le manager d’événement, en fait, un manager de projet.
Si le responsable du manager d’événement s’attend à ce que l’employé fasse simplement en sorte de “s’en occuper et le faire se produire”, il passe à côté du fait qu’il y a une méthode et une structure disponible pour donner davantage de contrôle et rendre la vie plus facile.
Le management de projet en pratique
Ouvrir un emballage de meubles IKEA et découvrir qu’il n’y a aucune instruction signifie que cela vous prendra beaucoup plus longtemps pour assembler les meubles et non sans un certain degré de stress ou d’erreurs.
De la même manière, en construisant « un produit », adopter une méthode de management de projet comme PRINCE2 vous donne les outils pour accroitre vos chances de le faire avec succès.
Prenons de nouveau l’exemple de la gestion d’événements. Il y a toujours un risque qu’un fournisseur ne parvienne pas à arriver à l’heure ou ne vienne pas du tout le jour J.
L’approche PRINCE2 vous aide à identifier de tels risques à l’avance et les atténuer ou les contrôler. Vous pourriez ainsi décider d’avoir un plan B complet si le pire frappe votre événement.
En fin de compte, quelqu’un menant des projets dans n’importe quelle organisation peut bénéficier de la méthode PRINCE2 d’un certain nombre de façons
Prince2 vous permet de comprendre les besoins des clients et de vérifier que le cas d’affaire reste valide durant tout le projet.
L’approche Prince2, solide et structurée, fournit une confiance accrue en vos capacités et celles de votre société.
Prince2 permet un plus grand contrôle et la capacité de prévoir ce qui pourrait arriver et atténuer les conséquences.
Si la crise nous a appris quoi que ce soit professionnellement, c’est que l’inattendu peut changer presque tout dans la façon dont nous travaillons.
Cependant, la formation en management de projet insuffle la capacité dans les personnes de s’adapter beaucoup plus rapidement, même si elles sont habituées à une certaine stabilité et à relativement peu de changement au travail.
Beaucoup d’organisations sont toujours sur un périple pour reconnaître combien de ce qu’elles font est projet. Comme leur compréhension se développe et qu’elles voient le besoin d’appliquer les meilleurs standards de cette pratique comme PRINCE2, les compétences en management de projet sont reconnues comme universellement appropriées et pas seulement pour ceux avec « Manager de projet » sur leur carte de visite.
partagez ce billet avec vos amis, collègues et relations professionnelles
Si on vous demandait d’écrire un scénario de test, sauriez-vous quoi faire ?
Qu’en est-il d’un cas de test ou d’un scénario de test ?
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
La première étape consiste à bien définir ces termes.
Chacun de ces termes implique un niveau de détail différent.
Une fois qu’un testeur sait ce que chacun de ces termes signifie, il peut comprendre comment les utiliser pour décrire le travail de test qui est effectué quotidiennement.
C’est quoi un scénario de test ?
Un scénario de test est essentiellement une documentation d’un cas d’utilisation. En d’autres termes, il décrit la fonctionnalité de l’application à tester. Il est utilisé pour tester de bout en bout une fonctionnalité.
Un même scénario de test nécessitera un ou plusieurs cas de test pour s’assurer que le scénario a été couvert de manière satisfaisante. Par conséquent, un scénario de test a une relation un-à-plusieurs avec les cas de test.
À titre d’exemple, considérons un scénario de test
« Vérifiez que l’utilisateur ne peut pas se connecter avec des informations d’identification incorrectes »
Maintenant, ce scénario de test peut être encore décomposé en plusieurs cas de test comme :
Vérifier qu’un utilisateur avec le bon nom d’utilisateur et le mauvais mot de passe ne soit pas autorisé à se connecter.
Vérifier qu’un utilisateur avec un nom d’utilisateur incorrect et un mot de passe correct ne soit pas autorisé à se connecter.
Vérifier que les utilisateurs avec des noms d’utilisateur et des mots de passe incorrects ne soient pas autorisés à se connecter.
Qu’est-ce qu’un cas de test ?
Le cas de test est un ensemble d’actions exécutées pour vérifier une caractéristique ou une fonctionnalité particulière de votre application logicielle.
Il inclut toutes les entrées possibles positives comme négatives, ainsi que des données de test, des préconditions et des postconditions développées pour un scénario de test spécifique afin de vérifier toute exigence.
À l’aide de ces variables et conditions, le testeur peut comparer les résultats réels aux résultats attendus pour déterminer si un produit logiciel fonctionne conformément aux exigences du client.
Scénario de test VS cas de test
QRP est partenaire de DantotsuPM, visitez leur site et leur blog
partagez ce billet avec vos amis, collègues et relations professionnelles
La logique de base poka-yoke est « Mieux vaut prévenir que guérir ». Une maxime chère aux managers de projets !
C’est Shigeo Shingō, un ingénieur japonais qui en est la source. Il était employé chez Toyota et s’est passionné pour le contrôle de la qualité et le « zéro défaut », sans le kanban.
L’idée de base du poka-yoke est de concevoir un mécanisme qui empêche toute erreur de se produire. Conçu au départ dans le monde industriel, ce dispositif généralement mécanique permet d’éviter des erreurs de montage, d’assemblage, de connexions, de procédures…
QRP est partenaire de DantotsuPM, visitez leur site et leur blog
On en distingue usuellement 3 sortes
#1 – Poka-yoke de contact
La présence de ce mécanisme lors de l’usage ou opération du produit force l’opérateur à ne pas faire d’erreur. Par exemple, sur un véhicule à boite de vitesse automatique, si la pédale de frein n’est pas enfoncée, la voiture refuse de démarrer. Il s’agit bien d’un mécanisme anti-erreur.
Des exemples dans votre projet
Les checklists de livrables à chaque jalon de projet que le manager de projet doit construire et assembler avec l’équipe sont l’un de ces mécanismes anti-erreur. Si les livrables ne sont pas présents, le bureau de management des projets ou PMO (Project Management Office) va refuser d’inscrire le projet à une revue de passage de jalon qui elle-même va potentiellement stopper le projet.
Les revues du registre des risques qui vont refuser d’accepter un nouveau risque sans avoir identifié nommément la personne responsable de le manager.
#2 – poka-yoke de signalement
Il indique tout oubli dans une procédure quand une opération nécessaire n’a pas été effectuée. C’est le signal sonore et visuel permanent dans votre voiture si vous démarrez sans avoir bouclé votre ceinture de sécurité.
Des exemples dans votre projet
Le registre des actions en court permet de rappeler à chaque réunion et comité de projet les actions qui sont ouvertes, depuis quand et avec quelle criticité ou impacts. Ceci met en alerte les propriétaires de ces actions qui ne voudront pas de manière répétée être pointés comme défaillants dans la résolution de ces points.
Les comptes à rebours qui vont égrener les jours avant une date fatidique ou critique pour le projet et servir de rappel journalier aux acteurs du projet.
#3 – poka-yoke chronologique
Ici, c’est la séquence d’opérations obligatoires à réaliser chronologiquement pour mettre en route une machine. C’est la checklist des mécaniciens et du pilote sur la grille de départ d’un grand prix.
Des exemples dans votre projet
C’est la séquence documentée dans votre processus de mise en production de tout nouveau produit avec toutes les étapes clés de préparation et de formation des futurs utilisateurs, des équipes de support, de mise en production du livrable, de vérification de son bon fonctionnement, de mise en place des métriques pour mesurer la capacité et la rapidité…
partagez ce billet avec vos amis, collègues et relations professionnelles
La team PMI Disciplined Agile de Poche, composée des bénévoles Claudine Blanquier, Laurent Thomas, Frédéric Martin et Selim Khaldi, facilite la découverte de Disciplined Agile avec des mémentos de poche résumant les fondamentaux de Disciplined Agile, EN FRANCAIS !
Le PMBOK V7
Le PMI, à travers la septième édition du PMBoK, a su prendre en compte l‘évolution de l’environnement de la conduite de projet : les approches adaptatives, dont font partie les démarches Agiles, sont identifiées et décrites dans le cadre général porté par des principes de conduite de projet.
De manière pratique, l’acquisition par le PMI en 2019 de la boîte à outils Disciplined Agile (DA), traduit tout l’intérêt qui est porté à ces approches.
À partir de ce constat, une équipe pluridisciplinaire de bénévoles du « Disciplined Agile Special Interest Group » du Chapitre PMI-France a décidé de faciliter la découverte de Disciplined Agile en produisant des mémentos de poche résumant les fondamentaux de Disciplined Agile, en français !
Un superbe travail de synthèse de l’essence de cette approche et une traduction compréhensible par tous les francophones.
1. Les personnes et les interactions plus que les processus et les outils
La méthode agile privilégie l’individu et lui donne le plus d’importance. Il est facile de comprendre les personnes plutôt que les processus ou les outils, car ce sont les personnes qui répondent aux besoins de l’entreprise et pilotent le processus de développement.
« Quand les entreprises prennent de l’ampleur, elles cherchent à reproduire leur succès initial. Elles confondent bien vite le processus et le contenu ». Steve jobs dans une interview en 1995.
2. Des logiciels opérationnels plus qu’une documentation exhaustive
L’approche Agile se concentre sur la production de valeur. La documentation reste nécessaire à la continuité et à la maintenabilité du projet, mais n’apparaît pas comme une priorité. Auparavant, l’équipe passait des heures sur la rédaction de documents et cela empêchait l’avancement des livrables.
3. La collaboration avec les clients plus que la négociation contractuelle
Le message ici n’est pas que les contrats doivent être jetés par la fenêtre mais que vous devriez collaborer plus souvent avec vos clients. L’approche Agile demande la collaboration continue avec le client et son implication dans toutes les phases du projet pour collecter ses retours et donc construire des produits de valeur.
4. L’adaptation au changement plus que le suivi d’un plan
Les méthodes traditionnelles considéraient le changement comme une dépense, il fallait donc l’éviter. L’intention était de développer des plans détaillés et élaborés. L’agilité nous invite à mettre en place un fonctionnement flexible capable d’absorber les changements et de redéfinir les objectifs et les priorités. Avec ce mode de fonctionnement, tout changement apporte une valeur ajoutée au lieu d’un obstacle à éviter.
Traditionnellement, les gens considèrent les tests comme une phase qui se produit à la fin du développement. En revanche, en Agile, les tests sont une activité qui doit se produire parallèlement au développement .
2. Éviter les bugs plus que trouver les bugs
Il serait beaucoup plus productif de clarifier les spécifications avant de commencer à écrire une seule ligne de code, et de s’assurer que tout le monde, du client au développeur et au testeur, a exactement la même compréhension de la façon dont quelque chose doit fonctionner.
3. Tester la bonne compréhension plus que vérifier la fonctionnalité
En Agile, les testeurs doivent devenir des ambassadeurs du client; Ils doivent comprendre en profondeur qui sont leurs utilisateurs et ce qu’ils essaient de réaliser avec le produit. Les testeurs doivent être les représentants de ce client dans chaque décision de conception, en veillant à ce que la fonctionnalité réponde aux besoins réels des clients, pas seulement aux spécifications.
4. Construire le système plus que casser le système
Bien qu’il existe une croyance commune que les testeurs sont exclusivement engagés dans la destruction, ce n’est qu’à moitié vrai. Il ne faut pas oublier l’objectif principal de créer un produit de valeur et qui fonctionne bien. C’est pourquoi la reproduction des actions réelles d’un utilisateur est de la plus haute priorité.
5. La responsabilité de l’équipe sur la qualité plus que la responsabilité du testeur
Les testeurs ne peuvent pas améliorer la qualité, leur rôle est de déterminer le niveau de qualité et d’en informer les parties prenantes. Vous ne pouvez améliorer la qualité que par les efforts conjoints de toute l’équipe.
Fidaa Berrjeb est Agile QA analyst certifiée ISTQB et Scrum Master.
Fidaa Berrjeb
Après ce premier billet qui, nous l’espérons, vous aura intéressés, Fidaa va essayer de s’orienter sur l’aspect Quality Assurance (QA) dans ses prochains billets car les sujets sont nombreux qui couvrent Agilité et QA.
partagez ce billet avec vos amis, collègues et relations professionnelles
La course d’orientation est un sport d’aventure en plein air dans lequel vous recevez une carte et des coordonnées. L’objectif est de naviguer d’endroit en endroit en passant par un ensemble de points de contrôle et de décider du meilleur itinéraire pour terminer le parcours dans les plus brefs délais. La seule différence est que la course est dans le projet une entreprise multinationale avec une structure organisationnelle complexe. Avant de vous précipiter aux prochains points de passage (ou aux phases de votre projet), il sera important de rencontrer votre équipe pour discuter de ce qu’est la cible finale (le livrable du projet) et si le projet est utile et viable.
Mais comment faire cela dans un environnement Agile PRINCE2® ?
D’après mon expérience, j’ai trouvé un excellent soutien de la part d’une valeur clé de PRINCE2 Agile : l’exploration. Cela m’a aidé à définir ce qui constitue le produit minimum viable (MVP) de mon projet et à définir les exigences obligatoires dans la description du produit de mon projet. Habituellement, les techniques d’exploration telles que « l’expérience » ou « spike/spiking » sont utilisées soit lorsqu’il existe des incertitudes autour des théories, lorsque l’impact est lié à l’utilisation de nouvelles technologies ou lorsqu’il existe des préoccupations fonctionnelles du point de vue du consommateur. Lorsque vous utilisez des techniques d’exploration au début du processus de projet PRINCE2 Agile (en avant-projet), cela peut être source de grande valeur.
Partenaire de DantotsuPM
Maintenant, imaginez qu’en plus du mandat du projet, vous receviez également la documentation technique de bout en bout pour intégrer une plate-forme de commerce électronique d’avant-garde pour votre organisation. Faire un Sprint d’une journée (un spike) et créer un livrable temporaire un tel prototype peut offrir les avantages suivants:
Vous réduisez les incertitudes d’un point de vue technique et client.
Vous aidez à identifier tous les domaines qui doivent être examinés pour remplir la description du livrable du projet et son analyse de rentabilité.
Vous identifiez et impliquez les bonnes parties prenantes, qui peuvent ensuite faire partie de l’équipe de projet.
Vous créez des boucles de retours rapides pour accélérer le processus de collecte des exigences.
Vous créez une opportunité de générer des apprentissages qui peuvent soutenir l’analyse de rentabilité.
Vous aidez à résoudre les « inconnus connus » et à révéler des informations sur des « inconnus inconnus ».
Pour rappel :Les Spikes sont une invention de la méthode Extreme Programming (XP). C’est un type spécial d’histoire utilisateur qui est utilisé pour acquérir les connaissances nécessaires afin de réduire les risques sur un choix technique, de mieux comprendre une exigence, ou d’accroitre la fiabilité d’une estimation. Une spike a une taille maximale en durée car elle doit tenir dans le sprint qui la contient. À la fin du sprint, la spike sera déterminée comme done ou pas comme toute autre histoire utilisateur. Une spike est un excellent moyen de réduire rapidement les risques et elle permet à l’équipe d’obtenir des retours utilisateurs et de mieux appréhender la complexité.
Dans PRINCE2 Agile, le travail à partir d’un spike peut être managé et contrôlé avec une approche de timeboxing telle que Scrum ou en utilisant un système basé sur les flux (par exemple Kanban). J’ai constaté qu’en raison du spike, j’étais mieux placé pour travailler avec l’équipe de développement sur les estimations du projet. Il est important d’être cohérent avec l’approche de management agile afin de s’assurer que les techniques d’estimation sont bien alignées.
Faire un ou des spikes au cours de la phase d’avant-projet a également fourni des informations sur les risques majeurs (dans mon cas, principalement les menaces) qui auraient un impact sur le projet s’ils se matérialisaient.
Toutes les données recueillies à partir de ce prototype ont contribué à éclairer l’élaboration de l’analyse de rentabilité. L’un des principes les plus pertinents de PRINCE2 Agile est de maintenir une justification business continue.
Le spike au cours de la phase d’avant-projet peut fournir suffisamment de données pour répondre à la question suivante : Le projet en vaut-il la peine et est-il viable ?
Si la réponse est « non », vous saurez alors que le spike vient de vous éviter un mauvais investissement. Si le projet fait partie d’un programme, il est fondamental de remonter ceci dès que possible; cela pourrait déclencher un examen de l’analyse de rentabilité du programme tout entier avec des conséquences majeures sur ses bénéfices et la réussite de la future organisation.
Si la réponse est « oui », utilisez les flux d’informations disponibles pour mettre en évidence les risques majeurs, l’impact associé et la probabilité lorsque vous demandez l’approbation de lancement du projet par la direction du programme.
partagez ce billet avec vos amis, collègues et relations professionnelles
Une nouvelle initiative s’est mise en place au sein de la communauté des membres du PMI Chapitre France, le Lab Hybrid.
Allez découvrir les sommets du monde hybride avec Stéphane Derouin
Réunissant environ 25 membres, Stéphane Derouin a lancé cette nouvelle initiative à mi-parcours entre la gestion de projet dite traditionnelle et les concepts Agiles.
L’objectif de ce groupe de travail est de co-écrire un guide des bonnes pratiques hybrides, pragmatique et utilisable par le plus grand nombre .
Vous y retrouverez des aspects liés :
A la gouvernance
Au cadre méthodologique
A la dimension humaine.
Bien évidemment le projet lui-même sera géré en mode hybride avec une livraison du guide prévue pour le 31 mai 2022.
Ricardo Naciff, Président du PMI France
Le Business Owner est Ricardo Naciff, président du PMI France et Stéphane Derouin est le responsable du projet. Chaque sujet au sein des trois thématiques sera porté par une petite équipe qui fonctionnera en mode Agile / Scrum avec un Product Owner (Responsable du Product Backlog) et un Scrum Master.
Nous ne manquerons pas de partager avec vous l’avancement de ce projet au cours de l’année 2021/2022.
La pandémie a obligé le Conseil Municipal de Kirklees à ajuster la façon dont il organise des ateliers facilités.
Avant la pandémie, il avait commencé à documenter toutes les sessions de sprint de conception qu’effectuait l’équipe digitale du service informatique. Cela avait été le cas pour des ateliers facilités en face à face où nous avions pu cartographier tout changement de processus et explorer les implications et concevoir de nouvelles façons de fournir des services informatiques. Des ateliers comme ceux-ci sont la clé d’une mise en œuvre informatique réussie et fournissent un réel sentiment de collaboration, d’engagement et d’exploiter l’expertise des personnes.
Cependant, une fois que la pandémie a commencé et que plus personne n’était au bureau, cette capacité de collaborer avec différents services, d’examiner un problème et de trouver une solution lors d’une session en face à face facilitée par les outils informatiques était perdue. Si nous ne voulions pas perdre l’essence même de la collaboration et de l’interaction, nous devions chercher de nouvelles façons d’interagir avec les différents services pour fournir des solutions, qui portaient maintenant sur la gestion de la pandémie et de ses effets sur la population de Kirklees.
CSP est partenaire de DantotsuPM
À partir de mars/avril 2020, nous avons commencé à organiser des sessions de sprint de conception en ligne à l’aide de Miro et d’autres outils en ligne tels que bit.ly. Cela a changé la donne pour nous. Nous avions un modèle configuré pour exécuter ces sessions et nous avons pu rapidement rassembler les gens sur un appel en ligne et exécuter des sessions d’environ 2 heures par jour ou une journée au maximum et à la fin, nous aurions une piste de solution claire que nous serions en mesure de transmettre à l’équipe de développement pour nous la livrer.
La possibilité d’organiser ces sessions à l’aide d’outils de collaboration en ligne signifiait que nous pouvions tous participer en ligne; tout le monde a pu collaborer. Cela a également permis aux personnes qui peuvent être plus introverties dans un environnement en face à face d’avoir leur mot à dire. D’une manière ou d’une autre, l’environnement en ligne a amélioré leur engagement. La possibilité de concevoir et d’afficher des modèles pré-formatés et la capacité de capturer des idées en ligne à l’aide de notes post-it numériques signifiaient que nous pouvions exploiter les commentaires de chacun. Là où nous devions travailler sur quelque chose qui émergeait au cours de la conversation, il était facile pour l’animateur de créer et de concevoir un modèle dans l’instant qui puisse répondre aux besoins. Travailler efficacement dans un environnement numérique signifiait que nous pouvions toujours travailler de manière collaborative et avec de bons effets.
Utiliser MIRO et d’autres outils de collaboration en ligne comme TRELLO planner est devenu plus fréquemment la norme maintenant. Cela n’a pas entraîné un ralentissement de la création de produits, au contraire, cela signifie que nous pouvons faire les choses plus rapidement.
Il semble que les ateliers facilités se soient simplement déplacés en ligne !
partagez ce billet avec vos amis, collègues et relations professionnelles
Trois versions de suite du AgilePM® Handbook citent la facilitation comme une technique qui aide à construire l’équipe, à prendre des décisions et à identifier les risques. Cependant, la facilitation est à peine décrite dans le manuel et cet article en présente un résumé et explique comment elle peut être utilisée avec succès dans des projets.
Selon l’une des définitions : « la facilitation est toute action qui rend une tâche facile pour les autres ou une tâche qui est supportée par d’autres ». Le but de la facilitation est de veiller à ce que les réunions et les ateliers soient conçus et menés de manière efficace. Elle permet à l’équipe de prendre des décisions indépendantes, grâce à une personne indépendante, comme un facilitateur. Ce professionnel peut manager correctement les réunions, afin que les participants ne se « nuisent » pas entre eux, mais apprécient les différences d’opinion et en comprennent les avantages.
Qui est le facilitateur ou la facilitatrice ?
C’est une personne qualifiée pour sélectionner le « processus » approprié (formats, modèles, techniques et outils) à la « tâche » (objectif de la réunion).
Ces dénominations semblent plutôt mystérieuses et compliquées et suggèrent que le rôle de facilitateur est difficile. C’est d’autant plus difficile que le facilitateur est censé manifester son impartialité même s’il est impliqué dans le travail ou s’il est émotionnellement dépendant des résultats.
De quoi le facilitateur ou la facilitatrice est-il responsable?
La facilitation met fortement l’accent sur la distinction entre la responsabilité du processus utilisé et la responsabilité de la tâche à réaliser. Comme dans le management de projet, un processus signifie effectuer certaines activités qui mènent à un résultat spécifique. Les normes de management de projet telles que PMBOK® Guide, Praxis Framework,AgilePM® définissent les processus nécessaires pour produire le livrable du projet, mais le livrable ou produit peut être différent pour chacun des projets.
Livre sur Amazon
Le manuel de facilitation (« Facilitation. Develop your expertise » par Tony Mann) ne définit pas le contenu de l’atelier (la « Tâche »), qui peut être différente à chaque réunion, mais il aide à identifier (le « Processus ») qui délivrera le résultat requis. Le résultat requis du management de projet est de livrer le produit dans les contraintes du triangle du projet. Le résultat requis de l’atelier facilité devrait être, par exemple, les risques identifiés, les exigences hiérarchisées en un certain laps de temps. Comme dans le cas du management de projet, la facilitation devrait également inclure les parties prenantes, d’autant plus que l’atelier peut être mis en œuvre en utilisant différents formats.
Nous appelons un « Format » la façon dont les ressources sont utilisées pendant la réunion :
Groupe – signifie que les parties prenantes impliquées travailleront ensemble en groupes,
Tous – signifie que tout le monde travaillera seul,
Tout à un – cela amènera toutes les personnes à travailler ensemble avec un seul support, par exemple un tableau à feuilles mobiles,
Un pour tous – une personne communique avec les autres, par exemple quand ils ont l’expérience, les connaissances à partager.
un pour tous, tous pour un
Deux parties prenantes clés sont mentionnées dans le manuel de facilitation
Leader de tâche – personne responsable de la définition de l’objectif de la réunion, par exemple Manager de projet, Leader d’équipe,
Facilitateur – responsable du processus de l’atelier.
Par conséquent, nous nous attendons à ce que le leader de tâche ait des connaissances spécialisées sur la tâche, et le facilitateur n’a donc pas besoin d’être expert en la matière. Une connaissance spécifique de la tâche pourrait même être un obstacle si le facilitateur voulait s’engager dans la création de la solution, perdant ainsi son impartialité.
Il est peu probable que nous nous attendions à ce que le manager de projet soit le facilitateur, mais nous pouvons nous attendre à ce qu’il assume le rôle de leader de tâche. AgilePM® Handbook suggère clairement que le facilitateur devrait être un rôle distinct et indépendant du manager de projet.
Un facilitateur efficace devrait…
Être orienté sur le changement,
être audacieux, courageux, prendre des risques,
avoir un focus général et être focalisé sur les idées,
être flexible,
être prompt à répondre et à agir,
être orienté processus,
être un catalyseur discret,
être extraverti,
être capable de rester calme sous le stress,
avoir un faible niveau de tension,
avoir une large connaissance des affaires.
Estimation du temps et du coût de la facilitation
Le manager de projet doit trouver une personne adéquate pour remplir le rôle de facilitateur, mais il doit également être en mesure d’estimer le temps nécessaire pour mener les ateliers.
Cependant, il y a ici plusieurs risques car les tâches peuvent avoir différents niveaux d’incertitude.
Avec la certitude que la question à laquelle il faut répondre est claireet que la réponse sera facile à obtenir des participants à l’atelier, il est plus facile d’estimer le temps nécessaire. Cette durée estimée sera alors généralement suffisante pour atteindre les objectifs de la réunion.
Lorsqu’il s’agit de complexité, c’est-à-dire que la question est claire, mais que la réponse n’est pas encore connue, le temps estimé à l’origine peut être plus que doublé pendant l’atelier.
Et enfin, lorsque nous avons affaire à l’incertitude (la question/problème est inconnu et doit d’abord être compris pour trouver une réponse ou une solution), le temps réel de l’atelier lui-même peut être jusqu’à 4,5 fois plus long.
De plus, le rôle de facilitateur est de bien manager le « triangle d’or de la facilitation ». Comme dans le cas du « triangle de projet », où les « portée-délais-coûts » restent en équation les uns par rapport aux autres, dans le cas de la facilitation, nous avons un triangle interdépendant « tâche-temps-maturité du groupe ».
Cela signifie que le temps des ateliers dépend de la tâche (que nous connaissons dans le management de projet comme la portée) et de la maturité du groupe/processus, c’est-à-dire de la difficulté de mettre en œuvre une tâche donnée. Cependant, le niveau de difficulté ne peut être estimé que par un facilitateur expérimenté. Cela signifie que le manager de projet (comme dans le cas de l’estimation d’autres tâches du projet) doit utiliser l’aide d’un facilitateur expérimenté pour planifier des ateliers. Cela signifie aussi que la logistique des ateliers (emplacement, équipement) affectera le budget du projet.
QRP est partenaire de DantotsuPM
En résumé
Un facilitateur expérimenté (comme un manager de projet expérimenté) utilise un processus afin que d’autres personnes puissent atteindre les objectifs. Ce sont les compétences et l’expérience du facilitateur (comme dans le cas du manager de projet) qui déterminent l’efficacité avec laquelle il ou elle gère la sélection des outils appropriés et l’ajustement du processus aux exigences de la tâche. La facilitation (un peu comme le management de projet) est une activité professionnelle différente. La responsabilité du manager de projet est d’aller chercher et de motiver un professionnel suffisamment expérimenté pour obtenir des résultats d’atelier satisfaisants.
partagez ce billet avec vos amis, collègues et relations professionnelles
Consultez le livre blanc Agile Kata white paper sur www.agilekata.org.
Les problèmes cachés ne s’améliorent pas. Dans un monde hyper-connecté, il n’y a aucune raison technique pour que le chef de projet ne sache pas ce que l’équipe sur le terrain sait de l’état du projet.
Comme plusieurs sujets sont en cours de traitement, vous vous retrouvez soudainement à limiter l’impact sur plusieurs sujets. Et cela signifie des efforts d’atténuation multiples : moins de temps pour travailler, et en même temps un risque plus élevé que toutes les mesures d’atténuation ne réussissent pas. Vous vous retrouvez avec une probabilité plus élevée de ne pas être en mesure de revenir sur les rails !
L’effet des répercussions en chaine dans l’organisation et des mesures d’atténuation pourraient entraîner des conséquences imprévues qui sont encore plus difficiles à prévoir que l’événement déclencheur. Dans de nombreux cas, la seule solution possible est de dire stop et de marquer tous les sujets commencés comme retardés, puis d’essayer de réparer la casse à partir de là.
Parce qu’il n’y a pas de marge de temps intégrée dans la planification Tetris, le plan à mi-parcours échouera automatiquement dès qu’une seule fonctionnalité s’avère plus complexe que prévue. Plus les fonctionnalités font partie de notre pile Tetris, plus il est probable qu’au moins l’une d’entre elles échouera. Et l’équipe sera généralement blâmée pour cela. Pour cette raison, nous nous retrouvons avec…
Avec Planning Tetris, cette opportunité n’existe pas car il y a toujours une autre fonctionnalité en attente et améliorer quelque chose qui existe est toujours moins important que de livrer la prochaine grande chose. Cela finit souvent dans des produits ratés qui ne sont pas un plaisir ni pour les développeurs ni pour les clients !
DantotsuPM.com 