Une autre relation client- fournisseur

Dossier agileEN COLLABORATION AVEC EPYX

rko. La méthode agile convainc de plus en plus d’organisations pour leurs développe-ments logiciels. La moitié des entreprises suisses auraient désormais recours à l’une de ses variantes (en particulier Scrum) selon une étude récente de SwissQ et de l’Univer-sité de St-Gall. Plusieurs raisons expliquent cet engouement, comme l’accélération des projets et une meilleure productivité et satisfaction des équipes de développement. La caractéristique et l’atout principal des méthodes agiles résident toutefois dans la nouvelle relation qu’elles instaurent entre les métiers ou clients demandeurs d’un applica-tif d'une part et les départements ou presta-taires amenés à le réaliser d'autre part. Une logique d’association co-responsable guidée par un objectif commun plutôt qu’un contrat détaillé. Une focalisation sur le chemin et le dialogue menant à la définition et à la réali-sation de l’applicatif, plutôt qu’un cahier des charges unilatéral et sujet à interprétation.

au-delà du développement logicielLes fameux tableaux remplis de post-it colo-

rés employés dans le développement agile gagnent d’autres domaines séduits par ce pacte entre client et fournisseur. Lors de la dernière conférence Lift, Daniel Freitag, patron de la marque de sacs éponyme, expli-quait comment il use de la méthode agile dans la gestion de sa firme au quotidien. Dans une édition récente, la très sérieuse Harvard Business Review vantait les atouts des procé-dés lean pour le développement des start-up. L’expérience montre en effet que les jeunes pousses allant rapidement à la rencontre de clients potentiels sur le marché et profitant de leurs inputs pour concevoir leur offre, ont de bien plus grandes chances de succès.

Cette dynamique fait écho à la manière dont se développent de nombreux services en ligne. Plutôt que d’attendre une version finalisée, les concepteurs lancent rapide-ment une solution inaboutie (voire plusieurs sous forme de A/B testing) et exploitent les retours des utilisateurs pour apporter des améliorations en continu. Ici aussi, la rela-tion client-fournisseur est profondément changée. <

> page 36 Agile: quel impact pour les entreprises

clientes?

> page 37 SCRUM, retour d’expérience interne

> page 38 Philippe Theytaz, FHVI: «Les itérations

régulières permettent de se concentrer sur les vraies priorités»

Sour

ce: ?

35 juillet – août 2013 © netzmedien ag

Dossier agileEN COLLABORATION AVEC EPYX

36 juillet – août 2013 © netzmedien ag

agile: quel impact pour les entreprises clientes?Il est unanimement convenu que lors de la construction d’un immeuble, le client se doit de suivre l’avancement des tra-vaux et d’intervenir éventuellement durant leur réalisation. Sous une forme assez similaire, le développement informa-tique en mode agile nécessite aussi un engagement fort et une collaboration soutenue de la part du client. Georges Caron

La mise en œuvre d’une approche de déve-loppement traditionnelle prédictive est envisageable lorsque tous les mécanismes d’un système sont bien compris et maîtrisés, aussi bien par le client que par l’équipe char-gée du développement. Lorsque la problé-matique est trop complexe le besoin réel est impossible à définir correctement. Dès lors, la vérification de l’adéquation au besoin est faite de manière trop tardive.

Souvent, durant la phase de conception et de réalisation le niveau de connaissance s’est sensiblement enrichi et à la fin du projet, le besoin réel a immanquablement changé. Le client se retrouve avec une application qui ne lui convient pas entièrement et, à ce stade, les ajustements coûtent chers.

Nouveau mode de collaboration entre client et fournisseurAvec la méthode agile, le client est partie prenante dans l’équipe de développement. Il participe en continu à la définition de la solution. Son implication ne s’interrompt pas après la validation des spécifications, pour ensuite reprendre lors des tests fonc-tionnels. Il est concerné durant toute la phase de conception et de réalisation. Cette collaboration s’inscrit à plusieurs niveaux dans la relation client-développeurs. Lors de la phase initiale du développement, une période d’analyse permet de définir les grandes lignes du projet, avec l’implication du client, et de définir le cadre extérieur du besoin. L’équipe (dont le client est partie pre-nante) passe en revue les besoins exprimés dans le cahier des charges, les techniques de

