Cassandra : Les problématiques à traiter lorsqu'on développe une application java

Cassandra fait parti de la famille des bases de données NoSQL. C'est une base de données dont on entend de plus en plus parler dès que l'on est confronté à devoir gérer de gros volumes de données, à être très performant et à vouloir monter en charge facilement.

De part sa conception, Cassandra a été nativement pensé pour être hautement distribué, hautement performant et avec une forte capacité de montée en charge. 

Cassandra est une très belle implémentation du modèle p2p. Tous les noeuds au sein d'un Cluster Cassandra ont le même rôle. Il n'y a pas de notion de maître/esclave...

Bref, Je ne vais pas vous énumérer les avantages à utiliser Cassandra car d'autres l'ont déjà très bien fait avant moi. Vous trouverez sur le wiki de Cassandra un ensemble de liens vers des présentation qui  décriront les concepts clés autour de Cassandra. Juste un dernier mot pour vous dire que Cassandra va bientôt sortir en v1.0.

Une fois votre choix arrêté : "ok, on part sur Cassandra", quelles sont les problématiques auxquels vous allez être confronté lors de sa mise en oeuvre? Je vais tenter d'apporter quelques réponses... C'est parti!

Design de votre modèle de données :

Une des premières choses à faire quand on commence à travailler avec Cassandra, c'est d'oublier tout ce qu'on vous a dit et ce que vous faisiez avec une base de données relationnelle : Le maître mot est dénormalisation.

Cassandra propose un modèle orienté "Column Family" inspiré par BigTable de Google. Je vous conseille dans un premier temps de bien comprendre le modèle de Cassandra (Keyspace, ColumnFamily, Column, SuperColum, Counter) avant de vous lancer. La documentation de DataStax sur le sujet ainsi que l'article sur le wiki sont un bon point départ.

Une fois le modèle de Cassandra compris, il faut axer la réflexion sur la façon dont vous allez requêter vos données. Le système de requêtage de Cassandra est limité (pas de jointures par exemple...). Il faut donc commencer par là pour être sûr de pouvoir faire ce que l'on veut faire.

Installer et paramétrer un cluster Cassandra

La force de Cassandra est de fonctionner avec un grand nombre de noeud dans un cluster. Le plus gros cluster dont j'ai entendu parler (dans cette interview de Jonathan Ellis) serait constitué de 400 noeuds... Juste énorme. Sans aller jusque là, il faut malgré tout rapidement vous familiariser avec le fonctionnement et l'administration d'un cluster Cassandra. Bref, il faut mettre les mains dedans. Je vous conseille cet article, cette video ou encore cette documentation DataStax décrivant la mise en oeuvre rapide d'un cluster cassandra. Cassandra fonctionne aussi en Single Node, cela peut toujours servir en terme de développement mais j'y reviendrai plus tard.

Il vous faut aussi comprendre le fichier de configuration principal de chaque noeud Cassandra : cassandra.yaml. Voici sa documentation.

Si vos serveurs acceptent le packaging Debian, Je vous conseille fortement d'utiliser celui proposé par Cassandra. Il vous permettra très rapidement de l'installer et surtout de le mettre à jour facilement!

Il faut aussi un peu de moyens... Pour pouvoir faire des tests sur votre cluster, il faut un environnement machines permettant de mettre en valeurs les capacités de Cassandra. Cela permet aussi pour vous rassurer avec des tests de performances valables avant d'arriver dans un environnement de production. La virtualisation de plusieurs noeuds sur un ("petit") serveur ne permettra pas de faire des tests de performances concluants.

Administrer et monitorer un cluster Cassandra

Cassandra fournit nativement un ensemble d'outils permettant d'administrer votre cluster :

• cassandra-cli : c'est l'utilitaire en ligne de commande permettant de lire/ecrire dans votre cluster
• nodetool : c'est l'utilisaire en ligne de commande permettant de monitorer et administrer les noeuds du cluster

