• Les Directions Achats entendent réduire les coûts (charges d’analyse, charges de pilotage, charges de recette, charges d’exploitation) grâce notamment à une mutualisation des ressources du partenaire choisi, une optimisation de ses taux d’occupation et le déport du travail vers des régions (de France ou du monde) où la main d’œuvre est moins chère.
• Les Directions Informatiques souhaitent rendre l’informatique plus agile grâce à la capacité à mobiliser très rapidement des ressources pour un projet particulier, quitte pour cela à changer radicalement le rôle de la DSI.
• Les Directions Métiers souhaitent rationnaliser le contrat de services entre elles et l’IT (externalisée) grâce à la mise en place de KPI.
• Les Directions Générales souhaitent se recentrer sur le métier et externaliser ce qui peut être considéré comme une organisation de support.
• Les Directions Juridiques souhaitent se protéger des éventuels effets de bord liés au durcissement du Code du Travail en France vis-à-vis du marché des prestations informatiques (délit de marchandage, prêt de main d’œuvre illicite).

Eldorado ou mirage pour les directions achats, les écueils sont nombreux et les directions opérationnelles subissent de plein fouet les dysfonctionnements d’un modèle en devenir et qui n’apporte pas encore satisfaction voire dans certains cas, une très grande insatisfaction.

Les challenges d’un Centre de Services

Le bilan que l’on peut tirer de la mise en place des premiers centres de services informatiques est mitigé. En effet, de nombreux problèmes surviennent naturellement dans ce type de dispositif comme par exemple :

• Une exigence tarifaire ne permettant pas au partenaire informatique de fournir des compétences suffisantes eu égard aux exigences de qualité de son client.
• Une déperdition de la connaissance technique et fonctionnelle liée au changement incessant des affectations projet pour des raisons d’optimisation des ressources.
• Une inadéquation des KPI qui se révèlent, quoique parfaitement respectés, inefficaces vis-à-vis des exigences des donneurs d’ordre.
• Un Coût Total d’Acquisition in fine élevé à cause, notamment, de la surévaluation des tâches unitaires par le prestataire (destinée à préserver ou réinstaurer une marge décente) et au coût de la non qualité.
• Une démotivation des personnels des centres de services principalement à cause du manque d’une politique RH adéquate et à la banalisation de la fonction informatique.
• Une bureaucratisation liée à l’établissement de stratégies défensives destinées à protéger chacune des parties contre l’autre, toutes deux engluées dans un cadre contractuel trop rigide, les détournant des objectifs initialement poursuivis.

Face à ces enjeux, Xebia, propose une démarche différente, le centre de services agile dont nous vous parlerons très prochainement.

En deux mots, nous souhaitons proposer à nos clients, un centre de services qui s’inscrit dans la parfaite lignée de ce qui a fait le succès du constructeur Dell dans les années 90 : le modèle d’intégration virtuelle. Ses principes sont les suivants :

• Un pilotage orienté Produit.
• L’excellence des équipes.
• Des pratiques d’ingénierie éprouvées.
• Un développement incrémental.
• Une transparence absolue.
• Un partage des objectifs métier de nos clients.
• La mise en place de KPI pertinents et non falsifiables.
• Une mise en place opérationnelle graduée et contextuellement adaptée.

Je souhaite relater ici les propos qui se sont tenus lors de cet échange avec Ken.

Quant à mes impressions personnelles, je ne les partagerai pas avec vous car, en tant que Président du SUG, je souhaite rester neutre face aux différents courants de pensée, organismes certificateurs ou non, canal historique ou dissidents …

Le premier contact avec Ken est surprenant. Le co-fondateur de Scrum avec Jeff Sutherland, la figure légendaire de l’agilité est fatiguée, un peu diminuée physiquement également. Son accident de vélo a laissé des traces.

Ken m’a glissé à l’oreille : « c’est parce que je fais du vélo que j’ai failli mourir mais c’est également parce que je fais du vélo (et donc que je suis en forme physique) que j’ai pu m’en sortir. »

Derrière son visage marqué par les décalages horaires permanents, se cache un personnage qui n’a rien perdu de sa verve, de son dynamisme, de son humour, de ses convictions.

Ken est un passionné de développement logiciel, cela se voit.

Nous lui avions demandé de nous présenter Scrum.org dont il est le fondateur.

Première définition : Scrum.org a pour objectif de « préserver l’intégrité et la consistance de Scrum » (sic !).

Allons plus loin.

Scrum.org propose des tests en ligne (assessments) et des cours destinés aux praticiens Scrum.
Parmi les tests en ligne, notons l’arrivée de :

• Scrum Developer (SD), test destiné aux développeurs.
• Scrum Open, test en ligne destiné à évaluer le premier niveau de connaissances Scrum d’un utilisateur.
• Scrum Level II, le test pour les expérimentés.

