“You can not observe a developer without altering their behavior”
▻http://mikehadlow.blogspot.co.uk/2014/06/heisenberg-developers.html
He introduced us to ‘Jira’, a word that strikes fear into the soul of a developer.
Ici le problème, à mon avis, n’est pas l’outil mais l’utilisation qui en est faite : flicage, surveillance, suivi du temps dépensé. Jira ne pose aucun problème quand il est utilisé par les développeurs, pour les développeurs : Suivi de l’état d’avancement de la correction / fonctionnalité (eg. Les projets open source)
As one explained to me, “you take the next item off the list, do the work, check it in, and you don’t have to worry about it.”
Finely grained management is a recipe for ‘talent evaporation’. The people who live and breathe software will leave – they usually have few problems getting jobs elsewhere. The people who don’t like to take decisions and need an excuse, will stay. You will find yourself with a compliant team that meekly carries out your instructions, doesn’t argue about the utility of features, fills in Jira correctly, meets their estimates, and produces very poor quality software.
So how should one manage developers?
Simple: give them autonomy. It seems like a panacea, but finely grained management is poisonous for software development. It’s far better to give high level goals and allow your developers to meet them as they see fit. Sometimes they will fail; you need to build in contingency for this. But don’t react to failure by putting in more process and control . Work on building a great team that you can trust and that can contribute to success rather than employing rooms full of passive code monkeys.
Commencer déjà par prendre en compte l’avis des développeurs, leur retour. Généralement ça permet de corriger d’améliorer le process actuel, tout en impliquant et motivant les troupes.
#micro_management #autonomie #développeur #Jira #estimation #motivation #productivité
