Quels outils pour quelle utilisation en télétravail ? Partie 2 : Réfléchir ensemble

Suite de la série concernant les outils à distance.

Si précédemment, nous parlions de la communication que nous appellerons directe, regardons maintenant comment émuler cet outil fantastique qu’est le tableau blanc accompagné de post-its ?

Comment travailler sur un support visuel alors que nous ne sommes pas dans la même salle ?

Une fois encore, séparons nos intentions en deux, que cherchons nous à faire : réaliser une analyse à plusieurs mains ou faire une rétrospective ?

Nous ne présenterons pas ici les tableaux de type Kanban ou Scrum, notamment car ils sont très souvent liés à un outils déjà utilisé par l’équipe (type Jira ou TFS).


 La rétrospective à distance

L’exercice mérite sa propre partie tellement nous avons identifié d’outils disponibles juste pour celui-ci.

Retrium ($)

Le plus connu sûrement, j’ai pu l’utiliser avec une équipe pendant plusieurs mois. Si à l’époque je le trouvais fabuleux : un timer intégré, la possibilité de réellement cacher le contenu de ce qui est écrit en temps réel … J’ai tendance à modérer mon propos car c’est quelque chose que je vois sur quasiment tous les outils de rétro en ligne maintenant.

Il reste une valeur sûre quoiqu’il en soit. 

Metroretro

Petite découverte personnelle. Un excellent site de rétro gratuit. Tout un tas de frameworks sont déjà sélectionnables (pas que des rétros d’ailleurs) qui s’affichent en fond du board et sont donc facilement hackables (un point à la fois positif et négatif, certes).

Son plus gros souci est qu’il ne s’intègre pas (encore ?) avec d’autres systèmes et que l’export de données est très limité (csv ou json très sommaire).

Funretro ($)

Très proche de Metroretro, plusieurs personnes chez Goood l’ont utilisé et m’ont fait suivre un très bon feedback de celui-ci également. Il est payant mais offre tout de même 3 boards gratuits.

Moins graphique mais plus sur des rails que celui mentionné précédemment, il a l’avantage de permettre l’accès en anonyme à un board.


Travailler ensemble sur un même support

La rétrospective, c’est bien, mais nous utilisons un tableau pour plein d’autres exercices. Et si nous avons découvert en expérimentant que l’utilisation d’un tableau blanc en équipe à distance nécessite un effort d’adaptation supplémentaire, nous pouvons déjà présenter les outils qui -pour nous- se sont avérés efficaces.

Miro ($)

Utilisé par plusieurs de nos clients, nous l’avons expérimenté très récemment tous ensemble. Il a fait l’unanimité pendant le workshop. L’immensité de chaque tableau est un peu compliquée au départ (certains peuvent ne pas voir totalement le travail en cours si on n’y fait pas attention). 

Miro utilisé chez Goood

Tout comme Funretro, 3 boards sont disponibles gratuitement.

iObeya ($)

Solution utilisée par plusieurs sociétés, notamment sous SAFe. Les retours sur sa puissance et sa prise en main sont unanimes, le produit est excellent. 

Il semblerait cependant que l’outil serait plus approprié pour des travaux à grande échelle, plutôt que pour des petites équipes en distribué.


Les boards dans les suites intégrées ($)

GApps propose Jamboard et Office 365 a Whiteboard. Je n’ai pas de retour direct sur ces outils malheureusement, si ce n’est que celui par Microsoft nécessite une tablette graphique ou tactile pour être réellement utilisable.

L’avantage est que si votre société a déjà des licences pour ces suites, vous n’avez aucune nouvelle dépense à faire.


Il y a une constellation de logiciels et sites de partage de tableau en ligne, et tant mieux ! Nous ne vous présentons que ceux dont  nous avons pu tester le fonctionnement ou qui nous paraissaient les plus évidents et accessibles (i.e. ceux intégrés de base avec GApps et Office).

