Publié par

Il y a 11 ans -

Temps de lecture 22 minutes

Scrum distribué : recettes pour avoir des équipes de développement Offshore hyper productives

Scrum a été conçue pour atteindre une productivité de 5 à 10 fois supérieure à celle traditionnellement constatée dans l’industrie et de nombreuses équipes co-localisées (c.a.d localisées physiquement au même endroit) ont réussi à atteindre cet objectif. La question qui est posée dans cet article est de savoir si des équipes Offshore et distribuées sont capables d’atteindre de manière durable de telles performances.

En particulier, la vélocité d’une équipe locale peut elle être maintenue voire même augmentée si elle est distribuée au travers de plusieurs continents ?

Xebia mène depuis mi 2006 des projets agiles distribués entre l’Europe et l’Inde. Après avoir atteint le stade de l’hyper productivité en Europe, les membres indiens de l’équipe ont été réinstallés dans leur pays d’origine. Dans le cadre de cette distribution, nous avons constaté que la vélocité de l’équipe a même augmenté. L’utilisation des pratiques d’ingénierie de XP (eXtreme Programming) au sein de projets Scrum a permis à Xebia de répliquer de manière durable un modèle de développement Offshore distribué de grande qualité identique à celui de SirsiDynix [1].

Introduction

Le but de cet article est donc de décrire un modèle de développement dont la productivité augmente linéairement avec la distribution des équipes sur plusieurs continents et dont la vélocité est comparable à celle d’équipes co- localisées.
Ce modèle est reproductible, éprouvé et est particulièrement recommandé aux équipes aguerries, maîtrisant Scrum et XP.
Les méthodes agiles héritent des meilleures pratiques de sociétés comme Fuji, Xerox, Canon, Honda et Toyota. Combiner Scrum à XP a permis d’atteindre des niveaux de productivité de 5 à 10 fois supérieurs à la moyenne de notre industrie [3] [5]. En 2005, deux sociétés agiles, SirsiDynix (E.U) et Exigen Services (Russie) ont utilisé des équipes Scrum distribuées afin d’atteindre des performances linéaires dans le cadre d’un grand projet de plus d’un million de lignes de code. L’équipe distribuée entre les Etats Unis et la Russie a atteint une vélocité équivalente à celle d’une équipe co-localisée et a réussi à construire une liste de fonctionnalités équivalente à celle d’une équipe de 350 personnes d’un projet mené traditionnellement en cascade (Waterfall).
De 2006 à 2008, Xebia a mis en place des équipes distribuées pour moitié en Europe et pour moitié en Inde dans le cadre de différents projets. Ces équipes ont utilisé le processus de développement de Scrum avec les pratiques d’ingénierie de XP.
Nous aborderons donc au cours de cet article les stratégies Offshore à adopter pour lever les obstacles géographiques, linguistiques et culturels traditionnellement rencontrés dans les projets Offshore et les techniques permettant de les mettre sur la voie de la réussite.
La distribution des équipes Scrum au travers de plusieurs continents élimine les problèmes de communication, les pratiques XP résolvent les problèmes d’intégration et les réunions quotidiennes (Daily Scrum Meetings) maintiennent l’emphase sur les priorités du client.
Les expériences menées dans d’autres sociétés ont démontré que la proximité géographique peut doubler la productivité des équipes agiles [8]. Ici, le modèle Agile distribué rend transparent l’éloignement géographique pour atteindre des performances équivalentes ou supérieures aux équipes agiles co-localisées.

Les challenges de l’Outsourcing Offshore

Que ce soit aux Etats Unis, en Europe et au Japon, de plus en plus d’entreprises font appel au développement logiciel Offshore dans des pays d’Europe de l’Est et en Asie. Pour autant, les équipes opèrent localement et les problèmes de communication altèrent le niveau de productivité de celles-ci.
La plupart des organisations Offshore exigent des spécifications détaillées avant le démarrage des projets. Il est prouvé que ces méthodes de planification atteignent des niveaux élevés d’échecs.
Les coûts cachés du développement Offshore sont significatifs et cela dès le début.
Barthelemy [8] a mené une étude auprès de 50 sociétés et a démontré que 14% des opérations menées en Offshore sont des échecs. Son rapport démontre que les coûts de transition liés à l’établissement de relations avec un nouveau fournisseur engloutissent souvent l’intégralité des économies attendues par le faible coût de la main d’œuvre. Le temps moyen entre l’étude d’opportunité de l’Offshore et l’atteinte de la vitesse de croisière chez le fournisseur est de 18 mois pour des petits projets.
Par conséquence, la MIT Sloan Management Review conseille à ses lecteurs de ne pas outsourcer les projets critiques.
Les trois objectifs que poursuivent les projets Offshore sont les suivants:

  1. faible coût de la main d’œuvre
  2. recherche de compétences locales
  3. accroissement ou au contraire la diminution des projets sans avoir à licencier son propre personnel

