Le Manifeste du BDD

BDD Manifesto

On voit des manifestes un peu partout ces jours-ci. Étant un passionné de BDD (Behavior-Driven Development), je me disais que cela serait pertinent d’en faire un à ce sujet.

L’objectif, pour moi, est de pouvoir résumer rapidement la technique avec des exemples, et surtout de faire prendre conscience que le BDD n’est pas une histoire d’outils avant tout. En fait, l’outil peut même s’avérer facultatif et arriver dans un deuxième temps.

Bref, afin de comprendre rapidement ce qu’est le BDD, voici mon manifeste :

Combler le fossé de communication entre le domaine d’affaires et le développement
plus que
Développer sans connaitre les objectifs et la vision affaires

L’équipe de développement est responsable de la qualité
plus que
C’est la responsabilité du testeur

Se valider fréquemment à l’aide d’exemples et d’explorations
plus que
Découvrir les bogues plus tard dans le processus de développement

Obtenir une documentation vivante des spécifications de notre système
plus que
Avoir une documentation lourde et coûteuse  à mettre à jour

Avoir des communications efficaces, rapides et avec des perspectives différentes
plus que
Travailler de manière hiérarchique et en silos

Établir des scénarios et des exemples concrets, accessibles et abstraits
plus que
Établir des scripts de tests détaillés et complexes

Automatiser l’exécution des tests fonctionnels
plus que
Réaliser manuellement tous les tests fonctionnels

Qu’en pensez-vous ?

Vos commentaires et critiques sont très appréciés afin d’améliorer ce manifeste.

Vous voulez en savoir davantage ? Il y aura une formation pour le côté fonctionnel et technique « Introduction au BDD » bientôt chez notre partenaire AFI.

Autres manifestes:

Références BDD:

Rétrospective sur la collaboration

Récemment, je devais tenir une rétrospective dont le sujet principal était la collaboration entre trois équipes. On parle régulièrement de la collaboration au sein d’une équipe, mais force est de constater que la collaboration inter-équipes est un sujet qu’on aborde moins souvent.

J’ai donc parcouru internet à la recherche d’idées dans l’espoir que la rétrospective que j’allais tenir porte ses fruits.

Je suis tombé sur un article de blog publié par Renzo Venini sur le site de Scrum Alliance. Dans son article, M. Venini présentait une méthode basée sur des souhaits et des offres pour finalement converger vers des actions. Je vous laisse lire l’article original si vous souhaitez  en savoir un peu plus sur sa technique.

Très intéressé par sa technique, j’ai tenté une approche afin que les équipes identifient leurs souhaits en considérant d’autres axes que ceux qu’ils emploient habituellement.

AtelierCollaboration

En me basant sur le Team Trust Canvas élaboré par Alexey Pikulev, j’ai créé un canvas identifiant les axes de collaboration inter-équipes.

CanvasCollaboration

J’ai détaillé ma version de la technique de rétrospective dans la section outils du site. Je vous invite à consulter la page correspondante par ici.

L’engagement en Kanban vs Scrum

Je lis actuellement l’excellent excellent excellent livre de Daniel Vacanti, Actionable Agile, Metrics for Predictability, que vous pouvez acheter sur Leanpub.com.

J’ai adoré cette citation à propos de l’engagement de la méthode Kanban versus Scrum.

Kanban approach to commitments is very different than, say, Scrum. Scrum commitments are made at the sprint level. At the beginning of a sprint, a team commits to getting some number of stories finished by the end of the sprint. That commitment is based on more upfront estimation and planning.

In a flow-based approach, teams commit at the individual work item level. Once an item is pulled into the process a commitment is made as to when that item should be done. That commitment is based more on measurement and observation rather than planning and estimation.

Ce que j’aime de plus en plus dans la méthode Kanban, c’est l’effort mis pour comprendre son système à l’aide d’observations et de mesures pour le rendre prévisible.

Et voici un exemple d’un engagement selon Vacanti pour un item de travail qui passe dans un système Kanban:

We expect this item to flow all the way through the process and exit in 14 days or less with an 85% probability of success.

Pour ceux et celles qui se demandent comment je fais pour prédire cet engagement en Kanban, je vous réfère à l’ensemble d’outils de Focused Objectives sur GitHub dont le fichier Excel Single Feature Forecaster.xlsx qui nous génère un tableau:

MonteCarloSimulation

Dans le cadre de sa série de formations Signature, Facilité Informatique est fier d’organiser la première formation sur la méthode Kanban à Québec. Les 5 et 6 mai prochains à Québec, Daniel Vacanti, pionnier de la méthode, sera à Québec pour expliquer comment mettre en application cette méthode. Profitez de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle.