Attention !: Pour réviser et réussir ces tests, il faudra avoir lu le Scrum Guide dont l’auteur est … Ken Schwaber.

A noter que Scrum n’est plus agnostique et que des cours Scrum Developer purement .net ou purement Java sont au programme.

La prochaine rencontre se fera avec Scott Ambler, le 15 mars grâce à IBM. Je donnerai des informations précises dans le cadre des activités du SUG.

Ayant passé toute ma carrière chez les éditeurs de logiciels, je faisais figure de « petit bleu » dans un monde nouveau, celui des prestations informatiques. J’y ai découvert souvent avec amusement, parfois avec effroi des pratiques que je ne connaissais pas.

A l’occasion de nos 5 ans, avec quelques Xebians, nous avons décidé de vous offrir une BD clin d’œil, illustrant quelques scènes de la vie quotidienne du Petit Monde Enchanté des SSII.

A la façon d’un calendrier de l’Avent, vous pourrez découvrir sur notre Blog, tous les jours (ouvrables) jusqu’à Noël, les dessins de GABS, le dessinateur du Nouvel Obs qui a travaillé pour Xebia à cette occasion.

Joyeuses fêtes.

Luc Legardeur
Président de Xebia

Notre client, CoachClub, premier site vidéo de Coaching Sportif personnalisé a accepté de témoigner ici sur son expérience du modèle Xebia ADDM (Agile Distributed Delivery Model). Voici quelques unes des réactions que nous avons pu collecter émanant de la part du Management :

« La maîtrise des technologies Java / J2EE et des architectures distribuées acquises par les consultants de Xebia était de ce point de vue un gage de réussite.
J’avais déjà pu expérimenter leur savoir faire quand j’étais Directeur Technique de voyages-sncf.com. »
Stéphane Coussement, DSI de CoachClub

« Il est absolument nécessaire d’instaurer des relations de pair et non de client / fournisseur entre les membres français et indiens de l’équipe. »
Olvier Bergeret, Responsable des développements chez CoachClub

« Les fonctionnalités attendues par le marketing de CoachClub peuvent évoluer très rapidement.
Seules les méthodes agiles nous garantissaient une réactivité suffisante. »
Aurélie Chomont Garbier, Directrice du Marketing de CoachClub

« Nous avons choisi pour construire notre site Web, le modèle Agile Offshore de Xebia qui nous garantit un prix très compétitif, une approche de développement par la valeur, des délais courts et une très grande qualité de code applicatif. »
Thierry Pépin, Président de CoachClub

Télécharger le témoignage complet de CoachClub.

Le Scrum User Group France, organe affilié à la SCRUM ALLIANCE, a mené, pendant deux mois, une enquête nationale, ouverte à tous, par l’intermédiaire de son site (www.frenchsug.org) afin de collecter des données qualitatives et quantitatives sur l’adoption en France des méthodes agiles les plus utilisées par ceux qui ont décidé d’emprunter le chemin de l’agilité.

Pour télécharger les résultats de cette enquête, suivez le lien suivant.

Suite au franc succès rencontré en France par les premiers projets Java/J2EE menés en Offshore Agile Distribué avec sa filiale indienne, Xebia a le plaisir d’annoncer la disponibilité de son modèle ADDM (Agile Distributed Delivery Model) en France.

Commentaire de Luc Legardeur, Président de Xebia :
« La crise incite les DSI a devoir faire autant ou plus qu’en 2008 avec moins de budget et cela en n’acceptant aucun compromis sur la qualité.
En nous appuyant sur l’expérience de nos collègues hollandais qui mènent depuis de nombreuses années des projets de ce type avec succès, nous avons décidé de travailler à l’implémentation de ce modèle en France. Nos expériences menées entre Xebia India et Xebia France étant très probantes, nous avons décidé de rendre disponible cette offre en France. Ce paradigme permet à nos clients de mener des projets en méthodes agiles tout en réduisant très sensiblement les coûts avec la garantie que l’Etat de l’Art des technologies Java/J2EE sera respecté. »

Pour en savoir plus sur Xebia ADDM, rendez-vous sur notre site web.

Avez-vous remarqué l’influence étonnante que peut avoir un Manager sur son équipe, sur une organisation, sur le comportement de ses collaborateurs, sur une culture d’entreprise et cela à quelque niveau hiérarchique que ce soit ?

L’équipier de chez Mac Donald sera d’une efficacité redoutable dans la préparation de votre Big Mac préféré car dans cette entreprise, le souci du Management est le respect du process. Aux antipodes de ce paradigme, l’ingénieur de développement de chez Google, lui, n’est pas contraint par les process, car au contraire, là bas, on pense que moins il y en a et plus la créativité des individus sera mise à contribution.