Pour autant, l’adoption de ces outils ne doit pas cacher la nécessité d’échanger en temps réel lorsque l’on manipule ces tableaux, que ce soit par téléphone ou en visioconférence, comme déjà évoqué dans la partie 1. Restez en contact permanent pendant ces exercices, ils sont souvent déjà compliqués en présentiel, la déconnexion physique peut être problématique, nous essaierons de revenir sur ces points au plus vite.

Image d’illustration Startup Stock Photos sur Pexels

Quels outils pour quelle utilisation en télétravail ? Partie 1 : Communiquer

Comme vous sûrement, j’ai reçu tout un tas de messages à propos des outils -client lourd ou pas- disponibles pour travailler en mode partagé. Soit on me proposait de nouveaux services soit on me demandait lequel choisir devant le vaste champ de possibilités qui s’ouvre devant nous.

Suivant que vous soyez développeur, coach, manager ou autre, bien évidemment, vos besoins seront différents. Essayons de catégoriser tout ça et reprenons les feedbacks que j’ai pu récolter sur chacun des produits.

Comment continuer à communiquer efficacement en télétravail ?

Comment faire en sorte que chacun soit au courant de l’état d’avancement de l’équipe en temps réel ? Et si la production tombe ?

Un P.O. un peu stressé

Je rajouterai un niveau supplémentaire :

Parle-t-on de réunions / cérémonies ou de suivre globalement le travail de l’équipe ?

Suivant votre réponse, deux possibilités : vous cherchez une solution synchrone (type visioconférence) ou asynchrone (plus axée notifications).


La visioconférence

Zoom ($)

L’option utilisée chez Goood pendant cette période de télétravail forcé. Pour l’instant nous l’utilisons pour notre « machine à café virtuelle » et pour les réunions depuis hier.

Le premier retour que nous en avons est qu’il utilise très peu de bande passante, une ressource rare et précieuse en ces temps.

Une feature que nous n’avons pas encore testée : la création de breakout rooms afin de travailler en sous groupes avant de se retrouver dans la salle commune. Intéressant pour les workshops et formations pour nous.

Whereby ($)

Ou anciennement appear.in. Je l’ai utilisé avec des équipes de développement en mode Scrum pendant plusieurs années.

Un peu plus gourmand en bande passante (mais je ne m’en suis pas resservi depuis plusieurs mois) mais très pratique en web. L’équipe était très bien organisée autour de cet outil suffisamment flexible pour tout le monde.

Jami

Petit outsider, j’ai une certaine sympathie pour les alternatives libres.

Les deux énormes avantages sont sa gratuité complète (GNU oblige) et son mode totalement distribué, fonctionnement totalement en peer-to-peer.

Je n’ai malheureusement pas eu l’opportunité de suffisamment le tester à cause de son problème majeur : aucune société n’a l’air de connaître le produit. Mais si vous avez l’âme d’un libriste et une équipe prête à relever un peu ses manches, je suis preneur d’un feedback !


La communication textuelle et les notifications

Parfois on n’a pas besoin d’être en visio, voire on ne le veut pas. Quelles solutions nous permettent d’échanger et manière centralisée ?

Slack ($)

Difficile de ne pas commencer par lui. Grand favori, c’est aussi lui que nous avons choisi chez Goood. Uniquement en cloud, riche en extensions et capable de s’interfacer avec presque tout. Par contre, si vous voulez profiter au maximum de ses capacités, il est payant.

Teams ($)

On l’oublie parfois. Il est intégré à la suite Office 365. J’ai pu voir des équipes l’utiliser et être parfaitement satisfaites du produit. Un Slack by Microsoft ? Peut-être. Mais si vous avez déjà un abonnement Office, il ne vous coûtera rien de plus.

Mattermost (hébergement $)

Encore une petite solution open source que j’ai pu tester cette fois. J’y ai retrouvé les mêmes fonctionnalités que Slack, juste un tout petit peu moins d’intégration avec des outils externes… Et encore.

Si vous avez les ressources pour l’installer vous-même, le produit ne vous coûtera rien (il existe même des images Docker).