En plus de ça, DataStax propose une application Web de monitoring et d'administration de votre cluster Cassandra : OpsCenter. C'est vraiment un superbe outil. Il y a une version gratuite pour le développement. J'ai cru comprendre (mais je me trompe peut être) qu'il y aura bientôt aussi une version production gratuite mais qui ne l'est pas pour le moment.

Gérer le "Eventuellement Consistant"

Cassandra propose un modèle "Eventuellement Consistant". Ces mots doivent normalement mettre la puce à l'oreille à n'importe quel développeur et faire un peu peur. 

Pour faire simple, selon le théorème CAP, il n'est pas possible d'avoir à la fois de la consistance (Consistency) , de la disponibilité (Availability) et une résistance au morcellement (Partition tolerance). Il n'est possible que d'en avoir 2 sur 3. Cassandra a choisi de mettre l'accent sur le "A" et le "P" et d'offrir la possibilité de choisir son niveau de consistance. Il est donc possible d'avoir un consistance forte avec Cassandra mais au détriment d'une dégradation du temps de latence (car il faut demander à plus de noeud dans le cluster de se mettre d'accord sur la valeur d'une donnée lors d'une lecture par exemple).

Il y est donc possible de choisir parmi plusieurs niveaux de consistances. Voici une documentation sur le site de DataStax sur le sujet pour vous guider dans votre choix.

Lock

Cassandra ne sait pas faire de Lock. C'est un inconvénient lié à son architecture. Il ne permet donc pas d’empêcher plusieurs clients de lire ou d'écrire un ensemble données portant sur les mêmes clés de votre modèle au même moment. Ce qui peut être fortement gênant, il ne faut pas le nier... Dans ce cas : "la réponse est ailleurs".

Il n'est pas impossible de faire du lock sur vos données mais en utilisant un système externe qui va gérer cela. Zookeeper va vous permettre de faire cela. C'est un système de synchronisation distribué de type sémaphore qui va vous permettre de faire des locks. Zookeeper n’entraîne pas de SPOF car il fonctionne aussi en cluster. Cage est une libraire Java qui s'appuie sur zookeeper et propose un système de lock basé sur des chemins. Voici un article qui vous explique en détail son utilité pour compléter l'utilisation de Cassandra. 

Transaction

Ok, vous faites du lock mais lock ne veut pas dire transaction... Cassandra assure une atomicité des données au niveau d'une même clé (même dans des columnFamily différentes). En revanche, comment faire si vous avez besoin d'une atomicité de données sur plusieurs clés car vos données sont fortement couplés et que vous ne pouvez pas faire autrement.

La réponse est "Just do it (yourself)". Une des approches est de mettre en oeuvre un système de transaction log dans une columnFamily dédiée. Le principe est donc : 

• de logger la transation en sérialisant les données qui ont besoin d'être atomiques (json, xml, ...) et en insérant le résultats de la sérialisation en une fois dans une colonne d'une columFamily.
• effectuer votre traitement en insérant vos données dans votre modèle.
• de marquer ou supprimer la log de la transaction une fois le traitement terminé.

Ce système vous donne alors la possibilité de rejouer la log de la transaction si un souci est survenu pendant votre traitement. Ce système est abordé dans cette présentation (à partir du slide 24).

Comment dialoguer avec Cassandra

Cassandra expose toute son Api cliente via Thrift. L'utilisation native de thrift est déconseillée car c'est plutôt une Api de bas niveau s'adressant à des clients développeur plutôt qu'à des applications clientes.

Il faut donc choisir votre client pour vous adresser à Cassandra : Ils sont listés ici.

En java, il en existe plusieurs. Hector semble clairement le plus utilisé et le plus configurable. C'est celui que j'utilise.

Environnement de développement

Si vous utilisez maven, la plupart des librairies dont vous avez besoin sont mavenisées et disponibles dans les repository centraux (l'exception est Cage qui nécessite de déclarer un repository spécifique).

Vous aimez faire des tests unitaires et du TDD, pas de problèmes, c'est possible et ça se fait même très bien. Il est possible de lancer Cassandra et Zookeeper de façon "embedded" dans votre JVM.

Il est même possible si vous le souhaitez de lancer Cassandra de façon embarquée et d'y charger des données avant d’exécuter vos tests unitaires. Je vous propose d'aller jeter un oeil du côté de cassandra-unit si vous souhaitez faire ça.

Ecosystème en évolution permanente

Que ce soit sur les fonctionnalités de Cassandra, son outillage, son écosystème, il y a beaucoup de changements, d'évolutions et d'améliorations.

De grosses et nouvelles fonctionnalités apparaissent constamment. Par exemple, il y a quelque mois, entre la version 0.7.8 et la 0.8.0, un langage de requêtage le "CQL" est apparu et très prochainement Cassandra sort en version 1.0... Ça va très vite.

Il faut globalement rester en veille sur les blogs, twitter, les mailing list (Cassandra et Hector par exemple) pour voir ce qui se fait, ce qui sort. La communauté autour de Cassandra est grossissante et est très réactive.

Ne pas avoir peur de défaire
Comme les choses changent et évoluent, Il ne faut pas avoir peur de jeter un peu, de modifier souvent, de refactorer beaucoup votre code. C'est dû soit à une évolution de compréhension de Cassandra qui vous fait dire qu'il faut mieux faire autrement, soit à l'apparition d'une nouvelle fonctionnalité soit à un lecture sur un blog...

Il n'y a pas de secret, ma meilleure arme pour gérer ses changements sont : mes tests unitaires et mes tests d'intégrations et ça se passe bien!

Pour aller plus loin

Vous pouvez aller jeter un oeil dans le code source de Cassandra sous svn ici ou sur le miroir sous Git ici.

Vous pouvez aller lire la documentation sur le wiki sur l'architecture interne de Cassandra ici et voir cette vidéo.

Vous pouvez contribuer en commençant ici.

Pour Conclure

Utiliser Cassandra comme backend pour stocker vos données à un réel impact sur votre façon de développer votre application. C'est quelque part assez normal dans le sens si vous utilisez Cassandra, c'est que vous avez normalement beaucoup de données à gérer et qu'il faut de toute façon obligatoirement prendre ça en compte pour développer votre application...

Une fois les efforts produits, quel plaisir de rajouter un noeud dans le cluster pour monter en charge...

En fait, Cassandra, c'est très "DevOps" :-).

CassandraUnit : a Java test framework to develop with Cassandra

Hi everyone,

Let me present you CassandraUnit!

Why?

I work for few months on a new Java application with a Cassandra database backend.

As I'm A TDD Lover, I'd like to developp in a pure TDD Style combined with continuous integration system like Jenkins.

The difficulty when using a database backend is how to write isolated unit Test. One of solutions is to :

• first : embed an instance of your database in your unit test.
• next : load data into your database to setup your unit test.
• finally : execute your test with your data.

In a Relational database world, there is some tools to help you like DBUnit. As Cassandra is a relatively young product (but so beautiful :-)), I didn't find some tools to help me doing what I want.

CassandraUnit is born.

What does it do?

CassandraUnit, for now, does :

• embed and start a Cassandra instance in your code if you want.
• load data from a dataset (xml).

A very little example?

• create an xml dataset like that "simpleDataSet.xml" :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<keyspace xmlns="http://xml.dataset.cassandraunit.org">
    <name>beautifulKeyspaceName</name>
    <columnFamilies>
        <columnFamily>
            <name>beautifulColumnFamilyName</name>
            <row>
                <key>key10</key>
                <column>
                    <name>name11</name>
                    <value>value11</value>
                </column>
                <column>
                    <name>name12</name>
                    <value>value12</value>
                </column>
            </row>
            <row>
                <key>key20</key>
                <column>
                    <name>name21</name>
                    <value>value21</value>
                </column>
            </row>
        </columnFamily>
    </columnFamilies>
</keyspace>

• create a JUnit test case witch extends AbstractCassandraUnit4TestCase :

package org.cassandraunit;

import static org.hamcrest.Matchers.is;
import static org.hamcrest.Matchers.notNullValue;
import static org.junit.Assert.assertThat;

import org.cassandraunit.dataset.IDataSet;
import org.cassandraunit.dataset.xml.ClassPathXmlDataSet;
import org.junit.Test;

public class AutomaticallyStartAndLoadSimpleDataSetTest extends AbstractCassandraUnit4TestCase {

    @Override
    public IDataSet getDataSet() {
        return new ClassPathXmlDataSet("simpleDataSet.xml");
    }

    @Test
    public void shouldHaveLoadASimpleDataSet() throws Exception {
        assertThat(getKeyspace(), notNullValue());
        assertThat(getKeyspace().getKeyspaceName(), is("beautifulKeyspaceName"));
    }

}

And now?

It was just a very little example. CassandraUnit allows to make more complex dataSet (Super column, type definition, ...).

I've just published it on github. It is published under LGPL v3.0 license.

The first release will be available on maven central repository in the coming hours.

As it's the first release, It probably still missing a lot of functionnality but it was time for me to published it.

You want to go further?

and it's normal :-)

Here you can find more informations :

• the github repository and doc (not a lot but a lot of tests)  of the framework : https://github.com/jsevellec/cassandra-unit
• the github repository of examples is available here : https://github.com/jsevellec/cassandra-unit-examples

You can follow it on twitter @cassandraunit

I hope it will help you as it helps me every day on my project.

Il est beau mon scrum board

Le scrum board est un élément central au niveau d'un projet agile. Il est déjà fort utile sur des projets dit "non agile". Dans un contexte agile, c'est tout simplement INDISPENSABLE. Cela ne sert à rien d'en dire plus à ce sujet!

J'ai déjà pu lire des débats sur la forme qu'il doit prendre surtout dans des contextes un peu complexe d'équipes distribuées où il peut devenir numérique. Dans mon cas, sur un projet avec une équipe centralisée, on est resté très KISS : un simple tableau blanc aimanté de 2m * 1m est impeccable.

Scrum Wall

Vous parler seulement de notre Scrum board est trop réducteur. Il faut que je vous parle de notre "Scrum Wall". Un tableau blanc est un peu juste pour tout ce dont nous avions besoin. Comme nous avions de la place, nous ne nous sommes pas privé.

Voici donc notre Scrum Wall :

La photo est prise après la fin du projet, le partie tableau blanc est un peu vide :-).