Réussir à transformer son organisation pour la rendre agile est donc avant tout, une question de mise en conformité en profondeur de l’état d’esprit collectif par une dynamique et volontaire impulsion managériale.
Le Boss doit donc mouiller sa chemise et vivre l’agilité de l’intérieur. Il doit avoir cela dans son code génétique (inné ou acquis), dans son ADN.

Justement, à propos d’ADN…vous rappelez vous les cours de Sciences Naturelles du collège ?

Un petit rappel. L’Acide Désoxyribonucléique (ADN) stocke l’information génétique ; information qui détermine le développement et le fonctionnement d’un organisme.

Pour faire simple, cette information génétique est transmise de génération en génération. Ce message (génétique) est transporté par l’ARNm (le messager) grâce à une vaste combinaison de nucléotides identifiés par des lettres T, A, G, C, …

Essayons maintenant d’établir un parallèle les lois de la génétique humaine et le fonctionnement d’une organisation.

Notre théorie consiste à affirmer que le fonctionnement d’une organisation est lui aussi, directement lié à l’ADN du Big Boss, à ses habitudes et à ses principes de Management.

Livrons nous donc à un exercice amusant : égrenons le chapelet de quelques principes Agiles (mais aussi quelques principes fondamentaux de Management) en empruntant le chemin de l’alphabet et mettons en face de chacun le bénéfice attendu. Vous suivez toujours ?

Sans vouloir jouer les apprentis sorciers ou les donneurs de leçons, nous pensons sincèrement que les quelques principes édictés ci-dessus sont propices à créer des organisations efficaces (des OGM -Organisations Génétiquement Modifiées- sous, nous en sommes sûrs, dans le cas présent, la bénédiction de José Bové).

Toute l’équipe Xebia vous présente ses meilleurs vœux pour 2009.

L’argent dette, monnaie virtuelle, créée à profusion par les banquiers, sous la bénédiction des états complices, a servi à accélérer artificiellement nos économies, à soutenir un rythme de croissance plus que déraisonnable. Tant pis, c’est fait. Nous devons désormais payer un lourd tribut à cette hallucination collective.

Le 2 janvier 2009, nous aurons donc tous la gueule de bois ; non pas à cause des abus d’alcool et de bonne chère dans lesquels nous ne pouvons nous empêcher de sombrer pendant la trêve des confiseurs mais plutôt parce que cette hypothétique crise dont nous ne voyons pas encore les effets (au point des fois de mettre en doute son existence) sera bel et bien là.
Par voie de conséquence, 2009 sera une année difficile pour les prestataires de services puisque nos clients seront tous contraints, nous le savons, à réduire leurs investissements informatiques.

Nous avons mangé notre pain blanc, nous allons manger notre pain noir. Les agapes finies, la période de vaches maigres va commencer.

Et bien tant mieux !

Tant mieux car c’est en période de manque que nous prenons les décisions les plus judicieuses, celles qui ne sont destinées qu’à assurer la survie de nos entreprises, c’est en période de difficultés que nous nous surpassons, que nous devenons créatifs, que nous sommes efficaces, que nous affûtons nos meilleures décisions.

En 2009, les DSI s’interrogeront certainement sur le meilleur moyen d’utiliser un budget réduit.
Elles stopperont, quand cela sera possible, les chantiers pharaoniques de type refonte en SOA à l’échelle de l’entreprise pour ne se concentrer que sur le ROI, le Quick Win, bref la suppression du gaspillage.

Dans ce contexte, les méthodes agiles que nous prônons tombent à point nommé. Basées sur le principe de travail itératif et incrémental, sur le principe de la priorisation par la valeur, sur la qualité plutôt que la quantité, elles seront, nous en sommes sûrs, le nouvel eldorado de l’ingénierie logicielle.
Nous avons d’ailleurs d’ores et déjà constaté un réel engouement pour les méthodes agiles (nous avons cette année, certifié 100 ScrumMasters, participé à 10 projets agiles et accueilli dans nos ateliers agiles du mercredi plusieurs dizaines d’entreprises).

Alors y aura-t-il une relation de cause à effet ? La crise sera t’elle le « compelling event » de l’adoption des méthodes agiles ?

Posons-nous la question : que pourront apporter Scrum et XP à nos clients en période de crise ?

Voici une liste (certainement incomplète), de 6 facteurs améliorant la rentabilité des projets informatique :

