Profile

Cover photo
Freddy Mallet
Works at SonarSource
Lives in Geneva, Switzerland
351 followers|20,656 views
AboutPostsPhotosVideos

Stream

Freddy Mallet

Shared publicly  - 
 
 
Call for paper pour la soirée Anniversaire de Janvier !

La session de Janvier, toujours spéciale, sera l'occasion de fêter l'anniversaire du GenevaJUG. Et comme tous les ans, il y aura du gateau :-)

Cette année, nous avons décidé de vous mettre à l'honneur, vous qui venez si nombreux chaque mois et qui faites toute la richesse de notre communauté !

Nous vous proposons donc une soirée dont vous serez les héros en nous présentant les sujets que vous voulez sous forme de Quickies de 15''

Proposez nous donc vos sujets: outils, techniques, méthodologies, ... au travers de ce Call For Paper et nous selectionnerons 6 d'entre vous pour cette soirée exceptionnelle !

Pour proposer votre talk, suivez ce lien :
https://docs.google.com/forms/d/1mj3aXT_C_33RjlCZxZlChuULjDphKVFFajVmAODEXYc/viewform
 ·  Translate
Drive
Call for Paper "Soirée anniversaire du GenevaJUG"Talk sous forme de Quickie de 15 minutes + 5 minutes de questions Tous les sujets sont possibles: outils, techniques, frameworks, méthodologies, ... Si vous en avez le besoin, nous pouvons vous aidez à vous préparez, envoyez nous pour cela un mail à speaker.academy@genevajug.ch Vous serez informés d'ici la fin de l'année si votre talk est retenu !
1
Add a comment...
 
What's the dream sustaining your project development ?

I was a bit disappointed two days ago after the keynote about Dart at #devoxx . Indeed 2 years ago I was thinking that this project might revolution our future as some other languages did in the past. To be honest I'm still thinking that this project has a great "revolution" potential. But what did I learn during this keynote ? ... absolutely nothing that I didn't already know. Google engineers are so well driven by this culture of "fast failure, experimentation, evolution, ..." that they don't want to speak about  something that might never happen. Of course they don't know what the Dart environment will be in 2 years the same way I don't know what SonarQube will be in 2 years but banning any even light reference to this initial dream sustaining the development of the Dart environment was a mistake. 

The only answer I got to this fundamental question via Twitter was "More productivity, more performance, more happy developers!". Am I really so stupid ? :) https://twitter.com/sethladd/statuses/400915945939415040 

Happily +Alexis Moussine-Pouchkine  did an interview just after the keynote and when you ask some good questions, you might sometimes get some interesting answers : Dart 1.0 interview with Lars Bak and Kasper Lund at Devoxx 2013

Google engineers, don't forget to make the community dream. You're sometimes so convinced by what you're doing and what you're going to achieve, that you might start considering all other developers as basic "consumers".  And keep doing this great job around #dartlang  
1
Add a comment...

Freddy Mallet

Shared publicly  - 
 
Fin des 20% de temps consacré à l'innovation chez Google, pourquoi  crier au loup ? Tout le monde s'accorde à penser que soutenir un effort d'innovation est un défi hautement complexe et permanent. Innover se résumerait-il à une recette de cuisine à un élément qui s'appliquerait à tout le monde et de tout temps: allouer 20% de temps libre à tous les collaborateurs pour faire de l'innovation ? 
 ·  Translate
2
Henri Gomez's profile photo
 
20% du temps pour tester des concepts et idées, c'était un des gros bonus vu par les geeks tentés par l'aventure Google.

Mais Google, devient petit à petit une grosse boutique comme les autres. Ca rationnalise à fond et pour preuve l'arrêt de services non rentables ou pas assez visibles.

La fin d'une époque, c'est ce qui fait crier au loup surement
 ·  Translate
Add a comment...

Freddy Mallet

Shared publicly  - 
3
5
Fabrice Bellingard's profile photoFelix Müller's profile photoLourie Decicco's profile photoJulien Carsique's profile photo
 
Hi,
when did you change the name of the project ? I've not seen any news about it.
Add a comment...
Have him in circles
351 people
 
The goal of a CI environment should be to make master branches unbreakable and not to provide a quick feedback when the master branches are broken.

During #devoxx  we had some passionate discussions about CI environments. Those discussions started after the reading of "How Google Test Softwares".

What's the current goal of most CI environments ? Notifying you as quick as possible as soon as some master branches have been broken ? With such approach, it's ultimately the responsibility of any developer before pushing some changes into a master branch to make sure that those changes don't break anything : compilation, unit tests, integration tests, ... whereas we all know that :
- The local developer environment is not reliable for such kind of validation
- This can highly impact the developer productivity (what to do when integration tests requires 3 minutes to be executed and consume 100% of the CPU time ?)
- This is a stressful approach for the developer as whatever is the effort provided, the risk to break the build always exists.

