La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des Responsabilités sert à documenter les rôles et responsabilités de chacun dans le projet.
Cet outil, qui prend la forme d’un tableau (qui croise la structure de décomposition du projet/WBS et les ressources de l’organisation) permet au chef de projet de lister les participants au projet ainsi que leur(s) responsabilité(s).
Le RACI est l’exemple de RAM le plus utilisé, a pour point de départ le croisement de la structure de découpage de projet ou SDP/WBS avec les ressources du projet.
« Qu’est-ce qui différencie les projets des activités régulières ? »: Lors de votre prochain entretien pour un job de chef de projet, cette question pourrait fort bien vous être posée.
Une lettre d’un chercheur en physique au Laboratoire Lawrence Livermore du nom de Tom Hirshfield. Tom y partageait quelques principes de base qu’il avait personnellement trouvés utile dans son travail et à utiliser comme bon vous semble dans le votre.
Voici quelques-unes des étapes sur lesquelles je plancherais pour préparer un plan à 90 jours que je pourrais proposer à mon futur employeur dès les premiers entretiens…
partagez ce billet avec vos amis, collègues et relations professionnelles
Qu’est-ce que le Scrum of Scrums et comment fonctionne-t-il dans le processus de développement de produit ?
La première chose à savoir sur le Scrum of Scrums est qu’il devient pertinent seulement pour de grands projets où de multiples équipes Scrum sont impliquées. Dans ce processus, les représentants d’équipes Scrum se rassemblent pour la réunion Scrum of Scrums à intervalles de temps prédéterminés ou chaque fois qu’il est nécessaire de collaborer et suivre leurs progrès, obstacles et dépendances respectifs à travers les multiples équipes Scrum.
Qui participe ?
Normalement, un membre de chaque équipe Scrum représentera son équipe dans la réunion Scrum of Scrums. Dans la plupart des cas, c’est le Scrum Master, mais de temps en temps quelqu’un d’autre peut représenter l’équipe. Une unique personne peut être nommée par l’équipe pour la représenter à chaque réunion Scrum of Scrums, ou bien le représentant peut changer au fil du temps, en fonction de qui peut remplir au mieux le rôle en raison des questions et circonstances actuelles. Chaque participant à la réunion devrait avoir la compréhension technique et être capable d’identifier des situations dans lesquelles les équipes pourraient causer obstacles ou retards les unes aux autres.
D’autres participants importants de réunion Scrum of Scrums incluent Scrum Master en chef et le Propriétaire de Produit en chef. Le but principal de la réunion Scrum of Scrums est de communiquer sur la progression entre des équipes multiples. Le Scrum Master en chef (ou n’importe quel Scrum Master qui faciliterait la réunion Scrum of Scrums), peut proposer un ordre du jour avant la réunion. Cela permet à chaque équipe de considérer les sujets de l’ordre du jour en préparant la réunion Scrum of Scrums.
De quoi discute-t-on ?
Tous les obstacles rencontrés par une équipe et qui peuvent aussi affecter d’autres équipes, devraient être remontés ainsi ils peuvent être discutés. De plus, si une équipe prend conscience d’un gros problème, changement ou risque qui peut impacter d’autres équipes, il devrait être communiqué lors de la réunion Scrum of Scrums.
Book on Amazon
Les productions des rétrospectives de Sprint peuvent aussi élever des problèmes qui pourraient impacter de multiples équipes Scrum et pourraient être utilisées lors de la réunion Scrum of Scrums. Ces réunions sont de préférence brèves (mais d’habitude non limitées dans le temps pour favoriser davantage d’échanges d’information entre les équipes) auxquelles se joint un représentant de chaque équipe Scrum pour partager le statut de son équipe. La réunion Scrum of Scrums se tient à intervalles prédéterminés ou quand demandé par des équipes Scrum. Ces réunions facilitent le partage en face-à-face d’informations entre des équipes Scrum différentes des difficultés, des dépendances et des risques qui doivent être étroitement contrôlés. Ceci aide les diverses équipes travaillant sur un grand projet à mieux coordonner et intégrer leur travail. C’est la responsabilité du Scrum Master en chef (ou tout autre Scrum Master qui facilite la réunion Scrum of Scrums) de s’assurer que tous les représentants ont un environnement contribuant à partager ouvertement et honnêtement l’information, y compris les réactions des représentants d’autres équipes. Pour de plus grands projets, impliquant un nombre significatif d’équipes, de multiples niveaux de ces réunions peuvent être implémentés. Chaque représentant d’équipe Scrum fournira à son tour les avancées de son équipe.
On donne d’habitude ces éléments en répondant à quatre questions spécifiques.
Sur quoi mon équipe a-t-elle travaillé depuis la dernière réunion ?
Que mon équipe fera-t-elle d’ici la prochaine réunion?
Quel reste-t-il à faire à mon équipe pour répondre aux attentes d’autres équipes ?
Que mon équipe va-t-elle faire qui pourrait impacter d’autres équipes ?
Les réponses à ces quatre questions fournissent l’information qui permet à chaque équipe de comprendre clairement le statut du travail de toutes les autres équipes. On recommande qu’une salle de réunion dédiée soit rendue disponible pour la réunion Scrum of Scrums, où tous les représentants d’équipes Scrum sont à l’aise.
Pour quels bénéfices ?
Dans le processus Scrum of Scrums, les meilleures pratiques pourraient être documentées sur la façon de conduire la réunion Scrum of Scrums et des suggestions incorporées dans le travail de projet d’équipes Scrum individuelles.
Il peut aussi y avoir une équipe d’experts du sujet qui peuvent aider le Scrum Master en chef à faciliter la réunion Scrum of Scrums.
L’une des productions importantes de la réunion Scrum of Scrums est la coordination du travail à travers des équipes Scrum multiples. C’est particulièrement important quand il y a des tâches avec des dépendances inter-équipes. Les incompatibilités et contradictions entre le travail et les livrables d’équipes différentes sont rapidement exposées.
Ce forum donne aussi aux équipes l’occasion de présenter leurs accomplissements et donner des retours à d’autres équipes.
En utilisant la réunion Scrum of Scrums, il y a de la collaboration à travers toute l’organisation par opposition à des personnes travaillant dans des équipes renfermées et concernées principalement par leurs responsabilités individuelles. La réunion Scrum of Scrums est un forum où les membres d’équipe Scrum ont l’occasion de discuter des problèmes impactant leur projet d’une manière transparente.
Le besoin de livrer chaque Sprint à l’heure force les équipes à confronter activement de telles questions au lieu de reporter à plus tard la recherche de résolution. Cette discussion et résolution opportunes de questions dans la réunion Scrum of Scrums améliorent énormément la coordination entre des équipes Scrum différentes et réduit aussi le besoin de refaire et retravailler. Les risques liés aux dépendances et délais de livraison sont aussi atténués.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le Planning Poker est une façon commune de réaliser l’estimation des points d’histoire utilisateur. Il présente quelques avantages, mais aussi quelques problèmes.
Qu’est-ce que ce Planning Poker ?
Le Planning Poker est souvent utilisé dans des équipes Scrum (bien qu’il ne soit mentionné nulle part dans le guide Scrum selon la croyance populaire). Mike Cohn l’a popularisé dans son livre “Agile Estimating and Planning“. C’est une technique d’équipe pour collectivement estimer les points d’histoires d’utilisateur. (Pas sûr de ce que cela signifie ? Lisez le « guide to story point estimation »).
Si vous êtes déjà familiers du Planning Poker, n’hésitez pas à sauter directement plus bas “la planification d’alternatives au Planning Poker”. Sinon, continuez de lire pour une explication de comment cela fonctionne et pourquoi les gens l’utilisent.
CertYou est partenaire de DantotsuPM
Comment fonctionne-t-il ?
Disons que vous avez une équipe de sept ou huit personnes, qui ont environ une douzaine d’histoires d’utilisateur dans leur arriéré de produit qu’ils voudraient estimer. Pour le faire via le Planning Poker, chaque personne dans l’équipe aura une certaine méthode pour fournir un chiffre. C’est d’habitude via un sabot de cartes de poker, mais vous pourriez aussi utiliser une app sur votre téléphone. Les chiffres sont d’habitude des nombres de la suite de Fibonacci, une série où chaque nombre est la somme des deux nombres précédents. Donc cela donne 1, 2, 3, 5, 8, 13, 21, et cetera (on ne va d’habitude pas dépasser 21 parce que les histoires d’utilisateur ne devraient jamais être beaucoup plus grandes que d’autres).
L’équipe prend la première histoire de la liste et en discute un moment. Souvenez-vous, une histoire d’utilisateur est écrite comme une déclaration de problème. L’équipe réfléchit ensuite à combien de travail il faudrait pour répondre à cette déclaration de problème, c’est-à-dire mettre en œuvre une solution qui réalise le comportement décrit dans l’histoire.
Estimation de Planning Poker
Une fois que l’équipe est prête à estimer, chaque personne choisit un numéro de son jeu de cartes. Ils le font en silence. Puis, chaque personne révèle son évaluation en même temps.
La raison de procéder ainsi est que l’évaluation d’une personne ne devrait pas influencer l’évaluation d’une autre. Si chaque personne fournit son évaluation à son tour, la première personne pourrait choisir une grande (ou petite) estimation, qui pourrait faire changer d’avis d’autres personnes et ainsi biaiser leur évaluation. Le processus est destiné à permettre à chaque personne de fournir sa propre évaluation impartiale et honnête.
Bien sûr, les valeurs sont souvent différentes, ce qui signifie qu’une autre discussion démarre. Il y a parfois alors un autre round d’évaluation. Quelques puristes de Scrum insistent pour que l’équipe continue les rounds d’évaluation jusqu’à ce que chacun arrive au même nombre. Je pense que c’est de la folie et que cela encourage ce que le planning poker devrait empêcher : les gens « forçant » d’autres à être d’accord avec leur évaluation.
Je pense que cela devrait continuer jusqu’à ce qu’un consensus soit atteint, ce qui est d’habitude très clair (et PAS la même chose que la conformité, c’est-à-dire quand chacun a la même valeur). S’il y a une gamme d’évaluations consistant de 2, 2, 3, 3, 5, 5, l’estimation est de 3. Cela ne doit pas être une moyenne exacte, mais une médiane suffit. Et cela ne doit pas être mathématiquement précis. Les évaluations sont essentiellement des suppositions informées. Le processus d’évaluation n’est pas précis donc les évaluations ne le seront jamais et c’est ok.
Alors, pourquoi chercher des alternatives au Planning Poker?
Vous pourriez vous demander pourquoi vous voudriez des alternatives à le Planning Poker. Ce n’est pas un mauvais système, mais il a quelques problèmes.
Il est lent
Cela peut prendre une longue période de temps pour faire l’évaluation avec le Planning Poker. J’ai vu des sessions de deux ou trois heures et ce n’est pas amusant. Montrer ces cartes est au départ amusant mais cela devient usant vraiment rapidement. Tergiverser sur savoir si quelque chose vaut 2 ou 3 est ennuyeux et irritant et ce n’est pas une conversation de valeur.
Il distrait
La discussion sur quelle carte est bonne ou fausse peut distraire les gens d’une conversation de plus de valeur : la discussion de la solution. Particulièrement, pourquoi quelqu’un estime que quelque chose mérite 2 ou 3 par opposition à une autre valeur.
Il peut donner une fausse impression des estimations
Certaines personnes pensent que si vous faites ce jeu intelligemment, alors les évaluations elles-mêmes deviennent soudainement plus précises et donc de plus de valeur. C’est complètement faux. Le Planning Poker est une bonne façon d’atteindre un consensus sur des évaluations. Cela ne signifie pas qu’elles soient précises. Il est très possible pour un groupe de personnes d’être dans l’erreur à propos de quelque chose (particulièrement quelque chose de notoirement difficile à évaluer comme la complexité de développement de logiciel).
Les alternatives au Planning Poker
Il y a quelques alternatives que vous pouvez essayer si vous vous fatiguez du Planning Poker, ou pensez que cela pourrait être mieux.
Classement par taille de t-shirt
Au lieu des nombres (Fibonacci ou autres, vous pouvez utiliser des tailles de T-shirt. Petit, moyen, large, extra-large. Cela vous donne une plus petite gamme d’estimations possibles, ce qui signifie que vous obtiendrez moins de désaccords et moins de variance. Vous pourriez penser que les évaluations seront moins précises, mais je ne pense pas qu’elles le seront. Je constate que les tailles de t-shirt sont suffisantes. Vous aurez besoin de quelques références pour ces tailles; utilisez simplement des histoires ou des fonctions précédentes. (J’aime en réalité faire des évaluations de taille de t-shirt et aucune autre estimation d’histoire). Vous pourriez aussi utiliser un jeu plus réduit de nombres (1, 5, 8, 20) ou autre chose pour remplacer les tailles de t-shirt. Mais j’aime le fait que des nombres ne soient pas utilisés. Cela clarifie le fait que ce ne sont pas des mesures et elles ne sont pas précises.
Pour l’estimation précise, vous pouvez utiliser la technique du planning poker, ou la Technique « Affinity Mapping ».
Affinity Mapping
Vous pourriez être familiers avec la technique « Affinity Mapping » car elle est utilisée dans les Rétrospectives de Sprint. C’est une technique pour grouper ensemble des articles semblables. Commencez par créer une série d' »étiquettes » ou de « piles » sur la table : celles-ci pourraient être numérotés selon Fibonacci, ou les tailles de t-shirt, ou des catégories, ou quoi que ce soit. Puis, vous déposez les histoires sur la table comme des cartes. Ensuite, l’équipe déplace collectivement les cartes dans les piles pour les représenter selon leur estimation.
C’est une technique intéressante, peu commune et peu connue. C’est une manière efficace d’évaluer un grand nombre d’histoires dans un espace de temps très court. Commencez par définir vos points de référence (nombres de Fibonacci, tailles de t-shirt, etc). Créez des piles sur la table selon la technique « Affinity Mapping ». Ensuite, chaque personne est aléatoirement assignée un jeu d’histoires à estimer (peut-être en distribuant les histoires comme si elles étaient des cartes à jouer). Puis, à tour de rôle, chaque personne évalue en silence en plaçant une carte sur une des piles. Alternativement, une personne peut déplacer une carte d’une pile à une autre, si elle est convaincue qu’une estimation est incorrecte.
Continuez à faire ceci jusqu’à ce que toutes les cartes soient estimées. Si une carte est déplacée deux fois, ôtez-la de la table – elle aura besoin d’une discussion séparée après la réunion car il y a un fort désaccord sur son estimation.
L’avantage de cette technique est qu’une équipe peut évaluer beaucoup d’histoires en un très court laps de temps. A utiliser si l’on vous demande d’évaluer 100 histoires (même si je pense que c’est le signe d’un plus gros problème car vous devriez seulement évaluer un ou deux sprints d’histoires Utilisateurs à l’avance). L’inconvénient est que vous sautez ce qui est souvent la partie de plus de valeur : la discussion autour des histoires.
Aucune évaluation
D’autres personnes prennent une position plus extrême. Ils pensent que nous devrions nous débarrasser totalement des estimations ! C’est un mouvement qui est souvent identifié par le hashtag Twitter #NoEstimates. Il a été lancé il y a quelques années par quelqu’un appelé Woody Zuil et est principalement soutenu par un coach Agile nommé Vasco Duarte. Si vous voulez l’essayer, c’est facile : n’abandonnez pas seulement le Planning Poker, abandonnez aussi toute estimation. Vous pouvez alors faire deux ou trois choses :
Donnez une évaluation moyenne sur toutes les histoires (utilisez une moyenne historique, total ou roulant la moyenne des trois derniers sprints)
Oubliez les points d’histoire et utilisez juste le nombre d’histoires pour la planification
Oubliez le planning d’histoires et estimez par fonctionnalité, utilisant probablement des tailles de t-shirt / le nombre de sprints.
En ce qui me concerne, je tombe dans le dernier camp. Je ne pense pas que les évaluations d’histoire sont très forte valeur, bien que des évaluations de haut niveau de fonctionnalités soient utiles pour la planification de release (et j’ai constaté qu’elles sont souvent aussi ou plus précises qu’une somme d’évaluations de point d’histoire).
#NoEstimates est un sujet complexe et très controversé et qui mérite une discussion séparée.
Conclusion
Vous pouvez essayer ces techniques et voir ce qu’en pense l’équipe. Assurez-vous de les considérer comme des expériences et recueillez-en les données: L’équipe estime-t-elle que c’est mieux que le planning poker ? Les évaluations se sont-elles avérées de plus de valeur ?
Rappelez-vous que la chose qui a le plus de valeur dans une session d’estimation est d’habitude les conversations autour de la solution, pas les nombres estimés.
partagez ce billet avec vos amis, collègues et relations professionnelles
Les membres des équipes Scrum, participants aux formations, collègues et parties prenantes diverses impliquées dans des projets de mise en œuvre Agiles/Scrum posent souvent les mêmes questions sur les histoires d’utilisateur (User Stories). Ci-dessous, une liste de questions et réponses que je partage avec vous. J’espère que ces informations seront utiles à quiconque veut en apprendre davantage sur les histoires d’utilisateur.
Q: Que sont les histoires d’utilisateur (User Stories) ?
Une histoire d’utilisateur est une brève description de tout besoin fonctionnel. Elle est écrite d’une perspective utilisateur pendant ou avant la priorisation de l’arriéré de produit (Product Backlog) ou une session de planification de Sprint (Sprint Planning). Une histoire peut inclure, mais n’est pas limitée à, une fonctionnalité avec ses caractéristiques et ses règles de gestion, des demandes d’amélioration, des corrections de bogue, l’installation d’infrastructure, ou une documentation technique. Les histoires d’utilisateur peuvent représenter presque n’importe quelle activité pendant le cycle de vie du développement logiciel.
Q: Comment les histoires d’utilisateur sont-elles apparues ?
Il n’y a aucune date spécifique ou événement rapportés sur l’origine des histoires d’utilisateur. Cependant, la littérature suggère que les histoires d’utilisateur ont évoluées pendant le processus de collecte et de mûrissement des besoins qui ont été à l’origine documentés sous forme de cas d’usage. Des « programmeurs extrêmes » à la fin des années 1990 ont rendu les histoires d’utilisateur populaires dans l’arène du développement logiciel. Des approches Agiles plus récentes, comme Scrum et Kanban, ont aidé à largement promouvoir l’usage massif les histoires d’utilisateur.
Q: Comment dois-je écrire une histoire d’utilisateur ?
Le format le plus populaire pour écrire des histoires d’utilisateur dans beaucoup d’approches Agiles est comme suit :
En tant qu’utilisateur (du système), je veux faire (action) pour que (les bénéfices à avoir cette fonctionnalité).
Par exemple, « En tant qu’étudiant, je veux voir mes notes pour connaitre ma performance. »
Q: Qui est responsable d’écrire les histoires d’utilisateur ?
Il n’y a aucun rôle spécifique responsable d’écrire une histoire d’utilisateur. Toute personne impliquée dans le processus de développement logiciel, des parties prenantes du métier aux membres de l’équipe Agiles, peut écrire des histoires d’utilisateur. Cependant, beaucoup d’histoires sont écrites pendant la session de revue de l’arriéré de produit par les membres de l’équipe de développement, comme les programmeurs, testeurs et analystes, ainsi que le propriétaire de produit (Product Owner).
Q: Quelles sont les qualités d’une bonne histoire d’utilisateur ?
Une histoire d’utilisateur idéale devrait être courte, simple et sans équivoque. Beaucoup de partisans Agiles considèrent le modèle de Bill Wake INVEST comme une base pour une bonne histoire.
Q: Les histoires d’utilisateur exigent-elles une approbation ?
qui approuve une histoire utilisateur ?
Contrairement aux exigences opérationnelles ou aux documents dans des approches de développement logicielles traditionnelles, aucun processus formel n’existe pour approuver des besoins dans un environnement Agile. Et les histoires d’utilisateur ne sont pas les seules fonctionnalités, donc ce sont les membres de l’équipe Agile qui acceptent les histoires quand la plupart d’entre eux sont confiants sur la capacité à livrer cette histoire en une itération. Tous les doutes sur une histoire d’utilisateur sont clarifiés par le propriétaire de produit dans le cadre de Scrum.
Q: Quels sont trois Cs des histoires d’utilisateur ?
En 2001, Ron Jeffries Proposé le concept de trois Cs : Carte (fiche), Conversation Et Confirmation, pour atteindre le consensus sur une histoire de la part des parties prenantes dans le cadre Agile.
La Carted’histoire est écrite sur une fiche, qui est souvent un Post-it®.
La Conversationest une série de discussions entre l’équipe de développement et les parties prenantes internes et externes pour comprendre la complexité et la valeur de l’histoire.
La Confirmationdoit s’assurer que la conversation tournant autour de l’histoire est parvenue à une conclusion.
Q: Quelles sont les différences entre un cas d’usage (Use Case) et une histoire d’utilisateur ?
Bien le cas d’usage et l’histoire d’utilisateur semblent semblables et que beaucoup de personnes les confondent comme une des façons de décrire des besoins, ils sont différents de bien des façons, comme suit :
Histoires d’utilisateur et tâches :
Les membres de l’équipe exécutent des tâches basées sur l’ensemble d’activités pour construire une fonctionnalité, comme exprimé dans l’histoire d’utilisateur. Par exemple, l’histoire d’utilisateur est: Comme un acheteur de mon futur domicile, je veux voir la liste de maisons dans mon voisinage pour que je puisse faire une liste des maisons candidates sélectionnées que je veux acheter.
Les tâches pour l’histoire pourraient être:
Codage, utilisation de la logique appropriée
Intégration d’APIs de recherche et de cartographie
Développement de scénarios de test
Intégration avec des sources de données
Finalisation de filtre de sélection
Les histoires d’utilisateur sont mesurées de manière relative avec des tailles comme S, M, L, XL, etc., ou en utilisant la séquence de Fibonacci : 1, 2, 3, 5, 8, 13 …, basée sur la complexité de développement des histoires. Les tâches sont toujours calculées en heures et sont basées sur le niveau d’effort que chaque membre doit fournir pour chacune des tâches.
CertYou est partenaire de DantotsuPM
Histoires d’utilisateur et épopées
Une épopée est un jeu de fonctionnalités qui ressemblent à une histoire au début, mais quand les membres de l’équipe commencent à l’analyser, ils constatent qu’elle pourrait être plus grande que précédemment envisagé. Donc ils doivent la décomposer en de multiples histoires. Une façon de différencier une épopée d’une histoire est en vérifiant qu’elle suit le modèle INVEST discuté plus tôt.
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.
Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue, de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.
AVERTISSEMENT : que faire avant que vous n’adoptiez ces pratiques Agiles
N’adoptez pas de pratiques Agiles simplement pour suivre les foules.
Comprenez les bénéfices que vous tirerez à incorporer des pratiques Agiles. Vous économiserez du temps et de l’argent en obtenant des réactions des clients et en livrant le bon produit. Vous travaillerez plus intelligemment avec une communication accrue et transverse dans l’équipe et des pratiques de travail améliorées.
Discutez avec votre équipe et obtenez leur adhésion. Le changement sera un effort d’équipe et vous aurez besoin de leur collaboration et coopération. L’équipe entière doit être à bord. Vous ne pouvez pas réussir seul.
Partagez vos idées avec l’équipe sur pourquoi vous voulez le faire. Découvrez les idées et préoccupations de vos coéquipiers. Assurez-vous qu’ils sont ouverts à faire un essai. Vous devrez vous lancer avec leur appui, parce qu’ils font aussi partie du jeu.
Voici 3 pratiques Agiles que vous pouvez déjà commencer à utiliser:
1. Standup Quotidien
Bénéfices : transparence et communication accrues dans l’équipe.
Votre équipe aura une plus grande compréhension de la progression et des défis. Le chef de projet peut « mener » si nécessaire, mais les équipes Agiles s’auto-organisent et peuvent le faire elles-mêmes si le chef de projet n’est pas là.
Comment le faire : c’est une réunion très courte (15 minutes ou moins) qui donne chaque jour une occasion à l’équipe de faire un point et partager l’information.
Chaque membre d’équipe répond brièvement à ces trois questions :
Qu’avez-vous fait hier ?
Sur quoi travaillez-vous aujourd’hui ?
Y-a-t-il des obstacles vous empêchant de faire votre travail ?
Dans le Scrum traditionnel, le scrum master élimine les points de blocage, mais le chef de projet peut aussi le faire.
Avertissement : ce n’est pas une réunion de statut d’avancement de 30 minutes. Ce n’est pas une longue discussion sur les détails. Cela devrait plutôt être très court : 15 minutes ou moins. C’est un rendez-vous pour votre équipe chaque jour pour rester à niveau. Si l’équipe doit discuter de plus de détails, faites-le après le stand up.
Un de mes amis a suggéré à son chef qu’ils s’y essaient. Ils avaient des très longues réunions de statut de projet. Son patron a accepté et aimé l’idée. Mais au lieu que ce soient les membres de l’équipe qui aient une réunion quotidienne rapide, son chef la dirige. Pis encore, le stand up s’est métamorphosé en réunion de statut prolongée tous les jours : une situation pire qu’avant. Évitez la tentation de faire traîner le stand up. Tenez l’agenda et le rythme et gardez les longues conversations pour après le stand up.
2. La Rétrospective
Bénéfices : amélioration continue.
Votre équipe identifiera des façons de s’améliorer pendant le projet, plutôt que d’attendre jusqu’à ce que le projet soit fini. Vous y gagnerez les bénéfices d’améliorations continues tout au long du projet.
Comment le faire : à divers moments pendant le projet, l’équipe évalue son efficacité.
Livre sur Amazon
Il y a 3 questions clefs à poser :
Qu’est-ce qui a fonctionné bien pour nous ?
Qu’est-ce qui n’a pas bien marché ?
Que pouvons-nous faire différemment pour nous améliorer ?
Choisissez divers moments pendant le projet pour mettre en œuvre cette pratique Agile. Une fois que vous avez fait l’exercice et identifié des choses que vous pouvez améliorer, choisissez-en une ou deux à cibler les premières. Incorporez ces changements et voyez comment ça va. Répétez ensuite ce processus pendant le projet.
Votre équipe peut incorporer des améliorations tandis que le projet est toujours en voie de réalisation, plutôt qu’attendre jusqu’à ce que le projet soit fini.
Notez : Il doit y avoir un environnement de confiance et de soutien entre les membres de l’équipe. Ne critiquez personne pour des suggestions faites. Ne blâmez pas de membres pour des fautes, mais identifiez plutôt des façons de vous améliorer. Soyez ouvert à considérer les challenges comme des opportunités.
3. Démonstrations de logiciel au client
Bénéfices : transparence et collaboration avec le client.
Les clients bénéficient de voir le produit en l’état et en partageant leurs réactions. L’équipe obtient l’avantage de retours des client sur n’importe quels ajustements nécessaires.
Comment le faire : Démontrez un logiciel qui fonctionne au client à des points appropriés en cours de développement. N’attendez pas jusqu’à ce que tout ce soit prêt pour les tests d’acceptation de l’utilisateur final.
Ce n’est pas une présentation PowerPoint. Vous montrez le logiciel réel. Ne cherchez pas de tape à l’œil ni perfection. Votre but est de montrer au client comment le produit progresse et d’obtenir des réactions. Vous ne devez pas louer une énorme salle de conférences et faire des PowerPoint tapageur. Vous ne montrez pas de produit fini pour l’instant.
Gérez les attentes du client sur ce que vous montrez. Vous ne voulez pas les étonner s’ils s’attendaient à quelque chose d’autre. Assurez-vous qu’ils sont conscients que c’est un premier jet et pas le produit fini. Expliquez pourquoi vous le faites et ce que vous espérez y gagner.
CertYou est partenaire de DantotsuPM
C’est un Voyage
Adoptez un esprit de collaboration, de communication et d’amélioration continue. Faites-le avec respect pour tous vos membres d’équipe pendant que vous adoptez de nouvelles pratiques.
Soyez patient avec eux. Vous n’atteindrez pas tout de suite la perfection. Mais vous en bénéficierez et l’aimerez probablement, aussi.
Maintenant que nous avons vu ces 3 pratiques Agiles, vous pouvez probablement voir comment les utiliser même si vous ne vous lancez pas à fond dans Agile.
Il n’y a désormais plus aucune raison de vous sentir exclu. La prochaine fois que vos amis scrum masters parleront Agile, vous pourrez vous joindre à eux.
Dites-leur les façons dont votre équipe s’en sert pour s’améliorer et combien vos clients en sont heureux.
Et ces autres amis qui ne l’ont pas encore essayé ? Partager votre amitié en partageant cette information avec eux !
partagez ce billet avec vos amis, collègues et relations professionnelles
Quelqu’un qui a passé du temps dans le cycle de vie de développement de logiciel traditionnel peut certifier que le principe Agile d’accueillir des exigences changeantes peut s’avérer le plus difficile pour des organisations basculant vers Agile. Dans le cycle de vie traditionnel, changer les besoins génère de la frustration, de la colère, du désespoir et, dans certains cas, des frais d’avocats et des coûts additionnels.
CertYou est partenaire de DantotsuPM
Le mouvement Agile demande que les clients et les organisations de développement travaillent ensemble et embrassent le changement pour le plus grand bénéfice de l’utilisateur final. Ce niveau de transparence exige que les murs tombent entre clients et développeurs. Il nécessite aussi que le client reconnaisse l’impact que le changement aura sur le projet et le coût complémentaire du changement sur le budget de projet, ainsi qu’acquérir un meilleur niveau de compréhension du travail.
Le client et les développeurs atteignent une compréhension mutuelle
Dans une mauvaise mise en œuvre de Agile, les clients pensent qu’ils peuvent changer les exigences aussi souvent qu’ils le souhaitent et que le personnel de développement doit gérer ces changements. « Hé, vous avez dit que vous étiez Agiles, non ? »
Dans une bonne mise en œuvre, le client et le développement travaillent ensemble en étroite collaboration pour examiner et adapter le produit à chaque occasion possible. Comme le produit est revu fréquemment, le client et l’équipe maintiennent une compréhension partagée de l’état actuel du produit et de l’état actuel du marché. Quand le client change des exigences, le changement, son coût de mise en œuvre et son impact sur le projet dans son ensemble, sont mutuellement compris.
Jeff Sutherland utilise l’expression « Money for nothing and your change for free » (« l’Argent pour rien et votre changement gratuit ») quand il conseille des organisations sur la façon d’écrire des contrats Agiles (ndlt. Tiens, je ne savais pas que Jeff est fan de Dire Straits). En essence, on tient compte des deux côtés pour avoir une flexibilité maximale; l’équipe de développement tient compte d’exigences changeantes sans modifier le contrat ni charger des honoraires de modification et, en échange, le client consent à participer conjointement au processus Agile et au cycle de vie du développement de logiciel. Dans le cas où le client est satisfait avec moins de travail que prévu à l’origine, ils peuvent finir le contrat plus tôt, avec le paiement d’une partie prédéterminée du contrat restant.
Le changement est bon
La position est que le changement est bon. Il permet au client de satisfaire l’utilisateur final avec les fonctionnalités de plus forte valeur et de terminer le contrat au plus tôt. Il permet à l’entité de développement de recevoir la juste compensation pour livrer tôt et leur permet de se passer à l’opportunité suivante.
avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets
« Accueillir des changements dans les exigences, même tard dans le développement » ne signifie pas que le propriétaire de produit, le « Product Owner », est libre d’ajuster les critères d’acceptation après que le sprint ait commencé. Les processus Agiles qui exploitent le changement pour y gagner un avantage compétitif devraient être mis en œuvre avant l’exécution de sprint. De l’avis de tous, il existe un processus pour terminer un sprint plus tôt; cependant, c’est rare.
Les processus agiles facilitent l’élaboration progressive, la décomposition, le raffinement de l’arriéré de produit, une approche incrémentale et la planification de sprint; Ils exploitent pleinement le changement tout en protégeant l’équipe.
partagez ce billet avec vos amis, collègues et relations professionnelles
La co-localisation est souvent considérée comme un activateur sinon un facteur critique de succès pour réussir le projet.
Alors que cela fait sens pour de petites équipes, comme nous prenons en charge de plus grands produits et projets, il n’est pas toujours faisable d’avoir tout le monde dans la même pièce. Les canaux de communication ne s’accroissent pas linéairement quand la taille d’une équipe grossit et à un certain point cela deviendra impossible d’un point de vue logistique immobilière ou d’une perspective d’efficacité.
Comme la taille d’une initiative grandit, la décomposition de la portée en composants ou lignes de fonction peut permettre la distribution de lots de travail auto-contenus à des équipes plus petites dont les membres pourraient être co-localisés pour réduire le besoin de constante communication. Avoir de telles équipes géographiquement distribuées ne devrait pas être un problème tant que l’on conserve l’opportunité de cérémonies telles que les Mêlée de Mêlées (Scrum of Scrum) pour manager les interdépendances, maintenir l’alignement dans la cadence des releases et remonter les obstacles partagés au bon niveau de résolution.
Livre sur Amazon
Avec une approche distribuée, il est souvent tentant d’utiliser un modèle de travail purement virtuel, particulièrement sur de grandes initiatives où il pourrait y avoir un coût important à rassembler tout le monde de temps à autre. Bien que cela fasse sens au niveau économique à court terme, l’avertissement de Simon Sinek « Leaders Eat Last » ne devrait pas être ignoré : “plus de gens deviennent abstraits, plus nous sommes capables de leur faire mal.”
Sinek fait référence aux expériences de Milgram au début des années 1960 où on a donné aux sujets d’étude l’opportunité de faire mal à quelqu’un d’autre. Alors que seulement 30 % de ces volontaires étaient capables de poursuivre l’expérience quand ils étaient témoins de la douleur (simulée) qu’ils causaient, 65 % étaient capables de le faire quand ils ne voyaient jamais à qui ils faisaient mal.
Notre problème très actuel de « cyber intimidation » est un autre brillant exemple de cela. Tandis que nous sommes toujours biologiquement des animaux sociaux, l’anonymat et la séparation créée par l’Internet et les plates-formes des médias sociaux réduit les impacts personnels d’infliger de la souffrance.
La confiance est aussi difficile à cultiver quand nous n’avons pas rencontré ceux avec qui nous travaillons. Bien que nous espérions que nos collaborateurs nous traiteront comme ils voudraient être traités, il est ardu de sentir psychologiquement en sécurité avec eux s’ils sont juste pour nous une adresse électronique ou un avatar de messagerie instantané. Comme Sinek l’a dit “La confiance ressemble à la lubrification. Elle réduit la friction et crée des conditions beaucoup plus propices à la performance.”
Nous pouvons avoir les différences d’opinions au travail, mais si nous avons rencontré et avons eu l’occasion de socialiser à l’extérieur du bureau, il est beaucoup plus facile de se voir et se traiter comme des êtres humains.
Économisez au besoin, mais n’éliminez pas d’opportunités pour vos équipes de se rencontrer en personne.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
L’expression “ Meilleure Pratique” fait partie de notre lexique depuis plus de ans. Elle est utilisée pour décrire quasiment tout : comment nous manageons les opérations, comment nous recrutons et licencions, comment traiter au mieux les patients atteints de maladie mortelle, comment nous dirigeons nos équipes sportives.
L’expression est devenue omniprésente. Mais y-a-t-il vraiment et réellement des pratiques « les meilleures » qui s’appliqueront dans tous les contextes pour toute organisation ?
Pratique et Contexte
Scott Ambler, qui est bien connu dans le monde Agile, challenge l’assomption qu’il peut y avoir une bonne pratique recommandée qui soit la meilleure dans tous les cas. Au lieu de cela, il propose une alternative, “la pratique contextuelle” dans laquelle la notion de ce qu’est « la meilleure » variera en fonction du contexte.
Le concept de la meilleure pratique, quand introduit dans notre lexique avait pour intention de capturer ce qui avait censément réalisé des résultats définis sur une base cohérente pour quelqu’un dans un certain contexte. Et là se trouve l’apparente simplicité et aussi son manque d’applicabilité directe ailleurs “quelqu’un dans un certain contexte”.
Tous nos contextes sont aussi différents que nous le sommes.
Scrum parle de « cérémonies » qui sont quelque peu la même chose que des pratiques – sauf que les cérémonies sont d’assez haut niveau, assez simples et il est facile de voir comment vous en respectez l’esprit et l’intention quand vous les appliquez sans être aussi doctrinaires que les promoteurs de la “meilleure pratique” le sont généralement . Quoique j’ai récemment vu un tweet disant “Nous sommes Agiles. Sauf quand on en vient à nos processus”. Je vous laisserai réfléchir sur ce tweet …
Agile dans un sens général est plus une question de comportements qu’autre chose. C’est quand nous essayons de faire Agile plutôt que démontrer de l’agilité que nous retrouvons nous-même dans ces débats et commençons à ajouter ce qui au mieux a potentiellement peu de valeur et au pire détruit notre capacité de faire preuve d’agilité.
CertYou est partenaire de DantotsuPM
Je crois que cette attention à ajouter des qualificatifs comme bonne ou meilleure empêche en fin de compte notre capacité de créer un écosystème agile.
“La meilleure Pratique” a-t-elle vu le jour ?
Ce qu’une personne peut penser être une « meilleure pratique », peut amener l’effet opposé pour quelqu’un d’autre dans un contexte différent.
Livre sur Amazon
David Marquet dans « Turn the Ship Around » raconte pendant ses discours que mettre en oeuvre certaines des pratiques on lui a appris pour les sous-marins nucléaires qu’il a été à l’origine formé pour commander, aurait été un échec sur celui qu’il a commandé. Heureusement, un membre de son équipage l’a alerté. Cette sorte d’effet inverse peut coûter des vies. Bien que les pratiques puissent avoir été « les meilleures » sur son premier commandement, elles auraient été catastrophiques sur son poste actuel. Le contexte avait changé. Pensez-y.
De la description du livre : “il a fait du bateau le plus mauvais le meilleur défiant l’approche de disciple-leader traditionnelle de la Marine américaine et mettant en œuvre au lieu de cela sa propre structure leader-leader.”
Rod Collins dans son livre, Wiki Management, décrit 50 pratiques différentes qu’un petit groupe de sociétés d’avant-garde utilise pour s’adapter à la vitesse du changement, plutôt qu’essayer de manager le changement.
Selon Collins :
“Comme les managers luttent pour aller aussi vite que les changements dans leur environnement, ils prennent de plus en plus conscience d’un problème très dérangeant. Ils découvrent que les méthodes et les pratiques qui délivraient toujours des résultats prévisibles de par le passé ne fonctionnent plus désormais.
Livre sur Amazon
Les prévisions deviennent soudainement incertaines comme de nouvelles technologies perturbatrices réorganisent radicalement les marchés. La réduction des coûts n’aboutit pas nécessairement des améliorations en efficacité et en productivité. Les méthodes analytiques prouvées sont maintenant trop lentes et inefficaces pour se maintenir à niveau avec un monde en rapide changement. Et mettre plus de contrôle semble mener les sociétés à perdre le contrôle et parfois leur business.
Dans un monde où le changement est une constante et les règles établies depuis longtemps semblent me plus travailler marcher, il n’est pas surprenant que beaucoup de managers se sentent dépassés par ce qui semble être complètement ingérable. ”
Collins a ajouté un avertissement sur ses cinquante pratiques que pas toutes fonctionneront dans tous les contextes et que même celles que vous considérez vraiment utiliser devront probablement être adaptées à votre contexte.
Remarquez qu’il n’a simplement utilisé le terme de « pratiques » dans qualificatif comme meilleures ou bonnes, seulement des pratiques. Se focaliser sur l’adoption et l’application de pratiques d’autres personnes se base sur le modèle de management hiérarchique traditionnel qui est fondé sur “ le leader omniscient” qui dit aux gens que faire.
Collins a aussi observé que beaucoup de questions challengeant les organisations modernes passent de problèmes discrets à des désordres holistiques. Les hiérarchies traditionnelles sont intrinsèquement inefficaces quand une rapidité de processus décisionnel est nécessaire pour manager à la vitesse des changements et résoudre ces désordres holistiques.
Ces désordres holistiques sont aussi beaucoup trop complexes pour que n’importe quel leader individuel puisse avoir toutes les réponses et solutions. De même ce serait de la folie pure que de supposer que nous pouvons prendre des pratiques inventées dans un contexte différent du nôtre et les appliquer sans plus de réflexion. Vous avez besoin de collaboration chez vos leaders et équipes pour co-créer les solutions qui peuvent marcher dans votre contexte.
Donc nous ne devrions pas perdre espoir en notre propre créativité et compréhension en appliquant simplement les pratiques d’autres personnes – c’est OK de considérer les avis et les idées d’autres (l’accent est mis sur le pluriel), mais si nous ne comprenons pas vraiment quelle est la pratique, comment l’appliquer, quand ne pas l’appliquer, ou si nous ne comprenons pas quand la pratique est faible ou inexistante dans un certain secteur compatible avec notre contexte, alors nous devenons ce que j’appelle un mouton de Panurge (Lemming Method). Nous suivons aveuglément quelque chose que nous ne comprenons fondamentalement pas.
Les qualificatifs ajoutent peu aux idées subjectives. Nous pouvons dire qu’une voiture est plus rapide qu’une autre en réalisant des mesures simples. Mais tant de choses peuvent affecter les résultats que nous obtenons du même jeu de pratiques utilisé par une autre équipe – même dans la même organisation – sans parler d’autres organisations et autres industries.
Nous avons besoin d’être capables de déterminer si incorporer les pratiques de quelqu’un d’autre dans notre propre cas nous apportera quelque chose de valeur.
Obtenons-nous de la valeur de cette pratique ?
Nous devrions toujours nous poser deux questions avant d’adopter les pratiques de quelqu’un d’autre :
Quelle valeur supplémentaire obtiendrai-je je n’ai pas déjà ?
Cela vaut-il le coût de mettre en œuvre cette pratique pour obtenir cette valeur additionnelle ?
Il y a des tas de pratiques de valeur égale ou d’une certaine valeur, sur n’importe quel sujet ou question à laquelle vous pouvez faire face. Il appartient à chaque personne ou équipe de trier comment adapter les pratiques des autres pour pouvoir les appliquer dans leur contexte pour obtenir quelque chose de plus auquel ils accordent de la valeur.
Ce sont des êtres humains, laissent les réfléchir!
Ester Derby a observé que “des adultes signent des contrats, choisissent des camarades de travail, élèvent des enfants et prennent toutes sortes de décisions importantes. Pourquoi nous attendons-nous à ce que ces mêmes adultes aient besoin de supervision rapprochée quand ils viennent travailler ?”
Bonne question !
Les pratiques qui fonctionnent pour une équipe, peuvent échouer misérablement pour une autre. Il peut y avoir quelques vérités générales, mais il n’y en a aucune d’absolue.
Les gens doivent être capables et être encouragé à utiliser leur propre jugement, créativité et compréhension dans le choix de ce qui pourrait aller dans leur contexte, en adaptant les pratiques d’autres personnes à leur situation. Qui sait ? Ils pourraient même en inventer de nouvelles mais seulement si vous, en tant que leader, désirez créer l’environnement dans lequel cela peut arriver.
Bien qu’il y ait des tas de pratiques que vous pouvez vouloir, c’est à vous et vos équipes de décider de manière collaborative ce qui est bon pour votre organisation et dans votre contexte. Et si ce n’est pas bon ? Ne l’utilisez pas. Ou créez vos propres pratiques. Maintenant il y a une réflexion.
Cela ne signifie pas que vous ne pouvez pas apprendre des autres en examinant leurs pratiques.
Cela signifie que vous et vos équipes devriez avoir tant la confiance que le courage de considérer la création de vos propres pratiques appropriées à la résolution de vos propres désordres. Ou bien, combiner des aspects de différentes pratiques avec vos propres adaptations. Et soyez prêts à rapidement faire des adaptations en fonction de ce que vous observez. Et faites preuve d’assez de confiance pour laisser vos équipes et leurs membres réaliser ces adaptations.
CSP est partenaire de DantotsuPM
L’idée de meilleures pratiques est née d’une ère qui se termine.
Celle des hiérarchies et du management traditionnels qui disent aux gens que faire, quand et comment le faire et pour combien de temps le faire. Pour un nombre croissant d’organisations, la rapidité des changements dans notre monde moderne écarte le fait de faire simplement ce que font tous les autres. De plus ce n’est pas très amusant non plus.
Amusez-vous avec vos pratiques, quelles qu’elles puissent être et partout où vous pourriez les trouver. Vous ne devez pas devenir un mouton de Panurge.
partagez ce billet avec vos amis, collègues et relations professionnelles
Décomposer les projets en périodes de temps limitées et connues comme les sprints ou itérations est souvent associé aux approches Agiles, mais peuvent aussi être utilisés pour délivrer par rapport à des exigences détaillées sur un projet complet selon l'(infâme) approche prédictive généralement nommée « en cascade ».
L’avantage est que cela aide à focaliser une équipe sur un jeu d’articles de travail petit, réalisable, et donnant aux parties prenantes de fréquentes occasions de réagir sur des lots de travail achevés en augmentant la transparence et l’objectivité des rapports d’avancement.
Les approches Agiles encouragent la priorisation de l’arriéré de travail et cela peut aussi être une bonne pratique en utilisant des sprints sur des projets traditionnels. Mais cette priorisation pourrait ne pas être suffisante de produire le niveau souhaité d’énergie et de focus de l’équipe. Alors, pourquoi ne pas mettre sur l’agenda permanent de l’équipe de définir des objectifs spécifiques à chaque cérémonie de planification de sprint ?
Les objectifs de sprint peuvent aider en :
Fournissant une mesure de progrès allant au-delà de la livraison d’individuels articles de travail de l’arriéré de produit. Des objectifs de sprint significatifs donnent des événements marquants à célébrer !
Donnant de la visibilité aux accomplissements qui dépassent la livraison du contenu planifié. Par exemple, terminer tous les articles de travail du sprint avec zéro défaut. Ou bien, compléter tous les engagements du sprint sans exiger d’heures supplémentaires de la part des membres d’équipe. Voici 2 choses qui méritent d’être célébrées.
Aidant l’alignement et le focus de l’équipe de livraison et des parties prenantes principales sur un objectif clairement partagé. Cela peut encourager l’autodiscipline dans l’équipe qui peut utiliser l’objectif de sprint comme un déterminant clé pour déterminer si un nouvel élément de travail proposé mérite ou pas d’entrer dans l’arriéré de sprint.
CertYou est partenaire de DantotsuPM
Les objectifs de sprint ne devraient pas être dictés, ils devraient plutôt émerger de la méthode globale de travail collectif de l’équipe et sont un bon contrôle de si l’équipe est alignée sur la vision complète du projet.
En définissant des buts, l’habituel acronyme SMART (Spécifique, Mesurable, Réalisable, Approprié et Temporel) peut être utilisé pour les évaluer et les affiner.
À la fin d’un sprint, la démonstration devrait inclure une présentation des objectifs et si vraiment ils ont été atteints et la cérémonie de rétrospective de l’équipe devrait inclure leur examen et l’identification d’idées d’objectifs pour améliorer les sprints futurs.
Comme l’a dit Albert Einstein: “si vous voulez vivre une vie heureuse, liez-la à un but, pas aux gens ni aux choses.”
Selon Lyssa Adkins, les coach Agile doivent pouvoir enseigner l’approche Agile à leurs équipes en moins de 10 minutes ! Voici ce qu’elle suggère de dire (en anglais).
partagez ce billet avec vos amis, collègues et relations professionnelles
Il y a beaucoup de fausses idées sur l’Arriéré de Produit. En fait, je dirais que c’est probablement l’artefact le moins bien compris de Scrum. Et cela peut causer de gros problèmes, pas seulement pour votre produit et son planning, mais pour vos développeurs également. Étant un propriétaire de produit et manager cette chose est un travail difficile et il est facile se tromper. Cet article dissipera certaines des fausses idées sur l’arriéré de produit.
L’Arriéré de Produit n’est pas une liste géante d’histoires utilisateurs
Beaucoup de gens pense que l’arriéré de produit est essentiellement une grande liste d’histoires d’utilisateurs, classées de la plus haute à la plus faible priorité. Comme si vous aviez un grand tableau et chaque ligne dans le tableau était une histoire d’utilisateur, avec un identificateur, un nom et une description et c’est votre arriéré.
Cela semble agréable et simple, mais c’est un arriéré de produit épouvantable, pour nombre de raisons :
Les histoires ne sont reliées l’une à l’autre d’aucune façon significative
Il n’y a aucune dépendance entre les histoires
Les histoires sont non seulement sans rapport l’une avec l’autre mais elles ne sont liées à aucun horizon particulier ou version
Il n’y a aucune explication “de l’image plus grande” sur comment les histoires touchent au produit, ses fonctions et sa vision.
Un arriéré de produit est vraiment une feuille de route
Un bon arriéré de produit commence par une feuille de route, qui est une vue très de haut niveau de l’avenir du produit. Il y a évidemment beaucoup de choses que nous ne savons pas au commencement, mais un propriétaire de produit devrait commencer par une feuille de route et une vision de comment le produit pourrait se développer puis commencer à décomposer ce plan en des fonctionnalités ou des épopées et des versions ou des horizons.
Il s’agit d’une feuille de route
Cela vous permet de :
Rapprocher des histoires l’une de l’autre, via une fonction ou une épopée
Donner les dépendances entre histoires
Définir les fonctionnalités et épopées et quelle valeur elles fournissent et pourquoi vous les construisez.
Les fonctionnalités et épopées peuvent entrer dans l’arriéré. Et elles peuvent avoir leur propre description avec valeur, risque, bénéfices, dépendances et critères d’acceptation définis. Elles peuvent être évaluées et priorisées. Tout cela fournit “l’image plus grande”, la « big picture ». Si vous avez juste une liste d’histoires, comme quelqu’un l’a une fois dit, vous avez “un sac de feuilles, au lieu d’un arbre”.
Un arriéré de produit devrait être un arbre, pas un sac de feuilles
Donc vous voulez vraiment des histoires dans votre arriéré, mais vous voulez d’autres choses aussi. Et vous voulez que les histoires découlent de ces autres choses. Les histoires entrent en dernier, pas en premier.
Ainsi, si vous voulez un arbre :
Débutez avec une vision de produit et une feuille de route
Décomposez-les en fonctionnalités et épopées
Dressez la carte des fonctionnalités et des épopées sur des horizons ou des versions
Décomposez -les alors en histoires d’utilisateur.
C’est un grand sujet et qui mérite beaucoup plus de couverture. Je recommanderais que vous lisiez User Story Mapping par Jeff Patton si vous voulez en savoir davantage.
Vous n’avez pas besoin d’évaluer toutes les histoires de l’arriéré
Certaines personnes pensent que vous devez avoir des évaluations sur tout dans l’arriéré, parce qu’autrement les items ne sont pas prêts à être travaillés. C’est-à-dire, ils ne respectent pas votre définition de « Prêts » (Ready). Et avoir quelques histoires prêtes à engager est bon, vous n’avez pas besoin que tout l’arriéré soit prêt à être entrepris. Le fait est que certaines des choses dans l’arriéré pourraient ne pas être travaillées avant une longue période de temps. Certaines d’entre elles pourraient ne jamais être développées. Et c’est OK.
Souvenez-vous, votre arriéré est fondamentalement superflu. Pour être plus spécifique, c’est le gâchis de type « Inventaire » en Lean. C’est une pile de choses qui restent là à attendre. Sans faire quoi que ce soit, sans allant où que soit, sans ajouter aucune valeur. Vous pouvez dépenser beaucoup de temps à construire, définir et évaluer un énorme arriéré de choses. Ou vous pouvez dépenser ce temps à faire en réalité du travail. C’est-à-dire à construire un logiciel.
Trouvez le bon équilibre
Il existe un bon équilibre et le trouver n’est pas aisé. Si vous n’évaluez rien, vous ne savez pas combien de temps il faudra pour construire quoi que ce soit. Si vous évaluez tout, c’est beaucoup de travail. Je pense qu’il est bon d’utiliser un système « n+1 » ou « n+2”, où vous avez le prochain ou les 2 sprints suivants de travail bien défini et évalué et prêt à entreprendre. Ainsi, si vous entrez dans la planification de sprint, vous pouvez avoir une vue d’où vous allez vous rendre. Et si les choses changent et que vous décidez de prendre quelque chose d’autre dans l’arriéré qui est un peu plus loin, vous pouvez aussi le faire. Mais vous ne dépensez pas 90 % de votre temps en planification et estimations.
Mais comment faisons-nous la planification d’une version si nous n’avons pas évalué les histoires ?
Les gens se bloquent sur ce point, mais c’est très simple. Vous pouvez simplement utiliser des moyennes. Donc, vous avez les un ou deux sprints d’histoires évaluées et pour le reste de votre arriéré, vous pouvez juste utiliser des points d’histoire médians (pour cette équipe) pour chaque histoire. Si vous avez 50 points d’histoires dans vos deux sprints suivants, avec une moyenne de 6.2 points (ce ne sera probablement pas un nombre de Fibonacci). Vous avez 30 autres histoires dans votre arriéré. Donc votre taille d’arriéré de produit est de 186 (6.2 fois 30) plus 50 (vos sprints évalués) pour un total de 236. Vu ? Facile.
La vérité est, quelques histoires s’avéreront être plus grandes que la moyenne et certaines s’avéreront être plus petites et c’est OK. Parfois votre vitesse sera plus élevée, parfois plus lente et c’est OK. Si vous le pouvez, essayez de faire décomposer les histoires en tailles semblables, proches des 5 ou 8. Cela rend l’affaire plus simple et plus précise. Vous pouvez même faire des estimations approximatives pour des fonctionnalités où vous n’avez pas décomposer les histoires, avec des évaluations de niveau de fonctionnalité, ou en utilisant un nombre moyen d’histoires par fonctionnalité et en multipliant le tout.
Souvenez-vous, l’estimation n’est pas porteuse de tant de valeur en premier lieu. N’y investissez pas trop de temps. Parce que les incertitudes sur les bénéfices sont plus fortes que les incertitudes sur les dépenses.
Vous ne devriez pas mettre chaque idée à laquelle vous pouvez penser dans l’arriéré
Certains propriétaires de produit se lâchent un peu trop quand ils passent sur Agile et disent “Super, je peux mettre tout ce que je veux ici ! Étonnant !”. Et passer les 20 jours suivants à bourrer l’arriéré de plein de particules et des pièces aléatoires, comme des gosses dans une confiserie.
Ce n’est pas une bonne pratique. Souvenez-vous, les articles dans l’arriéré sont une forme de gâchis. Vous voulez une feuille de route claire et une vision pour votre produit, pas une grande liste aléatoire de blanchisserie “de choses qui pourraient être sympas”. L’arriéré devrait refléter votre vision et stratégie pour le produit. Il devrait être capable de prendre en compte des changements, mais ne l’exagérez pas et surinvestissez pas. Concentrez-vous sur votre sprint actuel et paire suivante de sprints. Essayer de penser beaucoup plus loin que cela est de la pure spéculation et n’apporte pas de valeur.
CertYou est partenaire de DantotsuPM
Vous pouvez aussi totalement enlever des choses de l’arriéré
Des personnes pensent qu’une fois que quelque chose entre à l’arriéré, il ne peut jamais en ressortir. Ils pourraient penser “quel serait le point d’ôter quelque chose de l’arriéré ? C’est juste une idée, c’est juste un item de contenu potentiel. Nous pourrions ne jamais le construire, mais il n’y a aucun mal à le garder là”. Il y en a, c’est du superflu. Il introduit de la confusion embrouille les choses. De nouveau, l’arriéré n’est pas une liste de blanchisserie, c’est une feuille de route des fonctionnalités par version et qui reflète une vision et une stratégie de produit. Tenez-le fermement et propre et à jour. N’ayez peur de supprimer des choses. Si vous voulez vraiment y revenir plus tard, vous pourrez probablement la déterrer ou y bien réfléchir de nouveau (les choses peuvent avoir changé et reprendre le besoin pourrait ne pas être une mauvaise chose de toute façon).
Les développeurs devraient avoir voix au chapitre dans l’arriéré de produit
Certains pensent que l’arriéré de produit est exclusivement le domaine du propriétaire de produit. Et c’est partiellement vrai, mais pas tout à fait. Le propriétaire de produit dit ce qui y entre et dans quel ordre. Il est responsable de l’arriéré de produit. Et généralement, les développeurs s’occupent de l’arriéré de sprint, puisque c’est leur domaine. Ils construisent la portée qui entre dans le sprint. Mais un propriétaire de produit avisé parle toujours à l’équipe comme il construit et manage l’arriéré.
Les développeurs comprennent de domaine technique du produit. Ils comprennent ce sur quoi d’autres équipes travaillent et quelles nouvelles technologies arrivent (au minimum, ils le devraient). Ils comprennent les risques techniques et les dépendances dans le travail. Donc la discussion sur l’arriéré de produit avec eux est extrêmement importante.
La planification de sprint devrait être un environnement “sans aucune surprise”. Personne ne devrait lever la main en lisant un article de l’arriéré et dire “qu’est-ce diable que cela ? Je n’ai même aucune idée de ce que cela signifie ». La planification de sprint devrait être le choix final de quels articles de portée bien définis et compris de l’équipe prêts pour entrer dans le sprint.
J’espère que cet article effacera quelques fausses idées sur l’arriéré de produit! C’est un sujet important, difficile et il existe beaucoup de lectures que vous pouvez faire si vous êtes intéressés par ce sujet.
partagez ce billet avec vos amis, collègues et relations professionnelles
Nexus est une structure pour développer et supporter des initiatives de développement de logiciel avec Scrum à grande échelle. Il utilise Scrum comme sa composante de base. Ce guide contient la définition de Nexus qui consiste en des rôles Nexus, des événements, des artefacts et les règles qui les lient ensemble. Ken Schwaber et Scrum.org ont développé Nexus et ce guide qui a été traduit en français.
Nexus est une structure composée de rôles, événements, artefacts et techniques qui lient et tissent ensemble le travail de trois à neuf Équipes Scrum travaillant sur un même et unique Arriéré de Produit pour construire un Incrément Intégré qui atteint un objectif précis.
Contexte de Nexus
Récupérez gratuitement ce document disponible en français et de nombreuses autres langues.
Le développement logiciel est complexe. L’intégration de ce travail en une application logicielle qui fonctionne contient beaucoup d’artefacts et d’activités qui doivent être coordonnées pour créer un résultat « Fait ». Le travail doit être organisé, séquencé, les dépendances résolues et les résultats organisés. Le logiciel présente des difficultés complémentaires par rapport à d’autres produits puisqu’il n’est pas physiquement présent.
Beaucoup de développeurs de logiciels ont utilisé la structure Scrum pour travailler collectivement comme une équipe pour développer un Incrément de logiciel qui fonctionne. Cependant, si plus d’une Équipe Scrum travaille sur le même Arriéré de Produit et dans le même code source pour un produit, les difficultés surgissent. Si les développeurs ne sont pas dans une même équipe géographiquement colocalisée, comment communiqueront-ils quand ils font un travail qui peut impacter les autres ? S’ils travaillent dans des équipes différentes, comment intégreront-ils leurs livrables et évalueront-ils l’Incrément Intégré ?
Ces défis apparaissent dès que deux équipes sont en jeu et deviennent significativement plus difficiles avec trois ou davantage d’équipes.
Il y a de nombreuses dépendances qui surgissent dans le travail entre des équipes multiples qui collaborent pour créer un incrément complet et « Fait » dans chaque Sprint.
Ces dépendances sont liées aux :
Exigences : La portée des exigences peut se chevaucher et la façon dans laquelle elles sont mises en œuvre peut aussi les impacter les unes les autres. Cette connaissance devrait être prise en compte dans l’ordonnancement de l’Arriéré de Produit et le choix des exigences sur lesquelles travailler.
Connaissances de domaine : Les personnes dans les équipes possèdent la connaissance de divers systèmes informatiques. Cette connaissance devrait être reportée sur la carte des équipes Scrum pour s’assurer de son adéquation et réduire au minimum les interruptions et passage de relais entre les équipes pendant un Sprint.
Logiciels et artefacts de tests : Les exigences sont ou seront instanciées dans le code de logiciel et des jeux de test.
En fonction des exigences, la connaissance des membres d’équipe, les artefacts de code et de test et leur alignement sur les équipes Scrum en présence peut permettre de réduire la dépendance entre ces équipes.
Quand le développement de logiciel utilise Scrum à grande échelle, ces dépendances entre les exigences, la connaissance de domaine et les artefacts de logiciel/test devraient diriger l’organisation d’équipe. Dans la mesure où ceci est réalisé, la productivité sera optimisée.
CertYou est partenaire de DantotsuPM
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
C’est l’histoire d’un livre devenu culte, publié en 1997 par Don Miguel Ruiz (The four agreements), qui s’est écoulé à plus de 4 millions d’exemplaires dans le monde.
Client, Sponsor/Commanditaire, équipe… voici les parties prenantes pour lesquelles nous faisons un effort de communication et d’implication dans nos projets. Est-ce suffisant ?
Il n’y a pas de temps à perdre… il faut boucler le projet, respecter les échéances, lire et répondre aux mails, finir le rapport…. Le temps file entre mes doigts et je courre après… Vous aussi ? Voici trois conseils que j’ai mis en œuvre pour reprendre le contrôle.
La mondialisation de l’économie oblige les entreprises à rechercher tous les facteurs d’efficience et obtenir un avantage concurrentiel dans un marché où la chrono compétition est de rigueur.
La méthode Kanban adaptée à la planification de projet présente en effet de réels atouts
SMPP est Partenaire de DantotsuPM – Référentiel gratuit téléchargeable !Disponible sur Amazon en Anglais et sur PMI.ORG pour les certifiés en pdf gratuit
Le Project Management Institute (PMI) a sorti la 6ème édition du PMBOK le 6 septembre dernier.
Certains chefs de projet certifiés peuvent être tentés d’y répondre par “eh bien, je suis heureux que l’obtention de la certification soit derrière moi.”
Aujourd’hui, beaucoup de business optent au lieu de cela pour la gestion de projet Agile. Les personnes qui utilisent cette méthode se concentrent sur la production de petites parties du projet dans chaque cycle de livraison, plutôt que la création d’un plan pour le projet entier. Cependant, l’approche en cascade traditionnelle du management de projet a toujours plusieurs bénéfices clefs.
Le Docteur Laurence Peter a compris la promesse et le danger de la bureaucratie mieux que la plupart d’entre nous. Il y a cinquante ans, il a écrit, « les managers s’élèvent jusqu’à leur niveau d’incompétence ».
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
partagez ce billet avec vos amis, collègues et relations professionnelles
Ce fut en août dernier que parurent la toute dernière édition du PMBoK® Guide et le premier Agile Practice guide.
Sur DantotsuPM, vous avez particulièrement apprécié les billets sur les compétences douces mais aussi celles plus techniques comme Ishikawa et de Reporting ainsi que sur l’agilité avec les rétrospectives.
Disponible sur Amazon en Anglais et sur PMI.ORG pour les certifiés en pdf gratuit
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.
Beaucoup de professionnels techniques et non intuitifs me disent que maitriser les aspects pas si évidents des compétences interpersonnelles (des compétences douces ou compétences relationnelles) leur pose un grand défi, voire un réel casse-tête. Où trouver les vérités sur les compétences relationnelles à apprendre et utiliser ?
Les trois petits cochons sont une activité de rétrospective amusante qui utilise l’histoire des 3 petits cochons pour favoriser une conversation sur les améliorations pour obtenir de plus solides structures.
En tant que chef de projet, vous voulez faire un rapport efficace sur le statut de projet en fournissant des informations suffisantes aux parties prenantes en réduisant aussi la quantité d’aller-retour sur ces communications nécessaires. Ceci signifie des informations complètes, détaillées fournies de façons qui conviennent avec les parties prenantes, mais marchent aussi pour vous comme chef de projet. Cela peut être un challenge !
Avez-vous des problèmes ? Des projets en retard sur l’échéancier ? Des temps de cycle de processus métier en augmentation? Ventes en baisse ? Les gens continuent de vivre dans des silos ?
Discutons d’un outil simple mais puissant pour résoudre les problèmes – le Diagramme en arête de poisson « Fishbone Diagram » (Le diagramme de cause et effet).
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.
“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.
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
Acteurs du monde la formation professionnelle depuis plus de 25 ans, CERTyou met son savoir-faire à notre disposition pour réaliser nos projets de formation.
Olivier Boisne, Responsable pédagogique de CERTyou avec lequel DantotsuPM vient de renouveler et d’étendre un partenariat nous explique la démarche et les offres de CERTyou.
Partenaire de DantotsuPM
Spécialistes dans la préparation aux certifications de management de projet, CERTyou organise très souvent bien sûr la préparation à PMP, mais de plus en plus PgMPet PfMP.
Dans nos centres de formation (inter-entreprise) ou dans vos locaux (intra-entreprise), avec ou sans certification.
Avant tout efficaces, les formations CERTyou vous permettent de développer vos compétences par le transfert de connaissances et la mise en pratique au travers d’exercices, d’études de cas ou de jeux de rôle. Elles vous préparent à réussir les certifications dont vous avez besoin. Elles sont aussi l’occasion d’échanger des expériences et de se ressourcer dans le cadre d’environnements particulièrement conviviaux.
Nous sommes présents sur toute la France : Paris, Aix-en-Provence, Bordeaux, Lille, Lyon, Montpellier, Nantes, Rennes, Strasbourg, Toulouse… Mais aussi en Belgique, au Luxembourg, Suisse… Et dans toute la francophonie…
Plusieurs dispositifs s’offrent à vous pour financer vos projets de formations : le DIF (Droit Individuel à la Formation), le CPF (Compte Personnel de Formation), la prise en charge par l’OPCA de votre secteur professionnel, la période de professionnalisation.
Des accords entreprises peuvent également être proposés aux entreprises privées ou publiques.
La RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des Responsabilités sert à documenter les rôles et responsabilités de chacun dans le projet.
Pratique et Contexte
Donc nous ne devrions pas perdre espoir en notre propre créativité et compréhension en appliquant simplement les pratiques d’autres personnes – c’est OK de considérer les avis et les idées d’autres (l’accent est mis sur le pluriel), mais si nous ne comprenons pas vraiment quelle est la pratique, comment l’appliquer, quand ne pas l’appliquer, ou si nous ne comprenons pas quand la pratique est faible ou inexistante dans un certain secteur compatible avec notre contexte, alors nous devenons ce que j’appelle un mouton de Panurge (Lemming Method). Nous suivons aveuglément quelque chose que nous ne comprenons fondamentalement pas.
Nous devrions toujours nous poser deux questions avant d’adopter les pratiques de quelqu’un d’autre :
Bonne question !
DantotsuPM.com 
