La journée du PO : Le Backlog et sa gestion

Leave a comment

Et zoup, un nouveau petit post sur les activités de notre cher PO :  la gestion du backlog.

Une des premières étapes pour le PO dans un nouveau projet, est, dans mon idée, d’avoir une ébauche de son backlog et un plan de release.  En général, cette ébauche de backlog est réalisée par le PO avec les décideurs du projet, en amont du démarrage de l’implémentation.

La création du backlog se passe en plusieurs étapes. Au début, on peut utiliser des techniques comme l’impact mapping (présentée par Gojko Adzic), qui permettent entre autre d’obtenir une liste des épics avec la valeur attendue pour chacune d’elles (en définissant les hypothèses sur lesquelles les valeurs attendues sont calculées). Les informations sur les hypothèses et la valeur des épics servira plus tard pour la priorisation du backlog et la création du plan de releases.

Slide1

Dans une deuxième étape, les techniques de story mapping (ex : scrum alliance)  permettront d’aller plus loin dans le découpage des épics en stories et d’obtenir un plan de release.

Slide2

Dans une troisième phase, le travail du PO va consister à transformer le plan de release en liste de stories à implémenter par l’équipe  dans chacune des itérations.

Slide3

Notre PO, à donc maintenant un backlog,  mais attention, dans ce backlog toutes les epics ne sont pas détaillées. En effet, quel peut être l’intérêt de détailler des épics pour la release 2, sachant que nous remettrons peut être en cause le contenu fonctionnel de cette release. Pour la même raison, toutes les stories de la release 1 ne sont pas détaillées. En effet, certaines devront être découpées (suite aux estimations de l’équipe, …), ou évolueront au cours du temps.  Le PO doit faire à mon avis, le travail minimal qui lui permettra de travailler avec l’équipe, tout en ayant les informations nécessaire pour réaliser son plan de release (estimation, risques, …). Parmi les outils qui pourront aider notre PO dans l’écriture de son backlog, on peut noter la définition des personna (la vidéo de Jeff Patton illustre bien cette technique).

Une fois ce backlog en poche, notre PO peut commencer son travail quotidien et être confronté à de nombreux challenges:

  • Avoir un backlog à jour : cela semble le B-A,BA  mais est-ce que tous les PO maitrisent leur liste de livrables, questionne leur plan de release (validation des hypothèses sorties de l’impact mapping, …).
    Il doit préparer avec l’équipe les stories pour l’itération n+1 et n+2. Par préparer j’entends vérifier la compréhension de la story, définir les critères d’acceptations et peut être même l’écriture des scénarios de tests.
    Le PO doit aussi découper logiquement les stories trop grosses après l’estimation de l’équipe (Rappel : une story doit être indépendante des autres, négociable, avoir de la valeur, être estimable, réalisable en un sprint et testable). Parmi les ressources que j’aime bien pour aider a splitter les stories :
    * http://www.agileforall.com/2012/01/new-story-splitting-resource/
    * http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/
    * http://www.infoq.com/news/2011/04/how-to-split-user-stories
  • Comprendre et incorporer le fonctionnel caché : parmi les aspects que l’on oublie souvent dans le Done, ou dans un backlog nous pouvons citer la performance du logiciel, la sécurité, la traduction, la compatibilités dans les différents environnements ou l’application sera déployée ….
  • Adapter son backlog de manière continue : le travail de jardinage de son backlog est une activité quasi-quotidienne, ou le PO doit tenir compte des remarques de l’équipe, des métriques du projet, des remarques collectées lors des démos, de l’évolution de l’environnement, des retours des clients/utilisateurs, …
  • Gérer les défauts :  2 des objectifs des pratiques agile sont de rendre visible le travail réalisé, et de ne pas montrer de choses non finies (contenant un bug).  Cela implique que le PO doit rendre visible le travail réalisé sur les bugs (en donnant des métriques lors des démos par exemple),  minimiser la durée de vie d’un bug (pour rappel, un bug vue rapidement et corrigé directement par le développeur ne coute rien, proportionnellement à son occurrence en production). Il y a souvent un travail pour faire prendre conscience aux équipes de dev de l’importance ou des impacts de la non-qualité. Cela peut aussi aider l’équipe à prendre conscience de sa zone de responsabilité.
  • Tenir compte des taches techniques : qui n’a pas déjà entendu “sans le framework 2.0 on ne peut rien faire”, “on a du légacy”, mais aussi “cela est de la technique, ce n’est pas mon problème, c’est le vôtre”. Alors je sors le bouclier, et je dis non. Autant j’estime que le rôle d’un équipier est de fournir au PO les informations pertinentes (coûts, bénéfices, alternatives possibles, …), autant j’estime que le PO doit jouer son rôle d’arbitrage entre les solutions possible, et surtout dans la planification de ces évolutions dans le plan de release.
  • Gérer les releases : livrer fréquemment est possible, par contre, livrer incrémentalement de la valeur aux clients est beaucoup plus difficile et demande une discipline au PO pour ordonner les stories, valider et remettre en cause les hypothèses, supprimer régulièrement du logiciel les fonctionnalités sans ou peu de valeurs.