Le premier objectif n’est pas facilement atteignable. Chez PatientKeeper (une société du MIT, fondée en 2000 où travaille Jeff Sutherland), entre 2004 et 2007, le point mort des projets Outsourcés n’était atteint que lorsque les développeurs indiens ne coûtaient que 10% du prix de leurs homologues américains. Le comité de Direction de PatientKeeper décida alors de stopper définitivement les projets Offshore.
Attirer les compétences locales peut aussi s’avérer être un problème. Jack Blunt, Président de Dynix et ancien Directeur des Opérations de Borland refusa d’outsourcer ses projets en Inde ou en Chine lorsqu’il découvrit que le Turn Over dans ces pays était entre 30% et 50% [9].
Tenir les promesses du développement Offshore requiert de faire de vraies économies, d’avoir des équipes Offshore stables et d’élaborer une stratégie destinée à la connaissance en interne.
Cela n’est possible que si les équipes Offshore ont atteint le même niveau de productivité que les équipes internes et si les équipes internes et les équipes Offshore maintiennent le même niveau de connaissance.

Les modèles de distribution de Scrum

Considérons les trois modèles d’équipes Scrum suivants :

  • Equipes Scrum isolées : Les équipes Scrum sont isolées les unes des autres géographiquement.
  • Les Scrum de Scrum distribuées : Les équipes Scrum sont isolées les unes des autres et intégrées par un Scrum de Scrum [6] qui se réunit régulièrement.
  • Equipes Scrum distribuées : Les équipes Scrum sont cross fonctionnelles et distribuées au travers des continents.

Les équipes Scrum isolées du projet Google AdWords ont exprimé le besoin de meilleures pratiques de communication. La bonne pratique recommandée par la Scrum Alliance est le modèle Scrum de Scrum distribué. Ce modèle divise le travail au travers d’équipes Scrum isolées cross fonctionnelles tout en éliminant la plupart des dépendances entre celles-ci. Les équipes Scrum sont reliées par des Scrum de Scrum où les ScrumMasters des différentes localisations se rencontrent régulièrement.
Le modèle Scrum distribué, comme le montre le modèle OneTeam de Xebia, distribue intégralement toutes les équipes et chaque équipe Scrum a des membres à plusieurs endroits.
Même si, de prime abord, cela semble alourdir le processus de communication et de synchronisation, les Daily Scrum aident à supprimer les barrières culturelles et à lisser les disparités dans le mode de travail tout en améliorant l’emphase sur les besoins clients et leur compréhension par les équipes Offshore.
A l’échelle d’une entreprise, ce modèle organise le projet autour d’une seule base de code intégrée.
Le maximum de valeur métier est délivré par Scrum en implémentant les fonctionnalités du Product Backlog dans l’ordre des valeurs métier.
Les fonctionnalités du produit sont représentées par Xebia en User Stories et la taille d’une User Story est évaluée en Story Points [5].
Les équipes de Xebia mesurent le coût en Euro par User Story.
La valeur de la fonctionnalité divisée par le coût est l’indicateur principal de la valeur métier ainsi délivrée et est directement proportionnelle à la vélocité de l’équipe, calculée en Story Points par itération.
Xebia contrôle sans cesse que la vélocité d’une équipe distribuée équivaut à celle d’une équipe co-localisée.
Le modèle Scrum distribué n’est conseillé qu’aux équipes agiles expérimentées.
Il s’avère que les équipes distribuées ont un meilleur focus que les équipes co-localisées.
La métrique la plus communément admise pour comparer la productivité entre projets est le Function Point puisqu’il représente directement les fonctionnalités délivrées.
Capers Jones démontra il y a quelques années que le nombre de fonctionnalités délivrées par les Function Points peut être estimé par le « sacro saint » nombre de lignes de code.
Même si la mesure de la valeur métier est moins directe, c’est la meilleure manière de mesurer des équipes à l’échelle de l’industrie informatique.
On peut toujours argumenter du fait qu’écrire un grand nombre de lignes de code ne garantit pas de produire de la valeur métier. Les équipes Scrum utilisent également les pratiques d’ingénierie xP produisent plus de lignes de code qu’une équipe standard de l’industrie car :

  • Scrum priorise le Product Backlog en fonction de la valeur métier, garantissant ainsi que les lignes de code produites optimisent la valeur métier délivrée.
  • La pratique XP consistant à refactorer élimine des milliers de lignes de code qui seraient restées statiques dans un projet en cascade.