développement applicables, l’architecture logicielle et matérielle et tous les éléments permettant d’avoir une compréhension commune du besoin et des efforts néces-saires au développement de l’application. De fait, le client est ainsi concrètement engagé dans la gestion du risque.

Plus d’implication, moins de formalisme…Normalement, le rôle de product owner est dévolu à un représentant du client. C’est lui qui écrit les user stories qui alimentent le réservoir des tâches à réaliser. Elles sont ensuite prises en charge par l’équipe en fonc-tion de sa capacité et des priorités définies, et réalisées durant les diverses phases de développement, les fameux sprints. A la fin de chaque sprint, dont la durée se doit d’être assez courte (deux semaines), les utilisa-teurs sont conviés à une séance de démons-tration, effectuée par les développeurs eux-mêmes. Les utilisateurs y découvrent un incrément de produit terminé et peuvent

réagir immédiatement. Le cas échéant, le product owner prendra note des éventuels ajustements qui seront ensuite à considérer pour l’itération suivante. L’utilisateur parti-cipe ainsi activement à la convergence du produit vers la qualité et le niveau d’adéqua-tion voulu.

Bénéfices et cont raintesPour le développement à façon, la méthode agile permet d’intensifier la relation avec le client et de gagner en proximité avec lui. Le client est impliqué dans la phase de dévelop-pement, ce qui le rapproche plus rapidement du résultat du travail tout en y étant associé. Le souci de pérennisation de la compétence fait naturellement partie de la démarche, elle est garantie par l’équipe. L’assurance qualité et le contrôle sont également des aspects essentiels. De par la livraison d’incréments fonctionnels successifs, le client est à même de vérifier très tôt la conformité du niveau de qualité convenu.

georges Caron, directeur chez epyx.

Board interactif sous la forme de post-it dans le cadre de la méthodologie SCRUM. Source: epyx

Le premier principe qui a été appliqué consiste à ce que l’agilité soit synonyme de flexibilité, mais également de discipline. En effet, la suppression de tout gaspillage en respectant un rythme soutenu et soutenable de développement incrémental a permis aux équipes d’atteindre des niveaux de produc-tivité supérieurs à ceux de projets menés en mode cascade.

De plus, la durée et la fin de chaque itéra-tion (sprint) étant immuable, chaque équipe, réorganisée autour d’une taille optimale de cinq à neuf personnes, mène un arbitrage permanent sur le bien fondé de chaque fonc-tionnalité pour garantir le respect des engage-ments pris auprès des clients. Par ce biais, les ingénieurs ont développé une capacité accrue à intégrer les demandes de changement de périmètre et à collecter en continu le feedback des utilisateurs. Ceci a contribué à augmenter la transparence en interne et à garantir que les développements s’inscrivent toujours sur la trajectoire attendue.

Les processus d’assurance qualité ont éga-lement été transformés, en commençant par laisser les équipes s’accorder communément, puis s’engager avec les clients sur les critères d’acceptation et sur une definiton of done par-tagée. Le code est ensuite revu en appliquant des techniques simples d’extreme program-ming (XP) telle que la revue dite à quatre yeux entre deux développeurs.

Sur la base d’itérations de développe-ment de deux semaines, la fréquence de mises en production de lots a été augmen-tée. Ceci a favorisé la livraison et la démons-tration des fonctionnalités à plus forte valeur ajoutée en priorité. Dans cette démarche, les environnements de développement et de déploiement ont été standardisés avec des fonctionnalités d’intégration continue et de tests automatisés.

Enfin, les échanges face-à-face régu-liers lors des séances de démonstrations en fin d’itérations ont permis de valider les livrables le plus tôt possible, et surtout ont amené à entretenir une confiance et

une meilleure compréhension mutuelle entre développeurs et clients.

responsabilisation et autogestionDu fait que l’allocation des projets et des man-dats se fait au niveau de l’équipe et non au niveau d’un individu, l’esprit d’équipe en est sorti renforcé. Tant les succès que les difficul-tés sont partagés au sein du groupe.De même, les estimations sont faites de manière collective, en mettant en valeur l’avis de chaque membre de l’équipe dans un esprit d’échange constructif et le côté quelque peu ludique de ces séances dites de poker plan-ning n’enlève en rien à la responsabilisation de toute une équipe quant aux engagements pris sur les délais et sur l’effort à fournir.