Il existe encore beaucoup de produits de communication. Même Skype personnel, avec son bouton « Meet Now » peut faire l’affaire. J’ai préféré vous communiquer ceux qui sortaient du lot pour des raisons spécifiques (prix, intégration et popularité).

Pour autant, le plus important restera votre équipe : quel outil accepte-elle de prendre ? J’ai vu beaucoup de dev teams refuser Slack ou Mattermost parce qu’elles préféraient uniquement utiliser l’e-mail ou toute forme de visioconférence par peur de se sentir surveillées. Tout cela est compréhensible et doit être pris en compte.

Prenez cette liste pour ce qu’elle est : un retour d’expérience sur l’utilisation d’outil de communication à distance.

Image d’illustration par PhotoMIX Ltd.

Les Shadoks un demi sciècle plus tard

log_shadok

Par inconnu — Scan pochette DVD Les shadoks, édition intégrale, marque déposée, https://fr.wikipedia.org/w/index.php?curid=1330598

Presque 50 ans plus tard, Les Shadoks ont encore beaucoup à nous apprendre.

Google nous le rappelle aujourd’hui, cela fait 48 ans que la série animée culte et absurde a commencé sa diffusion.

Les Shadoks pompaient et pompaient. Ils ne savaient pas pourquoi, mais ils pompaient. Ils en ont déduit un certain nombre de devises.

S’il n’y a pas de solution, c’est qu’il n’y a pas de problème.

Quand on ne sait pas où l’on va, il faut y aller !!! … Et le plus vite possible.

Il vaut mieux pomper et qu’il ne se passe rien que risquer qu’il se passe quelque chose de pire en ne pompant pas.

 

Comme quoi, presque 50 ans plus tard … Les Shadoks pompent toujours.

[Agile France] Retour sur « Comment les jeux vidéo ont fait de moi un meilleur développeur ? »

Suite à l’annonce de la présence de Soft’It et Coactiv à Agile France, la conférence « Comment les jeux vidéo ont fait de moi un meilleur développeur ? » est disponible sur YouTube.

Un grand merci à l’organisation de l’événement et aux personnes présentes pour leur attention, leur soutien et leurs retours.

 

[Agile France] La naissance d’un Ordre des Développeurs ?

odd1

Les 18 et 19 juin derniers s’est déroulée Agile France. Au milieu des conférences, nous avons pu entre autres en suivre deux particulières :

L’Ordre des Développeurs par Jean-Baptiste Dusseaut

Le Réveil du Développeur  par Ly-Jia Goldstein

Leurs points communs ? Chacun a lancé l’idée de cadrer le métier de développeur (d’une manière assez large).

« With great power comes great responsibilities »

Et c’est un peu notre cas. Nous créons les sites, les applications que le reste du monde utilise tous les jours. Nous avons le devoir de bien faire notre travail.

Si la notion d' »Ordre » peut-être intimidante, paraître trop stricte, il est nécessaire de définir des engagements aussi bien du développeur seul (qualité, responsabilité, …) comme de la communauté (conseil, formations, …).

Si vous voulez en savoir un peu plus, vous pouvez rejoindre le GitHub de l’Ordre de Développeur ici : http://github.com/ordre-des-developpeurs

Soft’it et CoActiv présents à Agile France

En plus d’assister aux conférences Agile France, deux collaborateurs CoActiv (Christophe Keromen et Sébastien Delest) et un collaborateur Soft’it (Rémi Lesieur-Bridel) proposent des conférences.

Christophe présentera « Leurs petites pattes agiles », Sébastien « L’estimation : Un formidable outil de discussion, même pour des projets #NoEstimates » et Rémi « Comment les jeux vidéo ont fait de moi un meilleur développeur ».

Un teaser est d’ores et déjà disponible pour cette dernière conférence : 

Agile France aura lieu les 18 et 19 juin 2015 au Chalet de la Porte Jaune, Porte de Versailles à Paris.

