Carnet de route : Le ScrumDay 2014 (3/4)

Nouvelle journée, nouvelle énergie. Après la journée conférence que je vous ai comté ici et ici, voici la journée consacrée à l’open-space, à l’image de ce qui se fait à Grenoble depuis quelques années déjà.

L’organisation met à notre disposition tout ce qu’il faut pour se remettre dans le rythme : thé, café, jus de fruits, viennoiseries…

image

Mais on est vite intrigué par le grand cercle matérialisé à même le sol autour duquel nous sommes invités à nous rassembler pour débuter cet open-space.

image

Ce sont Laurent Bossavit et Raphael Pierquin qui se chargent d’expliquer les règles de fonctionnement de l’Open-space … ou du moins tentent de le faire ! Apparemment, la sonorisation pose quelques problèmes…

image

Le principes sont en fait assez simples. Une fois établis, il est temps d’utiliser le matériel mis à notre disposition au centre du cercle pour proposer nos sujets.

image

Ces sujets sont ensuite eux-mêmes affichés sur les différents créneaux horaires en mode auto-organisé. C’est la « place de marché ».

image

J’ai posté mon propre sujet. Il est temps de faire le tour de ceux qui peuplent le premier créneau horaire. Et je reste un peu perplexe devant le sujet traitant de l’utilisation des points de fonction dans les projets agiles. Quand je vois ce genre de sujet, mon reflexe est de me demander en quoi ces techniques peuvent nous apprendre quelque chose, si la technicité développée ici peut nous aider. Laurent Bossavit semble plus circonspect quand aux motivations. Du coup, nous décidons tous deux de nous joindre à ce débat.

Agilité et point de fonction

La première chose qui me trouble est une certaine confusion entre l’outil et l’usage. Dans l’esprit de beaucoup, il y a une relation directe entre projet au forfait et point de fonction.

image

En fait, il semble même que nous ayons un pattern d’usage : on se sert des points de fonction comme outil « commercial » pour chiffrer une réponse à appel d’offre. Ensuite, lors de la réalisation, on se servira des story points. Voilà un constat assez troublant pour moi, bien qu’instructif sur la vision que l’on peut avoir des différents outils :

  • Les points de fonction sont vus comme un outil donnant un chiffre absolu, alors qu’il donne un chiffre relatif (les points) qui se transforment en charge via des facteurs d’ajustements. Comme les story points, en fait, bien que de façon plus complexe.
  • Quel est l’intérêt de faire un « chiffrage agile » si en amont le projet est de toute manière verrouillé par un chiffrage contractuel ? Je dirais même : quel est l’intérêt de faire le projet en agile, mais c’est sûrement une autre question…

La discussion s’est beaucoup focalisée sur l’usage de l’une ou l’autre approche, alors que je pense que la question n’est pas là : on peut parfaitement utiliser les FP ou les story points dans les mêmes contextes.
Par contre les points de fonctions traitent des « blocs » plus gros, qui sont ensuite décomposés sous l’angle technique (requêtes, entités, I/O, etc…), alors que les story points s’adressent à des blocs plus fins que l’on évalue globalement, en différent les questions sur les choix de conception. Par son approche les points de fonction « vérouillent » les choix techniques dès le chiffrage.

image

J’ai été assez déçu par le débat qui ne s’est finalement pas dirigé vers la question de la nature de ces différents types d’estimation (ce que j’évoque plus haut). Dommage…

Ressources Humaines et agilité

Ce sont à la fois l’originalité du sujet et son importance qui m’ont attiré vers ce groupe. Une groupe à coloration un peu « grandes gueules » avec Pablo Pernot et Pierre Neis, par exemple !

image

Tout d’abord, quels sont les problèmes ?

  • La gestion du parcours professionnel.
  • La gestion des évaluations.
  • La dissonance cognitive entre rôle et fiche de poste.

Le constat partagé par tous est qu’aujourd’hui les RH ne sont pas une aide au sein des projets agiles. Dans le meilleur des cas. Dans le pire des cas, elles sont un frein, voir un obstacle. Bref, il n’y a pas grand monde dans le cercle à aimer les RH. On entend même que les RH n’ont pas de raison d’être !

image