• La disparition des fonctionnalités inutiles grâce à une meilleure utilisation des efforts de développement, ce qui engendrera une économie substantielle (au moins 20%) dans les coûts des projets.
• La suppression de la documentation à outrance, finissant dans un placard électronique appelé référentiel, les réunions interminables, finalisées par le sacro-saint compte rendu de réunion qui ne donnera lieu à aucune décision ou bien les reporting fallacieux destinés à se donner l’illusion que tout est under-control.
• L’augmentation de la productivité des équipes de développement (par deux, par trois, et même par dix !) grâce à un nouveau paradigme de management basé sur la confiance, la motivation, l’amélioration continue (voir nos comparaisons de productivité de développement constatées dans le cadre du projet Prorail mené par Xebia).
• La baisse faramineuse des coûts de maintenance grâce à l’élimination de la dette technologique accumulée à cause du manque de compétence des équipes ; ce n’est d’ailleurs pas de leur faute, un développeur à 350-400 Euros est forcément un débutant, un quart d’architecte partagé entre plusieurs projets est forcément insuffisant.
• La suppression de la perte financière sèche liée à l’arrêt brutal de projets pour cause de manque de maîtrise des risques inhérents aux projets menés en cascade (le phénomène du puit sans fond si souvent constaté).
• L’avantage concurrentiel, traduit en monnaie sonnante et trébuchante, apporté à l’entreprise par un logiciel qui, pour une fois, sera conforme aux besoins des utilisateurs, qui sera capable d’intégrer au fil de l’eau les changements de contexte commercial, juridique ou légal plutôt que de les décaler à la prochaine release.

Nous nous devons de faire une nécessaire mise en garde : Les bénéfices (ou les droits) apportés par les méthodes agiles sont contrebalancés par de réels devoirs auxquels on ne peut pas se soustraire.
Ne pas les respecter revient à sombrer dans la Wanabisme agile, c’est-à-dire le pire des mondes.

Nous vous le promettons, 2009 sera une année très faste pour ceux, qui comme nous, croient fondamentalement au bien fondé intellectuel des méthodes agiles et qui les mettent en place, une année comme une autre, une année passionnante.

Oracle a finalement réussi à mettre la main sur BEA pour quelques 8,5 Milliards de dollars. Nous nous étions exprimés à ce sujet lors d’une interview d’Olivier RAFAL dans LMI, il y a quelques temps.
Nous étions hier encore à Convergence Day à l’écoute d’Alfred Chuang à Paris … Celui-ci n’avait rien laissé paraître. La question nous brûlait les lèvres, nous l’avons à maintes reprises posée à des personnes de BEA mais aucun d’entre nous ne se doutait à quelle point elle serait d’actualité 24 heures plus tard.

Autre nouvelle: Sun rachète MySQL pour un milliard de dollars. Celle là nous l’avions moins vu venir …

Je ne suis pas amené à conduire des projets informatiques et ma démarche n’était guidée que par mon souci d’accomplir au mieux ma mission de chef d’entreprise : « ce qui se dit bien se comprend bien« . Et bien croyez moi, ces deux jours sont à noter d’une croix sur mon agenda professionnel.
J’ai vécu là, à n’en point douter, un moment privilégié. Si j’étais épris de lyrisme, je qualifierais cette session de bouffée d’oxygène de bon sens, de régal de pragmatisme ou bien encore de bain de clairvoyance.

Jeff a pour sûr, influencé à jamais ma manière d’aborder la gestion des situations. Si j’osais je mettrais presque Jeff sur un pied d’égalité avec les auteurs anglo-saxons que tout manager ayant soif d’apprendre se doit de lire comme Jim Collins et Jack Welch.

Je ne vais pas ici tenter de restituer le contenu des 200 slides de la formation ni même de vous relater les anecdotes croustillantes que Jeff a bien voulu nous raconter sur les méfaits de la conduite de projet de manière classique, ce ne serait qu’une pâle copie, au demeurant forcément maladroite. En revanche je m’engage à rédiger une série de billets « Agile Tips ».

 
Pour ceux qui lisent ces quelques lignes et qui tout comme nous affectionnent particulièrement les Méthodes Agiles, Xebia organise avec Jeff une formation certifiante « Scrum Master » les 24 et 25 Mars 2008 à Paris (en anglais avec une assistance linguistique d’un Scrum Master certifié français de Xebia).
Nous laissons la primeur aux lecteurs « Scrum sensitive » de ce blog pendant deux semaines avant de faire l’annonce à la communauté de manière plus massive. Si vous souhaitez vous inscrire, envoyez un mail à info@xebia.fr. Le prix est de 1 850 Euros HT et le nombre de places est limité, alors à vos claviers …

Nous connaissons tous les principes de ces méthodes car elles nous semblent porteuses de qualité, de satisfaction client, de motivation pour les équipes de réalisation, de pragmatisme, de simplicité …

Disciplines (ou valeurs)

L’approche que nous proposons, mais encore une fois, ce n’est qu’un brouillon, consiste à évaluer 6 disciplines sous tendant les valeurs Agiles comme indiqué dans le diagramme de Kiviat ci-dessous (qui reprend une partie des propositions de Ross Pettit) :