l’être : les valeurs d’équipe, la confiance, mon amélioration continue et la relation au monde exterieur

Leave a comment

Dans le monde agile, la collaboration de l’équipe et la confiance entre les équipiers sont des aspects important.

Dans de nombreuses migration à l’agilité, la construction de l’esprit d’équipe est souvent oubliée, et cela peut mener à l’échec de la migration ou du projet.

Parmi les activités que j’aime bien pour la construction d’une équipe, il y a l’arbre des valeurs que j’ai découvert grâce à Jean-Francois. Il permet à une nouvelle équipe d’apprendre à ce connaître.  Un des buts du jeu, et de découvrir les valeurs qui sont importantes pour un équipier, et que l’équipe construise petit à petit ses valeurs communes.

A partir de ces valeurs, l’équipe pourra alors réfléchir sur la cohérence de ces valeurs avec les piliers de l’agilité, et voir comment elles peuvent aider à la réussite. L’exercice sert aussi a identifier les points de vigilances,  quand certaines valeurs peuvent être en contradiction avec l’agilité.

Tout cela pour avoir une équipe autonome et responsable qui sera capable d’agir (et de réagir) efficacement dans la plupart des situations.

Slide2

Parmi les “Bad smell” qui peuvent indiquer que la confiance n’est pas la,  on peut citer :

  • les organisations où les équipiers n’ont pas le droit de manger ensemble (prestataires, stagiaires, … ) ;
  • les équipes avec des objectifs individuels forts ;
  • les équipes ne faisant pas de rétro constructives, en effet,  je pense que la confiance entre les équipiers est une des clés de la réussite des rétro ;
  • l’intégration ou le changement d’équipier sans accompagnement. L’ajout d’une nouvelle personne peut changer (et change souvent) certaines des valeurs communes …

Le deuxième aspect est le fait que développeurs,scrum master et PO fassent une équipe.

Le partage de valeurs et la confiance entre tous les membres de l’équipe est un début, mais cela n’est pas suffisant.

Pour atteindre une relation ou l’équipe est une et indivise dans toutes les situations (cela n’interdit pas la divergence d’opinions, mais elle doit être constructive et dans l’intérêt du projet). Il faut une interaction quasi quotidienne avec le PO. Etre PO est un travail au quotidien et il ne s’agit pas juste de gestion du backlog. Le PO doit être en relation avec l’équipe pour éclaircir les points, préciser les attentes, travailler sur les critères d’acceptation, … Cela implique aussi, que les rôles de chacun sont connus à chaque instant. On peut facilement être amener à oublier la différence entre le rôle et la personne. Par exemple, lorsque le PO est en vacances …  les équipiers peuvent penser qu’ils n’ont plus de PO …. Il est important que dans ce genre de situation, le PO “délègue” son rôle à une ou un ensemble de personne. La gestion des priorités pourra être déléguée à une personne, la validation des stories à une autre, et ainsi de suite….

