20 octobre 2010

Architecte ou Agile ?

Sur l'AgileTour, j'ai eu la surprise d'entendre un mythe sur l'architecture et son incompatibilité avec l'agilité. Cette fois, le propos était étoffé par un cas concret : une application qui a développé un module en local avant de constater qu'un service équivalent existait par ailleurs et centralisait cette information. Résultat : une migration à prévoir et un surcoût.
Conclusion de l'intervenant : l'architecte doit intervenir en amont pour éviter ce genre d'erreur.

Evidemment, je n'ai pas les détails du contexte, mais cette conclusion heurte mes conviction. Revoyons donc la scène au ralenti au travers de la loupe des 4 valeur eXtreme Programming :

Communication
De toute évidence, il n'existe pas de manière visible un diagramme des applications du S.I. Elles sont pourtant toutes fortement liées, donc cette information serait primordiale. Sans vouloir faire de scrum-urbanisme, un schéma logique des composants majeurs me semble indispensable. De manière plus générale, la communication ne doit pas s'arrêter au portes de l'équipe.




Simplicité
Est-ce que s'interfacer dès le début avec ce système externe aurait été bénéfique ? Le risque est de développer directement avec ses API, et de coupler les applications. En définissant une API neutre avec ses propres métaphores et son niveau d'abstraction, on découple les composants. Le code initial peut également servir de simulateur ou d'outil de test, ce qui n'est pas une perte de temps. Le concept de Simplicité est délicat à assimiler : il ne s'agit pas de faire du code naïf, ni même de faire le moins de lignes de code, mais de faire quelque chose de clair, concis, avec des rôles bien séparés et un bon niveau d'abstraction. Les métriques de cette architecture émergente sont difficiles à quantifier.
Par ailleurs, la maturité obtenue sur ce premier jet est en soi une avancée. On a toujours tendance à évaluer le coût en considérant nos connaissances actuelles, et non celles qu'on avait à l'instant t.

Feedback
Quelqu'un s'est rendu compte que le système existait déjà dans le SI, mais trop tard. De toute évidence il n'intervenait pas dans la boucle de feedback. D'où l'importance de lier aux démos un maximum de personnes d'horizons variés, de faire tourner en continue les tests d'inter-opérabilité, de publier ses API auprès des autres équipes, etc.

Courage
Il faut avoir le courage de faire un refactoring en profondeur pour abstraire l'application de ses dépendances externes. Dans cette optique, les bonnes pratiques de masquage par des interfaces nous aide  fortement. A ma connaissance, la seule difficulté majeur est de déterminer si un service est synchrone ou non, ce qui induit fortement nos interfaces. En dehors de ça, local, disant, XML, JMS, ou base de données, peu importe. Il faut aussi avoir le courage de développer son propre modèle de données et une couche de traduction, plutôt que de bondir sur le code généré depuis un WSDL. Le courage de défendre ce choix, qui coûte un peu initialement, mais qui permet une souplesse sans comparaison par la suite.

Alors ?
Si l'équipe agile a pondu une solution locale, même si elle n'est pas adaptée à la cible du S.I, elle a finalement apporté de la valeur métier rapidement. Elle a développé un mécanisme proche de ses propres besoins, respectant le critère de simplicité. Dire que le refactoring associé à une étape d'intégration dans le SI est un surcout est (AMHA) une erreur; au contraire, le système développé permet d'avoir un feedback rapide, et le refactoring nécessaire peut ne pas être si coûteux (en fonction de la maturité technique de l'équipe et de la propreté de son design). Le risque de faire intervenir une phase amont d'architecture, c'est de figer le périmètre, et de décharger l'équipe de ses engagements : "Ca ne tiens pas 1000 utilisateurs simultanés ? C'est pas nous, c'est l'architecte !"

Ma conclusion est que les architectes sont paradoxalement ceux qui défendent l'agilité pour avoir bouffé trop de projets mal ficelés, mais qui ne se l'appliquent pas à eux même. Un peu comme de vouloir une liaison TGV, mais dans le bled d'à côté. Ma conclusion secondaire, appuyé sur de nombreux autres exemples, c'est que beaucoup (trop) de gens s'arrêtent à Scrum pour mettre en place l'agilité, et ne poussent pas assez les pratiques de développement et de responsabilisation de l'équipe, ce qui est le coeur de l'eXtreme Programming.



Ah, et tant qu'on en est à parle de mythes ...
www.youtube.com/watch?v=DUoRtivgjao

19 octobre 2010

Les CastCodeurs

J'ai participé jeudi dernier à l'enregistrement de l'épisode #29 des CastCodeurs. Le sujet de cet interview à deux et demis est la "forge logicielle". Vincent Massol était obligé de s'y coller, après avoir séché les enregistrements depuis quelques temps. Arnaud Hériter était aussi de la partie, mais a dû nous quitter précipitamment pour une sombre histoire de cassage de nez à l'école, ah ces jeunes j'vous jure.


Un grand merci à Emmanuel Bernard qui se coltine le mixage de tout nos enregistrements sur son temps libre, entre deux versions d'hibernate-search.

Ecoutez l'épisode, et dites moi ce que vous en pensez !

Apple n'aime pas Sony

Tout le monde vous le dis, sur Mac c'est magique ça marche tout seul, youkaïdi.
La réalité est plus subtile.

Pour le BreizhJug nous utilisons un caméscope Sony à disque dur, qui enregistre en MPEG2+AC3. Lorsque j'essaie de lire ces fichiers sur le Mac, QuickTime, sensé être le centre multimédia ultime, ne sait pas décoder le format. Apple vend 20€ une extension MPEG2 pour Quicktime - y'a pas de petits profits - mais je préfère installer VLC qui passe sans soucis.

Voici que j'installe Adobe Première pour faire mon montage. J'utilise CS3 sur PC, je veux donc vérifier le portage Mac de la suite. Première refuse purement et simplement l'import des fichiers MPG (sans plus de précision : "erreur lors de la décompression audio ou vidéo"). Sous Windows j'ai du ajouter une DLL pour qu'il supporte le flux audio AC3, dll récupérée sur un autre soft de la suite CS3 - va comprendre. Par contre sur Mac ce type de manipulation n'est pas à ma portée.

Faut-il en déduire que la plateforme Apple ne supporte pas le MPEG, ce qui ne l'empêche pourtant pas de lire les DVD vidéo ? A moins que ce soit mon caméscope Sony qui est dans la liste noire d'Apple ? (Ou bien peut être est-ce un complot ?). La lecture de la documentation Adobe semble indiquer que l'orientation actuelle porte sur les contenus HD, mon caméscope et son format basique est donc passé de mode.

Ceci dit, AviDemux s'en sort très bien pour convertir mon fichier MPG+AC3, je me contente donc de "perdre" cinq minutes à décoder la bande son et à produire un fichier intermédiaire (un AVI, quelle honte), qui est alors accepté sans sourciller dans Première. Comme quoi l'ouverture inhérente à un logiciel opensource n'a pas de prix.