Mais il nous faut aussi admettre que l’on doit mieux comprendre le problème des RH : celui de devoir composer avec la loi, le management, les syndicats, le C.E., etc… En fait, il nous semble que leur effort porte plus sur la composition de ces contraintes que sur une véritable fonction support au sein de l’entreprise (ce serait plutôt un fonction contrainte !). Le mécanisme des entretiens annuels est bien entendu montré du doigt.

Alors, quelle solution pour la RH dans un environnement agile ?

C’est que cette RH devienne elle-même agile, en portant les valeurs agiles au niveau de l’entreprise. Entre autre choses.

image

Pause déjeuner

Pas de pause déjeuner bien calée dans le temps pour cette journée open-space ! Les session occupent les créneaux horaires sans discontinuer. Aux participants de faire une pause quand ils le désirent !

image

On est un peu plus en mode picnic que la veille, d’ailleurs les tables ont disparu au profit de quelques « mange debout », mais on s’assoit aussi par terre.

image

Cela ne veut pas dire que la qualité n’est pas au rendez-vous. Au contraire ! Je n’ai aucune raison de renier mes éloges d’hier. Jugez-en !

image

De mon côté, j’ai passé cette pause déjeuner avec Pierre Hervouet, Joumana et Pierre Neis. Pierre Neis nous parle (et nous montre des photos) de #play14, un rassemblement autour des agiles games qu’il co-organisait au Luxembourg. Prochaine étape : en faire une sorte d’Agile Tour des agile games !

Le bureau du SUG en mode Happy

Christopher Mann était le photographe de ce ScrumDay (il avait fait un excellent boulot lors d’Agile France, une bonne raison pour moi de le recommander pour cet évènement). J’ai suivi le mouvement, quand lui-même et le bureau se sont dirigé vers l’extérieur pour ce qui semblait une photo de groupe. Le résultat est visible sur le reportage du ScrumDay, mais j’ai aussi pris mes propres clichés…

image

Backlog, cher boulet…

J’avais aussi soumi mon propre sujet. En quelque sorte une reprise d’un de mes thèmes préférés sur le backlog produit, à la fois vision de ce qu’il y a à faire et frein du changement.

image

Au final, on trouve deux grand types de situation :

  • Les projets agiles « classiques » où la vision d’un périmètre complet est plutôt une chose souhaitée. Le backlog Scrum rempli bien son office car il donne une vue partagée à tous les acteurs du « reste à faire ».
  • Les projets innovants pour lesquels on essaie de limiter le stock par diverses approches (parfois combinées) : approche type « kanban » où l’on limite volontairement et activement le nombre d’items dans le backlog, où backog à granularité différentielle, à deux ou trois niveaux.

Dans le cas d’une approche « kanban » nous nous sommes posé la question d’évacuer, c’est à dire supprimer les items de plus basse priorité dépassant le WIP. Nous en sommes arrivés à la conclusion qu’il n’y a aucun dommage à le faire : si l’item est important, il reviendra !

J’ai aussi évoqué les sujets qui m’interpellent en ce moment : combiner un backlog (limité) avec une approche type impact mapping et/ou Lean Canvas. Mais nos réflexions n’ont pour l’instant pas abouti…

image

Clôture des ScrumDays

Ce grand open-space s’est terminé par une retrospective type « tour de parole ». Un tour de parole à près de 200 personnes, il faut dire !

image

Il me manque le courage (ou la motivation) pour en être. Je préfère passer un peu de temps avec Samira Batahouche d’IBM qui représentait Big Blue au bureau l’an dernier et avait accueilli le ScrumDay à Bois Colombe l’an dernier.

Le stand de Cloudbees est juste à côté, j’en profite pour fixer pour la postérité Nicolas De Loof en hôtesse d’accueil…

image

Scrum.org était aussi partenaire du ScrumDay cette année. Je me suis vu interdire de prendre le stand en photo, une première pour moi. J’ai moi-même étendu cette interdiction à la keynote de clôture faite par son représentant (je ne me souviens même plus de son nom, pourtant il s’est cité lui-même durant sa présentation).

J’avais aussi décidé de ne prendre aucune note de l’intervention pour faire bonne mesure. Grand bien m’en a pris : elle manquait complètement d’intérêt, j’ai failli quitter la salle. Finalement je suis resté et j’ai consulté mon fil Tweeter pendant le reste de la présentation.

