tyPouypOblOg

J’allais presque oublier d’en parler, et pourtant…

Jeudi dernier, au petit matin, j’avais rendez-vous à la défense. Au lieu de la couture: costumes cravatte et tailleurs de rigueur (enfin pas trop pour moi hein :)).

Excusez la photo de maigre qualité, en plus de ne pas être un photographe, elle a été prise avec mon téléphone portable :-/

J’avais donc rendez-vous avec un collègue qui m’avais quelque jours auparavent proposé de venir faire une intervention d’une heure trente en cours magistral pour un module dont il avait la charge: la pré-production. C’etais pour les 3eme année de la fac de vinci, vous savez la fac dites pasqua huhuuhu.

Enfin, bref, j’ai accepté bien sur, une occassion comme celle-ci y’en a pas non plus tout les jours.

J’ai beaucoup apprécié, j’avoue que je recommencerais volontier. D’autant plus que j’ai quand même pas mal de chose à corriger dans ma façon de présenter les choses, dans ma façon de parler, bref. C’etais une très bonne première expérience, certain élèves se sont endormi (peut-être que c’etais trop tot ? ou alors trop chiant :-/) d’autres regardaient un film ou je ne sais quoi sur leur laptop… Mais plus de la moitié (faisait semblant de) m’écoutaient. J’espère que j’ai mis la puce à l’oreille d’un ou deux au sujet des méthodes agiles.

Je mets le support de ma présentation sur ma zone, au cas où ça interesse quelqu’un: zone.typouype.org/preproduction_methode.odp. j’ai mis au format pdf et au format fermé ppt aussi, pour ce qui ne serais pas encore passé à des outils ouverts

Un TD pour la prochaine fois ? Ou alors une conférence dans un évènement libre ? On verra :)

Me voilà donc revenue dans le monde du service informatique. En mission chez un grand compte comme on dit. Une étape, pour me remettre dans le bain.

Mais voilà, chez ce client, comme chez beaucoup d’autres je pense, c’est à l’ancienne (ben oui c’est pas juste ma reprise de service qui est à l’ancienne ;)).

J’entends par là, vieille technologie propriétaire, vieille méthodologie non approprié.

D’un point de vue technologique d’abord. L’utilisation de cette technologie est une erreur et pour preuve. J’ai passé a peut prêt 75% de ma journée à essayer de remettre mon environnement de développement en route.

Forcement, j’ai une machine sous windows, assez récente, mais je ne l’utilise que pour me connecter en TSE à un serveur, sous windows également (déjà il y a du gâchis là, un thin client m’aurais suffis pour cela non ?). Bon passons pour les systèmes d’exploitation et le gâchis de matériel.

Alors forcement, la dessus, on se connecte tous on viens taper sur le même serveur de base de données et quand un petit malin (genre moi) fait tout planter sur un test de migration, ben c’est une 10aine de personnes qui sont au chomage technique. Mais il arrive aussi (caprice du monde propriétaire) que d’un coup, sans savoir, sans pouvoir analysé d’où, un problème survient, vous empêche de vous connecter. Vous aller voir les voisins, eux aussi ne peuvent pas bosser… Alors on reboot, ça ne fait rien, on fait quelque danse grigri en priant pour que ça reparte (enfin ceux qui sont croyant, moi je vais prendre un café dehors en général :p).

Bref, matériel et technologie à l’ancienne

Pour ce qui est des méthodologies: Papiers, verrouillage des spécifications fonctionnelles.

Tu sais ce que tu veux pour dans 2 ans pour des utilisateurs que tu n’as vu que 8 heures il y a deux mois ? ok ! Alors on verouille, tu pourras plus rien demander de plus pendant l’année qui s’écoule (si on a pas trop de retard genre voir chapitre précédent).

Horrible non ? Et bien c’est un peu ça que l’on souhaite mettre en place là, car forcement, il y a trop de modification en court de développement... Ben voyons.

C’est agile ça non ? Non effectivement, c’est à l’ancienne ...

Mais il ne faut pas croire c’est une bonne chose qui m’arrive ici. Je peut essayer d’imaginer comment je ferais autrement. Je peut aussi vérifier les arguments divers et varié pour ou contre tel ou tel méthode, technologie. On le sait, on le lit partout, mais s’y frotter pour de vrai c’est encore une autre affaire. J’ai déjà eu cette occasion y’a un moment, mais y revenir ça fait du bien, ça rafraîchi la mémoire.

