Tag Archives: methodologie

Multi écrans

Un collègue est absent cette semaine et j’en profite pour utiliser son poste de travail comme un deuxième écran… Je n’ai pas de deuxième sortie vidéo mais c’est possible grâce à synergie. Ce petit programme est un bijou. Avec un seul couple clavier/souris on peut contrôler par le réseau n ordinateurs. Mais au lieu d’amener l’image des ordinateurs distants sur votre écran (comme vnc), il transfère la souris et le clavier vers l’autre écran. Ca fonctionne comme du multi-screen mais lorsque je change d’écran je change aussi d’ordi. Magique! Et le copier/coller d’un poste à l’autre fonctionne. C’est un produit open source compatible Unix/Mac/Windows.

Dans le même genre mais légèrement différent on trouve aussi MaxVista qui est un shareware Windows. Il ne permet pas de prendre le contrôle d’une autre machine mais permet de rajouter une sortie vidéo virtuelle à votre pc. Cette sortie vidéo ira s’afficher sur l’écran d’un autre ordinateur par le réseau.
Une fois qu’on a goûté au développement avec deux écrans c’est un peu dur de s’en passer. Un écran pour les logs ou le débuggage un autre ou on fait tourner l’appli… Ca change tout. C’est très dur à faire comprendre aux directions mais c’est une erreur de faire des économies sur le matos des développeurs. Le bon matos peut tout changer question productivité.

ThoughtWorks recrute ?

Je ne cherche  pas à tomber dans la critique facile de Martin Fowler qui avec des ouvrages comme Refactoring ou Uml Distilled est un “guru” du développement. Mais son dernier billet ressemble bel et bien à une pub pour sa compagnie.
En même temps je suis entièrement d’accord avec son point vue. J’y vois même un facteur important de l’échec de pas mal de projet. On ne réussit pas un projet informatique avec une équipe peu chère (car ça veut souvent dire débutant ou peu compétent). A vouloir trop réduire les coûts des projets informatiques, ils finissent par durer bien plus longtemps qu’il ne devrait et le produit final est souvent médiocre et donc peu porteur de valeur ajouté.
L’autre facteur majeur d’échec est bien entendu la difficulté qu’ont les clients à définir leurs besoins, et encore plus à les définir dans une forme qui soit exploitatable par l’équipe projet. D’où la nécessité  des méthodes agiles et des processus itératifs.