Qu'est ce qu'un product Owner?

Le Product Owner a un rôle important dans un projet conduit en mode Agile.
C'est l'équivalent d'un Moa dans un projet en cycle en V.

Il est le représentant des utilisateurs . Il n'est pas un directeur de produit, il donne bien la direction fonctionnelle  mais n'a pas de responsabilité hiérarchique  sur des personnes.

Il prend des décisions de niveau stratégique comme la décision de la date de livraison du produit et de son contenu.

Le product Owner doit avoir une bonne vision du produit. La vision se construit au début du projet et se consolide ensuite. 

Tous les membres de l'équipe et tous les parties prenantes du projet doivent partager la même vision et c'est au PO de s'en assurer.

Voici le rôle du Product Owner

- être le représentant du client ou des utilisateurs.

- récolter les attentes, besoins, exigences du client ou des utilisateurs et les priorités associées.

- formaliser le backlog de produit avec le niveau de précisi on adapté à la priorité

- être en mesure de les expliquer au Scrum Master et à l’équipe de

développement ou d’inviter le client et/ou un utilisateur pour le faire.

- définir le planning des releases dans lesquels les Sprints s’inscriront

Google est il Agile ?

J'ai eu l'opportunité lors de mes dernières vacances à San Francisco de me  rendre sur le campus de Google.  Nous avons aussi pu avoir accès au show room réservé au visiteur.

Suite à cette visite, j'ai eu envie d'analyser l'agilité dans cette grande entreprise de plus de  10000 développeurs et de plus de 30 000  personnes.
La visite du  show-room nous a permis de faire quelques photos mais pas d’apprécier en détail  leur méthode de gestion de projets.
Mon point de vue s'est alors basé à la fois sur ma connaissance de Google, mes impressions de ma visite sur le campus et sur les références ci dessous:

http://blog.beule.fr/analyses-dexpert/lagilite-chez-google/


https://youtu.be/3DfZi3ooyfE

Et en voici mon résumé et ma conclusion :

La taille et l’organisation de Google sont des paramètres à prendre en compte impérativement pour comprendre les contraintes et enjeux :

• plus de 10 000 développeurs répartis sur plus de 40 pays
• 50% du code existant change tous les mois
• plus de 20 modifications sont décomptées par minute

Google travaille en effet en méthode agile, en mettant en production des versions quotidiennement.

Des équipes de  5 personnes travaillent à la réalisation d'une fonctionnalité. L'équipe est dissoute à la fin du projet pour aller travailler sur une nouvelle fonctionnalité.

Au niveau des réunions , Google suit bien les  cérémoniaux de la méthode agile : daily scrum, planning poker, sprint planning, démo, rétrospective mais les réunions sont courte  15 mn environ pour une rétro hebdo à 1h pour une rétro mensuelle.

Au niveau du back log une spécificité la ICE Box, des idées congelées en amont qui serviront à l'alimentation future du back log.

Cependant si l'on reprend les manifestes de l'agilité :

1. Les individus et leurs interactions plus que les processus et les outils
2. Des logiciels opérationnels plus qu’une documentation exhaustive
3. La collaboration avec les clients plus que la négociation contractuelle
4. L’adaptation au changement plus que le suivi d’un plan

Je ne doute pas des points  2 et 4, pour le point n°1 je n'ai pas suffisamment de recul pour juger.
Quand au point numéro 3, les clients de Google ne payent pas mais il n'y a pas de collaboration ou de négociation entre les équipes Google et les utilisateurs.
 La réponse est donc oui Google travaille en mode agile!!

Voyage en mode agile : le bilan

Comme dans un projet informatique gèré en agile, un projet de voyage comporte une partie bilan.

C'est le moment où tous participants font le point ensemble, ils disent les choses qui se sont bien passés et les choses qui se sont moins bien passés.

Les points forts:

- adapter les étapes à la réaliser du terrain. Les espaces sont grands, les temps de trajets sont importants

- le rythme de vacances n'est pas aussi rapide que celui du travail.

Il faut tenir compte du décalage horaire à l'arrivée, prévoir 24h à 48h pour s'habituer à la nouvelle civilisation du pays: monnaie, différence des mesures, de la langue, conduite ....

Les points faibles :

- l'organisation macro entraîne régulièrement des questions : qu'est ce que l'on fait?  

Il faut pour chaque période planifier l'hébergement, recadrer éventuellement le parcours ....

En conclusion, l'agilité dans un voyage est plutôt réservé à des experts du voyage qui arrivent à s'exprimer au moins en anglais et qui acceptent en voyage d'improviser au jour le jour leur voyage en fonction de leurs inspirations mais aussi de leurs rencontres.

Je vous recommande un site internet fait par des voyageurs agiles

www.peoplewhotravel.com

Mes vacances en mode Agile!!

Voici un sujet bien en relation avec le mois d'Aout et donc en relation avec les vacances !!

Il faut d'abord définir où l'on veut aller c'est la feature, il faut ensuite définir les sprints Se seront nos étapes

Feature: Californie

Les sprints seront nos Etapes : Los Angeles, Las Végas, les Parcs, La Vallée de la mort, San Fransisco

La durée du sprint : 2 à 3 jours

Equipe : les 4 personnes qui composent notre groupe

Nous avons réservé les billets d'avion, les premières nuits à Los Angeles et la voiture.