• Gouvernance représente les moyens que nous mettons à la disposition de nos commanditaires d’avoir de la visibilité et du contrôle sur nos travaux (Burndown Chart, démos…).
• Excellence technique représente notre niveau de bonnes pratiques (intégration continue, TDD, revue de code et mise en place d’outils idoines).
• Spécifications représente notre capacité à bien collecter et formaliser les besoins des utilisateurs avec le Product Owner afin de professionnaliser la relation avec lui (Backlog du produit, granularité, explicité, gestion du changement de spécifications, …).
• Simplicité est l’évaluation de notre propension à simplifier tout ce qui peut l’être et en toute occasion.
• Collaboration représente tout ce qui touche à la motivation (cérémonies, outils de collaboration, Stand-up meetings, Face to Face meetings, retrospective, petites célébrations, …).
• Lean représente notre capacité à vouloir éliminer le gaspillage.

 
Niveaux de maturité (ou capacité d’éxecution du modèle Agile)
Pour chacun de ces thèmes, notons nous d’une note de 1 à 4 (0 étant inacceptable car non Agile).

• 1 signifie que le minimum est mis en place. Le dispositif repose en général sur le bon vouloir d’un petit nombre d’individus. Le processus est artisanal.
• 2 signifie qu’une certaine discipline est en place mais que la pratique reste encore immature, non reproductible systématiquement..
• 3 signifie que la discipline est mature, qu’elle est gérée et organisée.
• 4 signifie que l’équipe est organisée en vue d’une amélioration permanente et qu’elle a atteint les règles de l’Art.

 
Une fois ce bilan fait, sélectionnez celle(s) qui vous semble(nt) sujette(s) à forte progression et appliquez lui(leur) l’un des principes Agiles en vous posant 3 questions fondamentales ?

• Quel bénéfice Business tirera mon client d’une amélioration de cette discipline ?
• Comment faire pour s’améliorer ?
• Combien cela coûtera-t-il ?

Et prenez les bonnes décisions.

Nous sommes bien sûr preneurs de toute suggestion en vue d’améliorer cette tentative d’auto-évaluation.

Je ne revendique qu’une partie de la paternité de ce billet et remercie pour le reste, l’ensemble des auteurs dont j’ai utilisé les citations.

• Commençons par un peu d’humour
• Soyons plus sérieux
• Quelques idées reçues
• RAD veut dire Agile
• Un projet agile ne peut pas être mené au forfait
• Le paradigme des projets au forfait repose sur le besoin de réduire les risques ce qui semble impossible dans le cadre de projets Agiles
• Ils sont Agiles
• Les faits

Commençons par un peu d’humour

• Dans l’économie actuelle, vouloir élaborer des spécifications détaillées exhaustives dans le cadre d’un projet classique revient à utiliser un canon de la guerre de 1870, charger un obus, ajuster le tir le plus précisément possible et faire feu ! Mais malheureusement … sur une cible mouvante qui changera d’endroit alors que le tir lui ne peut plus être corrigé. Mener un projet agile, c’est tirer d’abord (privilégier l’action), mais avec un missile à tête chercheuse qui changera de direction (se configurer en mode adaptatif) car tout le monde est conscient que la cible va bouger (intégrer le changement).
• Au même titre que le boursicoteur malheureux rachètera des titres d’une société qu’il a déjà en portefeuille après une baisse brutale, pour réduire son prix moyen d’achat, une entreprise menant un projet au forfait en difficulté devra souvent continuer à injecter de l’argent pour sauver l’investissement initial pour finalement ne pas gagner grand-chose (voire tout perdre c’est-à-dire arrêter le projet).
• Le concept de « Two Pizzas » team est la seule manière de déterminer la taille maximale d’une équipe Agile : si pour la nourrir, il faut plus de 2 pizzas, c’est qu’elle doit être divisée en plusieurs équipes.
• Charles Darwin disait « Ce ne sont pas les espèces les plus fortes qui survivent, ni les plus intelligentes mais celles qui s’adaptent au changement« .

Soyons plus sérieux

• Classique vs Agile = Suivre un plan vs Répondre au changement.
• Classique vs Agile = Prédictif vs Adaptatif.
• Classique vs Agile = Négociations contractuelles vs Collaboration client/fournisseur.
• Classique vs Agile = Rédaction d’une documentation exhaustive souvent inutile vs Communication privilégiée.

Quelques idées reçues

RAD veut dire Agile

Faux !
L’Agilité inclue, entre autres mais pas uniquement, la notion d’excellence technique, la priorité donnée aux fonctionnalités porteuses de la plus grande valeur ajoutée métier, la simplicité dans les choix techniques, la motivation des équipes …

Un projet agile ne peut pas être mené au forfait

Faux !
La notion de forfait n’est pas antinomique du concept de projet Agile puisque les itérations sont de longueur déterminée. C’est l’arbitrage des fonctionnalités à inclure dans une itération donnée qui est l’instrument de la négociation et non pas l’enveloppe budgétaire.

