Agile & Offshore : rétrospective d'un projet à 1 Meuros

Transcription

1 Hubert GILLON Valtech Technology Agile & Offshore : rétrospective d'un projet à 1 Meuros octobre 07 Résumé Résumé De nombreux projets offshore sont en difficulté et ceci pour de multiples raisons: Quelle est donc la clef du succès dans un contexte ou l'offshore s'impose comme quasiment le seul modèle économique répondant à la loi du marché à savoir Low cost Time to market L'offshore agit comme un verre grossissant, amplifiant tous les défauts de la fabrique logicielle La trousse à pharmacie? Etre agile, Réagir rapidement, Faire simple, Se rapprocher du client le plus souvent possible, Chasser les bugs sans relâche et bien d'autres petites choses efficaces et simples à la fois. Encore fallait-il y penser." 1

2 Table des matières 1. INTRODUCTION 5 2. CONTEXTE DU PROJET Un projet pour quoi faire? Type de contrat et planning Contraintes du projet Grandes fonction de l application Use-cases de l application Principes d architecture Contraintes techniques ORGANISATION PROJET Modèle d organisation Processus de réalisation QUELS CHANGEMENTS POUR QUELS RESULTATS Au niveau gestion de projet Responsabilisation de l offshore Amélioration de la pratique SCRUM Résultats obtenus Functional Workshops Transfert de connaissance métier Processus de workshop Résultats obtenus Industrialisation du processus de traduction Contraintes liées à la traduction Changements réalisés Résultats obtenus Avancement contrôlé via les backlogs Définition des backlogs projet Avancement contrôlé Résultats obtenus Utilisation de Fibonacci Fibonacci Estimation de charge Ajustement de la charge Résultats obtenus Pilotage projet en transparence Calendrier initial Calendrier réel du projet Visibilité sur le suivi de projet

3 4.6.4 Résultats obtenus Marquage à la culotte de la qualité du code Acceptation régulière par le client Mise en place de reporting dédié au contrôle qualité Automatisation des tests Résultats obtenus Meilleure maîtrise des évolutions Difficultés concernant les évolutions Changements réalisés Résultats obtenus CONCLUSION 30 3

4 Liste des Figures Figure 1 : Macro planning... 6 Figure 2 : Domaines fonctionnels... 7 Figure 3 : Principe d architecture... 8 Figure 4 : Modèles offshore de Valtech... 9 Figure 5 : Modèle duoshore Figure 6 : Processus de développement utilisé Figure 7 : Organisation projet initiale Figure 8 : Extrait de l outil de gestion des demandes de traduction Figure 9 : Exemples de «Backlogs» Figure 10 : Exemple de «product burndown chart» Figure 11 : Exemple de release/ iteration burndown chart Figure 12 : Poids Fibonacci Figure 13 : Micro estimation d un échantillon d exigences Figure 14 : Facteurs environnementaux Figure 15 : Facteurs de complexité techniques Figure 16 : Tendance de la vélocité durant le projet Figure 17 : Calendrier initial Figure 18 : Calendrier réel du projet Figure 19 : Plate-forme collaborative Valtech Cockpit

5 1. Introduction De nombreux projets offshore sont en difficulté et ceci pour de multiples raisons: Organisation complexe, Problème de communication, Manque de visibilité interne vis à vis du client, Processus de développement onshore et offshore différents, Difficulté d'acquérir rapidement de réelles compétences métier, De comprendre les besoins réels du client Et bien d'autres causes. Quelle est donc la clef du succès dans un contexte ou l'offshore s'impose comme quasiment le seul modèle économique répondant à la loi du marché à savoir Low cost Time to market L'offshore agit comme un verre grossissant, amplifiant tous les défauts de la fabrique logicielle La trousse à pharmacie? Etre agile, Réagir rapidement, Faire simple, Se rapprocher du client le plus souvent possible, Chasser les bugs sans relâche, et bien d'autres petites choses efficaces et simples à la fois. Encore fallait-il y penser." 5

6 2. Contexte du projet 2.1 Un projet pour quoi faire? Difficile de choisir un projet significatif des pratiques agiles mises au point chez Valtech car chaque contexte est différent et chaque projet ajuste ses pratiques en fonction de ces propres contraintes. Le projet sur lequel nous allons discourir concerne un client œuvrant depuis de nombreuses années dans le domaine de l intérim et qui a souhaité rester anonyme malgré l intérêt évident de cette expérience. Ce client possède en France plus de 1000 agences, ce qui représente environ 5000 utilisateurs. L application cœur de métier que ce client a réalisée, avait été développée sur une technologie vieillissante, Forté pour ne pas la nommer, sur une période d environ 3 ans. Elle avait représenté approximativement 5000 hommes.jours de travail, ce qui constitue déjà un beau projet de développement spécifique. Malgré le fait que cette application Forté était très riche fonctionnellement et possédait des temps de réponse adéquats, ce client a souhaité confier à Valtech la réalisation d une nouvelle application plus moderne, avec pour objectif ni plus ni moins que sa refonte complète. La raison principale en était la «pérennisation des évolutions fonctionnelles futures» liée au fait que l éditeur de Forté ne supportait plus ses clients à partir de Type de contrat et planning Le projet était en mode forfait, avec un budget global approximatif de 1 million d euros. La durée initialement prévue s élevait à 19 mois au total, répartis de la façon suivante : 10 mois pour la phase de développement, 3 mois pour la phase de vérification d aptitude au bon fonctionnement (VABF) 3 mois pour la phase de vérification en service régulier (VSR) 3 mois pour la phase de garantie La figure suivante décrit macroscopiquement le planning initial du projet : Pré-requis Réalisation VABF - VSR Garantie Test de déploiement Sites pilotes Déploiement T0 Fin janvier 2006 Fin septembre 2006 Fin mars 2007 Fin juin 2007 Figure 1 : Macro planning 6