Nous espérons vous voir là-bas pour échanger sur les sujets que nous vous proposons !

Windows 10 sera l’ultime version de Windows

Confirmé par Jerry Nixon, Microsoft arrêtera de créer de nouvelles versions de Windows.

Pour autant, le système d’exploitation n’est pas mort. Il passe simplement à un autre mode de livraison. Au lieu de livrer une nouvelle version boîte tous les 2 à 4 ans environ, les utilisateurs recevront régulièrement des mises à jour. Economiquement viable (la majorité des gains vient de la vente de nouveaux PCs). D’après eux, les améliorations ne devraient pas ralentir « ce sera l’inverse,  nous passons à la vitesse supérieure. » Lire la suite

Le chemin vers la qualité est-il unique ? (Part 2 : la Production)

le chemin

Nous avons vu précédemment qu’il n’existait pas de méthodologie parfaite (agile ou non). Que nos besoins en tant qu’unité (équipe, société ou individu) allaient dicter les méthodologies que nous voulons ou pouvons suivre.

A présent, que se passe-t-il lorsque nous produisons ? Comment organiser notre travail effectif afin d’atteindre un niveau de qualité le plus élevé possible ?

Là où les méthodologies peuvent parfois s’arrêter, certaines nous donnent des clés pour améliorer notre code en plus de notre façon de travailler. Et comme le nombre de méthodologies, il est aisé de crouler sous le nombre de « bonnes pratiques » et finalement ne pas savoir par quoi commencer. Voire de s’y perdre et de ne rien faire du tout.

Ici aussi, y a-t-il une bonne méthode à appliquer ?

En plus de notre expérience, deux conférences de Paris Web peuvent nous aiguiller dans cette réflexion.

Tout d’abord, « Code de qualité : ce qu’il faut savoir«  par Julien Wajsberg et Anthony Ricaud et « 100 % de revue de code«  par Agnès Haasser.

 

Quels outils sont utilisés, pourquoi et comment sont-ils intégrés ?

La revue de code est le point commun entre ces deux conférences. Et à raison : cette pratique est initialement la plus […] simple à mettre en place (une chaise suffit !).

La manière classique consiste à faire venir un pair à côté de soi et relire ensemble le code produit à la recherche d’erreurs ou d’oublis techniques comme fonctionnels. Ensuite, de partager sur les améliorations possibles.

Son principal inconvénient reste son coût en temps effectif, tout comme les interruptions que le demandeur réalise auprès de ses collègues.

Chez Soft’it, nous avons pris la décision de ne pas nécessairement impliquer le demandeur dans la revue de code. Le temps est provisionné et c’est à chacun de vérifier ce que les autres ont envoyé. Si besoin, le relecteur fera une remarque directement ou validera simplement le code produit.

Du côté d’Agnès Haasser, les « pull requests » de Git se sont avérés être la meilleure réponse aux besoins de son équipe. Le principe est le même : soumettre son code à la validation des pairs de manière asynchrone. Ce qu’ils ont rajouté est une surcouche de sécurité : préserver la branche master de toute erreur éventuelle. De plus, tous les devs peuvent participer et/ou suivre cette relecture de code, réduisant drastiquement le bus factor.

Une autre pratique pouvant remplacer la revue de code est le pair programming. On place ici aussi 2 développeurs face à une même machine. La revue de code a lieu en même temps que le développement.

Seulement, ce type de mise en place est coûteuse en temps si les développements ne sont faits que de cette manière. Notre choix interne a été de ne l’utiliser que dans trois cas très précis : l’arrivée de nouvelles personnes dans l’équipe, la découverte de nouvelles technologies ou langages et enfin le développement de parties complexes et/ou critiques. Dans le premier cas, le nouvel arrivant participe à la production tout en apprenant. Et nous avons un filet de sécurité en cas de soucis. Ce filet existera également dans le deuxième cas, tout en apportant un recul aux développeurs qui s’émuleront mutuellement. Dans le dernier, l’intérêt est assez évident : deux paires d’yeux valent mieux qu’une. Et si la fonctionnalité est trop complexe, revenir sur le code de quelqu’un peut s’avérer compliqué et finalement faire perdre plus de temps que d’en gagner.

