La méthode agile convainc de plus en plus d’organisations pour leurs développements 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’Université 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 applicatif d'une part et les départements ou prestataires 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éalisation de l’applicatif, plutôt qu’un cahier des charges unilatéral et sujet à interprétation.

1. Dossier agile
EN COLLABORATION AVEC EPYX
Une autre relation client-fournisseur
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 logiciel
Les 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»
Source: ?
juillet – août 2013 © netzmedien ag 35

2. Dossier agile
EN COLLABORATION AVEC EPyX
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
juillet – août 2013 © netzmedien ag 36
La mise en oeuvre 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 fournisseur
Avec 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­raintes
Pour 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

3. Dossier agile
EN COLLABORATION AVEC EPyX
SCRUM, retour d’expérience
interne
Lors 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
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 autogestion
Du 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. <
juillet – août 2013 © netzmedien ag 37
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.
Conclusion
La 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.
Source: shutterstock

4. «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 agile
EN COLLABORATION AVEC EPyX
juillet – août 2013 © netzmedien ag 38
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.