Archive | agile RSS feed for this section

20 December – Tunis #PMI® – After Work : Bring agile to the whole organization

7 Déc

Most organizations today say they practice “agile” methods.

Join the LinkedIn Group for the PMI Tunisia Chapter

But probing reveals that agility typically begins and ends with software engineering teams. It is rare for agile methods to be used more broadly in other areas, such as finance or HR.

PMI After-Work Agenda

• 6.30 pm to 7h15 pm: Registration & Networking

Michel Goldenberg

7.15 pm to 8.00 pm : Bring agile to the whole organization Conference
• 8.00 pm to 8.30 pm : Wrap-up & Networking

Speaker : Michel Goldenberg, Certified Scrum Trainer

Paid Access : 10 TND (50% Off for Chapter Members)

Registration

PMI is a registered mark of Project Management Institute, Inc.

CertYou est partenaire de DantotsuPM

Quand utiliser kanban ou bien Scrum ?

6 Déc

Quelles sont les principales différences entre les méthodes ?

When to use kanban vs scrum http://www.extremeuncertainty.com/when-to-use-kanban-vs-scrum/ par leontranter

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

scrum methodologie agile

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 Scrum et 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.

5 Décembre – Sophia Antipolis – Agile Tour 2017

2 Déc

Le 7ème Agile Tour Sophia Antipolis aura lieu le Mardi 5 décembre 2017 à Sophia Antipolis et j’ai hâte vous y rencontrer en physique pour une fois !

Pour sa 7ème édition, l’équipe de l’Agile Tour Sophia Antipolis nous propose un programme riche et varié.

Agenda de la journée

Inscrivez-vous aux différentes parties de cette journée :

  • Matinée de 9:00 à 12:35
  • Début d’après-midi de 13:45 à 16:00
  • Fin d’après-midi de 16:30 à 18:40
  • Cocktail networking de 18:40 à 20:30
  • Ou toute la journée de 9:00 à 20:30

Nouveauté 2017

Vous pouvez désormais réserver un rendez-vous avec un coach agile dans le cadre des créneaux dédiés à la coaching clinic.

Le principe de la coaching clinic est simple : n’importe qui présent sur l’évènement vient exprimer une demande (une problématique, un blocage…). Un coach professionnel, présent bénévolement, l’accompagne dans une session de travail de 15 à 30 minutes environ.

Inscriptions gratuites

Enregistrer

7 Décembre – Vincennes #PMI® – Lean Startup ou comment optimiser les moyens et ajuster l’offre en fonction des retours des prospects, clients et utilisateurs.

30 Nov

Une démarche qui va vous inspirer dans la gestion agile de vos projets.

Un livre de référence sur ce sujet disponible sur Amazon

Le Lean Startup est une démarche de lancement d’entreprise qui consiste à optimiser les moyens et ajuster l’offre en fonction des retours des prospects / clients / utilisateurs.

L’objectif est de couvrir au mieux les attentes du marché.

Cette session organisée par La Branche Ile-de-France du PMI qui est un bouillonnant écosystème qui réunit Paris, ses centres d’affaire et ses technopoles dans la région !

Benjamin Thomas

Elle sera animée par Benjamin Thomas qui a débuté sa carrière à Dublin, auprès de la Customer Insight Unit du département Marketing de Tesco, qui est considéré comme pionnier dans l’utilisation de la donnée client pour piloter son activité. Benjamin est aujourd’hui en charge du pôle Innovation d’aSpark, dont la mission est d’aider les entreprises à créer et tester de nouvelles expériences client. Il est également contributeur pour les Echos Start, et publie régulièrement ses analyses sur TheAngle.fr.

Inscriptions

PMI is a registered mark of Project Management Institute, Inc.

itérations et incréments

30 Nov

Que signifient les mots itératif et progressif ?

http://www.jrothman.com/mpd/agile/2016/11/iterations-and-increments/ par Johanna Rothman

Agile, c’est le développement itératif et progressif et la livraison fréquente avec un changement culturel vers la transparence.

Itératif signifie que nous prenons « un morceau à la fois » pour créer une fonction entière. Des approches itératives gèrent le risque technique. Nous apprenons du risque comme nous réitérons à travers le jeu entier des fonctionnalités.

Progressif signifie que nous livrons des portions de valeur. Les approches progressives managent le risque de planification, parce que nous délivrons un travail fini à chaque étape.

