Scrum : pourquoi utiliser les points ?

Dans la méthodologie Scrum, il est de coutume d’estimer la charge de réalisation des tâches avec d’autres unités que le temps, notamment les points.

Le temps passe…

Pendant un sprint de 3 semaines (15 jours ouvrés), chaque membre de l’équipe travaillera 15 jours. Le temps ne fait que passer, il est incompressible et inextensible. Mesurer en temps n’est donc d’aucune utilité car si on prend cette mesure à la fin du sprint, on trouvera à nouveau 15 jours comme prévu au départ.

En plus, si on mesure le réalisé du sprint, on va se retrouver avec des choses incohérentes. Par exemple, si l’équipe a bien fonctionné, elle aura pu réaliser une tâche estimée à 20 jours en 15 jours de travail. A-t-elle ralenti le temps ?

Le temps n’est donc pas un indicateur de la performance de l’équipe Scrum.

L’abstraction

Estimer en temps paraît plus naturel pour tout le monde. Mais les membres de l’équipe n’ont pas tous la même expérience et les mêmes capacités donc pas la même productivité. Une unité abstraite va donc apporter un relativisme propre à l’équipe et, de fait, plus juste. Chaque équipe Scrum a son propre barème d’estimation qui découle directement de ses membres, de leur mentalité et de leur expérience commune. C’est un argument en faveur de la stabilité de l’équipe.

Sans m’étendre sur les techniques d’estimation, les abstractions utilisées habituellement dans Scrum offrent un autre avantage. Leurs échelles ne sont pas linéaires et permettent d’éviter les débats stériles sur une unité (ex. 2j, 2,5j ou 3j). La suite de Fibonacci est l’abstraction la plus connue. En général, j’utilise cet échantillon avec mes équipes : 0 – 1/2 – 1 – 3 – 5 – 8 – 13 – 20

La mesure

En fin de sprint, on additionne les points des stories terminées par l’équipe pour mesurer sa performance : c’est la vélocité.

Dans la théorie, cela paraît très simple. Dans la pratique, c’est un peu plus complexe surtout si votre workflow a été enrichi et comporte des états intermédiaires autres que TODO, IN PROGRESS et DONE. C’est là que le DOD prend toute son importance.

On remarque aussi des variations dans la vélocité en fonction du type de tâches réalisées d’un sprint à l’autre. De petites tâches simples en grand nombre, faciles à terminer, auront tendance à gonfler la vélocité. A l’inverse, des tâches plus complexes, difficiles à terminer, auront tendance à la faire chuter. Le niveau d’avancement des tâches joue aussi beaucoup sur ces variations. Durant un sprint, si l’équipe a avancé beaucoup de tâches mais terminé peu, sa vélocité sera faible. Dans le sprint suivant, si les tâches commencées sont poursuivies et terminées, la vélocité gonflera grâce au travail réalisé pendant le sprint précédent.

A cause de ces variations, la vélocité ne reflète pas toujours le vrai niveau de performance de l’équipe. Ainsi, j’ai pris l’habitude de relever d’autres indicateurs à mes équipes :

  • « nombre de stories et total de story-points » embarqué au début du sprint (l’engagement)
  • « nombre de stories et total de story-points » non-commencé laissé en TODO
  • « nombre de stories et total de story-points » quasi-terminé (en test par exemple)

Cela permet de détailler le résultat du sprint et de relativiser la vélocité.

Relativiser les estimations

L’estimation de tâches est un exercice difficile et très incertain. Le mouvement « NoEstimate » le considère d’ailleurs comme un gaspillage de temps. De mon expérience, le travail d’estimation des tâches, réalisé lors du sprint-planning, a deux intérêts (dans l’ordre d’utilité) :

  1. permettre à l’équipe d’étudier les tâches, d’élaborer un plan pour les réaliser et d’obtenir un consensus sur ce plan
  2. améliorer la prédictibilité en se basant sur la performance connue de l’équipe mesurée par sa vélocité

