Les modèles d’entretien techniques surtout les modèles traditionnels ont beaucoup de points communs avec le modèle du cycle en V ou les projets waterfall.
Cette ressemblance concerne notamment les deux points suivants : - le récit des expériences professionnelles du candidat
- les tests techniques sous forme de QCM
Le problème avec ces deux points est le manque d’un feedback rapide pour le recruteur qui ne l’aide pas à optimiser son entretien qui est déjà d’une durée limitée.
Afin de maîtriser notre process de recrutement et garantir une méthode d’évaluation homogène et partagée, nous nous sommes inspirés des méthodes agiles pour définir notre propre modèle de recrutement et d’animation des entretiens techniques.
Notre objectif est de satisfaire les besoins des différents acteurs impliqués dans ce process, à savoir : le candidat, le(s) recruteur(s) et le(s) décideur(s).
L’entretien dans notre modèle est constitué de plusieurs itérations assez courtes ayant comme objectif de donner un feedback rapide au recruteur à la fin de chaque itération. A l’issu de l’entretien, notre modèle permet au recruteur d’identifier un profil bien précis du candidat synthétisant ses points forts, ses points faibles ainsi qu’un plan pour conquérir ces derniers.
Cette synthèse est partagée avec le candidat lors d’une rétrospective puis communiqué au(x) décideur(s) . Cette session est un retour d’expérience sur une centaine d’entretiens techniques animées sur quatre ans. Nous détaillons les différentes parties de l’entretien, la méthode d’évaluation suivie, les contrôles permettant de détecter les points à améliorer dans notre modèle, la qualité des candidats reçus (taux de réussite, etc.), ainsi que le suivi des candidats qui nous ont rejoint (intégration, évolution, etc.) Cette session s'adresse à tous les développeurs même ceux qui n'animent pas des entretiens techniques mais aussi toutes les personnes qui sont intéressées par les questions de recrutement.
Agile Tour Lille 2015 - Ratez vos revues de codeMichel Domenjoud
La revue de code, tout le monde connait, bien sûr. C'est d'ailleurs une des plus vieilles pratiques de développement, dont l'efficacité est prouvée depuis longtemps pour détecter des défauts au plus tôt. Alors pourquoi tant d'équipes n'utilisent elles pas la revue de code, ou n'en tirent pas les bénéfices qu'évoquent de nombreuses études ? Au cours de cette session, on explorera les nombreux écueils à éviter au travers de situations de revue de code qui se passent mal, et on proposera des pistes pour corriger le tir.
Support de ma session présentée à Agile Tour Lille le 15/10/2015
Les slides de ma session à aux Agile Tour de Rennes, Vannes et Nantes. Ou comment comprendre que faire des tests est vital pour un projet. Mais aussi que ce n'est pas aussi cher qu'on le pense.
Suite à ma lecture de "The Software Craftsman" de Sandro Mancuso, je présente ce qu'est le Software Craftsmanship.
Présentation visible sur YouTube : https://youtu.be/RW0-QIJttBM
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
Les modèles d’entretien techniques surtout les modèles traditionnels ont beaucoup de points communs avec le modèle du cycle en V ou les projets waterfall.
Cette ressemblance concerne notamment les deux points suivants : - le récit des expériences professionnelles du candidat
- les tests techniques sous forme de QCM
Le problème avec ces deux points est le manque d’un feedback rapide pour le recruteur qui ne l’aide pas à optimiser son entretien qui est déjà d’une durée limitée.
Afin de maîtriser notre process de recrutement et garantir une méthode d’évaluation homogène et partagée, nous nous sommes inspirés des méthodes agiles pour définir notre propre modèle de recrutement et d’animation des entretiens techniques.
Notre objectif est de satisfaire les besoins des différents acteurs impliqués dans ce process, à savoir : le candidat, le(s) recruteur(s) et le(s) décideur(s).
L’entretien dans notre modèle est constitué de plusieurs itérations assez courtes ayant comme objectif de donner un feedback rapide au recruteur à la fin de chaque itération. A l’issu de l’entretien, notre modèle permet au recruteur d’identifier un profil bien précis du candidat synthétisant ses points forts, ses points faibles ainsi qu’un plan pour conquérir ces derniers.
Cette synthèse est partagée avec le candidat lors d’une rétrospective puis communiqué au(x) décideur(s) . Cette session est un retour d’expérience sur une centaine d’entretiens techniques animées sur quatre ans. Nous détaillons les différentes parties de l’entretien, la méthode d’évaluation suivie, les contrôles permettant de détecter les points à améliorer dans notre modèle, la qualité des candidats reçus (taux de réussite, etc.), ainsi que le suivi des candidats qui nous ont rejoint (intégration, évolution, etc.) Cette session s'adresse à tous les développeurs même ceux qui n'animent pas des entretiens techniques mais aussi toutes les personnes qui sont intéressées par les questions de recrutement.
Agile Tour Lille 2015 - Ratez vos revues de codeMichel Domenjoud
La revue de code, tout le monde connait, bien sûr. C'est d'ailleurs une des plus vieilles pratiques de développement, dont l'efficacité est prouvée depuis longtemps pour détecter des défauts au plus tôt. Alors pourquoi tant d'équipes n'utilisent elles pas la revue de code, ou n'en tirent pas les bénéfices qu'évoquent de nombreuses études ? Au cours de cette session, on explorera les nombreux écueils à éviter au travers de situations de revue de code qui se passent mal, et on proposera des pistes pour corriger le tir.
Support de ma session présentée à Agile Tour Lille le 15/10/2015
Les slides de ma session à aux Agile Tour de Rennes, Vannes et Nantes. Ou comment comprendre que faire des tests est vital pour un projet. Mais aussi que ce n'est pas aussi cher qu'on le pense.
Suite à ma lecture de "The Software Craftsman" de Sandro Mancuso, je présente ce qu'est le Software Craftsmanship.
Présentation visible sur YouTube : https://youtu.be/RW0-QIJttBM
Agile Tour Nantes 2014 - Tdd, le meilleur moyen d'écrire du code testableAssociation Agile Nantes
Les tests unitaires automatisés sont indispensables à l'agilité. Le TDD est le meilleur moyen d'écrire
ces tests et d'avoir du code testable, mais sa pratique va au-delà, notamment dans l'aide à la
conception du code. Un peu de théorie et beaucoup de démo live pour vous montrer cette pratique.
Les développeurs dans le regard des autresHoussam FAKIH
“Des êtres introvertis voire asociaux avec des lunettes assis derrière leur ordinateur“ voilà un des stéréotypes associé à l’image d’un développeur dans l’imagination populaire. Mais qu’en pensent vraiment les personnes qui gravitent autour de nous?
Nous leur avons posé les deux questions suivantes :
”Qu’appréciez-vous chez les développeurs ?”
“Qu’est ce que vous n’aimez pas chez eux ?”
Préparez-vous à être surpris par les réponses des fonctionnels, responsables de la cellule R&D, managers des geeks, les RHs, les commerciaux, les responsables de l’avant-vente, de la vente, les architectes mais aussi les autres développeurs.
L’agilité ne suffit pas pour être un bon développeurHoussam FAKIH
L’agilité est sans doute une des méthodes les plus efficaces pour simplifier la production logicielle. Derrière ce mot nous avons tendance à ranger toutes les compétences requises et attendues d’un(e) développeur(se) professionnel(le) dans le sens crafts(wo)man. Mais quelles sont donc toutes ces compétences ? Est-ce que l'agilité suffit pour faire des bons développeurs ? Pourrions-nous développer sans être agile tout en livrant des applications de grande qualité ? Cette session apporte des réponses pragmatiques sur ces questions en définissant une liste bien précise et concrète des différentes compétences attendues d’un “crafts(wo)man” performant(e). Nous parlons également de l’importance de mesurer ces compétences d’une manière continue pour suivre notre progression et devenir plus efficace. Nous abordons également les techniques qui permettent un apprentissage ciblé et maîtrisé pour mieux progresser sur chacune de ces différentes compétences.
Quand vous avez une centaine d'entretiens de recrutement par an, comment construire le modèle le plus approprié pour avoir une méthode d'évaluation homogène, objective et partagée par tous les acteurs impliqués dans ce process (candidats, évaluateurs, recruteurs, commerciaux, RH et décideurs).
Sur les cinq dernières années nous avons vécu toutes les problématiques liées à cette situation dans notre société de conseil. Les pratiques agiles ont été cruciales pour l'amélioration continue de notre modèle. Ce dernier a atteint aujourd'hui une certaine stabilité et un niveau de maturité qui nous permet d'éviter des mauvais castings.
Comment nous avons réussi à mettre en place ce modèle. Sur quels critères nous sélectionnons nos candidats. Quelle est notre grille d’évaluation. Quelles sont les différentes difficultés rencontrées, les pièges à éviter, les retours de nos candidats, le suivi des nouvelles recrues et plein d'autres questions auxquelles nous tenterons de répondre durant cette conférence avec un coup de projecteur sur chaque acteur impliqué dans ce process.
Mon équipe, Moi et le Pair Programming à temps completHoussam FAKIH
Ne pas avoir son propre ordinateur mais partager le même ordinateur avec son binôme : voilà ce qui explique le pair-programming à temps complet. Dans ce contexte poussé à l’extrême, il ne suffit pas d’être seulement un bon développeur. Il faut également avoir d’autres qualités comme : la coordination, la précision, la vigueur, la souplesse, etc. Si le sujet vous intéresse, venez interagir avec toute l’équipe (inchangée depuis un peu plus de deux ans) qui sera présente pour vous faire un retour sur cette expérience inédite.
Thoughts on Building Metrics for Good DevelopersHoussam FAKIH
Measurement is a key. In general, developers do not like metrics. But “Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.” In this talk, we are interested in metrics based on the code produced by a developer or a team. Which metrics could help us to have a quick feedback on the quality of the code we just developed?
Never Develop Alone - Always with a partnerHoussam FAKIH
In February 2016, I celebrated my 4th anniversary developing using full-time pair-programming. By full-time I mean that when I arrive in the morning at work I do not have my own computer. I share a computer all the day with another developer of my team. At first sight, it might look easy, amazing and a kind of luxury. Instead of having one person to develop a new functionality we have two persons that work together on it. In reality, it is a tiring but exciting work: ‘Tiring’ because you need to have more skills than solo developers. ‘Exciting’ because it challenges you and if it does not challenge you it does not change you.
In this talk, I’ll focus on the challenges and the main benefits of this kind of pair-programming for you, for your team and for your company: How you can make the most of this kind of programming? How each pair can boost his partner? How you can improve your technique of pairing? How you can anticipate problems and fix them? What are the common errors about pairing?
Développement guidé par la résolution des problèmes Houssam FAKIH
Beaucoup d’entre nous limitent la résolution de problème à la simple élimination du “Muda”.
Après un an et demi de pratiques diverses et variées, au sein d'une société d'édition de logiciel financier, notre constat est différent: au delà de la réduction du gaspillage, nous pensons que cette pratique est bien plus riche en enseignements.
L’application de ces méthodes nous a contraint à changer de point de vue, à travailler notre acuité et notre créativité. Et ce changement de vision s’est avéré terriblement efficace et parfois “magique”, au point que nous tentons de l’appliquer à notre quotidien de développeur.
Nous vous proposons donc un bilan transparent, riche, sans concession et plein de métaphores:
* l’euphorie de la découverte
* nos pratiques
* les premiers obstacles rencontrés (Ha bon, ce n’est pas une solution magique?)
* l’épiphanie ou comment la résolution de problèmes change nos pratiques de développement
Ah la rétrospective … véritable colonne vertébrale de l’amélioration continue que tout Scrum Master attend avec impatience. Malgré de nombreux échanges, les multiples formats mis en œuvre et les centaines de post-its griffonnés, vos rétrospectives se suivent et malheureusement se ressemblent. Les mêmes problèmes ressortent continuellement, les actions ne sont pas suivies, les échanges sont stériles ou tournent parfois au conflit et finalement toute l’équipe a l’impression de perdre son temps.
Identifier les dérives inhérentes à cette cérémonie et découvrez comment faire pour que vos rétrospectives redeviennent un véritable « moteur de changement »
Decider ensemble efficacement, oui mais comment ?Frantz Degrigny
Nous voulons tous faire partie d'une équipe sympa et performante ! En réalité ce n'est pas magique : des pratiques simples et performantes existent. L'agilité nous propose de maximiser la valeur que nous livrons en misant sur l'intelligence collective. L'équipe est censée s'auto-organiser et prendre ses décisions collectivement. Oui mais comment fait-on concrètement ?
En regardant ce qui se fait ailleurs, nous pouvons miser sur l'aspect humain et voir comment les apports des Core Protocols et la pratique du Message Clair (issu de la CNV) peuvent nous aider à rendre notre travail, à la fois, plus confortable et plus efficace, par des exemples concrets basés sur des situations vécues.
Conférence présentée, en juin 2019, à Agile France - Paris et à la journée Agile - Lausanne
Les développeurs dans le regard des autresHoussam FAKIH
“Des êtres introvertis voire asociaux avec des lunettes assis derrière leur ordinateur“ voilà un des stéréotypes associé à l’image d’un développeur dans l’imagination populaire. Mais qu’en pensent vraiment les personnes qui gravitent autour de nous?
Nous leur avons posé les deux questions suivantes :
”Qu’appréciez-vous chez les développeurs ?”
“Qu’est ce que vous n’aimez pas chez eux ?”
Préparez-vous à être surpris par les réponses des fonctionnels, responsables de la cellule R&D, managers des geeks, les RHs, les commerciaux, les responsables de l’avant-vente, de la vente, les architectes mais aussi les autres développeurs.
L’agilité ne suffit pas pour être un bon développeurHoussam FAKIH
L’agilité est sans doute une des méthodes les plus efficaces pour simplifier la production logicielle. Derrière ce mot nous avons tendance à ranger toutes les compétences requises et attendues d’un(e) développeur(se) professionnel(le) dans le sens crafts(wo)man. Mais quelles sont donc toutes ces compétences ? Est-ce que l'agilité suffit pour faire des bons développeurs ? Pourrions-nous développer sans être agile tout en livrant des applications de grande qualité ? Cette session apporte des réponses pragmatiques sur ces questions en définissant une liste bien précise et concrète des différentes compétences attendues d’un “crafts(wo)man” performant(e). Nous parlons également de l’importance de mesurer ces compétences d’une manière continue pour suivre notre progression et devenir plus efficace. Nous abordons également les techniques qui permettent un apprentissage ciblé et maîtrisé pour mieux progresser sur chacune de ces différentes compétences.
Quand vous avez une centaine d'entretiens de recrutement par an, comment construire le modèle le plus approprié pour avoir une méthode d'évaluation homogène, objective et partagée par tous les acteurs impliqués dans ce process (candidats, évaluateurs, recruteurs, commerciaux, RH et décideurs).
Sur les cinq dernières années nous avons vécu toutes les problématiques liées à cette situation dans notre société de conseil. Les pratiques agiles ont été cruciales pour l'amélioration continue de notre modèle. Ce dernier a atteint aujourd'hui une certaine stabilité et un niveau de maturité qui nous permet d'éviter des mauvais castings.
Comment nous avons réussi à mettre en place ce modèle. Sur quels critères nous sélectionnons nos candidats. Quelle est notre grille d’évaluation. Quelles sont les différentes difficultés rencontrées, les pièges à éviter, les retours de nos candidats, le suivi des nouvelles recrues et plein d'autres questions auxquelles nous tenterons de répondre durant cette conférence avec un coup de projecteur sur chaque acteur impliqué dans ce process.
Mon équipe, Moi et le Pair Programming à temps completHoussam FAKIH
Ne pas avoir son propre ordinateur mais partager le même ordinateur avec son binôme : voilà ce qui explique le pair-programming à temps complet. Dans ce contexte poussé à l’extrême, il ne suffit pas d’être seulement un bon développeur. Il faut également avoir d’autres qualités comme : la coordination, la précision, la vigueur, la souplesse, etc. Si le sujet vous intéresse, venez interagir avec toute l’équipe (inchangée depuis un peu plus de deux ans) qui sera présente pour vous faire un retour sur cette expérience inédite.
Thoughts on Building Metrics for Good DevelopersHoussam FAKIH
Measurement is a key. In general, developers do not like metrics. But “Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.” In this talk, we are interested in metrics based on the code produced by a developer or a team. Which metrics could help us to have a quick feedback on the quality of the code we just developed?
Never Develop Alone - Always with a partnerHoussam FAKIH
In February 2016, I celebrated my 4th anniversary developing using full-time pair-programming. By full-time I mean that when I arrive in the morning at work I do not have my own computer. I share a computer all the day with another developer of my team. At first sight, it might look easy, amazing and a kind of luxury. Instead of having one person to develop a new functionality we have two persons that work together on it. In reality, it is a tiring but exciting work: ‘Tiring’ because you need to have more skills than solo developers. ‘Exciting’ because it challenges you and if it does not challenge you it does not change you.
In this talk, I’ll focus on the challenges and the main benefits of this kind of pair-programming for you, for your team and for your company: How you can make the most of this kind of programming? How each pair can boost his partner? How you can improve your technique of pairing? How you can anticipate problems and fix them? What are the common errors about pairing?
Développement guidé par la résolution des problèmes Houssam FAKIH
Beaucoup d’entre nous limitent la résolution de problème à la simple élimination du “Muda”.
Après un an et demi de pratiques diverses et variées, au sein d'une société d'édition de logiciel financier, notre constat est différent: au delà de la réduction du gaspillage, nous pensons que cette pratique est bien plus riche en enseignements.
L’application de ces méthodes nous a contraint à changer de point de vue, à travailler notre acuité et notre créativité. Et ce changement de vision s’est avéré terriblement efficace et parfois “magique”, au point que nous tentons de l’appliquer à notre quotidien de développeur.
Nous vous proposons donc un bilan transparent, riche, sans concession et plein de métaphores:
* l’euphorie de la découverte
* nos pratiques
* les premiers obstacles rencontrés (Ha bon, ce n’est pas une solution magique?)
* l’épiphanie ou comment la résolution de problèmes change nos pratiques de développement
Ah la rétrospective … véritable colonne vertébrale de l’amélioration continue que tout Scrum Master attend avec impatience. Malgré de nombreux échanges, les multiples formats mis en œuvre et les centaines de post-its griffonnés, vos rétrospectives se suivent et malheureusement se ressemblent. Les mêmes problèmes ressortent continuellement, les actions ne sont pas suivies, les échanges sont stériles ou tournent parfois au conflit et finalement toute l’équipe a l’impression de perdre son temps.
Identifier les dérives inhérentes à cette cérémonie et découvrez comment faire pour que vos rétrospectives redeviennent un véritable « moteur de changement »
Decider ensemble efficacement, oui mais comment ?Frantz Degrigny
Nous voulons tous faire partie d'une équipe sympa et performante ! En réalité ce n'est pas magique : des pratiques simples et performantes existent. L'agilité nous propose de maximiser la valeur que nous livrons en misant sur l'intelligence collective. L'équipe est censée s'auto-organiser et prendre ses décisions collectivement. Oui mais comment fait-on concrètement ?
En regardant ce qui se fait ailleurs, nous pouvons miser sur l'aspect humain et voir comment les apports des Core Protocols et la pratique du Message Clair (issu de la CNV) peuvent nous aider à rendre notre travail, à la fois, plus confortable et plus efficace, par des exemples concrets basés sur des situations vécues.
Conférence présentée, en juin 2019, à Agile France - Paris et à la journée Agile - Lausanne
Version longue en PDF de la présentation sur l'employabilité des traducteurs et sur la transition réussie entre formation et profession : explication des diapos et plus de 400 liens actifs vers des ressources de qualité !
Comment nous implémentons eduScrum à la Coding Factory, l'école du code de la CCI de Paris by ITESCIA.
Pour ceux qui souhaitent aller plus loin voici le guide officiel eduScrum:
http://eduscrum.nl/file/CKFiles/Guide_eduScrum_1.2_FR_2015.pdf
Ce guide d'évaluation des préférences d'apprentissage sensibilise le formateur sur la nécessité d'adapter ses stratégies d'enseignement pour amener l'apprenant à considérer ses préférences d'apprentissage et pour que les échanges formatifs entre les deux parties les prennent en compte. Des outils à utiliser en situation de formation sont proposés et contextualisés.
La seconde partie du guide met l'accent sur le rôle de l'apprenant et sur sa propre contribution méthodologique et méthodique nécessaire pour optimiser son apprentissage. Les exemples, donnés en référence à des apprenants adultes maîtrisant peu ou mal le français, sont utilisables plus largement dans le domaine de l'éducation des adultes.
Ce guide d'évaluation des préférences d'apprentissage sensibilise le formateur sur la nécessité d'adapter ses stratégies d'enseignement pour amener l'apprenant à considérer ses préférences d'apprentissage et pour que les échanges formatifs entre les deux parties les prennent en compte. Des outils à utiliser en situation de formation sont proposés et contextualisés.
La seconde partie du guide met l'accent sur le rôle de l'apprenant et sur sa propre contribution méthodologique et méthodique nécessaire pour optimiser son apprentissage. Les exemples, donnés en référence à des apprenants adultes maîtrisant peu ou mal le français, sont utilisables plus largement dans le domaine de l'éducation des adultes.
Coacher des managers avec le Lean (Agile France 2013)Antoine Contal
Le Lean fournit au coach un chemin pour métamorphoser les managers en développeurs de talent (hitozukuri en japonais), qui feront la joie des utilisateurs, des informaticiens et des patrons. Présentation effectuée à la conférence Agile France. Public visé : coach agile.