Le paradigme des projets au forfait repose sur le besoin de réduire les risques ce qui semble impossible dans le cadre de projets Agiles

Faux !
Les méthodes Agiles reposent sur le principe du feedback utilisateur permanent et donc de la suppression de l’effet tunnel, générateur des plus grands risques pour les projets informatique.

Devriez vous être Agile ?

Si vous répondez non à l’une des trois questions suivantes, vous devriez vous intéresser aux méthodes agiles.
Dans le cadre du dernier projet informatique que vous avez commandé et qui vous a été livré,

• Avez-vous eu ce dont vous aviez besoin ?
• L’avez-vous eu dans les délais prévus ?
• Le coût total est-il raisonnable et conforme à vos attentes ?

Ils sont Agiles

L’une de ces sociétés est elle un symbole de réussite pour vous ? Microsoft, Oracle, Siemens, IBM, Philips, Yahoo, Xerox, Nokia, SAP, Google ?

Sachez que toutes utilisent des méthodes agiles pour mener leurs projets informatiques.

Le meilleur exemple d’entreprise agile est Toyota. Elle applique le principe du Lean Manufacturing (action, contrôle et adaptation, suppression des gaspillages) depuis les années 50 avec succès et est devenue en 2007 le premier constructeur mondial en CA. C’est aussi le constructeur automobile le plus rentable au monde.

Les faits

Dans un projet informatique mené de manière traditionnel, 45% des fonctionnalités du logiciel développé ne sont jamais utilisées, 19% ne le se sont que très rarement.

Dans le cadre d’une enquête menée par le Standish Group, il s’avère que 53% des projets menés de manière classique sont en difficulté, et 18% sont en échec.

Selon cette même enquête,les principaux facteurs d’échec des projet informatiques sont, par ordre d’importance :

1. Manque d’implication des utilisateurs finaux : 12,8 %
2. Spécifications incomplètes : 12,3 %
3. Changement de spécifications en cours de projet : 11,8 %
4. Faible implication du Management : 7,5 %
5. Manque de compétences des équipes : 7%
6. Manque de ressources : 6,4 %
7. Attentes irréalistes : 5,9 %
8. Objectifs flous : 5.3 %
9. Planning intenable : 4,3 %
10. Introduction de nouvelles technologies : 3,7%
11. Autres : 23 %

Les statistiques sur les chances de réussite des projets :

Un Appel d’Offre a été émis à destination des principaux intégrateurs de la place car selon la Direction des Achats c’est la seule manière de mener un projet informatique (Nous vous en parlions dans un précédent billet : « Eloge de la qualité« ). C’est, selon les mêmes spécialistes reconnus pour leurs compétences informatiques, un moyen de maîtriser les coûts et les délais, de partager le risque avec l’entreprise choisie et d’avoir un moyen de pression (car bien entendu de superbes clauses de pénalités de retard ont été prévues au contrat). L’intégrateur X est choisi. Pour une grande part, parce qu’il avait une proposition alléchante et savait accepter, sans piper mot, tous les principes de ce « contrat de confiance ». Le décor est planté : une atmosphère de sérénité, une confiance réciproque, l’implication des meilleurs profils de la société X, des desiderata d’utilisateurs pris en compte …

Vous vous en doutez, cette dernière phase est ironique.

Le chef de projet est sous tension, son entreprise lui a affecté 3 stagiaires et demi, un quart d’Architecte car, après d’âpres négociations, l’affaire gagnée se révèle moins rentable que prévu. Et en interne dans la Société X, un projet mal négocié aboutit à l’affectation de développeurs inexpérimentés (« You pay peanuts, you get monkeys », c’est bien connu). Les acheteurs du client se frottent les mains, ils ont bien mené leur barque. Le chef de projet est contraint de faire travailler tout le monde plus que de raison pour tenir des délais déraisonnables. Le mot « pénalité » se murmure discrètement puis fuse au grand jour dans toutes les réunions de projet, brandi comme la menace suprême. Les services juridiques des deux parties ressortent le contrat et s’y penchent avec beaucoup d’intérêt. Tout le monde passe d’ailleurs plus de temps à voir comment prendre l’autre partie à défaut que de véritablement essayer de résoudre les problèmes ensemble, en toute bonne foi. Et les utilisateurs dans tout ça ? Ils s’inquiètent. L’application qu’ils ont commandée est critique pour l’exercice de leur métier. La MOE leur explique qu’ils ont mal travaillé, que leurs spécifications sont trop floues, que leurs incessantes demandes de modifications sont inacceptables. Ils seraient même pointés du doigt comme deuxième responsable d’un tel chaos, après l’intégrateur, bien entendu.