Il est constitué (en partant du porte manteau, de gauche à droite) :

• d'un A4 de rappel sur le daily Scrum :

Cette feuille n'était pas là au début, je l'ai rajoutée en cours de projet. Avec l'habitude du projet, nous oubliions parfois les fondamentaux. Ca fait toujours du bien de les avoir sous les yeux pendant notre Daily Scrum :-), même de dire que "je n'ai pas rencontré de problème particulier".

• La partie gauche du tableau blanc : 

La partie gauche du tableau blanc est purement réservée au sprint. Dans cette partie se trouvent 4 colonnes : 

- To do

- In progress

- QA

- Done. 

J'ai dû rajouter une feuille en dessous car je n'arrivais pas à tout faire tenir sur une colonne pour un sprint. Haaa... ces équipes hyperproductives, je vous jure :-). La dernière colonne de cette partie hébergeait un ensemble de zones qui ont évoluées au cours du temps. Nous avons commencé avec :

- identification du sprint (numero et contenu)

- technique (problèmes)

- organisationnel (problèmes)

- RE7 (remontées d'infos suite à la recette)

Pour au final terminer avec : 

- identification du sprint (numero et contenu)

- corbeille (permet de faire le ménage quand la colonne "Done" devient trop remplie sans pour autant enlever les tâches du sprint en cours du Scrum Board).

- Actions après rétro (actions à effectuer sur le sprint par rapport à la rétro précédente).

- Problèmes (tous)

- Stockage des aimants : il faut bien les mettre quelque part. Au lieu de les retrouver dans la zone des problèmes organisationnel par exemple...

La partie droite du tableau blanc : 

C'est l'espace "temporaire", il sert un peu à ce qu'on veut. Comme vous pouvez le voir, comme la photo a été prise après la fin du projet, l'emplacement est déjà "squatté" pour un autre projet. Cette espace permettait de réfléchir ensemble, d'expliquer, de schématiser, d'y mettre les horaires de la prochaine démo et de la prochaine rétro.

• La partie droite du mur : 

C'est le "A3 du projet". L'objectif est de proposer une vue synthétique du projet (la vision, les enjeux, la méthodologie, l'architecture globale, un mot sur Scrum, ...).

• Et il manque??? Le burndown du Sprint que nous mettions entre le tableau blanc et le A3 du projet mais qui n'est plus là au moment des photos que j'ai prises.

• Et en bonus, au dessus du tableau blanc, nous y avons mis des goodies que nous avions sur le projet, les cartes postales envoyées par les membres de l'équipe en congés,...

Beau et "clean"

Que vient donc faire la notion du "beau" dans un projet Scrum? 

Le principe d'affichage est à double tranchant. Il offre d'une part une transparence sur le projet et d'autre part justement, on ne peut rien cacher. Les apparences sont trompeuses mais elles ne laissent pas forcément une bonne impression :

Vous y croyez vous si la personne qui possède cette chambre est bibliothécaire? C'est possible mais c'est dur à croire avec cette seule vision:-) 

• Vue de l'équipe : Le Scrum board est le seul outil qui permet aux membres de l'équipe de travailler ensemble de façon efficace sans se marcher dessus. De plus, c'est aussi cette même équipe qui s'en sert quotidiennement. le désordre attire le désordre et inversement!

• Vue de l'extérieur, Scrum souffre parfois de son image. Les clichés ont parfois la vie dure :

-Le framework Scrum est parfois vue comme une méthode de gestion de projet exotique mais qui n'est pas applicable. On en arrive même à préférer ne pas dire qu'on fait du Scrum...
- "C'est quoi cette bande de rigolos qui joue avec des pos-its."
- "Et en plus ils font un poker au boulot"

- "Cela manque de rigueur"

- On a parfois du mal à comprendre que le fun peut faire partie du boulot.

Si on associe à cela un Scrum Wall qui n'est pas "clean", on a dû mal à projeter un image de qualité logiciel sur ce qu'on livre...

Il faut donc que le Scrum Wall soit beau!

CQFD

Des astuces

• Un "A3 projet" de qualité : Sa réalisation est un exercice délicat qui nécessite de prendre du recul et du temps mais il est la carte de visite de votre projet vu de l'extérieur. Il facilite aussi l'intégration d'un membre dans l'équipe ainsi que la présentation du projet.
• De la couleur : N'hésitez pas utiliser des couleurs différentes pour vos post-its d'un sprint à l'autre. En revanche, sur un sprint, essayez de vous y tenir.
• Des couleurs et des tailles différentes :  Utilisez des post-its de tailles et de couleurs différents permet d'identifier rapidement des fonctions différentes. Nous utilisons par exemple des pos-its carré (76mm*76mm) pour décrire une User Story et des petits post-its rectangulaire (38mm*51mm) d'une autre couleur pour les tâches.
• Utilisez un stylo feutre pour écrire. Ca augmente la lisibilité.

Une petite illustration : 

en haut : BAD / en bas : GOOD

• Eviter d'avoir le post-it qui rebique : http://www.bouzin-agile.fr/?post/2010/10/15/Evitez-d-avoir-le-post-it-qui-rebique
• Notez vos initiales sur les tâches en cours (ou un autre moyen d'identifier une personne sur une tâche en cours).
• Faites le ménage régulièrement sur le Scrum Board: Est-ce que ce schéma est encore utile, est-ce que le problème est toujours d'actualité, ...

Voici quelques illustrations de notre projet :

• Un début de sprint (d'une semaine) :

• Un sprint en cours (de 15jours, nous avons fait évoluer la durée de nos sprints) :

(Nous remontions la colonne de gauche au fur et à mesure des Users Storys terminées en haut).


Sur ce, bonne année à tous!

Intégration continue : "have fun" :-)

Je trouve que l'intégration continue est une pratique incontournable sur un projet de développement. Comme je l'avais déjà expliquée ici, la mise en place d'une démarche d'intégration continue peut ne pas prendre au niveau d'un projet de développement. Ce n'a pas été le cas sur le dernier projet auquel j'ai participé:

Un défi technique : tout doit être buildé

La mise en place d'une démarche d'intégration continue est d'abord un défi technique (en tous cas, ça peut l'être). Dans le cadre du projet dont je vous parle, nous avons un ensemble de plateformes de développements ayant des processus de builds différents (exemple : application jEE, application Iphone, application Android).

Le premier défi est donc de réussir à faire fonctionner le système d'intégration continue sur des plateformes hétérogènes. Le but est d'éviter que des membres de l'équipe plus ou moins spécialisés sur une ou deux plateformes et que celles-ci ne soient pas testées par l'intégration continue, seraient "à l'abri".

Notre serveur d'intégration continue est Hudson et notre gestionnaire de sources est Subversion. Un couple qui fonctionne bien.

Nous n'avons pas de soucis pour mettre en place l'intégration continue sur les applications jEE car nous utilisons maven pour les builder.

En ce qui concerne la plateforme Android, nous utilisons maven pour builder et signer l'application. L'intégration dans Hudson n'a pas posé de problème.

Le build Iphone est celui qui a été le plus complexe par rapport aux autres à mettre en place. Au final, avec un slave Hudson sur un de nos IMac et google comme ami pour trouver ça, ça s'est malgré tout fait assez rapidement.

Une fois de plus l'important est que tout soit buildé. Pour être transparent, on peut noter malgré tout des deltas sur le contenu des builds selon les plateformes. Par exemple, sur la plateforme Iphone, seul une compilation est effectuée alors que sur les applications jEE, il y a compilation, exécution des tests unitaires, execution des tests d'intégrations et déploiement.

Hudson notifie tous les membres de l'équipe par mail sur un build failed ou fixed.

 Un défi organisationnel : elle doit être adoptée par toute l'équipe

L'intégration continue c'est aussi et surtout une démarche et un fonctionnement d'équipe!

Comme je l'ai déjà dit, il ne sert à rien d'avoir une superbe plateforme d'intégration continue si un build cassé n'entraîne pas une mobilisation de l'équipe pour résoudre le problème. Même si normalement l'intégration continue est un outil pour aider l'équipe, il est parfois vu comme un outil "gênant".

Pour motiver l'équipe, il faut ajouter du fun :-). Le fun sur notre projet, pour simplifier, c'est d'être un peu ridicule le temps de corriger un build cassé. Voici notre règle : si tu casses l'intégration continue, c'est toi qui porte le chapeau jusqu'à ce que le build soit réparé. Et quand on dit porter le chapeau, c'est au sens propre et il y a même le choix :

Personne n'y a échappé sur le projet. Comme vous allez pouvoir le constater, il y a des têtes à chapeau ou pas.... On retiendra le "ou pas" dans l'équipe... :-). Juste pour repositionner le contexte, nous évoluions à cette époque sur un open space de 30 à 40 personnes qui n'étaient pas concernées par ce projet...