Ceci dit, vivement la suite quand même :)

Ca fait un moment que l’on entend parler du concept GTD (plus d’info sur wikipedia:Getting Things Done). C’est une méthode qui doit permettre de faire les choses, avec gestion des prioritées tous ça…

Bon, j’avoue que ça semble très interessant, surtout quand on cherche à arreter de s’éparpiller sur divers projets, divers bricolage à faire pour la maison, les 3 tonnes de courrier non ouverts, etc… Mais voilà, appliquer une méthode demande la rigueur de l’application de cette méthode (c’est con dit comme ça hein ?).

Et voilà qu’il y a quelque jour, chez Ploum, je tombe sur un billet traitant du sujet de l’organisation tout en glandouillant: GARI qui est une sorte d’adaptation Ploumesque de GTD.

Comme Ploum le rappel, toute méthode est interessante, mais bien souvent nécessite des adaptations en fonction du contexte, et des gens qui l’applique. Ploum à donc très bien décrit ça vision du GTD. Et j’avoue que ça version du GTD me plait bien. J’ai donc décidé de l’appliquer, du moins en partie, pour voir.

J’ai donc enlver les règles de tri de mes messages, tout remis dans la inbox principal, supprimer les dossier de chaque mailling-list à laquelle je suis abonné, puis créé un dossier deskbox. Pour trier un peu dans la deskbox j’ai ensuite créé des sous dossiers par projet courant (bon pour le moment c’est ma boite perso, donc ça ne concerne que mes projet perso, pour le coté pro on verra plus tard).

Ensuite viens le temps du grand menage de inbox. Comme le dit Ploum, on stock tros de mail, et c’est vrai, qui fouille dans ces mails à la recherche d’une info sur comment on configure PF sur OpenBSD 4.2 ? On vas tous sur notre moteur de recherche préféré, voir sur plusieurs pour bien faire, et c’est tout… Les mails, ça ne sert pas à grand chose de tous les stocker, même en archives.

Attention me faite pas dire ce que je n’ai pas dit ! Certain sont à garder. J’ai donc aussi ajouté une boite archive.

Après suppression et tri des messages, j’ai une inbox vide (pour le moment) et il faut avouer que ce n’est pas désagréable. Les dossiers par projets ne sont pas trop plein et ne contiennent que des choses en rapport avec mes projets en cours. Et ma deskbox contient 2 mails sur lesquel il faut que je travail…

A suivre donc, on verra si ça me rend plsu efficace. Peut-être une tentative de inbox physique pourrais suivre…

XP, eXtreme Programming (oui oui , on vas quand même pas parler du système d’exploitation à base de fenêtre ici ! Vous croyez quoi :) ). Pour ceux qui ne connaissent pas, c’est une méthode de travail. Dans mon ancienne boite il parait qu’on faisait de l’XP. Mais quelque personnes (dont moi) voyais bien que ça ne ressemblais pas à de l’XP comme on doit la faire, du coup c’étais rebaptisé Ultima Programming :p

Pour revenir sur l’eXtreme Programming, la vrai. C’est donc une méthode de développement basé sur quelque principe de base, simple, qui semble une évidence. Je vais vous parler des points dont je me souviens, je ne suis pas un expert, et j’ai jamais eu l’occasion de pratiquer cette méthode au sein d’une équipe, d’un projet, pourtant c’est pas l’envie qui me manque :p.

Test unitaire

C’est une des bases importantes de l’XP. Dans le livre qui ma permis d’en apprendre plus sur cette méthode, c’étais traité comme le pilier de l’XP. Les tests unitaires [wikipedia] sont une série de petite vérification. Pour faire simple, et par l’exemple imaginons un objet HexaColor qui a une méthode getColor(color). Une série de test unitaire de cet objet pourrais ressembler à :

assert(Color.getColor("blue"), "#0000ff")
assert(Color.getColor("white"), "#ffffff")

C’est simple non ? Les tests unitaires permette de bien préciser ce que l’on attend d’une méthode, d’un objet. Le développeur de l’objet les fournis, cela remplace bien souvent les spécifications fonctionnelle car on peut, en lisant les test unitaires comprendre ce que fait chaque méthode, chaque objet. De plus, en rejouant les test à chaque modification dans le code, on vérifie qu’il n’y a aucun effet de bord et/ou aucune régression dans le projet.

Une chose simple que je ne n’ai encore jamais vu appliquer…

Documentation