La dynamique d’entreprenariat a été parti-culièrement illustrée par le fait que les équipes se sont auto-organisées. Non seulement phy-siquement avec par exemple le regroupement créatif des places de travail autour des murs de suivi, mais également dans l’organisation proactive du travail. Puis par l’initiative de mettre en place des écrans de monitoring continu sur l’avancement des tâches et sur le suivi des environnements techniques. Enfin, les équipes ont développé l’art de l’autocri-tique durant les meetings de rétrospective en fin d’itération, dont le but principal est l’amé-lioration continuelle.

Le dernier point qui mérite sans doute d’être mentionné est la tendance croissante de chaque ingénieur à évoluer vers une cer-taine polyvalence. Sans pour autant gommer les préférences et talents de chacun. <

sCrUM, retour d’expérience interneLors du passage en mode agile, nous avons dû procéder par itérations avant de pouvoir récolter les bénéfices attendus. Les lignes qui suivent mettent en exergue cette phase de transition, le temps d’un trimestre. Rivo Radanielina

Dossier agileEN COLLABORATION AVEC EPYX

37 juillet – août 2013 © netzmedien ag

Il importe toutefois de veiller à ce que la méthode agile préserve certains éléments cruciaux dans le développement à façon. La notion de prix fixe est notamment un élément prépondérant. Pour y parvenir, le client est impliqué dans l’évaluation des fonctionnali-tés (story map) et la définition des priorités. Le classement des modules à réaliser doit se faire avec le client, dans le but de produire le maxi-mum de valeur ajoutée tout en réduisant rapi-dement le risque. Pour les développements à

réaliser en mode forfaitaire et à prix fixe, cette phase est cruciale dans la mesure où elle doit confirmer l’enveloppe budgétaire prévue.

Pour une société de développement infor-matique, le développement agile requiert d’autre part une organisation adéquate des équipes afin d’être à même de servir plusieurs projets simultanés. Une gestion de l’activité multi-projets est donc nécessaire. L’équipe par contre, doit rester la même. Elle acquiert sa capacité de travail par son homogénéité. Au sein de l’équipe, le rôle du client en tant que product owner est assuré par un corres-pondant interne en relation étroite avec le client réel.

ConclusionLa mise en place de la méthode nécessite un effort considérable car il est important que cette démarche soit appliquée de manière holistique. L’adoption par les collaborateurs doit être unanime malgré la charge de travail inhérente au changement de paradigme et à la mise en place des outils nécessaires à la pro-duction itérative. Le niveau d’adoption par les clients est par ailleurs excellent. Les avantages du travail commun sur un story map sont très appréciés. La perception d’une vision com-mune simultanée des fonctionnalités à déve-lopper et le constat rapide de l’avancement des travaux crée un lien de confiance précieux avec le client. L’aspect intuitif de la démarche et son côté humain incite à un élargissement de son champ d’application. <

rivo radanielina, COO chez epyx.

Sour

ce: s

hutte

rsto

ck

«les itérations régulières permettent de se concentrer sur les vraies priorités» La Fédération des Hôpitaux Vaudois Informatique (FHVI) a récemment lancé un projet d’optimisation de sa solution de suivi des encaissements en s’appuyant sur la méthode Scrum. En entretien avec ICTjournal, son Directeur Philippe Theytaz livre ses premières impressions sur ce développement agile. Interview: Corine Fiechter

