Mickaël’s Weblog

Les méthodes agiles assurent-elles le succès d’un projet de développement?
La réponse est clairement non. Ayant pratiqué plusieurs méthodologies (agiles…ou pas), il m’apparait clairement que c’est avant tout l’existence d’une méthode et son adhésion qui est la condition nécessaire, mais pas suffisante. Ne pas avoir mis en place de méthode est la garantie d’un désastre, et la responsabilité en incombe au management. Il faut de plus que l’ensemble des acteurs y adhèrent: équipe et client. Ce n’est pas chose facile, mais le management n’est pas une chose facile. Il faut enfin que le déroulement du projet ce fasse en toute transparence vis-à-vis de l’équipe et du client.

Mettre en place une méthode efficacement n’est pas aisée. Dans le cadre d’une SSII par exemple, les méthodes agiles sont souvent opposées aux contrats de type forfait. Il est vrai qu’au prime abord cela peut sembler vrai, mais c’est a mon avis juste une question d’approche, et au final les SSII travaillent de plus en plus en mode Agile. Sur ce sujet, Pascal Van Cauwenberghe a écrit 2 excellents articles à ce sujet: Succeding with Agil Fixed Price projects (part 1 et part 2). Les plus gros obstacles sont souvent la méconnaissance ou les fausses évidences.

Le plus important est la mise en place d’une méthodologie, ensuite il faut considérer tous les paramètres du projet dont le contexte d’éxécution (taille d’équipe, durée du projets, objectifs, priorités..etc), et choisir la méthode la plus appropriée, la modifier suivant les besoins et l’exécuter en toute transparence
.

…et notamment dans les secteurs du logiciel et des R&D. La france s’en sort plutôt bien au niveau de la productivité par heure travaillée. Dommage que ces statistiques ne donnent aucun chiffre sur les pays “off-shore” dans le développement logiciel : chine, inde, roumanie…etc.

Suite à mon exploration de Google App Engine Patch (AEP), j’ai regardé de plus près les framework de tests. Le constat global est que l’on nage un peu dans le monde de l’Open Source: plétorde de possibilités, mais au final aucune ne matchant parfaitement mes besoins (j’exagère délibérément mais cela donne ce sentiment).
Le premier fautif est certainement Google lui même. Je suis d’accord avec Michelschr quand il dit que Google devrait fournir les outils (ou API) pour que les développeurs suivent les bonnes pratiques de développement. Cela m’étonne effectivement d’autant plus que Google a une excellente équipe dédiée aux pratiques du test.
Au final, on tombe sur une myriade de framework adressant dans aspects différent du test. Il est alors très dur de trouver celui qui convient, et souvent il ne fonctionne pas parfaitement bien du fait que par exemple il est adapté à Django, mais pas à AEP.

J’ai donc réduit mes recherches sur les tests unitaire (et non pas fonctionnel). AEP étant basé sur Django, qui est un framework MVC, il me semblait évident de trouver quelque chose d’adapter a ce genre de tests. Ma première surprise fut de constater que Gaeunit exécute les tests dans l’environnement Google App Engine (GAE)…et non pas dans le SDK. C’est a mon avis utile, mais plutôt pour des “smoke” tests ou tests de prod. J’ai donc écarté cette option.
J’ai regardé ensuite les possibilités du coté de Django. Je ne suis vraiment pas fan du test-per-class où l’on associe systématiquement une classe de test par classe de code. Doctest, lui intègre les tests dans chaque fonction. Je préfère de loin placer les tests au niveau de la fonctionnalité ou du “comportement” (BDD) qui repose moins sur le refactoring qui est toujours plus délicat sur les langages dynamiques.
Autre possibilité: unittest de Django. Il est certainement possible de faire tourner ces tests dans le SDK AEP, mais cela ne fonctionne pas out-of-the-box. Django est en effet patché au vol par AEP et cela complique la mise en place de ces tests.
J’ai donc recherché quelque chose de simple, avec comme seuls pré-requis: ne fait pas intervenir d’url mais permet de “rendre” les template, et permet de mettre les tests dans un répertoire séparé des sources. J’ai au final utilisé gaetestbed (qui est très light), avec Mock, plus quelques classes permettant de créer des “fausses” requêtes HTTP POST et GET. J’utilise nose pour lancer mes tests.
Au final, j’arrive a tester l’ensemble MVC en total isolation (pas de browser, authentification mockée…etc). Il est claire que cette solution est restreinte à ce type de tests…mais pour l’instant je n’ai besoin que de cela. A noter que le DataStoreTestCase ne permet que de savoir le nombre de requetes exécuté…ce qui est clairement très insuffisant. En regardant de plus près, c’est GAE qui n’expose quasiment rien…je vais certainement devoir mocké (en stub) pour améliorer cela…a voire.