Slide3

Communication Niveau 1 : Les bases de la communication

Leave a comment

Et voila notre première qualité : La communication !

Slide1

Notre PO échange régulièrement avec les clients, l’équipe et les utilisateurs. Les communications peuvent être locales/distantes,  conviviales/conflictuelles et il est donc important pour un PO de maîtriser cet outil pour être efficace dans son travail quotidien.

Parmi les outils que le PO peut utiliser pour l’aider dans cette tâche nous retrouvons les techniques élémentaires de reformulation, de questionnement, ainsi que toutes les techniques liées à l’accompagnement au changement et/ou au benchmarking.

Attention, cette thématique est difficile à appréhender pour les PO issus du monde la technique ….

Le PO doit aussi faire attention a être cohérent dans le vocabulaire employé avec tous les interlocuteurs. En effet, si le graphe affiché pour un chimiste est une courbe de calibration, le fait d’utiliser le même vocabulaire avec l’équipe de développement fera que le code utilisera le même terme. Ce qui dans le temps, rendra le logiciel plus facilement maintenable et cohérent.

Tip : quelques liens pour débuter

  • http://www.pedagopsy.eu/
  • http://attitudesgagnantes.com/10cles-apprendre-a-ecouter/ … ou comment ça je suis bavard !!!!
    J’ai eu l’occasion de participer à une séance de théâtre d’improvisation improvisé avec Aline … Quelle leçon …. ce prendre en 2 minutes dans les dents qu’on n’écoute pas :)
  • A Practical guide to distributed Scrum (Elizabeth Woodward, Steffan Surdek, Matthex Ganis)

Les 6 grandes catégories

Leave a comment

Slide20    Dans le post précédent, on m’a demandé d’être plus précis sur les 6 catégories que j’ai choisies pour guider mon PO dans sa progression, voila, je vais essayer de mettre des mots et de clarifier ce que nous avions en tête lorsque nous les avons définies.

Les 6 catégories choisies sont :

  1. L’être, l’équipe : dans cette catégorie, je mets ce qui est lié au coté humain du PO. Avec par exemple, toutes les problématiques liées à sa communication avec l’équipe, avec ses clients, …., mais aussi les aspects liés à la confiance qu’il devra instaurer avec ses différents interlocuteurs.  Ce sont des points importants pour chacun des membres de l’équipe, mais à mon avis, ils sont critiques pour le PO et le scrum master.
    Slide21
  2. Le Produit : et oui, notre PO est le champion du produit, il doit en avoir la vision, comprendre les attentes des clients et/ou des acheteurs, être capable de gérer les contraintes légales et/ou marketing, il doit anticiper les besoins des clients, valider les idées, s’assurer de la satisfaction client, … enfin, un travail à plein temps.

    Slide22

  3. Le Backlog : mot un peu fourre tout, qui va de la gestion du plan de release du produit, à la gestion des sprints, et la gestion du backlog au quotidien, ….  Cela inclut aussi la gestion des risques du projet. Notre PO doit faire tout cela, sans oublier d’offrir une vision cohérente des évolutions à l’équipe et à ses clients.

    Slide23

  4. Les Stories : écrire des stories … des livres entiers ont été écrits la dessus, avec les questions récurrentes de la gestion des défauts, des contraintes techniques, du fonctionnel caché, des critères d’acceptation….
    La manière de les écrire dépend bien sûr, un peu de l’équipe qui va les réaliser, mais idéalement pas trop … Comment trouver le juste milieu qui permet à tous les acteurs d’être efficaces ?

    Slide24

  5. Le quotidien : ou comment s’assurer que son produit sortira régulièrement avec de la valeur. Quelles métriques suivre sur son projet, comment maîtriser ses livraisons, comment garder un rythme soutenu et tout cela en s’améliorant régulièrement ?

    Slide25

  6. Qualité : mot qui fait souvent sourire, ou qui fait peur.  Entre la startup qui doit à tous prix sortir la nouvelle fonctionnalité avant la concurrence, et/ou le logiciel médical qui doit sortir sans bugs, comment trouver le juste équilibre ? Comment tirer partie des différents tests réalisés tout au long de la vie d’un logiciel, comment définir sa stratégie de tests ?
    Mais la qualité n’est pas que le nombre de bug, il faut aussi s’assurer d’avoir un processus de développement fiable et prédictible, voire sous contrôle dans certain cas.

    Slide26