en quoi consiste ce projet, et pourquoi l’avoir lancé?Ce projet a pour but de moderniser et d’amé-liorer notre solution applicative qui permet de gérer le suivi des encaissements, notam-ment au niveau des flux financiers et de la traçabilité. La centrale d’encaissement des établissements sanitaires vaudois qui est opérée au sein de la FHV Informatique, traite quelque 240 000 factures chaque année, pour un volume d’encaissement d’environ 740 millions de francs. Concrètement, plus de 98% des factures sont gérées informatique-ment. En 2012, la centrale d’encaissement a travaillé avec 158 établissements prestataires de soins et 98 partenaires payeurs (assu-rances et autres). Sur ce nombre de factures, il y a lieu de traiter 6% à 7% d’extournes ou annulations. Certaines de ces factures sont également mises en suspens à la demande des payeurs jusqu’à éclaircissement des cas. La centrale d’encaissement a également pour mission de redistribuer les quoteparts de subventions publiques aux établisse-ments concernés. Nous avons donc déployé ce projet d’optimisation dans le but de dis-poser d’un meilleur suivi en temps réel, avec des indicateurs et des tableaux de bord per-formants, tout en augmentant l’automatisa-tion des traitements et la coordination des informations avec les systèmes des acteurs partenaires.

Pourquoi avoir opté pour une méthode agile, plus précisément scrum?Dans ce type de projet, pour exiger un résul-tat à prix fixe d’un prestataire, il est difficile de fixer le niveau de détail avec lequel il faut produire le cahier des charges. Sans compter le risque d’attendre plusieurs mois ensuite, avant de se rendre compte qu’au final, la solution livrée ne correspond pas entièrement aux exigences. Je pense que la méthode Scrum permet une meilleure maîtrise du risque, lequel est défini et suivi, à l’instar des processus, conjointement avec le prestataire dès le tout début. A quoi s’ajoute une réelle flexibilité, grâce aux inte-

ractions régulières, généralement tous les 15 jours. Ce qui facilite la compréhension mutuelle et permet à tout moment de redé-finir ensemble les besoins et les bonnes priorités.

espérez-vous également retirer des gains de temps?Pas forcément un gain de temps, mais une meilleure utilisation des ressources, donc de la création de valeur le plus en amont pos-sible dans le projet. Les itérations régulières permettent de se concentrer sur les priorités, et ce des deux côtés. Le fournisseur doit livrer ce qu’il s’est engagé à produire, généralement selon des sprints de deux semaines. Ce qui nous oblige de notre côté à valider les incré-ments de solutions et à nous calquer aussi sur le calendrier fixé.

Comment respecter un budget en mode agile, à partir du moment où la prestation à délivrer n’est pas clairement fixée au départ?Nous disposons bien sûr d’un budget et le

cadre est aussi défini au départ. Les itéra-tions fréquentes nous permettent toutefois de savoir en continu où nous en sommes, non seulement au niveau de l’avancement du projet, mais aussi en termes de coûts, et donc de pouvoir ajuster si nécessaire. Par exemple, si un module se révèle plus lourd que ce que nous avions imaginé, nous pouvons rééva-luer conjointement avec notre prestataire les possibilités d’ajustement et de réduction de coûts ailleurs, voire d’abandonner des options non prioritaires. Je ne pense pas que le fait de travailler en mode agile revienne moins cher. En revanche, je pense que cette méthode contribue à ce que l’argent investi corresponde bien et mieux au besoin réel et ceci dès le départ.

exigez-vous de tous vos prestataires des dé-veloppements en mode scrum?Non. D’abord, nous achetons en principe des solutions et packages applicatifs exis-tants que nous intégrons. Nous ne dévelop-pons que dans des cas spécifiques, lorsque les solutions ne sont pas disponibles sur le marché. Ou plutôt, nous faisons dévelop-per, car nous ne disposons pas de déve-loppeurs à proprement parler à l’interne. En ce sens, le projet d’optimisation de notre solution d’encaissement est un peu parti-culier, puisque l’un de nos collaborateurs avait porté ce développement et ces évo-lutions depuis plus de 10 ans. Etant donné qu’il allait partir à la retraite, nous avions initié une démarche d’externalisation de type TMA, en mode traditionnel. C’est la société Epyx, notre prestataire, qui nous a amené la culture agile dans ce projet, au tra-vers des structures qu’elle a mises en place. Forts de cette expérience, nous ferons une rétrospective en fin de projet et planifierons les ajustements nécessaires par rapport au mode de développement et de collabora-tion pour les projets futurs. <

Dossier agileEN COLLABORATION AVEC EPYX

38 juillet – août 2013 © netzmedien ag

Philippe Theytaz, Directeur de la FHVI, attend de la méthode Scrum une meilleure maîtrise des risques sur les projets de développement spécifique.