7 2.3 Contraintes du projet Les contraintes fixées par le client pour cette nouvelle application étaient : Ré-écriture Java de l application à iso fonctionnalités et à iso ergonomie Absence d impact sur les utilisateurs finals et sur l organisation en agence Grand niveau de qualité garantissant la non dégradation de son outil cœur de métier Compatibilité avec un déploiement progressif et massif de l application en agences 2.4 Grandes fonction de l application Les grandes fonctions de cette application sont : Recensement des besoins des clients en personnels intérimaires Qualification des intérimaires en termes de savoir faire Rapprochement des demandes clients et de l offre en intérimaires Les domaines fonctionnels couverts sont décrits dans le diagramme ci-dessous : Figure 2 : Domaines fonctionnels 2.5 Use-cases de l application Les principaux use-cases de l application sont : Use-cases fonctionnels Démarrer l application en s authentifiant Gérer le stock d annonces client en réservant des ressources (intérimaire ou candidat) 7

8 Passer et suivre une annonce Gérer des regroupements d agences Sélectionner plusieurs agences pour recherche ou statistique Sélectionner des rubriques et info à éditer sur un CV pour un client Editer de documents d inscription vierges à remplir à la main Pré-enregistrer un candidat Enregistrer les informations concernant un candidat ou intérimaire Proposer un candidat ou un intérimaire sur une ou plusieurs missions Mettre à jour le planning d un intérimaire (missions, indisponibilité ) Consulter le planning agence Réserver un intérimaire sur une mission d un client Use-case techniques Aides à la saisie d information dans les use-cases fonctionnels Rafraîchir les plannings des agences à partir du site central 2.6 Principes d architecture L architecture cible de l application était une architecture classique en couches, mais basée sur un framework métier développé par le client. Réécriture organisation en couches Présentation Applicatiion Business Access Data <<service>> UC simple <<service>> Access CICS <<trans. CICS>> <<écran>> UC <<composant>> <<service>> UC <<service>> Access <<service>> UC complexe <<service>> Business <<service>> Access DB <<table>> <<batch>> Synchro Couche <<stereotype>> classe Dépendance d utilisation Spécialise Figure 3 : Principe d architecture Le framework métier du client a évolué en même temps que les développements, ce qui a eu des impacts non négligeables sur le projet en termes de planning et de stratégie de test. En effet, à chaque livraison du framework, le projet l intégrait avec l application en développement et testait 8

9 cette intégration. Et lorsque des anomalies étaient identifiées, le sport du moment était d identifier leur origine : framework du client ou application Valtech? Cette problématique posait des problèmes contractuels et ne doit jamais être sous-estimée. Dans notre cas, il avait été convenu que les activités d intégration et de test du framework étaient dans le projet du fait de l apport fonctionnel du framework, qui réduisait ainsi la quantité de développement spécifique à réaliser. 2.7 Contraintes techniques Les contraintes techniques étaient principalement : L architecture cible en cours de définition Le développement du framework métier en parallèle de celui de l application La plate-forme cible d exécution standardisée pour tous les postes en agences La réutilisation du modèle physique de données existant et des transactions CICS A cela nous pouvons ajouter le fait que certains documents de spécifications, notamment d interface, étaient incomplets, ce qui a eu un impact négatif non négligeable sur la charge du projet. 3. Organisation projet 3.1 Modèle d organisation Valtech préconise différents modèles économiques permettant de répondre le plus finement possible aux objectifs stratégiques de ses clients. La figure suivante décrit ces modèles de façon très simple : Build-Operate-Transfer (BOT) Tous les avantages d un ODC Transfer immédiat des ressources Option de buy back plus tard à un prix prédéterminé Flexibilité d utilisation des ressources Valtech Centre offshore dédié Zone de travail dédiée Zone sécurisée VPN Serveurs dédiés Environnement personalisé Projet en Duoshore Externalisation de vos développements Analyse, acceptation & expertise : Valtech France TMA Notre centre de développement offshore à Bangalore, Inde Figure 4 : Modèles offshore de Valtech 9

10 Le modèle retenu dans le cadre de ce projet était le modèle duoshore. Il consiste à disposer de deux équipes distinctes en France proche du client, appelée «Front Office», et d une équipe distante située à Bangalore, appelée «Back Office». La figure suivante schématise ce modèle et récapitule sa structure. Client Front Front Office Office Équipe fonctionnelle/architecture/pilotage (Basée à Paris mais mobiles) Back Back Office Office Équipe usine de développement (Basée en Inde) Figure 5 : Modèle duoshore Dans notre cas, il a permis de bénéficier de la proximité des fonctionnels du client, tout en optimisant les coûts et la qualité des développements informatiques. Le Front Office était: Responsable de la définition de l architecture cible, Garant du scope fonctionnel du projet (rôle de «product owner» dans la méthode SCRUM), En charge des tests de recette (tests métier) 3.2 Processus de réalisation Valtech a fait le choix d adopter les méthodes agiles après avoir déployé les pratiques du process unifié (Unified Process) dans ses équipes. Cet historique a permis progressivement : D adopter dans ses projets les processus de développement itératifs et incrémentaux, D améliorer la gestion des risques en abordant prioritairement les aspects architecture et fonctions crtiques D industrialiser les processus d ingénierie tels que : o La gestion des anomalies, o La gestion des changements, o La gestion de projet et les reporting o La gestion des exigences o L intégration continue o Les builds journaliers o L automatisation des tests 10