Même si de manière générale le pair programming implique qu’un des développeurs s’occupe du code de production et l’autre des tests, on peut coupler tests et vérification.

 

Le testing, justement. S’il est considéré comme obligatoire chez certains (c’est notre cas chez Soft’it), il ne l’est pas nécessairement d’après messieurs Wajsberg et Ricaud. Ou du moins dès le début.

La décision prise chez Mozilla est de ne pas rendre obligatoire les tests à la création d’une classe. Mais une fois que la première brique est posée, il ne doit plus y avoir de développement sans test.

Pourquoi ce choix ? Parce qu’il est parfois compliqué de définir un premier test concluant lorsque l’on commence à développer une nouvelle fonctionnalité.

Travailler en TDD rendrait évidemment cette règle absurde. Mais cette pratique n’est pas si évidente à mettre en place : certaines architectures, utilisant des ORMs par exemple, rendent l’utilisation de doublures de tests trop lourdes pour être réellement efficaces. On se tournera alors vers des tests d’intégration (qui arrivent plus tard dans le cycle de développement) afin de valider les cas d’utilisation.

Alors quand commencer à tester ?

Lorsque votre architecture le permet. Et elle le pourra toujours très tôt. Lorsqu’il est intéressant de tester également (le faire sur les getters et setters n’a pas d’intérêt en soi). Plus les tests commencent tard, plus il est compliqué de commencer (quel sera le premier test ? Dois-je revenir sur ce qui n’a pas encore été testé ?). 

Leur présence offre un filet de sécurité à l’équipe. Techniquement d’abord : en cas de besoin de refactoring ou de reprise de code par un autre développeur. Ils sécurisent la modification : si on casse quelque chose, on le sait très tôt.
Fonctionnellement, écrire des tests correspondant au cheminement d’un user donnera une meilleure confiance dans le produit terminé. Notamment lors de corrections de bugs. Idéalement, un ou plusieurs tests devront valider la correction, scelleront sa correction et serviront de gardiens face aux régressions.

 

Enfin, l’intégration continue. Le nom du produit varie, mais l’intérêt et l’implémentation restent les mêmes : s’assurer qu’à tout moment, on ne livre pas un produit cassé aux clients.
La solution est modulable : vous pouvez limiter son utilisation à une machine de build, les développeurs sont alors assurés que les fichiers disponibles sur le repository ne sont pas à même de les empêcher de travailler. Exécuter les tests automatiques (unitaires et d’intégration), voire utiliser un analyseur de code (FxCop, NDepend, …) afin de sécuriser les règles de développement. 

Si les pratiques se retrouvent souvent dans les organisations, leurs applications diffèrent parfois très fortement. L’intention est la même : sécuriser les développements et les développeurs. Mais comme dans toute équipe, les besoins et contraintes ne sont jamais les mêmes. Et suivant ces contraintes, chacun doit plier plus ou moins chaque principe ou philosophie. Il se peut que vous arriviez dans une équipe et que certaines de leurs pratiques, notions ou terminologies vous semblent étranges, voire contre-productives. Mais gardez en tête qu’ils ont peut-être des contraintes très fortes qui ne leur permettent pas d’appliquer à la lettre les bonnes pratiques.

Comprenez vos besoins et ceux de l’équipe avant d’amener une réponse toute faite. Prenez en compte leurs peurs, limites et attentes et apportez-leur les pratiques qui leur conviennent.
C’est là le fondement même de l’agilité, utilisez des canevas de solutions plutôt que de vous baser sur celles que vous avez pu connaître avant.

Le chemin vers la qualité est-il unique ? (Part 1 : la Méthodologie)

le chemin 1

Scrum, Crystal Clear, eXtreme Programming (XP) … De plus en plus, nous nous éloignons du cycle en V. Ou en tout cas, nous essayons de le faire.