Ce projet devient vite un puit sans fond. Le client est allé trop loin pour faire machine arrière. On ouvre la boîte de Pandore : les « avenants », le mot est enfin lâché à la grande satisfaction de tous car, in fine, c’est la seule manière de s’en sortir la tête haute des deux cotés. Mais attention, l’usage de tels coups de canif au contrat liant les deux parties doit se faire avec beaucoup de parcimonie bien entendu, car il doit juste permettre à l’intégrateur de réduire « un peu » son déficit sur le projet, là où vraiment on ne peut pas le prendre à défaut. Ce subterfuge lui permet, tout juste, de se maintenir dans un état financier végétatif sur le projet (pertes réduites ou au mieux rentabilité nulle).

Le paradigme du développement logiciel au forfait repose sur des principes (pour ne pas dire des valeurs) falsifiés, malhonnêtes, utopiques, désuets.

Les entreprises qui réussissent comme Google, Amazon et Microsoft, pour ne citer que les plus connues, l’ont compris depuis longtemps. Les méthodes agiles sont une alternative sérieuse. Les principes de ces méthodes sont les suivants :

• Compétence et motivation des équipes
  Le personnel mis à la disposition des projets est du niveau de séniorité nécessaire au développement d’applications modulaires, évolutives, performantes, documentées, intégrables et exploitables. Ce personnel s’engage sur le chiffrage et la réalisation de l’application.
• Développement itératif
  Le développement des projets est itératif. L’effet tunnel est supprimé. Les modules livrés sont immédiatement opérationnels.
• Un accueil favorable du changement
  La rédaction de spécifications détaillées complètes des mois avant sa livraison se révèle être une utopie. Dans ce contexte, l’acceptation du changement de priorités, de fonctionnalités fait partie intégrante du processus de développement agile de Xebia.
• Une collaboration étroite avec les utilisateurs
  L’implication forte du management et des utilisateurs tout au long du projet est organisée autour de feedbacks permanents orchestrés par des démonstrations systématiques qui permettent, à chaque itération, de valider le travail effectué et de définir les priorités de l’étape suivante.
• Une attention permanente à l’excellence technique
  L’hyperspécialisation Java/J2EE permet, dès le début du projet, de mettre en place les meilleures pratiques en vigueur dans l’industrie et cela à tous les niveaux du projet : Architecture conçue par des Architectes expérimentés, politique d’intégration continue, tests de performance, gestion des erreurs, exploitabilité des applications, choix technologiques pérennes, …

L’adoption massive des technologies J2EE par les entreprises a contraint les cellules d’exploitation à adresser rapidement (et sans aucune aide particulière) plusieurs défis majeurs :

• Gérer l’augmentation sensible du nombre d’applications en exploitation.
• Rendre un service compatible avec le niveau de criticité des applications utilisées.
• Prendre en charge des cycles de déploiement et de mise à jour toujours plus rapides.
• Appréhender une complexité inhérente à l’empilement de couches logicielles nombreuses, basées sur des technologies nouvelles.

Pourtant, nous constatons tous que nous -collectivement les acteurs de l’écosystème J2EE- n’avons pas donné les moyens aux départements Production de faire leur travail.

Les symptômes que nous rencontrons le plus fréquemment chez nos clients sont :

• Déploiements chaotiques nécessitant de trop nombreuses interventions humaines.
• Performances dégradées, fuites mémoires, dysfonctionnements inexplicables, …
• Gestion des incidents et procédures d’escalade à faire se pouffer de rire les vieux routards de l’exploitation.

Face à cette situation, il est urgent d’agir. Agir de deux manières :

1. En amont, repenser le travail des architectes et développeurs et mettre l’exploitabilité des applications au cœur des applications.
2. En aval -comme nous le proposons- analyser la maturité des organisations, outils et procédures vis-à-vis de l’administration J2EE.

Pour cela, il faut découper l’administration J2EE en disciplines (Alimentation, Architecture et Exploitation).

Chaque discipline sera ensuite décrite par ses activités unitaires. Par exemple : la gestion de versions, le contrôle qualité, le déploiement, l’architecture middleware, l’architecture de sécurité, l’architecture HD, la gestion des environnements, la gestion des incidents, la gestion de la capacité, la gestion de la disponibilité, la gestion de la continuité, gestion des SLA, …
Il reste enfin à évaluer la maturité de chacune d’entre elles (état initial, reproductible, géré ou optimisé) et établir un plan d’action pour passer d’un état de non maturité (état initial) à l’état d’après (reproductible) …

Ce travail est nécessaire. Nous intervenons souvent en pompiers pour régler des problèmes ponctuels comme la performance.

Notre devoir de conseil nous oblige donc à tirer la sonnette d’alarme sur ce sujet.

Nous pouvons aider nos clients à devenir plus matures et à administrer plus sereinement leurs plateformes J2EE.

Luc Legardeur, Président

Si vous le faîtes, il est probable que vous soyez contraint de changer de numéro de téléphone portable.