11 La démarche Valtech intègre aujourd hui les bonnes pratiques des méthodes UP, SCRUM et XP. Unified Process apporte une rigueur dans la définition des activités d ingénierie classées par discipline, des livrables, des rôles et des responsabilités des différents acteurs projet. SCRUM apporte l agilité nécessaire à l accueil favorable de tout changement, à l ajustement rapide des objectifs projet et des pratiques, ainsi bonne collaboration et communication avec le client. Enfin, XP apporte une capacité à unir l effort de deux personnes lorsque des points durs, techniques ou fonctionnels, sont à résoudre rapidement pour le bien du projet. La figure suivante décrit le flow proposé par la méthode SCRUM et qui principalement basé sur des sprints rapides (appelés également itération), sur des backlogs produit et d itération, ainsi que sur le feedback du client et les décisions associées. Figure 6 : Processus de développement utilisé 4. Quels changements pour quels résultats 4.1 Au niveau gestion de projet Responsabilisation de l offshore Initialement, le mode duoshore tel que nous l avons essayé, nécessitait d avoir deux structures projet, une en France proche du client et une en Inde dans notre centre de développement, avec à leur tête un chef de projet. La figure suivante décrit l organisation mise en place en début de projet. 11

12 Engagement Manager Project Manager Paris Bangalore Functional Champion Architecte Équipe de de validation et et d intégration Project Manager Team Leaders Figure 7 : Organisation projet initiale Développeurs Équipe de de validation et et d intégration Responsable qualité Off-shore co-ordinator En Inde, l équipe est organisée en «Feature team» relativement autonomes avec à leur tête un «Team leader», développeur expérimenté. Chaque équipe est en charge du développement d un pan fonctionnel correspondant par exemple à un use-case ou à plusieurs use-cases d un même domaine fonctionnel. Après quelques mois d exercice, force était de constater certaines dérives : o Double pilotage avec divergence entre les informations onshore et offshore o Syndrome du «C est pas moi c est lui» o Communication concurrente : la France devait être le point de contact mais culturellement, les indiens sont très motivés à travailler en direct avec le client o Reportings projet pas toujours cohérents o Absence de vision unitaire du projet o Déresponsabilisation de l équipe en Inde Cet état de fait nous a amené à changer l organisation projet en prenant les décisions suivantes : 1) Un seul chef de projet indien, responsable de l ensemble des équipes 2) Un scrum master en France, seul interface client et animateur de l équipe onshore 3) Améliorer l agilité du projet en renforçant la collaboration France/ Inde de Valtech grâce à l application plus large de la méthode SCRUM 12

13 4.1.2 Amélioration de la pratique SCRUM Dans l application de SCRUM, nous avons donc appliqué : o Les scrum meetings et meta scrum chaque jour. Un scrum meeting est une réunion informelle de 10 mn permettant à chacun de répondre aux 3 questions suivantes : o Qu ai-je fait hier? o Que vais-je faire aujourd hui? o Quels sont les problèmes qui m empêchent d avancer? o Le planning game : exercice permettant à l équipe de s auto allouer les tâches du backlog de l itération à venir plutôt qu elles soient affectées d autorité par un chef de projet o Le bilan d itération : partage et acceptation des résultats de l itération terminée o Le retrospective meeting : exercice d auto critique du projet destinée à identifier les points qui fonctionnent bien et ceux à améliorer, afin de prendre de nouvelles orientations et ainsi d améliorer la productivité o Démonstration systématique au client à chaque livraison (MOA + MOE + équipe de recette) permettant de recueillir un feedback crucial pour le succès du projet Résultats obtenus Les résultats ont été spectaculaires et ont permis : o D améliorer la gestion de projet : o Vision unique du projet, consolidé en Inde o Reporting projet globaux et cohérents o Responsabilisation de l organisation Valtech en Inde à tous les niveaux o Meilleur suivi de l avancement et meilleure productivité o De favoriser les échanges entre le client et l Inde o Meilleure compréhension de la problématique offshore o Meilleure communication o Meilleure visibilité en direct o D améliorer le niveau de confiance du client en l offshore o Moins de suspicion et de négociation contractuelle o Acceptation du client de sa part de responsabilité dans les résultats du projet o D améliorer la compréhension du client sur les problèmes rencontrés o Changement de framework o Indisponibilité des serveurs du client o Interruption d accès aux transactions CICS 13

14 4.2 Functional Workshops Transfert de connaissance métier Le transfert de connaissance métier est critique pour un projet. En effet, la mauvaise compréhension ou interprétation du besoin du client par l équipe de réalisation, a pour conséquences la réalisation de la mauvaise application ou d une application non conforme à ses exigences logicielles. Ce point est exacerbé lorsque l équipe qui développe ne parle pas la même langue du client, est distante et très éloignée culturellement. Dans un tel contexte, le rôle du «Functional Champion» devient critique. Il s agit pour la personne jouant ce rôle : De s accaparer le fonctionnel en collaborant étroitement avec le client, Puis en interne d être le point de contact obligé de l équipe chaque fois qu il s agit d éclaircir des aspects fonctionnels, des règles de gestion métier ou tout autre exigence des spécifications logicielles. De s assurer que le périmètre fonctionnel du projet est bien respecté, surtout dans une approche forfaitaire Le transfert de connaissance métier est avantageusement réalisé par des workshops fonctionnels, qui rassemblent les différents acteurs autour d un même thème fonctionnel, devant être intégré au backlog d une prochaine itération Processus de workshop Dans la première phase du projet, le processus de transfert de connaissance se déroulait de la façon suivante : 1) Rédaction des spécifications par Valtech et validation par le client 2) Traduction des spécifications en anglais et vérification 3) Diffusion des spécifications validées à l équipe offshore (RFM) 4) Questions/ Réponses entre offshore et onshore, et entre client et onshore 5) Modifications des spécifications, rediffusion, traduction Ce processus ne garantissait pas une bonne qualité du transfert de connaissance à l équipe offshore car il ne permettait pas de s assurer de façon efficace de la bonne compréhension des spécifications. Le principe de poser des questions et d y répondre permet de lever certaines incompréhensions ou d éclaircir certains points obscurs, mais le fait d avoir compris un point de détail n implique pas automatiquement la bonne connaissance des exigences logicielles dans leur ensemble. C est la raison pour laquelle ce processus a été ajusté de la façon suivante : 1) Rédaction des spécifications par Valtech et validation par le client 2) Traduction des spécifications en anglais et vérification 3) Voyage en Inde du client (toutes les deux itérations) Présentation des spécifications par le client Questions/ Réponses 14