JE l’ai effleuré dans le bloc test unitaire, en XP il n’y a pas ou peu de documentation. Les tests unitaires servent de documentation fonctionnel, et la documentation technique ne sert à rien. Le code est sensé être simple, clair, limpide et donc se suffire à lui même.

A la limite, c’est ici un point discutable pour moi. Le problème viens du fait que nous ne sommes pas tous égaux en programmation, et chacun applique sont style. On dit bien “écrire du code”. C’est donc comme pour toute les écriture, chacun à ça façon de formuler. Maintenant, dans l’XP il y a un point qui peut permettre de palier à ce problème.

Coder en binôme

Et oui, c’est surprenant, pour beaucoup de manager c’est une perte de temps (comme les tests unitaires), mais dans l’XP c’est un des point clé (d’après moi): Tout code s’effectue en binôme. Plusieurs avantages sont apportés par ce point.

• La communication, le partage.
  Point ultra important. On peut dans ce cas partager ça façon de voir les chose et la confronté à une autre. Ca permet de faire évoluer les façon de faire, et permet de faire évoluer plus vite ceux qui débute en les mettant en contact avec des codeurs plus expérimenté, mais ça permet aussi aux plus expérimenté de continuer à ce remettre en cause, de ne pas rester assis sur des acquis (c’est jamais bon ça).
• Le contrôle, l’analyse
  Il n’y a quand même qu’un seul clavier sur le poste de développement. Donc pendant qu’un écrit l’autre regarde, réfléchi, affine l’algorithme mis en place. On peut corriger les erreurs tout de suite. On le sais: 4 yeux valent mieux que 2 (surtout que y’en a 2 qui sont plus ou moins concentré sur la frappe, même si bon, c’est discutable :p ). Si un des deux ne sais pas comment faire une partie, l’autre peut prendre la relève.
• L’ennui
  C’est bon pour le moral aussi de travailler à deux. Surtout que dans l’histoire, on doit changer de binôme toute les demi journée… Oui oui, un binôme n’est valable qu’un demi journée :). Ca bouge, ça casse la routine.

Itérations courtes

Comme les binômes doivent changer toute les demi journées (enfin c’est le système optimal d’après ce que j’ai retenu). Il faut se tenir à des “taches”, des “itérations” courtes. Une méthode, un besoin doit être construit en une demi journée, sinon ce n’est pas la peine de le faire, il faut le découper en plusieurs petits morceaux. Le but est de tester toute les demi journée l’intégration de nouveauté, de voir le projet avancé toute les demi journée. Avec l’XP on ne doit pas perdre de temps.

Réunions

Le contact avec le client ou un de ces représentant est permanant. Il voit le projet avancé rapidement par petit morceau et peut revenir dessus si un point flou commence à s’éclaircir au fur et à mesure que le code avance. Par contre fini les réunions qui n’aboutissent à rien. L’auteur du bouquin parle même d’un minuteur de cuisson. Il le mettais à 15 minutes, une fois sonner, fini la réunion, tant pis si tout les points n’ont pas été abordé. Une réunion qui dur embrouille les esprits, c’est contre productif.

Code jetable

Il ne faut pas hésiter à jeter le code fait la veille, le code qui finalement ne correspond pas à ce que le client souhaite. Jeter un code qui a pris une demi journée à faire est toujours plus facile que jeter un projet réalisé dans l’ombre pendant 6 mois. Je suis gentil sur les 6 mois, j’ai vu des projet de 2 ou 3 années mis aux oubliettes sans même avoir tourné en production… Un beau gâchis de ressources et d’argent.

Conclusion

C’est une bonne méthode sur le papier, après dans les fait, la difficulté c’est de l”appliquer. Comme pour la sécurité informatique, le problème vient de l’humain. Il est apparemment très dur d’avoir des responsables, des développeurs près et capable de passer à l’action.

Tout ça pour vous mettre un petit lien (oui je nettoie toujours mes favoris :p). Il existe une association française de gens qui développe ou s’intéresse à cette méthode de travail xp-france. Je n’ai pris contact avec eux, je ne suis pas inscrit. En gros je ne les connais pas vraiment, mais je crois qu’il faut que je le fasse. C’est dans ma monstrueuse TODOListe :). Le bouquin dont je parle doit être Extreme Programming : La référence [Amazon] par Kent Beck.

Erf ! encore un billet énorme, je voulais arrêter de faire ça. Pfff. Tout ça pour un lien en plus :p