Article
Les futures villes chinoises de l’outsourcing
6/08/08
Une étude récente plaçait 3 villes chinoises dans le top 10 annuel des meilleures destinations offshore. Beijing en troisième position, puis Shanghai et Dalian qui arrive neuvième.
Cependant l’outsourcing en Chine ne se limite pas seulement à ces trois destinations et il faut compter avec une dizaines d’autres villes chinoises ayant un fort potentiel.
En terme de coûts, Beijing et Shanghai reste moins chère que Bangalore ou Mumbai mais commencent à atteindre le niveau des villes indiennes de « second tiers ». Il peut donc être intéressant de s’intéresser à des villes chinoises de « second ou third tiers ».
Chengdu
- Population : 11,030,000
- Accessibilité : Chengdu Shuangliu International Airport, 6eme aéroport de chine. (2hours 15 min de Beijing et Shanghai)
- Université :Sichuan University, Sichuan Normal University, Southwest Jiaotong University, University of Electronic Science and Technology of China, Southwestern University of Finance and Economics, Chengdu University of
Technology. - Entreprises présentes : HP, EDS, IBM, Siemens, Intel, NCS, Microsoft, Citigroup, HSBC, ABN AMRO, BNP Paribas, KPMG.
- Commentaire : Hébergeant un grand nombre de spécialistes du secteur IT, Chengdu c’est vu décerner le titre de « base for China’s service outsourcing business » par le ministère du commerce chinois. Sa zone spéciale de développement pour les nouvelles technologies a attiré un grand nombre d’entreprises. Intel est l’un des principaux investisseurs de la ville avec quelques usines et de nombreux immeubles.
Guangzhou
- Population : 6,000,000
- Accessibilité : New Baiyun International Airport (2h de Shanghai et 2h 40min de Beijing); Connecté à Hong Kong par trains, bus et ferries.
- Université : Sun Yat-sen University, South China University of Technology, Jinan University Guangdong, Guangzhou University.
- Entreprises présentes : EDS, Siemens, Unisys, Cap Gemini, Accenture, Atos Origin.
- Commentaire : Guanzhou est le centre économique d’une des régions commerciales et industrielles les plus importantes de Chine. Avec un investissement de $180 millions, la zone industrielle de pointe de Guangzhou sert les principales sociétés multinationales en Chine du sud. Le gouvernement local fournit une aide financière au développement de l’industrie du logiciel de $19 millions chaque année jusqu’en 2010.
Hangzhou
- Population : 6,400,000
- Accessibilité : Hangzhou Xiaoshan International Airport. (1h 15min de Beijing)
- Université :
- Entreprises présentes : Zhejiang University, Zhejiang University of Technology, Zhejiang University of Finance and Economics, Zhejiang Institute of Science and Technology.
- Commentaire : Selon un rapport récent réalisé par la banque mondiale, Hangzhou a le meilleur environnement d’investissement en Chine, basé sur des critères comme la stabilité politique, la politiques fiscales, le commerce et les investissements extérieurs, la qualité des infrastructures et des services financiers.
Jinan
- Population : 5,900,000
- Accessibilité : Jinan Yaoqiang International Airport. (55min de Beijing et 80 min de Shanghai)
- Université : Shandong University, Shandong Economic University, Shandong Finance Institute, Shandong University
- Entreprises présentes : HP, Siemens
- Commentaire :Le gouvernement local à fortement encouragé le développement d’une zone spéciale d’industrie du logiciel. La Qilu Software Zone est l’une des quatre zones spéciales d’industrie du logiciel présentent en Chine
Nanjing
- Population : 8,200,000
- Accessibilité : Nanjing Lukou International Airport. (1h 35min de Beijing)
- Université : Nanjing University, Southeast University, Hohai University, Nanjing University of Science and Technology, Nanjing University of Finance & Economics, Nanjing Normal University.
- Entreprises présentes : Siemens, Fujitsu, Sharp, Fiat, Iveco.
- Commentaire : Ces dernières années, Nanjing a fortement attiré l’attention des investisseurs étrangers. En moyenne, deux entreprises étrangères s’y implantent chaque jour. Le gouvernement a aidé le développement en y faisant construire des parcs industriels tels que Gaoxin, Xingang, Huagong and Jiangning. C’est le deuxième centre économique de l’Est de la Chine et la ville compte de nombreuses industries de pointe dans la chimie, la pétrochimie, l’électronique, l’industrie automobile, le travail du fer et de l’acier, le secteur agroalimentaire et les matériaux de construction. La ville compte le plus grand nombre de diplômés par habitant. Ainsi que le faisait observer un élu, « les salaires sont moins élevés qu’à Shanghai mais le nombre de diplômés y est deux fois plus élevé ». De plus la ville ne semble pas souffrir, contrairement à Shanghai, des problèmes très courants de la turn over des employés qui représentent également un coût pour l’entreprise.
Shenyang
- Population : 7,204,000
- Accessibilité : Shenyang Taoxian International Airport (1h 10min de Beijing; 2h de Shanghai).
- Université : Northeastern University, Shenyang Normal University, Liaoning University, Shenyang Ligong University, Shenyang University, Shenyang University of Technology, Shenyang Institute of Engineering.
- Entreprises présentes : Neusoft, BMW, Michelin Tire Company, South Korean Hana Bank, Siemens Power Transmission and Distribution Group (PTD), Emerson Electric Company.
- Commentaire : C’est là que se trouve le siège social de Neusoft, une des sociétés leader dans le logiciel et le service informatique chinois. Il y a 25.000 entreprises étrangères dans la ville. Le gouvernement local a créé un environnement exceptionnel d’investissement et se concentre sur les infrastructures de ville. Les grandes marques y sont, BASF, Bekaert, BMW, Coca Cola, GE, Johnson, Lear, Michelin et Toshiba.
Shenzhen
- Population : 6,000,000
- Accessibilité : Shenzhen Airport. (2h 35min de Beijing and 2h 10m de Shanghai)
- Université : Shenzhen University, Shenzhen Polytechnic, Shenzhen Institute of Information Technology.
- Entreprises présentes : IBM, HP, Siemens, Satyam, Foxconn.
- Commentaire : Shenzhen est situé à côté de Hong Kong et est bien connu pour son ouverture d’esprit et sa force d’innovation. Elle est parmi les villes chinoises du continent qui se placent très haut en termes de puissance économique et de présence de capitaux étrangers. Elle a également l’avantage d’avoir de très bonnes infrastructures et une main d’œuvre très bien formée. Certaines des entreprises chinoises les plus importantes du secteur High Tech y sont présentent (Huawei, ZTE). Le Software Park de Shenzhen tire le développement de l’industrie du logiciel vers le haut et est financièrement soutenu par le gouvernement local.
Tianjin
- Population : 10,240,000
- Accessibilité : Tianjin Binhai International Airport (ZBTJ). (1h 45 min de Shanghai)
- Université : Tianjin University, Nankai University, Hebei University of Technology, Tianjin Polytechnic University, Tianjin University of Commerce China, Tianjin University of Finance & Economics, Tianjin University of Science & Technology, Tianjin University of Technology.
- Entreprises présentes : HP, ACS, Siemens, IBM, AT&T, Texaco, General Motors, Motorolla.
- Commentaire : La Economic and Technological Development Area de Tianjin est connu comme l’une des plus compétitive de Chine. Ces dernières années la ville est devenu un centre d’investissements étrangers. Plus de 13.000 compagnies étrangères y sont établi, impliquant l’entrée de capitaux se montant à $30 milliards. Tianjin est également connu pour sa main d’œuvre bien formée et bon marché.
Wuhan
- Population : 9,100,000
- Accessibilité : Wuhan Tianhe International Airport. (1h 10min de Shanghai et 1h 20min de Beijing).
- Université : Wuhan University, Huazhong University of Science & Technology, Wuhan University of Technology, Hubei University of Technology.
- Entreprises présentes : HP, Siemens, EDS.
- Commentaire : Wuhan occupe un rôle important dans l’économie, les finances, les technologies de l’information et l’éducation en Chine. Elle est au 3 eme rang des villes chinoises en termes d’innovation et de maturité dans les sciences et la technologie. Les trois zones de développement et les quatre parcs de développement scientifique et technologique de la ville ont aidé à attirer un grand nombre d’investisseurs étrangers. Le support du gouvernement et l’énorme concentration de talents dans le secteur IT forment un climat favorable pour les investissements. Le nombre de diplômés dans le secteur des nouvelles technologies y représente à lui seul 50% du total des étudiants américains dans le même domaine.
Xian
- Population : 8,070,000
- Accessibilité : Xi’an Xianyang International Airport. (1h 25min de Beijing et 1h 35min de Gulin).
- Université : Chang’an University, Xi’an Technological University, Northwest A&F University, Northwest University China, Northwestern Polytechnical University, Shaanxi University of Technology, Xi’an International Studies University, Xi’an Jiaotong University, Xi’an Shiyou University.
- Entreprises présentes : Siemens, Intel, Fujitsu, Philips, Sybase, Nortel, Thoughtworks, Agilent, Kingdee, NEC, Huawei.
- Commentaire : La ville a développé, et ce en l’espace d’un rien de temps, son industrie de hautes technologies et d’ingénierie et peut se vanter d’abriter cinq universités classées parmi les 100 premières de Chine. Ces dernières années le gouvernement local a fortement investi en infrastructure permettant à la ville d’attirer des ressources qualifiées et de recevoir de nombreux investissements étrangers. Xian est connu pour sa zone de développement industrielle High Tech et son software park qui ont fait de la ville le principal lieu de développement des technologies de l’information en chine.
Création d’une entreprise en Chine
16/06/08
En Chine, les autorités font clairement la différence entre les entreprises chinoises et les entreprises étrangères. Il existe trois types de structure juridique permettant à des étrangers d’investir en Chine, que ce soit seul ou bien avec un partenaire chinois.
Pour ce qui est de la fiscalité, depuis 2007, un taux unique d’imposition 25% est fixé sur les revenus des entreprises chinoises et étrangères.
Le bureau représentatif.
C’est une extension d’une société déjà existante. Il ne constitue pas une entité juridique et est essentiellement une structure de liaison avec le siège situé dans le pays d’origine. Le chef du bureau de représentation en Chine est légalement responsable des activités de la structure. Il n’est pas nécessaire que cette personne réside en Chine.
C’est le statut le moins onéreux, le plus flexible et le plus simple d’un point de vue administratif. Il permet de limiter au maximum les risques pour une société étrangère qui souhaite dans un premier temps tester le potentiel du marché chinois pour ses activités.
Les activités d’un bureau de représentation sont limitées à des activités de liaison, de promotion de produits ou services, d’échange de technologie et de développement de contacts avec des clients. Il peut également servir à la supervision des activités de la société mère en Chine.
Côté inconvénient, le bureau de représentation n’a aucune relation légale à l’égard des tiers à l’entreprise principale avec lesquels il n’a pas le pouvoir de contracter, de conclure de contrats, donc il est un simple relais de l’entreprise. Il ne permet donc pas d’émettre des factures à des clients présents en Chine.
Autre point il faudra nécessairement passer par une agence tiers (type FESCO) pour signer un contrat de travail avec un chinois. Vous pouvez effectué votre recrutement vous même mais il faudra forcement passer par une de ces agences.
Dernier point pour ouvrir une bureau représentatif, il est nécessaire de louer un locale dans un building de grade A, aux alentours de 500 euros par mois pour 20/30 m2 à Shanghai.
Les sociétés à capitaux 100% étranger.
WOFE est l’abréviation anglaise désignant une société étrangère détenue à 100% par un ou plusieurs actionnaires étrangers en Chine (« Wholly Owned Foreign Enterprise« ).
Les activités d’une WOFE peuvent être les suivantes :
- Commerce, distribution, trading import-export : Activités à caractère purement commercial. Ce type d’entreprise est également appelé FICE (« Foreign Invested Commercial Enterprises »).
- Production et assemblage : Achat local et importation pour revente locale et/ou export.
- Services et Consulting : Services aux entreprises ou aux particuliers.
Ce statut peut garantir une autonomie de gestion et évite d’avoir un partenaire chinois. Elles sont organisées sous forme de sociétés à responsabilité limitée. Le capital social minimum est fixé par la législation suivant l’activité de l’entreprise.
Les WFOE et FICE peuvent avoir un investisseur qui est une personne morale ou physique.
Leur création doit d’abord être soumise à une commission d’approbation locale des investissements étrangers. Pour commencer il faut un bail attestant de la location d’un local. C’est un pré requis nécessaire à toutes demandes. Ensuite il faut rédiger un projet d’investissement (étude de faisabilité) ainsi qu’exigé par l’administration. Cette étude contient des informations relatives à l’investisseur, à ce qu’il souhaite faire en Chine et au budget qu’il prévoit d’allouer a son investissement. Une fois votre enregistrement auprès de l’administration du Commerce accomplie et votre licence délivrée, vous devez alors vous enregistrer auprès des autres administrations (affaires sociales, fiscales, douanières, statistiques, …).
Le capital d’une WFOE doit être payé obligatoirement en devises étrangères (USD, EUR…) et en provenance de l’étranger (les échéances de son versement se négocient aussi avec les zones ou districts de tutelle).
Le rapatriement des bénéfices est bien sur autorisé, en vertu de la loi chinoise sur les mesures applicables aux investissements étrangers.
Les entreprises à investissements étrangers (les joint-ventures)
Ces entreprises sont détenues à la fois par des étrangers et des chinois. Même si dans le droit chinois le montant minimum du capital n’est pas fixé, dans la pratique il tourne autour du million de yuans.
La loi chinoise oblige les investisseurs étrangers en partenariat avec des investisseurs chinois d’investir dans des sociétés commerciales ou dans des sociétés de droit commun chinois appelées sociétés à responsabilité limitée et société par action.
Deux types de joint ventures sont possibles
- Le joint-venture à capitaux mixtes : la participation des étrangers dans ces entreprises n’est pas plafonnée et les bénéfices redistribués proportionnellement à l’apport initial de chacun. La part étrangère doit être d’au moins 25% du capital de la société.
- Le joint-venture contractuel : toutes les modalités de répartition des bénéfices et la part sont déterminées par contrat.
Création d’une société chinoise
C’est la solution la moins onéreuse et la plus simple en termes de formalités administratives. Mais c’est aussi la plus risqué car vous devez pour cela mettre la société au nom d’un(e) chinois(e) (ou d’une société chinoise partenaire).
Vous aurez pour votre part un statut d’employé (quel que soit votre titre) de cette société. Vous n’avez en votre nom propre aucun contrôle directe sur cette société.
Le capital de cette société chinoise est payable localement, en Rmb, et le siège de cette société étant bien sur en Chine, le rapatriement des bénéfices à l’étranger n’est pas envisageable en tant que tel puisqu’une société chinoise n’est pas censée avoir de maison mère à l’étranger.
L’agilité en Chine, retour d’expérience SCRUM
12/05/08
L’introduction des méthodes agiles dans une organisation cause souvent des problèmes d’adaptation à cause de la différence culturelle qu’elles amènent. La manière de fonctionner la plus répandu est que les séniors prennent les décisions et que les moins expérimenté les exécutent. Pour que les méthodes agiles fonctionnent il faut donner plus d’autonomie aux exécutants.
Ce problème peut être encore amplifié en Asie, du fait que la culture asiatique renforce le respect du supérieur.
InfoQ qui possède une structure en Chine a récemment réalisé une étude sur l’adoption de SCRUM en chine.
Une traduction libre de cette étude est présentée ci-dessous.
Les personnes interrogées et leurs entreprises sont présentées ci-dessous. Pour le respect des sociétés leurs vrais noms n’ont pas été utilisés.
- Julie – Une célèbre entreprise de l’internet – Réussit
- Kaverjody – Un célèbre éditeur de logiciel – Réussit
- David – Une célèbre entreprise de l’internet – Echec
- Alex – Nibirutech, une start-up – Réussit
- Fiona – Une start-up – Echec
Les cinq questions suivantes ont été posées à ces cinq entreprises installées en Chine utilisant SCRUM.
Pourquoi avez-vous utilisé SCRUM sur votre projet ?
Julie :
Les exigences changeaient trop rapidement, la feuille de route n’était pas claire, nous devions améliorer l’efficacité et la communication, et le service commercial devait pouvoir obtenir des résultats le plus tôt possible.
Kaverjody :
En raison des défauts dans le modèle de développement en cascade nous ne pouvions pas apporter des améliorations sans modifier la méthode de développement. Les top-managers ont pris la décision d’utiliser SCRUM pour résoudre les problèmes, par exemple le coût de maintenance très élevé, la livraison de nouvelle version nous prenais beaucoup de temps, etc
Alex :
La première fois que j’ai entendu parler de la notion d’agilité c’est lorsque j’ai rejoint NibiruTech en octobre 2007. À cette époque, la pratique agile que nous utilisions le plus était la réunion quotidienne. Je n’avais aucune idée quant à l’effet d’une telle réunion. J’ai essayé de comprendre et j’ai ainsi découvert SCRUM.
Comme beaucoup de start-up, nous n’avions pas beaucoup d’expérience dans les méthodes de gestion. Nous avons écrit notre propre méthode de gestion et l’avons utilisé conjointement avec TRAC. SCRUM m’a vraiment impressionné, j’ai donc décidé de populariser SCRUM au sein de notre entreprise.
Comment avez-vous adopter SCRUM, et pourquoi ?
Julie :
Nous n’utilisons pas du pur SCRUM. Au lieu de cela nous l’avons mélanger avec de nombreuses pratiques agiles, comme des pratiques d’XP et en partant de la rétrospectives SCRUM que nous avons adapté à nos exigences, pour finalement trouver notre propre modèle. Par exemple, si dans une rétrospective, nous constatons que nous devons améliorer la revue de code, alors lors du sprint suivant de nouveaux mécanismes de revue sont introduits.
Nous somme partie du bas pour aller vers le haut. Tout d’abord, nous n’avons fait des expériences locales, avec une petite portée, et ensuite nous l’avons étendu de plus en plus largement.
Nous avons également fait des améliorations au processus lors de l’adoption:
- Mars à Juin 2006 – utilisé dans une équipe d’environ 8 personnes.
- Juin 2006 à Décembre 2007 – utilisé dans trois équipes, environ de 25 personnes.
- Décembre 2007 à Janvier 2008 – Utilisé dans un département, 6 équipes, environ 50 personnes.
- Janvier 2008 à maintenant – Utilisé dans toutes les équipes.
Kaverjody :
Les top-managers ont pris la décision d’utiliser SCRUM dans l’entreprise.
Alex :
Je n’ai pas réfléchir à la manière d’adopter SCRUM à ce moment-là, je partageait uniquement les informations entre le CEO et mes coéquipiers.
A la question : « Comment avez-vous décider des mesures à prendre au cours de l’expérience ? Est-ce que vous vous êtes concentré sur les problèmes existants et choisis des pratiques agiles appropriées pour les résoudre ? Ou une autre manière de procéder ?
Julie :
En fait, nous n’utilisions pas le mot « SCRUM » au début. Nous avons discuté avec les commerciaux sur la date de livraison, nous sommes tombés d’accord sur une livraison tous les mois. La gestion du projet se faisait pendant la réunion quotidienne du matin et les améliorations étaient décidées pendant la réunion de conclusion du d’une itération. La rétrospective de la production et celle de l’équipe étaient incluses dans cette réunion de conclusion. Le chef de produit expliquait la situation actuelle, et tous les membres de l’équipe discutaient de nos réalisations, des défis et de nos lacunes. Pour la réunion de planification, nous avons suivi SCRUM depuis le début. MS Project n’étant pas approprié pour un petit projet, nous avons d’abord utilisé une feuille de calcul Excel SCRUM, puis ensuite nous somme passé à Xplanner.
Après quelques mois, nous avons réunis tout le monde pour une réunion de partage de connaissances sur les méthodes agiles. Il y a été présenté toutes les pratiques que nous avions utilisées, et expliqué la philosophie de l’agilité, d’XP et de SCRUM. Puis tout le monde s’est regardé et nous nous sommes aperçu que nous avions utilisé SCRUM pendant ces derniers mois.
Notre succès a été également confirmé par les managers, et nous avons été autorisés à partager notre expérience avec d’autres équipes. Nous avons alors choisi certaines équipes comme « pilotes ». Du fait que les développeurs pouvaient passé d’une équipe à une autre, cela augmentait les coûts de gestion si une équipe utilisait MS Project et un autre XPlanner. Nous avons donc utilisé SCRUM dans toute l’entreprise.
Quel est le plus gros problème rencontré lors de l’adoption, et comment l’avez-vous résolu ?
Julie :
Tout d’abord, nous avions besoin du soutien des dirigeants. Et puis, de dire la vérité, l’adoption de SCRUM est assez facile, beaucoup plus facile que CMMI.
Le plus difficile, c’est que vous devez résoudre les problèmes révélés dans votre processus, tels que:
- « Nous n’avions pas d’exigences claires, ce qui à un coût élevé en communication sur les dernières étapes. Nous passons trop de temps à discuter avec le chef de produit encore et encore. »
- « Cycle de livraison est trop long : notre Sprint est de 3 ou 4 semaines, mais le chef de produit souhaite que nous livrions deux versions par semaine. »
- « Nous ne pouvions pas maîtriser les besoins et le produit en nous basant sur les caractéristiques de SCRUM« .
- « La date de livraison était fixé par les commerciaux, nous n’avons pas le temps de faire des tests unitaires, ni code de la revue de code. »
- « Nous ne pouvions pas voir clairement les goulets d’étranglement entre les tâches, ou la façon de coordonner tout le monde« .
- « Nous avions besoin d’au moins une semaine pour analyser les données après le déploiement, il est impossible de conclure sur des amélioration à faire juste après le sprint actuel.«
- « Le rythme de développement était trop rapide, nous n’avons pas assez de temps pour s’arrêter et faire une bonne rétrospective. L’exigence historique n’est pas pleinement utilisé. »
Kaverjody :
Pour moi, la plus grande difficulté est les malentendus autour de l’agilité rencontrés parmi mes collègues. Ils pouvaient voir les outils et les pratiques de développement utilisés, mais ne pas comprendre l’idée sous-jacente dans ces choix. Pourquoi avoir choisi ces outils? Pourquoi prendre ces pratiques? Avions-nous des standards avant ces pratiques ? Ce n’est que dans les choix effectués que nous pouvons voir la valeur de l’agilité.
Il n’y aucun moyen d’atteindre son objectif d’un seul coup, le seul moyen est de sensibiliser les collègues en permanence. De plus nous devons également analyser et résoudre les problèmes à temps et analyser ce qui s’est passé ensuite. Expliquer pourquoi nous avons résolu les problèmes de cette façon et comment traiter les mêmes problématiques dans le futur.
Alex :
Je pense qu’il y a deux grandes difficultés avant l’adoption de SCRUM :
- Le soutien des dirigeants. Je pense que c’est un problème commun. Jeff Xiong a publié un article pour InfoQ Chine: Agile step by step: how to do agile bottom-up, qui explique que si les dirigeants ne peuvent prendre en compte SCRUM, commencer par appliquer SCRUM uniquement dans l’équipe. Dieu merci, nos CEO et CTO ont soutenu SCRUM.
- Formation SCRUM pour les employés. Mes collègues ne comprenaient pas clairement SCRUM, j’ai alors organisé une formation SCRUM. Nous avons répondu aux interrogations ensemble. Et lors de l’adoption, tout le monde est devenu de plus en plus familier avec SCRUM. Bien sûr, les personnes qui popularisent SCRUM doivent être familier avec.
Ensuite, InfoQ a demandé à chacun de présenter leurs solutions dans le détail :
Julie :
Pour le premier problème, « manque de clarté des exigences« , nous avons fait un modèle universel pour tous les cahiers des charges, et ajouter une réunion de discussion des besoins avant la réunion de planification. Le chef de produit, les testeurs et les développeurs participent également à cette réunion.
Pour le deuxième problème – « cycle de livraison trop long« , nous avons ajouté la prise en compte quotidienne des demandes de maintenance, en plus de nos livraisons. Le chef de produit recueille les demandes d’évolutions, tels que « modifier les pages », « Ajouter / supprimer des données ». Ces exigences sont soumis aux ingénieurs dans la réunion quotidienne tous les mardis et jeudis matin, pour être livré dans l’après midi.
Alex :
Nous sommes à un bon niveau de l’adoption de SCRUM. Peut-être parce que je n’ai pas compris SCRUM très bien, et que nous utilisons seulement certaines pratiques, mais j’ai une conviction: nous trouverons notre propre version de SCRUM dans les itérations à venir, dans les succès et les échecs. Nous étions habitué à des projets avec des définitions des exigences peu claires. Pendant la réunion de planification, nous listons tous les points techniques à partir des besoins fonctionnels connus, ils sont ensuite classés par priorité. Une itération est de seulement 10 jours, il est donc toujours possible de gérer le planning global. Pendant la réunion du matin, tout le monde indique sur le tableau les tâches qu’il va réaliser pendant la journée. Cela améliore la capacité d’auto gestion de l’équipe.
Quels avantages SCRUM a t’il apporté à votre projet, à votre entreprise ?
Julie :
Je pense qu’il est difficile de mesurer les bénéfices tirés de SCRUM. Nous avons fait une enquête dans les équipes et a obtenu quelques informations générales:
Kaverjody :
Il est difficile pour moi de tirer une conclusion. Les avantages que je peut voir sont : nous pouvons obtenir du feedback sur les fonctionnalités plus fréquemment, nous pouvons détecter certains problèmes plus rapidement, par exemple développement multi-sites et coopération, rétrospectives et améliorations.
Alex :
Nous utilisons SCRUM dans toute l’entreprise, du développement, aux commerciaux en passant par les ressources humaines. Nous ne présentons pas SCRUM aux nouveaux employés, ils peuvent se familiariser avec au cours des journées de travail. Je ne peux pas dire l’importance du gain, mais cela nous a aidés à travailler heureux, plein d’énergie, et nous avons terminé notre itérations avant la date butoire. Maintenant nous préparons le prochain projet.
Pourquoi n’avez-vous pas adopté Scrum avec succès? Pourriez-vous décrire le process utilisé ?
David :
Notre problème était le suivant: certains dirigeant n’ont pas compris l’agilité et SCRUM. Ils ont considéré l’agile comme une formalité. Par exemple, nous avions un Scrum Master sur un gros projet, qui s’est très bien passé. Un chef de projet a trouvé cela bien et a instauré le Daily Scrum dans plusieurs projets, sans savoir ce qu’était l’agilité, ce qu’était SCRUM. Le Daily Scrum est alors devenu grâce à lui le daily report, et les principes fondamentaux de SCRUM n’ont pas été respectés.
Tout le monde devait assister au Daily Scrum a l’heure fixé, et indiquer ses tâches de la journée au manager qui décidait si il / elle devait prendre plus de tâches ou non. C’est nul. Le «Daily Scrum » a été annulé, tout le monde a estimé qu’il était trop ennuyeux. Et par la suite plus personne n’a parlé d’agilité dans l’entreprise.
Diona:
J’étais dans l’équipe multi site et l’équipe chinoise ne connaissait que peu de chose sur l’agilité au début. Un jour, le chef de projet à l’étranger nous a envoyé plusieurs liens parlant d’un terme étrange : SCRUM. Nous avions seulement un ou deux jours pour lire des documents sur SCRUM, et puis nous avons du commencer les daily meeting. En fait, tout le monde connaissait l’importance de la communication, mais nous avions 6 à 7 heures de décalage horaire, alors quand ils arrivaient au travail le matin, nous nettoyons le bureau et on retournait à la maison. Le daily scrum n’a pas amélioré notre communication, et a été abandonné après une ou deux semaines. Nous avons essayé de faire des daily scrum dans l’équipe chinoise, mais le plus gros problème a été la différence culturelle entre les équipes et la planification du projet. Le daily meeting n’a rien apportée et est vite devenu une formalité. Finalement il a été abandonné.
Nous n’avions pas de réunions de planification. Nous avions un soi-disant product owner, mais il n’a jamais expliqué les détails de chaque user stories, il n’a pas non plus pu définir ce qui était terminé. Nous avons essayé la rétrospective par nous-mêmes, mais nous n’avons pas obtenu de réponse de l’équipe à l’étranger, et nous avons abandonné.
Lorsque nous avons utilisé pour la première fois ScrumWorks, le product ower n’a pas donné de priorité aux user stories, et nous avons fait des estimations. Mais maintenant tout le monde peut ajouter des user stories dans ScrumWorks, et personne ne fixe la priorité, c’est nous, les développeurs, qui décidons. Si il restait une centaine d’user stories à la fin du sprint, elles étaient simplement ajoutées au sprint suivant.
Pour finir
Il y a eu plein de réactions à la fin de l’écriture de cet article en version chinoise sur le Agile China Google Group qui seront rapporté plus tard.
Je me souviens d’un phrase célèbre de Shakespeare: « Il y a des milliers d’Hamlet dans les regards différents de millier de personnes. » Donc: que penser vous de SCRUM ? et comment avez vous adopter SCRUM dans votre organisation ? Pouvez-vous partager votre expérience avec nous ?
A propos de l’auteur
Jacky Li est l’un des acteurs principaux d’InfoQ Chine et de la communauté agile chinoise. Spécialisé en Java et dans le développement logiciel agile. Il s’est consacré au développement de l’agilité en Chine. Il est le traducteur de InfoQ sur le minibook: Starting Struts2..
SCRUM, la revue de SPRINT
6/04/08
A la fin de chaque Sprint les développeurs présentent le travail réalisé aux autres membres de l’équipe. Dans l’idéal cette présentation doit être ouverte à toute personne de l’entreprise.
Intérêt de la revue de SPRINT
- Permet au Product Owner de valider que ce qui a été réalisé est conforme à la demande.
- L’équipe obtient de la reconnaissance pour le travail réalisé.
- Les autres personnes découvrent ce que l’équipe fait.
- Cela permet de recevoir du feedback de la part des participants.
Faire une démo pousse l’équipe à finir les tâches qu’elle a à réaliser et à ne pas se retrouver avec un tas de tâches faites à 90%. Peut-être que moins de tâches sont réalisées mais elle le sont à 100%.
Si la démo ne se passe pas bien, l’équipe de développement prendra un petit coup au moral mais cela les poussera à réagir et à faire en sorte que la prochaine démo se passe bien. Cela les conduira à faire plus attention à la qualité des réalisations.
Quelques conseils
- Enoncé clairement l’objectif du SPRINT. Il est important de se le remémorer pour s’assurer que ce qui est présenté permet de l’atteindre.
- Ne pas oublier que le but n’est pas de faire une démo mais de montrer ce qui a été développé et que les objectifs ont été atteints.
- La démo doit être fonctionnelle et ne pas se concentrer sur des points techniques.
- Il n’est pas nécessaire de présenter les corrections de bug mineur car cela pourrait détourner l’attention des fonctionnalités. Citer la liste des corrections effectuées suffit.
- La présentation des développements ne donnant pas lieu à une fonctionnalité visible doit être faite par le biais de rapports de benchmark, de tests…
Martin Fowler, utilisation d’un processus agile dans le développement offshore (Part 1)
24/03/08
Martin Fowler, une pointure du développement informatique et un pionnier des méthodes agiles a écrit il y a quelques temps de cela un article très intéressant sur l’utilisation des méthodes agiles pour le développement offshore. Les images utilisées pour illustrer cet article sont tirées d’une présentation réalisée par ThoughtWork (société où travail Martin Fowler) disponible ici.
L’article date un peut (Il a été écrit en 2003 et mis à jour pour la dernière fois en Juillet 2006) à l’époque les bienfaits des méthodes agiles sur le développement offshore n’étaient pas encore reconnus et certains disaient même qu’ils étaient incompatibles.
L’article étant d’une taille assez conséquente, je diviserais sa traduction en plusieurs posts.
Partie 1 :
- Introduction
- Leçons apprises
- Utiliser l’intégration continue pour éviter les migraines lors de l’intégration.
- Que chacun des bureaux est un ambassadeur de l’autre site.
- Des visites pour instaurer la confiance.
Introduction
Durant les quatre dernières années, ThoughtWorks, a fonctionné avec un laboratoire situé à Bangalore afin de soutenir le développement de ses logiciels en Amérique du Nord et en Europe
L’un des principes de base de toute méthodologie agile est l’importance portée à la communication entre les différents protagonistes du projet. « Le moyen le plus efficace et efficient de transmettre l’information au sein d’une équipe de développement, c’est le face-à-face ». Le livre d’Alistair Cockburn parle beaucoup de l’importance de la proximité physique dans les méthodes agiles.
Une autre tendance a récemment bousculé le monde du développement logiciel. C’est le passage au développement offshore. Celui-ci semble opposé au développement agile. Pour commencer, l’offshore va à l’encontre de la notion de proximité physique, puisque, par définition, les développeurs offshore sont loin. Deuxièmement la plupart des organisations faisant de l’offshore utilisent une approche prédictive (non agile) dans laquelle les documents de conception sont envoyés en zone offshore pour être réalisés.
ThoughtWorks a ouvert un bureau à Bangalore en 2001 et plusieurs des projets que l’entreprise a réalisés y ont eu recours. ThoughtWorks a utilisé autant que possible une approche agile, car pour eux cela est dans le plus grand intérêt des clients.
Il était également très important pour ThoughtWorks de conserver leur très grande exigence en matière de recrutement (généralement ils proposent un emploi à environ 1 candidat sur 100). Une grande partie des développeurs ont été recrutés à la fin de leurs études. On y a ensuite rajouté des développeurs plus expérimentés. Au début, plusieurs développeurs américains et britanniques ont rejoint le bureau de Bangalore, pour encadrer les nouveaux développeurs, à la fois sur le développement de logiciels mais aussi sur l’agilité et les pratiques XP appréciées par ThoughtWorks. Actuellement le centre de Bangalore compte environ 150 développeurs.
Utiliser l’intégration continue pour éviter les migraines lors de l’intégration.
Il y a de nombreuses histoires sur les problèmes rencontrés lors de l’intégration des travaux réalisées dans des équipes multi sites. Même en définissant des interfaces avec beaucoup de soins, les problèmes d’intégration font toujours leur apparition. Souvent même si toutes les signatures des méthodes sont correctes, il est toujours difficile de prévoir ce que l’implémentation fera réellement
La première pratique XP utilisée chez ThoughtWorks a été l’intégration continue. Ils y étaient tellement habitués qu’ils étaient déterminés à l’utiliser pour leurs développements offshores. Donc, dès le début, tout le monde travaillait sur le même serveur de source, avec CruiseControl réalisant les builds et les tests.
L’intégration continue et l’exécution automatique des tests permet de détecter très rapidement les éventuels problèmes et, de ce fait, ils peuvent être fixés avant que cela ne devienne trop difficile.
Tous les matins, les développeurs se connectent à l’interface web de CruiseControl pour voir les modifications faites par l’autre site. Il fournit un moyen facile de savoir ce qu’il s’est passé de l’autre côté du monde.
Mais l’intégration continue exige une grande discipline. Les développeurs s’efforcent de ne pas avoir de build failled et doivent réparer immédiatement si cela était le cas. Si un commit est effectué, on ne quitte pas le bureau tant que la confirmation du succès du build n’a pas été reçu. Un build failed de fin de journée à beaucoup plus de conséquence lorsque l’équipe offshore doit prendre le relais des développements.
Cependant des problèmes dus à la qualité du réseau de communication ont été rencontrés. En général, le serveur de build se trouve sur le même site que la majorité des développeurs, cela peut être ennuyeux pour l’équipe distante qui devra attendre longtemps lors d’un check-out complet. De plus le fait d’avoir un serveur devant être accessible 24h/24 n’est pas pratique pour pouvoir réaliser des backups. Tous ces problèmes pourraient être résolus en utilisant un cluster de serveur de sources mais l’équipe de ThougthWork n’avait pas les connaissances nécessaires à l’époque.
Que chacun des bureaux est un ambassadeur de l’autre site.
Comme dit plus haut, les méthodes agiles soulignent l’importance de la communication face-à-face. Même si tout le monde ne peut pas être sur le même site, le fait de déplacer certaines personnes aide énormément. Dès le début, un membre de l’équipe américaine était en permanence en Inde pour faciliter la communication. Un tel ambassadeur connaissant l’équipe américaine partage ses contacts ce qui facilite la communication.
Nous avons par la suite jugé utile d’envoyer un développeur américain et un analyste américain en Inde pour communiquer à la fois sur les exigences techniques et fonctionnelles. Il est également utile d’envoyer un membre de l’équipe Indienne en Amérique. Le coût du transport aérien est vite amorti par l’amélioration de la communication.
L’utilisation d’ambassadeurs dans l’équipe Offshore permet de partager le contexte du projet. Construire un logiciel sur une liste de fonctionnalités ne permet pas au développeur de savoir ce qu’il est prioritaire et important de faire. Le fait de connaître le « pourquoi » permet souvent de mieux choisir le « comment ».
Une partie importante du travail qui devra être effectuée par l’ambassadeur, est la diffusion « des bavardages ». Sur un projet il y a beaucoup de communication informelle. Même si en majorité cette information n’est pas importante, une partie l’est. Donc le travail de l’ambassadeur sera de rapporter des morceaux choisis de cette information qui n’a pas été jugée assez importante pour être transmise par les canaux officiels.
Les ambassadeurs changent en générale tous les mois. Si un ambassadeur passe trop de temps à l’étranger, il perd le contacte avec son site d’origine. Etre ambassadeur permet de passer du temps avec l’équipe distante et ainsi de mieux connaître les équipes. Lors du choix des ambassadeurs il est très important de prêter attention aux besoins et aux préférences des individus. Certaines personnes ne veulent pas passer plusieurs mois à des milliers de kilomètres de chez eux, de sorte qu’ils ne devraient pas être ambassadeur.
Nous avons également constaté qu’il est important pour les chefs de projet de passer un peu de temps en tant qu’ambassadeur. Une grande partie du travail du chef de projet est d’aider à résoudre les conflits et d’éliminer les problèmes avant qu’ils ne deviennent graves. Le fait d’avoir travaillé des deux côtés de la ligne téléphonique est vraiment important pour travailler efficacement.
Il est essentiel d’envoyer le plus tôt possibles des ambassadeurs. Si un projet se déroule pendant un certain temps sans ambassadeur, les malentendus et les mauvais sentiments vont se développer et cela demandera beaucoup de travail pour réparer les dégâts.
Des visites pour instaurer la confiance
En plus des ambassadeurs qui passent plusieurs mois dans le site distant, il y a d’autres types de visites qui contribuent à créer et à maintenir la communication nécessaire pour travailler efficacement à distance.
Les visites de lancement doivent être prévues le plus tôt possible dans le projet et doivent être d’une durée de deux semaines minimum. Le but premier de ces visites est d’habituer les gens à travailler ensemble.
- Envoyer les représentants du client et les chefs de projet pour créer un planning de livraison.
- Les analystes offshores doivent venir onshore pour participer aux sessions de recueil des besoins.
- Des développeurs onshore doivent rendre visite à l’équipe offshore pour travailler avec elle sur la première itération.
- L’équipe offshore doit visiter le site « onshore » surtout si il se trouve chez le client.
Il ne faut pas oublier que le but principal de cette visite n’est pas de faire le travail, mais de construire les relations de travail. C’est une erreur fréquente de vouloir faire entrer le plus de tâches possibles durant ses visites et de se retrouver au final avec très peu de temps pour les relations humaines. Le rythme de travail doit y être relax et il ne faut pas avoir peur de planifier des réunions informelles où l’on présente à l’invité l’environnement de travail.
Une variante de la visite de lancement est importante si des développeurs sont présent sur les différents sites. Dans ce cas il est important que les développeurs, au moins les séniors, travaillent ensemble sur les premières itérations. C’est durant ces itérations que les décisions d’architectures cruciales sont prises. Il est important d’avoir une forte proximité durant cette période sinon il pourrait y avoir une scission entre les deux équipes lorsque des décision ne sont pas partagées ou non comprises.
Une fois le lancement du projet terminé, des visites moins intenses doivent être utilisées pour garder le contact. Ces visites peuvent être plus courtes, mais assez fréquentes (au moins tous les deux mois). Il est important de prendre plus de temps lorsque des changements significatifs apparaissent dans le projet.
Des présents, en particulier ceux qui participent à l’échange culturel, comme les spécialités locales, sont toujours important.
C’est la fin de cette première partie. La suite devrait arriver prochainement.
Les salaires du développement offshore / nearshore
27/02/08
De nombreux critères sont importants lors du choix d’une destination offshore. Par exemple le nombre de ressources disponibles dans le pays, la qualité des infrastructures, le système éducatif, le système économique et politique, le niveau de formation des ingénieurs ou encore leur salaire sont autant de paramètres à prendre en compte.
La réduction des coûts est l’une des motivations premières d’une entreprise qui fait appel à l’offshore. Cette réduction dépend en partie de la rémunération qu’il faudra verser aux ingénieurs locaux.
Nous allons donc faire ici un petit tour des salaires des principales destinations offshores.
Salaire du développement offshore en Europe de l’est et Afrique du sud
Sur le graphe ci-dessus ne sont pas présent la Tunisie et le Maroc qui ont un niveau de salaire équivalent à la Russie ou à la République Tchèque. De même Madagascar et l’île Maurice ont des coups très faible, inférieur à ce qui se pratique en Inde (par contre infrastructure, nombre de ressource, niveau de formation sont moins bon).
Dans cette zone les pays attrayant sont la Roumanie et la Slovaquie qui se développent de plus en plus dans le secteur des services informatique. La Roumanie, comme le Maroc et la Tunisie, à l’avantage de fournir de nombreuses ressources francophones. La Russie est également intéressante pour ces coûts réduits et le niveau de son enseignement.
Salaire du développement offshore en Amérique (Sud, Nord)
Le Canada est une destination très attractive pour les USA pour son niveau de compétences, sa proximité, et des coûts environ deux fois moins chèrs.
Les pays d’Amérique du Sud (Costa Rica, Mexique, Brésil ou Argentine) présentent un niveau de salaire équivalent à ce qui se fait en Europe de l’Est. Le niveau de compétences y est bon (notamment en Argentine) mais pour le moment ils s’intéressent essentiellement au marché Américain.
Salaire du développement offshore en Asie
Le Vietnam est clairement la destination la moins chère, par contre la qualité n’est pas encore tout à fait au rendez-vous. Il y a un manque de ressources compétentes et les infrastructures doivent être améliorer.
La Chine et l’Inde font jeu égal sur ces chiffres datant de 2005 même si aujourd’hui la Chine est moins chère. Les deux pays fournissent un grand nombre de ressources ayant un bon niveau de formation. L’avantage linguistique et culturel est du côté de l’Inde mais les salaires sont amenés à y augmenter rapidement.
Récapitulatif et prévision pour 2010
| Pays | Salaire moyen en 2005 ($) | Salaire moyen en 2010 ($) |
| Vietnam | 5,503 | 7,827 |
| Chine | 8,455 | 11,972 |
| Inde | 8,485 | 12,877 |
| Thaïlande | 9,651 | 11,686 |
| Philippines | 10,736 | 14,918 |
| Romania | 13,708 | 17,329 |
| Brésil | 14,087 | 18,324 |
| Slovaquie | 14,786 | 18,163 |
| Russie | 17,882 | 25,316 |
| Malaysia | 18,564 | 23,024 |
| Costa Rica | 18,641 | 26,39 |
| République Tchèque | 19,125 | 26,203 |
| Mexico | 19,427 | 24,559 |
| Hongrie | 22,76 | 30,172 |
| Pologne | 26,38 | 34,152 |
| Afrique du sud | 31,957 | 38,881 |
| Israël | 32,599 | 37,975 |
| Singapour | 36,7 | 43,169 |
| Canada | 37,589 | 45,513 |
| Ireland | 48,178 | 56,396 |
Le radiateur d’informations
15/02/08
Simple et efficace, voici les deux adjectifs que j’utiliserais pour décrire le radiateur d’informations. Un mur, des stylos, des post-it et le tour est joué. Le but est d’afficher sur le mur les informations importantes pour que tous les acteurs du projet puissent y avoir accès à tout moment.
Un bon radiateur d’informations doit être :
- A jour et complet
- Précis et facile à interpréter
- Visible par tous
- Facile à manipuler.
Les informations affichées diffèrent selon les projets et les besoins mais il y a quelques grands classiques.
Le Task Board
Il présente les tâches à réaliser durant le sprint en cours.
Sur la gauche sont affichés sur des post-it verts les user story (et leur charge de travail) à réaliser pendant le sprint.
Pour chacun d’eux on trouve sur la même ligne les tâches nécessaires à leur réalisation. Elles sont représentées par des post-it jaunes sur lesquels sont indiqué le nom de la tâche, le temps restant et la personne qui en à la charge. La tâche passera successivement de la colonne « A faire », à « En cours » puis « Terminés »
On sait ainsi à n’importe quel moment qui travaille sur quoi et quelles sont les tâches restantes pour le sprint.
Le Burn Down Chart
Il permet de visualiser graphiquement l’avancement du travail et de savoir si le contenu du sprint pourra être réalisé dans les temps ou si certaines tâches devront être reportées au sprint suivant. Il permet également de détecter les ralentissements de production ou tout autres problèmes pouvant intervenir.
Il est placé au dessus du TaskBoard et est mis à jour tous les matins après le daily scrum.
En ordonnée on trouve la charge de travail restante dans l’itération et en abscisse les journées présentes dans le sprint. Le but étant que chaque jour, la charge de travail restant diminue.
Le Project Progress Poster
C’est une vue du projet dans sa globalité. Y est représenté le contenu des différents Sprints.
Pour chacun d’eux est indiqué l’objectif (Post-it orange) et la liste des user story qu’il faudra réaliser (Post-it en vert).
La colonne du sprint en cours a été déplacée dans le Task board. Les colonnes à gauche de celle étant vide représentent donc les sprints terminés alors que celles à droite représentent ceux restant. Une fois qu’un sprint est terminé on place son burndowChart au dessus de sa colonne.
Autres informations utiles pouvant être affichées
- Les « impediments » : Les problèmes identifiés qui pourraient entraver la progression du projet.
- Le calendrier des livraisons.
- Le burndownChart du projet total.
Petit tour d’horizon des destinations offshores
4/02/08
Voici un petit tour des destinations offshores qui pourrait intéresser les entreprises prêtent à franchir le cap.
L’Afrique
Deux régions y sont très attractives, le Maghreb (avec le Maroc et la Tunisie) et les îles de l’océan indien (avec Madagascar et l’île Maurice). Leur points forts, la pratique du français et la proximité culturelle. Ces destinations sont davantage accessibles aux PME françaises.
Le Maroc arrive en tête des implantations au Maghreb et cela grâce au programme lancé par le gouvernement marocain, Emergence 2010, où tout est fait pour attirer les Européens. Les coûts y sont deux fois moins importants qu’en France avec de bons ingénieurs qui ont souvent suivi leurs études en France. La Tunisie quand à elle, attire par son système éducatif connu pour son élitisme et par la qualité de ses ingénieurs. Sa faiblesse, la qualité de ses infrastructures que le gouvernement commence à améliorer(voir : Opportunités Nearshore en Tunisie, les SSII françaises intéressées).
De l’autre coté du continent nous trouvons l’île Maurice et Madagascar. Leur point fort, des coûts très bas aux alentours de ce qui se fait en Inde. L’île Maurice a surtout développé des compétences autour des nouvelles technologies, Java, J2EE, et.Net, tandis que Madagascar est davantage orientée « anciennes » technologies. Les points négatifs y sont les infrastructures qui ne sont pas encore très bien développées et le nombre d’ingénieurs formés chaque année qui reste assez faible.
L’Europe de l’est
Même si la réduction des coûts y est moins importante qu’en Asie, la Roumanie, la Pologne ou la Hongrie profite de leur appartenance à l’union Européenne. L’Europe de l’est est reconnue pour l’excellence de ses formations scientifiques. La formation qui y est dispensée rivalise avec celles des indiens et des occidentaux.
Leur plus gros point fort est d’être européen et donc proche sur le plan géographique (pas besoin de visa) mais surtout culturel et juridique. On va y chercher une plus grande sécurité à l’exemple des grandes banques françaises qui ont fait ce choix pour la confidentialité des données.
Pour nous français, la Roumanie a l’avantage de porter un grand intérêt à la langue française et il est très facile de trouver des ingénieurs parlant un français parfait.
La Russie
Nouvel arrivant dans le grand jeu de l’offshore, la Russie va devoir être prise au sérieux car elle possède de nombreux atouts. Comme en Europe de l’est, la qualité de l’enseignement scientifique y est très élevé mais elle a en plus l’avantage de former chaque année un grand nombre d’informaticiens de très bon niveau. Les coûts salariaux y sont similaire à ceux de la Tunisie.
L’Asie
L’Inde reste le leader mais la Chine avec ses ressources inépuisable arrive à grand pas. Le Vietnam commence à se développer dans le secteur avec comme avantage de pouvoir proposer des ingénieurs francophones même si la pratique du Français y perd du terrain face à celle de l’anglais.
L’Inde a, depuis une vingtaine d’année, rodé ses processus industrialisés et offre une large gamme de prestations. Tata Consultancy Services (TCS), Infosys, ou Wipro, rivalisent avec les SSII occidentales. De l’informatique de gestion à l’informatique technique, en passant par l’externalisation de processus métier ou BPO (Business Process Outsourcing), l’expertise indienne est complète.
Du côté du grand rival chinois, le gouvernement met en place une politique très agressive à grand coup de défiscalisation pour attirer les grands clients occidentaux et ainsi être le leader d’ici 5 ans. Le nombre d’ingénieurs formés chaque année y est supérieur à celui de l’Inde pour un niveau de formation comparable et des coûts inférieurs. Pour le moment les clients restent en majorité japonais et américains. Les SSII françaises sont encore peu présentes dans ces pays. Pour plus de détails voir l’article : Inde ou Chine, qui sera le futur leader de l’offshore ?
Développement offshore, un besoin d’agilité
19/01/08
Lorsque l’équipe (ou une partie de l’équipe) est éloignée, que ce soit avec des équipes offshores en Inde ou nearshores en Roumanie, de nouveaux problèmes liés à l’éloignement vont apparaître
- Problèmes de communication.
- Suivi de l’avancement du projet.
- Assurer la qualité.
A chacun de ces problèmes les méthodes agiles vont apporter des réponses.
- La communication : Les méthodes agiles mettent l’accent sur l’importance de la communication. Cette attention devra être encore plus forte avec l’éloignement des équipes. Heureusement, de nos jours, de nombreux outils sont disponibles pour nous faciliter la tâche.
- Le wiki : L’utilisation de wiki est un moyen simple et pratique de regrouper l’information et de la rendre disponible à tous les membres de l’équipe. C’est la que, par exemple, on trouvera les bonnes pratiques, les conventions de code, le processus de build, la description de l’architecture technique… C’est l’équipe qui l’alimente et qui y ajoute tous ce qui lui semble utile. De plus lors de l’intégration de nouvelles ressources sur le projet, l’information contenu dans le wiki se trouve être une vrai mine d’or pour le nouveau venu.
- La messagerie instantanée : C’est un très bon moyen de communication qui permet d’obtenir rapidement des réponses sur des problèmes pouvant être bloquant. Son grand avantage est qu’il n’est pas intrusif et qu’il n’est pas nécessaire de cesser toutes activités pour l’utiliser (contrairement au téléphone). Il ne remplace pas le téléphone mais lorsque s’agit d’éclaircir des points pouvant prêter à confusion, il fait très bien son boulot.
- Le téléphone : Avec l’apparition de la VoIP, le coût des communications internationales devient pratiquement nul. De plus elle apporte un plus grand confort d’utilisation en permettant à l’utilisateur d’avoir les mains libres, de pouvoir dans un même temps transférer des fichiers ou des urls par messagerie instantanée. Il est également très simple de mettre en place des conférences.
- La visoconférence : Même si sont utilisation n’est pas encore parfaite, la visioconférence peut permettre de recréer un peu les rapports humains « francs », face à face qui manque lorsque l’on travaille à distance. Deux développeurs qui travaillent à 10 000 km de distance peuvent ainsi « se voir » et mettre un visage sur l’autre.
- Les voyages : Il est essentiel, surtout en début de projet que de nombreux voyages aient lieux. Au minimum un responsable doit se déplacer au près des équipes offshore, pour les rencontrer et présenter le projet et ses objectifs. Il est aussi important que les équipes « on-site » et « distante » se rencontrent (au moins une fois) pour ainsi créer « un lien » et ainsi faciliter le travail avec « l’autre ».
- Suivi du projet : L’utilisation d’itérations courtes permet de montrer rapidement aux utilisateurs des fonctionnalités qui marchent, d’avoir des retours fréquents et donc de corriger le tir si besoin est. L’utilisation de Scrum permet de faire cela très bien. Les daily scrum permettent d’avoir un retour rapide sur le travail restant avant la fin d’une itération. Les « BurndownCharts » (graphiques d’avancement) permettent de visualiser graphiquement l’avancement du travail. Une interprétation simple permet d’avoir une idée sur les échéances futures.
- La qualité : Il est essentiel de garantir la qualité du produit développé. Pour cela il faut respecter certains principes forts comme ceux prônés par L’eXtreme Programming (voir article précédent pour plus de détails).
- Intégration continue
- Livraisons fréquentes
- Tests unitaires et tests de recette automatisés
- Conception simple
- Refactoring
- Appropriation collective du code
- Convention de nommage
Présentation de SCRUM
18/01/08
Scrum est une méthode de gestion de projets agile qui a été créer par Ken Schwaber et Jeff Sutherland. Le terme Scrum est emprunté au monde du rugby dont elle s’inspire des valeurs collectives (une équipe soudée, qui cherche à atteindre un but commun).
Le principe de Scrum est simple. Il s’agit de concentrer l’équipe sur un ensemble de fonctionnalités à réaliser au sein d’un itération appelée « sprint » dont la durée varie entre 15 et 30 jours. Pour chacun des sprints, le directeur de produit défini un but à atteindre et, en collaboration avec l’équipe de développement, les fonctionnalités à développer nécessaire pour y arriver.
Pendant la durée du « sprint » le ScrumMaster doit prendre soin de l’équipe en réduisant au maximum les perturbations extérieures et résolvant les problèmes non techniques que pourrait rencontrer l’équipe de développement. Pour cela tous les matin, le ScrumMaster réunit l’équipe pour une réunion de 15 minutes, appelée « scrum du matin » ou « daily scrum », au cours de laquelle chacun des membre de l’équipe répond au 3 questions suivantes :
- Qu’est-ce que tu as fait hier ?
- Qu’est-ce que tu vas faire aujourd’hui ?
- Quelles difficultés as-tu rencontrées ?
Cela permet au ScrumMaster de suivre l’avancement du projet et de lever les problèmes qui pourraient empêcher l’équipe d’avancer.
A la fin de chaque sprint, l’équipe présente le travail réalisé qui est un logiciel partiel fonctionnel. Il est potentiellement livrable et son évaluation permet d’ajuster le contenu du sprint suivant.
Je reviendrais plus en profondeur dans de prochains articles sur Scrum.
Vous pouvez retrouver un témoignage intéressant sur Scrum et l’offshore ici : Scrum et offshore