A mon sens, la définition du plan et l’obtention du consensus de l’équipe sur ce plan justifient à eux-seuls le temps passé en estimations malgré leur faible fiabilité.

500px.com : installation du plugin Lightroom

Le site de partage de photos 500px.com est le concurrent principal de Flickr. L’équipe de 500px a développé un plugin pour Adobe Lightroom qui semble malheureusement abandonné. Je suis tout de même parvenu à dénicher et à installer la dernière version fonctionnelle.

Il est possible de partir des sources du plugin hébergées sur Github. Mais c’est un peu complexe car il faut reconfigurer le plugin et peut-être même le recompiler.

En inspectant le code source, notamment la fonction qui vérifie que vous avez bien la version la plus récente, j’ai trouvé des URLs vers le CDN de 500px :

1.11.0 https://dlcdn.500px.org/downloads/lightroom/500pxPublisher_v1.11.0.zip
1.10.0 https://dlcdn.500px.org/downloads/lightroom/500pxPublisher_v1.10.0.zip
1.9.0 https://dlcdn.500px.org/downloads/lightroom/500pxPublisher_v1.9.0.zip
1.7.1 https://dlcdn.500px.org/downloads/lightroom/500pxPublisher_v1.7.1.zip

1 – Télécharger le plugin

Récupérez l’archive de la version 1.11.0.
Dézipper-la dans le dossier d’installation de votre Lightroom. Sur mon poste, Lightroom 5 est installé dans :

C:\Program Files\Adobe\Adobe Photoshop Lightroom 5.7.1

2 – Installer le composant additionnel dans Lightroom

Dans Lightroom, rendez-vous dans « Bibliothèque » > « Services de publication » > « Ouvrir le gestionnaire de publication… ».

Gestionnaire de publication Lightroom

Cliquez sur « Gestionnaire de modules externes ».

Gestionnaire de publication Lightroom

Ajoutez le plugin 500px en sélectionnant le dossier « 500pxPublisher.lrplugin » dézippé à l’étape 1 dans votre installation de Lightroom.

Lightroom select a plugin

3 – Connecter votre compte

Dans Lightroom, dans l’écran de configuration du plugin, cliquez sur « Login ».

Lightroom authorize 500px plugin

Là, il faudra ruser un peu. La page qui permet d’autoriser le plugin à accéder à votre compte n’existe plus sur www.500px.com. Et oui, le plugin a été abandonné et n’est plus maintenu.

Page 404 sur www.500px.com

Mais le plugin vous aura tout de même redirigé dessus avec le bon token d’authentification Oauth. Récupérez la valeur du paramètre « oauth_verifier » dans l’URL.

https://500px.com/apps/lightroom?oauth_token=xxxxxxxxxxxxxxxxxxxxxxxxxxx&oauth_verifier=yyyyyyyyyyyyy

Collez la valeur du paramètre « oauth_verifier » et validez. Dans mon exemple, il faut récupérer « yyyyyyyyyyyyy ».

4 – Tout est prêt !

Vous devriez désormais voir apparaître le plugin Lightroom dans vos applications autorisées sur www.500px.com/settings/applications.

C’est tout bon ! Le plugin est installé, configuré et autorisé sur votre compte 500px. Vous pouvez désormais ajouter des photos à votre page 500px depuis Lightroom. Attention, le plugin est un peu contraignant. Vous serez obligé d’ajouter un titre, une description et des tags à vos photos pour les uploader dans le « fresh feed » de 500px. Cette option est désactivable dans la configuration du service de publication. Ces informations doivent être saisies dans les meta-données « 500px ».

Ressources

https://github.com/500px/500pxPublisher.lrplugin
https://dlcdn.500px.org/downloads/lightroom/versions.txt

Agile : comment bien terminer les sprints ?

L’un des grands concepts des méthodes Agile est le découpage d’un gros travail en petits lots. En Scrum, on parle de sprints, en français, des itérations. Ce mode de fonctionnement présente de nombreux avantages mais demande une grande rigueur.

Terminer les stories !