Au passage, merci à tous les membres de l'équipe d'avoir accepté que je publie les photos.

Je vous laisse découvrir ce que cela peut donner  : 

Bon ok, je commence par moi :

Une version sobre, discrete, ça passe presque inaperçu : 

Une version plus "je vous jure que c'est pas moi" :

Une version "pair programming", assez rare à obtenir :

version "total style" : 

version "j'assume" et en plus en vidéo :

version "faire abstraction, je suis au téléphone avec le client" : 

version "represent" : 

Au delà de ça, on va vu des comportements très intéressants émerger au niveau du projet :

• Le temps de découverte du build cassé était très court : C'était en général un des membres de l'équipe qui venait gentiment déposer le chapeau sur la tête de la personne qui a cassé le build (le dernier commiteur). On devait être, la plupart du temps, en dessous des 30 secondes après que la notification par mail du "build failed".
• Des temps de résolution de build cassé assez court aussi. De l'ordre de 15 minutes. C'est qu'en plus, ils grattent et ils tiennent chaud ces chapeaux :-)
• Le fun, c'est contagieux : Il se trouve que le projet voisin du notre sur l'open space faisait aussi de l'intégration continue, le principe du ridicule a été réutilisé, je dirais même amélioré... Je vous laisse juger par vous même : 

