Démarrage imminent du premier évènement de la tribu en ligne !

Vous avez massivement plébiscité le cours : Bien démarrer un produit agile – de la vision au backlog

C’est donc celui-ci que nous démarrons à partir du 1er juin !

A noter que le deuxième cours sur Scrum sera joué à une date ultérieure (nous n’avons pas encore la bande passante pour animer les deux en parallèle !) probablement vers la rentrée.

Rendez-vous donc mercredi prochain pour le démarrage de cette aventure. Si vous n’êtes pas encore inscrit, faites vite, il vous reste une semaine : Site de la tribu online.

 

Nathaniel et Yannick pour la tribu.

Démarrage de la tribu online

La tribu est heureuse de vous proposer son nouveau service de cours en ligne gratuit sur l’agilité : tribu.agiletribu.com

Nous croyons fortement qu’il existe différents types de personnalités et différentes manières d’apprendre. Fort d’une première expérience sur la création de cours en ligne en 2014, nous relançons l’expérience et cette fois nous vous le proposons gratuitement !

Chaque cours aura une durée de 4 semaines durant lesquelles nous vous proposerons du contenu (vidéos, articles, résumés), des exercices ainsi que de nombreuses ressources. La plateforme héberge également un forum de discussion qui vous permettra d’échanger à la fois sur le contenu du cours aussi bien que sur vos expérimentations.

Pour cette première session ouverte nous vous laissons choisir entre deux sujets possibles : 

C’est à vous de choisir le premier sujet que nous démarrerons. En effet, nous commencerons au premier juin le cours ayant reçu le plus d’inscription.

Nous comptons donc sur vous pour vite vous inscrire, vous avez jusqu’au premier juin au plus tard pour faire partie de cette première édition !

at-logo-lego

Agile Game France 2016 à Nailloux

La semaine dernière nous avons eu le plaisir de descendre à Nailloux (compter 30 minutes depuis Toulouse) pour participer à Agile Game France. Récit du voyage :

Pour nous, le voyage a commencé dès jeudi pour assister à la rencontre de la fédération agile. Levé à 4H30, arrivé à 6H00 à Orly, petit coup de stress pour attendre Yannick qui embarque juste avant la fermeture des portes et nous voilà parti pour trois belles journées sous le soleil du Lauragais :

Il est 9h et la fédé semble se languir de notre arrivée 😉 

Nous voici donc finalement réunis pour une super journée d’échange en compagnie de Claude, Alexandre, Romain et Johan. La fédération agile est un regroupement d’experts de l’agilité et l’objectif de cette journée est de passer un moment convivial pour échanger aussi bien sur les activités de chacun que sur des sujets pointus. J’ai eu la chance de me faire coopter par Yannick et Johan et de découvrir leur réunion, chouette !

Nous finissons tranquillement la journée vers 17H, il est temps d’accueillir les premiers arrivés et d’accompagner Claude et Ellène pour une balade autour du lac.

cdxkfcqwoaaaedu

Un bon repas, des premières rencontres passionnantes (merci Stefan pour ce chouette échange) puis au lit pour garder des forces pour la journée du lendemain.

Jeudi démarrage en fanfare

… par un IceBreaker survolté, animé par Aurélie et Axel. On y découvre 6 personnes en train de faire la patrouille de France, une équipe mimer le cycle en V en faisant l’aviron, d’autres faire du basket, du curling, …

Lire la suite

Arbre de noël à la tribu

Samedi dernier nous avons eu le plaisir de fêter notre premier arbre de noël à la tribu. Fidèle à notre idée d’ouverture, nous avons invité également les amis de la tribu et leurs enfants.

Notre objectif : passer un bon moment tous ensemble et permettre aux enfants de jouer à nos jeux que nous  réservons d’habitude aux adultes lors de nos formations.

Nous avons commencé par le fameux marshmallow challenge :

IMG_1264

IMG_1265

 

 

 

 

 

 

 

Nous avons pu valider l’hypothèse que les enfants sont plus doués à ce jeux que la majorité des adultes, ceux-ci ont réussi une première réalisation à 46cm en moins de 5 minutes!

Lire la suite

Dashing : alors ça dépote?

Dernier article pour cette série sur comment faire un dashboard qui déchire avec Dashing. Nous avons préalablement vu pourquoi utiliser dashing, puis nous avons vu comment faire un super widget giphy, aujourd’hui je vous propose de finir avec un widget JIRA.

Tout d’abord, avant d’attaquer la partie technique laissez-moi vous expliquer pourquoi ce widget nous est utile.

Notre équipe est organisée dans une logique Kanban, c’est-à-dire que nous travaillons en flux tiré et nous nous efforçons de limiter l’encours. Afin de gérer notre flux nous utilisons principalement deux outils : le suivi du nombre d’éléments en cours et notre « throughput », c’est-à-dire notre débit. C’est ce deuxième indicateur qui va nous intéresser aujourd’hui.