15 «Functional workshop» : l équipe indienne présente les spécifications au client Modifications des spécifications, rediffusion, traduction Dans ce processus, le client est en contact direct avec les équipes offshore ce qui constituait une nouveauté. Il présente lui-même les spécifications et répond aux questions posées jusqu à atteindre le même état qu à la fin du premier processus de transfert. Ensuite, nouvel élément, l équipe offshore organise un «Functional Workshop» au cours duquel elle présente sa compréhension des spécifications au client, qui par retour immédiat, corrige ou confirme les exigences logicielles. Cette validation par le client est la garantie qui était recherchée dans ce transfert de connaissance Résultats obtenus Les résultats de ce changement de processus concernent à la fois les livrables mais également les personnes. Concernant les livrables tout d abord : La qualité des spécifications s est améliorée avec une meilleure collaboration entre le client le «Functional champion» et les équipes de réalisation. L impact a été important par voix de conséquence sur la qualité du code et le nombre de défauts introduits dans le code a diminué de façon plus que significative. Le bilan des itérations en termes d atteinte des objectifs et donc de productivité, mais aussi de nombre d anomalies détectées par le client lors de ses tests de recette provisoire, a été extrêmement positif. Concernant les personnes : Le client n avait au paravent aucun contact avec les équipes indiennes, et il imaginait une équipe pas ou peu motivée, jamais assez productive et bien d autres choses peu objectives. Finalement après avoir travaillé avec l équipe offshore à clarifier, écouter, répondre aux questions et valider la compréhension de son besoin et des exigences associés, la vision du client s en est trouvée vraiment changée dans le bon sens du terme. Autre élément important, le client a finalement accepté plus facilement de se remettre en question, se rendant compte au travers des incompréhensions révélées, que sa communication ou la manière d écrire était parfois sujette à interprétation et pouvait engendrer de la «perte en ligne». 4.3 Industrialisation du processus de traduction Contraintes liées à la traduction Valtech dispose d un service de traduction sous la responsabilité d un traducteur français, situé à Bangalore dans notre centre de développement. Ce service a pour mission évidente de répondre dans les meilleurs délais, à des demandes de traduction provenant principalement des projets, mais également du management ou des commerciaux dans le cadre de contrat franco indiens ou de nouvelles offres de service. Le constat fait après quelques mois d activités est le suivant : 15

16 Les demandes arrivent au fil de l eau (ce qui est bien normal) mais les priorités de traduction varient énormément et remettent en cause de façon journalière les dates de livraison des documents traduits ou en cours de traduction Les temps de traduction ne sont pas toujours adaptés aux exigences des projets ou des actions d avant-vente. Par exemple, lorsqu un appel d offre français nécessite un chiffrage de l équipe indienne car la solution retenue est une solution offshore, les délais de traduction du cahier des charges (qui peut représenter plusieurs centaines de pages) ne sont pas compatibles de la date de remise de la réponse et la France se retrouve dans l obligation de faire elle-même son chiffrage. Se pose alors le problème du «commitment» sur les charges entre l organisation Valtech France et celle de Bangalore. La gestion des traducteurs est également un souci car le changement incessant de priorités rend le travail pénible avec de multiple interruptions qui : o Rallonge les temps de traduction o Baisse la productivité o Diminue la qualité de la traduction La visibilité sur l état d avancement des traductions est également un problème. Le client ou le chef de projet souhaite savoir quand tel ou tel document sera prêt, et ne peut obtenir aucune réponse fiable. Enfin, aucune mesure ne permet d améliorer le processus de traduction Changements réalisés Afin d améliorer le processus de traduction, Valtech a choisi de développer une solution basée sur un outil de workflow appelé Jira. Cette application accessible d internet est mise à disposition des clients potentiels du service de traduction afin qu ils puissent : Créer une nouvelle demande de traduction Consulter l état d avancement de leurs traductions Changer les priorités de traduction de leurs demandes de traduction Annuler une demande de traduction Cette application est gérée par le responsable du service de traduction qui : Vérifie la cohérence et la complétude des demandes, Puis les affecte aux traducteurs afin qu ils estiment le temps et la charge nécessaires, Puis après confirmation de sa part, que les documents soient traduits. Elle lui permet également d obtenir des statistiques et des indicateurs de productivité. Une fois traduits, le responsable du service vérifie la qualité des traductions puis les met à disposition des demandeurs. Un autre changement a consisté à convaincre le client de travailler en anglais principalement pour décrire les anomalies détectées et écrire les mails. Il a fini par accepté et petit à petit à souhaité élargir sa communication en anglais. 16

17 4.3.3 Résultats obtenus Le déploiement de ce nouvel outil de gestion des traductions a permis : La réduction du temps moyen de traduction Une meilleure productivité des traducteurs Une meilleure qualité de service avec un niveau de satisfaction accru Un meilleur suivi de l équipe de traduction permettant d anticiper l augmentation des demandes par du recrutement L extrait d écran suivant donne une petite idée du type d application qui est utilisé par Valtech aujourd hui, avec une interface à la «Jira». Figure 8 : Extrait de l outil de gestion des demandes de traduction 17

18 4.4 Avancement contrôlé via les backlogs Définition des backlogs projet La notion de backlog découle de l application de la méthode SCRUM qui est la méthode agile que Valtech a décidé d appliquer sur ses projets. Nous distinguons deux niveaux de backlog : 1 Product backlog décrivant le produit cible : use-cases et exigences : 2 niveaux d exigences 1 Iteration backlog décrivant les tâches à réaliser et allouées à l équipe : exigences du product backlog et tâches associées Les deux schémas suivants donnent une idée d une des façons qu à Valtech de gérer ces exigences et tâches, l autre étant basée sur l utilisation de la plate-forme Valtech Cockpit intégrant Jira. Figure 9 : Exemples de «Backlogs» Le product backlog identifie les capacités futures de l application et pour chacune, identifie les exigences de niveau 2 qui vont être suivies tout au long des développements en matière de : Taille logicielle Charge totale nécessaire à l implémentation des exigences Charges restant à consommer pour implémenter des exigences, itération par itération L itération backlog identifie pour chaque exigence de niveau 2, les tâches d ingénierie nécessaires pour leur implémentation, avec pour chaque tâche : L identité du propriétaire de la tâche (celui qui va la réaliser) L estimation de la charge de réalisation La charge en heures restant à consommer pour finir la tâche, jour par jour 18