Le message de ce document est donc que les équipes Scrum/XP de Xebia délivrent les Function Points sept fois plus vite qu’une équipe standard dans un projet en cascade.

Le cas ProRail de Xebia

Le meilleur moyen d’illustrer le modèle distribué est de prendre un cas réel : le projet ProRail mené par Xebia.
ProRail , la branche infrastructure et logistique des chemins de fer néerlandais devait développer un nouveau système d’informations voyageurs.
Les informations sur les horaires des trains sont centralisées et mises à jour par le réseau ferroviaire lui même.
Quand un train est en retard ou en avance, l’information est collectée par des capteurs disséminés dans l’infrastructure ou dans certains cas, manuellement.
Xebia a donc mené le projet d’affichage de ces informations aux voyageurs pour l’ensemble des Pays Bas.
Les développements portaient sur la construction du système d’agrégation et de distribution de l’information (incluant le routage d’informations ad’hoc pour chaque gare pour l’ensemble des trains la concernant), le client d’affichage, le système audio ainsi que le contrôle et le monitoring des interfaces.
Dans ce type de projet très visible et très sensible et nécessitant une très haute disponibilité, les besoins non fonctionnels sont nombreux.
Le temps était le critère majeur car des projets antérieurs, menés en cascade, n’avaient pas respecté leurs engagements.
La transparence et la recherche de l’amélioration continue ont été des critères déterminants pour le client dans le choix de Xebia.
Le choix du développement Offshore a été guidé par les coûts et la capacité à monter en charge rapidement.

Structure projet et montée en charge

Xebia a initialisé le projet par une courte phase de construction du Product Backlog, une conception sommaire de l’Architecture ainsi qu’un plan qualité. La recette et les spécifications étaient laissées à la charge du client.
Après 3 semaines d’initialisation de projet, une équipe co-localisée mena deux itérations.
La longueur d’une itération avait été fixée à 2 semaines pour l’ensemble du projet.
Les équipes indiennes furent introduites sur site dès la troisième itération.
Les membres de l’équipe néerlandaise et ceux de l’équipe indienne furent regroupés au sein d’une même équipe, co-localisée, partageant un seul et même Product Backlog et des pratiques d’ingénierie d’XP.
Durant les itérations co-localisées, les membres de l’équipe ont scellé des relations interpersonnelles qui ont perdurées jusqu’à la fin du projet et les équipes indiennes ont pu ainsi s’approprier pleinement le contexte du client.
Cela a aussi permis d’aligner tout le monde sur des pratiques, des standards, des rôles et des outils communs.
Après 3 itérations, l’équipe indienne retourna en Inde. Force est de constater qu’en 5 itérations (10 semaines), l’équipe avait atteint le niveau de l’hyper-productivité.
Le projet est ensuite monté en charge après le retour des indiens chez eux.
Des développeurs furent ajoutés au dispositif pour ainsi former deux équipes supplémentaires, chacune avec des membres distribués dans les deux pays.
Une attention toute particulière fût portée au partage de l’expérience avec les nouveaux au sein des équipes et des pratiques comme le Pair Programming furent largement utilisées pour accélérer leur apprentissage.
La division cellulaire fut ainsi répétée jusqu’à atteindre la taille désirée.
Le projet grossit donc jusqu’à atteindre 3 équipes distribuées et une équipe Scrum locale, avec au total 25 personnes. Les équipes partagèrent le même Product Backlog mais chacune avait son propre Sprint Backlog.
A la fin du projet, les équipes furent peu à peu réduites et fusionnées entre elles.
Comme le client préféra que la maintenance soit prise en charge par des ingénieurs néerlandais, les équipes indiennes furent les premières à disparaitre du dispositif.
La taille totale du projet fût de 20 années/homme, 100.000 lignes de code sur une période de 11 mois.

