 Your new post is loading...
Your new post is loading...
|
Scooped by
Mickael Ruau
May 25, 2015 2:58 AM
|
L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes. Définir puis partager la Vision du produit est donc cruciale.
La vision synthétique est un excellent point de départ : POUR (public concerné par le produit) QUI SOUHAITENT (formulation du besoin des cibles) NOTRE PRODUIT EST (ce qu’est le produit) QUI (le bénéfice majeur, l’utilité de la solution) A LA DIFFERENCE DE (pratique actuelle, concurrence) PERMET DE (éléments différentiateurs majeurs)
Elle peut se prolonger dans de petits docs. à la structure souvent similaire
|
|
Scooped by
Mickael Ruau
May 18, 2015 2:00 AM
|
The table below contains a list of color names, each displayed in another color. Say aloud the color each word below is written in, rather than the word itself. blue green yellow green greenblue white green blue whiteyellow white blue white redyellow cyan blue cyan blue greengreen cyan cyan yellow red blueyellow white yellow blue greencyan red green
|
|
Scooped by
Mickael Ruau
December 16, 2014 5:05 AM
|
Après une première présentation sur la rédaction des User Stories, je mets à jours une nouvelle présentation.
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:20 PM
|
Construction de la Maison AGILE
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:17 PM
|
Contractualiser un projet AgileGreg Hutchings, le 04 aout 2008Greg.Hutchings@valtech.frComment s’engagersans forfait global?
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:06 PM
|
En l’état du marché, on constate que les appels d’offres pour des projets Agile sont souvent assortis de conditions incompatibles avec cette démarche. Il existe en effet un décalage entre le désir des clients d’appliquer les méthodes Agile et leur crainte de s’engager sur la base d’un contrat Agile. Ce problème de démarche consistant à vouloir bénéficier des avantages de ces méthodes tout en réinjectant de la rigidité contractuelle est aujourd’hui classique alors même que la contractualisation Agile n’induit pas une responsabilité atténuée du prestataire. Pour autant, ce retour au contrat « classique » ne sert pas nécessairement les intérêts du client s’il n’est pas en ligne avec la réalité opérationnelle du projet.
Un client avisé listera et qualifiera précisément les obligations qu’il entend mettre à la charge du prestataire, plutôt que de s’abriter derrière une obligation générale de résultat, incompatible avec la participation active du client au développement de la solution.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:59 PM
|
Xebia a communiqué sur la mise en ligne d'un contrat agile open source: cool, me suis-je dit.
Je lis le texte et je commence déjà à avoir des remontées gastriques.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:50 PM
|
Comment rédigez-vous un contrat au forfait sur une proposition Agile embryonnaire ? Ce n’est pas aussi difficile que certains le font paraître mais cela implique un vrai changement de mentalité et un exercice d’apprentissage pour tout un chacun. Clairement définir « fait » (« done »), évaluer des histoires et comprendre la vélocité sont clés à la réussite.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:14 PM
|
La méthode agile et le droit
L’approche première du juriste est de dire : l’objet de la prestation n’est pas clairement déterminé.
En bref : le client s’engage à payer une prestation qu’il n’est pas encore parfaitement définie.
Est-ce grave?
Sur le principe non. En revanche sur les modalités de mise en œuvre, il faudra être particulièrement vigilant.
Sur le principe, il convient de rappeler qu’un contrat doit avoir un objet licite et déterminé ou déterminable. Le contrat portant sur le développement d’un logiciel ou de la création d’un site web est un contrat de prestation de service portant une obligation de faire à la charge du prestataire. En telle matière, il est fréquent que le périmètre de la prestation ne soit pas parfaitement délimité. Cela n’est pas de nature à remettre en cause la validité du contrat.
Sur les modalités de mise en œuvre, la question est plus épineuse.
Tout d’abord il conviendra de déterminer la forme contractuelle appropriée. Faut-il rédiger un seul contrat ? Faut-il au contraire signer un contrat cadre puis des contrats correspondants aux différents sprints ?
Quelle que soit la solution retenue (qui variera en fonction de l’importance du projet), il est toujours essentiel de bien s’entendre sur les termes du contrat qu’il faut convenablement rédiger.
Il faudra donc être particulièrement vigilant sur au moins deux points :
la rédaction de la clause de recette ;
la clause de sortie à l’issue d’un sprint.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:11 PM
|
Introduction
I. La Qualification du contrat
1. La Détermination des obligations des parties
1.1 Les Obligations du prestataire
1.2 Les Obligations du client
2. La Recherche d'un cadre juridique
2.1. Le Contrat de louage d'ouvrage
2.2. Le contrat de société
II. Le régime juridique du contrat agile
1. Droit applicable
1.1 droit du contrat
1.2 Réglementations diverses
2. Responsabilité et contentieux
2.1 La formation du contrat
2.2 L'exécution du contrat
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:00 PM
|
L’expérience montre que figer l’expression par le client de ses besoins en début de projet conduit à contractualiser les projets informatiques sur un mode statique là où ils sont en réalité dynamiques. Or, la complexité des projets informatiques ne peut être niée. Elle doit au contraire être appréhendée comme l’un des paramètres du projet afin que tout problème puisse être identifié et résolu rapidement.
En outre, cette distorsion entre pratique des projets informatiques et modes de contractualisation génère un contentieux fourni.
|
|
Scooped by
Mickael Ruau
December 8, 2014 12:50 PM
|
Les besoins métiers peuvent évoluer pendant la phase de conception d’un projet et la description initialement figée dans le contrat peut se révéler approximative ou fausse.
Si le contexte l’exige, le responsable du contrat devra alerter les contractants et proposer un dispositif contractuel qui permettra de compléter ou de réviser aussi souvent qu’il le faudra, le référentiel du contrat. Il proposera des rendez-vous – ateliers et comités – pour affiner la conception de la solution et en cadrer le référentiel. Les phases de réalisation pourront alors leur succéder. On voit donc une alternative à l’exemple cité précédemment (roadmap détaillée et contractualisée) : les équipes affinent au fur et à mesure la solution et alimentent un référentiel documentaire qui fera partie du périmètre contractuel.
La phase de conception peut alors être étalée dans le temps ce qui procure une certaine souplesse au client. La collaboration est la pièce maitresse du dispositif « agile » : c’est la collaboration entre les équipes dans des instances adaptées qui permettra de construire ou de modifier le référentiel du contrat. La gouvernance fournit le cadre dans lequel s’exprimera la richesse des équipes. A la notion de cahier des charges on préfère alors celle de 'BackLog' : la solution est spécifiée par les équipes client et fournisseur en collaboration étroite et par itérations successives.
Pour la réalisation d'entretiens ou la conduite de panels-groupes, nous avons mis en place un outil de recherche qui ne repose plus sur un guid...
Via Louis Levy, CECI Jean-François
|
|
|
Scooped by
Mickael Ruau
May 22, 2015 3:00 AM
|
Plus j’interviens dans les projets de développement informatique (Logiciel, Application Web, Sites Internet, INTRANET, EXTRANET …), plus je m’aperçois du caractère essentiel mais complexe, de trois activités, qui bien menées, maximisent pourtant les chances de réussite des projets:
- Recueillir et exprimer le besoin (Expression des besoins, Cahier des Charges, Vision …)
- Spécifier le besoin (Dossier de spécification, SRS, Use cases, User stories …)
- Gèrer et tracer les exigences (Backlog de produit, Liste des exigences, manuelle à base d’attributs ou sur des outils dédiés)
|
|
Scooped by
Mickael Ruau
December 18, 2014 9:13 AM
|
Cahier des charges pour une infrastructure informatique.
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:21 PM
|
Histoire de la mise au point et de l'utilisation d'un contrat agile type à la DSI du Courrier.
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:19 PM
|
Cette session vous présente comment utiliser le pilotage par la valeur comme pivot de la relation métier / IT aux niveaux portefeuille, programme et équipe et comment la valeur devient le pivot de la relation client / fournisseur avec un contrat agile.
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:12 PM
|
Ma vision
Solution simple : l'assistance technique (AT)
Oui "Faire et défaire c'est toujours facturer" mais en AT le client est libre de choisir ces ressources, de remplacer une ressource d'une société par une autre...
La relation de confiance est obligatoirement présente si l'équipe veut rester sur le projet.
Un forfait puis après la recette (ou mise en production) : Migration en Agile (en Assistance Technique)
Généralement le client arrive à exprimer son besoin, tous les besoins "flous" seront intégré en mode Agile plus tard; si le besoin est flou, c'est que le client ne sait pas encore ce qu'il veut, il faut donc attendre d'avoir une première version de l'application disponible ou bien de voir comment les utilisateurs vont s'approprier l'application.
La première version de l'application peut être le socle technique plus une série de fonctionnalités "classiques" (espace membre, gestion d'un caddy etc...)
|
|
Scooped by
Mickael Ruau
December 8, 2014 2:02 PM
|
Le périmètre est la variable d'ajustement
A ce client prêt à effectuer la transition vers l'agilité, je conseille d'élaborer un appel d'offres Agile (AOA), dans lequel c'est un processus de développement agile qui est préconisé aux fournisseurs (par exemple Scrum, qui est le plus simple à mettre en oeuvre). Le budget et le délai, au lieu d'être demandés aux fournisseurs, sont fixés par le client et annoncés dans l'AOA. Le plus souvent le client est bien incapable de donner ses exigences précises, il exprime simplement des souhaits, au mieux une vision qu'il a du produit futur. Partant de ce principe qu'il est impossible de définir le périmètre fonctionnel à l'avance, le client fournit simplement sa vision du projet dans l'AOA. Le périmètre deviendra la variable d'ajustement.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:58 PM
|
Nous avons définit dernièrement, pour deux clients différents, deux méthodes de contractualisation agile adaptés pour le secteur public
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:15 PM
|
Le sujet du contrat au forfait sur les projets Agiles est discuté depuis longtemps, j'y ai moi même consacré un peu de temps il y a quelques années et j'en ai aussi parlé en conférence.
Je passe sur les différents points de vue quand aux détails ou au limites du terme "forfait" pour arriver au cœur du sujet : la volonté pour un client de déléguer la réalisation d'un logiciel à un fournisseur.
Il semble que la question fondamentale sur laquelle tout le monde s'accorde est celle de la relation entre la façon de définir le contrat et les comportements qui vont en résulter.
L'idée, c'est que le type de contrat en usage dans le domaine du logiciel ne laisse pas la place aux comportements en phase avec les pratiques Agiles. Partant, un autre type de contrat doit être recherché pour permettre aux pratiques Agiles de trouver leur place dans la sous-traitance. CQFD
Cette idée, que le contrat est le problème à adresser "à priori", est fausse. Ce n'est pas au contrat de permettre l'adoption de nouveaux comportements, c'est juste l'inverse.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:13 PM
|
Ce document est sous contrat Creative Commons Paternité-Partage des
Conditions Initiales à l'Identique 2.0 France License
Vous n'avez pas le droit de commercialiser le contrat et ses versions amendées mais pouvez l'utiliser
dans le cadre d'une collaboration client/fournisseur.
|
|
Scooped by
Mickael Ruau
December 8, 2014 1:09 PM
|
L’une des options pour arriver à un contrat complètement synchronisé avec une organisation “gagnant – gagnant” est d’avoir un enchaînement de contrats comme nous l’explique Greg Hutchings dans son article “Contract Evolution on a Large Agile Project“. Dans l’exemple qu’il présente dans cet article, l’évolution contractuelle n’a pas été prévue dès le départ mais elle a été la conséquence de l’évolution de la relation client/fournisseur et, dans un second temps de la maturité du projet. Voici les quatre types de contrats qu’il préconise : - Contrat avec un prix et un périmètre fixes : il s’agit du mode traditionnel qui résulte du manque de confiance entre les deux parties. Comme je l’ai indiqué plus haut, pour limiter les risques importants, il faudrait à minima éviter de partir dans un cycle séquentiel et restreindre la durée du contrat.
- Contrat en mode équipe dédiée par itération avec bonus / malus : ce type de contrat est réalisé en mode Agile mais avec plus de confiance, de la part du client qui accepte de passer en mode équipe dédiée (plus intéressant financièrement) mais qui veut néanmoins garder un “contrôle” en jouant sur deux paramètres : qualité des livrables et vélocité de l’équipe. Ces facteurs peuvent bonifier ou pénaliser le prix final. Je préfère nettement le premier cas mais cela peut malgré tout avoir une influence négative sur la transparence et sur certains “jeux” de l’équipe qui fera tout pour éviter les malus.
- Contrat avec des prix fixés par unité de travail : dans ce type de contrat, le système bonus/malus est supprimé. Le client et l’équipe doivent bien intégrer la notion d’unité de travail : points relatifs associés aux cas d’utilisation. Le coût de chaque itération dépend ici du nombre de points relatifs livrés à la fin de l’itération. Greg Hutchings considère, et je suis d’accord avec lui, que ce type de contrat est idéal pour chacune des parties. Par contre, pour arriver à une bonne estimation basée sur l’unité de travail, il faut prévoir une analyse plus détaillée et un décalage de deux sprints environ par rapport au sprint d’implémentation (l’analyse et l’estimation du sprint N se fait au sprint N-2).
- Contrat en mode équipe dédiée – plafonné par itération : ce type de contrat est bien adapté pour les phases de maintenance. Le client a un budget fixé annuellement et le périmètre est variable.
D’autres types de contrats existent également et incluent explicitement le partage des risques et/ou pertes/profits pour assurer un alignement parfait entre les objectifs des deux parties et contractualiser la philosophie “win-win”. Je reviendrai sur ces contrats dans un prochain article. Pour terminer sur ce sujet, je suis complètement d’accord avec Craig Larman qui dit que les bons contrats sont ceux qui soutiennent la mise en place des valeurs Agile comme : la transparence, la collaboration et donc la confiance. Je considère que la confiance est l’élément clé permettant, une fois acquise, le relâchement du modèle contractuel pour assurer un des quatre principes du Manifeste Agile “La collaboration avec les clients plus que la négociation contractuelle.” et donc maximiser la valeur produite.
|
|
Scooped by
Mickael Ruau
December 8, 2014 12:51 PM
|
En gestion de projet traditionnel, les contraintes entourant un projet sont généralement celles-ci :
Portée (fonctionnalités)
Durée
Coûts
Ces contraintes se retrouvent illustrées sous la forme du « triangle de projet ».
Dans un modèle agile, le triangle traditionnel fait l’objet de distorsion puisque les contraintes sont observées sous un paradigme différent.
|
|
Scooped by
Mickael Ruau
October 2, 2014 1:41 PM
|
Une recommandation est de confier le pilotage du processus à un expert ayant une connaissance du domaine et une indépendance des acteurs vis-à-vis du marché afin de s’assurer que la recommandation finale ne soit pas biaisée.
|
