Tag Archives: scrum

Les articles les plus sur DantotsuPM.com au mois d’Aout 2017

11 Déc

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

PMBOK® Guide – la 6ème édition

Réalisé par de chefs de projets pour les chefs de projets !

Disponible en ligne dès le 6 septembre

Le Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 6ème édition est la dernière évolution de cette ressource clé pour les chefs de projets.

Connaissez-vous le nouveau Agile Practice Guide (en anglais) ?

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.

Utilisez ces 15 vérités pas si évidentes sur les compétences relationnelles

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 3 petits cochons et les rétrospectives Agiles amusantes

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.

MPM est partenaire de DantotsuPM

Faire un rapport de projet: simple et difficile à la fois !

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 !

Et si vous alliez à la pêche… …aux causes du problème !

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).

CertYou est partenaire de DantotsuPM

Le management de projet Agile ne s’applique pas seulement au logiciel et aux projets informatiques !

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.

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.

CERTyou, partenaire de DantotsuPM, est votre Partenaire Certifications

4 Déc

Olivier Boisne

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

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.

En savoir plus sur les méthodes d’apprentissage

CERTyou MissonsNous 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

En savoir plus sur nos centres de formation

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.

En savoir plus sur les Financement Formation

Certifications Management de Projet essentielles à obtenir :

PMP logo squareFormation PMP, réussir la Certification PMP du PMI

5 jours de formation, Promotions jusqu’à -40% toute l’année

Examen PMP, Adhésion PMI, PMbok, Coaching Inclus

En savoir plus sur la Formation PMP

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

Formation PRINCE2, réussir les Certifications PRINCE2 Foundation et PRINCE2 Practitioner
Prince2 Logo Small

5 jours de formation, Promotions jusqu’à -40% toute l’année

2 Examens PRINCE2, Ouvrage Officiel, Coaching Inclus

En savoir plus sur la Formation PRINCE2

 

Formation AGILE Scrum Master, réussir la Certification AGILE Scrum Master
Professional Scrum Master

2 jours de formation, Promotions jusqu’à -40% toute l’année

Examens AGILE Scrum Master, Coaching Inclus

En savoir plus sur la Formation AGILE Scrum Master

 

Formation ITIL Foundation, réussir la Certification ITIL Foundation

ITIL3 jours de formation, Promotions jusqu’à -40% toute l’année

Examens ITIL Foundation, Coaching Inclus

En savoir plus sur la Formation ITIL Foundation

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

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

22-24 Novembre – Grenoble – Agile tour

12 Nov

Détails en ligne

L’agilité dans tous ses états

  • L’agilité au jour le jour : du concret, des outils, des pratiques
  • Souvenirs de voyages en Agilité
  • Un nouveau souffle pour votre agilité

Le programme des sessions est disponible !

CertYou est partenaire de DantotsuPM

a 30′ video introduction to Scrum: Did you know that 11 Million people participate in Daily Scrum Meetings ?

8 Nov

I found this video prepared and shared by Axosoft & Scrum.org to be quite an interesting introduction to Scrum (section going from 2’30 » to 32’00 »).

CertYou est partenaire de DantotsuPM

14 November – Zürich #PMI® – Concrete Goes Agile as BIM and SCRUM shape the future of Real Estate

2 Nov

An event organized byPMI Switzerland

Tools like Value-Driven Delivery, Agile Product Development, and Adaptive Planning have made the way from software development to most of the industry sectors, corporate strategies and even the vocabulary of business schools. In the last 30 years, the productivity gains in many industries have increased, sometimes over 500%. Meanwhile, the productivity level of the Real Estate Sector has decreased by 15%.

For years, Real Estate business has kept its usual pace, providing relatively low but stable margin for the companies involved.

Most of the projects remain firmly tied to waterfall methodology – once lease contract has been signed, or concrete has been poured, it’s costly to do another ‘release’ and test other solutions.

However, we are now facing a change of attitude, tools, and methods. Concrete goes Agile for sure.

How and why?

We will hear from two experts in the fields of BIM (Building Information Modeling) and Digital Real Estate: Simon Caspar and Adrian Wildenauer from pom+Consulting AG.

Register

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

CertYou est partenaire de DantotsuPM

Enregistrer

%d blogueurs aiment cette page :