Les avantages de la démarche constatés

L’approche OneTeam prônée par Xebia dans le cadre de développements Offshore Agiles distribués atteint les mêmes résultats qu’une équipe co-localisée.
Les différents aspects du projet sont décrits ci-dessous :

Productivité
Durant le projet, la vélocité fut déterminée par le nombre de Story Points qu’une équipe pouvait réaliser dans le cadre d’une itération.
Comme les Story Points ne peuvent pas être convertis d’un projet à l’autre, le projet fut estimé en Function Points.
Cette estimation fut faite pour l’ancienne implémentation et la nouvelle implémentation, et les chiffres correspondent.
Même si cette mesure de la valeur métier n’était qu’approximative, elle fut le seul moyen de faire des comparaisons entre projets.

Schéma 1 : Productivité d’équipes Scrum co-localisées, équipes projet classique, d’équipes SirsiDynix distribuées, et Xebia One Team.

fig1.png

Le Schéma 1 montre aisément que les équipes Scrum surperforment les équipes de projet classique.

Les résultats d’une équipe Scrum distribuée Xebia sont équivalents à ceux d’une équipe Scrum co-localisée et les performances de Xebia et SirsiDyniax sont équivalentes.
Ce schéma montre que la performance d’une approche Scrum distribuée est reproductible et non spécifique à SirsiDynix.
Afin d’évaluer l’effet de la distribution des équipes sur la productivité, nous pouvons examiner le coût de la réalisation par Story Point tout au long du projet.

fig2.png

Il est important de noter qu’il y a une augmentation graduelle du coût de réalisation d’un Story Point dans la plupart des projets classiques dès que complexité grandit et que le code devient important, ce qui n’est pas le cas dans le diagramme ci-dessus.
La transition d’une équipe co-localisée à une équipe distribuée survint à la 6ème itération.
Nous pouvons voir sur le schéma que le nombre d’heures nécessaires à l’implémentation d’un Story Point n’a pas été affecté par cette transition.
Les estimations des Story Point ont été faites en début de projet pour l’ensemble du Product Backlog et au fil de l’eau quand ils naissaient.
Les itérations 18 et 19 montrent une augmentation significative du nombre d’heures nécessaires par Story Point : une dette technique s’était formée dans lors des itérations précédentes.
A partir de l’itération 20, cette dette fut systématiquement réduite pour aboutir finalement à augmentation constante de la productivité.

Une communication claire au travers de Scrum.
Les Scrum Meetings facilitent grandement la communication. Cela est rendu possible dans une équipe Scrum distribuée par le fait que les objectifs sont complètement partagés.
Toutes les cérémonies de Scrum furent tenues en mode distribué en utilisant le système de vidéo conférence de Skype à l’exception des démos.
Des salles de réunion séparées furent créées avec l’équipement de conférence ad’hoc. Un outil de planification utilisant une version électronique du Burn Down Chart permettait d’avoir une vision partagée du statut du Sprint en cours pour l’ensemble de l’équipe. Un microphone passait de main en main pour des raisons d’audibilité. Nous avons découvert que les face à face visuels accroissaient l’efficacité de la communication et permettaient d’améliorer les relations interpersonnelles.
Les Sprint Planning impliquaient tous les membres de l’équipe, utilisant les Planning Poker Cards afin que les équipiers des deux continents participent aux estimations.
Planifier un Sprint prenait environ 4 heures.
Les Daily Stand Up meetings démarraient quand les européens arrivaient au travail. Un Stand Up meeting ne durait pas plus de 15 minutes.
Le Retrospective Meeting était mené comme le Sprint Planning Meeting et durait environ 2 heures.
La démonstration, elle, n’était pas partagée afin de garder un maximum d’emphase et de réactivité face au client. Les Européens briefaient les indiens après la démo.
Les meetings Scrum de Scrum avaient lieu juste après les Daily Scrum afin de synchroniser les éventuelles dépendances entre les équipes, et d’identifier les obstacles ou les points techniques.
L’ensemble de ces meetings étaient donc conformes au cycle officiel. Les face à face étaient aussi tenus si nécessaires ainsi que les revues de conception.
Il n’y avait donc rien de différent par rapport à l’utilisation de Scrum co-localisée si ce n’est l’outillage.