Un sprint délimite un cadre dans lequel l’équipe va s’engager sur la réalisation d’un périmètre fonctionnel défini par le product owner. Ce périmètre est délimité en fonction de la capacité de production de l’équipe de développement afin que l’objectif de l’itération soit atteignable.  Il est donc primordial de figer ce périmètre lorsque le sprint à commencé !

Mais ce n’est pas chose simple. Si les livraisons et la recette se font en continu, vous verrez les testeurs et le métier vous renvoyer vos stories. On peut alors très vite perdre le contrôle et passer beaucoup plus de temps sur une story que prévu initialement. Il en va de la réussite du sprint et de l’appréciation de la qualité du travail réalisé.

J’ai pris l’habitude de demander au product owner de saisir de nouveaux tickets pour ses remarques et retours sur une story livrée. On peut alors réintroduire ces demandes dans le backlog et les traiter comme les autres stories en les priorisant et en les embarquant dans un futur sprint. A l’inverse, si les retours sont faits sur la story initiale, vous aurez beaucoup de mal à la terminer et vous avez de grandes chances de la retrouver dans le prochain sprint alors que la demande initiale a été traitée. Cela fausse tous les indicateurs. La vélocité en prend un coup et l’équipe se décourage sur ces stories qui reviennent comme des boomerangs.

Pour réussir à terminer les stories, il faut définir ce qu’on entend par « terminé ». Et Scrum a des outils pour ça : le DOD et les critères d’acceptation.

Definition Of Done (DOD)

Ce concept Agile est méconnu et trop souvent inutilisé. Il prend généralement la forme d’une checklist. Exemple :

  • toutes les sous-tâches de la story sont réalisées
  • le développeur a mené des tests sur son environnement de travail
  • le nouveau code ne génère pas d’erreurs ou de warnings dans les logs
  • le code a passé les tests de qualité
  • le code a passé les tests unitaires
  • le code a été mergé sur la branche de développement
  • le code a été livré sur l’environnement de recette

Il parle plus à l’équipe de développement qu’au product owner. Il faut évidemment l’adapter au contexte du projet. Le DOD peut être global, c’est à dire valable pour chaque story. On peut aussi le redéfinir pour l’adapter à une story.

Les critères d’acceptation

Les critères d’acceptation d’une story sont fonctionnels et exprimés par le product owner. Ils servent à formaliser dans quelles conditions il estimera que la fonctionnalité livrée correspond à la fonctionnalité demandée. Par exemple, pour une notation « 5 étoiles » :

  • Sur un article pas encore noté, je vois le message « Soyez le premier à évaluer cet article ».
  • Sur un article déjà noté, je vois la note moyenne attribuée à l’article, arrondie à la décimale 0.5.
  • Sur un article que je n’ai pas encore noté, je peux attribuer à l’article une note de 1 à 5.
  • Sur un article que j’ai déjà noté, je ne peux pas attribuer une note.

On peut aussi définir des critères d’acceptation plus techniques, notamment par rapport aux performances :

  • La fonctionnalité de notation « 5 étoiles » ne doit pas augmenter le temps de chargement de la page de plus de 3%.

Il est possible de travailler d’avantage sur la formalisation des critères d’acceptation afin d’en faire des tests automatisés grâce à des solutions comme Behat.

Et les tickets de retours ? On en fait quoi ?

Il est naturellement difficile de satisfaire tous les critères d’acceptation dès la première livraison. Donc le product owner va créer des tickets pour vous transmettre ses retours sur les fonctionnalités livrées. Vous allez retrouver ces demandes dans le backlog où elles doivent être traitées comme les stories initiales : priorisées, estimées et embarquées (ou pas) dans les futurs sprints.

Si vous utilisez Jira, vous avez la possibilité de créer des sous-tâches de la story pour formaliser les retours. C’est cohérent et pratique mais cela présente une contrainte : vous ne pouvez pas terminer la story tant que toutes ses sous-tâches ne sont pas terminées. Et comme on essaie de terminer les stories pour maîtriser nos sprints, c’est contre-productif…