Un Scrum Master en position d’autorité: une option à ne pas écarter

J’ai trouvé le dernier billet de Mike Cohn fort intéressant car il adresse un enjeu avec lequel je suis constamment confronté sur le terrain.  Que faire si le Scrum Master est aussi en lien d’autorité avec son équipe ?

common advice in the Scrum community is that a team should never, ever report to their Scrum Master

Le piège le plus souvent cité est la possibilité que l’équipe ne soit pas très transparente envers son manager. De plus, en situation de stress, le manager se sentant imputable des résultats de l’équipe pourrait être tenté par le micromanagement. Ceci étant dit, qu’enseigne-t-on aux gestionnaires Agiles?  Quelle est la principale qualité du manager Agile?

Mener votre organisation comme si vous n’aviez aucune autorité » (Kan Higashi)

Une équipe a-t-elle  avantage à cacher de l’information à son manager?  Comment peut-il aider et soutenir l’équipe s’il n’a pas accès à la bonne information?

With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue

If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it.

Le rôle de Scrum Master aurait-il été créé pour camoufler une dysfonction de notre système de gestion traditionnel?  Est-ce qu’on a « tassé » les gestionnaires dans les transformations Agiles, ou est-ce qu’on les accompagne individuellement dans la transformation de leur style de leadership?  je crois qu’il faut faire la même chose avec les chefs d’équipe et chargés de projet, les aider à ajuster leurs postures pour supporter des équipes auto-organisées, les aider à devenir des leaders 3.0, les aider à devenir des Scrum Masters.

With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world.

And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.

Après tout, ne valorisons-nous pas les individus davantage que le processus (et les descriptions de rôles qui viennent avec) ?

Blog original

When I first started doing Scrum, I was what we’d call today the team’s ScrumMaster and product owner. But we didn’t have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both. I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.

I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP — but I should not have been both at the same time to the same team. (And to be clear, everything I’ll write here is going to apply to any personnel manager, whether that’s a manager, director, vice president or even CEO.)

While I don’t think it’s desirable to have team members also have a reporting relationship to their ScrumMaster, I don’t think it is always horrible. Much depends on the person who is filling both roles. One of the common arguments against a manager as the team’s ScrumMaster is that team members will become reluctant to raise issues. For example, a programmer who is behind on a task will not be willing to say so in the daily scrum if his or her manager is also the ScrumMaster. That’s simply not true. With the right manager in place as ScrumMaster, this programmer should be extremely willing to say he’s behind because he knows that manager-slash-ScrumMaster is going to be doubly incentivized to and capable of resolving that issue. If the right person is doing double duty as both ScrumMaster and a personnel manager, I have no problem with it. If the wrong person is in place, there are lots of problems.

But it’s time to stop defining processes to prevent problems and create workarounds for the troublesome people in the organization. Instead, assume the right people are in place and then work to create a culture that puts the right people in place. With the right person in the dual role of ScrumMaster and manager, it can work well. In an ideal world, I’d love to separate ScrumMastering from personnel management. But I rarely get to live in that ideal world. And this is a compromise that works fine. Rather than banning everyone from being both ScrumMaster and manager, I’d rather allow it. And then only fill the position with the right people.Doing that will help your team succeed with agile.

Mike Cohn

The Tyranny of the timebox

Le titre révèle tout. Dans sa présentation en 2014 intitulée « 10 years of Kanban – What have we learned », David J. Anderson rappelle le concept du « Tyranny of the timebox » proposé à Agile 2009.

KanbanTyrannyTimebox

Plus loin dans sa présentation, Anderson mentionne que la méthode Kanban a passé le chasm en 2012.

KanbanCrossingTheChasm

Pour ceux qui connaissent le livre Crossing the chasm, ce terme veut dire qu’une technologie est passée du stade d’adoption à celui d’être mise en place par la majorité de la population.

Et vous, où êtes-vous par rapport à votre adoption de la méthode Kanban dans vos équipes?

Dans le cadre de ses formations Signature. Facilité Informatique est fier d’organiser la première formation sur la méthode Kanban à Québec. Les 5 et 6 mai prochains à Québec, Daniel Vacanti sera à Québec pour expliquer comment mettre en application cette méthode. Je vous invite chaleureusement à profiter de cette occasion exceptionnelle pour apprendre des meilleurs et ainsi être meilleur à satisfaire votre clientèle.