Book on Amazon

Agile fonctionne parce que nous manageons les risques techniques et ceux de planification. Nous réitérons sur un jeu de fonctionnalités, livrant de gros incréments de valeur. (Une raison pour livrer de la valeur souvent et que nous pouvons ainsi changer ce que l’équipe va faire ensuite).

Prenons l’exemple d’un jeu de fonctionnalités appelé: “l’établissement d’une connexion sécurisée”.

Personne ne veut avoir à s’identifier pour se connecter. Mais, les gens veulent avoir une forte sécurité pour leur paiement. Hors, l’établissement d’une connexion sûre peut être une façon d’arriver à garantir le paiement. Le thème, ou ce que j’appelle un jeu de fonctionnalités, est “l’établissement de la connexion sécurisée”. Un jeu de fonctionnalités, ce sont plusieurs fonctions reliées qui livrent un thème.

Si vous voulez réitérer sur le jeu de fonctionnalités, vous pourriez livrer ces incréments de valeur :
  1. L’utilisateur existant déjà peut se connecter.
  2. Les utilisateurs peuvent changer leur mot de passe.
  3. Ajouter le nouvel utilisateur comme utilisateur.
  4. Ajouter le nouvel utilisateur comme admin.
  5. Empêcher des utilisateurs indésirables de se connecter : bots, certaines adresses IP, ou un emplacement physique. (3 histoires séparées.)

Si vous mettez en œuvre la première histoire, vous pouvez utiliser un fichier à plat. Vous pouvez toujours utiliser un fichier à plat pour la deuxième histoire. Une fois que vous commencez à ajouter plus de 10 utilisateurs, vous pourriez vouloir passer à une sorte de base de données. Ce serait une autre histoire utilisateur. Ce n’est pas “Créer une base de données.” L’histoire serait “Explorer des options pour permettre d’ajouter 10, 100, 1000, 10000 utilisateurs à notre site et voir quelles sont les implications en matière de performance et de fiabilité.”

Remarquez « explorer » comme une partie de l’histoire. Cela pousserait à produire des options que l’équipe puisse discuter avec le Product Owner. Certaines options ont des implications à l’exécution.

Chaque fois l’équipe réitère sur le jeu de fonctionnalités, elle livre un incrément. Puisque beaucoup d’équipes utilisent des durées de temps fixes (timebox), elles utilisent « des itérations » comme leur timebox. (Si vous utilisez Scrum, vous utilisez des sprints.) Remarquez les mots “réitère sur le jeu de fonctionnalités.”

Dans des cycles de vie progressifs, comme la livraison par étapes, l’équipe finirait toutes les fonctionnalités dans un jeu de fonctionnalités donné. Les cycles de vie incrémentaux n’ont pas nécessairement à utiliser des timeboxes pour livrer leur développement progressif. Dans les cycles de vie itératifs, comme spiral ou RUP, l’équipe développerait des prototypes de fonctionnalités, ou même finirait partiellement des fonctionnalités, mais l’intégration finale et les tests n’arrivent qu’après que tout le développement itératif ait été fait.

Dans Agile, nous réitérons sur un jeu de fonctionnalités, livrant la valeur progressivement.

Si vous ne finissez pas vos histoires, vous êtes dans un cycle de vie itératif. Si vous ne limitez pas les fonctionnalités que vous finissez et ne les terminez pas « toutes », vous êtes dans un cycle de vie progressif.

Il n’y a pas de bonne façon de choisir un cycle de vie pour votre projet. Si vous voulez utiliser agile, vous réitérez sur un jeu de fonctionnalités sur un bref cycle de temps, livrant de gros incréments de valeur.

CertYou est partenaire de DantotsuPM

 

révision 2017 du Scrum guide pour les 90% des équipes Agile qui utilisent déjà Scrum et pour les autres 10% qui vont y venir :-)

29 Nov

Le 7 Novembre dernier, Jeff Sutherland et Ken Schwaber ont été interviewés sur la toute dernière révision du Scrum Guide.

La première partie est consacrée à un bref retour en arrière sur la genèse de Scrum et sa très rapide adoption pour atteindre aujourd’hui:

  • grandir

    90% des équipes Agile utilisent Scrum

    90% des équipes Agile utilisent Scrum

  • 12 millions de personnes participent à des Daily Scrum meetings
  • Dans tous les pays
  • Dans toutes les industries et de nombreuses organisations gouvernementales

