Aspects juridiques de la contractualisation agile

ANNEXE 3

Estimation de charges, structure et délais du PRESTATAIRE

ANNEXE 4

Plan Qualité de Service

Version initiale

1. Contexte d'utilisation du plan

L'objectif de ce Plan de Qualité de Service est de présenter les dispositions prises par CLIENT et par l'équipe projet pour :

- Organiser le déroulement du projet. - En assurer la qualité.

Ce plan de qualité de service (désigné tout au long du document par l'acronyme PQS) est :

· Un document de référence pour tous les acteurs du projet. Il permet de partager une vision commune entre CLIENT et PRESTATAIRE.

· Un engagement sur les critères de qualité du projet. Il est réalisé en collaboration avec CLIENT et approuvé par lui.

· Un descriptif de la gouvernance du projet.

Chaque partie se doit de respecter le PQS dans sa dernière version amendée au contrat.

2. Domaine d'application

Description du contexte du projet.

Exemple : ...

1. Présentation

2. Contexte

3 .Objectifs

3. Responsabilité de l'assurance qualité

1. Responsables

Conformément aux principes de la méthodologie agile SCRUM, l'ensemble des membres de l'équipe est responsable de la qualité du projet et se doit ainsi de respecter les engagements pris dans le présent PQS.

XX XXX, en tant directeur de projet, se porte garant du respect du PQS, au nom de l'équipe et au nom de PRESTATAIRE.

YY YYY, en tant que chef de projet, se porte garant du respect du PQS, au nom du CLIENT

Cette section décrit l'ensemble des dispositions à mettre en oeuvre pour s'assurer du bon déroulement de la prestation.

4. Suivi de l'exécution du plan

1. Pilotage

Bilan de Sprint	Revue des indicateurs de performance et décisions associées, point sur les risques		· Chef de projet CLIENT · Directeur de Projet PRESTATAIRE	Comité de pilotage
Revue de l'avancement de la release en cours et du planning de mise en production, point sur les risques et problèmes, revue de la capacité d'exécution	· Chef de projet client · Directeur de Projet PRESTATAIRE · Product Owner · Scrum Master

2. Critères de suivi de la prestation

Afin de s'assurer du niveau de qualité de la prestation, PRESTATAIRE propose des critères qualitatifs et quantitatifs qui sont évalués par des indicateurs.

Ces indicateurs servent à mettre en lumière des situations anormales, par exemple :

- Baisse de la productivité

- Instabilité de l'équipe

- Défaut de qualité du produit

Ces situations peuvent être dues à des événements indépendants des deux parties ou un manquement d'une ou des deux parties.

Des seuils sont fixés pour chaque indicateur.

Le franchissement d'un de ces seuils déclenche une analyse causale en comité de pilotage. Des pénalités financières seront appliquées dans le cas où PRESTATAIRE aurait manqué à ses engagements. (SI l'option des pénalités n'est pas retenue -> supprimer le paragraphe 6.3 du contrat)

La méthode de calcul et le montant des pénalités sont spécifiés dans l'annexe financière.

3. Liste des critères évalués par un indicateur

Critères avec seuil d'alerte

- Prédictibilité

- Productivité de l'équipe

- Qualité du logiciel délivré : Technique et fonctionnelle

Critère	Prédictibilité
Objectif	Suivre le respect du périmètre fonctionnel de chaque itération
Définition	Nombre de fonctionnalités démontrées en fin d'itération par rapport aux fonctionnalités prévues.
Mesure	Soit A = Somme des points de complexité
	correspondant aux fonctionnalités		livrées et
	démontrées en fin d'itération.
	Soit B = Somme des points de		complexité
	correspondant aux fonctionnalités		prévues en
	réunion de planification d'itération.
	Prédictibilité = (A/B)*100
Unité de mesure	%
Seuils	Objectif	100 %
(phase opérationnelle)	Alerte	< 75 %

e de lance e de lance

Critère

	Productivité
Objectif	Suivre la capacité de l'équipe à enrichir le produit à chaque itération
Définition	Le nombre de «story points » qui ont été implémentés dans un sprint rapporté à la taille de l'équipe.
Mesure	Soit A = Somme des «story points » correspondant aux fonctionnalités livrées et démontrées en fin d'itération. Soit B = Charge totale de l'équipe. Productivité : X = (A/B)
Unité de mesure	N/A
Seuils (phase opérationnelle)	Objectif	A définir à l'issu de la phas
	Alerte	A définir à l'issu de la phas

e de lance

Critère

	Qualité du logiciel livré : Fonctionnelle
Objectif	Suivre la qualité du logiciel livré du point de vue fonctionnel
Définition	Nombres d'anomalies (y compris régressions) découvertes après la livraison de l'incrément de produit.
Seuils (phase opérationnelle)	Objectif	0
	Alerte	A définir à l'issu de la phas

8

40

Critère

	Qualité du logiciel livré : Technique
Objectif	Suivre l'évolution de la dette technique
Définition	A minima, couverture de code (non généré) par les tests unitaires et complexité cyclomatique.
Mesure	Mesure automatique à l'aide d'un outil adapté
Seuils (phase opérationnelle)	Objectif	Couverture de code : 85% Complexité cyclomatique :
	Alerte	Couverture de code < 60 % Complexité cyclomatique >

Critères sans seuil d'alerte

- Implication de l'équipe

- Satisfaction client

Critère	Implication de l'équipe
Objectif	Mesurer l'implication de l'équipe
Définition	Une mesure de l'implication des membres de l'équipe au sein de l'équipe et de l'organisation.
Mesure	Lors de chaque rétrospective d'itération chaque membre de l'équipe réponds à la question suivante : « Sur une échelle de 1 à 5, recommanderiez vous cette équipe et ce projet à un de vos collègues ? »
Outil de mesure	Moyenne des notes
Unité de mesure	Note de 0 à 5
Objectif	5

Comme spécifié dans le paragraphe 5.1 (« Découpage des prestations ») du contrat agile, le projet est découpé en trois grandes phases :

Critère	Satisfaction client
Objectif	Mesurer la satisfaction du client
Définition	Une mesure de la capacité de l'équipe à répondre aux attentes du client.
Mesure	A l'issu de chaque démonstration chaque personnes impliquées dans le projet coté client doit répondre à la question suivante : « Sur une échelle de 1 à 5, recommanderiez vous cette équipe et ce projet à un de vos collègues ? »
Outil de mesure	Moyenne des notes
Unité de mesure	Notes de 0 à 5
Objectif	5

5. Documents applicables et de références

Le projet devra se dérouler selon les principes de la méthodologie SCRUM décrite dans l'Annexe 1 du contrat.

Tout au long du projet, les deux parties pourront se référer à l'annexe 2 du contrat : « Vision (Cahier des charges) ». Ce document décrit les objectifs du projet et donne les grandes fonctionnalités attendues du produit à réaliser.

Enfin, le montant de la prestation, l'échéancier de paiement et la méthode de calcul du montant forfaitaire d'éventuelles pénalités se trouvent dans l'annexe 6 : « Annexe financière »

6. Terminologie

La terminologie liée à la pratique de la méthodologie agile SCRUM est entièrement définie dans le contrat agile dans l'annexe 1 « Méthodes Agiles »

7. Organisation du projet

- Phase de lancement

- Phase opérationnelle

- Phase de finalisation

-

Phase de lancement

La phase de lancement du projet se découpe en deux parties :

- Sprint 0 : Le contenu et les objectifs du Sprint 0 sont décrits dans le contrat (5.1.1)

- Sprints 1 à 3 : Les sprints 1 à 3 sont des sprints de production dont les objectifs sont :

o Délivrer des incréments de logiciels.

o Stabiliser les indicateurs choisis pour suivre le projet. A l'issue du sprint 3, PRESTATAIRE s'engage sur la valeur définitive des seuils d'alerte pour chaque indicateur.

Phase opérationnelle

La phase opérationnelle est une succession de Sprints à l'issue desquels PRESTATAIRE livre des incréments de logiciel.

Ces incréments sont testés et validés par CLIENT lors de recettes incrémentales. Phase de finalisation

Finalisation régulière :

Un comité de pilotage exceptionnel défini le contenu des deux dernières itérations du projet. Arrêt anticipé du projet :

CLIENT à la possibilité d'interrompre le projet lorsqu'il considère que le projet a atteint des objectifs suffisants.

Les modalités de cet arrêt anticipé sont spécifiées dans le paragraphe 17.2 du contrat agile : « Atteinte anticipée des objectifs du client »

8. Pratiques d'ingénierie

Les pratiques d'ingénierie suivies par PRESTATAIRE se basent principalement sur des techniques issues de l'eXtreme Progamming (XP). L'XP est un ensemble de 13 pratiques dont la définition est consultable à l'adresse suivante : ( http://fr.wikipedia.org/wiki/Extreme_programming) PRESTATAIRE systématise l'utilisation de quatre d'entres elles :

- Développement piloté par les tests (appelé aussi TDD)

- Propriété Collective

- Normes de développement

- Programmation en binôme (Pair Programming)

Il aurait fallu évoquer toutes les méthodes susceptibles d'inspirer les pratiques de développement du

projet, en effet l'annexe 1 précise que le projet sera piloté selon les méthodologies « scrum » et « XP ». L'annexe 1 contient déjà une description de ces méthodes. Se référer à l'article de Wikipedia pour la définition de XP consiste à lui donner valeur contractuelle, en cas de divergences entre ces deux sources c'est l'annexe 1 qui prévaudra (voir 4.2). C'est préférable car un article Wikipedia est modifiable par tout internaute, il suffit de créer un compte en quelques clics pour pouvoir contribuer à l'encyclopédie.

9. Gestion des modifications

Les demandes de changement sont de deux types :

· Anomalie: écart constaté avec les critères d'acceptation d'une story (cf. Définition d'une story dans le contrat agile : Annexe 1)

· Evolution: L'écart est du à une modification, un ajout ou une suppression au niveau des spécifications des besoins

Le processus détaillé de gestion des modifications est à définir en phase de lancement, en respectant les principes suivants:

· A la fin de chaque itération, un PV de recette provisoire est signé sur la base des éléments prévus en début de sprint et démontrés en fin de sprint, il mentionne les éventuels anomalies et évolutions souhaitées

· CLIENT dispose ensuite de 2 semaines maximum pour effectuer la recette partielle ou complète d'un incrément

· Les retours de démonstration mentionnés dans le bon de livraison sont traités dans le sprint N+1

· Les retours de recette sont planifiés par défaut dans le sprint N+2

ANNEXE 5

Conditions Particulières

au Contrat de prestation de

services réalisés selon les

Méthodes Agiles

1. RÉFÉRENCE CONTRACTUELLE / OBJET

ENTRE :

<DÉNOMINATION SOCIALE>

Société <forme juridique> au capital social de <montant> euros, inscrite au RCS de <ville> sous le numéro <numéro>, dont le siège social est sis <adresse>.

Représentée par <nom>, agissant en sa qualité de <statut>, dûment habilité à l'effet des présentes.

Ci-après dénommée le « Client »

D'une part

ET :

LE PRESTATAIRE

<Raison Sociale, Adresse, RCS>

Représentée par le signataire du présent contrat, dûment habilité à l'effet des présentes.

Ci-après dénommée « LE PRESTATAIRE »

D'autre part

Ces stipulations apparaissent contraires à celles de l'article 5.3 (« personnels affectés à la réalisation des prestations », voir note sous l'article 5.3 ; voir II, 1.2 Réglementations diverses).

Les présentes Conditions Particulières sont prises en application du Contrat en référence. Elles ont pour objet de compléter et/ou amender la lettre et la portée dudit Contrat. La signature par le CLIENT des Conditions Particulières emporte acceptation expresse des termes dudit Contrat qui n'auront pas été complétés et/ou amendés. Les termes en majuscule figurant aux présentes sont définis au sein dudit Contrat.

2. COMPLÉMENTS / AMENDEMENTS AU CONTRAT