Maven 3 : avoiding duplication of information, make stuff easy to maintain

Leave a comment

This post in the 3rd one of a series on maven3. You can find the information related to the demo project used in example here.

One of the painful thing with all build management system, is the maintenance.

Setting it up at the beginning is ok, but maintaining it over time take time. Ensuring that all tools run on all modules, with same version, that the experiment you made on one module, or on a subset of module do not brake the whole things ….

So, in this post will see some tips to avoid information duplication in order to ease maintenance.

1: use pomParent mechanism to share most of the configuration

The pom parent mechanism is an “inclusion like” mechanism. It’s well defined here.
In the demo project, you have it located in the PomParent directory, and it’s used in all the others pom files.
In the following pomParent I am :

  • defining common properties (java version, encoding, plugin version) use in all pom files
  • defining plugin management element for all plugin used in one of the pom, in order to have plugin version centralized in one location
  • defining developer, license, organisation in one location

PomParent content :

   <project>
<modelVersion>4.0.0</modelVersion>

<!– The Basics –>
<groupId>com.persistentsas.mavenTraining.PomParent</groupId>
<artifactId>parent</artifactId>
<version>1.9-SNAPSHOT</version>

<packaging>pom</packaging>
<properties>
<!– build mechanism property –>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<!– Plugin having a custom setting –>
<maven.pmd.plugin>2.7.1</maven.pmd.plugin>
<pmd.java.version>1.7</pmd.java.version>
….
</properties>
<dependencyManagement>
…..
</dependencyManagement>
<modules></modules>
<!– Build Settings –>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<configuration>
<encoding>${maven.resources.plugin.encoding}</encoding>
</configuration>
</plugin>
……
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>${maven.release.plugin}</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>${maven.site.plugin}</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>${maven.findbugs.plugin}</version>
</plugin>
…………….
</plugins>
</pluginManagement>
</build>
<reporting></reporting>

<!– More Project Information –>
<name>parent</name>
<description></description>
<url></url>
<inceptionYear></inceptionYear>
<licenses>
<license>
<name>Apache License, Version 2.0</name>
<url>http://www.apache.org/licenses/LICENSE-2.0.txt</url&gt;
<distribution>repo</distribution>
<comments>A business-friendly OSS license</comments>
</license>
</licenses>
<organization>
<name>PersistentSAS</name>
<url>http://www.persistentsas.fr</url&gt;
</organization>
<developers>
<developer>
<id>LaurentT</id>
<name>Laurent Tardif</name>
<email>Laurent.Tardif at persistentsas.com</email>
<url>http://www.persistentsas.fr</url&gt;
<organization>PersistentSAS</organization>
<organizationUrl>http://www.persistentsas.fr</organizationUrl&gt;
<roles>
<role>architect</role>
<role>developer</role>
</roles>
<timezone>+1</timezone>
<properties>
<picUrl>http://www.persistentsas.fr</picUrl&gt;
</properties>
</developer>
</developers>
<contributors></contributors>

<!– Environment Settings –>
<issueManagement></issueManagement>
<ciManagement></ciManagement>
<mailingLists></mailingLists>
<scm></scm>
<prerequisites></prerequisites>
<repositories></repositories>
<pluginRepositories></pluginRepositories>
<!– not inherited –>
<distributionManagement>
<site>
<id>${project.artifactId}-site</id>
<url>file:///c:/temp/site/${project.artifactId}/${project.artifactId}.${project.packaging}</url>
</site>
<repository>
<id>GrenobleWrite</id>
<name>artifatoryWrite</name>
<url>http://MyBinaryRepo:8081/artifactory/libs-release-local/</url&gt;
</repository>
<snapshotRepository>
<id>GrenobleWrite</id>
<url>http://MyBinaryRepo:8081/artifactory/libs-snapshot-local/</url&gt;
</snapshotRepository>
</distributionManagement>
<profiles></profiles>
</project>

Inclusion in other pom :

<parent>
        <groupId>com.persistentsas.mavenTraining.PomParent</groupId>
        <artifactId>parent</artifactId>
        <version>1.9-SNAPSHOT</version>
<!– hint path, not mandatory –>
        <relativePath>.\PomParent\parent.pom</relativePath>
    </parent>

2: use properties to centralize in a common place important informations.

This is the first advise I’ll give. Use properties to put in a common place, informations your need to share.

you can define as many properties you want, and reuse them in any part of the pom file. If you define them in a PomParent, you can reuse them in all pom files. That’s help having easy to maintain project.

