La gestion d’une équipe informatique à distance

La gestion d’une équipe informatique à distance

Processus et méthode

La gestion d’une équipe informatique à distance demande bien évidemment plus de rigueur que celle d’une équipe locale. Pour que cette approche puisse être appliquée simplement, il faut l’accompagner d’un outillage approprié pour organiser, contraindre et suivre le travail réalisé à distance. La mise en place d’un processus de développement structuré est souvent intimidante. On se retrouve en face d’une forêt de tâches, de rôles, de documents et de flux complexes, dont on ne perçoit pas immédiatement la portée. La seule exploration des processus n’est pas à la portée de tous. Les guides qui accompagnent ces méthodologies ne sont réellement efficaces que si l’on a l’expérience qui convient pour les appliquer intelligemment. L’application à la lettre des directives d’installation mènerait à un échec certain, car elles prévoient tous les cas de figure et sont d’une lourdeur excessive. Les méthodologies formelles sont assez nombreuses. La plupart des grands éditeurs de logiciels ont créé la leur, et certains l’incluent dans leurs offres de produits ou la vendent en la mettant plus ou moins en avant. Les deux approches méthodologiques qui se détachent assez nettement sont le RUP (Rational Unified Process) d’IBM (www-306.ibm.com/ software/awdtools/rup/) et XP (eXtreme Programming) (www.extremeprogramming.org/). Microsoft propose avec MSF (Microsoft Solutions Framework) son propre cadre de travail, qui complète sur de nombreux sujets les approches du RUP ou de XP en insistant davantage sur la gestion des hommes et les flux de travail que sur la structuration des processus et documents (www.microsoft.com/msf/). Ce chapitre se penche sur les quelques éléments qui doivent impérativement être implémentés lorsqu’on travaille avec l’offshore. La plupart des méthodologies récentes appliquent ces recommandations, bien qu’en les présentant de façons assez différentes.

La méthodologie et les hommes

La méthodologie ne garantit pas un résultat indépendamment des équipes en place. Comme expliqué au chapitre 11, le succès d’un projet est avant tout conditionné par la qualité des hommes, leurs interactions, leur management et leur motivation. Livre Offshore.book Page 243 Lundi, 21. février 2005 7:44 19 Conduite de projets informatiques offshore 244 Plus le projet est important, plus la méthodologie est indispensable, car il faut harmoniser le travail entre différentes équipes et gérer des masses importantes d’informations. Lorsque le projet est très petit, les efforts nécessaires pour déployer des procédures industrielles prennent un poids exagérément important par rapport aux tâches de production, et l’on privilégie des procédures légères. Les qualités humaines font toute la différence dans ces projets légers. Les méthodes essaient de prendre en compte toutes les étapes d’un projet, depuis les premiers moments, quand le projet prend forme, jusqu’aux évolutions et corrections du produit final en exploitation et à la préparation du projet suivant. La mise en place d’une méthodologie est souvent dépersonnalisante. Elle vise à structurer les échanges et la traçabilité et à centraliser les responsabilités. La plupart des outils méthodologiques utilisent la gestion de work orders, qui attribuent des tâches unitaires à des personnes d’une façon plus ou moins automatique. Les développeurs qui découvrent leurs tâches dans ces outils méthodologiques, assorties de dates de livraison, ont l’impression de n’être que des exécutants, qui ne décident de rien. Il est donc important de respecter les motivations, engagements, initiatives personnelles et responsabilités que chacun apporte aux tâches qu’il réalise. Cela peut paraître évident, mais lorsqu’on met en place une méthodologie, on tend à s’imprégner de tous les concepts, et l’on a tendance à oublier le facteur humain. Il est important de ne demander aux collaborateurs d’engager leur pleine responsabilité que s’ils ont pu étudier et accepter les tâches à réaliser et s’ils ont effectivement la possibilité de mener à bien les réalisations. Un collaborateur que l’on tient pour responsable de tâches sur lesquelles il ne s’est pas engagé personnellement ou pour lesquelles il n’a pas de possibilité d’agir se désintéresse de ses objectifs. Si certains outils méthodologiques peuvent mener à des effets négatifs sur la gestion des ressources humaines, ces mêmes outils utilisés correctement peuvent aider à structurer l’organisation des workflows et l’utilisation du référentiel tout en conservant les motivations et responsabilités des collaborateurs. Procédures et outils méthodologiques n’ont de sens que pour accompagner les collaborateurs dans la structuration de leur travail et dans les échanges d’informations. On doit donc mettre en place ces méthodes et outillages avec la volonté de préserver l’initiative, la responsabilisation et l’engagement personnels des collaborateurs. EN RÉSUMÉ Outils méthodologiques et motivation Les outils méthodologiques peuvent mener à une gestion des ressources humaines réduisant les collaborateurs à des rôles d’exécutants. La motivation et l’engagement des collaborateurs sont essentiels pour garantir le succès et la qualité des réalisations. Il faut donc veiller à conserver ces valeurs dans le management des ressources humaines lors de la mise en place des procédures. Un autre piège des méthodologies est la façon dont elles présentent les rôles. Un rôle assure un certain nombre de tâches ciblées. Le nom des rôles est souvent trompeur, car certains d’entre eux correspondent à des postes (par exemple, développeur), tandis que d’autres se rapprochent d’une activité (par exemple, test designer), qui doit être assurée. Les rôles peuvent être très précis, comme test reviewer, même si cela ne correspond pas à un poste à temps plein

