C'est parti pour une revue de
Peopleware: Productive Projects and Teams, 2013 (1ère édition en 1987) par Tom DeMarco et Tim Lister. Encore une revue très en retard puisque j'ai eu le temps de le lire deux fois depuis que j'ai décidé d'en faire la revue.
C'est un livre à propos des équipes de développeurs, de ce qui leur permet de créer des logiciels exceptionnels et de comment (pour les managers) ne pas les en empêcher. De mon point de vue c'est aussi la suite logique du
Mythical Man Month.
L'idée centrale c'est que le développement logiciel est un travail essentiellement intellectuel (de communication et de réflexion) dans un environnement (le marché et la technologie) qui change rapidement.
Je grouperais les autres idées dans les trois catégories suivantes:
- les projets logiciels se gèrent différemment des autres projets traditionnels
- équipes et motivations
- créativité et gestion du changement
Les projets logiciels sont différents des autres
Sur la nature du travail,
Peopleware: Productive Projects and Teams ne dit pas grand chose de plus que
The Mythical Man Month de Fed. P. Brooks. Cependant il en tire la conclusion plus radicale que les méthodes traditionnelle de management sont non seulement inutiles mais souvent contre-productives.
Parmi les erreurs relevées:
- une organisation traditionnelle optimise tout pour un état stationnaire
- l'expérimentation et la prise de risque sont découragées ou très contraintes
- le travail est standardisé pour éliminer tout risque d'erreur, de temps mort ou d'originalité
- souvent le tout s'accompagne, dans l'industrie logicielle, de la conviction que le travail des développeurs est voué à être automatisé
Tout ceci est clairement inadapté au monde du logiciel où un projet qui n'est pas risqué est obsolète et où même si les robots apprenaient à coder, il faudrait toujours des humains pour analyser, négocier et formaliser les besoins clients.
Équipes et motivations
Donc les développeurs sont indispensables et il en faut certainement plus d'un pour venir à bout d'un projet ambitieux. C'est là qu'il faut s'intéresser au développement des équipes.
Un secret pour une bonne cohésion d'équipe est de s'assurer que tous aient en vue un objectif ou un idéal commun. Mais dans un métier où tout change rapidement et, en particulier les objectifs techniques, ce n'est pas si simple. Il faut donc se tourner vers quelque chose d'un peu plus abstrait.
Si on remarque par ailleurs que la plaie la plus handicapante autant pour le succès d'un produit que pour le quotidien des développeurs se résume notoirement par le doux nom de "bugs", le meilleur choix (cohérent et utile) devrait donc être de fédérer une équipe autour de la
qualité, et ceci indépendamment du projet !
Ceci étant dit d'autres éléments sont importants:
- laisser au développeurs un maximum de responsabilité et le pouvoir de décision qui va avec car ce sont eux qui en dernier lieu élaborent le logiciel et doivent réagir rapidement aux imprévus
- s'assurer que l'environnement de travail est propice (suffisamment calme et confortable)
- recruter les bonnes personnes, construire et maintenir une "élite" sans sous estimer l'apport des qualités "humaines" (par opposition aux qualités techniques qui sont toujours nécessaires)
Créativité et gestion du changement
Maintenant que les développeurs ont responsabilité et pouvoir de décision, il est certain que si des changements de plans sont nécessaires, ils se feront sans perte de temps. Mais comment s'assurer que les changements sont faits dans le meilleur sens ?
Il n'y a probablement aucun moyen d'en être sûr, mais des moyens existent pour aider en ce sens:
- laisser à l'équipe du temps pour réfléchir sur son propre travail
- s'assurer que les techlead et managers jouent plus un rôle de catalyseur que de directeur
- se méfier des méthodologies qui tendent à centraliser la réflexion et donc à en décharger les développeurs
- s'assurer qu'il est naturel pour tout le monde que le changement n'a de chance de bien se passer que l'échec est acceptable
Pour finir, un autre élément important du livre: pour que la créativité (nécessaire pour s'adapter à tout changement) se développe une certaine dose de rébellion et de chaos est nécessaire !
C'est parti pour une revue de Peopleware: Productive Projects and Teams, 2013 (1ère édition en 1987) par Tom DeMarco et Tim Lister. Encore une revue très en retard puisque j'ai eu le temps de le lire deux fois depuis que j'ai décidé d'en faire la revue.
C'est un livre à propos des équipes de développeurs, de ce qui leur permet de créer des logiciels exceptionnels et de comment (pour les managers) ne pas les en empêcher. De mon point de vue c'est aussi la suite logique du Mythical Man Month.
L'idée centrale c'est que le développement logiciel est un travail essentiellement intellectuel (de communication et de réflexion) dans un environnement (le marché et la technologie) qui change rapidement.
Je grouperais les autres idées dans les trois catégories suivantes:
Maintenant que les développeurs ont responsabilité et pouvoir de décision, il est certain que si des changements de plans sont nécessaires, ils se feront sans perte de temps. Mais comment s'assurer que les changements sont faits dans le meilleur sens ?
Il n'y a probablement aucun moyen d'en être sûr, mais des moyens existent pour aider en ce sens: