Une alternative plus agile à Java EE

En un mot, j'essaie de trouver une pile de processus/technologie pour le développement d'applications Web, facile/rapide/flexible au prototype, mais qui a un chemin de mise à niveau clair vers une plate-forme de production robuste.

Je m'excuse pour une longue description ci-dessous, mais le problème est entre la technologie et le processus et je ne trouve aucun moyen facile/court de l'exprimer. Et oui, j'ai lu" Bon Subjectif, Mauvais Subjectif " article.

Actuellement, nous utilisons Java EE avec tous les coups et sifflets (agile, intégration continue, suivi des problèmes, tests unitaires, pile hibernate/spring/stripes/jquery ...). Nous utilisons également un processus flexible de définition/analyse de projet avec la collecte de fonctionnalités en parallèle avec la création de maquettes GUI (bravo aux maquettes Balsamiq) et plus tard le prototype de pages statiques HTML. Pendant le développement, nous faisons des builds intermédiaires fréquents avec des avis clients. Donc, une fois que nous arrivons à la phase de test, la fonctionnalité est 90% sur la cible et tout ce qui est nécessaire est une correction de bugs et la finale vernis de robustesse.

Pour nos clients traditionnels, c'est-à-dire les banques et les produits pharmaceutiques, la pile de processus/technologie ci-dessus fonctionne comme un charme.

Dernièrement cependant, nous développons pour les startups Internet. Dans ce cas, le processus est tout à fait différent. Nous commençons par quelques maquettes de base, puis le premier prototype très brut est fait (beaucoup de pages statiques + quelques fonctionnalités de base pour couvrir les scénarios de base). Ensuite, nous commençons à développer l'application complète.

Étape Critique ici! Lorsque l'application est rendue publique, les gars du marketing/des affaires reçoivent les commentaires des lève-tôt, observent la concurrence, ils tirent leurs conclusions et veulent changer l'application. Beaucoup! Mais à ce stade, nous ne sommes plus en mode prototype, nous avons une belle application Java EE robuste et de qualité de production avec des centaines de tests unitaires intégrés. Nous pouvons le faire évoluer, mais il n'est certainement ni facile ni agile.

1) Du côté du processus, nous avons essayé de clouer bas la spécification avec tous les outils visuels et formels disponibles, mais en vain; personne n'est en mesure de corriger la spécification avant que le marché ne parle.

2) Nous avons essayé des environnements plus "flexibles" comme RubyOnRails et PHP.

2.a) Pour la qualité de production, ceux-ci semblent encore un peu semaine par rapport à Java EE (oui, je sais que certains des services/applications les plus importants sont écrits en PHP)

2.b) Si nous les utilisons de manière "flexible" , ils sont parfaits pour le prototypage, mais nous obtenons le code difficile à atteindre pour la qualité de la production.

2.c) Si nous mettons en œuvre toutes les meilleures pratiques (superposition, tests unitaires ...), la complexité devient comparable à la complexité standard de Java EE que nous avons déjà.

3) Lorsque l'application est mise en ligne, elle doit être polie et robuste, donc un prototype facile à fabriquer n'est pas une option.

4) Si nous proposons de faire un prototype jetable, le client refuse de le voir comme un jetable et demande de l'amener à la qualité de production (pas prêt à payer le développement à partir de zéro).

Donc, au fond, nous mettons la "qualité" (structure intentionnelle, robustesse) trop tôt dans le processus, quand elle n'est pas nécessaire et quand elle reste dans la voie du changement et de la flexibilité.

Des idées?