Si j’étais parti, je n’aurais pu prendre en photo l’équipe du French SUG, et cela aurait vraiment été dommage. Grand merci à toute l’équipe pour ce bel évènement ! De droite à gauche : Anne, Christopher, David, Arnaud, Valérie, Karine, Laurence et Xavier.

image

Voilà, il est temps de replier tous le matériel, et de tout remettre dans les cartons … jusqu’à l’an prochain.

image

Note à moi-même

Pour ce qui est du format tout d’abord : le ScrumDay (ScrumDays, donc comme je l’ai écrit par ailleurs), ça marche ! Les open-spaces dans des « coins de salle » ne sont toutefois pas une configuration idéale. il faudra trouver mieux et surtout moins bruyant !

Cette année, le thème était la « culture produit ». En fait cela ne me paraissait pas si évident au vu du programme. Maintenant, est-il nécessaire d’avoir des thèmes annuels ? Des tracks thématiques feraient assez bien l’affaire.

Concernant le lieu, eh bien il a clairement la taille voulu pour accueillir l’évènement. Le hall central (qui hélas n’était pas central) permettait une bonne circulation. Les stands des sponsors étaient disposés sur le pourtour.

Question sponsors, leur nombre était réellement à l’inflation, et cela fait un peu ressembler le ScrumDay à une expo (sans compter un traitement pas différentiant des platinums) … La raison est bien entendu le coût d’organisation, car le lieu est apparemment très cher, malgré son éloignement de Paris.

J’avais crains que cet éloignement, justement,  soit une cause de désaffection, d’autant que la venue en voiture n’est pas vraiment facilitée (pour ne pas dire franchement découragée), mais il semble au final que ce facteur n’ait eu aucune influence.

Bref, un bel évènement, avec deux fois plus de plaisir pour deux fois plus de durée !

Une dernière chose : nous n’en avons pas fini avec ce ScrumDay : je vous ai promis un 4ème volet : ce sera un « bonus track », je n’en dis pas plus. Je ferais aussi un petit post sur mon atelier sur l’acceptance testing.

Note de lecture : Software Project Management, par Walker Royce

Note : 6 ; La gestion de projets selon Unified Process.

Un ouvrage un peu dense et un peu difficile à lire, mais dont le contenu est indéniable, notamment sur les métriques de suivi de projet. Walker Royce porte un fardeau assez difficile : son père, Winston, est en effet l’auteur d’un article décrivant le cycle en cascade qui est à l’origine du « cycle en V »… à son corps défendant !

Les 4 parties constituées de 17 chapitres de la partie principale du livre couvrent un peu plus de 250 pages. Il faut y ajouter les très conséquentes 5 annexes de la 5ème partie qui totalisent à elles seules 150 pages !

La première partie « software management renaissance » comprend 4 chapitres et un peu moins de 70 pages. Bien entendu, le premier chapitre traite du modèle en cascade présenté dans l’article de 1970 de papa Royce. Plutôt que de critiquer son géniteur, Walker fustige, à juste titre je dois dire la manière dont le modèle a été mal compris. Le second chapitre, s’il est court avec sa dizaine de page, n’est pas une ballade de santé. Il présente l’évolution de l’économie du logiciel en terme de ROI, coût par SLOC, etc. En comparaison le 3ème chapitre qui présente logiquement l’amélioration de cette économie est nettement plus accrocheur. L’auteur y évoque l’influence de différents paramètres tels que le langage de programmation, l’utilisation de la conception orientée objet ou la pratique du peer review. Cette première partie se conclut par la comparaison des « anciens principes » contre les nouveaux (ceux de l’auteur). J’ai trouvé l’énoncé des 30 principes de Davis bien plus intéressante (même si certains sont clairement erronés), en regard des 10 principes de Royce.