Nous avons un budget et une date de retour.

Nous nous sommes documentés sur la région, avons confronté nos idées avec nos amis voyageurs, fait des recherches sur Internet, consulter les guides.

Nous sommes forts de notre connaissance relative, de notre souplesse, de notre esprit d'aventure.

Nous déciderons à chaque étape, collégialement le détail de la prochaine : lieu, visite, hébergement, budget; de façon itérative en s'adaptant  à nos rencontres, aux envies, à la météo et au budget restant.

Pour les curieux, le récit de notre voyage se trouve sur le site de www.peoplewhotravel.com

Et pour finir voici la devise du jour en anglais svp.

Bonnes fins de vacances 

No battle plan ever survives contact with the enemy

- Helmuth von Moltke –

Exemple de projet Gérer en méthode Agile par Cap Atlantic Consulting

IOD@ est un produit de gestion de la traçabilités des livraisons logistiques, cette solution est totalement développé en mode AGILE.

Dés le démarrage, nous avions pris conscience de 2 contraintes majeures:

-       le délai de réalisation est de 3 semaines 

-       le déploiement national et la formation sont de 1 semaine

Pour le chef de projet, la complexité était, justement d’arriver à avoir à la fois une vue microscopique qui va dans le détail, mais aussi une vue macroscopique pour pouvoir anticiper et piloter le dynamisme global nécessaire autours du projet : la gestion des ressources, la communications en continue, les interactions avec les autres outils, … etc

Il faut imaginer une représentation où l’équipe  de développement est au cœur du dispositif projet et gravite autours toutes les autres équipes.

Le chef de projet joue un peu le rôle du maestro. L’interaction entre les équipes est en continue. Chaque intervenant  valide le processus global et les actions dont il a la charge, le tout dans un système souple et dynamique.

Chaque action est précise et courte y compris le processus de validation. 

Le projet est actuellement opérationnel, toutes les contraintes ont été respectées, 

www.ioda.link/dhl

https://play.google.com/store/apps/details?id=com.capAtlantic.ioda

https://www.powtoon.com/show/dIGvRsGNQ9r/la-solution-iod/

Chiffrage: Méthode traditionnelle versus Méthode Agile

Dans un projet gérer selon la méthode traditionnelle du cycle en V c'est le chef de projet qui fait le chiffrage avec éventuellement l'avis des développeurs.
C'est lui qui est le garant du chiffrage et du planning.

Dans les méthodes Agiles, le chiffrage n'est pas au niveau du projet mais au niveau de la User Story.
Une User Story s'intègre à un sprint et cela permet de définir une planification.

C'est l'équipe qui est responsable du chiffrage, cela demande un consensus.
Les difficultés sont réparties dans des classes de difficultés qui suivent le suite de Fibinacci {0.1/2, 1, 2, 5, 8, 13, 20...}
Les chiffres ne représentent pas des heures ou des jours de travail mais une unité propre à l'équipe.
Par exemple, sur le projet sur lequel je travaille, le print de deux semaines représente 22 points en moyenne.
Les user Story sont classées lors d'une réunion appelée planning poker.
Dans la première partie de la réunion, l'équipe (les développeurs et les recetteurs) qualibre les US.
Chaque membre de l'équipe indique par une carte le nombre de points de la US. S'il y a un écart, les membres discutent et par un deuxième tour arrive à un consensus.
Le Product Owner ne participe pas au chiffrage.
Dans un deuxième temps, l'équipe choisit avec l'aval du Product Owner, les User Stories  à embarquer dans le sprint.
Dans le cas de mon projet, l'équipe ne peut pas embarquer plus d'une vintaine de points pour la quinzaine.

A l'inverse d'un chiffrage selon la méthode traditionnelle, le chiffrage est obtenu par le vue des différents experts  (développeurs, base de données, recetteurs), tous sont impliqués dans la réussite du sprint et du projet.
C'est une méthode collaborative qui demande aussi une souplesse d’esprit et un bon esprit d'équipe  !

Découvrir la méthode agile fut pour moi une révélation !

Vous allez trouver mon titre surprenant: découvrir la méthode Agile fut pour moi une révélation !
Je me décris comme un chef de projet multi-projetS : Projets pro, perso et associatif plutôt traditionnelle 
Vous pouvez retrouver cela dans mon interview à jeudi au féminin 

La méthode agile est plutôt une philosophie agile que nous utilisons tous, Comme Monsieur Jourdain faisait de la prose sans le savoir...
Je retiendrai ici  plutôt la souplesse et l’apprentissage.  La méthode agile permet de se tromper et comme on travaille de façon incrémentale d’apprendre de ses erreurs. Elle prône l’esprit d’équipe plus important que l’individu. 
Quand il y a un problème, on ne cherche pas quel est le coupable mais comment s’en sortir comment capitaliser.
 Cette méthode apporte un vrai changement par rapport à la méthode de cycle en V.
La relation client / fournisseur ne peut plus être la même. On doit remplacer le forfait bien bordé juridiquement par une relation win / win.  Cela entraîne un changement  de conduite du projet qui concerne toute l’équipe fournisseur et toute l’équipe client. 
Êtes-vous prêts à changer ? A apporter un peu plus de souplesse dans vos projets ? Un peu plus de communication ?
Soyons agiles !
A jeudi prochain 
Christine