19 4.4.2 Avancement contrôlé Le contrôle de l avancement projet est réalisé en utilisant les charges restant à consommé sur les tâches du projet et par consolidation sur les exigences. Ce contrôle est visualisé sous la forme de «burndown chart». C est un type de graphe fabriqué en prenant comme référence une ligne idéale de charges restant à consommer sur une base linéaire, sur laquelle on positionne la charge restante estimée. Pour le «product burndown chart», la fréquence de suivi est celle des itérations, tandis que pour l «iteration burndown chart», la fréquence est journalière. Figure 10 : Exemple de «product burndown chart» Figure 11 : Exemple de release/ iteration burndown chart 19

20 4.4.3 Résultats obtenus Le déploiement de SCRUM sur nos projets et plus particulièrement des «product» et «iteration backlogs» a permis : D améliorer le suivi du projet interne à Valtech D améliorer la visibilité du client sur le projet et son avancement réel à une fréquence soutenue (entre 2 à 6 semaines) 4.5 Utilisation de Fibonacci Fibonacci La suite de Fibonacci (1, 2, 3, 5, 8, 13, 21 ) est construite en ajoutant les deux précédents nombres. Cette suite peut être utilisée de manière à caractériser la taille logicielle de sousensemble d exigences. L affectation d un poids de 1 à une exigence signifie que l exigence est d une taille très faible. A contrario, une taille de 21 caractérise une exigence de taille ou de complexité très importante. Entre les deux, on positionne la taille des exigences de manière relative, les unes par rapport aux autres. Il est important dans ce type de démarche de comprendre que de dire que telle ou telle exigence est équivalente en taille d une exigence bien connue est une démarche plus précise que de faire une estimation en utilisant une méthode analytique ou basé sur une méthode de type «Use case point» ou «Function point». Le résultat obtenu est une taille de scope fonctionnel correspondant à un sous-ensemble des exigences du «product backlog», taille quantifiée en nombre de points Fibonacci Estimation de charge Une taille logicielle se traduit en charge exprimée par exemple en hommes.jours. Pour estimer la charge correspondant à une taille Fibonacci donnée, nous procédons par micro estimations sur des échantillons d exigences représentatifs et donc de taille différentes. Figure 12 : Poids Fibonacci Dans notre exemple, Ca, Cm et Cp ont un poids de 1 et représente un poids total de 3. L ensemble des exigences représente un poids total de 188. Le tableau ci-dessous est issu des micro estimations réalisées sur les échantillons Cp, Ci et Cr, Cp ayant respectivement des poids de 1, 5 et

21 Figure 13 : Micro estimation d un échantillon d exigences Dans notre exemple, la taille de l échantillon d exigences représente un poids de 19 tandis que la charge estimée globale s élève à : = 54 h.j. Nous calculons ensuite l effort moyen unitaire, à savoir : 54 h.j. / 19 = 2,84 h.j Cela signifie qu en moyenne un poids de 1 représente 2,84 h.j.. Il ne nous reste plus qu à calculer la charge correspondant à l ensemble des exigences qui nous intéressent de la façon suivante : Effort total non ajusté = 2,84 x 188 = 534,5 h.j. Si l objectif de note itération est de réaliser les exigences représentant 188 de poids Fibonacci, il faut que la taille de l équipe et la durée de l itération permettent d atteindre 534,5 h.j Ajustement de la charge L estimation de la charge n a pour l instant tenu compte ni de la taille, ni de la nature de l équipe, ni des caractéristiques de l application à développer. Le modèle d estimation COCOMO (COnstructive COst Model) prévoit d ajuster l estimation de charge en tenant compte de facteurs environnementaux et techniques ayant une influence non négligeable sur les charges à prévoir. Les facteurs environnementaux sont présentés dans le tableau ci-dessous. Ils permettent de calculer un facteur correctif appelé EF pour «Environment Factor».,% # 0' /.,-+ ' #! + "#! * ') ( $ %&' "#!! Figure 14 : Facteurs environnementaux 21

22 Les facteurs techniques sont présentés dans le tableau ci-dessous. Ils permettent de calculer un facteur correctif technique appelé TCF pour «Technical Complexity Factor».,%$, 0' /., 0, :)+ +,* ++,(, 395,! 8,,- "7!,,- "7!,.,6,- +," 2',.+, %-32.45,* 1 %- + Figure 15 : Facteurs de complexité techniques Enfin, la taille de l équipe a une influence notamment sur la charge de gestion de projet. Plus une équipe est importante, plus l effort pour la gérer est important. La règle que nous appliquons passe par le facteur de taille GO pour «Group Overhead», qui s identifie de la façon suivante : Entre 2 et 5 personnes : Group Overhead = 1,1 Entre 6 et 12 personnes : Group Overhead = 1,2 Plus de 12 personnes : Group Overhead = 1,3 Finalement le calcul de la charge globalement nécessaire pour réaliser le scope de taille Fibonacci 188 est : Effort ajusté = Effort non ajusté x EF x TCF x GO S il s avère que compte tenue de la taille de l équipe et de la durée de l itération, le scope fonctionnel identifié correspond à une charge trop importante, il faut diminuer le scope en supprimant certaines exigences des objectifs de l itération Résultats obtenus L utilisation systématique en fin d itération de la méthode de Fibonacci pour réajuster la taille et donc la charge nécessaire à la réalisation des objectifs d itération a rendu possible : L amélioration de la qualité et de la fiabilité des estimations Le respect du scope livré à chaque fin d itération sur la moitié du projet Le suivi de la vélocité de l équipe : taille en poids Fibonacci réalisé par l équipe sur chaque itération 22

