Blog entries

  • Mini-DebConf Paris 2012

    2012/11/29 by Julien Cristau

    Last week-end, I attended the mini-DebConf organized at EPITA (near Paris) by the French Debian association and sponsored by Logilab.

    http://www.logilab.org/file/112649?vid=download

    The event was a great success, with a rather large number of attendees, including people coming from abroad such as Debian kernel maintainers Ben Hutchings and Maximilian Attems, who talked about their work with Linux.

    Among the other speakers were Loïc Dachary about OpenStack and its packaging in Debian, and Josselin Mouette about his work deploying Debian/GNOME desktops in a large enterprise environment at EDF R&D.

    On my part I gave a talk on Saturday about Debian's release team, and the current state of the wheezy (to-be Debian 7.0) release.

    On Sunday I presented together with Vladimir Daric the work we did to migrate a computation cluster from Red Hat to Debian. Attendees had quite a few questions about our use of ZFS on Linux for storage, and salt for configuration management and deployment.

    Slides for the talks are available on the mini-DebConf web page (wheezy state, migration to debian cluster also viewable on slideshare), and videos will soon be on http://video.debian.net/.

    Now looking forward to next summer's DebConf13 in Switzerland, and hopefully next year's edition of the Paris event.


  • We hosted the Salt Sprint in Paris

    2013/07/30 by Arthur Lutz

    Last Friday, we hosted the French event for the international Great Salt Sprint. Here is a report on what was done and discussed on this occasion.

    http://www.logilab.org/file/228931/raw/saltstack_logo.jpg

    We started off by discussing various points that were of interest to the participants :

    • automatically write documentation from salt sls files (for Sphinx)
    • salt-mine add security layer with restricted access (bug #5467 and #6437)
    • test compatibility of salt-cloud with openstack
    • module bridge bug correction : traceback on KeyError
    • setting up the network in debian (equivalent of rh_ip)
    • configure existing monitoring solution through salt (add machines, add checks, etc) on various backends with a common syntax

    We then split up into pairs to tackle issues in small groups, with some general discussions from time to time.

    6 people participated, 5 from Logilab, 1 from nbs-system. We were expecting more participants but some couldn't make it at the last minute, or though the sprint was taking place at some other time.

    Unfortunately we had a major electricity black out all afternoon, some of us switched to battery and 3G tethering to carry on, but that couldn't last all afternoon. We ended up talking about design and use cases. ERDF (French electricity distribution company) ended up bringing generator trucks for the neighborhood !

    Arthur & Benoit : monitoring adding machines or checks

    http://www.logilab.org/file/157971/raw/salt-centreon-shinken.png

    Some unfinished draft code for supervision backends was written and pushed on github. We explored how a common "interface" could be done in salt (using a combination of states and __virtual___). The official documentation was often very useful, reading code was also always a good resource (and the code is really readable).

    While we were fixing stuff because of the power black out, Benoit submitted a bug fix.

    David & Alain : generate documentation from salt state & salt master

    The idea is to couple the SLS description and the current state of the salt master to generate documentation about one's infrastructure using Sphinx. This was transmitted to the mailing-list.

    http://www.logilab.org/file/157976/raw/salt-sphinx.png

    Design was done around which information should be extracted and display and how to configure access control to the salt-master, taking a further look to external_auth and salt-api will probably be the way forward.

    General discussions

    We had general discussions around concepts of access control to a salt master, on how to define this access. One of the things we believe to be missing (but haven't checked thoroughly) is the ability to separate the "read-only" operations to the "read-write" operations in states and modules, if this was done (through decorators?) we could easily tell salt-api to only give access to data collection. Complex scenarios of access were discussed. Having a configuration or external_auth based on ssh public keys (similar to mercurial-server would be nice, and would provide a "limited" shell to a mercurial server.

    Conclusion

    The power black out didn't help us get things done, but nevertheless, some sharing was done around our uses cases around SaltStack and features that we'd want to get out of it (or from third party applications). We hope to convert all the discussions into bug reports or further discussion on the mailing-lists and (obviously) into code and pull-requests. Check out the scoreboard for an overview of how the other cities contributed.

    to comment this post you need to login or create an account


  • SaltStack Paris Meetup - some of what was said

    2013/10/09 by Arthur Lutz

    Last week, on the first day of OpenWorldForum 2013, we met up with Thomas Hatch of SaltStack to have a talk about salt. He was in Paris to give two talks the following day (1 & 2), and it was a great opportunity to meet him and physically meet part of the French Salt community. Since Logilab hosted the Great Salt Sprint in Paris, we offered to co-organise the meetup at OpenWorldForum.

    http://saltstack.com/images/SaltStack-Logo.png http://openworldforum.org/static/pictures/Calque1.png

    Introduction

    About 15 people gathered in Montrouge (near Paris) and we all took turns to present ourselves and how or why we used salt. Some people wanted to migrate from BCFG2 to salt. Some people told the story of working a month with CFEngine and meeting the same functionnality in two days with salt and so decided to go for that instead. Some like salt because they can hack its python code. Some use salt to provision pre-defined AMI images for the clouds (salt-ami-cloud-builder). Some chose salt over Ansible. Some want to use salt to pilot temporary computation clusters in the cloud (sort of like what StarCluster does with boto and ssh).

    When Paul from Logilab introduced salt-ami-cloud-builder, Thomas Hatch said that some work is being done to go all the way : build an image from scratch from a state definition. On the question of Debian packaging, some efforts could be done to have salt into wheezy-backports. Julien Cristau from Logilab who is a debian developer might help with that.

    Some untold stories where shared : some companies that replaced puppet by salt, some companies use salt to control an HPC cluster, some companies use salt to pilot their existing puppet system.

    We had some discussions around salt-cloud, which will probably be merged into salt at some point. One idea for salt-cloud was raised : have a way of defining a "minimum" type of configuration which translates into the profiles according to which provider is used (an issue should be added shortly). The expression "pushing states" was often used, it is probably a good way of looking a the combination of using salt-cloud and the masterless mode available with salt-ssh. salt-cloud controls an existing cloud, but Thomas Hatch points to the fact that with salt-virt, salt is becoming a cloud controller itself, more on that soon.

    Mixing pillar definition between 'public' and 'private' definitions can be tricky. Some solutions exist with multiple gitfs (or mercurial) external pillar definitions, but more use cases will drive more flexible functionalities in the future.

    Presentation and live demo

    For those in the audience that were not (yet) users of salt, Thomas went back to explaining a few basics about it. Salt should be seen as a "toolkit to solve problems in a infrastructure" says Thomas Hatch. Why is it fast ? It is completely asynchronous and event driven.

    He gave a quick presentation about the new salt-ssh which was introduced in 0.17, which allows the application of salt recipes to machines that don't have a minion connected to the master.

    The peer communication can be used so as to add a condition for a state on the presence of service on a different minion.

    While doing demos or even hacking on salt, one can use salt/test/minionswarm.py which makes fake minions, not everyone has hundreds of servers in at their fingertips.

    Smart modules are loaded dynamically, for example, the git module that gets loaded if a state installs git and then in the same highstate uses the git modules.

    Thomas explained the difference between grains and pillars : grains is data about a minion that lives on the minion, pillar is data about the minion that lives on the master. When handling grains, the grains.setval can be useful (it writes in /etc/salt/grains as yaml, so you can edit it separately). If a minion is not reachable one can obtain its grains information by replacing test=True by cache=True.

    Thomas shortly presented saltstack-formulas : people want to "program" their states, and formulas answer this need, some of the jinja2 is overly complicated to make them flexible and programmable.

    While talking about the unified package commands (a salt command often has various backends according to what system runs the minion), for example salt-call --local pkg.install vim, Thomas told this funny story : ironically, salt was nominated for "best package manager" at some linux magazine competition. (so you don't have to learn how to use FreeBSD packaging tools).

    While hacking salt, one can take a look at the Event Bus (see test/eventlisten.py), many applications are possible when using the data on this bus. Thomas talks about a future IOflow python module where a complex logic can be implemented in the reactor with rules and a state machine. One example use of this would be if the load is high on X number of servers and the number of connexions Y on these servers then launch extra machines.

    To finish on a buzzword, someone asked "what is the overlap of salt and docker" ? The answer is not simple, but Thomas thinks that in the long run there will be a lot of overlap, one can check out the existing lxc modules and states.

    Wrap up

    To wrap up, Thomas announced a salt conference planned for January 2014 in Salt Lake City.

    Logilab proposes to bootstrap the French community around salt. As the group suggest this could take the form of a mailing list, an irc channel, a meetup group , some sprints, or a combination of all the above. On that note, next international sprint will probably take place in January 2014 around the salt conference.


  • SaltStack Paris Meetup on Feb 6th, 2014 - (S01E02)

    2013/12/20 by Nicolas Chauvat

    Logilab has set up the second meetup for salt users in Paris on Feb 6th, 2014 at IRILL, near Place d'Italie, starting at 18:00. The address is 23 avenue d'Italie, 75013 Paris.

    Here is the announce in french http://www.logilab.fr/blogentry/1981

    Please forward it to whom may be interested, underlining that pizzas will be offered to refuel the chatters ;)

    Conveniently placed a week after the Salt Conference, topics will include anything related to salt and its uses, demos, new ideas, exchange of salt formulas, commenting the talks/videos of the saltconf, etc.

    If you are interested in Salt, Python and Devops and will be in Paris at that time, we hope to see you there !


  • Retour sur MiniDebConf Paris 2014

    2014/03/05 by Arthur Lutz
    http://www.logilab.org/file/226609/raw/200px-Mini-debconf-paris.png

    Nous sommes heureux d'avoir participé à la MiniDebConf Paris.

    Nous avons sponsorisé l'évenement mais aussi effectué deux présentations :

    • Julien Cristau a présenté l'équipe dont il fait partie pour la prochaine release de debian : Jessie. Il a notamment donné des conseils à la communauté sur la préparation de jessie. Voici ces diapos : Release team: Jessie.
    • David Douard a présenté Salt to administrate Debian systems, introduisant Salt avec un focus particulier sur ce que Salt peut apporter à de l'administration d'un parc de machines sous Debian.

    Avec une cinquantaine de participants sur les deux jours, c'est toujours agréable de rencontrer la communauté francaise autour de Debian. Merci donc à l'association Debian France d'avoir organisé cette conférence.


  • Compte rendu présentation Salt à Solution Linux

    2014/05/21 by Arthur Lutz

    Logilab était à l'édition 2014 de Solutions Linux qui se déroulait au CNIT à Paris. David Douard participait à la table ronde sur les outils libres pour la supervision lors de la session Administration Système, Devops, au cours de laquelle un certain nombre de projets libres ont été mentionnés : nagios, shinken, graphite, ElasticSearch, logstash, munin, saltstack, kibana, centreon, rsyslog.

    http://www.logilab.org/file/248048/raw/solutionlinux.png

    Suite à des présentations sur OpenLDAP, LXC, btrfs et ElasticSearch David Douard a présenté notre approche agile de l'administration système articulée autour de Salt et en particulier le principe de l'administration système pilotée par les tests (diapos) (Test-Driven Infrastructure).

    https://www.logilab.org/file/248098/raw/Screenshot%20from%202014-05-21%2017%3A55%3A35.png

    Merci aux organisateurs de Solutions Linux pour cette édition 2014.


  • SaltStack Meetup with Thomas Hatch in Paris France

    2014/05/22 by Arthur Lutz

    This monday (19th of may 2014), Thomas Hatch was in Paris for dotScale 2014. After presenting SaltStack there (videos will be published at some point), he spent the evening with members of the French SaltStack community during a meetup set up by Logilab at IRILL.

    http://www.logilab.org/file/248338/raw/thomas-hatch.png

    Here is a list of what we talked about :

    • Since Salt seems to have pushed ZMQ to its limits, SaltStack has been working on RAET (Reliable Asynchronous Event Transport Protocol ), a transport layer based on UDP and elliptic curve cryptography (Dan Berstein's CURVE-255-19) that works more like a stack than a socket and has reliability built in. RAET will be released as an optionnal beta feature in the next Salt release.
    • Folks from Dailymotion bumped into a bug that seems related to high latency networks and the auth_timeout. Updating to the very latest release should fix the issue.
    • Thomas told us about how a dedicated team at SaltStack handles pull requests and another team works on triaging github issues to input them into their internal SCRUM process. There are a lot of duplicate issues and old inactive issues that need attention and clutter the issue tracker. Help will be welcome.
    http://www.logilab.org/file/248336/raw/Salt-Logo.png
    • Continuous integration is based on Jenkins and spins up VMs to test pull request. There is work in progress to test multiple clouds, various latencies and loads.
    • For the Docker integration, salt now keeps track of forwarded ports and relevant information about the containers.
    • salt-virt bumped into problems with chroots and timeouts due to ZMQ.
    • Multi-master: the problem lies with syncronisation of data which is sent to minions but also the data that is sent to the masters. Possible solutions to be explored are : the use of gitfs, there is no built-in solution for keys (salt-key has to be run on all masters), mine.send should send the data at both masters, for the jobs cache: one could use an external returner.
    • Thomas talked briefly about ioflo which should bring queuing, data hierarchy and data pub-sub to Salt.
    http://www.logilab.org/file/248335/raw/ioflo.png
    • About the rolling release question: versions in Salt are definitely not git snapshots, things get backported into previous versions. No clear definition yet of length of LTS versions.
    • salt-cloud and libcloud : in the next release, libcloud will not be a hard dependency. Some clouds didn't work in libcloud (for example AWS), so these providers got implemented directly in salt-cloud or by using third-party libraries (eg. python-boto).
    • Documentation: a sprint is planned next week. Reference documentation will not be completly revamped, but tutorial content will be added.

    Boris Feld showed a demo of vagrant images orchestrated by salt and a web UI to monitor a salt install.

    http://www.vagrantup.com/images/logo_vagrant-81478652.png

    Thanks again to Thomas Hatch for coming and meeting up with (part of) the community here in France.


  • Petit compte rendu du meetup postgresql d'octobre 2014

    2014/10/09 by Arthur Lutz

    Hier soir, je suis allé au Meetup PostgreSQL intitulé "DBA et Développeurs enfin réunis". Après quelques bières et pizza (c'est la tradition de le faire dans ce sens), nous avons écouté 4 présentations autour de PostgreSQL après une courte introduction de Dimitri Fontaine et des sponsors (Mozilla et Novapost).

    http://www.logilab.org/file/266939/raw/BzcR8UOIQAAdFMh.jpg

    Jean-Gérard Pailloncy nous a parlé d'aggrégation temporelle sous contrainte d'IOPS (page wikipedia pour IOPS, au cas où). Malgré le temps court de présentation, c'était une synthèse très bien déroulée d'un projet avec des flux de données ambitieux pour des plateformes "entrée de gamme". Quelques "petites" astuces que chacun pourrait appliquer à ses projets.

    Flavio Henrique Araque Gurgel nous a parlé du partitionnement de tables et des mythes qui entourent ce sujet. Dans quels cas dois-je partionner ? Beaucoup de cas de figure sont possibles, les métriques qui permettent de prendre ce genre de décisions sont nombreuses et nécessitent une bonne compréhension du fonctionnement interne des bases de données Postgresql. Il s'agissait principalement d'amener les praticiens de postgresql à se poser les bonnes questions lors de la conception de leur base de données.

    Thomas Reiss et Julien Rouhaud nous ont présenté POWA (PostgreSQL Workload Analyzer). Il s'agit d'une extension C pour postgresql (à partir de 9.3) et une interface en Perl and Mojolicious. Un projet prometteur (bien que l'on puisse être supris qu'il soit écrit en Perl) pour maîtriser les performances de sa base de données postgresql.

    http://www.logilab.org/file/266940/raw/safe.png

    Enfin, Dimitri Fontaine a prêché la bonne parole pour rapprocher les développeurs des administrateurs de bases de données. L'idée était de faire penser aux développeurs que le SQL dans leur code est du code, pas juste des chaînes de caractères. Quelques exemples autour des "window functions" et de "common table expressions" plus tard, on espère que les développeurs feront une partie de leurs calculs directement dans PostgreSQL plutôt que dans leur application (en évitant de balader des tonnes de données entre les deux). Petit conseil : il est recommandé de rajouter des commentaires dans les requêtes SQL. "SQL c'est un language de programmation en vrai."

    Les slides devraient être publiés sous peu sur le groupe meetup, que vous pouvez rejoindre pour être informés du prochain meetup. Update : slides publiés sur : https://wiki.postgresql.org/wiki/PostgreSQL_Meetup_Paris_2014_Sept

    À Logilab nous utilisons beaucoup Postgresql que ce soit sur des projets clients (données métier, GIS, etc.) mais aussi extensivement dans CubicWeb, framework web en python orienté web sémantique.

    Le format de 20 minutes par présentation est pas mal pour toucher rapidement à un grand nombre de sujets, du coup souvent il s'agit de pistes que chacun doit ensuite explorer. Les meetups sont toujours aussi sympathiques et accueillants.


  • Système d'Archivage Électronique Mutualisé

    2015/11/20 by Marla Da Silva

    À l'occasion de l'Open Source Summit Paris 2015 Sylvain Thénault a co-présenté le projet SAEM : Système d'Archivage Électronique Mutualisé en compagnie de Pascal Romain et Pierre-Etienne Cassagnau du Conseil Départemental de la Gironde dans le cadre des retours d'expérience et solutions des entreprises.

    De nos jours, les institutions publiques locales doivent conjuguer efficacité et économie. Cherchant à résoudre cette équation complexe, les services d'Archives du Conseil Départemental de Gironde, de la Métropole de Bordeaux et de la Ville de Bordeaux ont choisi de s'allier pour développer et déployer un Système d'Archivage Électronique Mutualisé (SAEM) construit à partir de logiciels libres.

    https://www.logilab.org/file/2716717/raw/IMG_4603.JPG

    Cette présentation allie le point de vue du client (Conseil Départemental de Gironde) et notre regard technique (Logilab), en particulier sur l'utilisation du logiciel libre CubicWeb et des technologies du Web Sémantique. Vous pouvez la visualiser en HTML et aussi sur slideshare.

    Une prise vidéo a été réalisée et nous partagerons bientôt la vidéo avec vous.


  • Agile France 2016

    2016/06/30 by Marla Da Silva

    Nous avons assisté à la conférence Agile France qui a eu lieu les 16 et 17 juin au Chalet de la Porte Jaune, à Paris.

    La grande conférence agile francophone, de la communauté pour la communauté, réalisée dans un lieu exceptionnel proposait d'aborder différents sujets, tels que les méthodes agiles, l'intelligence collective et la facilitation, le développement de logiciels, l'expérience utilisateur d'innovation, les organisations et leur management, etc.

    Dans un cadre très agréable permettant de s'échapper de l'ambiance urbaine, notre équipe a pu assister à quelques conférences qui ont attirées notre attention :

    Facilitation graphique

    Jean-Pierre Bonnafous, qui a participé aux 15 ans de Logilab, a invité les participants à réagir tout au long de ces deux jours et a mis en image leurs retours.

    https://www.logilab.org/file/6729471/raw

    Toutes les sessions d'Agile France étaient présentées sur une fresque. Nous, nous sommes fans !

    https://www.logilab.org/file/6831358/raw

    Utilisateur, fais moi mal : la ditacture du test

    Emilie-Anne Gerch et Nicolas Moreau ont parlé de l'importance du test utilisateur d'une façon dynamique et ont partagé leur expérience concernant le site d'AXA Assurances avec une approche assez drôle : les designers viennent de Vénus et les développeurs de Mars, les utilisateurs sont, quant à eux, de bons Terriens. Comment ramener sur Terre un designer un peu trop perché ou sortir de sa grotte un développeur pour qui un texte blanc sur fond noir est la norme ?

    Grande leçon pour les designers, les développeurs et les chefs de projet, car ceux qui apportent la bonne réponse ce sont les utilisateurs. Selon eux, c'est le jury le plus juste, car ce sont eux qui utilisent le produit final. Les utilisateurs finaux constituent le jury le plus sévère mais le plus juste qui soit. Ils ont des mots parfois crus et des doigts qui cliquent partout sauf là où on avait pensé. :-)

    Les tests utilisateur permettent de tester un produit en conditions réelles. Grâce à ceux-ci, il est possible de recueillir des informations utiles pour améliorer le produit. Ils permettent de donner une priorité à différentes fonctionnalités ou idées. Ils permettent de reconnaître les fonctionnalités à conserver (les plus utilisées, les plus demandées...) et celles à supprimer (celles que personne ne voit ou n'utilise). Ils constituent aussi un moyen d'intégrer efficacement l'utilisateur dans la conception.

    Quelques points permettant de mieux comprendre la psychologie de l'utilisateur :

    L'être humain utilise rarement un outil pour sa fonction primaire. Il est partisan du moindre effort, il bricole et modifie les outils de manière à les adapter à son besoin.

    L'utilisateur souhaite avant tout aller à l'essentiel.

    Il ne veut pas avoir la sensation de devoir apprendre. Il ne lit pas les manuels, il pioche les informations dont il a besoin lorsque la nécessité se fait sentir.

    Il est influencé par l'extérieur (le bruit, un interlocuteur), par son état émotionnel (le stress, la somnolence...) et par son vécu (il calque ses actions sur ce qu'il a déjà pratiqué ailleurs). Son expérience s'étend au delà du numérique.

    Il est "techno-aveugle" : il veut avant tout que ça marche, la technique utilisée ne l'intéresse pas.

    Il est bienveillant : il aura tendance à se blâmer au lieu de remettre en cause le produit et donne des retours d'expérience très facilement.

    Présentation

    Un iceberg pour explorer ce qui ne va pas

    Certains d'entre-nous ont assisté à la conférence Un iceberg pour explorer ce qui ne va pas, animée par Emmanuel Gaillot et Raphaël Pierquin. La session portait sur la découverte de nos réactions face à un évènement donné.

    Cette conférence a démarré par une démonstration pratique basée sur la métaphore de l'iceberg créée par Virginia Satir. Il arrive qu'on agisse et qu'on réagisse d'une manière qui nous surprend ou nous dépasse. Pendant cette session, nous avons exploré ces situations à l'aide d'un exercice inventé par Virginia Satir, basé sur la métaphore de l'iceberg (ce qui est émergé est observable, ce qui est immergé se passe au-dedans). Les participant·e·s ont pu ainsi s'approprier un format de réflexion simple à suivre pour apprendre à mieux se connaître — et possiblement apprendre à mieux s'apprécier.

    Raphaël Pierquin a choisi un évènement qu'il a contextualisé en décrivant les comportements de chaque personne impliquée dans son récit, puis a présenté sa stratégie par rapport à cet évènement. Guidé par Emmanuel Gaillot, qui avait au préalable disposé des feuilles de papier au sol sur lesquelles étaient écrits les intitulés de chaque "case" de l'iceberg, il a ensuite déroulé devant l'assemblée toutes les étapes présentes sous le niveau de l'eau de l'iceberg. À chaque changement de "case" dans son récit, Raphaël se déplaçait vers la feuille idoine, établissant ainsi son propre cheminement physique et mental. Nous avons ensuite eu l'occasion de pratiquer par trinôme puis de discuter de cette méthode avec Emmanuel et Raphaël.

    https://www.logilab.org/file/6832314/raw

    DDD : et si on reprenait l'histoire par le bon bout ? Tout simplement.

    La conférence sur le DDD (Domain Driven Design), par Thomas Pierrainet Jérémie Grodziski a été une synthèse intéressante sur une approche de conception et de développement permettant de se concentrer sur la valeur métier. Cette approche permet notamment de communiquer efficacement et de collaborer avec les experts métier (qui doivent être capables de lire et comprendre notre code !). Les conférenciers ont su extraire certains principes et patrons de conception du fameux "blue book" à l'origine de cette expression, et les rendre accessibles : les "values objects", la couche anti-corruption, l'architecture hexagonale, etc.

    Forum Ouvert

    À cette occasion plus d'une trentaine d'orateurs ont proposé un sujet qui leur tenait à coeur. Les personnes intéressées pouvaient débattre sur chaque sujet en groupes spontanés répartis dans tout l'espace de la conférence pendant 45 minutes.

    Dans ce type d'activité, les groupes sont petits et donc la répartition du temps de parole est assez homogène.

    Juliette de notre équipe a animé le forum "le bonheur au travail" avec une vingtaine de personnes, elle a pu recueillir beaucoup d'idées intéressantes.

    Voici quelques idées qui se sont dégagées de la reflexion :

    https://www.logilab.org/file/6831796/raw

    Mindfulness & Agile

    Dov Tsal Sela nous a présenté "Comprendre tes équipes, pour comprendre à toi-même". La pleine conscience est l'art de regarder le moment présent avec clarté. En nous conseillant de faire un voyage à travers le Taoïsme, les neurosciences et le royaume animal pour comprendre comment sont prises les décisions personnelles et en groupes (et qui les prend…)

    Au cours de cet atelier, nous avons pu visionner des vidéos, et même méditer un peu.

    Comment j'ai recruté mon pair ?

    Juliette a assisté à une conférence animée par Houssam Fakih et Jonathan Salmona centrée sur le recrutement. Partant du principe que les profils trop semblables feront les mêmes erreurs et souhaitant recruter les bonnes personnes pour leur société, ils ont développé leur propre méthode d'évaluation. L'entretien est, pour eux, une des nombreuses vitrines de l'entreprise, aussi souhaitent-ils que cette expérience se déroule de la manière la plus professionnelle possible. Ils ont établi un modèle d'entretien, ce qui assure l'équitabilité des chances pour tous les candidats. Ils ont présenté leur grille d'évaluation, les différentes difficultés rencontrées, les pièges à éviter, les retours de leurs candidats, le suivi des nouvelles recrues ...

    Mais aussi...

    Laura a participé à une discussion intéressante sur le travail agile réparti sur plusieurs sites. De nombreux participants ont fait des retours sur leur expérience, qui parfois impliquait une équipe de développement répartie dans plusieurs pays. À la distance peuvent donc s'ajouter des difficultés liées aux différences culturelles. En laissant de côté ce dernier aspect qui nous concerne moins à Logilab, plusieurs éléments sont applicables sur nos développements répartis entre Paris et Toulouse :

    Des obstacles à garder en tête :

    Il est difficile de capter le ressenti à distance.

    À distance, on ne bénéficie pas de l'"info café" : ces conversations informelles dans le couloir ou la salle café, qui souvent contiennent des informations utiles pour le projet en cours.

    Certaines pratiques sont plus compliquées à distance : rétrospective, planning poker... Mais il existe des applications en ligne pour ça.

    Il est important de :

    Se rencontrer régulièrement, pour partager la même vision et souder les équipes.

    En début de projet, se mettre d'accord sur un "contrat de développement", avec entre autres les bonnes pratiques et le processus de revue et d'intégration.

    Que tout le monde ait accès à la même information : idéalement, le product owner devrait être sur un troisième site distant, pour ne "favoriser" personne. Si il n'y a pas de PO, faire en sorte que des développeurs de chaque site puissent assister régulièrement aux réunions client.

    Et enfin, pourquoi pas...

    Mettre des webcams en salle de pause.

    Faire du pair-programming réparti.