Of course, as soon as the build is broken, this becomes the top priority of the developer to fix what he has broken but it's already too late and this is again stressful and counterproductive. 

In fact a paradigm shift should occur : whatever the developers are doing, the master branches should be unbreakable. In other words : the CI environment should prevent developers from pushing some changes in the master branches which breaks the build.

If my understanding is correct, this concept is already in place at Google and a CI engine like Team City provides the required feature to "almost" support such approach when feature branches are used and when Team City is configured to automatically create some new jobs when a feature branch is started : http://blogs.endjin.com/2013/04/a-step-by-step-guide-to-using-gitflow-with-teamcity-part-4-feature-branches-in-teamcity/.

Of course, the impact on the CI environment can be huge as this leads to highly increase the number of validations done by the CI environments (close to the number of commits) but this definitely worth the price. 
10
2
Nicolas Lehuen's profile photoNoel Pickering's profile photoHenri Gomez's profile photoCyril Lapinte's profile photo
16 comments
 
+Henri Gomez In case of unbreakable build, I tend to highly connect the DVCS, the CI engine and the code review tools. They all should be part of an integrated workflow. If we take the example of SonarQube, I tend to think that each "pull request/task branch/change list" should be analysed before being integrated and if some technical debt is added this technical debt must be "accepted". 
Add a comment...

Freddy Mallet

Shared publicly  - 
 
Prédictibilité, ce mot si ambigu...

La semaine dernière j'avais la chance d'assister à LeanKanban.fr dont SonarSource était l'un des sponsors (Merci encore à Dimitri Baeli pour son invitation). J'ai eu l'occasion d'assister à plusieurs présentations de qualité dont celle de Yannick Quenec'hdu "La prédictibilité avec Kanban, comment je tiens mes promesses" http://lanyrd.com/2013/lean-kanban-france/scpmtm/.

Cette présentation de Yannick était vraiment excellente mais 2 messages passés durant cette présentation tiennent à mon sens au mieux d'une maladresse et au pire ... bon restons en à la maladresse. 

La première porte sur ce fameux mot "prédictibilité". En langage agile, la prédictibilité porte sur la capacité à maintenir dans le temps une vitesse de "delivery" et par voie de conséquence à pouvoir anticiper sur au grand maximum 2 mois ce qui va sortir du tuyau d'un point de vue fonctionnel. Le problème c'est que pour un manager IT, la prédictibilité c'est tout autre chose :  c'est la capacité à garantir qu'un projet d'une duré estimée d'1 an de réalisation va bien sortir dans les temps et avec le périmètre escompté. Durant la présentation, le mot prédictibilité n'a jamais été défini et malgré une question en fin de présentation, l'ambiguité n'a jamais été levée. Yannick, de quelle prédictibilité parlais-tu ?

Deuxième message: sur un projet de développement informatique et sous entendu quelque soit la nature du projet informatique, on peut arriver à un niveau de prédictibilité avec une variance maximale de 2%. En gros, à partir du moment où le processus est bien en place et parfaitement maitrisé, il n'y a aucun mur qui résiste. Autant je peux entendre ce message pour des développements à complexité faible à moyenne (sous entendu pour de l'informatique de gestion) autant pour des développements complexes ou requiérants un haut niveau de créativité, l'idée me semble plus que très dangereuse. Ou alors il est temps d'aller voir Microsoft et Oracle pour leur expliquer comment procéder pour tenir leurs délais sur les releases de Windows et de Java. 

L'agilité est né d'un constat : la prédictibilité est un graal donc oublions là !


 
 ·  Translate
1
Yannick Quenec'hdu's profile photoFreddy Mallet's profile photo
2 comments
 
Hello Yannick, bon en effet je crois qu'une ou deux bières ne seront pas de trop pour tenter un alignement sur le sujet car la prédictibilité dont tu parles je ne la vois possible que sur les projets relativement simples d'un point de vue à la fois fonctionnel et technique. Rendez-vous peut être à Devoxx France ...
 ·  Translate
Add a comment...

Freddy Mallet

Shared publicly  - 
 
Scrum et le fantasme de l'auto-organisation

Dans sa définition et sa compréhension la plus courante, le principe d'auto-organisation Scrum tient heureusement du pur fantasme. Pour en savoir un peu plus sur ce principe d'auto-organisation, il vous suffit de prendre le premier consultant Agile en herbe qui vous passe sous la main et de lui poser la question 

