Archive for the 'Uncategorized' Category

Améliorer les conditions de travail pour améliorer la productivité ?

Imaginez un peu, s’il était possible d’améliorer la productivité des développeurs en changeant simplement leurs conditions de travail. Ce n’est pas le rêve d’un utopique mais bien le résultat de deux études -l’une du wall street journal, l’autre de Microsoft Research– selon lesquelles avoir un second écran ou un écran plus grand améliore la productivité des développeurs jusqu’à 50%.

Uu ROI rapide

Si l’on prend un peu de recul par rapport à cette étude, que l’on prend en compte le fait que les cartes graphiques à deux connecteurs se sont généralisées et que les écrans, désormais tous plats, se sont agrandis à prix constant, l’investissement à réaliser est modeste. Le retour sur investissement est donc extrêmement rapide.
Et que les managers se rassurent, ces mêmes études montrent que le choix d’un écran de 26 pouces n’apporte aucun gain de productivité supplémentaire par rapport à un modèle 24 pouces. De même, le passage à trois écrans n’apporte rien. Ouf, les développeurs ne coûteront pas trop chers…

Peut-on vraiment faire confiance à ces études ?

Ces études vont probablement être reprises par quelques commerciaux en mal de chiffres -comme ils le font avec l’étude du Standish group sur le Pair Programming- sans qu’ils comprennent en quoi ces pratiques améliorent véritablement la productivité des équipes. Je vais donc essayer de le leur expliquer en donnant quelques exemples dans lesquels l’utilisation de dual screen me semble apporter un gain de temps incontestable :

  • lors de la rédaction ou de la mise à jour de cas de tests, cela me permet d’avoir sous les yeux à la fois le document que je rédige  et l’exigence qui doit être développée, évitant ainsi de switché de l’un à l’autre
  • lorsque je développe, je peux à la fois avoir sous les yeux une classe dont je souhaite m’inspire et la classe sur laquelle je travaille, ou encore ma page web et le fichier de ressources dans lequel j’ajoute les traductions nécessaires au fur et à mesure. Je pourrai même avoir sous les yeux l’exigence pendant que je développe et ainsi vérifier régulièrement que je n’en ai pas oublié une partie
  • lorsque je lance les tests et qu’ils sont rouges, je peux à la fois voir la méthode de tests en cause et la cause de l’erreur
  • lorsque je débug, je peux avoir d’un côté la classe parcourue et de l’autre les variables, points d’arrêt et autres espions
  • lorsque je livre, je peux le faire en ayant sous les yeux le mode opératoire de livraison et ainsi éviter de trop nombreuses erreurs

Faisons confiance au feed-back

S’il fallait encore ajouter un argument, ce serait le feed-back de ceux qui ont essayé. La conclusion de Microsoft Research est simple : donnez un second écran à quelqu’un, laissez le l’utiliser quelque temps et essayer ensuite de le lui retirer. Cela n’arrivera pas. Personne ne voudra revenir à un seul écran.

Publicités

Engagement sincère (et réaliste)

Comme chacun l’imagine je travaille dans une équipe agile, dans un environnement que je pourrai facilement qualifier de complexe : muti-projets, multi-technos, équipe hétérogène en croissance…

Dans ce contexte se pose souvent la question de savoir comment l’équipe peut s’engager. Comment faire pour donner de la visibilité au client sans mettre en danger l’équipe ?

Ma réponse tient en deux mots : l’engagement de l’équipe doit être sincère et réaliste.
Sincère parce qu’il ne s’agit pas de sous-estimer volontairement sa capacité de production dans le seul but d’atteindre cette productivité.
Réaliste car il ne s’agit pas pour l’équipe de faire abstraction des problèmes qu’elle a rencontrée -et qu’elle rencontrera donc probablement encore- mais au contraire de les intégrer, d’en tenir compte et d’en déduire sa capacité de production.

Pour résumer ma pensée, je prendrai une image : imaginons qu’un employé soit obligé d’arriver à 9h au travail -par exemple pour assurer le support- l’heure d’arrivée qu’il va viser
– ne sera évidement pas 9h. Ce ne serait pas réaliste car il oublierait alors qu’il y a souvent sur la rocade bordelaise des bouchons et qu’il est une tradition bordelaise bien ancrée : lorsqu’il pleut, il y a des accidents, ce qui provoque des bouchons (qui peuvent provoquer des accidents… mais ce n’est pas le sujet).
– ne sera évidement pas 6h. Ce ne serait pas sincère. Il arriverait beaucoup trop tôt lors des nombreuses journées bordelaises ensoleillées au cours desquelles il n’y a ni bouchons, ni accidents.

Pour conclure, un engagement sincère et réaliste, c’est celui qui permet à l’équipe d’arriver à l’heure dans la grande majorité des cas, en acceptant d’être en retard dans les rares cas dans lesquels elle connait un accident sur le trajet.

 

Un début

Plutôt que de me limiter à lire les billets -forts intéressants- de mes collègues, et d’y apporter parfois un certain nombre de commentaires, j’ai choisi de pouvoir développer ici ma vision de notre métier : le développement logiciel.

Mes lecteurs voudront bien pardonner l’aspect austère de ce blog, mais je me suis limité au plus simple qui fonctionne… L’amélioration continue viendra avec le temps !


Mises à jour Twitter