Octo a récemment participé à la réalisation de l’application iNomineo pour iPhone (cf  OCTO Technology accompagne Generali sur l’iPhone ) :

Pourquoi avons nous mis en place une usine de développement (UDD) suite à ce projet ? A première vue, cela soulève plusieurs questions :

• La mise en place d’une UDD relève d’une problématique d’industrialisation : comment rendre plus productif un process que l’on maîtrise. Alors qu’un projet iPhone évoque plutôt l’innovation : un langage peu connu, de nouveaux outils, une nouvelle plateforme.

• Une UDD a pour vocation de simplifier le travail d’intégration entre les différents développeurs : plus ceux-ci sont nombreux, plus l’UDD se révèle payante. Or nous n’étions que 3 développeurs sur ce projet, on aurait tendance à penser que l’on peut gérer cet effort d’intégration « à la main ».

• L’UDD a également pour rôle d’automatiser l’exécution des tests, or une des particularités d’une application iPhone c’est la prédominance de l’interface graphique (réputée couteuse et compliquée à tester), de plus quels outils peut-on utiliser ?

• Pour finir, l’iPhone souffre encore de l’image du jeune étudiant faisant fortune sur l’appstore : ce type de projet véhicule pour certains une image d’amateurisme, « c’est un travail à confier à un stagiaire ».

Pourtant l’expérience nous a montré qu’une UDD et la pratique des tests unitaires apportent des solutions à des problèmes récurrents sur le projet.

De plus, la mise en place d’une UDD avec une couverture de test conséquente et les métriques associées sont un moyen d’apporter un gage de qualité et de professionnalisme à un projet iPhone.

Dans cet article, nous couvrirons les raisons concrètes qui nous ont poussé à le faire, et comment nous y sommes parvenus.

Dans un prochain article, nous verrons quelles pratiques de test mettre en place sur un projet iPhone (les outils, les méthodes, les bonnes pratiques).

(Lire la suite…)

Les méthodes agiles recommandent la colocalisation des acteurs (i.e. une localisation physique dans un même bureau) pour une meilleure communication, une meilleure collaboration et globalement une équipe ou un processus projet plus performants. Par exemple Ken Schwaber dans The Enterprise and Scrum :

« High-bandwidth communication is one of the core practices of Scrum… The best communication is face to face, with communications occurring through facial expression, body language, intonation, and words. »

Que disent les sciences de ce sujet aujourd’hui âprement discuté dans la communauté agile et ô combien toujours délicat à mettre en œuvre dans les faits ?
(Lire la suite…)

Dans un projet d’entreprise, il est important de vérifier continuellement la non-régression du produit réalisé. Au même titre que les tests unitaires, les tests d’acceptance font partie intégrante du harnais de tests à mettre en place sur un projet. FitNesse est une des solutions à ce besoin.

FitNesse / Slim

FitNesse dormait jusqu’à Juillet 2008. Mais il suffit de voir le rythme des releases depuis cette date, pour se rendre compte qu’il s’est réveillé ! Avec une nouvelle version presque tous les mois entre Juillet 2008 et Juillet 2009, et l’arrivée de Slim, on obtient un produit qui a sensiblement changé.

Mais avec une évolution aussi soudaine, on ne peut malheureusement pas éviter les effets de bords. Notamment dans le monde des outils qui tournaient autour de la sphère FitNesse. Par exemple, je recherchais un plugin Maven pour FitNesse. Mais la plupart des liens que me renvoie mon moteur de recherche préféré, pointe sur des outils incompatibles avec les nouvelles versions de FitNesse.

Il faut creuser un peu avant de trouver les perles rares…

(Lire la suite…)

Oyez, oyez, l’Agile Tour passe par Genève ce lundi 12 octobre. Cet évènement attend près d’une centaine de participants. C’est gratuit, ouvert à toutes et à tous mais il faut s’inscrire en ligne.

OCTO viendra en force avec une équipe d’architectes, basés à Lausanne et Paris, qui vont rejouer deux sessions présentées à l’USI 2009:

• Maîtrise d’ouvrage et agilité
  • Directions métiers et Maitrises d’Ouvrage (MOA), principaux demandeurs de réactivité, ont aujourd’hui entre les mains de nouvelles opportunités comme lancer la construction d’un logiciel sans avoir à spécifier dès le début l’intégralité des fonctionnalités, pouvoir réorienter en cours de projet ou encore réduire les délais de livraison en parallélisant spécification et développement.
    Oui mais…
    Comment spécifier au fil de l’eau ? Que devient la phase de recette ? Quelle documentation mettre en place ? Doit-on encore gérer le changement (à la fin) ?
    Une chose est sûre, les activités traditionnelles des Maitrises d’Ouvrage sont en train d’évoluer…
• La face cachée de la mesure: une opportunité pour votre amélioration continue
  • Les métriques ne sont plus regardées pour ce qu’elles sont. Les indicateurs sont aujourd’hui bien souvent synonymes de « flicage » dans nos entreprises. Néanmoins, la mesure est une opportunité lorsqu’elle s’inscrit dans une dynamique d’amélioration. Sur la base de la roue de Deming et son célèbre PDCA (Plan, Do, Check, Act) nous parcourons différents types de métriques envisageables autour des projets de développement logiciels et y associerons des contextes d’utilisation pour s’améliorer continuellement.