Les 6 catégories, ne sont évidemment pas gravées dans le marbre et ne demandent qu’à évoluer au cours du temps :)

Les 36 qualités d’un Product Owner

2 Comments

Cela fait quelques temps que je travaille avec plusieurs collègues et des membres du groupe cara coach, pour arriver a caractériser les qualités que l’on peut attendre d’un Product Owner. Dans le monde de l’agilité on trouve facilement des articles, des conseils, des formations pour les scrum masters. Cela est tout à fait normal, ils sont un peu les gardiens du temple.

Par contre, je trouve que le Product Owner (PO) est souvent délaissé. Son rôle est pourtant tout aussi important que le Scrum master.

Le PO, est un peu le Mc Giver de l’agilité. Il doit savoir presque tout faire, et bien :

  • Il doit être à la fois capable d’avoir une vision produit, et donc une forte compétence métier, voir marketing.
  • Il doit être un leader capable d’emmener les équipes de réalisations avec lui dans le projet.
  • Il doit naviguer entre clients, utilisateurs, acheteurs, sponsors  et satisfaire chacun (ou sacrifier certains) de ses interlocuteurs.
  • Il doit être capable à partir des informations précédentes de faire un plan de release pertinent, tout en ayant des stories utilisables au quotidien par les équipes.
  • Il doit parler l’informaticien(ne)s ….  comment ça, aurais-je des-fois l’impression d’être Chewbacca lorsque je parle avec une chimiste ??? ;-)
  • Il doit faire preuve d’écoute et diplomatie pour expliquer les choix.
  • Il doit être disponible pour répondre au questions de l’équipe, …
  • et je pourrais continuer la liste encore sur quelques points.

Le PO doit donc être un sur-homme (ou femme).

J’ai la chance de fréquenter des PO qui pratiquent ce rôle depuis quelques années, et nous avons voulu essayer d’aider nos petits PO débutants dans leur progression.

Après quelques débats passionnants et enrichissants, nous sommes arrivés à une liste de 36 compétences et/ou pratiques utiles.

Nous avons réussi à les regrouper en 6 catégories :

  1. Etre/Equipe : pour tout ce qui est en relation avec les relations humaines
  2. Produit
  3. Backlog
  4. Story : en effet, c’est un sujet tellement vaste que nous lui avons donné une catégorie rien que pour elles:)
  5. Le quotidien : de l’équipe, du projet, ….
  6. La qualité :  ou comment avoir la qualité juste et adapté dans le contexte de notre projet

Fier de nous, nous avons cependant voulu aller un coup plus loin, et essayer de donner des indices de difficultés (ou de maturité) nécessaires pour acquérir un niveau supérieur. Nous avons été très originaux et utilisé un système de ceinture, connu dans tous les sports d’arts martiaux, ou dans le monde Lean.

Et zoup, 6 catégories, et 6 niveaux, cela nous fait 36 qualités.

FormationPO_Board_Empty

Mais quelles sont elles ????

—————————————> PUB <——————————————-

Un PO dojo à Grenoble : http://www.agilex.fr/2014/01/podojo-atelier-dexperimentation-pour-product-owner/

—————————————> PUB <——————————————-

La suite demain :)

Merci à  Solange, Lucie, Vanessa, Bruno, Jean, Jean-Francois, Luc, Michel pour tous les échanges constructifs