Puis, certaines des mises à jour du Scrum Guide 2017 sont discutées plus en détail:

  • L’utilisation de Scrum en dehors de l’informatique.
  • Les précisions sur le rôle de ScrumMaster qui est parfois mal interprêté alors qu’il s’agit avant tout de faire la promotion de Scrum et supporter son adoption dans l’entreprise en aidant au changement vers Scrum, ses bonnes pratiques, ses valeurs, ses règles.
  • 12 millions de personnes participent à des Daily Scrum meetings

    Il était aussi nécessaire de réitérer l’objectif des Daily Stand Up meetings trop souvent utilisés comme des rapport d’avancement alors qu’il s’agit de voir où l’on en est et décider d’actions adaptatives pour atteindre l’objectif du Sprint, pour passer les items du Sprint Backlog à « Done ».

  • Une autre incompréhension levée par cette mise à jour concerne les activités « timeboxées »,i.e. limitées dans le temps. Les durées proposées par Scrum sont maintenant clairement identifiées comme des durées maximales, et non obligatoires ni nécessaires.
  • Enfin, l’importance de la prise d’action suite à la rétrospective de Sprint se matérialise par l’obligation d’avoir au moins une histoire permettant d’améliorer les process par Sprint.

Plusieurs questions récurrentes sont également abordées:

  • Scrum s’applique-t-il seulement au domaine du développement de logiciel ?
  • Est-il nécessaire d’attendre la fin du Sprint pour livrer ?
  • Comment Scrum et DevOps peuvent-ils travailler ensemble ?

Regardez la vidéo.

Visionnez la vidéo

Téléchargez le nouveau Scrum guide: www.scrumguides.org

CertYou est partenaire de DantotsuPM

30 November – Webinar – Mixing Qualitative & Quantitative data with Storyboarding

25 Nov

Qualitative vs. Quantitative is a silly argument.

Qualitative data from UXers should not compete against the quantitative data product owners need for their business model. Both are necessary to have a complete understanding of where the desirability of the product meets the viability of the business.

Tristan Kromer, Lean Agile Coach, Kromatic

Storyboarding is a simple way to start integrating both perspectives into a complete picture of how the user experience impacts the business model.

  • How to integrate qualitative insights on user experience with a business model based on numbers
  • How to instrument qualitative metrics and when not to
  • How to use storyboard to remove the ten unnecessary features from your MVP
  • When to use journey mapping versus storyboarding

November 30, 2017 11 AM PST, 2 PM EST, 7 PM GMT

Tristan Kromer, Lean Agile Coach, Kromatic

Tristan works with innovation teams and leaders to create amazing products and build startup ecosystems. He has worked with companies from early stage startups to very large enterprise companies.

Register

28 Novembre – Pause&Vous, série web IQar – Les outils de pilotage des Projets

24 Nov

Vous faites quoi à la pause déjeuner du mardi 28 nov 13h ?

Pause&Vous 15min, on vous invite ! Notre Cyprien du PPM, Louis Marie RESSEGUIER, nous dévoile dans sa vidéo les bénéfices de la planification KANBAN dans la gestion de projet !

RÉSERVEZ VOTRE TABLE DES MAINTENANT

A few videos to get started on Agile, Scrum & Kanban

La mise en œuvre d’une méthode KANBAN pour la planification de vos projets, peut être un véritable vecteur de simplification de cette phase incontournable de la vie du projet qu’est la Planification.

Cette méthode peut également être un formidable levier d’aide à la conduite du changement dans certaines organisations : notamment celles désireuses de bénéficier des avantages du mode projet tout en adaptant par étapes les modes de travail de ses collaborateurs pour faciliter l’adhésion et le succès de la mise en place de la démarche.

Pause&Vous: la nouvelle série web du cabinet conseil en maturité de gouvernance de projets, IQar.

Chaque mois, 15 min top chrono de convivialité avec les experts de notre partenaire IQar autour des principaux enjeux du pilotage opérationnel de vos projets et des outils PPM (choix, méthodologie, déploiement, pilotage…)

 Le programme Pause&Vous permet de faire partager des idées et des expériences, au fil de « talks On Line » et de présentations vidéos.

Des interventions flash de 15 min, sur Internet accessibles à tous pour plus de souplesse et d’efficacité.

On vous a mis en appétit ? Pour réserver votre table, c’est par ici