Tous les détails du programme de la journée sont ici.

Venez nombreux!

Suite à mon précédent post, La meilleure façon de rater son projet grâce à Maven2, un collègue m’a décrit la situation suivante « Une pratique sur notre projet est de lancer un build maven -mvn clean install- sur son poste local avant de faire un commit. Cette commande est super longue, et les développeurs disent ‘c’est normal c’est maven qui est long’, ça doit prendre combien de temps un build Maven ? ».
(Lire la suite…)

Existe aussi en version .NET ou PHP !

La JSR 314 spécifiant la version 2 de Java Server Faces (JSF), le framework de développement d’IHM web fourni par JEE, a été livrée en version finale le 12 mai dernier (cf. http://jcp.org/en/jsr/detail?id=314).

Cette version 2 de JSF cherche à améliorer la productivité des développements, l’intégration d’AJAX et la ré-utilisation. Nous allons parcourir ici les principales nouveautés.
(Lire la suite…)

Bonjour,

Avec un plaisir certain, nous nous sommes replongés dans le livre blanc « Java Productivity Primer » pour le traduire en français. Cette version est une 1.1, mise au goût du jour par petites touches, réécrite parfois.
Nous espérons que vous y retrouverez le sel de la version anglaise. Pour rappel, ces 12 bonnes pratiques prônent usines de développement, automatisation des tâches, poste de travail mieux intégré : des principes issus de la vraie vie que nous mettons en oeuvre tous les jours chez nos clients. Au delà du gain de productivité pour les équipes, nous espérons aider les développeurs à vivre des journées plus passionnantes, et produire plus avec leurs têtes qu’avec leurs mains.
Ce livre blanc est noté « Primer » car il constitue pour de nombreuses équipes le B-A-BA du développement logiciel. Ces conseils sont connus des experts techniques ; cette vision intégrée pourra néanmoins les aider à communiquer leur connaissances et pourra les inspirer pour aller encore plus loin dans ces pratiques.
C’est la raison d’être de cette traduction : faciliter la diffusion de ces recommandations afin de lancer les discussions sur la productivité au sein des équipes de développement.

Pour télécharger le livre blanc : http://octo.com/com/com_Java-Productivity-Primer-livre-blanc-octo.html

Bonne lecture,

Les auteurs :

Arnaud « Maven » Héritier,
Benoît « Hitman » Lafontaine,
Guillaume « Plouf » Duquesnay,
Philippe « No Stress » Mougin.

Un lundi matin, de bonne heure (10h53), bureau « des développeurs », le téléphone sonne…
- Allo Jean ? c’est Michel de l’équipe des designers, je viens de t’envoyer la nouvelle maquette HTML pour le site institutionnel, tu peux le mettre à jour dans l’environnement de test pour une démo cette semaine ?
- Oui, pas de soucis, on se lance dans cette intégration avec mon équipe, je te tiens au jus, bonne journée !

Mercredi, fin de journée (17h48), même bureau
- Allo Michel, c’est Jean, on a une première version du site à te montrer, je t’envoie l’URL
- Mince, j’attendais à avoir le résultat plus rapidement pour le montrer à la direction, attend je regarde … Eh ! Mais il n’y a que la première page, je pensais avoir le site complet !
- Ecoute Michel, j’ai déjà sorti d’un autre projet 2 gars de l’équipe pour faire ça, on a fait de notre mieux pour l’intégrer au plus vite
- Mais, attend, c’est tout décalé et plus du tout conforme à ce que je t’avais envoyé
- … On a fait au mieux je te dis, nos composants ne permettaient pas de générer exactement les balises HTML que tu nous a données, on a même dû en customiser quelques uns et on est pas sûr des effets de bord sur nos pages actuelles
- Et mon CSS, pourquoi vous l’avez modifié ?
- Euh, ça c’est le framework qu’on utilise qui a ses propres classes, donc on a dû faire face à des conflits, d’ailleurs ça nous a bien pris 2H pour corriger ça !
- Mais pourtant c’est pas bien compliqué le HTML, j’en fais tous les jours et je ne suis pas développeur moi !
- Oui, mais de notre côté on doit passer du temps à intégrer ton HTML avec notre framework IHM…

Vous êtes-vous déjà retrouvé dans ce genre de situation ?
Vous vous prénommez Jean ou Michel et vous avez justement eu cette discussion ce matin même ?
Trouvez vous normal que ce que votre équipe de designer met une journée à réaliser, vous ne pouvez l’intégrer en moins de 3 jours ? Le problème viendrait-il seulement d’un mauvais choix de framework IHM ?
(Lire la suite…)

12 leçons à retenir

Retour d’expérience sur le projet NéoRetraite de GENERALI, vu par Benamar développeur et Olivier coach. Ce projet stratégique consistait à mettre en production une nouvelle version d’un contrat de retraite. Il s’est déroulé sur 1 an et a nécessité l’effort coordonné de 3 équipes, chacune en charge d’une application participant au projet. Au plus fort de l’activité 50 développeurs travaillaient en même temps sur le projet.

(Lire la suite…)