Je crois qu'au final je préfère nos chapeaux :-).

Tout ça pour dire

que l'intégration continue n'a pas été vécue comme une contrainte au niveau de l'équipe. Bien au contraire : 

• c'était un moyen d'améliorer la qualité sur le projet (notamment la qualité des commits)
• c'était un moyen d'avoir du fun sur le projet et le fameux "team spirit".

Scrum Box : la caisse à outil d'un projet Scrum

Avez-vous déjà remarqué la rapidité avec laquelle vos pos-its, vos stylos et autres fournitures disparaissent sur votre bureau. C'est d'autant plus gênant sur un projet utilisant Scrum car justement assez gourmand en fournitures.

Pour éviter ça, j'ai créé sur notre projet la "Scrum Box" :

C'est quoi donc "une Scrum box"? : 
On peut la voir comme la caisse à outil Scrum de notre projet.

Qu'est-ce qu'elle contient : 

• Un assortiment de bloc de post-it carré 76mm*76mm. "les standards"
• Un assortiment de bloc de pos-it rectangulaire 38mm*51mm. "les petits"
• Un assortiment de marqueur pour tableau blanc.
• Un assortiment de marqueur pour paper board.
• Un ou deux stylos feutre.
• Une dizaine de stylos à bille.
• Un jeu de carte de Planning Poker.
• l'adaptateur vga de mon mbp pour le video projecteur.

