earlegal #4 - Risques et opportunités de la méthode agile dans les contrats informatiques

Contrats informatiques Agile :
Risques et opportunités
Alexandre CRUQUENAIRE
Anne CUSTERS

www.earlegal.beGroupe Larcier / Lexing
Programme
 Caractéristiques et particularités de la méthode Agile
 Comment sécuriser le budget?
 Comment gérer le planning?
 Quelles responsabilités dans le cadre d’un projet Agile?

Groupe Larcier / Lexing www.earlegal.be
Particularités de la méthode Agile

www.earlegal.beGroupe Larcier / Lexing 4

Phases de développement classiques (Waterfall)
Planning: «statement of requirements»,
détermination des points de
développement et leur priorité
Analyse et conception (design)
Codage (coding)
Essais (testing)
Déploiement en production
(deployment)

Agile: Cycles courts
Cycles dénommés « iterations » ou « sprints »
Durée: 1 à 4 semaines par cycle de développement
Pour chaque cycle, plusieurs phases (//Waterfall):
Product vision (général): buts et bénéfices envisagés pour produit fini
Product backlog (“carnet du produit”): définition des fonctionnalités du
logiciel et leur priorité (requirements), une estimation de la valeur de chaque
élément (coût pour client) et de l’effort de développement (ressources pour
prestataire).
Sprint backlog: planning pour itération spécifique: détermination des points
de développement à réaliser pour 1 cycle
Exécution du Sprint backlog, puis validation (tests;
identification des points à corriger)
 fin cycle
 nouveau cycle…

Avantages par rapport à méthode traditionnelle Waterfall
Flexibilité par rapport au changement:
priorités peuvent être modifiées, points de développement
rajoutés, enlevés ou repris lors d’une autre itération (p.ex. en
cas de points nécessitant des corrections)
(<-> Waterfall: request for change additional costs)
Fourniture rapide et régulière de parties du logiciel/projet.
(par itération<-> Waterfall: une fois à la fin du contrat)
Monitoring régulier  vue sur qualité travail, mesures
correctrices plus rapides.
(par itération: réunion pour élaborer Sprint Backlog, réunion
régulière de suivi du travail de développement en cours de
Sprint, réunion d’évaluation à la fin du Sprint après testing)
7

Inconvénients / risques
Incertitude sur la fin du contrat
Combien d’itérations nécessaires? Coût final?
Disponibilité des ressources
Suivi régulier = ressources client à mobiliser
Disponibilité des ressources client à bien évaluer
Alternative: faire appel à société extérieure pour la phase « testing »
Suivi régulier et fréquent du client (meetings et (re)définition des
points à développer par itération)
compétences internes nécessaires
Contrat spécifique nécessaire afin de prévoir des procédures
adaptées aux capacités du client (disponibilité des ressources,
contraintes budgétaires, etc.)

Comment sécuriser le budget?

Fixed price <-> time and material basis
Crainte: approche de type « régie »
Combien d’itérations nécessaires?
Coût final?
Travail au « forfait » peu réaliste (changements inévitables)
MAIS la méthode Agile n’est pas incompatible avec un certain
contrôle sur le budget ou forfait
 le contrat doit prendre en compte les besoins spécifiques du client
10

Solutions budgétaires
Aménagements contractuels
pour protéger les deux parties
11

Solutions budgétaires : Aménagements contractuels
Adapter la formulation des requirements du Product backlog et les priorités
au budget estimé avec le prestataire
Accord du client sur le budget du sprint au début de chaque sprint
Coût unitaire de main d’oeuvre fixé pour toute la durée du contrat
 permet de déterminer clairement les budgets des sprints et d’évaluer facilement les
ressources encore disponibles
12

Solutions budgétaires : Aménagements contractuels
Prévoir OK sur le budget lors des réunions d’évaluation des modifications de
sprint backlog (réorientation des priorités si nécessaire)
Prévoir des réunions intermédiaires d’évaluation des ressources/budgets (tous
les 4 sprints, par exemple) afin d’actualiser le statut de l’enveloppe globale
et de permettre au client de mettre à jour sa liste de priorités si nécessaire
Risque que les décisions prises en réunion « engagent » le client sur une
extension de budget  Prévoir une enveloppe globale fermée en exigeant
un avenant contractuel pour étendre le budget
13

Quels outils pour gérer le planning?

Agile = Cycles très courts
La gestion du planning est cruciale : pas de temps à perdre car
l’enchainement des cycles doit être fluide
Bien définir les différentes étapes à suivre, la durée
(fixe) pour les accomplir, ainsi que les responsabilités
de chaque partie dans les étapes du processus
Qui fait quoi et dans quel délai;
Ex.: propositions à faire par le Product Owner, développement
par l’équipe de développement…
15

Solutions en cas de blocage du processus ou non respect
des délais
Pénalités
en cas de non respect de délais prévus (un ou plusieurs sprints?);
À manier avec modération car le but du processus est de stimuler l’interaction
et non de paralyser les initiatives par la crainte de pénalités systématiques
Mécanisme d’acceptation tacite:
Utile pour éviter les situations de blocage
Sanction plus constructive que la pénalité
À double tranchant  prévoir des délais réalistes pour ne pas être
piégé
Exemple: prévoir qu’à défaut de réaction de la part de … endéans le
délai de …, présumé avoir accepté/validé.
La rédaction du contrat est cruciale
16

Solutions en cas de blocage du processus ou non respect
des délais
Résiliation du contrat
Dans quelles circonstances, pour quelles raisons et quand a-t-on le droit de
terminer le contrat (après chaque itération? Lorsque plus de x sprints en
retard? En raison de faillite…);
Indemnités de résiliation vu investissement important par l’équipe de
développement;
bien régler les conséquences d’une résiliation (livraison du logiciel
développé, des codes, copies du logiciel en cours de développement, droits
intellectuels…)
17

Quelles responsabilités dans le cadre d’un projet Agile?

Rôles principaux suivant intervention dans les phases
de développement
Product Owner/ Propriétaire du produit agile (chef de projet du
client)
Project Leader/ chef de projet (fournisseur)
Development team Leader/ chef de l’équipe de développement
(fournisseur)
Testing Team Leader (client)
19

Rôles principaux
Importance de définition claire des obligations des parties par rapport
aux différents étapes du processus
P.ex.: Qui décide quoi dans le cadre du sprint backlog, qui doit veiller à la
disponibilité des ressources,…
Quid en cas de litige lors de la prise de décision?
Veiller à la disponibilité de la personne chargée de la fonction
concernée. Prévoir un back-up (en cas de maladie…).
Déterminer les délais pour agir.
Processus de décision à fixer + procédure résolution litige
20

Product owner (Propriétaire du produit agile)
Chef de projet du client
Détermine la priorité des requirements
Représente le client, communique les souhaits au fournisseur
(Product Backlog), et demande et communique les validations du
client requises
Déterminer les limites de pouvoir. Par exemple: pas le pouvoir de
prendre des décisions impliquant des frais supplémentaires par
rapport à ceux prévus dans le contrat initial. (variable selon les règles
internes au client)
Veiller à la disponibilité de la personne chargée de cette fonction,
expérience en la matière,…
21

Project Leader
Chef de projet du fournisseur
Assure la collaboration correcte entre les parties;
Responsable de la bonne conduite du processus;
Coordination générale de l’apport du prestataire
22

Development team Leader
Chef de l’équipe de développement (fournisseur)
Coordination
disponibilité de ressources
Conformité sprint backlog
Identification/résolution problèmes
Avec testing team (anticiper difficultés)
Communication avec les chefs de projets et testing team
23

Testing team leader
Chef de l’équipe des essais(client)
Organisation et coordination tests
Coordination avec équipe développement (scénarios tests + suivi tests)
Préparation des scénarios de test
disponibilité des ressources clients
Validation des résultats de tests
24

Quid pour la fin du projet?
Au début de chaque sprint, s’accorder sur le statut de ce qui est déjà
fait et les points à développer.
Tenir compte du fait que le « product owner » peut décider de laisser
tomber certains éléments.
La définition claire des rôles permet de fixer plus facilement les
responsabilités en cas de difficulté;
L’implication étroite du client n’est pas sans risque
 ce qui est demandé au client = réaliste % ressources internes
(risque de responsabilité du client / de limitation de la responsabilité
du prestataire)
25

Quid en cas de discussion ou litige?
Méthode agile implique des procédures rapides et efficaces
Prévoir une procédure d’escalade (escalation) claire du litige qui
permette de maximiser les chances de résoudre rapidement la plupart
des désaccords susceptibles d’intervenir entre les acteurs du
processus Agile.
Bien définir les étapes de la procédure, le rôle des parties et les délais
à respecter avant la possibilité éventuelle d’entamer une procédure
judiciaire.
26

Merci de votre attention !
N’hésitez pas à nous adresser vos questions !

earlegal #4 - Risques et opportunités de la méthode agile dans les contrats informatiques

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à earlegal #4 - Risques et opportunités de la méthode agile dans les contrats informatiques

Similaire à earlegal #4 - Risques et opportunités de la méthode agile dans les contrats informatiques (20)

Plus de Lexing - Belgium

Plus de Lexing - Belgium (20)

earlegal #4 - Risques et opportunités de la méthode agile dans les contrats informatiques

Notes de l'éditeur