Cela commence par “Pourriez-vous juste … ?”, “En ce qui concerne …” ou “ne me tuez pas, mais … ?”. Ce qui vient est ensuite une nouvelle idée, fonctionnalité, ou demande qui n’a pas été abordée auparavant. Cette conversation arrive tout le temps et cause beaucoup de bougonnement sur “la dérive de contenu”.
Mais si vous considérez l’étude et la découverte comme étant des parties naturelles du processus de développement de logiciel, il n’existe pas de dérive de contenu. C’est seulement un changement mal managé.
Nous ne savons pas de quoi nous avons besoin quand nous commençons. De nouvelles choses surviennent toujours . Le client a besoin de changement. Le marché force le changement. Des personnes à l’extérieur de l’équipe trouvent de nouvelles idées. Les gens dans l’équipe ont de nouvelles idées. Ce changement constant est la seule chose sur laquelle nous pouvons compter. Donc arrêtons de feindre de pouvoir l’arrêter et améliorions-nous dans bien le manager.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
Appréciez l’apprentissage
Un des problèmes avec la terminologie « dérive de contenu » est qu’elle implique que nous n’avons pas fait assez bien notre travail. Elle implique que quelqu’un, quelque part, a failli et si nous étions de meilleurs managers, ce ne serait pas arrivé. Nous aurions prévu toutes les demandes possibles ou nous aurions la force ou la capacité de dire « Non » à chaque fois quelqu’un a une nouvelle idée. Elle implique que la dérive de contenu est un monstre effrayant qui doit être tenu éloigné par un chef de produit toujours vigilant qui garde jalousement la porte de grange.
Cela décourage le changement et l’apprentissage. Une des leçons du mouvement de développement de logiciel Agile est qu’il n’y a aucune façon fiable de spécifier à l’avance ce que nous devons construire. Apprendre sur les besoins est nécessaire pour pouvoir converger sur une solution idéale.
L’équipe de développement doit apprendre ce qui est possible en fonction des contraintes des outils et de la technologie disponible. Les chefs de produit doivent valider leurs suppositions sur quelles fonctions ou technologies particulières sont les plus susceptibles de répondre à un besoin, tandis que les consommateurs du produit ne savent souvent pas vraiment ce qu’ils veulent avant qu’ils ne le voient.
Nous pouvons penser qu’une solution donnée sera idéale quand nous la considérons sur le papier ou sur un tableau blanc, mais quand nous mettons une application entre les mains d’un utilisateur, nous obtiendrons toujours une compréhension nouvelle et plus profonde de ce qu’est la « bonne » chose à construire. Apprendre est quelque chose qui doit être recherché et pas craint.
Le management du changement est une compétence
Une équipe de développement a une capacité fixée et aucune quantité de désirs, de pressions ni de contraintes ne générera de production plus significative. Au lieu de cela, la gestion du changement réussie est l’art d’optimiser le travail qui est fait avec cette capacité.
Cela commence par un processus pour rassembler toutes les nouvelles idées, demandes et choses apprises à travers toute votre organisation. Des modèles apparaîtront, montrant quelles nouvelles choses sont les plus importantes. Le management du changement n’a pas pour objet d’agir sur toutes ces idées; il s’agit plutôt de trouver l’équilibre entre être réactif et disruptif.
Si nous avons un processus robuste pour gérer notre capacité, nous pouvons considérer autant de nouvelles idées que nous voulons, sachant que le processus exigera que nous nous engagions seulement sur ce que nous pouvons raisonnablement faire. Les équipes arrêtent de craindre la dérive de contenu quand elles se rendent compte que de nouvelles idées ne signifient pas automatiquement des nuits plus courtes.
Certaines nouvelles idées qui surgissent sont suffisamment bonnes pour remplacer de vieilles idées. Certaines ne sont pas aussi bonnes que ce que nous avons déjà, et nous devrions y renoncer. Et parfois l’union d’une vieille idée avec une nouvelle crée quelque chose de magique.
Finalement, nous avons besoin d’un rythme raisonnable pour considérer de nouvelles idées et changer de direction. Si une équipe consomme une grande partie de son temps chaque jour à considérer de nouvelles choses, elle fait probablement peu de progrès sur le livrable. Plusieurs méthodes agiles spécifient une période courte pendant laquelle aucun changement de ce sur quoi l’équipe travaille n’est permis. Mais tout est alors à prendre en considération aux frontières de cette courte période de temps.
La dérive de contenu est un ennemi imaginaire
Nous n’avons absolument ni le temps ni les ressources pour agir sur toutes les bonnes idées qui sont déposées sur la table pendant le déroulement du projet. Mais agir sur quelques-unes de ces idées peut être essentiel.
Alors, la prochaine fois une nouvelle demande arrive, arrêtez-vous et considérez-la. Cette dérive de contenu à laquelle vous avez résisté pourrait juste être la chose qui fait réussir votre projet.
partagez ce billet avec vos amis, collègues et relations professionnelles
Quand Henry Ford a conçu ses usines en 1913 pour construire la Modèle T, il a réduit le temps nécessaire pour assembler une voiture de plus de 12 heures à 2 heures 30 minutes. Ce processus a permis la production d’une automobile à prix ciblé pour “le travailleur”. Toutes les voitures avaient la même conception et toutes étaient peintes en noir.
Les designs préconfigurés fonctionnent quand les prévisions rencontrent les attentes (qui en 1913 aurait demandé une voiture rouge ?) et quand un spécialiste peut remettre son travail au suivant sans aucune perte de temps dans la transmission.
Quand une société est dans le business de produire des produits et des services innovants, ses plans reposent sur une ou plusieurs estimations et suppositions. Ces évaluations ne sont rien de plus que des probabilités. Baser un plan de projet sur des suppositions exige que votre système puisse manager les changements.
Livre sur Amazon
Marie Poppendieck a exposé dans Lean Software Development, An Agile Toolkit, “le simple fait mathématique ici au travail est que toute variation est toujours amplifiée comme elle déplace le long d’une chaîne d’événements connectés. Une petite variation dans une étape peut représenter une énorme variation cinq étapes plus loin”. Donc la question reste entière quant à pourquoi les managers continuent à planifier des projets en se basant sur des suppositions séquentielles.
Pour comprendre comment un changement inattendu peut causer des retards significatifs en aval, visualisez une chaussée très occupée avec des voitures se déplaçant selon la limitation de vitesse. Le trafic s’écoule régulièrement jusqu’à l’entrée d’un nouveau véhicule ou autre événement qui fasse qu’un conducteur actionne ses freins. Le trafic sur la chaussée ralentit ou s’arrête alors pendant une brève période puis recommence à s’écouler de nouveau sans signe apparent de pourquoi il a ralenti en premier lieu. L’exemple de cette route illustre comment, à moins que les systèmes ne soient conçus pour se concentrer sur le flux, ils ne fonctionneront pas efficacement à pleine capacité. Parce que le développement de logiciel est un effort complexe dans lequel les suppositions et les décisions devraient être prises le plus tard possible. Le fait de prendre des décisions au dernier moment possible permet à l’équipe Scrum de changer pour travailler sur les articles d’arriéré de produit de plus de valeur en fonction des données les plus récentes.
CertYou est partenaire de DantotsuPM
L’empilement de beaucoup de suppositions l’une après l’autre dans un plan de projet réduit significativement la probabilité d’un résultat positif.
Par exemple, considérez cinq tâches tout d’une probabilité de 90 % d’achèvement en une semaine: (0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.59). Dans ce cas, nous avons cinq tâches sur lesquelles nous nous sentons confiants, mais le résultat cumulatif est que nous sommes à seulement 59 % de probabilité de finir ces cinq tâches en cinq semaines. Je soutiendrais que basé sur mon expérience de professionnel en management de projet, il est aussi peu probable que cinq tâches séquentielles atteignent jamais chacune un niveau de confiance de 90 %. Alors, êtes-vous encore étonné quand vous lisez Standish Group’s Chaos Report qui indique qu’approximativement 70 % de tous les projets des technologies de l’information échouent à atteindre leurs objectifs et sont significativement en retard et sur-dépensent ?
Ceci n’empêche pas que vous devriez adorer les statistiques 🙂
La meilleure façon d’optimiser la livraison de valeur est de faire des tâches ajoutant une valeur visible pour les parties prenantes. La documentation de chaque flux de valeur mettra en évidence l’avancée et les retards entre les transitions. En évaluant quantitativement des activités du flux de valeur, le coût des retards devient aussi visible. Cette visibilité aidera l’organisation à déterminer où la constitution d’équipes fonctionnelles transverses améliorera immédiatement les temps de réponse.
L’utilisation de Scrum pour rendre ces inefficacités visibles est seulement le premier pas.
Le leadership a-t-il le désir et l’engagement d’effectuer le changement ? Craig Larman, l’auteur des Laws of Organizational Behavior, a observé que les organisations sont implicitement optimisées pour éviter de changer les positions de statu quo et les structures de pouvoir. Il a aussi noté que si vous voulez changer la culture d’une société, vous devrez changer la structure de votre organisation parce que la culture/comportement et la mentalité suivent les systèmes organisationnels et leur design.
Les organisations comme des sociétés d’assurance et banques ont typiquement les silos de spécialisation fortifiés autour des applications, technologies et fonctions. Chacun de ces départements a développé des règles soigneusement travaillées et des procédures interdisant le changement. Ces processus administratifs ont pour conséquence fortuite de perturber le flux de valeur qui va du concept à la livraison au client.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
Marie Poppendieck a décrit cette situation Lean Software Development: An Agile Toolkit, “la règle établie pour résoudre un problème renforcera souvent le problème, créant une spirale vers le bas : Comme un problème empire, les managers appliquent encore plus agressivement la même politique qui cause le problème.” La mise en place d’équipes fonctionnelles transverses qui ont toutes les compétences pour achever le travail sans avoir à traverser des silos fonctionnels aura un impact étonnamment positif sur la capacité des organisations d’améliorer la qualité et le temps nécessaire pour commercialiser.
Votre direction a-t-elle le courage et l’engagement d’entreprendre le dur labeur d’éliminer les processus et les procédures qui n’ajoutent pas de valeur ?
La plupart des sociétés considérant l’adoption de Scrum devront changer leurs structures organisationnelles pour soutenir des équipes fonctionnelles et transverses autonomes. Si la structure organisationnelle ne change pas, les comportements ne vont pas probablement changer. Si votre modèle business dépend de l’innovation, ce changement devrait être d’une priorité supérieure.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les démonstrations ou « showcase » comme elles sont parfois appelées, sont des cérémonies critiques quand elle sont menées efficacement car elles adressent des objectifs multiples du projet en un événement simple incluant :
Valider que ce que l’équipe a achevé jusqu’à présent est de valeur de la perspective de leur client et d’autres parties prenantes importantes
Aider l’équipe et les parties prenantes à changer ou développer leur compréhension de la solution souhaitée
Obtenir l’acceptation des parties de travail achevées dans les organisations où une telle signature est un préalable exigé pour mettre en œuvre le changement
Faciliter un rapport d’avancement transparent car les parties prenantes voient ce qui a été promis par l’équipe et ce qui a été livré
Fournir aux membres d’équipe des retours réguliers et une reconnaissance de leur travail , ce qui augmente les niveaux de satisfaction au travail et l’engagement
Mais les démonstrations peuvent (comme d’autres pratiques de management de projet) aboutir à un résultat pire que si elles avaient été omises.
Voici quelques-unes des choses à faire et ne pas faire pour accroître la valeur que votre équipe tirera des démonstrations.
A faire : Envoyez les invitations pour la rencontre à l’avance et si vous suivez une cadence de sprint ou d’itération standard (par exemple toutes les deux ou trois semaines). Envoyez un jeu d’invitations récurrentes.
A ne pas faire :Les démonstrations le vendredi après-midi afin d’éviter d’avoir les parties prenantes absentes de corps ou d’esprit.
A faire :Partagez la richesse en vous assurant que chaque membre de l’équipe ait son opportunité de présenter une démonstration.
A ne pas faire :S’en servir pour vous plaindre de l’équipe, des points de blocage ou ce qui aurait pu ou dû être fait différemment.
A faire :Fournissez objectivement le contexte sur le sprint ou résultats itératifs (par exemple le prévu versus le réalisé).
A ne pas faire :Présenter une démonstration sans avoir testé à l’avance ce que vous allez montrer.
A faire :Invitez les représentants du client et parties prenantes associées appropriées à vos démonstrations.
A ne pas faire :Submerger vos parties prenantes de contenu.
A faire : Enregistrez les présentations à l’avance ou, si vous vous sentez chanceux, pendant la démonstration elle-même pour le bénéfice de parties prenantes qui ne pourraient se libérer.
A ne pas faire : Prendre les retours négatifs personnellement.
Bien que cet article soit principalement destiné aux équipes qui utilisent une approche de développement Agile, il est également applicable aux projets traditionnels. Les démonstrations éblouissantes peuvent aider à maintenir l’attention, conserver l’appui de votre client et maintenir les membres de l’équipe concentrés sur délivrer de la valeur.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
La Scrum Alliance était le premier organisme de Certification Scrum, fondée en 2002. Elle offre une gamme de Certifications Scrum, la plus populaire étant le Certified Scrum Master (CSM). Il y a actuellement plus de 400000 CSMs dans le monde. Le CSM est une certification de niveau d’entrée. Pour obtenir le CSM vous devez suivre une formation de 2 jours donnée par un Certified Scrum Trainer (CST) et réussir ensuite un test en ligne avec le livre ouvert. Pour trouver une formation proche de vous, allez sur le site de la Scrum Alliance. Les tarifs des cours varient selon la région et le fournisseur. Si vous considérez cette certification, la meilleure approche est d’acquérir quelques mois d’expérience avant d’y aller. Ainsi, vous saurez quelles questions poser et les parties sont les plus difficiles pour vous.
La Scrum Alliance offre aussi une certification de niveau d’entrée pour des Propriétaires de Produit appelés le Certified Scrum Product Owner (CSPO). Un cours de 2 jours donné par un CST. Actuellement, il n’y a pas de test sur le CSPO.
Certified Scrum Product Owner offre un parcours de certification avec Certified Scrum Professional (CSP), Certified Scrum Coach (CSC), Certified Enterprise Coach (CEC), Certified Agile Leader (CAL) et Certified Scrum Trainer (CST) pour ceux avec plus d’expérience. Vous pouvez en découvrir davantage sur ces programmes sur le site de la Scrum Alliance.
Ken Schwaber a quitté la Scrum Alliance et formé Scrum.org en 2009. Ils offrent maintenant des certifications Scrum. Vous pouvez passer la certification Scrum.org en ligne sans suivre de formation. La certification Scrum.org est appelée Professionnel au lieu de Certifié. PSM au lieu de CSM. Il y a des niveaux multiples sur chacune des certifications de Scrum.org, c’est-à-dire PSM I, II et III. Il y a actuellement plus de 75000 I PSM, 600 PSM II et 360 PSM III dans le monde. On considère le PSM comme l’équivalent du CSM.
Vous pouvez passer les évaluations sans suivre aucun cours, mais il y a un coût à prendre l’examen. Scrum.org offre aussi un Professional Scrum Product Owner (PSPO). Les prix des cours varient par région et formateur.
Listée en dernier parce que ce n’est pas une certification spécifique à Scrum, il y a l’offre du PMI : le Praticien Certifié Agile (PMI-ACP). Actuellement il y a 17000 détenteurs de la certification PMP-ACP. C’est une offre agile semblable au PMP dans la gestion de projet traditionnelle. Elle exige la preuve tant d’expérience de gestion de projet traditionnelle que d’expérience agile et il faut réussir une évaluation dans un centre d’examen autorisé.
Pour tous les détails (en anglais)
Bien qu’il n’y ait aucun cours spécifique exigé, 21 heures de formation sont requises. Comme avec le PMP, il y a des cours préparatoires disponibles pour fournir les heures de formation nécessaires et couvrir le matériel que vous devez connaitre.
CertYou est partenaire de DantotsuPM
“PMI,” the PMI logo, “PMP,” “Project Management Institute” and “PMI-ACP” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans cet article, l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et Agile.
Serhiy Kharytonov
Selon Serhiy Kharytonov, le choix entre les méthodes « en cascade », RUP (rational unified process) et agile, dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dispersion géographique de l’équipe.
Une combinaison des trois méthodes selon les moments du cycle de développement pourrait être une bonne approche.
Cet article qui date pourtant de presque dix ans reste étonnamment actuel.
Utilisez vous d’autres critères de choix de votre approche de développement?
Waterfall, RUP et Agile : quelle est la bonne méthode de développement logiciel pour vous?
Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mix de stratégies de développement logiciel afin de répondre aux besoins spécifiques de votre projet.
Malgré les signes de reprise dans l’économie, une réalité persiste dans le développement logiciel: La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible.
Pour atteindre ces objectifs apparemment contradictoires, les développeurs cherchent à rationaliser la production avec des processus rapides et efficaces qui peuvent donner au client ce qu’il veut en un laps de temps le plus court possible.
Ces constantes et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel souvent appelées le modèle Waterfall / « en cascade », vers des modèles plus itératifs et progressifs tels que « Rational Unified Process » et « Agile. »
Les partisans d’Agile sont nombreux et il peut parfois sembler que les processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, leurs incovénients et leurs environnements de projet favoris.
Au bout du compte, la meilleure méthode ou le meilleur mix de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, votre culture business et votre propre environnement de développement.
Waterfall / « En cascade »
La programmation « en cascade » est un processus fortement structuré qui compte fortement sur une planification initiale et un ensemble d’étapes séquentielles, prescrites qui découlent l’une de l’autre comme l’eau dans une une cascade. Chaque étape a typiquement sa propre équipe d’experts et jalons soigneusement préparés à l’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète avec des résultats qui sont fortement prévisibles. On appelle aussi souvent cette approche le cycle en « V ».
Typiquement les étapes dans le développement « en cascade » sont :
Recueil des besoins et rédaction du cahier des charges
Analyse fonctionnelle
Développement du code
Intégration
Test et mise au point
Installation
Maintenance
Ceci peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.
Les détracteurs disent que le « Waterfall » demande simplement trop longtemps et manque de la flexibilité, ou de l’agilité, requise pour le marché logiciel actuel avec son environnement de développement en constant mouvement. Les projets qui suivent la méthode « en cascade » prennent typiquement des mois ou des années et quand ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut alors être des corrections onéreuses explosant le budget initial.
RUP (rational unified process)
Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin de répondre au changement et introduit de l’adaptabilité pendant le processus de développement.
Comme la « cascade », RUP a une série de phases et des jalons qui découlent l’un de l’autre :
L’initiation, où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
La construction, où le logiciel est construit et testé et la documentation de support est produite.
La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.
RUP définit en détail les rôles et les activités de membres de l’équipe et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que de grandes quantités de documentations requises pour chaque étape « Waterfall ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de guides, modèles, outils et autres articles pour s’assurer qu’ils partagent les mêmes langages et perspectives sur le projet.
Alors que cela apparaît de prime abord similaire au développement « en cascade », la plus grande différence du RUP est son approche de développement itérative, qui construit le produit en plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin, de l’architecture et l’exploration de différentes idées, alors que les itérations ultérieures essayent d’assembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.
Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours utilisateurs.
RUP adresse bon nombre des critiques du développement « Waterfall » et c’est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » les développements dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.
Les critiques disent que RUP n’est pourtant pas aussi rapide ni adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial et là où l’on s’attend à des mises à jour fréquentes et des compléments rapides de fonctionnalités.
Agile
Tandis que « Waterfall » et RUP penchent vers la prédictibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, dont XP et SCRUM, et tous s’efforcent de mettre une version du produit basique mais fonctionnelle entre les mains du client aussi vite que possible.
Ils font alors suivre cette version par des versions successives qui ajoutent et changent les fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes périodes de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme en « Waterfall » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.
Plutôt que de dépendre d’équipes composées de nombreux experts, le processus de développement Agile est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La constante collaboration en face à face est l’objectif, avec le représentant du client comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à l’approche « Waterfall » et même RUP pour sortir quelque chose aussi rapidement que possible.
Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement des besoins et réponses aux challenges amenés par la compétition, qui sont les raisons de tant de partisans.
Certaines sociétés sont fréquemment citées comme ayant utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont apporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.
Mais même s’il est facile de tomber amoureux d’Agile, l’approche a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rend le processus difficile à adapter à l’externalisation des développements, à des situations où clients et développeurs sont géographiquement éloignés, ou aux clients qui n’ont tout simplement pas les compétences, les ressources ou le focus nécessaires.
Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas aux clients qui veulent des contrats avec des évaluations fermes et définitives et des échéanciers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec de très nombreuses parties prenantes aux besoins différents et néglige de prendre en compte le besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.
De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec le « Waterfall » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.
CertYou est partenaire de DantotsuPM
Le meilleur de chaque monde
Si Agile, RUP et des modèles « en cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret des développements logiciels réussis est de comprendre les trois processus dans le détail et de sélectionner les parties de chacun qui conviennent le mieux à leurs livrables et environnements spécifiques. Donc, être agile dans l’approche même du choix du processus, en regardant sans cesse ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux aux circonstances actuelles.
Par exemple, si vous développez du logiciel « Software as a Service » SaaS dans un marché fortement concurrentiel, vous ferez probablement le meilleur choix en penchant vers des méthodologies Agile. Le SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour y ajouter ou en changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateurs changeants, vous voudrez probablement être capables d’apporter rapidement des changements.
D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou autres systèmes qui exigent un haut degré de design et de certitude, alors il semble logique de commencer par du »Waterfall ».
Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui vont être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière sur le recueil des besoins, la définition du périmètre et du contenu au tout début, ainsi que des standards de parcours et d’interface utilisateur.
Quel est le meilleur de chaque approche que vous puissiez utiliser sur votre projet ?
Les développeurs peuvent tout de même utiliser des techniques Agile pour présenter des prototypes fréquents et des modules successifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de la société (selon que ces équipes soient plus ou moins habituées à une telle collaboration). Quand la distance géographique est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.
Ce même mélange de techniques peut être utilisé dans un environnement d’externalisation du développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contacts de suivi que possible pour votre projet.
Choisir de partir sur des équipes auto-organisées ou une approche plus directive (« top-down ») de management dépend aussi du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leadership qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins lors des itérations suivantes.
Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et tous les environnements, ni même pour un seul.
C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement.
Bref, en choisissant entre Agile, RUP et « Waterfall », adaptez le processus à vos besoins, plutôt que de chercher à adapter votre projet au processus !
partagez ce billet avec vos amis, collègues et relations professionnelles
Si Scrum est la méthodologie Agile la plus largement utilisée, Kanban devrait être en seconde place. Ça existe depuis longtemps, c’est élégant, c’est efficace, c’est simple et ça marche. Beaucoup de gens utilise Kanban en conjonction avec Scrum. Ils appellent parfois cette « Scrum-ban ». Quelques personnes utilisent juste quelques idées de Kanban, certaines un mélange à 50/50 des deux et d’autres uniquement Kanban. Pas de Scrum du tout. Cet article expliquera quand utiliser Kanban ou Scrum. Cela dépend vraiment de quel type de travail vous faites.
scrumban board
Cependant, beaucoup d’équipes utilise juste deux ou trois des idées de base de Kanban, plutôt que la totalité. Kanban est bien comme ça. Vous pouvez facilement ajouter, choisir les parties que vous aimez et laisser celles qui ne vous conviennent pas. Scrum ou la Programmation Extrême ne sont pas aussi flexibles. Elles n’ont pas tendance à bien fonctionner si vous n’en prenez que deux ou trois particules aléatoires. Elles sont un système logique. Kanban n’est pas vraiment un système logique, c’est juste un jeu de principes pour visualiser et améliorer le travail. Choisissez ceux que vous aimez. Ou utilisez-les tous!
D’abord, passons les différences principales entre les méthodes.
Scrum est avant tout itérations
Voici le diagramme du Modèle Scrum
Le focus principal dans Scrum est sur les itérations. Une itération est une courte unité fixe de temps. Scrum appelle ces itérations « des sprints ». Un sprint dure d’habitude deux, trois ou quatre semaines. Vos sprints doivent tous être de même durée. Vous ne pouvez pas avoir un sprint légèrement plus long ici et un sprint plus court là. Ce serait tricher. Le principe est d’entrer dans un modèle prévisible de livraison de travail. L’équipe exécute une planification fréquente et des revues et rétrospectives fréquentes. Cela permet à l’équipe de prévoir et planifier le travail qui sera fait sur les deux prochains sprints.
Kanban est avant tout états de travail
Dans Kanban, il n’y a aucun sprint. Il n’y a aucune itération. Il ne s’agit pas tellement de temps et de prévisibilité, il s’agit plutôt de travail. Le focus dans Kanban est dans le découpage et la visualisation de petits articles de travail. Vous dressez alors la carte des articles de travail sur des états spécifiques du travail. Essayer de placer peu d’articles de travail dans n’importe quel état particulier et aussi peu d’articles de travail possible comme bloqués. Vous pouvez aussi imposer des “limites WIP ” (nombre d’items « work in progress » donc de travail en cours) dans chaque état. Cela signifie que vous ne pouvez pas avoir plus qu’un certain nombre d’articles dans un état particulier. L’objectif est d’avoir un flux de travail lissé à travers tous ces états.
Scrum est bon pour suivre le progrès et planifier
Scrum est une bonne structure pour le travail de développement de fonctionnalités. Pour le travail où vous avez une pile de fonctionnalités à construire et vous devez planifier grossièrement combien de temps il faudra pour les construire et quand elles pourraient être finies. On utilise des sprints de durée fixe donc vous pouvez mesurer votre progrès comme vous avancez et déterminer votre vélocité. La vitesse vous aidera à projeter combien de temps il faudra pour finir tout le travail. Souvenez-vous, la vélocité est pour qu’une équipe pour fasse son propre planning, pas pour qu’un manager mesure la productivité.
Alors, en résumé, Scrum est bien adapté pour réaliser un travail de développement parce que :
Le travail est composé de grosses parties vagues qui peuvent alors être décomposées en item de fonctionnalité spécifiques plus petits
Le travail fait généralement partie d’une série encore plus grande de buts à long terme (« des releases » ou « des horizons »)
Les délais fixes et limités, les timeboxes, vous laissent mesurer votre taux de progression
Les délais fixes et limités et un taux de progression signifient que vous pouvez planifier vers les objectifs à long terme.
Kanban est bon pour le flux et la quantité livrée
Get the book for free on line
Kanban est bien adapté à un travail où il n’y a pas de gros arriéré de fonctionnalités à développer. L’attention est plutôt sur livrer rapidement de petits items de travail comme ils arrivent. Un exemple usuel est celui d’une équipe assignée à résoudre des incidents de production. Kanban fonctionne vraiment bien ici parce que :
Le travail surgit devant l’équipe (c’est-à-dire poussé vers elle, basé sur la fourniture) plutôt que tiré par l’équipe (c’est-à-dire basé sur la demande)
Le travail est composé de petits composants distincts qui ne sont pas d’habitude connectés à d’autres composants de travail
Il n’y a aucun objectif à long terme ou but à atteindre
La planification est sans importance ou sans rapport.
Et si vous voulez utiliser les deux ?
Eh bien, bonne nouvelle, vous pouvez. En fait, la plupart des personnes le font. Les équipes de développement de logiciel les plus agiles utilisent Scrumet beaucoup d’entre elles utilisent au moins certaines (mais pas toutes) les idées de Kanban. La plus commune est celle des colonnes sur le tableau de visualisation Kanban. Elles sont si fréquemment utilisées que je les prends pour acquises et oublie souvent qu’elles ne sont mentionnés nulle part où dans Scrum ! C’est aussi une pratique commune que d’utiliser quelques autres idées des tableaux de visualisation Kanban comme des avatars et de marquer les histoires bloquées.
Alors, quand utiliser Kanban ou Scrum ?
En résumé, vous devriez :
Utiliser Scrum (ou quelque chose de similaire) pour le travail de développement de fonctionnalités avec des gros objectifs de livraison ou des jalons importants
Utiliser Kanban (ou similaire) pour les petites items de travail entrant dans l’équipe comme la réparation de bugs ou de petites demandes d’améliorations
Mais ne pas hésiter à les combiner, en particulier en adoptant Scrum, mais en appliquant certaines grandes idées Kanban comme les tableaux de visualisation.
J’espère que cela aide à éclaircir les choses!
CertYou est partenaire de DantotsuPM
Une petite vidéo de 6 minutes en anglais pour exposer comment appliquer certains des principes de Kanban à Scrum.
partagez ce billet avec vos amis, collègues et relations professionnelles
Agile, c’est le développement itératif et progressif et la livraison fréquente avec un changement culturel vers la transparence.
Itératif signifie que nous prenons « un morceau à la fois » pour créer une fonction entière. Des approches itératives gèrent le risque technique. Nous apprenons du risque comme nous réitérons à travers le jeu entier des fonctionnalités.
Progressif signifie que nous livrons des portions de valeur. Les approches progressives managent le risque de planification, parce que nous délivrons un travail fini à chaque étape.
Book on Amazon
Agile fonctionne parce que nous manageons les risques techniques et ceux de planification. Nous réitérons sur un jeu de fonctionnalités, livrant de gros incréments de valeur. (Une raison pour livrer de la valeur souvent et que nous pouvons ainsi changer ce que l’équipe va faire ensuite).
Prenons l’exemple d’un jeu de fonctionnalités appelé: “l’établissement d’une connexion sécurisée”.
Personne ne veut avoir à s’identifier pour se connecter. Mais, les gens veulent avoir une forte sécurité pour leur paiement. Hors, l’établissement d’une connexion sûre peut être une façon d’arriver à garantir le paiement. Le thème, ou ce que j’appelle un jeu de fonctionnalités, est “l’établissement de la connexion sécurisée”. Un jeu de fonctionnalités, ce sont plusieurs fonctions reliées qui livrent un thème.
Si vous voulez réitérer sur le jeu de fonctionnalités, vous pourriez livrer ces incréments de valeur :
L’utilisateur existant déjà peut se connecter.
Les utilisateurs peuvent changer leur mot de passe.
Ajouter le nouvel utilisateur comme utilisateur.
Ajouter le nouvel utilisateur comme admin.
Empêcher des utilisateurs indésirables de se connecter : bots, certaines adresses IP, ou un emplacement physique. (3 histoires séparées.)
Si vous mettez en œuvre la première histoire, vous pouvez utiliser un fichier à plat. Vous pouvez toujours utiliser un fichier à plat pour la deuxième histoire. Une fois que vous commencez à ajouter plus de 10 utilisateurs, vous pourriez vouloir passer à une sorte de base de données. Ce serait une autre histoire utilisateur. Ce n’est pas “Créer une base de données.” L’histoire serait “Explorer des options pour permettre d’ajouter 10, 100, 1000, 10000 utilisateurs à notre site et voir quelles sont les implications en matière de performance et de fiabilité.”
Remarquez « explorer » comme une partie de l’histoire. Cela pousserait à produire des options que l’équipe puisse discuter avec le Product Owner. Certaines options ont des implications à l’exécution.
Chaque fois l’équipe réitère sur le jeu de fonctionnalités, elle livre un incrément. Puisque beaucoup d’équipes utilisent des durées de temps fixes (timebox), elles utilisent « des itérations » comme leur timebox. (Si vous utilisez Scrum, vous utilisez des sprints.) Remarquez les mots “réitère sur le jeu de fonctionnalités.”
Dans des cycles de vie progressifs, comme la livraison par étapes, l’équipe finirait toutes les fonctionnalités dans un jeu de fonctionnalités donné. Les cycles de vie incrémentaux n’ont pas nécessairement à utiliser des timeboxes pour livrer leur développement progressif. Dans les cycles de vie itératifs, comme spiral ou RUP, l’équipe développerait des prototypes de fonctionnalités, ou même finirait partiellement des fonctionnalités, mais l’intégration finale et les tests n’arrivent qu’après que tout le développement itératif ait été fait.
Dans Agile, nous réitérons sur un jeu de fonctionnalités, livrant la valeur progressivement.
Si vous ne finissez pas vos histoires, vous êtes dans un cycle de vie itératif. Si vous ne limitez pas les fonctionnalités que vous finissez et ne les terminez pas « toutes », vous êtes dans un cycle de vie progressif.
Il n’y a pas de bonne façon de choisir un cycle de vie pour votre projet. Si vous voulez utiliser agile, vous réitérez sur un jeu de fonctionnalités sur un bref cycle de temps, livrant de gros incréments de valeur.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le 7 Novembre dernier, Jeff Sutherland et Ken Schwaber ont été interviewés sur la toute dernière révision du Scrum Guide.
La première partie est consacrée à un bref retour en arrière sur la genèse de Scrum et sa très rapide adoption pour atteindre aujourd’hui:
90% des équipes Agile utilisent Scrum
90% des équipes Agile utilisent Scrum
12 millions de personnes participent à des Daily Scrum meetings
Dans tous les pays
Dans toutes les industries et de nombreuses organisations gouvernementales
Puis, certaines des mises à jour du Scrum Guide 2017 sont discutées plus en détail:
L’utilisation de Scrum en dehors de l’informatique.
Les précisions sur le rôle de ScrumMaster qui est parfois mal interprêté alors qu’il s’agit avant tout de faire la promotion de Scrum et supporter son adoption dans l’entreprise en aidant au changement vers Scrum, ses bonnes pratiques, ses valeurs, ses règles.
12 millions de personnes participent à des Daily Scrum meetings
Il était aussi nécessaire de réitérer l’objectif des Daily Stand Up meetings trop souvent utilisés comme des rapport d’avancement alors qu’il s’agit de voir où l’on en est et décider d’actions adaptatives pour atteindre l’objectif du Sprint, pour passer les items du Sprint Backlog à « Done ».
Une autre incompréhension levée par cette mise à jour concerne les activités « timeboxées »,i.e. limitées dans le temps. Les durées proposées par Scrum sont maintenant clairement identifiées comme des durées maximales, et non obligatoires ni nécessaires.
Enfin, l’importance de la prise d’action suite à la rétrospective de Sprint se matérialise par l’obligation d’avoir au moins une histoire permettant d’améliorer les process par Sprint.
Plusieurs questions récurrentes sont également abordées:
Scrum s’applique-t-il seulement au domaine du développement de logiciel ?
Est-il nécessaire d’attendre la fin du Sprint pour livrer ?
Comment Scrum et DevOps peuvent-ils travailler ensemble ?
Il semble que tout le monde utilise Agile pour manager des projets de nos jours. Et il y a de grandes chances si vous questionnez vos contacts professionnels que vous constatiez qu’une certaine forme d’Agile dirige leur travail. À Think Brownstone, nous travaillons souvent étroitement avec des clients en tant que membres de leurs équipes projet Agile (tant comme experts UX que développeurs). Nous avons pu adapter nos méthodes Agile pour aider les clients à lancer avec succès des produits en permettant un processus flexible pour notre équipe.
Ci-dessous, je partagerai les 5 astuces qui nous ont aidés à réaliser ces succès avec Agile.
1. planifiez continuellement
La planification est continuelle dans tout projet qui n’est pas « en cascade ». La rapidité d’exécution des activités, les chevauchements de tâches et les exigences opérationnelles qui changent constamment demandent de l’attention. Vous ne connaîtrez pas chaque détail à l’avance, mais c’est bien. Le but est de rester maitre de la planification pour que vous soyez toujours un coup d’avance sur vos efforts de développement.
Même si cela peut sembler fastidieux, une planification appropriée en amont payera ses dividendes en cours de route. Une bonne façon de commencer est d’avoir une session de planification avec l’équipe entière (le propriétaire de produit, UX/Responsable de l’eXpérience Utilisateur, et les développeurs). Utilisez ce moment pour revoir le design de conception et permettre à l’équipe de poser des questions. Cette session est une bonne occasion de découvrir des domaines sur lesquels vous pouvez devoir faire des recherches plus approfondies. Cette sorte de planification vous aide aussi à savoir ce que vous ne savez pas (encore) et comprendre les risques que ceci pourrait poser.
Une fois que votre projet est démarré, la planification est tout aussi critique. Vous devrez surveiller l’arriéré de produit et la vitesse de livraison de l’équipe. Quand les priorités changent, comprendre les variables avec lesquelles vous travaillez vous aidera à planifier les sprints à venir et ajuster le sprint actuel si nécessaire. Vous devrez continuer à travailler avec votre équipe pour planifier, re-prioriser si nécessaire et ajuster es attentes. Juste quand vous pensez que vous avez fini de planifier, soyez prêt à planifier un peu plus.
2. faites ce qui est bien pour le produit
Parfois (en réalité, la plupart du temps) « la bonne façon » n’est pas la voie la plus facile, la plus rapide, ni la moins coûteuse. Cela ne signifie pas que vous devriez mettre en péril votre vision pour le cœur du produit. Déterminez la meilleure ligne de conduite, évaluez les impacts et prévoyez comment avancer. Les dates changent, les priorités changent et le monde avance.
Sur la même ligne de pensée, un propriétaire de produit avisé sait quand il est temps de prendre une décision difficile et tirer sur les rênes. Il y aura toujours encore une fonctionnalité à caser parce que c’est « une capacité à surprendre » ou parce qu’un grand client la demande. Prenez du recul pour considérer ce qui est le plus critique et voir s’il y a d’autres façons d’atteindre ce but. Le chemin peut ne pas sembler exactement comment vous l’avez prévu, mais vous pourrez probablement trouver un passage.
3. Sachez que les outils que vous utilisez sont seulement aussi bons que les données qui y entrent
Les équipes doivent comprendre tous les processus et flux de travail associés au projet et quelles sont leurs responsabilités dans ceux-ci. La dernière chose dont vous voulez vous inquiéter est un problème de communication surgissant à cause d’étapes manquées (qui peuvent en fin de compte causer des retards). Pour communiquer efficacement, assurez-vous que les membres du projet informent leur équipe quotidiennement lors des réunions standup et managent activement les statuts des tâches qui leur sont confiées.
Votre équipe devrait aussi opérer de façon systématique et communiquer de façon opportune pour qu’il soit facile de suivre le progrès. Trouvez des façons de fournir de la visibilité à ceux qui en ont besoin et supprimez le bruit pour ceux qui ne sont pas concernés. Les tableaux de bord peuvent être un outil puissant pour montrer comment le travail progresse et identifier rapidement les risques (les délais, la portée, ou des ressources) dans le projet.
4. Ayez une compréhension claire et partagée de ce que « done » signifie
Parce que les méthodes Agile varient, « done » peut avoir de significations différentes selon les projets. Ce qu’une équipe considère « done » peut ne pas correspondre à ce qu’une autre équipe en penserait. Pour éviter toute confusion, votre équipe devrait créer une définition partagée de ce que « done » signifie pour que tout le monde sache quand considérer une fonctionnalité complète.
Si vous êtes nouveaux en Agile, posez une définition simple. « Done » pour une fonctionnalité pourrait être défini selon des critères clairs d’acceptation pour déterminer si l’histoire d’utilisateur est complète. Les critères d’acceptation contiendraient une liste explicite de déclarations (avec un accepté/rejeté) qui manifeste si le livrable répond aux exigences. Une fois qu’une fonctionnalité a été codée et testée, elle peut être remise au propriétaire de produit pour la revue finale. Le propriétaire de produit acceptera alors (idéalement, par écrit) une fonctionnalité avant qu’elle ne soit considérée « done ».
5. Gardez l’objectif final à l’esprit
À un certain point dans votre projet, vous allez devoir faire des compromis. Quand ces situations surgissent, vous devrez prendre du recul et
vous demander, « Quel est le MVP ? (Minimum Viable Produit) ». Assurez-vous de livrer de la valeur – une réelle Valeur – à vos clients et votre business. Si vous n’avez pas fait de recherche avec des clients, ne passez pas du temps à créer quelque chose qu’ils peuvent ne pas vouloir ni avoir besoin. Concentrez vos efforts sur ce qui va fournir un bénéfice à court terme et ce sur quoi vous pouvez continuer à construire dans l’avenir.
Produit Viable Minimum (MVP)
Bien que nous ne suivions pas un processus de développement logiciel Agile strict à Think Brownstone, les méthodes que nous avons adaptées se sont avérées fructueuses tant avec des projets internes que clients. Avec autant de sortes différentes d’Agiles utilisées, ce qui marche pour certains peut ne pas toujours marcher pour d’autres, mais nous avons constaté que garder ces 5 astuces à l’esprit peut mener au succès.
Quelles autres astuces avez-vous trouvées utiles pour manager des projets agiles ? Quel conseil pouvez-vous communiquer à celles et ceux qui sont nouveaux en Agile ? Répondez dans la zone commentaires de ce billet.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Les approches agiles ne se limitent plus au développement de logiciels.
AgilePM Certification APMG est Partenaire de DantotsuPM
Elles sont devenues populaires auprès de diverses organisations qui doivent être plus souples et réactives pour traiter efficacement leur rythme de changement croissant.
Agile Project Management (AgilePM) est une approche novatrice de la gestion de projet.
Le webinar vous présentera les différentes méthodes agiles, les principes de l’approche AgilePM et les outils nécessaires pour gérer les projets Agiles.
cliquez sur l’imagePartenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La méthode Kanban adaptée à la planification de projet présente en effet de réels atouts
Louis Marie RESSEGUIER, PMO consultant au sein du cabinet expert IQar dans l’accompagnement et le conseil de la gouvernance des portefeuilles projets, vous partage ses convictions sur un volet clé de la gestion de projets : la planification de projet !
Quand on évoque la gestion de projet et particulièrement quand on s’intéresse à la phase de planification des projets plusieurs mots clefs peuvent revenir : PERT, Gantt, Kanban…
Ces mots font référence à des méthodes de planification ou de représentation de la planification du projet. Si la démarche de planification consistant à déterminer le chemin critique en passant par la méthode PERT puis à représenter de manière visuelle la planification via l’outil diagramme de Gantt est classique, elle n’en présente pas moins une certaine forme de complexité.
Nombreux sont nos clients qui nous reçoivent avec leurs visages déformés par la douleur au moment d’aborder ce sujet et de leur niveau actuel de leur art en la matière !
Pas de panique ! Pour y remédier dans le cadre des organisations qui débutent en gestion de projet ou qui ne sont confrontées qu’à des projets peu complexes, planifier à l’aide d’une adaptation de la méthode Kanban peut apporter de nombreux avantages.
On vous donne aujourd’hui les 5 principaux !
1/ Simple : Cette méthode est compréhensible et accessible pour le plus grand nombre. Elle se résume à déplacer des post-it (virtuels) dans un tableau en phase de réalisation et à exprimer la feuille de route du projet sur des post-it (virtuels) dans un tableau en phase de planification.
Le Drag and Drop de la planification, on adore !
2/ Visuel : C’est en effet une méthode très visuelle. On repère en un seul un coup d’œil l’avancement du projet, le nombre d’actions à réaliser. En cela, le KANBAN se révèle être un formidable outil de communication complémentaire du Gantt !
Utilisez-le à volonté, ne nuit pas à la santé…de votre Projet !
3/ Universel : Cette méthode est très utilisée et connue dans de nombreux secteurs d’activité et ne demande pas, pour être mise en œuvre, une conduite du changement drastique.
Kanban, une planification à portée de mains…de clics !
4/ Agile : Cette méthode est nativement compatible avec les méthodes agiles comme « scrum » et permet de les outiller avec succès puisqu’elle permet d’illustrer à merveille la gestion d’un « sprint ». En phase de planification un « planning poker » sera facile à réaliser grâce à ce support.
Le Kanban c’est SMART non ?
5/ Compatible : Cette méthode n’empêche pas de la coupler avec le diagramme de Gantt pour l’aspect visuel des délais en planification puisqu’un outil PPM comme SuiteProG, application SaaS développée par IQar, permet déjà de passer pour le plan d’action d’un projet de la vue Kanban à la vue Gantt (en fonction des dates des actions du Kanban) automatiquement.
Agile et docile le Kanban… demandez une démonstration de SuiteProG !
Pour conclure, la mise en œuvre d’une méthode Kanban pour la planification de vos projets, peut être un véritable vecteur de simplification de cette phase incontournable de la vie du projet qu’est la Planification.
Cette méthode peut également s’avérer être un formidable levier d’aide à la conduite du changement dans certaines organisations : notamment celles désireuses de bénéficier des avantages du mode projet tout en adaptant par étapes les modes de travail de ses collaborateurs pour faciliter l’adhésion et le succès de la mise en place de la démarche.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Basé sur le modèle proposé par le Agile Business Consortium,
Pour acheter le guide
AgilePM guidance offre une méthodologie pratique et répétable qui tend à trouver le bon équilibre entre rigueur, standard et visibilité nécessaires à un bon management de projet, et l’adaptabilité, la rapidité et l’autonomie proposées par Agile.
AgileM fournit une structure pour déployer Agile dans l’organisation en se basant sur les meilleures pratiques.
APMG est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La seconde en Français dure une cinquantaine de minutes et est illustrée de retours d’expérience personnels de Guillaume LOURS, Coach Agile et Expert Java EE, co-fondateur du Normandy Agile User Group et l’un des organisateurs de l’AgileTour à Rouen.
N’oubliez pas de poster vos commentaires et retours d’expérience !
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Quand nous pensons au voyage depuis les approches de livraison traditionnelles vers Agile, le focus est normalement placé sur des équipes de développement et livraison ou sur les secteurs de l’organisation qui auront besoin d’un focus projet à une plus grande attention sur le produit, la capacité ou le flux de valeur.
Les ressources humaines sont un bon exemple de fonction organisationnelle que vous pourriez penser ne pas subir de changement significatif.
Pour les grandes sociétés qui ont défini des familles de métiers et de rôles, Agile pourrait présenter de nouveaux rôles comme des scrummasters, des propriétaires de produit ou des coachs agiles. Les architectes et spécialistes organisationnels vont devoir développer les compétences et les responsabilités exigées par de tels nouveaux rôles. Ils devront aussi concevoir les parcours de carrière d’autres rôles vers ceux-ci.
Hors, dans de nombreux marchés, les coachs agiles expérimentés pourraient bien valoir leur pesant d’or, et donc le personnel chargé des compensations devra identifier quels seraient les salaires médians raisonnables pour de tels rôles et calculer ensuite l’impact sur les personnes occupant de telles positions.
Ceci est critique, l’effort dépensé à recruter, intégrer ou promouvoir le personnel dans ces rôles sera gaspillé si la compensation n’est pas alignée sur le marché. Comme avec d’autres expertises et compétences recherchées, garder ces personnels peut être aussi difficile que les acquérir.
Les sociétés sont souvent organisées par départements de compétences distinctes, spécialisées et les programmes de mesure d’exécution soulignent l’individu au lieu des équipes. Les programmes traditionnels récompensent l’exécution individuelle et la célébration des performances de l’équipe passe à la trappe quand on en vient aux budgets.
pour aller plus haut ensemble il faut apprendre à se connaitre
L’approche Agile prospère quand vous conservez longtemps ensemble des équipes de spécialistes qui deviennent plus généralistes et collaborent étroitement. L’équipe, plutôt que n’importe quel membre d’équipe est le niveau le plus bas de granularité quand on parle de processus décisionnel, d’engagement et d’exécution.
Ce que cela implique est que les managers des personnes qui pourraient précédemment avoir découragé leur personnel de sortir des frontières de leurs compétences ou rôles spécifiques devront changer leur approche et les ressources humaines devront mener cette campagne en encourageant les bons comportements de leadership. Les processus de management de l’exécution devront aussi se développer pour souligner la contribution d’un individu envers l’équipe et récompenser le bon type de comportements d’anciennes primadonnas.
Les transformations agiles couronnées de succès impactent toutes les parties de la société, y compris celles qui ne sont pas d’habitude directement impliquées dans la livraison de projet.
CSP est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Les histoires d’utilisateur sont un artefact de développement crucial en programmation extrême (XP) ou projet Scrum. Elles sont les définitions de haut niveau d’exigences qui incluent juste assez d’information pour que les développeurs puissent produire des évaluations raisonnables de l’effort nécessaire pour les mettre en œuvre. Une autre façon de penser aux histoires d’utilisateur consiste en ce qu’elles peuvent rappeler aux développeurs d’avoir une conversion avec le client ou le propriétaire de produit pour obtenir des informations plus détaillées quand viendra le moment de mettre en œuvre l’histoire.
Le client ou le propriétaire de produit écrivent des histoires d’utilisateur comme des fonctions et options que le système doit exécuter. Elles sont semblables à des scénarios d’usage, sauf qu’elles ne sont pas limitées à la description d’une interface utilisateur. Une histoire d’utilisateur est courte (deux ou trois phrases) et elle utilise seulement la terminologie du client. Les histoires d’utilisateur peuvent être écrites de façon informelle, comme suit : les étudiants peuvent acheter un forfait de stationnement mensuel en ligne, ou de façon plus formelle, en suivant ce modèle :
En tant que < rôle > je veux < quelque chose >pour < ce bénéfice >.
Donc, notre exemple pourrait être écrit comme suit :
En tant qu’ étudiant, je veux acheter un forfait de stationnement pour que je puisse venir en voiture à l’école.
Méta Projets Management est partenaire de DantotsuPM
La manière plus formelle aide les développeurs à identifier clairement les acteurs, la fonction exigée et « le pourquoi » (la valeur business/client) qui soutient l’exigence. Avec la manière informelle, tous ces détails ne sont pas si évidents.
Les histoires d’utilisateur conduisent aussi la création des tests d’acceptation. Des contrôles d’acceptation plus automatisés doivent être créés pour vérifier que l’histoire d’utilisateur a été correctement mise en œuvre. Une bonne approche est de faire spécifier par le client les critères d’acceptation pour aider à créer les tests de recette.
Si l’estimation est trop importante et ne peut pas entrer dans une itération, l’histoire doit être décomposée. Pendant la réunion de livraison, de nouvelles histoires d’utilisateur pourraient apparaitre en en divisant d’autres. XP et Scrum ont des vues légèrement différentes de comment les histoires d’utilisateur sont évaluées.
XP utilise le concept de temps de développement idéal, combien de temps cela nécessiterait pour mettre en œuvre l’histoire dans le code s’il n’y avait aucune distraction, aucune autre tâche allouée et que vous saviez exactement que faire. En comparaison.
Scrum utilise le concept plus abstrait de points d’histoire (ou de complexité), qui est basé sur l’assignation de valeurs différentes — des points d’histoire — à chaque histoire d’utilisateur, en considérant sa complexité relative par rapport aux autres histoires.
En se basant sur la valeur métier (celles de plus grande valeur viennent d’abord) et les estimations fournies, les histoires d’utilisateur sont priorisées et planifiées pour une certaine itération/livraison. Quand il est temps de mettre en œuvre l’histoire d’utilisateur, le développeur et le client ou le propriétaire de produit s’assoient ensemble pour détailler les exigences; Juste suffisamment pour que l’équipe de développement puisse la mettre en œuvre.
Les épopées (epics) sont de grandes histoires d’utilisateur, typiquement celles qui sont trop grosses pour une mise en œuvre en une seule itération et doivent donc être décomposées en histoires utilisateur plus petites. Les épopées sont typiquement des histoires utilisateur de priorité inférieure, qui sont vagues, mais deviendront plus claires avec le temps. Cela n’a aucun sens de décomposer une épopée de basse priorité, parce que vous investiriez du temps sur quelque chose que vous ne pourriez ne jamais parvenir à adresser, à moins qu’une partie de l’épopée ne soit de forte priorité et doive être regardée.
Un thème est une collection d’histoires utilisateur reliées. Les thèmes sont souvent utilisés pour organiser des histoires dans des itérations/releases ou les organiser pour que des sous-équipes différentes puissent travailler dessus.
CertYou est partenaire de DantotsuPM
Vidéo de Lyssa Adkins sur le Scrum Framework
Agile coaches need to be able to teach the agile framework their teams will use in 10 minutes or less.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
PMI et Agile Alliance se sont mis au travail ensemble pour produire le Agile Practice Guide dans l’intention de forger une meilleure compréhension des pratiques agiles pour les chefs de projet.
Vidéo mise en ligne par le PMI:
Voici un aperçu de ce que vous pourrez lire dans ce guide.
Qu’est-ce que l’état d’esprit Agile?
Le guide sur Amazon
Pour partir du bon pied, un rappel est fait du Agile Manifesto, des valeurs, et des 12 principes Agile. Cette entrée en matière couvre aussi les concepts de travail à faire bien défini ou à fortes incertitudes avec les corrélations entre Lean, Kanban et Agile.
Une analyse approfondie du choix de l’approche en fonction des cycles de vie de projet
L’un des aspects les plus saillants des approches Agile pour les chefs de projet est le cycle de vie du projet et les livraisons de produits. Plusieurs cycles sont développés dans le guide avec des critères de choix, guides d’adaptation et combinaisons fréquentes des approches. L’objectif est mieux mettre en évidence ce qui est ou pas Agile et comment choisir en connaissance de causes.
CertYou est partenaire de DantotsuPM
Autres suggestions et recommandations
Composition des équipes et “servant leadership” détaillés
Organisation d’équipe pour livraison fréquente de valeur et métrique efficace.
Facteurs favorisant le travail en équipe Agile : organisation, culture, PMO…
Tableau de références croisées entre les concepts Agiles et les groupes de processus et domaines de connaissance du PMBOK® Guide, 6ème édition.
PMI and PMBOK Guide are registered mark of Project Management Institute, Inc.
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Récemment, j’ai beaucoup réfléchi à comment augmenter l’agilité personnelle. Non, je ne parle d’exécuter des sauts périlleux ou autres folles poses de yoga. Je parle de la capacité à me concentrer sur la valeur et à être adaptable dans ce que je fais chaque jour. L’agilité telle que mentionnée dans les valeurs et principes du Manifeste pour le Développement Logiciel Agile. Quand le manifeste a été répondu en 2001, il y avait des représentants de Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming et autres. Aussi, quand je dis Agile, je ne veux pas nécessairement dire Scrum.
Scrum de Un ?
Dans ce billet, je veux mettre le focus sur les personnes et pas les organisations. Étant un coach Agile et un consultant, j’ai appris beaucoup de stratégies qui m’ont aidé à manager des clients. En travaillant avec de grandes organisations complexes, j’ai vu des améliorations de productivité au niveau organisationnel en appliquant Lean et Kanban et au niveau de l’équipe avec Scrum et Kanban. Mais qu’en est-il de toutes les personnes qui travaillent pour ces organisations ou dans ces équipes Scrum ? Qu’en est-il des gens qui n’ont aucune idée de ce qu’est Scrum et ne s’en soucient pas ? Comment peuvent-ils améliorer leur productivité ?
Dans le billet Lifehack « Scrum for One« , Dustin Wax décrit combien des éléments de Scrum pourraient être adaptés à la productivité individuelle. En lisant l’article, je n’ai pas acheté l’idée. Scrum est une approche géniale pour des équipes mais c’est comme vouloir faire passer une pièce ronde dans un trou carré que de vouloir utiliser Scrum pour votre productivité quotidienne.
Dans Scrum, vous démontrez la valeur à votre client toutes les 2 à 4 semaines dans le cadre d’un sprint. Cela a-t-il du sens pour manager votre travail personnel ? Non.
Dans Scrum, vous avez les 3 rôles : ScrumMaster, Propriétaire de Produit et Équipe. À moins que vous n’ayez une double personnalité, il n’y a que vous !
La plupart des choses auxquelles je pense pour atteindre mes objectifs : l’alignement des activités sur les livrables, la décomposition du travail en morceaux exécutables, réitérer sur ce qui est créé pour pouvoir l’améliorer au fil du temps… la liste est longue.
Et ces composants ne sont pas des éléments exclusifs à Scrum. Alors, pourquoi vous limiter à Scrum ?
Manifeste d’Agilité Personnelle
Je crois que la productivité personnelle doit être repensée.
La productivité personnelle est-elle d’être tout le temps occupé ou de réaliser des choses ?
Pour être productif, cela signifie que vous devez produire. Sinon, vous êtes actifs. Il y a une différence! Pour aider à structurer mes pensées, j’ai écrit un Manifeste d’agilité personnelle.
Vous remarquerez que c’est proche du Manifeste Agile. Mais, il y a des différences clés.
D’abord, (tous) les résultats obtenus sont des mesures primaires de progrès. Ceci n’est pas du tout le cas pour le développement logiciel.
Deuxièmement, je me suis concentré sur des minutes, heures et jours pour réaliser des choses. Les équipes continueront à se concentrer sur des jours, semaines et mois pour obtenir le travail escompté et le livrer.
Je cherche à produire quelque chose que tout un chacun puisse utiliser. Quand vous entendez « Agile » c’est en réalité un groupe de niche de personnes concernées. Mais, quand vous parlez de productivité personnelle, la taille de l’audience explose. Comme avec Agile, je ne pense pas qu’il y ait une unique et meilleure voie. Alors, je regarde pour expérimenter et continue d’essayer pour améliorer.
Comme j’écris sur Personnel Kanban depuis 2010, vous pourriez penser que je devrais avoir tout compris à ce jour. Eh bien non, ce n’est pas encore le cas…
Aussi, si vous avez d’autres trucs, astuces et suggestions, j’aimerais les entendre/lire.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
L’intérêt et la demande d’approches Agiles pour une gamme de projets et initiatives de plus en plus vaste n’ont jamais été plus forts.
Cependant il y a un mythe généralement attribué à Agile qui continue à persister, après bien des discussions et débats, et qui décourage souvent des individus et organisations de considérer, sans parler d’adopter, le management de projet Agile. Le mythe dit qu’Agile ne serait approprié que pour des projets de développement informatique et de logiciel.
Il est compréhensible que cette idée fausse existe. Après tout, le concept entier d’Agile est né dans le secteur informatique et dans le domaine du développement de logiciel
Cependant, ce mythe (selon lequel Agile ne s’applique qu’aux projets IT) n’est pas vrai et c’est un mythe qui a besoin d’être éliminé une fois pour toutes.
AgilePM® est agnostique de l’industrie et du type de projet
AgilePM Certification details APMG est Partenaire de DantotsuPM
L’approcheAgilePM®, basée sur le Agile Project Framework du Consortium DSDM – a été conçu pour être agnostique d’industrie, le rendant applicable à une vaste gamme de projets et d’initiatives de changement, s’étendant du marketing, du développement commercial aux restructurations et transformations d’organisations et entreprises.
AgilePM fournit un guide pas-à-pas pour la prise en considération de la faisabilité du travail et suggère de décomposer le travail en composants petits mais indépendamment porteurs de valeur. Il encourage leur mise en œuvre immédiate pour produire les fonds qui financeront les composants de travail suivants.
Chacun de ces éléments fait d’AgilePM une approche raisonnable de lancement de quoi que ce soit de nouveau. Après tout, le matériel informatique et le logiciel sont juste des exemples de nouveaux produits et services. AgilePM n’est pas un jeu d’instructions pour du travail technique; AgilePM guide comment n’importe quel nouveau produit ou service, ou n’importe quelle amélioration de produits existants ou de services, peuvent être lancés.
Une nouvelle campagne publicitaire, un nouveau type de revêtement de sol, rapatrier un centre appel offshore dans son pays peuvent tous être facilement gérés utilisant AgilePM.
AgilePM aide à établir la faisabilité de la nouvelle idée en poussant sérieusement ceux impliqués à décrire les problèmes qu’ils essayent de résoudre ou les capacités qu’ils veulent créer et à les documenter dans quelques documents bien pensés.
Cela garde les options ouvertes en s’assurant que ces questions décrivent ce que l’avenir doit être et pas comment il doit être créé. AgilePM établit à la fois ce qui existera dans l’avenir et les avantages que ceci produira en décrivant des histoires de très haut niveau de ce que le projet amènera.
Reconnaitre que les spécialistes et experts peuvent débattre de comment mieux réaliser ce projet seulement quand les bénéfices attendus ont été évalués et acceptés est une excellente façon d’éliminer les projets ‘de vanité’, c’est-à-dire la création de nouvelles choses pour l’excitation de créer de nouvelles choses. Ceci protège les investissements d’être gaspillés dans des choses qui ne rembourseront jamais ce qu’elles ont coûté.
Accédez à la vidéo de notre partenaire QRP International
La décomposition du travail en éléments indépendamment porteurs de valeur permet de livrer de la valeur très tôt dans la vie du projet.
C’est grâce à AgilePM que cette pratique s’étend, qui réduit les risques projet et construit la confiance en management de projet. Il permet aux sponsors d’obtenir une rapide évidence des bénéfices générés par leurs produits ou services.
Nous ne dépensons plus autant d’argent à répondre à tous les besoins avant de savoir si nos idées sont aussi passionnantes pour nos clients que nous pensions qu’elles allaient l’être. Nous découvrons tôt si nos suppositions étaient justes, en gardant de l’argent laissé dans le budget pour réparer les choses qui ne marchent pas.
Si nous avons raison, les premiers clients génèrent du revenu pour payer pour le travail suivant et créent une atmosphère de succès qui est très passionnante pour l’équipe.
Partenaire de DantotsuPM
Le cadre AgilePM, la formation et la certification ont été développés par le Consortium DSDM et APMG International.
Basé sur le Cadre Agile de Projet du DSDM, AgilePM offre une méthodologie robuste, pratique et répétable pour tous les types de projets. Ses principes réalisent un équilibre idéal entre normes, rigueur et contrôles requis pour la conduite de projet efficace et l’allure rapide, adaptation aux changements et responsabilisation fournis par Agile.
AgilePM devient rapidement le standard pour la conduite de projet agile, avec plus de 38,000 examens passés à l’échelle mondiale depuis 2011. Découvrez-en davantage sur www.apmg-international.com/AgilePM.
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Cela commence par “Pourriez-vous juste … ?”, “En ce qui concerne …” ou “ne me tuez pas, mais … ?”. Ce qui vient est ensuite une nouvelle idée, fonctionnalité, ou demande qui n’a pas été abordée auparavant. Cette conversation arrive tout le temps et cause beaucoup de bougonnement sur “la dérive de contenu”.
Un des problèmes avec la terminologie « dérive de contenu » est qu’elle implique que nous n’avons pas fait assez bien notre travail. Elle implique que quelqu’un, quelque part, a failli et si nous étions de meilleurs managers, ce ne serait pas arrivé. Nous aurions prévu toutes les demandes possibles ou nous aurions la force ou la capacité de dire « Non » à chaque fois quelqu’un a une nouvelle idée. Elle implique que la dérive de contenu est un monstre effrayant qui doit être tenu éloigné par un chef de produit toujours vigilant qui garde jalousement la porte de grange.
Cela commence par un processus pour rassembler toutes les nouvelles idées, demandes et choses apprises à travers toute votre organisation. Des modèles apparaîtront, montrant quelles nouvelles choses sont les plus importantes. Le management du changement n’a pas pour objet d’agir sur toutes ces idées; il s’agit plutôt de trouver l’équilibre entre être réactif et disruptif.
Nous n’avons absolument ni le temps ni les ressources pour agir sur toutes les bonnes idées qui sont déposées sur la table pendant le déroulement du projet. Mais agir sur quelques-unes de ces idées peut être essentiel.