23 La fixation d objectif de productivité à l équipe projet réaliste et atteignable car basé sur la réalité du projet et non sur des théories L amélioration de la planification projet, notamment de la prévision de la fin du projet La courbe suivante nous donne la tendance en termes de vélocité de l équipe au fur et à mesure des itérations. 1,00 0,90 0,80 Poids Fibonacci réalisé par h.j. 0,70 0,60 0,50 0,40 0,30 0,20 0,10 0,00 12/03/06 24/04/06 12/06/06 08/08/06 09/07/06 21/08/06 12/10/06 29/11/06 17/01/07 01/03/07 Temps Figure 16 : Tendance de la vélocité durant le projet Les diminutions sur les itérations 8 et 10 correspondent au fait que les charges prises en compte couvrent la correction des bugs résiduels avant recette de l application sur le périmètre initial du projet (itération 8), puis sur le périmètre de l application avec ses évolutions. La vélocité moyenne se situe aux environs de 0,4 points de Fibonacci par h.j., ce qui démontre que le projet a assez mal démarré, pour ensuite revenir à un rythme de progression intéressant. La raison principale en est que l architecture de l application a eu du mal à être stabilisée avec un framework métier qui a continué d évoluer de façon importante durant la première moitié du projet. 4.6 Pilotage projet en transparence Calendrier initial Le calendrier initial du projet est présenté dans le tableau ci-dessous. Durée prévue (mois) Date de début Date de fin Nb de releases Durée de release Nb d'itérations/ release Durée d'itération Phase de pré-requis 2 01/12/05 30/01/ mois 1 1 mois Phase de réalisation 8 01/02/06 29/09/ semaines 3 2 semaines Phase d'acceptation 6 01/10/06 30/03/ semaines 2 2 semaines Phase de garantie 3 02/04/07 29/06/ semaines 2 2 semaines Figure 17 : Calendrier initial La durée prévisionnelle du projet était de 19 mois dont : 23

24 2 mois de phase de pré-requis destinée à stabiliser le projet au niveau architecture, fonctionnel et processus, suivie de 8 mois de réalisation suivie de 6 mois de recette en deux phases distinctes de 3 mois chacune : Une phase de VABF (vérification d Aptitude au Bon Fonctionnement) Une phase de VSR (Vérification en Service Régulier) puis de 3 mois de garantie. La recette était prévue en deux Enfin, la durée envisagée pour les releases était de 6 semaines durant la réalisation et de 2 semaines durant la phase de recette Calendrier réel du projet Il est extrêmement prétentieux de croire que l on peux prédire et planifier de façon précise quelque projet que ce soit. Les événements qui ne manquent pas de survenir et qui ont une influence sur le déroulement du projet sont multiples et nombreux. Pour s en convaincre, il suffit de se reporter au calendrier réel du projet ci-dessous, et de comparer ces valeurs avec celles du calendrier prévisionnel. Durée réalisée (mois) Date de début Date de fin Nb de releases Durée de release Nb d'itérations/ release Durée d'itération Phase de pré-requis 2 01/12/05 30/01/ mois 1 1 mois Phase de réalisation 10 30/01/06 01/03/ semaines semaines Evolutions 1,5 02/03/07 10/04/ semaines semaines Phase d'acceptation 4 11/04/07 23/08/ semaines 1 2 semaines Phase de garantie 2 24/08/07 23/10/ semaines 1 2 semaines Figure 18 : Calendrier réel du projet Les zones en vert sont celles qui ont changées par rapport aux prévisions. Globalement le projet a duré environ 19 mois mais avec des différences importantes concernant essentiellement : Le nombre d itérations nécessaires à la réalisation de l application : 10 au lieu de 6 La durée des phases de recette et garantie : 6 mois au lieu de 9 mois La différence en nombre d itération s explique principalement par un retard du projet lié à un démarrage difficile, plus au fait qu une itération d évolution non prévue au départ ait été rajoutée. La différence de durée des phases de recettes et de garantie quant à elle s explique par la qualité de l application en fin de réalisation. En effet, le très faible nombre d anomalies mineures résiduelles en fin de réalisation a rendu possible le rattrapage du temps en réduisant de 3 mois la durée initialement prévue Visibilité sur le suivi de projet Valtech n est pas une société de service réalisant des projets mais un cabinet de conseil ayant dans sa stratégie de signer des partenariats dans la durée avec ses clients, et de les faire bénéficier de son centre de développement offshore situé à Bangalore en Inde. 24

25 Par conséquent, le fait de donner une visibilité totale sur ce qui se déroule sur les projets d un client est en faveur de cette collaboration étroite souhaitée par Valtech, et présente de multiples avantages : Visibilité sur la taille estimée de l application à chaque fin d itération, en prenant en compte les nouvelles évolutions et les éventuels changements de scope fonctionnel demandés par le client. Le client est partie prenant de toutes les décisions concernant le périmètre fonctionnel à livrer en cours de route ou à la fin du projet Visibilité sur le bilan de chaque itération. Le client sait exactement quel est le % du scope qui lui est livré pour recette provisoire, et connaît les raisons pour lesquelles certains pans fonctionnels peuvent ne pas l être. Visibilité sur la productivité de l équipe Valtech (onshore et offshore) et de sa tendance. Le client Valtech a également investi dans une plate-forme collaborative appelé Valtech Cockpit pour gérer plus efficacement les processus de ses projets offshore. Figure 19 : Plate-forme collaborative Valtech Cockpit Cette plate-forme intègre des outils open source et possède des fonctions spécifiques pour la gestion de projet. Jira et Confluence sont les deux outils phares de cette plate-forme. Ils permettent respectivement : La gestion des workflows du projet tels que les exigences, les risques, les anomalies, La mise à disposition des acteurs du projet (y compris le client) de l ensemble des informations projets issues des workflows, et ceci sous la forme de pages wiki accessibles via un simple accès Web. 25