Après avoir étudié notre débit pendant plusieurs semaines, nous nous sommes rendu compte que nous délivrions environ quinze éléments en quinze jours.

Nous allons donc faire une petite jauge pour dashing pour visualiser en temps réel le nombre d’élément qui sont sortis les quinze derniers jours et ainsi avoir un feedback pour nous prévenir lorsque ce nombre chute (ou pour nous arrêter boire un coup s’il augmente trop 😉 ).

Je pars du principe que vous avez lu l’article précédent et donc que vous avez déjà un embryon de dashboard à minima.

Pour commencer nous allons donc ajouter à notre dashboard (/dashboard/foodash.erb) un nouveau widget de type « meter » :

<li data-row="1" data-col="1" data-sizex="1" data-sizey="1">
      <div data-id="throughtput" data-view="Meter" data-title="Nb tickets DONE (15j)" data-min="0" data-max="30"></div>
    </li>

Nous utilisons pour le moment le widget de base, si vous démarrez votre dashboard vous devriez avoir quelque chose comme ça :

Capture d'écran 2015-12-10 09.34.11

Bien, passons à l’alimentation de notre widget. Nous allons maintenant créer un fichier jira.rb dans le répertoire jobs :

# encoding: utf-8
require 'httparty'

require 'json'

SCHEDULER.every '5m', :first_in => 0 do |job|

nbDays = 15

auth = {:username => "USERNAME", :password => "PASSWORD"}

url_jira = "http://your.jira.com/rest/api/2.0.alpha1/search?jql="

issues_done = getIssues(url_jira, auth, nbDays)

send_event(:throughtput, value: issues_done.length)

end

def getIssues(url_jira, auth, nbDays)

jql = 'project=SEC AND status=Closed AND resolution = Fixed AND type!=Epic AND resolutiondate>startOfDay(-'+nbDays.to_s+")"

url = url_jira+ERB::Util.url_encode(jql)

res = HTTParty.get(url, :basic_auth => auth)

return res["issues"]

end

A noter qu’en fonction de votre version de jira, il faudra que vous modifiez l’appel à l’API, mais ce ne devrait pas être bien compliqué à migrer. J’ai par facilité préféré utiliser une authentification par login/password. Dans l’idéal il faudrait transformer ceci en authentification oauth (si quelqu’un veut proposer une amélioration ce sera avec plaisir). Attention à bien penser à encoder l’url sinon il y a de grande chance pour que l’appel à Jira ne fonctionne pas.

Suite à la création de notre job, notre widget se met à jour automatiquement toutes les cinq minutes :

Capture d'écran 2015-12-10 09.35.23

Maintenant, ce que nous souhaitons faire c’est y apporter un peu de couleur pour faciliter la lecture. Dans l’idéal notre widget sera vert si nous avons fini au moins 12 éléments, jaune jusqu’à 9, puis rouge en deçà (bornes définies avec l’équipe).

Nous ajoutons donc dans notre job une petite méthode pour définir la couleur (méthode bien verbeuse pour en faciliter la lecture cher lecteur) :

def getBackgroundColorByNBIssuesDone(nbIssues)
hotness = "cool"
if nbIssues < 12
hotness = "warm"
if nbIssues < 9
hotness = "hot"
end
end
return hotness
end

Et nous modifions le send event pour envoyer également cette couleur au widget : 

send_event(:throughtput, value: issues_done.length, hotness: getBackgroundColorByNBIssuesDone(issues_done.length))

Pour que la couleur de fond soit modifié nous allons modifier le fichier coffeescript de notre widget meter, widgets/meter/meter.coffee et ajouter cette partie :

onData: (data) ->
node = $(@node)
hotcss = switch
when data.hotness == "cool" then "#00C176"
when data.hotness == "warm" then "#FABE28"
when data.hotness == "hot" then "#FF003C"

$(@node).css("background-color", hotcss)

Ainsi notre widget ressemblera à ça :

Capture d'écran 2015-12-10 09.35.58

Ou sinon :

Capture d'écran 2015-12-10 09.36.36

Capture d'écran 2015-12-10 09.37.06

 

 

 

 

 

 

 

Voilà, notre widget est déjà terminé. Comme vous l’avez-vu, nous avons quelque chose de très précis, facile à lire et ceci pour tout juste une trentaine de ligne de code. De plus, cette jauge colorée pourra être réutilisée pour d’autres indicateurs.

C’est ainsi que se termine cette série d’article Dashing, j’espère que cela vous aura donné envie de vous lancer, vous aussi, dans la création de joli dashboard très utile. Si vous avez besoin d’aide, n’hésitez pas à nous contacter.

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