Dessine moi un cercle

Ce jeudi nous nous sommes retrouvés, comme de coutume, à la tribu pour travailler.

Nous avions fait la proposition via notre meetup d’accueillir des gens extérieurs pour l’après-midi et Nicolas Montens s’est gracieusement prêté au jeu (un grand merci à lui).

L’objectif de cette demi-journée était de poser sur le papier les bases de notre modèle afin de commencer à le faire vivre et pouvoir le communiquer à l’extérieur pour l’enrichir.

Une valeur importante à nos yeux étant la transparence radicale, voici donc les résultats de nos travaux et les prémices de la tribu. Ceci n’est pas parfait, mais au moins ça a le mérite d’exister et d’être une base pour débuter.

N’hésitez pas à commenter et à apporter vos idées, nous sommes totalement ouvert 🙂 dans les commentaires.

Nous avons beaucoup d’idées encore en stock, mais comme tout Agiliste nous avons beaucoup utilisé le principe YAGNI. N’essayons pas de régler des problèmes que nous n’avons pas encore…

Notre modèle

Tout d’abord, pour comprendre le modèle que nous avons dessiné, il est important de repartir des valeurs qui sont au coeur de la tribu (pour plus de détails voir sur le site web) : 

  • Une communauté « ouverte »
  • Transparence radicale
  • Auto-organisé dans la bienveillance
  • Rendre service aux agilités
  • Apprendre et enseigner

AgileTribu-Valeurs

Afin de mettre en pratique ceci nous nous sommes beaucoup inspirés des « cercles » sociocratique. Nous avons défini pour le moment 5 cercles mais l’objectif est que cette organisation soit vivante et dynamique et donc que ces cercles ne soient pas figés.

Chaque cercle pour exister doit définir à minima ces critères :

  • sa raison d’être (pourquoi?)
  • ses conditions d’entrée
  • ses conditions de sortie (si nécessaire)

Nous avons défini que chaque cercle avait à minima comme condition d’entrée le consentement de tous les membres de ce cercle. Nous détaillerons ce point plus tard.

Voici vu d’avion à quoi cela ressemble : 

IMG_4588

Nous allons dans les prochains articles détailler ces premiers cercles, en commençant dès demain par le cercle de base « associés ».

Pimp my gif : création d’un widget avec dashing

Je vous ai brossé dans l’article précédent tout l’intérêt d’un dashboard sur mesure avec Dashing. Aujourd’hui je vous propose de voir comment celui-ci fonctionne à travers la création concrète d’un widget. 

Pour cet exemple je vous propose de créer avec vous un widget permettant d’afficher sur notre dashboard dashing un gif animé, qui sera récupéré en fonction d’un ensemble de mots clés.  Pour cela nous allons utiliser Giphy et son API.

Avant de commencer je vais vous expliquer les concepts clé dans Dashing :

  • nous allons commencé par créer un dashboard, celui-ci déclarera l’ensemble des widgets que nous allons avoir et leur définira un id
  • pour la partie widget nous pouvons soit utiliser les widgets existants soit créer un widget custom.
  • enfin pour envoyer la donnée nous pouvons soit l’envoyer directement via un appel POST en HTTP, soit créer un job en ruby dans dashing.

dashing-architecture

Création du dashboard

Pour commencer vous aurez installé Ruby & Dashing (qui vous demandera certainement également l’installation de NodeJS). 

Puis pour initier notre projet nous allons utiliser la commande : 

Lire la suite

Dashing deux en un : pour un dashboard étincelant !

Bon que ce soit bien clair : je n’aime pas et je n’ai jamais aimé les dashboards électroniques que l’on peut créer via Jira, Redmine, ou peut importe le logiciel de suivi de besoins.
Je trouve déterminant la mise en place d’un management visuel « physique » (c’est-à-dire bien visible, facilement modifiable et partagé par toute l’équipe) pour la bonne marche d’une équipe.
Et puis il y a dashing. Cela lui là je l’aime bien. Il faut que je vous raconte pourquoi…

Découverte et premier dashboard

J’ai découvert Dashing il y a quelques mois grâce à Vincent et Philippe. C’est un outil open source et gratuit créé par une boite américaine Shopify. J’ai regardé l’outil, vu la démo. C’est cool et c’est joli en effet …
bon …
je retourne bosser.

Mais Philippe insiste. Il envisionne la création d’un dashboard électronique qui nous permettrait de voir en un clin d’oeil si tout est ok sur l’équipe ou non. Son idée est d’avoir des widgets qui soient intégralement verts lorsque tout roule et rouges lorsqu’il y a un soucis et qu’il faut prendre une action.
Un peu pour lui faire plaisir et un peu par curiosité je décide de m’y mettre. Je vois qu’il existe de nombreux widgets, certains attirent mon attention comme le widget Jenkins (état de l’intégration continue), ou le widget Rickshaw graph  qui permet de faire de jolies graphiques.
Cependant, je ne trouve pas forcement mon bonheur pour tout et je me rends vite compte qu’il faudra vite faire du custom…

Je me lance en me posant la question « que voulons nous voir ? » (et non pas : « que pouvons-nous voir ? » ) :

  • Certains jobs Jenkins (intégration continue) tombent en échec et nous les laissons parfois rouge quelques jours ce qui nous pose beaucoup de problèmes. 
  • Nous avons un mécanisme de réalimentation d’un référentiel qui se lance trois fois par semaine en soirée et celui-ci crash de temps en temps. L’impact est très mineur, mais au plus l’analyse est faite tardivement au plus celle-ci est compliquée.
  • L’humeur de l’équipe de teammood. Lorsque certaines journées sont mauvaises (deux/trois membres de l’équipe mettent un mauvais mood) ou au contraire très bonnes, nous ne nous en rendons compte que quelques jours après et il est trop tard pour discuter et comprendre ce qu’il s’est passé.
  • Nous avons mis en production un module de floutage automatique des plaques d’immatriculation de voitures et nous nous regardons quasiment quotidiennement ces résultats sur kibana.

Après quelques tâtonnements j’arrive à un premier résultat (note : certaines parties business sont volontairement masquées, désolé 🙂 ) :

Dashing-V1

C’est encourageant. Avec l’équipe nous jugeons que ce premier opus a assez de valeurs et nous installons donc dashing sur un serveur et demandons un écran dédié pour l’afficher en continue sur notre bureau, bien visible par tous.

Lire la suite

Supprimer les comportements négatifs avec le sourire!

Notre problème : quand la revue coince

Lors de la dernière rétrospective, nous avons identifié tous ensemble que le principal point de contention de l’équipe se situe lorsque les développements sont terminés, au moment de faire une revue du code par les pairs, pour que la story puisse ensuite passer en recette.

Nous avons discuté sur le fait d’éviter de bloquer trop longtemps l’auteur de cette pull request (nous utilisons git). En effet si la story n’est pas revue rapidement le cout du switch et du travail parallèle devient très fort. En contrepartie, l’équipe ne peut pas s’arrêter immédiatement pour la valider afin de ne pas casser son flot et dans ce cas-là, elle aussi switcher…

PullRequest-blurred
Un exemple de pull request (certaines sont plus utiles 🙂 )

Lire la suite