Mon frère suit actuellement des études d’informatique en école d’ingénieur. Son professeur de Java a donné un projet d’année à réaliser. Pour cela, il a distribué un document contenant l’expression des besoins succincte et le déroulement du projet.
Mon frère, qui veut réussir ce projet, m’a demandé de l’aide. Comme j’ai aussi été étudiant et que j’ai, comme certainement beaucoup d’autres étudiants, connu de longues nuits blanches une semaine avant de rendre ma copie, je lui apporte des conseils pour se focaliser sur l’important dès le début, avoir un rythme soutenable et voir son avancement. Je suis donc en train de lui expliquer la seule méthode de travail que je connais et qui permet d’atteindre ces objectifs : extreme programming.
La fin du projet est prévue pour le mois d’avril 2011.
Un cent mètres avec des boulets aux pieds
Tout pourrait être pour le mieux dans le meilleur des mondes possibles, mais voilà… Dans le document décrivant le déroulement du projet, j’ai vu des contraintes fort déplaisantes.
Fermez la communication !
Fin des questions pour l’appropriation du besoin : le 14 décembre 2010 à 10h30
Un des critères les plus importants d’un projet réussi est l’adéquation entre le besoin et le logiciel réalisé. Pour atteindre cet objectif, une communication constante doit être établie entre le client et l’équipe de développement. Il est aujourd’hui admis, en regard de l’échec des méthodes traditionnelles, qu’il est impossible de prédire dès le début du projet le périmètre de celui-ci. Comment, dans ces conditions, peut-on se permettre de refuser toute forme de communication avant la fin du projet ?
À vos marques, prêt, documentez !
— Dossier de spécification à rendre le 28 janvier 2011. Première note.
— Dossier de conception à rendre le 27 avril 2011. Deuxième note.
Évidemment, quiconque avec un minimum de connaissance dans les méthodes agiles pensera à la deuxième valeur du manifeste agile : « Des logiciels opérationnels plus qu’une documentation exhaustive».
Nous sommes ostensiblement dans l’approche opposée puisqu’il est dit clairement que les documents qui doivent être fournis seront notés. Il n’est d’ailleurs pas fait mention du code à fournir ni de sa notation dans le reste du document.
Est-ce formateur ?
L’argument avancé par les professeurs pour proposer une approche ne favorisant que très peu l’agilité et la réussite du projet est que « c’est comme ça en entreprise ». Je dois bien admettre qu’il y a malheureusement un fond de vérité dans cette affirmation. Ces professeurs estiment donc que le rôle d’une école est de préparer ses étudiants à ce qu’ils vont rencontrer dans les entreprises. Même si pour cela, les étudiants doivent souffrir des méthodes traditionnelles.
Est-ce vraiment ça le rôle des écoles ?
Lors des dernières conférences auxquelles j’ai pu assister, de nombreuses questions portaient sur les problèmes liés au recrutement de jeunes qualifiés aux méthodes agiles. Il est clairement difficile de trouver des jeunes développeurs qui connaissent TDD, la conception incrémentale et l’art de faire le plus simple qui fonctionne.
Je mettais cette rareté sur le dos de l’ignorance des méthodes agiles par les professeurs. Hors, visiblement, nous ne sommes pas dans ce cas puisque, toujours selon mon frère, les professeurs prétendent connaître ces méthodes mais choisissent de ne pas permettre à leurs étudiants de les utiliser parce que « c’est comme ça en entreprise ».
Le monde de l’entreprise a besoin de jeunes professionnels adaptés aux contraintes actuelles et formés aux meilleures méthodes qui existent actuellement. Ces jeunes doivent être capable de regarder le fonctionnement des entreprises avec un regard critique et pas avec celui d’un ovin incapable de proposer des changements.
Crédit photos: On compte plus facilement ses moutons que ses amis.. / Lionoche via Flickr CC License By