Choix de la méthodologie et des outils

Les outils permettent d’améliorer les communications avec l’offshore en rendant transparents les workflows, les livraisons et la progression du projet. Ce chapitre ne prétend pas aider à choisir la méthodologie ou les outils qui doivent être utilisés pour travailler avec des équipes en offshore. Il propose simplement un tour d’horizon des fonctionnalités les plus utiles pour les projets en offshore parmi celles offertes par la plupart de ces outils de développement. En tout premier lieu, il importe de choisir une méthodologie qui utilise une approche itérative et qui est correctement accompagnée de l’outillage permettant d’en appliquer, voire d’en forcer les principes essentiels. La méthode La méthode peut se présenter sous la forme d’un produit packagé et versionné, pour les méthodologies qui sont gérées comme des produits, tel le RUP, ou sous forme d’archive compressée à télécharger sur Internet. Qu’elle soit livrée sur un CD ou disponible sur le Web, elle doit être adaptée aux besoins du projet. Livre Offshore.book Page 245 Lundi, 21. février 2005 7:44 19 Conduite de projets informatiques offshore 246 La solution la plus simple pour installer la méthode consiste à créer un intranet à partir du site brut proposé par la méthodologie et de le personnaliser selon les activités, livrables et workflows que l’on souhaite mettre en œuvre. Les méthodes couvrent le plus souvent un spectre beaucoup plus large de situations que celles que l’on rencontre dans un projet réel. Certains flux, comités ou documents peuvent n’avoir qu’une utilité réduite dans le cadre d’un projet. Il faut donc adapter le cadre méthodologique afin de ne déployer que les éléments utiles, tout en respectant les principes de base. La méthodologie elle-même doit être mise en place de façon itérative et permettre de revenir sur des éléments dont la définition ne serait pas pleinement efficace et que les collaborateurs voudraient améliorer. Le référentiel Le référentiel est l’outil le plus important de l’outillage méthodologique. Il reçoit tous les éléments qui sont créés, modifiés ou utilisés dans le cours du projet. On trouve aussi bien des textes, contenant des informations générales sur le projet, que des documents méthodologiques, des codes source, des scripts, des plans de test, etc. On peut y placer les différents jeux de données de test, ainsi que tous les outils qui permettent de reconstituer l’intégralité de l’environnement de développement et de déploiement. Le référentiel permet de conserver le versionnement de tous les éléments que l’on y place. On peut ainsi retourner à des versions antérieures et savoir qui a effectué des modifications et quand. C’est tout particulièrement sur la gestion du code source que l’on trouve les mécanismes les plus évolués. Le référentiel peut être lié aux autres outils qui sont mentionnés dans la suite du chapitre et qui permettent de gérer des informations sur le changement, maintenant ainsi non seulement les différentes versions des éléments mais les changements opérés sur ceux-ci. De cette façon, l’utilisateur extrait un code source du référentiel pour effectuer un ou des changements (correction d’anomalie, évolution fonctionnelle, nouvelle fonctionnalité, etc.) qui sont demandés dans l’outil de gestion du changement et le replace dans le référentiel une fois le changement effectué. Le premier objectif de la gestion de référentiel est de gérer les extractions pour modifications et l’insertion de l’élément modifié. Le programmeur peut bloquer un élément pour éviter que plusieurs personnes ne travaillent dessus en même temps sans le savoir. L’outil sait aussi gérer la fusion de modifications simultanées si ces dernières sont situées dans des parties différentes du code. Il peut tout aussi bien demander au programmeur de résoudre les recouvrements de modifications. Pour créer une version d’un produit, on identifie des baselines, qui sont un ensemble d’éléments versionnés qui doivent être extraits simultanément pour être compilés. Ces éléments doivent être compatibles entre eux et s’assembler correctement. Par exemple, si l’on fait évoluer une interface technique, les anciens programmes qui utilisent l’interface précédente ne fonctionnent plus. Il faut donc attendre que les programmes aient été retravaillés pour prendre en compte la nouvelle interface afin qu’ils fonctionnent à nouveau. La baseline identifie les versions des éléments qui sont compatibles avec la nouvelle interface afin de les compiler et créer un produit exécutable.