Je fais une réelle différence, non seulement pour mon organisation, mais pour toute l’économie. J’aide à aplanir les hiérarchies et à donner aux clients ce qu’ils veulent vraiment !
Why we need Agile Projects and not just Agile Development
Les méthodes les plus agiles se concentrent au niveau du développement de produits. Il y a un aspect révolution sous ceci qui est séduisant. Il encourage les équipes à changer le monde en le faisant. Qui ne voudrait pas arriver au travail en se disant : « Je fais une réelle différence, non seulement pour mon organisation, mais pour toute l’économie. J’aide à aplanir les hiérarchies et à donner aux clients ce qu’ils veulent vraiment ». Si votre rôle est à un niveau dans la hiérarchie où on vous a traditionnellement dit quoi faire avec une autonomie minimale, ceci est un sentiment de libération. La prise de contrôle de votre propre travail est l’un des meilleurs ressentis. Il n’est donc pas étonnant que les membres de l’équipe adoptent de plus en plus Agile. Il n’est pas étonnant qu’Agile se répande si largement.
La différence entre faire et être
Mais il y a un problème. Puisque la plupart des méthodes ciblent le niveau équipe, on les voit juste comme quelque chose pour l’équipe. Elles encouragent les organisations à adopter une attitude de type « si cela les rend heureux, laissez-les le continuer ». Donc nous voyons des tas d’organisations faire Agile plutôt qu’être Agile. Nous évangélisons. Nous disons au management que pour être vraiment Agile la culture de l’organisation doit changer; s’ils ne changent pas ils n’en obtiendront pas les pleins bénéfices. Néanmoins, très peu d’organisations changent leur culture pour une culture Agile. La plupart d’entre elles continuent à voir Agile comme quelque chose pour des équipes de développement. Pourquoi en est-il ainsi ?
Agile serait-il devenu un club fermé, réservé à ses membres ?
Nous pourrions parler d’inertie. Nous pourrions parler de tankers mettant des miles pour virer de bord. Nous pourrions parler de Rome qui ne s’est pas construite en un jour. Ce sont plus des excuses que des raisons. Je suis certain qu’il y a une variété de raisons pour lesquelles les organisations n’embrassent pas la culture Agile. Chaque organisation est unique et aura ses propres motivations et son propre contexte. Cependant, il m’apparait qu’une raison pour laquelle les plus grandes organisations n’adoptent pas la culture Agile est qu’il n’y a aucune place pour elles dans Agile. Agile est devenu un club de membres – un club de membres Exclusifs – qui précisément exclut.
Prenons Scrum comme exemple. Scrum a un tas de vertus. Cependant, Scrum exclut les chefs de projet. Beaucoup d’équipes sont ravies de cette exclusion. Elles voient des chefs de projet et plus généralement les managers, comme une mauvaise chose. Ceci érige une barrière. Les équipes disent souvent « Nous sommes Agiles : nous n’avons pas besoin de chefs de projet. »
CertYou est partenaire de DantotsuPM
Comment enchanter notre organisation aussi bien que le client
Cependant, tandis que les équipes de développement peuvent ne pas aimer les chefs de projet si ils commencent à leur dire comment faire leur travail, les organisations aiment les chefs de projet. Il y a bien plus dans la plupart des projets que la partie qui est visible aux équipes de développement. Les organisations comptent sur les chefs de projet pour s’occuper de tout ce travail en dehors du développement. C’est ainsi que l’organisation s’arrime aux projets. Il ne suffit pas d’enchanter le client, nous devons aussi enchanter notre organisation. Nous devons ouvrir la porte et laisser une plus large portion de l’organisation entrer dans notre monde Agile. Nous devons faire des Projets Agile pas seulement du Développement Agile.
Pendant plus de deux décennies, le Consortium DSDM a tranquillement promu une méthode Agile qui prend en considération la vue organisationnelle. Ses membres étaient là à la station de sport d’hiver Snowbird quand l’Alliance Agile a été formée et que le Manifeste Agile a été rédigé. DSDM est une méthode Agile qui inclut le management de projet – mais avec une approche Agile du management de projet.
AgilePM Certification details APMG est Partenaire de DantotsuPM
En 2010 ils se sont ouvertement manifestés. Le Consortium s’est réuni avec le Groupe APM pour sortir le programme de formation et qualification appelé AgilePM®. Il démontre comment les chefs de projet pourraient travailler d’une façon Agile avec des équipes Agile. La porte était alors ouverte. Tout à coup, il y avait une façon facile pour les organisations d’embrasser Agile au-delà du niveau de l’équipe.
La croissance fut rapide. L’appétit était là et AgilePM est une façon d’y donner satisfaction et d’apaiser cette faim. Des milliers de chefs de projet, ainsi que membres de l’équipe et autres parties prenantes, se sont inscrites.
Dans le vrai style Agile, le produit a continué à se développer, allant de pair avec l’évolution du mouvement Agile. AgilePM V2 est l’offre actuelle. Elle a été rationalisée pour que le nombre de produits de management soit réduit. Elle offre une intégration plus simple avec d’autres méthodes Agile comme Scrum et permet aussi l’intégration avec PRINCE2 ®.
AgilePM est ici pour durer et s’améliore constamment.
Partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Beaucoup d’attention est portée au « Manifeste Agile » et bien qu’il soit une composante importante de Agile, ce n’en est pas toute la substance. Il y a 12 principes directeurs en plus des 4 composants principaux du manifeste. Jetons un rapide coup d’œil à chacun d’entre eux et voyons combien ils affectent comment nous percevons et implémentons les pratiques Agiles…
1. Notre priorité la plus haute est de satisfaire le client par la livraison rapide et continue de logiciel de valeur.
Ceci est l’aspect le plus important d’Agile qui doit être compris et adopté comme une partie de la culture de toute organisation qui veut être « Agile » : le client et l’utilisateur final sont le focus ultime du processus tout entier, du commencement jusqu’à la fin. Le client est le juge du succès ou de l’échec d’un produit ou d’une fonctionnalité, pas la société ni ses parties prenantes. Le client est celui avec les problèmes que nous adressons et comme tel il doit être partie intégrante du processus de développement de produit du commencement à la livraison.
Ignorer vos clients jusqu’à ce que votre produit soit prêt à être expédié est l’anti-modèle Agile numéro 1 dans le monde.
2. Accueillez avec bienveillance les demandes d changement, même tard dans le développement. Les processus agiles exploitent le changement pour donner un avantage compétitif du client.
La deuxième partie la plus importante de Agile est en fait… …de faire preuve d’agilité. N’importe quelle organisation qui investit lourdement dans la définition en amont, la conception et la définition des besoins n’estPas Agile…et ne fait certainement pas preuve d’agilité. Tout le point de l’agilité est que vous pouvez vous accommoder d’importants changements de besoins à n’importe quel point du processus et toujours livrer quelque chose qui est utile pour le client et résout un ou plusieurs de leurs problèmes. Des processus agiles s’appuient sur la Priorisation et non par la Négociation de contrat pour atteindre le succès. Quand de nouveaux besoins surviennent, ils ne sont pas soumis à de lourds et détaillés processus de management des changements. Ils sont plutôt ajoutés à la pile de tout le reste à faire et évalués tout simplement comme une autre tâche ou histoire utilisateur déjà dans le processus.
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
Penser que les choses sont totalement ou presque entièrement définies à l’avance est un autre anti-modèle Agile dont beaucoup de sociétés souffrent fréquemment.
3. Livrez souvent (entre deux semaines et deux mois) du logiciel qui fonctionne avec une préférence pour les fréquences les plus rapides.
Il y a plusieurs choses dans ce principe. D’abord du logiciel qui marche est le but du processus à chaque étape, ensuite le travail devrait être itératif et s’améliorer à chaque livraison et, finalement les itérations qui sont engagées devraient être les plus courtes possible. Si vous travaillez sur un projet qui progresse pendant six mois sans vérifier les résultats intermédiaires avec le client (ou son représentant), vous n’êtes pas Agiles. Si vous travaillez sur des itérations d’une semaine, mais ne livrez pas quelque chose qui résout au moins un problème client à chaque itération, vous n’êtes pas Agiles. Les itérations agiles doivent être assez longues pour livrer un logiciel qui fonctionne et assez courtes pour vous assurer que ce que vous livrez résout bien dans les faits des problèmes clients.
CertYou est partenaire de DantotsuPM
Travailler itérativement ne signifie pas nécessairement que vous êtes Agiles; l’itération est importante, mais livrer un logiciel qui fonctionne l’est tout autant.
4. Les gens du métier et les développeurs doivent travailler ensemble quotidiennement pendant tout le projet.
La collaboration et les interactions entre les gens sont critiques au succès de toute organisation Agile. Les silos et le « jeté de besoins par-dessus le mur » sont contre-productifs aux approches Agiles, comme l’est de segmenter votre organisation entre les gens « du métier/business » et les « techniciens ». Tout le monde du côté « métier/business » devrait être prêt, consentant et disponible pour fournir autant de support que possible aux équipes « techniques » et vice versa. L’idée séculaire qu’il y a une certaine différence inhérente entre la façon dont « l’activité business » devrait être exécutée et la façon dont « la technologie » devrait l’être est entièrement artificielle et contre-productive dans un âge d’innovation rapide et de livraisons encore plus rapides.
Décourager la collaboration ou encourager le « silotage » des efforts est un anti-modèle Agile qui persiste dans trop de cultures d’entreprise.
5. Construisez les projets autour de personnes motivées. Donnez-leur l’environnement et le support dont elles ont besoin et faites leur confiance pour faire le travail.
Agile valorise les personnes en tant que personnes et les équipes en tant qu’équipes. Les gens ne sont pas des rouages interchangeables que vous pouvez aléatoirement déplacer d’un projet à un autre et vous attendre à ce qu’ils excellent continuellement. Les individus sont motivés par des choses différentes et dans une vraie approche Agile nous exploitons ce qui motive individuellement les membres de notre organisation pour créer des équipes avec ces individus motivés qui sont intrinsèquement motivés pour réussir. Agile déboute de l’idée que la récompense extrinsèque fournit des résultats exceptionnels et se concentre plutôt sur l’assurance que les individus aient la motivation, l’environnement et les outils dont ils ont besoin pour réussir tout seuls. Il n’y a aucune approche de type « la carotte et le bâton » dans Agile. Il y a des problèmes à résoudre pour les clients qui sont intéressants et fascinants et qui sont résolus par des personnes qui ont l’intérêt nécessaire et la motivation intrinsèque pour les résoudre.
NQI est Partenaire de DantotsuPM
Attendre des gens d’être performants simplement parce qu’ils sont membres « d’une équipe » et non pas parce que cette équipe partage la motivation intrinsèque de réussir est un anti-modèle extrêmement commun dans les grandes organisations.
6. La méthode la plus efficace et effective de transmettre des informations dans une équipe de développement est la conversation en face à face.
La méthode séculaire d’avoir un unique expert du sujet qui écrit tout qu’il veut avoir et le remet aux développeurs comme « une liste à exécuter » de besoins est hérétique aux approches Agiles. Des personnes différentes pensent et communiquent différemment et le texte écrit est l’une des pires façons d’exprimer que vous essayez de dire. Au pis-aller, c’est vague et difficile à déchiffrer pour la personne qui ne l’a pas écrit; au mieux, c’est un document clinique, stérile qui remplace le sentiment par la précision. Si le but est d’exprimer la douleur que ressent le client et motiver les équipes à exceller dans leur job parce qu’elles le veulent, alors aucune de ces approches par des besoins écrits n’aura le résultat que nous désirons. Nous utilisons plutôt des choses comme les Histoires Utilisateur, qui explicitent le problème que nous voudrions résoudre, mais qui permettent à notre équipe de développement d’utiliser sa créativité pour y répondre de la meilleure façon possible.
Même quand nous utilisons des outils pour suivre le travail et communiquer les informations les plus basiques, nous ne pouvons pas oublier que la façon la plus importante de communiquer l’un avec l’autre, indépendamment des rôles, est toujours la conversation en face à face.
7. Le logiciel qui marche est la principale mesure de progrès.
Particulièrement dans le monde des grandes sociétés, nous aimons le concept que tout peut être mesuré, évalué et KPIsé. Nous suivons les revenus, des points d’histoire, la vélocité, la consommation, les nombres d’erreurs découvertes, Ad Nauseum. Pourtant nous oublions souvent que ce que nous essayons vraiment de faire est résoudre des problèmes pour les clients. Et aucune de ces mesures n’indique combien de valeur nous apportons en réalité ni si nous résolvons vraiment des problèmes clients. Le but final de chaque itération devrait être du logiciel qui marche, qui fait quelque chose que nous pensons être de valeur. Sans cela, c’est un échec. Quoi que ce soit de plus que cela est du glaçage sur le gâteau. Les équipes Agile se mesurent elles-mêmes sur si elles apportent réellement de la valeur et si elles créent vraiment quelque chose qui marche la fin de chaqueitération.
Répétons ceci : la vélocité n’est pas la mesure du progrès. La consommation n’est pas la mesure de progrès. Les points d’histoire ne sont pas la mesure de progrès. La capacité n’est pas la mesure de progrès. Les délais ne sont pas la mesure de progrès. La seule chose qui importe est combien vous créez de logiciel qui marche.
Campana & Schott est partenaire de DantotsuPM
8. Les processus agiles font la promotion du développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir indéfiniment tenir une allure constante.
Voir les billets sur l’initiative #ecoPMI
Il y a cette idée fausse dans le monde, tenue tant par les développeurs que par des hommes d’affaires, que Agile signifie aucune documentation, que Agile veut dire faire quoi que vous ayez besoin de faire pour atteindre un but, que Agile signifie changer les priorités et équipes rapidement pour assurer une production maximale, que Agile rime avec imprévisibilité et manque de prédictibilité. Le fait est, l’un des buts principaux d’Agile est créer un environnement de prévisibilité, de stabilité et une allure constante et acceptable de développement de produits qui dure indéfiniment. Il n’y a rien dans les principes Agile qui écarte de créer des planning (quoique ces plans portent un peu d’incertitude !) ni d’être capable de prévoir quand quelque chose pourrait être livré. Au contraire, il n’y a rien dans les principes Agile qui s’attend à ce que des développeurs s’engagent dans des comportements de pression exagérée. En fait, de tels comportements sont de bien des façons antithétiques aux concepts Agiles : si votre équipe doit travailler beaucoup trop durement pour livrer quelque chose, vous avez manqué en amont à vos devoirs de priorisation efficace des Histoires Utilisateur.
Aucune vraie pratique Agile ne devrait aboutir à de l’épuisement, des périodes critiques, ni une incertitude constante et prolongée. Les anti-modèles aboutissent à ces comportements contradictoires.
9. L’attention continue à l’excellence technique et à la bonne conception améliore l’agilité.
Des équipes vraiment agiles ne rassemblent pas à la va vite de mauvais morceaux de code pour l’appeler « bon ». Elles prennent le temps et mettent les efforts nécessaires pour comprendre ce qu’elles essayent de réaliser, comment elles pensent pouvoir résoudre les problèmes et décomposer les choses en assez petits « morceaux » de travail pour à la fois itérer sur le problème et livrer des solutions potentiellement exploitables à chaque étape du projet. La majorité de ce travail se produit avant que les équipes ne s’engagent à faire le travail. Il y a là du pré-travail pour parler approches, pour discuter architecture et s’engager dans des discussions avec des représentants du métier, des parties prenantes et les équipes techniques. Nous nous référons souvent à ceci comme à des sessions de démarrage ou de préparation d’arriéré de produit mais Agile ne devrait jamais être une excuse pour la mauvaise qualité ou une conception erronée.
La conception erronée et de faibles standards aboutissent à de pauvres solutions qui ne répondent pas vraiment aux besoins clients; c’est un facteur de ralentissement, pas un facteur d’accélération.
10. Simplicité, l’art de maximiser la quantité de travail non fait, est essentielle.
Beaucoup trop de personnes lisent ceci de la mauvaise façon et limitent ainsi leur capacité à totalement s’engager dans des pratiques Agiles fortes. Simplifier vos buts, vos histoires, votre travail et tout le reste est un processus qui commence par l’opposé : une très large compréhension de ce que sont les buts et de comment ils pourraient être atteints. Le résultat de tels efforts n’est pas nécessairement un projet plus petit, mais des incréments plus petits et plus simples qui peuvent s’additionner en quelque chose de très grand et qui peuvent aussi indirectement réduire les buts globaux. Le plus grand obstacle est ici que lesimple est plus difficile que le complexe, particulièrement quand les gens s’engagent dans des séances de remue-méninges, ce qui arrive souvent avec des équipes techniques. Résolvez le problème d’abord, itérez ensuite par petits morceaux.
« Rendez chaque détail parfait et limitez le nombre de détails à perfectionner. » Jack Dorsey
11. Les meilleures architectures, besoins et conceptions naissent d’équipes auto organisées.
Le mot clé est ici « naissent ». Quand vous réunissez les bonnes personnes et que toutes sont alignées vers les mêmes buts, certaines choses se produisent. D’abord, elles se tiennent naturellement responsables, parce qu’il y a un sentiment intrinsèquede camaraderie et de but commun. Deuxièmement, Elles se supportent et en même temps se défient pour assurer que le résultat final respecte non seulement leurs attentes individuelles, mais aussi leurs attentes collectives qui sont presque toujours plus élevées. Et finalement, elles améliorent le tout par la collaboration : la valeur de n’importe quelle équipe auto-organisée est au moins 2 fois plus importante que la somme de ses parties individuelles. Le facteur clé est ici auto-organisation, qui peut être dure à vendre dans beaucoup d’organisations, mais les meilleures équipes ne sont pas celles assemblées par un cadre intermédiaire, ce sont plutôt des groupes de personnes qui ont choisi de s’aligner vers un but commun.
Les personnes qui travaillent vers un but commun parce qu’elles le veulent seront toujours plus efficaces, plus fortes et plus fiables que des équipes travaillant ensemble parce qu’on leur a dit de le faire.
12. À intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis règle et ajuste son comportement en conséquence.
Get the book on Amazon
Dans presque chaque organisation que j’ai observée face au défi d’implémenter les pratiques Agile, la plus grande chose qu’elle loupe est l’importance de l’amélioration continuelle ou continue. Agile a ses origines dans des concepts industriels LEAN : la valeur de l’individu, la primauté du résultat sur le processus et, plus important encore, le besoin de constamment mesurer, ajuster et améliorer comment vous faites ce que vous faites. Toute équipe qui veut ne pas s’engager dans les rétrospectives et les revues d’équipe avec leurs parties prenantes après chaque itération risque la stagnation et les anti-modèles parce qu’elle ne les voit jamais arriver. Beaucoup d’équipes voient ces sessions comme contre-productives, des pertes de temps, des exercices « soft skills » qui consomment seulement de leur temps d’exécution. Mais la plupart des équipes les évitent simplement par crainte (et le rationalisent comme elles le peuvent): la crainte d’être sur la sellette, la crainte d’accepter la responsabilité, la crainte de changement. La vérité vraie est que quand elles sont exécutées correctement, elles peuvent être les réunions les plus enrichissantes dans lesquelles les équipes s’engageront. Elles sont destinées à pousser les gens à constamment s’améliorer et être plus efficaces et il n’y pas de bonne raison de ne pas s’engager dans ces discussions.
L’absence de « regarder derrière soi » profondément et honnêtement pour évaluer comment une équipe avance et où elle peut s’améliorer est un anti-modèle fatal au succès de Agile sur le long terme.
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie mais il y a 2 principes pour en déterminer la valeur optimale pour votre projet.
On me demande souvent, ‘Combien de temps devrait durer un Sprint pour mon équipe ?’ Et ‘le Sprint doit-il être de durée fixe ?’. Je constate qu’il ne suffit pas de répondre : « N’y réfléchissez-y pas trop longtemps. Si vous utilisez un environnement raisonnable et un langage de développement comme Java ou dot-net, utilisez une durée de Sprint de deux semaines. Cela semble marcher pour la plupart des équipes, mais certains utilisent une semaine ou trois semaines. Voyez simplement ce qui vous convient. »
Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie.
Deux principes sur la durée
Il y a deux principes pour déterminer la durée d’un Sprint.
Le Sprint ne devrait pas être changé après son démarrage.
Les Sprints devraient être de même durée.
Ne pas se mentir à soi-même ni à l’équipe
Je pense que la première règle est claire et directe. Ce serait tricher que de changer la durée du Sprint après qu’il ait commencé. Si l’équipe ferme les yeux sur le changement de la durée de Sprint, elle sera tentée de changer la définition de « Done » pour permettre certains changements de contenu. Ceci est une mauvaise chose: La chose correcte à faire est d’ajouter une autre histoire utilisateur (User story) à l’Arriéré de produit (Product Backlog).
Quant aux Sprints devant tous être de même durée, c’est un peu plus délicat. J’ai déjà dit qu’un Sprint de démarrage pourrait être de seulement une semaine, donc, clairement je ne suis pas totalement inflexible sur le fait que tous les Sprints devraient être de même durée. Puisqu’un Sprint est une boucle de retour d’information, l’équipe doit prendre en compte les parties prenantes. Avoir une durée de Sprint fixe donne aux parties prenantes un rythme constant pour les revues de livrables, ce qui est réconfortant et installe une routine familière. Cependant, avoir des durées de Sprint différentes pour des Sprints spécialisés, comme la prise en compte des périodes de fêtes (ou des vacances), ou une autre raison dont l’équipe et les parties prenantes peuvent convenir, ne me semble pas être une terriblement mauvaise chose.
Est-ce assez long ?
Un Sprint doit être assez long pour vraiment achever des histoires (user stories). C’est-à-dire l’équipe doit pouvoir amener ses histoires jusqu’à leur état fini (« done »). C’est une règle dans Scrum qu’un Sprint ne devrait jamais excéder un mois. En général, la longueur de Sprint devrait être approximativement de trois fois le temps nécessaire à analyser et réaliser totalement une histoire de taille moyenne. Ceci semble donner assez de flexibilité dans le système pour permettre à l’équipe de s’auto-organiser pour obtenir un travail fini. Mon expérience est qu’une histoire prend environ 2-3 jours pour une équipe typique qui est bien en place, donc une longueur de Sprint raisonnable est deux semaines. Cependant, les environnements sont différents; certains sont plus faciles (ou plus difficiles) que d’autres. Je m’attends donc à ce que les longueurs de Sprint d’une équipe varient largement en fonction de ces différences d’environnement.
Est-ce assez court ?
La durée de Sprint devrait être suffisamment courte pour que le changement d’avis sur les besoins soit plus lent que la durée du Sprint. C’est-à-dire, si la durée de Sprint est de deux semaines, l’équipe espère que les changements de besoins arrivent plus lentement que toutes les deux semaines. Ce qui veut dire que les parties prenantes peuvent attendre jusqu’à la fin du Sprint pour voir leur ‘nouveau truc’ délivré avant de vouloir le changer.
Dans l’environnement business actuel, il est typique que la modification de besoins soit trop rapide pour le Sprint. Il y a des bogues à réparer dans d’autres systèmes que l’équipe maintient, il y a des cas d’urgence partout dans l’organisation à fixer et les parties prenantes changent presque constamment d’avis sur ce qui est important. Ce sont autant de raisons pour que l’équipe raccourcisse la durée de Sprint ou celle du cycle de planification.
Des choses se produisent et les équipes développent des méthodes pour manager le fait que des besoins devraient être changés plus d’une fois par Sprint.
Soyez ouverts à re-planification
Parfois la durée de Sprint d’une équipe est juste trop longue pour que survivent les accords pris : la fréquence de changement des besoins est plus rapide que la longueur de Sprint ne peut le supporter. Il est tentant d’essayer de raccourcir les Sprints, mais peut-être n’est-ce pas faisable parce que les parties prenantes ne peuvent pas manager des revues plus fréquentes, ou parce que l’équipe ne peut pas développer plus rapidement.
Essayez Bubble Plan !
Que fait l’équipe ?
Scrum n’est rien sinon adaptatif. En fait, si l’équipe ne s’adapte pas pour respecter ses propres réalités, ce n’est pas du Scrum. Alors, adaptez-vous… l’équipe pourrait avoir des sessions de planification de Sprint plus fréquentes – peut-être une fois par semaine.
Par exemple, si l’équipe a une durée de Sprint de deux semaines, du lundi au vendredi deux semaines plus tard. Alors, l’équipe pourrait planifier chaque lundi, et non pas seulement un lundi sur deux. Le premier lundi l’équipe remplirait son Sprint à environ 80 % de sa capacité et le deuxième lundi les membres de l’équipe se poseraient la question : « qu’ajoutons-nous maintenant ? »
Je constate que beaucoup d’équipes se sont spontanément déplacées vers ce système, donc c’est un modèle connu qui est très efficace. Il devrait faire partie de la boîte à outils du ScrumMaster.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Un monde en disruption… par Stéphane Derouin – Ancien Président et Fondateur du PMI France, Président de Pmgs.
Stéphane Derouin
Incertitude, risques et difficulté à gérer la transformation
Complexité, (a)synchronie et accélération des temps
Primauté de l’innovation
Déferlement du Digital qui « rebat les cartes »
Nouvelles générations, nouveaux entrants
Le Vertical ne répond plus ni aux besoins ni aux attentes : « Servant Leadership »
Montée de l’interdépendance, du collaboratif, « monde en réseau »
Waterfall ?
Mode déterministe et planifié – on connaît le périmètre du projet qui est placé sous la responsabilité d’un Project Manager. Adapté lorsqu’il y un besoin important de contrôle des spécifications et de maîtrise du périmètre du projet
Exemples : projets de pont, d’autoroute, de centrale nucléaire
Partenaire de DantotsuPM et le calendrier 2017 est déjà disponible !
Agile ?
Mode incrémental et collaboratif. On ne connaît pas le périmètre du projet et il est animé par un Scrum Master. Innovation, R&D, rupture technologique. Adéquation avec les besoins mouvants du projet ou du client
Les «Story Points» sont une unité de mesure pour exprimer une évaluation de l’effort total qui sera exigé pour entièrement mettre en œuvre un article de l’arriéré de produit (du « Product Backlog ») ou autre travail.
Quand nous évaluons avec des «Story Points», nous assignons une valeur de point à chaque article de l’arriéré de produit. Les valeurs brutes que nous assignons sont sans importance. Ce qui importe sont les valeurs relatives. Une histoire qui est assignée un 2 devrait représenter deux fois plus qu’une histoire qui est assignée 1. Elle devrait aussi être les deux-tiers d’une histoire qui est évaluée à 3 «Story Points».
Au lieu d’assigner 1, 2 et 3, cette équipe pourrait avoir assigné 100, 200 et 300. Ou 1 million, 2 millions et 3 millions. Ce sont les valeurs relatives qui importent, pas les chiffres isolés.
Qu’est-ce qui entre dans un « Story Point » ?
Parce que les «Story Points» représentent l’effort pour développer une histoire utilisateur, l’évaluation d’une équipe doit inclure tout ce qui peut affecter l’effort.
Cela pourrait inclure :
Le travail pour faire
N’importe quel risque ou incertitude dans la réalisation du travail
La complexité du travail
En évaluant avec des «Story Points», assurez-vous de considérer chacun de ces facteurs. Voyons comment chacun impacte l’évaluation d’effort donnée pour l’histoire en question.
Le travail pour faire
Certainement, s’il y a plus à faire pour réaliser quelque chose, l’évaluation d’effort devrait être plus importante. Considérez le cas simple de développer deux pages Web. La première page a seulement un champ et une étiquette demandant à entrer à un nom. La deuxième page a 100 champs qui attendent aussi à être simplement remplis d’un peu de texte.
La deuxième page n’est en rien plus complexe. Il n’y a aucune interaction entre les champs et chacun d’eux n’est rien de plus qu’un peu de texte. Il n’y a aucun risque additionnel sur la deuxième page. La seule différence entre ces deux pages est qu’il y a plus à faire pour la deuxième page.
On devrait donc donner plus de «Story Points» à la deuxième page. Cela ne mérite probablement pas 100 fois plus de points bien qu’il y ait 100 fois plus de champs. Il y a, après tout, des économies d’échelle et peut-être que le développement de la deuxième page est seulement 2, 3 ou 10 fois autant d’efforts que la première page.
Risque et incertitude
« Image courtesy of Stuart Miles / FreeDigitalPhotos.net »
La quantité de risque et incertitude dans un article d’arriéré de produit devrait affecter l’estimation en «Story Points» donnée à l’article.
Si on demande à une équipe d’évaluer un article d’arriéré de produit et le demandant est peu clair sur ce qui sera nécessaire, cette incertitude devrait être reflétée dans l’évaluation.
Si l’exécution d’une fonction implique le changement d’un morceau particulier de code ancien, fragile et qui n’a aucun essai automatisé en place, ce risque devrait être reflété dans l’évaluation.
Complexité
On devrait aussi considérer la complexité lors d’une évaluation de «Story Points». Repensez à l’exemple précédent de développer une page Web avec 100 champs de texte insignifiants sans interactions entre eux.
Pensez maintenant à une autre page Web, elle aussi avec 100 champs. Mais certains sont des champs date avec des gadgets de calendrier qui s’affichent en surimpression. Certains sont des champs de texte formatés comme des numéros de téléphone ou des numéros de sécurité sociale. D’autres champs ont des validations comme avec des numéros de carte de crédit.
Cet écran exige aussi des interactions entre des champs. Si l’utilisateur saisit une Carte Visa, on montre un champ CVV à trois chiffres. Mais si l’utilisateur saisit une carte d’American Express, on montre un champ CVV à quatre chiffres.
Bien qu’il y ait toujours 100 champs sur cet écran, ces champs sont plus difficiles à mettre en œuvre. Ils sont plus complexes. Ils prendront plus de temps. Il y a plus de chance que le développeur fasse une erreur et doive repasser dessus et la corriger.
Cette complexité complémentaire devrait être reflétée dans l’évaluation fournie.
Considérez tous les facteurs : Travail, Risque et Incertitude et Complexité
Il peut sembler impossible de combiner ces trois facteurs en un chiffre et le fournir en tant qu’évaluation globale. C’est cependant possible parce que l’effort est le facteur d’unification. Les experts considèrent combien d’effort sera exigé pour réaliser le travail décrit dans un article d’arriéré de produit.
Les experts considèrent alors combien d’effort inclure pour prendre en compte le risque et l’incertitude inhérentes à l’article d’arriéré de produit. D’habitude, ceci est fait en considérant le risque d’apparition du problème et l’impact si le risque survient vraiment. Ainsi, par exemple, plus d’effort sera inclus dans l’évaluation pour un risque consommateur de temps qui va probablement arriver que pour un risque mineur et peu probable.
Les experts considèrent aussi la complexité du travail à faire. Le travail complexe exigera plus de réflexion, pourra exiger une expérimentation plus empirique, peut-être plus d’interactions avec le client, pourra prendre plus longtemps à valider et avoir besoin de plus de temps pour corriger des erreurs.
Ces trois facteurs doivent être combinés.
Considérez tout dans la définition de fini (« done »)
Une évaluation de «Story Points» doit inclure tout ce qui est impliqué dans l’obtention d’un article d’arriéré de produit entièrement fini. Si la définition d’une équipe de « fini » inclut la création des tests automatisés pour valider l’histoire (et ce serait une bonne idée), l’effort de créer ces tests devrait bien sûr être inclus dans l’évaluation de «Story Points».
Les «Story Points» peuvent être un concept complexe à saisir.
Mais l’effort de bien comprendre que les «Story Points» représentent tout l’effort nécessité par le travail, la complexité du travail et tout risque ou incertitude dans le travail le vaut tout aussi pleinement.
Essayez Bubble Plan !
Quels autres conseils prenez-vous en compte dans l’évaluation des « story points » ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
PRINCE2 Agile est une solution de management de projet qui combine les qualités de gouvernance et de management de PRINCE2 avec la flexibilité des concepts Agile.
Partenaire de DantotsuPM
PRINCE2 Agile a été construit de manière collaborative avec des experts PRINCE2 et des « Agilistes ».
Partenaire de DantotsuPM
PRINCE2 Agile couvre les approches Scrum, Kanban, Lean Startup et Cynefin et utilise les principes de PRINCE2 avec 5 comportements clés:
Transparence
Collaboration
Communication
Auto Organisation
Exploration
Partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Le succès du management de projet Agile se base sur des conditions indispensables : des chefs de projet et des équipes impliquées et adaptables, des points réguliers, d’étroites relations avec le client, et un sens de l’organisation incomparable.
Alexis Sgaros
Dans un projet, le changement est normal. Tel est le principe sur lequel se base le management de projet Agile. Un changement qui peut toucher le besoin du client ou les technologies disponibles par exemple, et auquel le chef de projet et son équipe projet doivent être capables de s’adapter. Une méthode de travail qui s’est imposée assez naturellement dans le monde du développement de logiciel, mais qui peine davantage dans d’autres secteurs. « C’est tout un ensemble de fondamentaux à remettre en cause en termes de culture d’entreprise », selon Alexis Sgaros, formateur consultant chez CSP Formation. Cela signifie qu’il faut être en relation proche avec le client tout au long de la vie du projet, afin de s’assurer qu’on ne s’écarte pas de son besoin. En fait, le client fait presque partie de l’équipe.
NQI est Partenaire de DantotsuPM
Une organisation renforcée et un pilotage serré
De son côté, « l’équipe doit être plus fortement responsabilisée. Le chef de projet devient davantage un coach qui laisse l’équipe s’auto-organiser. » Aux membres de se porter volontaires pour accomplir des tâches spécifiques, avec des points à organiser, quotidiennement dans la plupart des cas, afin d’éviter les doublons et oublis. Alexis Sgaros prévient que « comme la zone d’incertitude est plus forte, le pilotage doit être plus serré. On a souvent l’impression que le management de projet Agile est plus simple et demande moins de rigueur, mais en réalité, il en demande plus en termes d’organisation. » Et de sens des priorités, puisqu’il faut réagir instantanément pour traiter d’abord les changements les plus urgents.
CSP est partenaire de DantotsuPM
L’émergence des méthodes hybrides
Attention : Une clé de la gestion de projet Agile est de travailler avec une équipe entièrement dédiée au projet, et physiquement sur le même site, ce qui n’est pas le cas de tous les projets. Au final, Alexis Sgaros remarque que « on a de plus en plus tendance à voir apparaître des méthodes hybrides. Il n’est pas rare que certaines parties d’un projet soient gérées en mode normal et d’autres en agilité. Bien sûr, cela demande une forte ouverture d’esprit du chef de projet, qui doit accepter que tout le monde ne travaille pas de la même manière. »
Ventura Asssociates est partenaire de DantotsuPM et le votre pour dénicher les ressources critiques en PM dont vous avez besoin
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je me rends compte que le concept de Sprint Zéro est controversé. Et dans mes premiers temps en Agile, j’ai été étonné par l’importance accordée à ce sujet. Je pensais que nous aurions des sessions de transfert de connaissances au fil du travail, alors, pourquoi avoir un sprint séparé ? Mais plus tard j’ai compris l’importance du Sprint Zéro dans l’organisation où je travaille. Je ne prétendrai pas que toutes les équipes en ont besoin, mais voici pourquoi c’est utile pour nous.
Les questions abordées au Sprint Zéro s’appliquent à la release toute entière.
Nous pourrions l’appeler Sprint Initial, Itération Zéro, ou Sprint de démarrage.
Selon mon expérience, le Sprint Zéro est limité dans le temps à seulement une semaine.
Notre équipe passe en revue l’ensemble des items de la release et quel travail devrait être achevé dans chaque sprint. En passant en revue chaque article de sprint, l’équipe identifie les endroits pour lesquels nous ne connaissons pas suffisamment bien les exigences qu’elles soient matérielles, d’architecture, logicielles, ou techniques.
Après que l’équipe ait revu les épics (ndlt. groupe de User Stories pour fournir une valeur métier) et fonctions priorisés de l’arriéré de produit, nous devons les annoter et préparer les sessions de revue avec le product owner, le propriétaire de produit. Nous devons comprendre l’environnement et le code exigé pour les items de l’arriéré de produit, indépendamment de si le code sera simple ou complexe.
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)
La raison principale d’introduire un Sprint Zéro est que nous ne voulons pas inutilement prolonger le temps nécessaire aux sessions de revue ou de transfert de connaissance depuis le Sprint 1 jusqu’à la fin. Donc, nous prenons une semaine pour préparer notre équipe avant de démarrer sur des arriérés de sprint.
Grâce à Agile, on nous donne l’opportunité d’en apprendre beaucoup en peu de temps.
L’équipe avancera de façon calme, sans pression excessive.
CertYou est partenaire de DantotsuPM
Utilisez-vous un sprint 0 en début de release sur votre projet Agile? Pourquoi? Quels en sont pour vous les bénéfices et inconvénients ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
« Nos entreprises doivent devenir plus Agiles », certes, mais comment ?
L’émergence de la gestion de projet agile n’est qu’une première manifestation d’un phénomène socio-économique mondial touchant toutes les sphères d’activités des organisations, qu’elles soient privées ou publiques.
Relisez l’article de Claude Emond sur la gestion de projet Agile
L’environnement dans lequel les organisations de ce début de 21e siècle évoluent est de plus en plus volatile, incertain, complexe et ambigu (VUCA), et ce, en grande partie à cause des changements nombreux qui se matérialisent tout azimut. Pour bien fonctionner dans un tel environnement, tous les experts disent que nos entreprises doivent devenir plus agiles.
Mais être «plus agiles», qu’est ce que ça veut dire? Qu’est-ce que ça implique et requiert au juste? C’est ce que nous allons découvrir ensemble lors de cette conférence-atelier.
Conférenciers : Claude Émond et Charlotte Goudreault, associés principaux, coach et formateurs en agilité organisationnelle chez QualiScope Inc (précédent billet sur la gestion de projet Agile)
Le jeu d’introduction de pairs est une activité de développement de l’esprit d’équipe pour que les nouveaux membres de l’équipe en apprennent davantage les uns des autres. Une conversation rapide suivie par introduction par un pair fournit un mécanisme rapide de présenter chaque personne dans un grand groupe.
Avez-vous également expérimenté cet exercice « brise-glace » ?
Comment diriger l’activité
Divisez le grand groupe par paires. Demandez aux gens de se mettre avec quelqu’un qu’ils ne connaissent pas bien.
Demandez aux paires d’avoir une conversation rapide l’un de l’autre et informez-les que plus tard ils présenteront leur partenaire. Vous pouvez laisser la conversation ouverte, ou choisir quelques questions auxquelles répondre (comme : nom, lieu de naissance, rôle actuel, nourriture préférée, lieu de voyage préféré).
Faites le tour du grand groupe et laissez tout le monde présenter son alter-ego.
Microsoft est partenaire de DantotsuPM
Exemple
Paulo dit: « Je vous présente Amit. Il est né au Canada, mais sa famille est en Inde. Il aime la samba brésilienne et sa nourriture préférée est le hot-dog, plus particulièrement en assistant à une partie de base-ball. Il travaille actuellement comme … »
Essayez Bubble Plan !
Note: J’ai été surpris la première fois que l’on m’a invité à faire cet exercice dans le cadre d’une réorganisation et de la mise en place d’une nouvelle équipe de management.
Questions: Avez-vous également expérimenté cet exercice « brise-glace » ? En connaissez-vous d’autres ?
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.
En fait, je vais aller plus loin et poser une affirmation audacieuse :
Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.
En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.
« Les plans ne sont rien. La planification est tout. »
Ceci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.
Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.
Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :
Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.
Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?
Pourquoi les projets entrent-ils dans une telle spirale ?
Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information
Les projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :
Peu ou pas d’informations sur le travail qui a besoin d’être fait
Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)
Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).
Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:
« Aucun plan ne survit au contact avec l’ennemi. »
Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.
Les projets agiles planifient à plusieurs reprises par petits morceaux
Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).
Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :
Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
Pouvant être achevé en un sprint (qui est souvent de deux semaines).
Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.
Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.
Un si petit plan apporte-t-il vraiment de la valeur ?
Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».
Bien sûr, mais deux points :
Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.
Une grande partie de la valeur réside dans la Planification, pas dans le Plan.
Rappelez-vous la précédente citation de Eisenhower.
Les membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.
Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?
Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.
Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.
Get the book on Amazon
Déroulé de l’activité
Donnez à chaque participant un marqueur et un post-it
Demandez-leur de décrire leur sentiment (dans le contexte de la réunion) en un mot
Groupez les notes sur une grande page
Optionnellement, demandez si quelqu’un veut en dire plus sur leur mot choisi
Décrivez s’il vous plaît < le dernier sprint ou le mois passé ou vos sentiments sur XYZ > en un mot !
Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.
Microsoft est partenaire de DantotsuPM
I.N.V.E.S.T.
I – Indépendante
N– Négociable
V– de Valeur
E – Estimable
S – Suffisamment petite
T – Testable
Indépendante
Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.
Négociable
Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.
de Valeur
Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.
Estimable
Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».
Suffisamment petite
Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.
Testable
Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.
Découpage vertical ou horizontal
Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.
Des exemples de découpe de « User Stories »
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits
Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…
En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.
Et/ou
En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.
Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.
Découpage par flux de travail
revoir mon panier de courses
Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :
Fournir mes informations bancaires
En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.
En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
Recevoir une notification par SMS
En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.
D’autres méthodes
Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :
Visitez le blog Agilistic
par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
par options d’interaction / par plate-forme
par types de données ou paramètres
par scénarios de test
par rôles
par ‘j’optimisemaintenant ‘ contre ‘ j’optimise plus tard ‘
par compatibilité de navigateur
la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.
Les méthodes les plus agiles se concentrent au niveau du développement de produits. Il y a un aspect révolution sous ceci qui est séduisant. Il encourage les équipes à changer le monde en le faisant. Qui ne voudrait pas arriver au travail en se disant : « Je fais une réelle différence, non seulement pour mon organisation, mais pour toute l’économie. J’aide à aplanir les hiérarchies et à donner aux clients ce qu’ils veulent vraiment ». Si votre rôle est à un niveau dans la hiérarchie où on vous a traditionnellement dit quoi faire avec une autonomie minimale, ceci est un sentiment de libération. La prise de contrôle de votre propre travail est l’un des meilleurs ressentis. Il n’est donc pas étonnant que les membres de l’équipe adoptent de plus en plus Agile. Il n’est pas étonnant qu’Agile se répande si largement.
Mais il y a un problème. Puisque la plupart des méthodes ciblent le niveau équipe, on les voit juste comme quelque chose pour l’équipe. Elles encouragent les organisations à adopter une attitude de type « si cela les rend heureux, laissez-les le continuer ». Donc nous voyons des tas d’organisations faire Agile plutôt qu’être Agile. Nous évangélisons. Nous disons au management que pour être vraiment Agile la culture de l’organisation doit changer; s’ils ne changent pas ils n’en obtiendront pas les pleins bénéfices. Néanmoins, très peu d’organisations changent leur culture pour une culture Agile. La plupart d’entre elles continuent à voir Agile comme quelque chose pour des équipes de développement. Pourquoi en est-il ainsi ?
Nous pourrions parler d’inertie. Nous pourrions parler de tankers mettant des miles pour virer de bord. Nous pourrions parler de Rome qui ne s’est pas construite en un jour. Ce sont plus des excuses que des raisons. Je suis certain qu’il y a une variété de raisons pour lesquelles les organisations n’embrassent pas la culture Agile. Chaque organisation est unique et aura ses propres motivations et son propre contexte. Cependant, il m’apparait qu’une raison pour laquelle les plus grandes organisations n’adoptent pas la culture Agile est qu’il n’y a aucune place pour elles dans Agile. Agile est devenu un club de membres – un club de membres Exclusifs – qui précisément exclut.
Cependant, tandis que les équipes de développement peuvent ne pas aimer les chefs de projet si ils commencent à leur dire comment faire leur travail, les organisations aiment les chefs de projet. Il y a bien plus dans la plupart des projets que la partie qui est visible aux équipes de développement. Les organisations comptent sur les chefs de projet pour s’occuper de tout ce travail en dehors du développement. C’est ainsi que l’organisation s’arrime aux projets. Il ne suffit pas d’enchanter le client, nous devons aussi enchanter notre organisation. Nous devons ouvrir la porte et laisser une plus large portion de l’organisation entrer dans notre monde Agile. Nous devons faire des Projets Agile pas seulement du Développement Agile.