26 4.6.4 Résultats obtenus Le fait de fournir une visibilité totale à son client oblige un fournisseur à être «irréprochable» ou du moins à faire montre de professionnalisme. Le client challenge les équipes et le management de projet de son fournisseur, et dans l esprit d une collaboration étroite, participe au succès du projet. Les résultats obtenus grâce à cet état d esprit et à la mise en œuvre obligée de certaines pratiques agiles peuvent se résumer à une meilleure qualité : Du suivi de l avancement des itérations et du projet Des estimations par l implication des équipes de développement Des informations projet entre le management et les équipes de développement De la communication sur les événements projet (baisse de productivité par exemple) Ces résultats se traduisent très logiquement par une meilleure confiance du client vis-à-vis de l offshore. Cette confiance favorise la compréhension de la problématique offshore par le client et facilite toutes les négociations notamment en termes de chiffrages d évolutions nouvelles. 4.7 Marquage à la culotte de la qualité du code Acceptation régulière par le client Le fait de respecter un cycle de vie logiciel basé sur des itérations courtes et des livraisons régulières au client évite de façon évidente l effet tunnel chef aux projets d un autre temps et qui se caractérisaient par un taux d échec supérieur à 50%. Le feedback régulier et à une fréquence de 4 à 6 semaines permet entre autres choses de : Vérifier la qualité de l application sur un scope restreint mais connu Corriger les pratiques qui s avèrent non payantes et de les améliorer De s assurer que les besoins du client sont bien compris et que l application finale répondra de façon certaine aux attentes des utilisateurs finals De fournir au client une visibilité lui permettant de collaborer en toute transparence avec son fournisseur, et donc dans un bon état d esprit Au départ du projet, le client n était pas supposé livrer ses cahiers de recette à Valtech. Après discussion il a néanmoins accepté de livrer les tests de recette provisoire au début de chaque itération et sur le scope de l itération. Cela a permis à Valtech : De faciliter la compréhension du besoin aux développeurs D exécuter ces tests avant chaque livraison au client Ce changement a été très bénéfique au projet et seule une itération a été refusée, et c est elle qui a motivé la livraison par le client de son cahier de recette. Après chaque livraison, le client disposait de 3 jours pour accepter la livraison. Cette acceptation était basée sur des critères qualité précis, notamment en termes De nombre d anomalies bloquantes, majeurs, mineures, De régression par rapport à la livraison précédente, 26

27 Non fermeture d anomalie normalement corrigées. Le client après ses tests d acceptation diffusait un PV d acceptation précisant si les critères étaient atteints et si il acceptait ou non la livraison, avec ou sans réserve. Ces critères draconiens ont obligé Valtech à améliorer la qualité de ses livraisons, à tester de plus en plus et ont par voix de conséquence réduit significativement le scope fonctionnel livré, baissant ainsi la productivité Mise en place de reporting dédié au contrôle qualité Les difficultés initiales d assurer un niveau de qualité compatible des objectifs fixés nous ont obligé à mettre en place des indicateurs projet dédiés au travers d un nouveau reporting appelé «QC report» pour «Quality Control report». Ce reporting permet de suivre : Les anomalies (bloquantes, majeures et mineures) pour l itération courante et précédente, ainsi que pour l application Les nombres et pourcentages suivants : Anomalies levées par le client Anomalies acceptées par Valtech (appelé «defect backlog») Anomalies fermées Anomalies internes levées par les testeurs Taux d anomalie rejetée après investigation Taux d automatisation des tests Les ressources de test (testeurs et moyens logiciel) Ce reporting réalisé tous les 15 jours a permis de suivre de façon objective et rigoureuse le «defect backlog» responsable de la perte de productivity initiale et de fixer de nouveaux objectifs en matière de qualité de code comme le % d automatisation ou le nombre d anomalies dans le «defect backlog» Automatisation des tests Pour lutter contre la baisse de productivité induite par les anomalies et leur résolution, nous avons décidé d automatiser au maximum les tests de non régression. Valtech a investi dans un framework de test basé sur Excel et fonctionnant avec Quick Test Pro (QTP) un outil de Mercury Interactive. Les avantages de ce framework sont : De faciliter le travail des testeurs en permettant de définir les données de test et résultats attendus dans une simple feuille Excel, Et d exécuter les tests sous QTP sans avoir à pré-enregistré des scripts de test via l IHM dont la durée de vie reste limitée, surtout dans le cas de projet agile. Cette automatisation de certains tests récurrents a permis : De rejouer à moindre coûts des tests destinés à identifier des régressions ou des disfonctionnement liés à des modifications de code 27

28 De détecter au plus tôt des régressions fonctionnelles, avant livraison de l application au client Ces modifications peuvent être dues à des corrections de bugs, à des évolutions ou à du «refactoring». le «Refactoring» est une activité systématique lorsque l on applique les méthodes agiles car on se concentre sur le bon fonctionnement, puis une fois établi, sur la qualité du code visà-vis des règles de programmation et standard applicable au code Résultats obtenus Concernant la qualité du code, les résultats obtenus sont : Définition hebdomadaire des priorités de correction d anomalie Optimisation des corrections d anomalies empêchant leur vieillissement Jamais plus de 2 itérations internes soit entre 3 et 5 semaines «Defect backlog» minimisé permettant d améliorer la productivité du projet Adéquation des ressources aux objectifs de test Concernant l automatisation des tests, les résultats se déclinent au niveau du projet mais également au niveau de Valtech, de la façon suivante : % d automatisation supérieur à 30% au lieu des 20% visés Capitalisation de l organisation Valtech dans la Tierce Recette Applicative (TRA) Diminution du nombre de tests détectés lors des acceptations de livraison par le client Augmentation du scope couvert par les itérations car moins d anomalies à corriger Capitalisation de Valtech grâce à LoFat Nouvelles offres et équipes expertes en test et dédiées à ce domaine 4.8 Meilleure maîtrise des évolutions Difficultés concernant les évolutions Plusieurs difficultés ont perturbées l équipe projet. 1) En premier lieu le contexte particulier du projet avec la refonte d une application existante à iso fonctionnalité. Se référer systématiquement à une application en production pour savoir si la spécification écrite y est conforme, n est pas une tâche aisée. Quand en plus les spécifications d interface brillent par leur absence, cela n arrange rien. Cet état de fait a coûté très cher à Valtech car les investigations incessantes pour savoir si une exigence de spécification est fausse ou non a pris beaucoup de temps, y compris au client. Ce type de contrat est de mon point de vue une bizarrerie qu il faut éviter de réitérer à l avenir car déduire les règles de gestion d une application en production sans en connaître ni l historique, ni le code, et partiellement le métier couvert est un travail long et fastidieux qu il est impossible d estimer de façon précise. 2) Autre difficulté, lorsque des évolutions sont demandées par le client sous forme de spécification, il est difficile d en déduire l impact sur l application en production tant que les spécifications n ont pas été rédigées et validées comme étant conformes à l application existante. 28