Vous recevrez en quelques heures, plusieurs dizaines d’appels de cabinets de recrutement et de sociétés (y compris de Xebia, si votre CV en vaut la peine).

Vous serez même éventuellement invité par les grands intégrateurs à des soirées de « Speed Dating CV » où, dans une ambiance pseudo décontractée, vous passerez du temps à découvrir votre futur employeur et à défendre votre CV en quelques minutes. L’opération séduction fonctionnera peut être pour vous.

Chez Xebia, nous avons une approche très classique du recrutement.

Nous recherchons des candidats compétents, dont la motivation est de rejoindre et de travailler avec des spécialistes de Java/J2EE par approche directe.

Notre originalité réside dans l’après entretien (c’est-à-dire le travail chez Xebia au quotidien) et nos spécificités sont les suivantes :

• Tous les salariés sont actionnaires
• Tous les salariés se retrouvent une fois par mois pour assister à nos sessions techniques d’échanges (appelés XKE- Xebia Knowledge Exchange).
• Tous les salariés bénéficient de notre base de connaissance corporate (et doivent y contribuer).
• Tous nos salariés se doivent de respecter nos valeurs (votées par un vote démocratique) qui sont :

• Absence de compromis sur la qualité.
• Partage de la connaissance.
• Indépendance de jugement et objectivité.
• Disponibilité.
• Simplicité et humilité.
• Loyauté.
• Ouverture d’esprit.
• Fiabilité.
• Honnêteté.
• Bon sens

En espérant vous rencontrer bientôt.

Luc Legardeur

Président

En période de crise, les personnes de ces entités ont construit des théories auxquelles malheureusement elles croient. Je vais tenter de lister ici un certain nombre de leurs idées reçues et d’y apporter une réponse que je pense intellectuellement honnête.

Idée reçue #1 : Un développeur est une ressource banale, codifiée par une grille de tarifs aux alentours de 300 Euros.

Il n’est pas rare aujourd’hui – mais heureusement le retournement du marché change le cours de l’histoire – de voir des responsables des achats considérer un développeur Java/J2EE comme une denrée interchangeable, une commodité banalisée qu’il suffit de remplacer par une autre pour continuer à faire avancer le projet au même titre d’un ouvrier sur une chaîne de montage (mon propos n’est pas péjoratif vis-à-vis des ouvriers, loin de là).

Mon point de vue : Rien ne ressemble moins à un développeur qu’un autre développeur.

• Certains sont bons d’autres mauvais.
• Certains développent 3 à 4 fois plus vite que d’autres.
• Certains écrivent des programmes de qualité, qu’il n’est pas nécessaire de reprendre, d’autres nécessiterons un refactoring très coûteux car les programmes qu’ils écrivent sont buggés, peu performants, non modulables, pas documentés (donc non maintenables)…

L’arithmétique est simple un développeur à 300 Euros coûte en fait 600 à 700 Euros par jour à une entreprise.

Idée reçue #2 : Le projet au forfait est le meilleur moyen de protéger son entreprise contre les dépassements budgétaires.

Le schéma classique est le suivant, nous le connaissons tous. Rédaction d’un cahier des charges, émission d’un appel d’offre au forfait, sélection du moins disant.

La réalité est toute autre: Il est utopique de geler des spécifications. Il n’est pas raisonnable de s’engager dans cette voie (81% des projets au forfait subissent des dépassements de délais, de budget, des réductions de périmètre fonctionnel ou des abandons purs et simples).

Un projet au forfait est une relation perdant/perdant.

Les grands intégrateurs, pour arriver à gagner des projets, tirent sur leurs prix, assignent des stagiaires, négocient dans la douleur des avenants, se rattrapent sur la TMA. Voila la réalité qu’est la nôtre, ou plutôt la vôtre car Xebia ne s’engagera pas dans cette voie. Notre fameuse exception culturelle française.

Chez Xebia, nous privilégions les projets agiles, nous accueillons favorablement le changement demandés par les utilisateurs, nous travaillons à leur coté, nous constituons des équipes projet solides avec de vrais développeurs (qui ne coûtent pas 300 Euros/jour), de vrais Architectes (qui ne coûtent pas 500 Euros/jour). Nos clients sont heureux. Leurs applications sont maintenables, évolutives, documentées. Et leur coût de la qualité – moins cher que les forfaits mais les paramètres à prendre en compte sont nombreux. En voici quelques uns :

• La durée de vie d’une application et de ses versions successives (coût de TMA)
• L’absence d’impacts financiers liés à une faible disponibilité des applications
• Le faible coût d’une reprise par un autre prestataire
• L’absence d’avenants « Coup de massue »
• Du temps passé pour obtenir le résultat et non des jours entiers en réunions passés à renégocier des contrats, des avenants, faire du reporting à outrance pour se protéger.