Traditionnellement, on se disait que pour développer plus vite, il fallait soit faire travailler plus de développeurs, soit les faire travailler plus longtemps chaque jour.

Le problème avec plus longtemps chaque jour, c'est qu'il ne tiennent pas longtemps! :roll:

Le problème avec plus de développeurs, c'est que la collaboration devient de plus en plus complexe et la gestion de plus en plus importante. Il faut une répartition des tâches minutieuse, une modularité exemplaire et un système de gestion de code source à la hauteur.

Tout ça coute cher... très cher... souvent trop cher et il reste plus rentable, dans de nombreux cas, développer moins vite, avec moins de développeurs! :|

Une autre alternative consiste à décharger le développeur des tâches ingrates de manière à ce qu'il puisse se concentrer sur l'essentiel. Le développeur appréciera souvent de se faire livrer à déjeuner... et parfois même à diner (ne pas abuser du régime pizza, ça lasse et la lassitude nuit à la créativité)... Mais plus sérieusement, il appréciera que quelqu'un d'autre s'occupe de la documentation... et par dessus tout: ce dont le développeur moyen à horreur: c'est le testing! Il repoussera toujours les tests à plus tard alors qu'il serait en fait plus judicieux de tester tout au fur et à mesure des modifications, avant qu'on ait oublié ce qu'on a bien pu modifier exactement et qui puisse provoquer tel ou tel bug... (Je ne m'étends pas sur la nécessité de tester le plus rapidement possible, c'est une vérité communément avérée! :|)

Actuellement, je travaille à mes heures perdues, au développement de b2evolution, un logiciel qui permet de gérer des blogs ultra-sophistiqués :D

Avec ce type de projets - et la majorité des projets web en général - il est relativement facile de livrer une release cohérente quotidienne. J'entends pas là, une release utilisable sans soucis majeur au delà des messages "non implémenté pour l'instant".

En ce qui me concerne, j'ai une tendance naturelle à contempler le fruit de mes efforts en situation de fonctionnement réel... donc de fait, je teste systématiquement... ne serait-ce que pour le plaisir de voir fonctionner la chose. Rigolez, mais regardez comment ça se passe chez les développeurs en entreprise... vous verrez à quel point ils ne sortent pas du code pour voir le produit! C'est affollant! 8| Bon, il faut dire aussi que je ne travaille pas en tant que développeur; ici je ne développe que ce qui me fait envie... ça aide considérablement! :P

En revanche, là où je les rejoins (les développeurs d'entreprise), c'est que je n'aime pas reprendre tous les tests à zéro de manière répétée pour voir si les nouvelles fonctionnalités n'ont pas eu de répercutions négatives sur l'existant, sur l'utilisabilité globale... Les tests de non régression au sens large en fait...

Bref, je fais donc appel à des testeurs extérieurs pour vérifier l'intégrité globale du logiciel. Ceci est d'autant plus utile que b2evolution est basé sur du code antérieur (b2) que je n'ai pas écrit et dont je ne maitrise donc forcément pas l'ensemble des subtilités! (And don't get me started about b2's documentation! >:()

Ces développeurs se trouvent être localisés aux Etats-Unis. Et bien qu'il ait été utile au départ de pouvoir discutter en direct par instant messaging afin de répondre aux questions les plus immédiates, je me rends compte maintenant que je peux envoyer une release par mail le soir et lire les résultats des tests le matin! :) C'est pas bonheur ça?

(Si vous êtes développeur, je suis sûr que vous partagez mon enthousiasme... mais ne croyez pas pour autant que vous pouvez vous foutre de tout.. et en particulier pas de la gueule de vos testeurs! Si vous leur livrez des releases pourries, ils vous livreront des résultats de tests pourris! :>>)

Quoi qu'il en soit, je me dis que la formule est probablement applicable au développement professionnel. Bien évidemment, bien qu'à une certaine époque j'aie moi même passé de longues nuits à tester le code de mes développeurs, je ne suggère pas d'embaucher des testeurs et de les faire travailler la nuit...

Ce que je suggère, c'est d'embaucher des développeurs dans un autre fuseau horaire et grâce à la magie de l'internet, d'alterner des journées de développement et des journées de test, mais tout ça dans un même cycle de 24 heures!

Il est temps de tirer partie du fait que la terre tourne sur elle même, non? :))

Je me demande également si il ont ne pourrait pas mettre à profit un troisième fuseau horaire pour le project management! :?: L'idée serait la suivante: pendant 8 heures les chefs de projets fixent les priorités, puis pendant 8 heures les développeurs implémentent, puis pendant 8 heures les testeurs valident, puis ce sont à nouveau les chefs de projet qui réajustent les priorités en fonction des résultats des tests. Idéalement, il faudrait que les zones de travail se chevauchent légèrement afin de garder des contacts directs. Personnellement, je placerais la coupure entre les testeurs et les chefs de projets, je pense que ce sont ceux qui souffriront le moins de ne pas avoir de contacts directs...

M'enfin il est probable que ça ait déjà été fait... Si vous connaissez des exemples, ça m'intéresse fortement!

Comments from long ago:

Comment from: pk

Voilà, moi aussi je développe tout seul un produit (openTIME chez http://www.noparking.net/) et j’avais un testeur à Dakar. Et hier pour la première fois on s’est recontré pour parler du code et du produit.

Bilan ? On se dit quand même beaucoup plus de choses de vivo que par le net… Et ma liste de choses à faire vient de faire un bon de 10 lignes ;-)

Donc ne “jamais” rencontrer ses testeurs ni ses chefs de projet (ils sont dans un fuseau horaire différent), c’est pas toujours le plus productif non plus :-(

2003-05-22 18-15