Archive | agile RSS feed for this section

18 October – Webinar ( #PMI ®) – Agile ProDUCT Management Essentials for Project Managers

30 Sep

Product management is often a murky role !

Rich Mironov

Rich Mironov

Program management is poorly understood and inconsistently practiced across tech companies and often confused with program and project management.

Yet done well, product management is a driver of market success and effective development. Agile teams building commercial software have additional role confusion between product owners and sometimes-agile product managers.

This session facilitated by Rich Mironov outlines product management basics, contrasts them with project/program management, and matches this to scrum-defined product ownership.

Attendees will get a better sense of what product managers do, and how we can work together more effectively.

Details and registration

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

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

Enregistrer

Enregistrer

Enregistrer

13-14 Octobre – Lille – Agile Tour 2016

21 Sep

L’évènement 2016 le plus agile et le plus convivial de la région.

nord-agileL’association Nord-Agile garantit que :

  • Vous vous passionnerez des conférences animées par des speakers nationaux et internationaux
  • Vous vous amuserez aux cours d’ateliers de coding, de management agile ou de dessin
  • Vous échangerez avec les acteurs moteurs de l’agilité dans la région lilloise
  • Vous partagerez vos expériences à l’occasion d’un forum ouvert

Fort du succès des années précédentes, les organisateurs ont décidé de consacrer davantage de temps pour célébrer l’agilité.

Accessible à tous, l’Agile Tour vise un public étendu souhaitant découvrir ou approfondir les méthodes agiles telles que Scrum et découvrir leurs apports et impacts tant au niveau industriel que sociétal.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Ils s’engagent sur 2 objectifs sur ces 2 jours :

  1. octroyer plus de temps et de plaisir aux échanges entre les participants
  2. permettre à davantage d’animateurs et speakers de vous partager leurs expériences

Afin de contribuer à nourrir ces échanges, une nouveauté cette année : un forum ouvert.

Inscriptions et Détails

Enregistrer

Jeu d’introduction de pairs pour les retrospectives #Agile

16 Sep

Peer Introduction Game

http://www.funretrospectives.com/peer-introduction-game/

Le jeu d’introduction de pairs est une activité de développement de l’esprit d’équipe pour que les nouveaux membres de l’équipe en apprennent davantage les uns des autres. Une conversation rapide suivie par introduction par un pair fournit un mécanisme rapide de présenter chaque personne dans un grand groupe.

Passengers on an Icebreaker Watching Pack Ice

Avez-vous également expérimenté cet exercice « brise-glace » ?

Comment diriger l’activité

  1. Divisez le grand groupe par paires. Demandez aux gens de se mettre avec quelqu’un qu’ils ne connaissent pas bien.
  2. Demandez aux paires d’avoir une conversation rapide l’un de l’autre et informez-les que plus tard ils présenteront leur partenaire. Vous pouvez laisser la conversation ouverte, ou choisir quelques questions auxquelles répondre (comme : nom, lieu de naissance, rôle actuel, nourriture préférée, lieu de voyage préféré).
  3. Faites le tour du grand groupe et laissez tout le monde présenter son alter-ego.
Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Exemple

Paulo dit: « Je vous présente Amit. Il est né au Canada, mais sa famille est en Inde. Il aime la samba brésilienne et sa nourriture préférée est le hot-dog, plus particulièrement en assistant à une partie de base-ball. Il travaille actuellement comme … »

Essayez Bubble Plan !

Essayez Bubble Plan !

Note: J’ai été surpris la première fois que l’on m’a invité à faire cet exercice dans le cadre d’une réorganisation et de la mise en place d’une nouvelle équipe de management.

Questions: Avez-vous également expérimenté cet exercice « brise-glace » ? En connaissez-vous d’autres ?

Enregistrer

Enregistrer

Enregistrer

les mythes d’Agile : « il n’y a aucune planification dans #Agile »

12 Sep

« Il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression »

http://trainings24x7.com/2015/06/22/list-of-free-pmp-sample-questions-websites/ par Leontranter

Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.

En fait, je vais aller plus loin et poser une affirmation audacieuse :

Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.

En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.

Il ne s’agit pas de plans mais de planification

Une de mes citations favorites est celle de Dwight Eisenhower :

« Les plans ne sont rien. La planification est tout. »

protectionCeci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.

Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.

Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :

  • Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
  • documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.

Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?

Pourquoi les projets entrent-ils dans une telle spirale ?

Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information

aveugleLes projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :

  • Peu ou pas d’informations sur le travail qui a besoin d’être fait
  • Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
  • Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)

Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).

Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:

« Aucun plan ne survit au contact avec l’ennemi. »

Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.

Les projets agiles planifient à plusieurs reprises par petits morceaux

Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).

Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :

  • Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
  • Pouvant être achevé en un sprint (qui est souvent de deux semaines).

Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.

Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.

Un si petit plan apporte-t-il vraiment de la valeur ?

Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».

Bien sûr, mais deux points :

  1. Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
  2. Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.

Une grande partie de la valeur réside  dans la Planification, pas dans le Plan.

Rappelez-vous la précédente citation de Eisenhower.

plans are nothingLes membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.

  • Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
  • Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?

Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.

Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

11 October – Webinar – Why #Agile?

10 Sep

The world of project management has changed significantly over recent years.

Prince2 AgileFor decades the profession has been dominated by traditional, sequential, “waterfall” approaches. Increasing numbers of individuals and organisations are now turning to Agile methods and frameworks to manage projects more effectively.

Whether you are just starting to find out about Agile, or already considering it as a potential new way of working, ‘Why Agile?’ is a very sensible question.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Aiming to address this question, this webinar will focus on the key differences between Agile and traditional approaches to project management, and the benefits an Agile way of working can bring to your business.

Click Here To Register

Enregistrer

Enregistrer

Enregistrer

Enregistrer

un mot et un seul pour démarrer vos rétrospectives #Agile…

9 Sep

One Word

post ithttp://www.funretrospectives.com/one-word/

La technique « Un Mot » est un contrôle simple dans l’activité qui permet aux participants de partager leurs sentiments avant d’entrer dans les données et détails de la réunion en elle-même. C’est une bonne ouverture pour une réunion car elle reconnaît les sentiments des personnes et les fait parler dès le début.

Get the book on Amazon

Get the book on Amazon

Déroulé de l’activité

  1. Donnez à chaque participant un marqueur et un post-it
  2. Demandez-leur de décrire leur sentiment (dans le contexte de la réunion) en un mot
  3. Groupez les notes sur une grande page
  4. Optionnellement, demandez si quelqu’un veut en dire plus sur leur mot choisi

Décrivez s’il vous plaît < le dernier sprint ou le mois passé ou vos sentiments sur XYZ > en un mot !

Cette activité est décrite comme un Activité de Checkin par Esther Derby Et Diana Larsen dans leur remarquable livre Agile Retrospectives book.

à la lecture de ce billet, quel mot écririez-vous sur votre post-it, quel sentiment vous inspire-t-il ?

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Great International Agility survey: une enquête sur la culture #Agile, ses valeurs et principes

3 Sep

Ce sondage auquel je vous propose de participer couvre les 22 points mentionnés dans la présentation de Claude Emond « Culture agile – 4 valeurs, 8 techniques, 10 principes« 

La présentation de Claude: http://fr.slideshare.net/claudee/culture-agile-4-valeurs-8-techniques-10-principes

Sont également couverts dans cette enquête 12 points sur les «facteurs humains» et 8 points sur la résilience.

Take the survey

Take the survey

Enregistrer

Enregistrer

14 September – Webinar (ScrumPulse) – Transforming a 25,000+ Person Consulting Company to Become More #Agile

2 Sep

Over the past 4 years, Avanade has embarked on a journey to increase their organization’s agility while also building an enterprise-level agile capability to better serve their clients.

Patricia Kong leads the Scrum.org scaling initiative

Patricia Kong leads the Scrum.org scaling initiative

During this time, Avanade joined Scrum.org as a partner in principle to support these initiatives.

In this session, Karel Deman, global agile lead at Avanade, and Patricia Kong, who leads the Scrum.org scaling initiative, will describe how Avanade improved their organizational agility.

They will also share the successes and challenges Avanade faced in scaling ability across the enterprise to best deliver solutions to their clients using Scrum and agile practices.

SMPP est Partenaire d DantotsuPM

SMPP est Partenaire d DantotsuPM

Register to Attend Webcast on Agile Transformations

Enregistrer

Enregistrer

Enregistrer

Enregistrer

12 questions pour répondre à cette question : faites-vous du Développement Logiciel #Agile ?

2 Sep

12 questions to find out: Are you doing Agile Software Development?

http://neilkillick.com/2015/07/26/12-questions-to-find-out-are-you-doing-agile-software-development/ Par Neil Killick

Voulez-vous faire Développement Logiciel Agile ? Non ==>
AU REVOIR !

Oui

|

v

Votre équipe réfléchit-elle régulièrement comment s’améliorer ? Non ==> Rencontrez régulièrement votre équipe pour réfléchir à comment vous améliorer et rebouclez sur cette question.

Oui

|

v

Pouvez-vous livrer un logiciel utilisable fréquemment, au moins toutes les 2 semaines ? Non ==> Éliminez les obstacles à la livraison d’un incrément expédiable toutes les 2 semaines, rebouclez sur cette question.

Oui

|

v

Travaillez-vous quotidiennement avec votre client ? Non ==> Commencez à rencontrer quotidiennement votre client, rebouclez sur cette question.

Oui

|

v

Satisfaites-vous systématiquement votre client ? Non ==> Découvrez pourquoi votre client n’est pas content, corrigez cela, puis rebouclez sur cette question.

Oui

|

v

Vous sentez-vous motivés ? Non ==> Allez travailler pour quelqu’un qui a confiance en vous et qui vous apporte tout son support, rebouclez sur cette question.

Oui

|

v

Parlez-vous chaque jour avec votre équipe et vos parties prenantes? Non ==> Commencez à le faire puis rebouclez sur cette question.

Oui

|

v

Mesurez-vous principalement le progrès en fonction du logiciel livré qui marche? Non ==> Commencez à le faire puis rebouclez sur cette question.

Oui

|

v

Pouvez-vous maintenir indéfiniment votre allure de développement? Non ==> Embarquez moins de choses dans l’itération suivante, rebouclez sur cette question.

Oui

|

v

Prêtez-vous attention continue à l’excellence technique et à une bonne conception ? Non ==> Commencez à le faire puis rebouclez sur cette question.

Oui

|

v

Gardez-vous les choses simples et maximisez-vous la quantité de travail non faite ? Non ==> Commencez à garder des choses simples et écrire aussi peu de code que possible pour satisfaire le client, rebouclez sur cette question.

Oui

|

v

Votre équipe est-elle auto-organisée ? Non ==> N’assignez pas de tâches aux personnes et laissez l’équipe comprendre ensemble comment satisfaire le client au mieux, rebouclez sur cette question.

Oui

|

v

VOUS FAITES DU DÉVELOPPEMENT LOGICIEL AGILE!!

comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

1 Sep

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite
  • TTestable

Indépendante

Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.

Négociable

Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.

de Valeur

Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.

Estimable

Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».

Suffisamment petite

Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.

Testable

Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.

Découpage vertical ou horizontal

Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.

Des exemples de découpe de « User Stories »

Trop grosse User Story: "En tant que client, je peux payer ma commande pour recevoir les produits"

Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »

En tant que client, je peux payer ma commande pour recevoir les produits
Mindview est Partenaire de DantotsuPM

Mindview est Partenaire de DantotsuPM

Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…

  • En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.

Et/ou

  • En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.

Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.

Découpage par flux de travail

revoir mon panier de courses

revoir mon panier de courses

Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :

  • Fournir mes informations bancaires

    Fournir mes informations bancaires

    En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.

  • En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
  • Recevoir une notification par SMS

    Recevoir une notification par SMS

    En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.

D’autres méthodes

Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :

Visitez le blog Agilistic

Visitez le blog Agilistic

  • par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
  • par options d’interaction / par plate-forme
  • par types de données ou paramètres
  • par scénarios de test
  • par rôles
  • par ‘j’optimise maintenant ‘ contre ‘ j’optimise plus tard
  • par compatibilité de navigateur

la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

%d blogueurs aiment cette page :