Among the practices i liked (but not every one agreed :-), I’m agree also to say that in the example, it’s a bit too much :-), but it’s an exercise … ), is to duplicate variable definition, in order to know where it’s used. That make also my life easier when the value need to be changed locally.

<properties>
<!– build mechanism property –>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>${project.build.sourceEncoding}</project.reporting.outputEncoding>
        <maven.resources.plugin.encoding>${project.build.sourceEncoding}</maven.resources.plugin.encoding>
        <maven.compiler.plugin.encoding>${project.build.sourceEncoding}</maven.compiler.plugin.encoding>

        <maven.deploy.plugin>2.8.2</maven.deploy.plugin>
        <maven.checkstyle.plugin>2.7</maven.checkstyle.plugin>
….
</properties>

 3) define common build step in the pom Parent

In the pom parent you can define common build section in order to centralized that.

Now Imaging you have 4 modules, let’s say two standard jar libraries, and two webservices with code generation, and so on….

The build steps are not common to the 4 modules, but in this case you can make 3 pomParent :

1) first one common to every one (with dependencies version, common variables, … )

2) Second one, including first one, and defining build step for jar

3) 3rd one , including first one, and defining , source code generation, and so on for webservices.

Maven 3: some useful tips

Leave a comment

Maven is a build tool, but not only. It’s able to manage to whole lifecycle of your library/application.

I’ll use the project describe in a previous post and the source is available on github.

 

 1 : Work online / offline

One of the common usage of maven, is to work most of the time connected. Before going deeper, let explain quickly how maven work. when you run the following command to display the project hierarchy :

mvn dependency:tree

It will check on you build repository for new snapshots, or dependencies update to display it. There’s lot of command that will lead to an update of either your project dependencies, or the plug-in used by maven to build your project.

In order to control when you check update or not, you have the –offline to disable all remote access, and the -U as example, to force verification of updates. The maven –help command list all the options possible at Maven level, it’s independent of the content of your pom, or of any setting you defined.

mvn –offline dependency:tree

 

2: Use several thread to work

By default, maven will use One thread to work. Since maven3, you can use several thread to do the job.

You have 2 options to define the number of threads to use

  • The first one is by explicitly specifying the number of threads to use (2 in the example)

mvn -T2 compile

  • The second one is by specifying the number of thread relatively to the number of core you have on the PC (2 thread per core in the example)

mvn -T2C compile

The second option is very interesting on a heterogeneous build farm or in script, where you can adapt you number of thread regarding the number of cores available at run time.

 

3: Build partially your project

You can also optimise your build time , when running  :

mvn compile

Maven will build the list of project/module to build, and will determine a build order.  For each module, it will check if building it make sense (if no sources, tests or ressources change, there’s no point to rebuild the project).

Even if the verification is efficient, doing it on large project make no sense when, as a developper, you know where you change stuff, and want to do only a partial build.

Let’s see some running examples :

mvn compile

will generate a full build

[INFO] Scanning for projects…
[INFO] ————————————————————————
[INFO] Reactor Build Order:
[INFO]
[INFO] module1
[INFO] module2
[INFO] project1
[INFO] P2module1
[INFO] project2
[INFO] Root
[INFO]
[INFO] ————————————————————————
[INFO] Building module1 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO] Compiling 1 source file to C:\Dev\GITHUB\mavenTraining\Project1\module1\target\classes
[INFO]
[INFO] ————————————————————————
[INFO] Building module2 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO] — maven-compiler-plugin:2.5.1:compile (default-compile) @ module2 —
[INFO] Nothing to compile – all classes are up to date
[INFO]
[INFO] ————————————————————————
[INFO] Building project1 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO]
[INFO] ————————————————————————
[INFO] Building P2module1 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO]
[INFO] — maven-compiler-plugin:2.5.1:compile (default-compile) @ module1 —
[INFO] Nothing to compile – all classes are up to date
[INFO]
[INFO] ————————————————————————
[INFO] Building project2 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO] ————————————————————————
[INFO] Building Root 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO] ————————————————————————
[INFO] Reactor Summary:
[INFO]
[INFO] module1 ……………………………………. SUCCESS [  1.020 s]
[INFO] module2 ……………………………………. SUCCESS [  0.017 s]
[INFO] project1 …………………………………… SUCCESS [  0.001 s]
[INFO] P2module1 ………………………………….. SUCCESS [  0.013 s]
[INFO] project2 …………………………………… SUCCESS [  0.001 s]
[INFO] Root ………………………………………. SUCCESS [  0.001 s]
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 1.240 s
[INFO] Finished at: 2014-10-07T10:00:38+01:00
[INFO] Final Memory: 11M/214M
[INFO] ————————————————————————