Si ces tickets de recette sont en trop grand nombre et qu’il est trop fastidieux de les estimer, on peut réserver un « effort » à leur consacrer pendant les futurs sprints. C’est une bonne façon d’améliorer en continu la qualité du produit. On peut aussi ajouter un sprint final de recette pendant lequel on ne réalisera rien de nouveau et qu’on consacrera uniquement au traitement des retours du métier.

Terminer les sprints !

Avec un peu de rigueur et beaucoup de communication, vous parviendrez à terminer la réalisation des stories et donc à clôturer vos sprints. C’est bon pour votre équipe qui voit le projet avancer et pour le product owner qui voit son application s’enrichir. Vous aurez alors des indicateurs fiables et vous pourrez réellement mesurer la vélocité.

 

Vérifier l’ouverture d’un flux réseau entre 2 machines

Premier article de ma nouvelle série « Kit de survie en DSI », mes astuces pour s’en sortir au sein d’une DSI quand les équipes collaborent plus ou moins bien.

Deux VMs vous ont été livrées mais il vous semble qu’elles ne sont pas en mesure de dialoguer. Pour en avoir le cœur net, nous allons tester le flux. Prenons un exemple : la machine FRONT1 doit requêter la machine BDD sur le port 3306.

Sur la machine BDD, lancer :

tcpdump -ni any port 3306

Sur la machine FRONT1, exécuter :

telnet BDD 3306

Si le flux est ouvert, vous devriez voir arriver des paquets sur BDD :

12:01:22.514085 IP xxx.xxx.xxx.4.33747 > xxx.xxx.xxx.47.mysql: Flags [S], seq 1162048942, win 14600, options [mss 1460,sackOK,TS val 254014943 ecr 0,nop,wscale 7], length 0
12:01:22.514171 IP xxx.xxx.xxx.47.mysql > xxx.xxx.xxx.4.33747: Flags [S.], seq 3654184421, ack 1162048943, win 14480, options [mss 1460,sackOK,TS val 254020172 ecr 254014943,nop,wscale 7], length 0
12:01:22.514531 IP xxx.xxx.xxx.4.33747 > xxx.xxx.xxx.47.mysql: Flags [.], ack 1, win 115, options [nop,nop,TS val 254014944 ecr 254020172], length 0
12:01:22.523118 IP xxx.xxx.xxx.47.mysql > xxx.xxx.xxx.4.33747: Flags [P.], seq 1:86, ack 1, win 114, options [nop,nop,TS val 254020181 ecr 254014944], length 85
12:01:22.523209 IP xxx.xxx.xxx.47.mysql > xxx.xxx.xxx.4.33747: Flags [F.], seq 86, ack 1, win 114, options [nop,nop,TS val 254020181 ecr 254014944], length 0
12:01:22.523489 IP xxx.xxx.xxx.4.33747 > xxx.xxx.xxx.47.mysql: Flags [.], ack 86, win 115, options [nop,nop,TS val 254014953 ecr 254020181], length 0
12:01:22.523572 IP xxx.xxx.xxx.4.33747 > xxx.xxx.xxx.47.mysql: Flags [F.], seq 1, ack 87, win 115, options [nop,nop,TS val 254014953 ecr 254020181], length 0
12:01:22.523582 IP xxx.xxx.xxx.47.mysql > xxx.xxx.xxx.4.33747: Flags [.], ack 2, win 114, options [nop,nop,TS val 254020182 ecr 254014953], length 0

Si vous ne voyez aucun paquet tcp arriver, contactez votre équipe infrastructure/réseau afin de faire ouvrir le flux.

Warmup : préparez les caches de votre site

Une commande toute simple pour préparer les caches de votre site avant son ouverture en production :

wget -r -np -p -k [URL]

Détail des options

  • -r : suivre récursivement tous les liens de chaque page
  • -np : empêcher le robot de remonter l’arborescence du site
  • -p : télécharger toutes les ressources de la page (css, images, Javascript…)
  • -k : convertir les liens des pages pour utiliser les ressources locales téléchargées