Consistance et qualité
Durant tout le projet, une attention toute particulière a été portée à la qualité.
La notion Scrum de  » done  » sur ce projet était la suivante : couverture à 80% des tests unitaires, chaine de tests fonctionnels complètement automatisée, tests de non régression complets, tests de charge et de performance mis en place pour toutes les User Stories et production de la documentation nécessaire.
Pour chaque fonctionnalité, l’intégralité de l’équipe était impliquée afin de débattre de la conception et de refactorer si nécessaire.
En complément à cette propriété collective de la conception, chaque équipe employait un  » Gardien de la Qualité « . Il s’agissait d’un membre de l’équipe responsable de la qualité et de la consistance des travaux menés. Chaque fois qu’il soulevait un problème, il était traité par l’intégralité de l’équipe.
Tous les membres de l’équipe partageaient la même pièce et des membres d’une équipe participaient systématiquement aux phases de conception des autres équipes afin de maintenir une consistance architecturale de l’ensemble.
Le Pair Programming et la rotation entre les équipes servaient à éviter l’appropriation du code et maintenir la polyvalence.

fig3.png

Tous les bugs détectés et leur résolution ont été scrupuleusement comptabilisés tout au long du projet.
Le Schéma ci-dessus montre que le nombre de bugs est resté constant tout au long du projet (environ 50) évitant ainsi à l’équipe de constituer ce que l’on appelle une dette technique.
Le nombre de bug par KLOC (KiloLineOfCode) a même décru au fur et à mesure de l’avancée du projet.
Nous avons aussi constaté que 90% des bugs étaient résolus au sein même de l’itération où ils avaient été produits.
En nous basant sur ces chiffres, nous pouvons en conclure que le processus de vérification et de validation isolait 6 bugs par KLOC avant les phases de recette, laissant environ un bug par KLOC.

Ces résultats sont bien meilleurs que la moyenne de l’industrie qui est de 5 bugs par KLOC [10].
Une équipe Scrum distribuée, utilisant les pratiques xP délivre donc un travail d’excellente qualité.

Transparence et contrôle
L’équipe projet put donner des estimations pertinentes sur le temps et le budget nécessaires au projet grâce à l’utilisation du Backlog et un calcul précis de la vélocité de l’équipe [11].
Cela permit de mettre à disposition du client toute les informations nécessaires au contrôle total du projet. La transparence et la production d’un logiciel ‘fini’ à la fin de chaque itération permettaient de donner de la visibilité et de construire ainsi une totale relation de confiance.

Les problèmes rencontrés

Même si Scrum est facile à comprendre, l’implémenter l’est beaucoup moins.
Le développement distribué ajoute une couche de complexité et le projet, comme tout projet, rencontra un certain nombre de difficultés dans ce domaine.

Les différences culturelles
Les équipes européennes et indiennes ont des parcours et des cultures très différents.
Cela est particulièrement vrai dans le domaine de la communication.
Prenons un exemple : un européen est bruyant et direct alors qu’un indien est précautionneux et discret.
Les indiens sont plus hiérarchisés que les européens.
La meilleure arme pour outrepasser ces différences consiste à travailler sur les relations entre les individus. Les échanges qui ont été maintenus tout au long du projet, le contact visuel quotidien à l’occasion des Daily Scrum et l’appartenance à une seule et même équipe sont autant de facteurs qui ont permis de construire des relations interpersonnelles très fortes.
Ensuite une culture de la communication franche et ouverte a été instaurée par les ScrumMasters ce qui a permis d’adresser tous les problèmes lors des Retrospectives et de supprimer les barrières culturelles.
Enfin, le partage d’une culture d’entreprise commune, de part et d’autre a grandement facilité la construction d’une équipe soudée.

Partage du contexte et des priorités
Dans un contexte de développement distribué, il est parfois difficile de communiquer à l’équipe Offshore les nuances du contexte et des priorités du client. Afin de distribuer activement une telle connaissance du contexte client, nous avons prévu des voyages réguliers dans les deux sens, des connections Skype permanentes, la mise en place d’une  » gazette projet  » envoyée à la fin de chaque itération et des contacts informels avec le Product Owner.

