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.
Ce n’est pas évident de le faire comprendre à son comptable, mais pour de petites société la délocalisation de certains services permet réellement d’y gagner. J’ai testé et je suis prêt à recommencer! 😉
je dois avouer que mon expert comptable n’est pas convaincue….moi oui! :-))
Pour l’avoir pratiqué en long et en large auparavant en agence, je sais que cela doit être plus que bien maitriser pour différentes raisons :
– Si cela est caché au client (risque énorme), 0 droit à l’erreur sur la livraison
– Garder la maitrise et le controle du projet et des fonctionnalités, il ne faudrait pas que ce soit nous qui nous nous adaptions à un développement érroné ou incomplet.
– Un brief de départ est primordial et à organiser de façon rigoureuse avec des supports compréhensibles par n’importe quel interlocuteur
– Les livraisons ( code ) doivent être commentées et sur-commentées en anglais
– Le suivi quotidien des équipes off-shore est primordial par un chef de projet fonctionnel (ou ergonome) et par un chef de projet technique qui doivent faire corps et ne pas se contre-dire eux-mêmes.
– Il sera aussi souvent nécessaire qu’un chef de projet sur place suive son équipe de développement.
– Attention que les livraisons ne s’écrasent pas entre elles…
– etc… etc…
Mais il est clair, que cela permet de lortir des développements (modules faits à l’off-shore, d’autres sur place) et de compresser les délais.
Mais je resterai prudente sur ce sujet, car le suivi est primordial et pas toujours simple à distance, voir contraignant et parfois il peut devenir un surcout.
Merci de ton retour d’experience Elodie.
L’approche collaborative et la visibilité que donnent les méthodes Agiles sont, me semble-t-il, de vrais points forts dans lesquels tu devrais te retrouver