Pourtant, si l’on se rappelle la conférence « Petite histoire d’une méthodologie agilement établie » donnée à Paris Web, ce n’est pas si vrai que ça. A la question « Combien d’entre vous n’appliquent pas d’agilité dans leur entreprise ?« , un bon nombre de mains se sont levées.

Incidemment, la question qu’on a pu entendre était « Quelle est la vraie bonne méthodologie à appliquer ?« .

Et Alexandre Jakubiak tout comme Julien Oger -tenant la conférence citée plus haut- se sont bien gardés de donner une réponse toute faite. Ils ont même prévenus l’audience qu’ils nous présenteraient « la solution qui leur correspondait le mieux ». Ce qui remet beaucoup de choses en perspectives.

Tout d’abord, ils ont voulu bien évidemment éviter le cycle en V. On comprend très vite ses limites avec la fameuse phrase client : « C’est bien ce que j’ai demandé, ce n’est plus ce que je veux. » (i.e. la lenteur de cette méthodologie fait que les besoins du client vont évoluer avant qu’il ait pu mettre la main sur la solution).
Mais rejeter cette méthodologie en bloc n’est pas nécessairement productif non plus : son approche prédictive (bien que trop orientée projet) a ses vertus.

Opposées, la ou les méthodologies agiles, considérée plus réactive intégrant notamment le client plus tôt au processus de développement. Son principal inconvénient reste le nombre de solutions déjà existantes.

Première chose : éviter à tout prix le Big Bang. Mettre en place Scrum -par exemple- dans son ensemble (outils et pratiques) d’un coup au sein de son équipe est suicidaire. Au mieux, on retournera au cycle en V (plus rassurant car déjà connu) en un sprint. Au pire, l’équipe implosera.

La solution choisie a été d’y aller progressivement. Surtout de préalablement faire un tour de l’existant, regarder ce qui serait le plus simple, qui apporterait le plus… et le plus simplement en interne.
Leur conclusion fut de partir de Crystal Clear puis de piocher dans toutes les méthodologies existantes ce qui leur correspondait et les implémenter au fur et à mesure.

Tout ne fut pas simple de l’aveux même de ces messieurs. La méthodologie parfaite n’est qu’utopie. Il faut, dans la mesure du possible, rester souple et ouvert à l’évolution. De même, chaque équipe, chaque société a des besoins différents.
Cela peut être lié à la taille de l’équipe, des projets, des langages utilisés ou même de l’expérience (on fera passer plus facilement de jeunes développeurs à une nouvelle méthodo que des seniors habitués au bon vieux V).

Chez Soft’it, nous utilisons Scrum en interne, notre Scrum. Nous avons dû adapter certaines règles pour que notre fonctionnement soit plus limpide : il n’y a pas de Scrum Master fixe par exemple, il change à chaque Sprint. Cela permet de responsabiliser chaque personne travaillant sur les projets et en plus de ne pas laisser cette pression toujours sur les épaules d’une même personne.

Nous appliquons également plusieurs pratiques de l’eXtreme Programming (XP) : le « Pair Programming« , par exemple, pour les nouveaux arrivants et sur des phases un peu complexes; ou la revue de code (« Code Review ») après chaque story réalisée.
Nous faisons également du testing et avons une usine logicielle pour l’intégration continue. Cependant, la TDD (« Test Driven Development », également part d’XP) n’est pas une obligation chez nous.

S’arrêter à une méthodologie et l’appliquer « By the book », même le cycle en V, est impossible. Le faire est source de frustration ou de goulot d’étranglement bien plus que de facilités dans un projet.

Savoir écouter les besoins en interne et externe, tirer le meilleur de ses retours d’expérience heureux et surtout malheureux, vous guidera bien plus vers votre méthodologie qu’un livre à appliquer à la lettre.

L’agilité contient un principe fondamental : l’amélioration continue. Pensez à réserver du temps pour prendre du recul sur votre organisation, et à construire ensemble la méthodologie qui vous correspond.