Gérer un client qui fait de l’agile pour la première fois
Même si Scrum ne nécessite pas la présence d’un chef de projet, Xebia ajoute un tel rôle au sein du projet.
Ce chef de projet est responsable de la négociation financière avec le client. Il gère ses attentes et fait tout ce qui est possible pour que Scrum fonctionne.
Comme le client n’avait aucune expérience Agile, le chef de projet agit comme un coach responsable de mener l’organisation du client sur la voie de l’Agilité et servit aussi de Proxy Product owner.
Cela permit à l’équipe et aux ScrumMasters d’avoir, dès le premier jour, un Product Backlog clair et d’avoir quelqu’un faisant l’interface avec le client.
Le Proxy Product Owner /Chef de Projet s’assurait de la pertinence du planning Agile et était en contact permanent avec le client pour discuter des jalons, du périmètre et opérer le suivi du projet.
Les ScrumMasters étaient donc en charge des Sprints, des processus agiles et de la qualité.

Une partie du travail doit se faire localement
Même si l’ensemble des développements peuvent être distribués, certaines tâches du projet ne peuvent l’être aisément et doivent être traitées localement.
La 4ème équipe Scrum (cf 4.1) était purement locale, constituée d’européens et dédiée à certaines activités impliquant des interactions physiques avec le client. Des exemples de tâches locales sont : écrire de la documentation en néerlandais, se coordonner avec les Responsables de l’Architecture du client, discuter des spécifications techniques avec la MOE du client ou bien encore établir la liste des dépendances techniques.

Les outils nécessaires à la communication et aux processus
Sur le projet, ScrumWorks a été utilisé pour gérer le Product Backlog et le Sprint Backlog au format électronique.
Les Burndown Charts étaient imprimés quotidiennement et accrochés aux murs des pièces où travaillaient les équipes.
Afin d’obtenir un partage global de l’information, un Wiki fut utilisé de manière intensive.
Les discussions d’Architecture étaient tenues autour de WhiteBoard électroniques.
Parmi quelques uns des outils accessibles par l’ensemble des équipes (co localisées et distantes) nous pouvons énumérer un référentiel de code unique, un système d’intégration continue, des serveurs et des mailing lists.

Conclusion

En résumé, nous pensons qu’il est possible de faire du Scrum distribué avec la même vélocité et la même qualité qu’en situation co-localisée et cela dans la majorité des projets.
La stratégie OneTeam abaisse les coûts, utilise au mieux les talents des membres Offshore tout en permettant une augmentation (ou une diminution) de la taille de l’équipe sans perte de la connaissance.
Nous recommandons cette stratégie aux équipes agiles aguerries.

Références

  • [1] Sutherland J., Viktorov, A. and Blount J.: « Adaptive Engineering of Large Software Projetcs with Distributed/Outsourced Teams ». Proc. International. Conférence Complex Systems, Boston, MA, USA, 25-30 Juin 2006.
  • [2] Sutherland J.: « Future of Scrum »: Parallel Pipelining of Sprints in Complex Projects’. Proc. AGILE 2005, Conférence de Denver, CO, 24-29 Juillet 2005.
  • [3] Beck, K.: « Extreme Programming Explained: Embrace Change », Addison-Welsley, Boston, 1999.
  • [4] Takeuchi, H. et Nokata, I. « The New New Product Development Game », Harvard Business Review, 1986 (Janvier-Février).
  • [5] Cohn, M.: « User Stories Applied : For Agile Software Development », Addison-Wesley, 2004
  • [6] Sutherland, J., et Schwaber, K.: « The Scrum Papers: Nots, Bolts, and Origins of an Agile Method », Scrum Inc, Boston, 2007
  • [7] Jones, C.: « Software assessments, benchmarks, and best practices », Addison Wesley, Boston Mass, 2000
  • [8] Teasley, S. Covi, L., Krishnan, M.S., and Olson I.S.: « How does radical collocation help a team succeed? », Proc CSCW’00, Philadelphie, PA, 2000, pp. 339-346.
  • [9] Sutherland J, Viktorov, A. Blount J., et Puntikov, N.: « Distributed Scrum: Agile Project Management with Outsourced Develoment Teams ». Proc HICSS’40, Conférence International d’Hawaii, 2007.
  • [10] Humphrey, W.S.: « Introduction to the Personal Software Process », Addison Wesley, 1996
  • [11] Cohn, M.: « Agile Estimation and Planning », Adison Wesley, 2005

Traduction libre de l’article « Fully Distributed Scrum : The Secret Sauce for Hyperproductive Offshored Development Teams » co écrit par: Jeff Sutherland Ph. D. (Scrum Inc), Guido Schoonheim (Xebia), Eelco Rustenburg (Xebia) et Maurits Rijk (Xebia).

Publié par

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.