09 September 2010

Inscrivez-vous au Flux RSS

Dévelopement Offshore : de l’itératif, du Timeboxing sinon rien ….

Posté par jc-QualityStreet le 25 avril 2007

Gérer des itérations en timeboxing (”la date de fin d’une itération est fixe, on ne la bouge pas ; en cas de difficultés, on peut jouer sur le contenu à réaliser en le reportant par exemple à l’itération suivante”) est le premier principe à respecter quand on s’engage dans le développement offshore, un contexte dans lequel les méthodes traditionnelles (cycle en V…) ont clairement montré leurs limites.
Vincent Massol, dans son livre blanc « Le Développement Offshore Agile » , nous explique pourquoi l’utilisation des méthodes agiles en Offshore est essentielle. A l’arrivée,

L’agilité diminue le risque projet dû à l’éloignement
L’agilité permet de réaliser des projets complexes en Offshore
L’agilité permet d’augmenter la productivité en soignant la motivation des équipes

D’ailleurs, l’utilisation de courtes itérations et le timeboxing, est une de ses 10 règles d’or permettant d’assurer le succès de projets de développement Offshore.
Itération, Timeboxing, il existe désormais un véritable consensus parmi les experts français du domaine (Développement Offshore) ; Eric O’Neill va lui aussi dans ce sens dans son livre « Conduite de projets informatiques offshore » :

Le processus itératif est primordial pour gérer efficacement un projet en Offshore. C’est le seul moyen de juger de l’avancement du projet et d’en tirer les conclusions pour améliorer les points faibles.

C’est pour lui l’une des clés de la gestion de projet.
En terme de méthodologie, les instantiations du Processus Unifié (notamment RUP ou AUP), simplifiées, réorganisées et réorientées pour s’adapter aux contextes offshore semblent faire l’unanimité parmi ces spécialistes.
Outre l’itératif, UP dans ce contexte bénéficie de réels points forts : “la gestion des exigences ” (sur la base d’une liste des exigences et de cas d’utilisation, ici les “User stories” ne sont pas forcément des plus adaptées), ” une documentation adaptée” (juste ce qu’il faut), “des build permanents“, un focus sur les tests (unitaires et autres en fonction des exigences) …
Si l’on ajoute des principes de gestion de projets plus agiles (un “scrum daily meeting”, deux trois fois par semaine, le “burndown chart”…), des moyens communication adéquats et l’intégration des activités et livrables de l’ergonome, on peut obtenir des résultats intéressants…
Dans tous les cas, vous pouvez aussi suivre les précieux de conseils de Martin Fowler, fondés sur l’expérience réussie de ThoughtWorks, acteur majeur de l’offshore, notamment entre Inde, USA et UK, et qui prône depuis quelques années l’adoption des principes agiles pour ce type de projets.

Développement Offshore: toujours plus agile…

Posté par jc-QualityStreet le 11 avril 2007

Certains ont choisi de mixer offshore et Méthodes Agiles avec succès…
Envisager le développement informatique Offshore (c’est à dire la sous-traitance d’un développement informatique dans un pays éloigné) ou passer d’un mode de développement “séquentiel” aux méthodes agiles, sont deux stratégies différentes répondant pourtant aux mêmes besoins de la part des entreprises:

  • Baisser les coûts de développement
  • Augmenter la flexibilité des équipes
  • Réduire les délais de mise en marché
  • Améliorer la qualité

On sépare souvent ces deux statégies argumentant qu’Offshore et Méthodes Agiles ne font pas bon ménage, que l’Offshore va à l’encontre des principes Agiles
Depuis quelques années, certaines sociètés ont pourtant fait le pari de mixer les deux approches espèrant un cumul des bénéfices de chaque stratégie et donc un avantage concurrentiel évident. C’est ce que tend à démontrer ce rapport de Forrester, signé Stéphanie Moore et Liz Barnett…
Plus récemment, l’agilité est apparue comme une réponse aux échecs des premières tentatives Offshore opèrées par quelques éditeurs de logiciels et SSII, comme un remède aux problèmes de communication, au manque de visibilité sur l’état d’avancement du projet, aux dérapages budgétaires, ou encore aux livraisons non adéquates.
Mais tout n’est pas si facile et des adaptations sont nécessaires… encore une fois le Processus Unifié semble être un bon compromis, toujours avec notre dose de SCRUM et une forte implication de l’ergonomie tout au long du projet.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes