RTFB

Un état de fait m'énerve, il m'énerve d'une part parce que dans d'autres domaines professionnels, il n'est pas aussi exacerbé, et d'autre part parce que je pense que la tendance s'accélère.

Pour résumer,

• Un cuisiner peut devenir un chef qui se réinvente tout le temps, et fait de sa cuisine un art ;
• Un architecte construit des edifices, et tire à chaque itération des leçons de ses erreurs ;
• Un médecin diagnostique des maladies et construit les contre-mesures adaptées ;
• Un manager analyse, planifie et anticipe les problèmes de son projet et de son équipe pour atteindre un objectif ;
• Enfin, et ce pour les décideurs et l'opinion publique, un développeur ...  pisse du code.

Il pourrait être en Inde, en Thaïlande ou en région parisienne, ça ne change quasi rien, il lui suffit d'une tête (mal faite ou bien faite) d'un dossier de spec, d'un manager qui gueule, d'une QA (elle-même outsourcée) chargée de vérifier que ça correspond bien aux desiderata du client, et c'est tout !

Mais alors me direz-vous, "ce n'est pas le cas partout, quid des startups ? quid des méthodologies agiles ? quid du DevOps et du Software Craftsmanship !

Ben rien, en startup, j'en ai vu beaucoup qui considère les devs comme tout le monde, alors que pour moi (biaisé comme je suis) c'est eux qui créé le produit !

Et là on atteints mon favoris, les méthodologies Agiles, Scrum, Lean, Xp, Kanban etc... Quasi-toutes responsabilisantes pour les devs, mettant l'équipe au centre, facilitant leur travail etc... Eh bien désolé de vous décevoir, mais au delà des laboratoires de Toyota, on se retrouve dans le beau petit monde du Flicage ou le standup devient un reporting au manager, et où beaucoups de gourous et pratiquant (français) vous expliqueront bien gentiment que les développeurs sont des "gens simples"/ressources/abrutis qu'il faut savoir controller. Et qu'une fois leurs pouvoirs débloqués vous pourrez enfin bien vous faire voir de votre hierarchie !!

youhou... Sur ce

Vale

When big corporations try to create new corporate standards out of multiple agile methods (Xp, Scrum...). You often end up like that :

This was extracted from the website : http://www.halfarsedagilemanifesto.org/

Il y a un problème qui se pose très souvent dans toute équipe de développement et de support, a fortiori dans les équipes qui emploient des consultants (comme moi ), c'est celui de l'intégration des nouveaux arrivants et comment les rendre opérationnels le plus tôt possible.

A cette question les reponses sont toujours les mêmes :

• Une documentation à la fois générale et spécifique sur l'application ;
• Un accompagnement par un ancien pour les premiers temps ;
• Des petits exercices simples pour se mettre en condition et gagnez en confiance sur l'application ;
• et enfin le plus d'interaction possible avec les autres membres de l'équipe.

Beaucoup de ces conseils sont très bien, et certain particulièrement useless... Maintenant j'expérimente depuis quelque peu une nouvelle approche. Une approche plus centrée sur la réalité et, en tout cas je trouve, un peu plus interactive : des scénarios d'incidents de production.

Car en somme quand on est sur une application, on apprend vraiment à 200% en s'occupant du support, des incidents de production ou des demandes utilisateurs (le fameux "au fait comment ça fonctionne ça ?" très copain du "ben j'comprend pas, j'attendais ça et j'ai eu ça !?")

Donnez à vos nouveaux arrivants de vrais scénarios passés d'incidents de production pour qu'à la fois vous et eux puissent apprendre des erreurs passées.

Pas (que) des stacktraces bruts sans explications, mais plus un mélange de logs, de messages d'erreurs, de stacktraces et potentiellement d'indices supplémentaires.

Je tiendrais à jour mes expériences sur ce sujet, mais pour l'instant je suis plutôt content des résultats et surtout de la manière dont cette approche stimule beaucoup plus mes padawans que l'usuelles présentation rébarbative des packages/classes/mini-frameworks.

A mes bons lecteurs,

Vale