Isabelle & Laurent

[Hudson] Checker le nombre de jobs

Leave a comment

Si vous voulez avoir un job qui joue le rôle de sentinelle :


$url="http://10.190.200.87:8080/hudson/api/xml"
$path="c:\Temp\jobs.xml"
$expectedJobsNb=41
$client = new-object System.Net.WebClient
 #Download the hudson home page in xml, through the web service
$client.DownloadFile( $url, $path )
[xml] $content=get-Content $path
#Get the jobs list
$jobs=$content.SelectNodes("/hudson/job")

if ( $jobs.count -ne $expectedJobsNb ) {
    Write-Error "We do not have the good number of jobs $($jobs.count)"
    exit 1;
} else {
    Write-Output "We have the good number of jobs : $($jobs.count)"
}

Distributed CI is the present

Leave a comment

I’ve seen recently, lot of posts, articles, saying distributed CI is the future. Sorry guys, it’s the present.

When we look at evolution of tools, techniques, requirement, we saw the distributed tools having lot of success ? So, does build-master over design their build framework ? or do they already work distributed ?

In this article I’ll summarize why I think the CI is already distributed.

What’s distributed today ?

  • Teams … yep,  collocated team, became more and more uncommon. Industry requirements, specific knowledge make collocation of brains more and more difficult, even for Giant ….
  • Source Repository, as soon as your team is distributed, you need to distribute your source repository.  Of course, network speed, huge servers may give you the feeling you don’t need distributed source repository. But do you have really distributed administration ? does the team really use the power of your source repository ? Do you use pre/post build event ? how often they commit ?
  • Dependencies … of course if the team are not co-located, your build process should be able to generate a partially your application, and download up-to-date (or the version you want)  of required libraries. So shared directory, and this kind of stupid stuff, are difficult to sync across the world.  Java community have understand that with artifacts repository that you can setup in your enterprise. Indeed, some language, provide similar functionality (perl,php,ruby, python, …) but how difficult it is to setup a proxy/mirror locally (to have the process under control).
  • The build process, should allow dynamic download of dependencies. Does European, US, Indian, will download dependencies at the same location of course not ! Imagine in Visual Studio the ability to define a binaries repository for all your projects ? able to handle binaries not generated by visual ? or artefacts no generated by VS ….
  • The programming languages are more and more different. Once upon a time, project were C or ++,  Borland even Java. Now, some part are in Java, some in PHP, some in Ruby, …..  Even if you have only one programming language (C#as example), you may have to handle different version in your application ( .Net 1.0 up to .Net 4.0 as example). On large project, it’s may not make sens to keep all your libraries to the last level of your programming language. So it’s common today to have at least 3 programming languages, that you want to test on a least 5 major OS ( and if you want to test 32/64b, you double this number)
  • You clients became more and more heterogeneous, and so, you test platform is more and more complex.  If you write an application, you have to test it on at least 5 , 5 major OS, 5 major language, 5 major Web Browser, …. more than 125 combinations. Of course, if you minimized and combined some tests, you have at least  5 tests  platforms.
  • The two previous point, encourage the continuous integration framework to scale easily, and to distribute build on a farm of servers, and that, at the job level. Indeed, all your libraries, applications, doesn’t have the same constraints.
  • Static code analysis, syntax checker. As your team are distributed, don’t have the same knowledge, all your programmers can not follow the same rules at the same time. So, every thing should be configurable by libraries or project.
  • Reporting tools, as all the stuff is distributed, asynchronous, reporting tools should take that into account. Does it make sens to compare code coverage of a new project under ruby, and a legacy one in C ? Does it make sens to compare an experimented team in Java, and a team of beginners ?

So, if your build master take all these elements into account, instead of using centralized tools, you may end with a distrusted platform, allowing team to work at their speed, with their constraints, their knowledge, ….

Older Entries

Follow

Get every new post delivered to your Inbox.