J’ai assisté mardi 23 octobre à la 1ère journée des Valtech days 2007 sur le thème de l’agilité (méthodes [XP], outils). Un résumé (laborieux) des sessions auxquelles j’ai pu assister.
Test Driven Requirements: Introduction et perspectives (Gilles Mantel)
Le principe de base fût tiré du Toyota Production System ou le lean. Dans ce système, la satisfaction client est mis en avant, chaque employé est dans l’absolu responsabilisé, il se doit d’alerter et d’arrêter la ligne de production dès qu’une anomalie est détectée afin de la corriger, et de ne commander que ce qui est utile, autrement dit s’il existe un besoin réel. Ces principes ont été adaptés au développement logiciel (lean software development).
Tout le long du développement, la chasse aux gâchis est le leitmotiv de toute conduite de projet et développements : tout ce qui n’apporte pas de valeur ajoutée au client est considéré comme un gâchis. Pour cela, dès le début du cycle de développement du logiciel, toute anomalie est corrigée. Cette dernière peut-être détectée très tôt grâce au développement ou les exigences pilotés par les tests.
Exemples de gâchis :
- cycles de corrections/livraisons successifs
- signature des exigences
- tests manuels de non-régression
- informations provenant de la discussion initiale avec la MOA (des exemples concrets aboutissent à des tests).
Dans un cycle itératif normal ou conventionnel (dans le sens ce qu’applique tout le monde à 80 %), on trouve : exigences (CDC) -> spécifications -> conception/développement -> tests unitaires -> tests fonctionnels -> recette et validation de la version.
Dans la logique lean, le test est introduit dès les exigences, et dans toutes les phases du cycle du projet. Pour la conception et développement, des outils sont nécessaires pour améliorer le processus (Wiki, usine logicielle), et automatiser notamment tout ou partie les tests : FIT apporte une solution aux tests fonctionnels. fitnesse, quant à lui intègre FIT et un Wiki (équipe = collaboratif). On parlera aussi de greenpaper.
Conclusion
Tout cela apporte des bénéfices sur la qualité du code et la diminution du risque de bugs. Il est très conseillé de se faire accompagner pour la mise en place d’une approche agile, ces méthodes formant un tout. Des mutations organisationnelles et professionnelles seront également à prévoir, autrement dit, changer ses habitudes pour en acquérir de nouvelles. L’équipe (un terme fort) prend toute sa place ici, sous réserve que chaque membre ait une forte compétence en conception et une assez bonne expérience en développement objet.
Le Refactoring : la solution agile pour conserver un code évolutif (Régis Médina)
Un mot que j’aime bien : le refactoring (ou appelé également revamping). Session présentée sous forme de démonstration, par Régis MEDINA, ou comment à partir d’un code existant (Java, Swing), le refactorer proprement (IDE Java utilisé : IntelliJIDEA).
Le refactoring n’est qu’une brique d’XP, l’ensemble des briques forment un tout. Le refactoring sert à réduire la complexité du logiciel sur le long terme. Lors de la production de code, on assiste à un phénomène inhérent à tout produit qui croit : la difficulté de maintenance, et surtout la question d’évolutivité du logiciel : rendre plus simple le développement de toute évolution dans le logiciel, que cela soit par l’auteur ou part toute personne susceptible de toucher au code.
Les différentes phases du refactoring d’un code :
- safe delete
- rename
- extract
- inline
- move
- change signatures
- factory
Principes pour la suppression des duplications :
- identifier ce qui est commun (on trouve souvent l’acronyme : DRY : éviter la redondance de code).
- identifier ce qui change
- concevoir l’interface
Conclusion
la conception est centrée sur l’existant, des compétences en conception sont demandées au développeur, le travail en équipe reste primordial.
Agilité: à monter soi-même… (Laurent Bossavit)
Le conférencier est ouvertement opposé à UML, trop compliqué à son goût.
L’adoption d’une méthode agile peut s’effectuer de 2 manières :
- en sous-marin, sans soutien des instances dirigeantes : cas le plus difficile et le moins propice à son adoption
- adoption sous forme de projet pilote : le scénario idéal, on se fera dans ce cas accompagner par un professionnel.
Plusieurs risques à l’adoption d’une méthode agile :
- adoption en bloc : difficultés d’apprentissage, logique de performance, choc culturel
- adoption “une pratique à la fois” : pas forcément optimale, car une pratique est compréhensible dans son ensemble (XP, Scrum forment un ensemble de pratiques, qui rendues indépendantes deviennent moins pertinentes).
Introduire une notion de délais reste très mauvais psychologiquement (“stress”), on parlera plus volontiers de vélocité d’un projet (compréhension, refactoring, tests).
Comme dans la session TDD / TDR, les tests sont primordiaux dès le début, et automatisés, ainsi que la notion de travail en équipe.
Quelques livres :
- “La 5ème discipline”, Peter Senge
- “The logic of failure”, Dietrich Droner
Conclusion
le bon sens, tiré de mon expérience, veut que l’on s’oriente sur ces méthodes. Introduire des tests [automatisés] s’avère une très bonne chose. Cela nécessite une relation moins MOE/MOA au sens fournisseur/utilisateurs (avec le mur des spécifications signées très tôt) mais plus une relation de partenaires, client et maîtrise d’oeuvre ont le même objectif : sortir un logiciel qui rendra service aux utilisateurs et répondra au service attendu. Se faire accompagner reste la seule solution à mon sens, la mise en oeuvre requière énormément de bouleversement du point de vue technique (conception, outils) que organisationnelle (changement des habitudes et des processus).
Web 8.3 ou l’avenir du web (Xavier Paradon)
Après un résumé des technologies mises en oeuvre dans le cadre de projet Web 2, et une critique toute justifiée sur l’abus de langage souvent employé lorsque l’on parle de site Web 2.0, l’orateur a fini sur une conclusion intéressante mais discutable.
Conclusion
La tendance pour l’avenir du RIA serait d’extraire les applications du navigateur pour les faire fonctionner sur le poste de travail, on en reviendrait à des clients Adobe AIR, Silverlight, ou autre JavaFX. La concurrence est rude, et Adobe a une avance non négligeable sur ce domaine.
Intégrer les APIs Google Maps dans une application WinForm .NET (Jean-Louis Vidal)
Objectif : sous forme de démonstration, coder une application fenêtrée (winform .NET), qui appelle Google Maps, afin détablir des chemins de parcours à la Défense.
Le contrôle WebBrower est utilisé pour embarqué le navigateur dans l’application. La clé Google Maps est utile dès lors qu’on commence à utiliser des recherches d’adresses par exemple. Cette clé gratuite permet 50 000 hits / jour, dans le cas d’un plus grand besoin, il devient nécessaire d’obtenir une licence commerciale de Google Maps (à titre d’exemple, pour 1,5 M hits, la licence tourne autour de 195 k€).
Astuce pour une communication entre .NET et le JS : utilisation de webbrowser.Document.InvokeScript(“fctJS”,args).
Conclusion
La démonstration fut très intéressante, car les objets Javascript manipulés restent simples et accessibles, l’API fournie par Google est riche et permet un grand nombre de fonctionnalités.
1 je n’ai pu assister aux 2 journées, la 2ème étant baptisée Openspace, qui se voulait ouverte, les thèmes étant élaborés par les participants.
2 framework opensource, disponible dans différents langages.
3 on ne peut le blâmer. Personnellement, UML se résume souvent aux use cases et quelques schémas de classes pour parler la même langue que l’équipe.
4 J’en rajoute un : “Le mythe du mois-homme”, Frederick P. Brooks