29 3) Autre difficulté liée au fait que l équipe projet se focalise par nature sur les développements à réaliser et sur le sprint en cours et ses objectifs. C est d ailleurs un des objectifs des méthodes agiles que de concentrer les efforts de l équipe sur le produit à livrer à court terme. Cette attitude a néanmoins un impact sur la maîtrise du périmètre fonctionnel car être agile signifie être ouvert aux changements ce qui s est traduit par une remontée incomplète des changements de périmètre. 4) Les indisponibilités de certaines ressources mises à disposition par le client ont également eu un impact négatif sur le projet. L équipe s en est accommodée sans formaliser les données précises les décrivant telles que date de début et de fin d indisponibilité, membres ou activités projet impactées. 5) Des évolutions demandées par le client ont été implémentées et livrées sans qu aucun accord n ait été préalablement convenu entre Valtech et le client. Difficile parfois de savoir à posteriori combien de temps on a réellement passé pour réaliser en totalité les actions liées à ces évolutions. De plus, les discussions à posteriori sur ces chiffrages sont presque toujours houleuses et nuisent considérablement aux bonnes relations. En conclusion, comme le mode forfaitaire implique la maîtrise contractuelle de ces changements, chaque écart par rapport au référentiel projet doit être identifié clairement, analysé, estimé pour donner ensuite lieu à un chiffrage en h.j., puis converti en commande. De la même façon, le non respect des engagements de mise à disposition de ressources se traduit par des impacts négatifs pour le projet et à ce titre, il doit être tracé et donner lieu à un chiffrage et une commande client. Le non respect de cette approche à motivé les changements réalisés Changements réalisés Un suivi hebdomadaire avec compte rendu a été mis en place en même temps que le suivi hebdomadaire des anomalies, mais pour traiter le cas des évolutions et des ressources indisponibles Une estimation systématique des impacts et évolutions a été menée par Valtech, qui s est traduite par une proposition de chiffrage dans le compte rendu de suivi de projet hebdomadaire. Le client après analyse de ces estimations a accepté et a formalisé sa décision d accepter dans ce même compte rendu. Enfin, lors de chaque comité de pilotage, une synthèse des évolutions et impacts négatifs précisant les estimations acceptées par le client a été présenté et acceptée avec pour conséquence, l émission d un bon de commande de régularisation contractuelle Résultats obtenus Le suivi rigoureux des évolutions et des impacts négatifs sur le projet a permis de réduire le temps de négociation au plus strict minimum, et de mieux respecter le périmètre contractuel du projet. Le client a également pris conscience que certains de ces actes pouvaient avoir une influence négative importante sur l équipe projet à l autre bout du monde, comme par exemple le fait de ne plus accéder au legacy qui dans le cas de ce projet, était la seule référence contractuelle. 29

30 5. Conclusion L intérêt du modèle économique de l offshore n est plus à démontrer car une fois établi la vitesse de croisière, les gains se situent entre 20% et 30% par rapport à une démarche projet classique. Néanmoins, un grands nombre de facteurs peuvent rendre cet investissement inefficace et même entraîner des pertes financières non négligeables, parmi lesquels : Projets outsourcés de taille trop faible Turnover des équipes offshore trop important Complexité du métier du client difficile à acquérir Instabilité des besoins du client mal maîtrisée Décalage de maturité entre le client et le fournisseur trop important Faiblesse de la communication et de la collaboration entre le client et le fournisseur Opacité des pratiques de l offshore Productivité des équipes offshore insuffisante Manque d expérience et d expertise du fournisseur entraînant de mauvaises attitudes ou décision Processus insuffisamment outillés Cycles de livraison trop importants Méthodes d estimations inadaptées et non fiables Par conséquent, seul un réel savoir faire en matière de gestion de projet, d ingénierie logiciel, de processus de développement agile associé également à une bonne connaissance des métiers du client et de la culture du pays, peut permettre d assurer un minimum de retour sur investissement à court terme, et une marge confortable sur le plus long terme. Valtech a su s organiser de manière à capitaliser sur ses projets et à améliorer ses pratiques projet de manière continue, ainsi que sa connaissance des métiers qui sont sa cible à savoir : Décliner les métiers cible de Valtech Distribution, e-commerce Aéronautique Banque, Finance, Assurance Voyages Valtech a acquis sur la durée, 10 ans déjà, dont 6 ans d offshore, une réelle maîtrise projet en ayant avec ses clients des succès de plus en plus fréquents. En effet, avec l offshore, le moindre grain de sable, le moindre courant d air peut avoir un impact amplifié et pénalisant pour le client, pour le fournisseur, bref pour le projet, avec des pertes financières à la clef. Valtech a également investi dans les méthodes agiles en faisant intervenir Craig Larman plusieurs mois sur le site de Bangalore. Il a pu adapter l organisation projet, l infrastructure et les pratiques 30