Elle doit être identifiée en tant que telle et porter le nom du projet!

Qui s'en sert?

L'équipe et uniquement l'équipe! Il peut y avoir des dérogations si c'est demandé gentiment :-)

Quand s'en sert-on?
Au quotidien, tous les membres de l'équipe viennent y piocher des post-its, prendre des stylos, et choses assez cool : les remettre une fois utilisé.

Et plus particulièrement lors des rituels de début de de fin de sprints : Nous effectuons le sprint planning, la démo et la rétro dans une salle un étage en dessous de celui où nous travaillons. Dans cette box, j'ai quasiment tous ce qu'il me faut pour mener ces rituels.

Est-ce vraiment utile?
Oui! C'est une évidence sur notre projet. On n'y prette même plus attention.
On peut se poser la question de savoir si ça permet de ne pas se faire piquer les fournitures par d'autres collègue sur d'autres projets, hé bien oui ça marche et pourtant la box est en libre service et juste en carton.

Avec elle, impossible d'avoir oublié son stylo lors d'un sprint planning!

Cela me permet d'avoir un stock intermédiaire et dédié au projet de fournitures. Elle permet d'être "toujours prêt". Il y a déjà pas mal de chose à préparer et à transporter lors d'un rituel de début ou de fin de sprint (entre le portable, son chargeur,  le video projecteur, des éléments pour faire la démo, ...), la box simplifie le transport de toutes les fournitures :-).

En tant que ScrumMaster sur le projet, ca a été un réel obstacle en moins pour moi ou pour les autres membres de l'équipe. Evidemment, il faut relativiser, il y a d'autres obstacles plus importants et plus compliqués à enlever sur un projet :-).