With such small project, optimizing build time in a intellectual game, but can save lot of time on large project :) So, let’s optimize it.

You can launch the build from a module level (ex: module2). We are going to use the maven “-rf”  parameter to do so (resume from).

[INFO] Scanning for projects…
[INFO] ————————————————————————
[INFO] Reactor Build Order:
[INFO]
[INFO] module2
[INFO] project1
[INFO] P2module1
[INFO] project2
[INFO] Root
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.
count of 1
[INFO]
[INFO] ————————————————————————
[INFO] Building module2 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO]
[INFO] — maven-compiler-plugin:2.5.1:compile (default-compile) @ module2 —
[INFO] Nothing to compile – all classes are up to date
[INFO]
[INFO] ————————————————————————
[INFO] Building project1 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO]
[INFO] ————————————————————————
[INFO] Building P2module1 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO][INFO]
[INFO] — maven-compiler-plugin:2.5.1:compile (default-compile) @ module1 —
[INFO] Nothing to compile – all classes are up to date
[INFO]
[INFO] ————————————————————————
[INFO] Building project2 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO]
[INFO] ————————————————————————
[INFO] Building Root 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO] ————————————————————————
[INFO] Reactor Summary:
[INFO]
[INFO] module2 ……………………………………. SUCCESS [  0.689 s]
[INFO] project1 …………………………………… SUCCESS [  0.002 s]
[INFO] P2module1 ………………………………….. SUCCESS [  0.016 s]
[INFO] project2 …………………………………… SUCCESS [  0.002 s]
[INFO] Root ………………………………………. SUCCESS [  0.003 s]
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 0.900 s
[INFO] Finished at: 2014-10-07T10:04:05+01:00
[INFO] Final Memory: 7M/214M
[INFO] ————————————————————————

 

or even directly from a project :

[INFO] Scanning for projects…
[INFO] ————————————————————————
[INFO] Reactor Build Order:
[INFO]
[INFO] project2
[INFO] Root
[INFO]
[INFO] ————————————————————————
[INFO] Building project2 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO]
[INFO] ————————————————————————
[INFO] Building Root 1.9-SNAPSHOT
[INFO] ————————————————————————
[INFO] ————————————————————————
[INFO] Reactor Summary:
[INFO]
[INFO] project2 …………………………………… SUCCESS [  0.003 s]
[INFO] Root ………………………………………. SUCCESS [  0.068 s]
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 0.252 s
[INFO] Finished at: 2014-10-07T10:04:53+01:00
[INFO] Final Memory: 6M/214M
[INFO] ————————————————————————

 

Not so bad, we reduce build time by 80% :)

As you see, maven will scan for project,  construct the ordered list of projects, and will start build at the module or project.

You have several option to control more precisely the resume, let see some :

Options:
-am,–also-make                         If project list is specified, also build projects required by the  list
-amd,–also-make-dependents            If project list is specified, also build projects that depend on  projects on the list
-B,–batch-mode                         Run in non-interactive (batch)  mode
-fae,–fail-at-end                         Only fail the build afterwards;  allow all non-impacted builds to  continue
-ff,–fail-fast                                   Stop at first failure in reactorized builds
-N,–non-recursive                     Do not recurse into sub-projects
-pl,–projects <arg>                   Comma-delimited list of specified  reactor projects to build instead  of all projects.
A project can be  specified by [groupId]:artifactId  or by its relative path.
-rf,–resume-from <arg>          Resume reactor from specified project

Maven 3 standard layout

2 Comments

I have help a team recently to move to maven 3, and ask for “what’s the standard way to organise a project ?”.

Using Maven, you are encourage to follow convention to organise your library sources, but working at a project level you have more freedom.

When you use Maven since years, yo know there’s some good / bad practices that will make your project easy to maintain or not. Recently, some plug-in maintainer have advise a structure, and I’m pretty align with it.