Vous souhaitez en savoir plus sur le programme de la série web Pause&Vous ? Demandez le menu ! contactez-nous

Quelques infos des prochains plats à la carte que l’on vous concocte…

  • Pause&Vous # : Météo des Projets :  le 19 décembre.
  • Pause&Vous # 3 : Le Scoring :  le 30 janvier
  • Pause&Vous # 4 : Gérer les équilibres du projet le 27 février
  • Pause&Vous # 5 : Une bonne charte de projet le 27 mars
  • Pause&Vous # 6:  De l’idée en passant par la demande 26 avril
  • Pause&Vous # 7:  Rôles et Responsabilités des acteurs projets 29 mai.
  • Pause&Vous # 8: Gestion du temps, des ressources, bande passante Le 28 juin

Et pomme sur le gâteau, peu d’outils proposent nativement cette fonctionnalité à part l’outil SuiteProg d’IQar. Demandez la démonstration de SuiteProg

IQar, auteur du référentiel français du Système de Management du Portefeuille de Projets (SMPP) – SMPP est labellisé par Bureau Veritas Certification.

SMPP est Partenaire de DantotsuPM – Référentiel SMPP gratuit téléchargeable.

5 Décembre – Paris-Saclay #PMI® – DevOps, fondamentaux et concepts, quels impacts pour les chefs de projet

20 Nov

Le pôle PMI Paris-Saclay vous invite à assister à la conférence sur « DevOps, fondamentaux et concepts, quels impacts pour les chefs de projet « 

Cet événement aura lieu le mardi 5 décembre 2017 de 12h30 à 14h00 à la cité de l’Innovation, Nokia.

La conférence est réservée aux membres du PMI.

Détails et inscriptions

La participation à cet événement rapporte 1,5 PDU aux certifiés PMP et PgMP présents (1: Catégorie Technique, 0,5: business).

PMI is a registered mark of Project Management Institute, Inc.

Enregistrer

5 recommandations pour réussir les projets Agile

20 Nov

Tout est devenu ou doit devenir Agile de nos jours !

Five Tips for Agile Project Success

http://www.thinkbrownstone.com/2015/11/five-tips-for-agile-project-success/ par Meaghan Sorte

Il semble que tout le monde utilise Agile pour manager des projets de nos jours. Et il y a de grandes chances si vous questionnez vos contacts professionnels que vous constatiez qu’une certaine forme d’Agile dirige leur travail. À Think Brownstone, nous travaillons souvent étroitement avec des clients en tant que membres de leurs équipes projet Agile (tant comme experts UX que développeurs). Nous avons pu adapter nos méthodes Agile pour aider les clients à lancer avec succès des produits en permettant un processus flexible pour notre équipe.

Ci-dessous, je partagerai les 5 astuces qui nous ont aidés à réaliser ces succès avec Agile.

1. planifiez continuellement

La planification est continuelle dans tout projet qui n’est pas « en cascade ». La rapidité d’exécution des activités, les chevauchements de tâches et les exigences opérationnelles qui changent constamment demandent de l’attention. Vous ne connaîtrez pas chaque détail à l’avance, mais c’est bien. Le but est de rester maitre de la planification pour que vous soyez toujours un coup d’avance sur vos efforts de développement.

Même si cela peut sembler fastidieux, une planification appropriée en amont payera ses dividendes en cours de route. Une bonne façon de commencer est d’avoir une session de planification avec l’équipe entière (le propriétaire de produit, UX/Responsable de l’eXpérience Utilisateur, et les développeurs). Utilisez ce moment pour revoir le design de conception et permettre à l’équipe de poser des questions. Cette session est une bonne occasion de découvrir des domaines sur lesquels vous pouvez devoir faire des recherches plus approfondies. Cette sorte de planification vous aide aussi à savoir ce que vous ne savez pas (encore) et comprendre les risques que ceci pourrait poser.

Une fois que votre projet est démarré, la planification est tout aussi critique. Vous devrez surveiller l’arriéré de produit et la vitesse de livraison de l’équipe. Quand les priorités changent, comprendre les variables avec lesquelles vous travaillez vous aidera à planifier les sprints à venir et ajuster le sprint actuel si nécessaire. Vous devrez continuer à travailler avec votre équipe pour planifier, re-prioriser si nécessaire et ajuster es attentes. Juste quand vous pensez que vous avez fini de planifier, soyez prêt à planifier un peu plus.

