David BROCARD Consultant Indépendant

Chaîne de Production Multimédia

Depuis septembre 2009 je suis Scrum Master sur un projet multimédia innovant dont le but est de développer un produit Open Source permettant de produire des films d'animation en stop motion et de faciliter la collaboration entre les acteurs du métier :

• Scénariste : rédige scénarios et storyboards
• Animateur : met au point l'animatique, qui vient après le storyboard (synchronisation avec les sons notamment)
• Graphiste : prépare les images, vidéos dans la banque de médias ; détourage
• Sonorisateur : prépare les sons, les musiques dans la banque de médias

etc

L'agilité

Il s'agit de déployer Scrum/XP (désormais je les considère comme indissociables) sur un projet soumis à des contraintes fortes :

• Regroupement d'indépendants, tous en activité partielle sur le projet
• Release sans date fixée : le backlog est donc en perpétuelle remise en question car il s'agit d'un projet "greenfield" dont les objectifs sont rediscutés en permanence
• Itérations d'une semaine : choix ambitieux retenu par l'équipe de développement mais qui jusque là s'en sort pas trop mal
• Double activité : en parallèle des activités de développement, l'équipe a choisi de produire un vrai film d'animation pour tester le logiciel dans des conditions représentatives. Ces activités occupent pas loin de 30% du temps (préparation logistique (caméra DV, écran vert etc), création des personnages, des décors, enregistrement des bandes son etc)
• Technologies non standards pour les pratiques d'ingénierie logicielle : Flash (fichiers FLA et ActionScript3), Adobe Flex3.5a et AIR2Beta. On bosse sur Mac.

Le plus difficile dans cette entreprise, sont les changements d'objectifs. Ok, le product backlog est fait pour évoluer, mais ici c'est la vision qui évolue aussi ! C'est pourquoi les itérations sont de courtes durées et j'insiste lourdement sur la nécessité de définir quand même des plans de versions fiables. L'enjeu est de passer le moins de temps possibles à les établir car ils ont toutes les chances d'être complètement revus.

Aspects techniques

L'architecture du produit, à laquelle je participe, est basé sur du client (très) riche AIR2 beta¹. Contrairement à AIRv1, la v2 permet d'aller beaucoup plus loin en autorisant par exemple la communication par ports, ce qui permet d'envisager de toutes nouvelles répartitions de responsabilités entre client et serveur. Côté serveur, c'est du J2EE avec BlazeDS pour assurer la communication entre les objets AS3 et Java avec la techno AMF.

Après quelques cheveux en moins, je suis finalement venu à bout de l'intégration continue pour l'application cliente. On utilise la plate-forme Eclipse Ganymede WTP avec M2Eclipse et le plugin Flex Builder 3 (Flex Builder 3 n'est pas encore dispo pour Eclipse Galileo). Il s'agit de mettre en intégration continue les projets directement manipulés sous Flex Builder.

Dans Hudson, j'invoque directement le compilateur Flex/AIR en ajoutant des jobs tels que :

# compilation du SWF AIR
amxmlc -output bin-debug/clientriche.swf src/clientriche.mxml
# lancement du SWF AIR en mode debug (pas vraiment d'intérêt pour l'intégration continue)
adl bin-debug/clientriche-app.xml
# packaging d'un application AIR (attention, il faut avoir créé un certificat avant et l'invoquer)
adt -package -storetype pkcs12 -keystore /path/to/moncertif.p12 clientriche.air bin-debug/clientriche-app.xml

 -C bin-debug clientriche.swf 

Avec le runtime Flex/AIR dans : "/Applications/Adobe Flex Builder 3 Plug-in/sdks/3.5.0.12683andAIR2/bin/".

Ce n'est pas la meilleure solution, loin s'en faut. Le mieux est d'utiliser ant car Flex est fait en java et le permet nativement.

Côté java, on est full Maven2. J'avoue avoir du mal à comprendre les détracteurs de Maven. Il est vrai que le ticket d'entrée est cher mais cela en vaut la chandelle. Je miserais volontiers sur le succès grandissant de cette technologie militant pour la standardisation des processus de fabrications.

Prochaine étape : je teste l'archetype Flex pour Maven !