La seconde partie « a software management process framework » rentre dans le dur de UP. 65 pages sur 5 chapitres y sont consacrés. Le chapitre 5 se focalise sur le concept de phase (vous savez, celui que l’on a abandonné avec agile…). Bien entendu ce sont les 4 phases d’UP qui y sont évoquées. C’est sans surprise que l’on aborde le chapitre 6 qui s’avère consacré à la question des artéfacts projet, les 25 pages de se chapitres évoque l’existence de nombre d’entre eux en les ventilant sur 5 pratiques d’ingénierie. Un chapitre que j’ai du mal à trouver passionnant, bien qu’il soit central dans les méthodes prescriptives et finalement bien abordé ici, y compris la discussion sur l’usage et l’apport d’artefacts formels. Les deux chapitres suivants sont étrangement courts. D’abord le chapitre 7 sur les modèles n’évoque que l’existence de 5 modèles (qui rappellent les 4 + 1 vues de Philippe Kruchten), mais sans aller plus avant parce que hors du sujet de l’ouvrage probablement. Ensuite le 8 chapitre 8 nous parle du workflow de l’itération, décrivant celle-ci comme un mini waterfall. Beurk ! Le dernier chapitre de cette seconde partie est plus ésotérique en évoquant les jalons majeurs et mineurs.

La troisième partie « software management disciplines » couvre 85 pages sur 5 chapitres. Il commence avec le chapitre 10 qui aborde la planification itératif et son outil phare : le WBS (Work Breakdown Structure). Encore un truc que l’on ne fait plus en agile. Toutefois si vous voulez rentrer dans le sujet, vous avez là une référence de première main. Non seulement il donne une méthode de découpage, mais évoque les répartitions budgétaires relatives et leur évolution en fonction des phases du projet ! Le chapitre 11 lui traite de l’organisation de projet, au sens « administratif ». C’est donc à des organigrammes qu’il nous faut faire face, avec des listes de responsabilités et tout et tout… Le chapitre 12 focalise sur l’automatisation du processus et notamment du change control. Bref, pas mal d’outillage « projet ». Fort logiquement, au chapitre 13, ce sont les indicateurs de management qui sont à l’honneur et principalement le fameux Erned Value Tracking (EVT). Le chapitre 14 aborde la customisation du processus (car UP se customise). Walker Royce aborde cela en classant les types de projet en 2 dimensions : la complexité technique sur un axe et la complexité de management sur l’autre. Chaque axe nécessite une emphase particulière sur certaines disciplines et certains artefacts. Il n’y a plus qu’à combiner les deux, hein ?

La dernière partie du corps du livre « looking forward » ne compte que 3 chapitres et se contente donc d’une trentaine de pages. Elle débute par le chapitre 15 qui évoque les projets dits « modernes ». C’est finalement là que l’on retrouve des choses qui se rapprochent le plus des projets agiles : des exigences qui évoluent, de l’intégration continue, mais le tout encore et toujours dans les fourches caudines d’XP aux forceps. Au chapitre 16, on tente de tourner notre regard vers un nouveau modèle économique des projets. Il s’agit en partie d’une remise en cause partielle des postulats de Boehm dans le cadre des développements actuels. La partie textuelle de cet ouvrage se conclu par un chapitre 17 assez courts évoquant les problèmes de transition vers ces processus…

La 5ème partie du livre est consacrée aux annexes. Comme je l’ai dit, elle est franchement volumineuse. L’annexe A évoque l’état des pratiques en s’appuyant sur des rapports. Hélas tout ce ceci n’est plus d’actualité, mais cette partie est au moins courte ! L’annexe B rentre dans le modèle COCOMO 2 de Boehm, et on s’en tire pour une vingtaine de pages. Une dizaine de pages sont consacrées à des métriques de changement qui à mon avis ne servent à rien. L’annexe D est un cas d’étude et franchement il faut être motivé pour s’en taper les 60 pages. Enfin, même si l’annexe D compte 30 pages, il est plus facile de s’y intéresser : challenger UP face à CMM peut s’avérer instructif.

Le livre est dense, très dense. Il traite de processus semi-prescriptif est déballant beaucoup de matériel, beaucoup de concepts et un niveau de technicité, en processus, en métriques et un petit peu dans tout, il faut bien le dire, qui est très élevé. Le vrai risque est d’être un peu noyé à force d’en vouloir pour notre argent. L’erreur de l’auteur est d’essayer d’augmenter le niveau de technicité, de finesse dans la maitrise et la gestion de projet, là où la clé serait plutôt la simplification.

software-proj-mgt-unified-framework

Référence complète : Software Project Management: A Unified Framework – Walker Royce – Addison Wesley 1998 – ISBN: 0-201-30958-0

Software Project Management: A Unified Framework

http://www.goodreads.com/book/add_to_books_widget_frame/0201309580?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on