Vous: "En quelques mots, ça consiste en quoi ce principe d'auto-organisation dans Scrum ?"

Consultant: "Une équipe Scrum est une petite équipe pluridisciplinaire, autonome, sans hiérarchie interne et auto-organisée. Ce principe d'auto-organisation est au coeur de la méthodologie pour permettre à l'équipe de s'adapter en continue aux changements."

Vous, grand crédule que vous êtes: "Ok, mais concrètement chez moi comment je fais pour mettre en oeuvre Scrum et adopter ce principe d'auto-organisation ?"

Lui: "Après des années de fonctionnement dans des structures classiques de management pyramidales, faire le virage va prendre du temps. Il te faut donc intégrer un ScrumMaster qui va progressivement amener l'équipe à maturité."

Vous: "Désolé d'être un peu lourd, mais ça marche comment ce principe d'auto-organisation ?"

Lui: "Commence par adopter les pratiques Scrum (stand-up, retrospective de sprint, ...), intègre un bon ScrumMaster et tu vas voir que la mayonnaise va prendre. D'ailleurs si ça prend vraiment bien tu verras qu'au bout d'un certain temps la présence d'un ScrumMaster ne sera peut être même plus nécessaire."

Vous: "Désolé de devenir très lourd, mais ça marche comment ce principe d'auto-organisation ?"

Lui: "Tu viens de passer 10 ans dans une boîte au mode de management très conservateur, il faut faire un acte de foi et avoir le courage de mettre un pied dans l'inconnu"

Vous: "C'est ça, prends moi pour un con!"

Et vous avez raison, on nous prend vraiment pour des cons. Le principe d'auto-organisation Scrum aux relents quelque fois vaguement humanistes est en fait une mécanique avec des rouages parfaitement connus, relativement intelligibles et qui doivent être compris par tous. 

Après plus d'une décennie de pratique approximatives, j'en suis arrivé aux conclusions suivantes :

1- Une équipe Scrum sans ScrumMaster c'est un fantasme, disons que c'est comme une fille sans cheveux pour paraphraser Nabila.
2- Une équipe Scrum c'est une équipe qui évolue avant tout dans un cadre extrêmement rigide : sprint, stand-up, backlog, rétrospective, réunion de planification, ... En gros c'est comme un musicien à qui vous dite : "En concert, tu vas pouvoir te lacher, tu vas partir en impro mais commence par maîtriser à la perfection et de manière presque maladive la partition suivante".
3- Ce cadre auquel on ne peut se dérober va offrir rapidement quelque chose de précieux : le feedback. Mais ce feeback va être dans 90% des cas douloureux ou disons contrariant (ex: on avait dit qu'on le ferait en 2 jours, nous venons de consommer nos 2 jours et ce n'est pas terminé, pourquoi ?). comme tout feedback, surtout négatif, il est toujours possible de se mentir à soi-même en l'ignorant. Le principal rôle du ScrumMaster est précisément ici : c'est en continue de mettre le doigt là où ça fait mal pour AMENER l'équipe à prendre des décisions d'ajustement très rapidement. Enlever le ScrumMaster d'une équipe qui fonctionne à plein régime et normalement au bout de 3 mois, elle va partir en sucette.

Donc pour un gars qui vient de passer 10 ans dans une structure de management IT classique, Scrum c'est quoi ?
1- Un cadre de conduite de projet beaucoup plus rigoureux (j'irai même jusqu'à dire professionnel quand on y ajoute les épices XP et Leans) que ce qu'ils ont connu jusqu'ici
2- Une capacité à identifier les problèmes beaucoup plus rapidement (fonction essentielle du ScrumMaster même si bien entendu tout le monde doit se sentir investi de cette mission)
3- Des prises de décisions collectives pour répondre à ces problèmes (là où avant ces décisions étaient prises de manière unilatérale par monsieur le petit chef). Et là encore le ScrumMaster a un rôle primordial à jouer pour faire accoucher l'équipe. 

Bref, tout cela c'est de la très belle mécanique qui s'appuie sur une forme d'intelligence collective et inutile d'en appeler en la foi en l'homme, à Che Guevara ou au tréfond de la nature humaine pour en justifier le bon fonctionnement. 
17
5
Nicolas PERU's profile photoYoan Blanc's profile photo
2 comments
 
Non mais âllo!
 ·  Translate
Add a comment...
People
Have him in circles
351 people
Work
Employment
  • SonarSource
    present
Basic Information
Gender
Male
Story
Tagline
Co-Founder of SonarSource and Product Director of the SonarQube Ecosystem.
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Geneva, Switzerland