So let’s describe it, and see how to benefit from it. For those interested, you can clone the repository on github, to have the files locally on your PC ( https://github.com/LaurentTardif/mavenTraining )

The project is made of :

  • 3 java libraries (2 in project 1 : module1 and module2, and 1 in project2)
  • one build-tools project
  • one pom parent project

We’ll saw later the benefit of this structure.

+—build-tools
|   \—src
|       \—main
|           \—resources
|               \—build
+—PomParent
+—Project1
|   +—module1
|   |   \—src
|   |       +—main
|   |       |   \—java
|   |       |       \—org
|   |       |           \—persistentsas
|   |       |               \—mavenTraining
|   |       \—test
|   |           \—java
|   |               \—org
|   |                   \—persistentsas
|   |                       \—mavenTraining
|   \—module2
|       \—src
|           +—main
|           |   \—java
|           |       \—org
|           |           \—persistentsas
|           |               \—mavenTraining
|           \—test
|               \—java
|                   \—org
|                       \—persistentsas
|                           \—mavenTraining
+—Project2
|   \—module1
|       \—src
|           +—main
|           |   \—java
|           |       \—org
|           |           \—persistentsas
|           |               \—mavenTraining
|           \—test
|               \—java
|                   \—org
|                       \—persistentsas
|                           \—mavenTraining
\—src
\—site
\—markdown
\—training

Now, let add some files inside this structure ;

  • Some java files in sources and tests. The current setup is minimalist, and contains one file per project.
  • A pom files per library, and some others to make life easier
  • Some files in the build-tools repository, these files will be use to share some common configuration or settings among  libraries.
  • A package-info.java to demonstrate package documentation in Java
  • a Site repository with some markdown file (.md), to demonstrate how to provide documentation up to date with your project.

C:.
|   .gitignore
|   LICENSE
|   pom.xml
|   README.md
|
+—build-tools
|   |   pom.xml
|   |
|   \—src
|       \—main
|           \—resources
|               \—build
|                       checkstyle.xml
|                       lib-filter.xml
|                       LICENSE.txt
|
+—PomParent
|       parent.pom
|
+—Project1
|   |   pom.xml
|   |
|   +—module1
|   |   |   pom.xml
|   |   |
|   |   \—src
|   |       +—main
|   |       |   \—java
|   |       |       \—org
|   |       |           \—persistentsas
|   |       |               \—mavenTraining
|   |       |                       HelloWorld.java
|   |       |                       package-info.java
|   |       |
|   |       \—test
|   |           \—java
|   |               \—org
|   |                   \—persistentsas
|   |                       \—mavenTraining
|   |                               HelloWorldTest.java
|   |
|   \—module2
|       |   pom.xml
|       |
|       \—src
|           +—main
|           |   \—java
|           |       \—org
|           |           \—persistentsas
|           |               \—mavenTraining
|           |                       HelloWorld2.java
|           |
|           \—test
|               \—java
|                   \—org
|                       \—persistentsas
|                           \—mavenTraining
|                                   HelloWorld2Test.java
|
+—Project2
|   |   pom.xml
|   |
|   \—module1
|       |   pom.xml
|       |
|       \—src
|           +—main
|           |   \—java
|           |       \—org
|           |           \—persistentsas
|           |               \—mavenTraining
|           |                       HelloWorld3.java
|           |
|           \—test
|               \—java
|                   \—org
|                       \—persistentsas
|                           \—mavenTraining
|                                   HelloWorld3Test.java
|
\—src
\—site
|   site.xml
|
\—markdown
|   index.md
|
\—training
Training.md

Now, let describe what are the benefit of such layout.

  1. You have all items related to a project, inside a project (pom, source code, test code, resources)
  2. You are able to share common build related configuration file using the build-tools repository
  3. you have several pom to make a hierarchical build, let’s call them aggregator pom for the moment
  4. you have “master” pom at the root of the project, that allow you to easily build, tests all your projects, but all to run command on a dedicated module.
  5. you do not duplicated informations inside build (versionning, behavior, …) using pomParent mechanism.

We’ll see in the next posts, how these functionalities works.

Le PO et la gestion du projet au quotidien: 6 qualités/facteurs de plus

Leave a comment

Nous avons vu dans le post précédent qu’avoir un backlog utile et à jour n’était pas si évident. Malheureusement, un bon backlog, ne suffit pas pour avoir un projet qui se déroule bien.  Dans Scrum, le Scrum Master est le garant du processus et il doit donc s’assurer que le processus ce déroule bien. Le PO (ou les artefacts dont il a la responsabilité : backlog, story) à/ont un rôle clé dans beaucoup des cérémonies : sprint planning, demo, ….

Le PO a donc un rôle clé, et je vais essayer de lister les points de vigilance qu’il doit avoir au quotidien sur ses projets.

  1. From the book : j’ai vu beaucoup d’implémentation de l’agilité, ou dès les premières itérations les équipes ont commencés à customiser scrum pour de “bonnes” raisons, en oubliant souvent l’esprit de scrum ou de l’agilité.  Quand on regarde les cérémonies scrum avec l’œil d’un PO, on pense immédiatement aux Démos et au sprint planning.  Un petit rappel de quelques bases pour nos PO :
    • Au début du projet on définit le DONE avec l’équipe, et on le raffine régulièrement si nécessaire
    • On ne démontre que les stories finies, sans défauts et avec tous les tests qui réussissent.
    • Si possible, l’équipe ne découvre pas la story au sprint planning, on a le droit d’en discuter avant, notamment pour clarifier les critères d’acceptances.
  2. Les rétros : souvent utilisées pour régler des problèmes, elles peuvent aussi servir à l’amélioration de l’équipe.  Voici quelques bonnes pratiques liés aux rétro :
    • L’équipe doit faire régulièrement des rétrospectives
    • L’équipe, lors de ces rétros définit des actions à réaliser, et les réalise.
    • En tant que PO, je peux proposer des sujets de retros.
    • Je collecte les retours des équipiers et j’en tiens compte.

    Les rétros peuvent être un lieu ou de temps en temps le PO peut par exemple faire réfléchir l’équipe sur comment améliorer la qualité du produit.

  3. Les métriques : Dans le quotidien de la gestion de projet, il est important de savoir où on en est. Les métriques classiques, telles que le value burn-up (la valeur que nous avons produite) ou l’effort Burn-down (ce qu’il reste à faire) permettent d’avoir une vision de l’avancement du projet. Par contre, elles ne sont pas forcement suffisantes.  Sans non plus rentrer dans le piège d’avoir 300.000 métriques, il est important d’identifier quels sont les indicateurs qui font du sens, et ne pas hésiter à les remettre en cause, voir les changer régulièrement.
    Il est donc important pour le PO de :

    • Définir au début du projet les métriques qu’il va suivre
    • Revoir régulièrement (release, sprint, …) les métriques utilisées, et de les adapter aux nouvelles contraintes du projet
    • S’assurer que l’équipe ne fait pas une course à la métrique, rendant contre productif toutes les métriques mise en places.

    Parmi les métriques que j’aime bien, il y a par exemple, la dispersion du temps de réalisation  des stories, qui permet d’identifier si régulièrement on a des stories à problèmes, mais aussi de voir si le découpage des stories permet une implémentation dans un temps raisonnable. On peut aussi regarder la répartition entre les différents type de stories, celles ayant de la valeur cliente, les stories soit disant “techniques” et le nombre de bugs corrigés.

  4. Les livraisons : tous le projets ne faisant pas encore du déploiement continu, il existe encore souvent une phase de livraison explicite, avec une phase de qualification du produit. Parmi les anti-pattern que nous pouvons identifier il y a :
    • la phase de validation avant la release est longue (au moins l’équivalent d’un sprint)
    • L’équipe fait un sprint de finalisation.
    • Je fais des démos avec des stories qui ne sont pas complétement finies (cf. DONE)
    • L’équipe n’est pas responsable de la livraison (et peut être du packaging).

    Si on veut avoir un rythme de production soutenable et prédictible, il vaut mieux éviter les points précédant.

  5. Le Rythme : si l’équipe veut être capable de garder un rythme régulier et prédictible au cours des sprints, il est important de :
    • définir des sprint cours (2 ou 3 semaines par exemple)
    • d’avoir des estimations fiables, sans pour autant passer de longues heures à détailler et raffiner les estimations. Il est important de ce poser des questions lorsqu’une story estimée à X journées, prend au moins 25% de  plus. Le graphique sur la dispersion des temps de réalisation peut aider a identifier de telles stories. Parmi les pratiques intéressantes,  j’ai vu des équipes qui en plus des estimations sur une story, évaluaient 2 facteurs de risques : techniques et métier.
    • Les échanges entre le PO et les développeurs sont fréquents. Ces derniers ne découvrent pas les stories le jour du sprint planning, et le PO ne découvre pas l’implémentation de la story le jour de la démo …..
  6. L’amélioration continue personnelle et de l’équipe:  parmi les facteurs de succès  la volonté de s’améliorer est un des piliers clefs. Parmi les indicateurs qui montre que l’équipe est sur la bonne voie:
    • L’équipe a des réunions productives
    • L’équipe a des réunions efficaces
    • L’équipe écrit des documents utiles
    • L’équipe suit les actions définies (par exemple lors des retros)
    • l’équipe s’améliore

 

En rajoutant ces derniers items, je trouve que le terme ‘qualités’ est de plus en plus mal choisi, peut être devrais utiliser plus facteurs, ou …. il va falloir que je me creuse un peu les méninges …. affaire à suivre ..

 

 

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 et découvrons 6 des qualités du PO.

Pour illustrer les difficultés d’un PO à construite un backlog, Henrik Kniberg à réaliser une illustration parfaite, à méditer:

SplitStory

 

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)

Older Entries

Follow

Get every new post delivered to your Inbox.