La déontologie, ça te parle?
C’est quand tu respectes un code de conduite, une charte, les règles de l’art…
C’est aussi savoir dire non quand il le faut et savoir faire des compromis quand il le faut aussi.
Mais attention à ne pas confondre compromis et compromission…
Dans cet épisode de SCRUM Life, Jean-Pierre Lambert m’interroge sur cette question de la déontologie de l’ingénieur.
SAFE, Scaled Agile Framework ne plait visiblement pas à tout le mode.
Mais pourquoi?
Qu’est-ce qui se cache au delà d’une page d’accueil peu accueillante?
Thierry Cros nous en dit plus sur ce qu’est SAFE, à qui il s’applique et pourquoi tout le monde ne l’aime pas.
Pour en savoir plus:
Billets de Thierry Gabriel Cros: http://www.toltequeagile.com/
SAFe: https://www.scaledagileframework.com/
Thierry Cros nous emmène dans une voyage aux origines du mouvement agile par la découverte de l’eXtreme Programming avant même que le manifeste ne soit publié.
Tu y verras en quoi XP est révolutionnaire à l’époque et comment la technologie a permis son émergence.
Enjoy !
Pour en savoir plus sur Thierry et son travail, c’est par ici !
Les 12 principes du manifeste agiles sont souvent ignorés. C’est bien dommage car leur étude reste riche d’enseignements 20 ans plus tard.
Le manifeste n’est plus tout jeune. Les premiers développeurs nés après son écriture arrivent sur le marché du travail.
Si les 4 piliers ont souvent été repris et commentés, j’ai vu moins de choses sur les 12 principes. Pourtant, ils sont de précieux guides sur comment mettre en oeuvre la démarche.
En plus ils ont traversé le temps sans une ride : la sagesse qu’ils nous livrent restent plus que jamais d’actualité.
Continuer la lecture de « Les 12 principes du manifeste agile »
Si tu confonds le SCRUM Master avec le chef de projet d’avant, peut-être. Mais si tu considères le SCRUM Master comme un animateur, alors avoir une compétence technique devient un handicap: il est trop tentant de prendre part à la réunion.
En même temps pour aider les développeurs à mettre le pied à l’étrier ou pour gagner leur confiance, un bagage technique est quand même bien utile…
Viens écouter le point de vue de Jean-Pierre Lambert dans cet épisode.
Et toi, ton SCRUM Master est technique ou pas?
Youtube: www.youtube.com/c/JPLambert
Article mentionné: jp-lambert.me/scrum-master-techn…r-not-1dc478a1bd50
Youtube: https://www.youtube.com/c/JPLambert
Blog: jp-lambert.me
Article mentionné: jp-lambert.me/le-bon-d%C3%A9velo…odeur-23ca9eb635c8
Cette réflexion commence par un échange avec un ami. Nous trollons sur un sujet stratégique: vaut-il mieux développer en PHP / Symphony ou en Ruby on Rails?
Il argumente que les développeurs PHP sont plus nombreux, ce que je concède. Il marque un point.
J’argumente que trouver un bon développeur Ruby on Rails est plus facile que trouver un bon développeur PHP, ce qu’il concède. Je marque un point.
C’est alors qu’il lance l’estocade finale:
“Oui mais moi je ne cherche pas un bon développeur, je cherche juste un mec qui pisse du code. J’ai juste besoin d’un bon lead dev.”
Le monde d’aujourd’hui file à toute allure. Il faut aller vite. Les deadline sont ASAP. Je vois pas mal de projets qui oublient un détail: si notre capacité de calcul évolue de manière exponentielle depuis quelques décennies, l’humain évolue beaucoup plus lentement… Et l’humain vie depuis des milliers d’années au rythme des journées et des saisons.
Continuer la lecture de « Monter une équipe de développeurs, machine à vapeur ou V12 ? »
Comme toi probablement, les emails ont pris une place centrale dans mon activité professionnelle. Sauf que cela prend une place envahissante!
J’avais l’impression d’être connecté en permanence à ma boite. Je gardais toujours un onglet ouvert sur gmail.
Cela prenait un temps considérable. Et pendant que je traitais mes emails je ne produisais pas de valeur pour mes clients.
Pire, je me surprenais parfois à regarder mes emails sans même m’en rendre compte… Tu sais un peu comme ces matins où tu ne réalises que tu as pris la voiture qu’en arrivant au parking de ta destination…
Continuer la lecture de « Comment atteindre l’inbox 0 ? Retour d’expérience »
Un bon code source est un code qui se lit SANS commentaires.
Par ce que s’il y a besoin de commentaires, c’est qu’il est difficile à lire…
Alors je sais, on t’a peut-être dit le contraire…
Traditionnellement, les commentaires sont un critère de code mieux documenté et donc, sous entendu, plus facile à maintenir.
Et si c’était tout l’inverse?