2. faites ce qui est bien pour le produit

Parfois (en réalité, la plupart du temps) « la bonne façon » n’est pas la voie la plus facile, la plus rapide, ni la moins coûteuse. Cela ne signifie pas que vous devriez mettre en péril votre vision pour le cœur du produit. Déterminez la meilleure ligne de conduite, évaluez les impacts et prévoyez comment avancer. Les dates changent, les priorités changent et le monde avance.

Sur la même ligne de pensée, un propriétaire de produit avisé sait quand il est temps de prendre une décision difficile et tirer sur les rênes. Il y aura toujours encore une fonctionnalité à caser parce que c’est « une capacité à surprendre » ou parce qu’un grand client la demande. Prenez du recul pour considérer ce qui est le plus critique et voir s’il y a d’autres façons d’atteindre ce but. Le chemin peut ne pas sembler exactement comment vous l’avez prévu, mais vous pourrez probablement trouver un passage.

3. Sachez que les outils que vous utilisez sont seulement aussi bons que les données qui y entrent

Les équipes doivent comprendre tous les processus et flux de travail associés au projet et quelles sont leurs responsabilités dans ceux-ci. La dernière chose dont vous voulez vous inquiéter est un problème de communication surgissant à cause d’étapes manquées (qui peuvent en fin de compte causer des retards). Pour communiquer efficacement, assurez-vous que les membres du projet informent leur équipe quotidiennement lors des réunions standup et managent activement les statuts des tâches qui leur sont confiées.

Votre équipe devrait aussi opérer de façon systématique et communiquer de façon opportune pour qu’il soit facile de suivre le progrès. Trouvez des façons de fournir de la visibilité à ceux qui en ont besoin et supprimez le bruit pour ceux qui ne sont pas concernés. Les tableaux de bord peuvent être un outil puissant pour montrer comment le travail progresse et identifier rapidement les risques (les délais, la portée, ou des ressources) dans le projet.

4. Ayez une compréhension claire et partagée de ce que « done » signifie

Parce que les méthodes Agile varient, « done » peut avoir de significations différentes selon les projets. Ce qu’une équipe considère « done » peut ne pas correspondre à ce qu’une autre équipe en penserait. Pour éviter toute confusion, votre équipe devrait créer une définition partagée de ce que « done » signifie pour que tout le monde sache quand considérer une fonctionnalité complète.

finiSi vous êtes nouveaux en Agile, posez une définition simple. « Done » pour une fonctionnalité pourrait être défini selon des critères clairs d’acceptation pour déterminer si l’histoire d’utilisateur est complète. Les critères d’acceptation contiendraient une liste explicite de déclarations (avec un accepté/rejeté) qui manifeste si le livrable répond aux exigences. Une fois qu’une fonctionnalité a été codée et testée, elle peut être remise au propriétaire de produit pour la revue finale. Le propriétaire de produit acceptera alors (idéalement, par écrit) une fonctionnalité avant qu’elle ne soit considérée « done ».

5. Gardez l’objectif final à l’esprit

À un certain point dans votre projet, vous allez devoir faire des compromis. Quand ces situations surgissent, vous devrez prendre du recul et

vous demander, « Quel est le MVP ? (Minimum Viable Produit) ». Assurez-vous de livrer de la valeur – une réelle Valeurà vos clients et votre business. Si vous n’avez pas fait de recherche avec des clients, ne passez pas du temps à créer quelque chose qu’ils peuvent ne pas vouloir ni avoir besoin. Concentrez vos efforts sur ce qui va fournir un bénéfice à court terme et ce sur quoi vous pouvez continuer à construire dans l’avenir.

Produit Viable Minimum (MVP)

Bien que nous ne suivions pas un processus de développement logiciel Agile strict à Think Brownstone, les méthodes que nous avons adaptées se sont avérées fructueuses tant avec des projets internes que clients. Avec autant de sortes différentes d’Agiles utilisées, ce qui marche pour certains peut ne pas toujours marcher pour d’autres, mais nous avons constaté que garder ces 5 astuces à l’esprit peut mener au succès.

Quelles autres astuces avez-vous trouvées utiles pour manager des projets agiles ? Quel conseil pouvez-vous communiquer à celles et ceux qui sont nouveaux en Agile ? Répondez dans la zone commentaires de ce billet.

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

%d blogueurs aiment cette page :