8 octobre 2009
Les méthodes agiles articulent le développement autour d’équipes dotées d’une grande autonomie technique – elles comprennent typiquement chacune au moins un architecte ou développeur très expérimenté, susceptible de structurer les choix de conception (nous avons dessiné le profil de cet architecte agile dans un article paru il y a quelques mois). Cette approche décentralisée des choix d’implémentation conduit naturellement à une interrogation : comment, dans ces conditions, garantir la consistance globale de l’architecture du système ?
Les méthodes agiles à proprement parler ne fournissent pas de solution clé en main dans ce domaine. C’est donc au travers du système de valeurs et des retours d’expérience que l’on cherchera à répondre à cette question.
Lire la suite de cet article »
8 septembre 2009
Certains d’entre vous connaissent probablement le phénomène du teamicide, décrit par Tom de Marco et Timothy Lister dans le fameux (et indispensable) Peopleware. Le teamicide, c’est un ensemble de pratiques managériales dont la conséquence directe et inéluctable est la destruction définitive de tout esprit d’équipe au sein des personnels concernés. Souvent pratiqué par inadvertance, le teamicide est particulièrement fréquent dans les projets informatiques, avec des résultats souvent désastreux pour ces projets – et une expérience navrante pour ceux qui y participent et chez qui les symptômes oscillent généralement entre dépression nerveuse et indifférence cynique.
Lire la suite de cet article »
4 février 2009
En matière de sous-traitance du développement logiciel, la pratique contractuelle la plus fréquente est celle dite du projet au forfait. La notion de forfait n’a, en principe, pas de rapport avec le processus de développement ou les pratiques d’ingénierie utilisée dans la réalisation du projet. Il s’agit simplement, dans l’esprit des contractants, de fixer les contours exacts de leur relation commerciale, et de définir leurs obligations mutuelles – en terme de coûts, de délais, de mode de paiement et de livraison. Dans un État de droit, et pour autant qu’elles ne soient pas abusives, ces dispositions contractuelles ont force de loi, et protègent efficacement les parties prenantes.
A bien y regarder cependant la neutralité du forfait vis à vis du processus de développement est moins évidente. Conçu historiquement pour satisfaire aux exigences de mise en concurrence des fournisseurs du Département de la Défense américain, le contrat au forfait est né du même substrat que le processus de développement en cascade – initialement décrit en 1970 par Winston W. Royce dans Managing the developpement of large software systems.
Ce processus de développement est aujourd’hui fortement remis en question, sous le constat empirique de son échec relatif, et sous l’impulsion des méthodes agiles. Je pense quant à moi que la « cascade » sera perçue dans quelques années comme l’aveuglement juvénile d’une industrie encore adolescente, à la recherche de son identité.
La question qui nous intéresse ici est de savoir si le projet au forfait survivra à la cascade. Autrement dit s’il est possible de mener au forfait un projet agile sous-traité. Certains le pensent, et certains intégrateurs proposent au demeurant de tels contrats. J’entends quant à moi démontrer ici que l’agilité et le forfait reposent sur des logiques financières radicalement antinomiques, qui les rendent difficilement conciliables.
Lire la suite de cet article »
15 janvier 2008
Lors d’une récente séance de brainstorming avec plusieurs de mes collègues français et hollandais, un intéressant concept a émergé : celui de l’Enterprise Spaghetti Bus. Je vous en fait part, je suis sûr que vous aurez l’occasion de le replacer…
Lire la suite de cet article »
10 janvier 2008
Lors des Rencontres Agiles, que nous avons co-organisées en décembre dernier – et qui, soit dit en passant, ont rencontré un fort et encourageant succès -, plusieurs personnes m’ont demandé si, pour démarrer un projet agile, il était préférable de choisir eXtreme Programming (XP) ou Scrum. La réponse est simple : il faut adopter les deux !
La complémentarité de Scrum et XP est communément admise. Scrum se positionne au niveau de la gestion et de l’organisation de projet là où XP se positionne au niveau des activités de développement. C’est la raison pour laquelle ces deux approches fonctionnent si bien ensemble : elles adressent des problématiques différentes et se complètent mutuellement.
Je vous propose, dans cet article, une présentation sommaire de Scrum et de la façon dont elle (il? non, allez, c’est plutôt une fille) s’articule avec eXtreme Programming… Bonne lecture !
Lire la suite de cet article »
5 décembre 2007
Le 18 décembre prochain, se tiendront à la Défense les premières Rencontres Agiles.
Il s’agit d’une conférence cosponsorisée par XEBIA, OCTO et SFEIR et dont le principe est d’une simplicité enfantine :
- Une salle de 200 places, inscription gratuite
- Une matinée complète, sans interruption
- Des sessions de 20 minutes pour aller rapidement à l’essentiel (no fluff, just stuff).
- Une sélection des meilleurs acteurs de l’Agile en France aujourd’hui.
Le programme se construit de manière incrémentale – il est publié au fur à mesure sur le site de la conférence. Au menu : une dizaine de sessions couvrant des pratiques, des retours d’expérience et des démonstrations d’outils.
Si vous voulez en savoir le maximum sur l’agilité aujourd’hui en France en une matinée, inscrivez-vous dés maintenant sur le site de la conférence !
29 novembre 2007
J’ai été, il y a peu, confronté à un problème de performances que l’on peut qualifier d’intéressant – dans la bouche d’un expert technique, ce mot a généralement tendance à provoquer une bouffée de panique chez les plus chevronnés des managers.
Je vous explique.
Le programme consiste à appliquer massivement un traitement identique à un volume important de données – bref, c’est un batch. Objectif opérationnel : assurer la capacité du système à traiter 50000 dossiers par heure.
L’architecture d’exécution de ce batch est relativement classique : un contrôleur est chargé d’obtenir auprès d’un service métier une liste de dossiers à traiter, de segmenter cette liste en lots, puis de soumettre les lots à un pool de threads qui vont réaliser les traitements en parallèle – chaque lot est traité dans une transaction distincte. Le traitement unitaire d’un dossier est relativement long, de l’ordre de 2 secondes ; les lots sont donc petits – 4 dossiers – pour limiter la durée des transactions.
Lire la suite de cet article »
22 novembre 2007
Dans une récente interview sur InfoQ, que nous évoquions il y a peu dans notre revue de presse, Jeff Sutherland fait état d’un ensemble de tests que la société Nokia applique aux processus de développement logiciel pour déterminer s’ils utilisent réellement une approche itérative et incrémentale, et plus spécifiquement s’ils adhèrent ou non à la méthodologie Scrum. Je ne reviendrai pas sur ces tests – Jeff les explique mieux que moi – mais j’aimerais attirer votre attention sur un phénomène que j’observe depuis quelque temps chez certains de nos clients : le wannabisme agile.
Lire la suite de cet article »
31 octobre 2007
L’offshore est devenu une réalité du développement logiciel. Néanmoins, un grand nombre de projets échouent dans ce domaine faute d’adopter une approche efficace de la distribution des équipes. Au-delà des avantages strictement financiers, l’off-shoring amène son lot de complexité et de risques, et ouvre des boulevards aux gaspillages de toute sorte.
Ce billet, librement traduit de mon excellent collègue indien Vikas Hazrati (
billet original sur TheServerSide), vise à présenter comment Xebia réussit à faire fonctionner les projets off-shore en s’appuyant sur les principes du Toyota Manufacturing Process, connu également sous le nom de « Lean ». Nous appelons cette méthodologie « Lean Agile Off-shoring ».
Davantage que des économies de bouts de chandelle, notre objectif, lorsque nous avons fondé notre filiale indienne, était de bénéficier de la somme de talents disponibles en Inde pour développer plus rapidement des logiciels de meilleure qualité. Pour gérer les projets, nous avons choisi d’adopter Scrum en raison des solides compétences que nous possédons dans ce domaine, et des succès que nous avons rencontrés dans la conduite de projet agiles avec Scrum. Les principes du « Toyota Way of Working » – que l’on peut au demeurant appliquer à tout type de développement logiciel – nous ont permis d’ajuster le modèle pour obtenir aujourd’hui un processus de développement mature et doté de mécanismes organiques d’amélioration perpétuelle – en un mot, Lean.
Le projet sur lequel cette méthodologie a été mise au point est la refonte d’un système de traitement automatisé appartenant à une administration centrale hollandaise. Le système traite certaines données salariales en provenance des employeurs et d’autres en provenance du système de taxation sur le revenu. Il valide ces données puis crée automatiquement la déclaration de revenu pour la période considérée. Le système traite 16 millions de transactions par mois, avec un débit d’environ 50 transactions par seconde.
L’équipe était composée de 14 personnes, 6 en Europe, 8 en Inde.
La suite présente un ensemble de principes qui ont émergé de cette expérience, et qui nous permettent aujourd’hui de mener des projets de toute taille avec un niveau de productivité et de qualité qui nous épate nous-mêmes !
Lire la suite de cet article »
4 octobre 2007
Nous vous proposons aujourd’hui la quatrième d’une série de cinq vidéos consacrées aux problèmes de performances des applications java / J2EE.
Nous y déroulons le top 10 des problèmes de performances en environnement java / J2EE en les illustrant par des cas concrets et en proposant pour chacun des mesures permettant de s’en prémunir.
Cette vidéo traite des numéros :
- 04 : Les bibliothèques tierces
- 03 : Mauvais usage de la concurrence
