tag:blogger.com,1999:blog-7705671659201281415.post6016749696570417947..comments2023-02-04T18:12:48.847+01:00Comments on Xavier blogue un peu ...: Forfait, marché public et agilité : petit REXXavier NOPREhttp://www.blogger.com/profile/05819244619625995331noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-7705671659201281415.post-18241348093938337342011-11-07T23:44:30.733+01:002011-11-07T23:44:30.733+01:00@Emilie : je suis du genre pragmatique ...
Donc, ...@Emilie : je suis du genre pragmatique ...<br /><br />Donc, s'il existe des tests unitaires, tant mieux, super ! Sinon, s'il n'y en a pas, je ne vais pas refuser d'intervenir sur un code, mais je prends , plus d'attention, plus de tests manuels !<br /><br />Pour la qualité et les améliorations, il faut y aller petit à petit. Comme je dit lorsque je parle de tests unitaires et TDD : "Commencez petit, là où vous le sentez, là où c'est propice, mais toujours un peu et encore un peu, ce sera toujours ça, et toujours mieux que rien !".Xavier NOPREhttps://www.blogger.com/profile/05819244619625995331noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-2001928297232769522011-11-07T23:39:42.941+01:002011-11-07T23:39:42.941+01:00@Pablo : Salut Pablo !
Effectivement, c'est ...@Pablo : Salut Pablo ! <br /><br />Effectivement, c'est un REX sur une expérience qui s'est bien passée. <br /><br />Le problème avec l'agilité, c'est qu'on va avoir besoin de confiance et de transparence. Dès lors qu'une des parties commence à craindre un conflit, à mettre des billes de côté "au cas où", le doute s'installe, la confiance n'y est plus, le projet en mode agile est voué à l'échec.<br /><br />Il faut vraiment oublier les "anciens" réflexes, il faut y croire ensemble, main dans la main, dans le même bateau, dès le début et jusqu'à la fin. Avec le client, il faut former une <b>équipe</b> pour la <b>réussite ensemble</b> du projet. Nous serons tous responsable du succès ou de l'échec ! Oui, je sais, c'est simpliste, c'est mon côté optimiste ...<br /><br />Tous les projets et toutes les équipes ne sont pas éligibles à l'agilité. Il en va de même pour les affaires et les clients, il faut un contexte positif dès le début. Si les premiers échanges, les premières explications, n'initient pas une petite étincelle, mieux vaut faire autrement, non ?<br /><br />Tout le plaisir était pour moi de cette brève rencontre à Marseille, et merci pour le Marshmallow ;-)Xavier NOPREhttps://www.blogger.com/profile/05819244619625995331noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-75915242491451052332011-11-07T19:43:34.187+01:002011-11-07T19:43:34.187+01:00Merci Xavier pour le complément, cela répond tout ...Merci Xavier pour le complément, cela répond tout à fait à ma question !<br />Ca n'a probablement pas été facile de se lancer dans les évolutions "sans filet" (comment être sûr de ne pas casser qqch ailleurs...). Toutefois, cela répond aux attentes de ton client, surtout sachant qu'ils ne comptent pas faire évoluer beaucoup l'application par la suite. Et comme tu l'as dit, là où tu as pu et où tu es intervenu, tu as eu le souci d'améliorer la qualité (le développeur du futur, ici, ça peut encore être toi ;-).Emilienoreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-58940094004723587732011-11-07T18:28:36.628+01:002011-11-07T18:28:36.628+01:00Hello Xavier,
Oui à mon avis c'est une bonne...Hello Xavier, <br /><br />Oui à mon avis c'est une bonne pratique de ne pas embarquer les mots clefs agiles pour simplifier une relation ou une mise en confiance. <br /><br />Mais pour les projets au forfait : "tout va bien lorsque tout va bien". Peux-tu extrapoler et imaginer ce qui se serait passer en cas de conflit, de désaccord, de pression ? <br /><br />Ok pour les projets "au forfait" qui dissimulent un engagement de moyens car les deux parties sont capables de s'entendre là dessus. <br /> <br /><br />Ravi d'avoir fait ta connaissance lors de l'agile marseille.pablohttp://www.areyouagile.comnoreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-42985085859053577982011-11-07T18:21:39.708+01:002011-11-07T18:21:39.708+01:00@sanlaville : Salut Rémy !
Concernant le Référent...@sanlaville : Salut Rémy !<br /><br />Concernant le <b>Référentiel des fonctionnalités</b>, voir les explications dans un commentaire précédent. Est-ce que ça répond à ta question ?<br /><br />Mes critères pour évaluer la satisfaction du client ont été son sourire et son enthousiasme ... ;-)<br /><br />Plus sérieusement, à chaque réunion d'itération, je faisais une démonstration de chaque fonctionnalité (i.e. <i>histoire</i>). Je m’efforçais alors de bien vérifier si cela correspondait aux attentes. Mes 2 interlocuteurs étaient très tolérants, en partie parce qu'ils ont vite été en confiance dans notre relation (je pense), j'ai donc dû m’astreindre à être très rigoureux sur la satisfaction de chaque fonctionnalité, en étant exigeant avec moi-même.<br /><br />Donc plus globalement, pas de critères de satisfaction, le projet et le contexte ne semblait pas le nécessiter, mais ça peut être une bonne approche. Juste des ressentis, apparemment très positifs, peut-être en partie dus à la rigueur évoquée précédemment ... Et tout de même un retour très concret lorsqu'en fin de projet, le client m'a dit que mon approche était "super" et avait répondu "au-delà" de ses attentes, probablement en comparaison d'expériences passées et plus .... classiques et figées ...<br /><br />Concernant la valeur apportée :<br />* sur le projet lui-même : une mise en production à la moitié et dès la fin du projet avec des premiers retours utilisateurs la semaine suivante, et l'annonce par le client d'une phase supplémentaire d'ici quelques mois<br />* sur la gestion du projet : une réelle flexibilité, un droit au changement concrétisé par une maitrise des priorités par le client<br />* sur l'application existante : une expertise et un œil neuf :<br /> . sur l'ergonomie (remarques et propositions au client) : simplifications des pages et formulaires, détections automatiques de doublons, fenêtre type "dialog" plutôt que "popup", ergonomie dynamique, etc ...<br /> . mais également plus techniquement, sur les sources (moins visible par le client) : amélioration des requêtes SQL, meilleure cohérence globale, introduction de conception objet pour simplifier et améliorer la lisibilité, etc ...Xavier NOPREhttps://www.blogger.com/profile/05819244619625995331noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-89249452063620623652011-11-07T17:57:05.046+01:002011-11-07T17:57:05.046+01:00@C.Monnier : encourageant ? Tant mieux !
Effectiv...@C.Monnier : encourageant ? Tant mieux !<br /><br />Effectivement, il s'agit d'un MAPA ou MPA (Marché à procédure adaptée). Je ne suis pas sûr de pouvoir en dire d'avantage, et en plus, je découvre ce domaine dans lequel je suis loin d'être expert ... Là n'est pas l'important, mais comme vous le suggérez, il y avait bien un cahier des charges (plus ou moins) sous forme de CCTP.<br /><br />Et "oui" : le projet n'a pas respecté le cahier des charges ou CCTP ... Je m'explique.<br /><br />Je propose une approche agile pour donner au client le droit au changement, c'est-à-dire changer d'avis sur le contenu fonctionnel : modifier des fonctionnalités, en ajouter ou en supprimer. Le contenu est ajustable, ce qui ne l'est pas, c'est le volume de travail, donc les moyens (coûts) et les délais (même si ces derniers ont été ajustés en totale collaboration). Dans ce contexte de changements possibles, il est donc impossible de respecter un cahier des charges !<br /><br />C'est pour cela que j'ai introduit la notion de <b>"cahier des charges initial"</b>, en précisant dès le début, en expliquant la méthode, que le cahier des charges représente ce que le client <i>"aimerait avoir"</i> aujourd'hui (à l'instant t), mais pas ce qu'il <i>"aura"</i> ! Et finalement, je lui démontre que ça ne change pas d'une approche "classique" qui est un <b>leur</b>, mais qu'au moins, on met cela sur la table et on en tire profit ... (je pourrais détailler dans un autre article)<br /><br />Merci pour vos réactions !Xavier NOPREhttps://www.blogger.com/profile/05819244619625995331noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-48635535883668040012011-11-07T15:49:38.175+01:002011-11-07T15:49:38.175+01:00Merci de partager ce REX intéressant.
Je te rejoi...Merci de partager ce REX intéressant.<br /><br />Je te rejoins sur le fait qu'un point important est le fait d'avoir un bon référentiel des fonctionnalités et que c'est une colonne vertébrale pour le bon déroulement du projet. Je suis intéressé pour savoir comment<br />tu t'y es pris pour reformuler le besoin avec tes 2 interlocuteurs. Sous quelle forme les as-tu décrit ?<br /><br />Une difficulté est souvent que les Product Owner qui commencent avec l'agilité, pense que comme on peut changer, il n'y a pas besoin de définir des spécifications.<br /><br />- Un de tes objectifs était de "Satisfaire les utilisateurs finaux et donc mon client"<br />Aviez-vous définis des critères particuliers pour indiquer que ton client était satisfait ?<br />Comment pourrais-tu définir la valeur/plus-value que tu as apporté à ton client ?<br /><br />Rémysanlavillehttps://www.blogger.com/profile/11937176214913509036noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-41764963913408889232011-11-07T15:43:59.505+01:002011-11-07T15:43:59.505+01:00Merci pour votre article clair et encourageant.
Po...Merci pour votre article clair et encourageant.<br />Pourriez-vous préciser de quel type de marché public vous parlez svp ? (mapa, consultation hors marché avec simple publicité, etc...).<br /><br />En général, un marché public se base notamment sur un CCTP ? est-ce ce que vous appelez "cahier des charges" en entrée ? Est-ce à dire que votre projet a respecté les souhaits et satisfait votre client (facteur important nous sommes bien d'accord :),... mais sans respecter le CCTP (ou cahier des charges) ? <br /><br />C'est bien là que se pose le problème des projets agiles en marchés publics à mon avis ; et votre article, très intéressant par ailleurs, ne précise pas comme ce dilemne a été résolu. <br /><br />merci de votre retour. <br />C.MONNIERAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-91281073893581300112011-11-07T14:43:01.172+01:002011-11-07T14:43:01.172+01:00@Emilie : concernant l'application existante, ...@Emilie : concernant l'application existante, c'était du PHP/MySQL "à l'ancienne" dont j'avais eu un aperçu lors d'un précédent contact. Donc pas d'usine logicielle, pas de tests, pas vraiment d'architecture, juste quelques inconnues sur les solutions mises en place (gestion des formulaires, validations, interface BDD, ...). Mais effectivement, dans mes estimations, j'ai pris en compte une répartition d'un "ticket d'entrée", surtout pour certaines parties (pages) que j'imaginais plus complexes.<br /><br />Comme je l'ai expliqué dans le commentaire précédent, j'ai beaucoup travaillé avec le client sur l'expression des ses besoins, et j'ai pris en charge le reste. Je rappelle le contexte : organisme public, 2 interlocuteurs pas du tout informaticiens, simplement utilisateurs de leur application (qu'ils connaissent bien) et de certains points précis qu'ils en attendaient. Pour compléter le tableau, le projet visait à améliorer le système existant en attendant une migration possible d'ici 2 ans vers un système tout autre. Donc, le focus pour le client était sur les évolutions fonctionnelles, pas trop d'approche pérenne ...<br /><br />Le client avait également comme souhait d'augmenter le taux d'utilisation de l'application par les agents (en interne). J'ai donc mis pas mal d'énergie à proposer des changements et des nouveautés pour avancer sur ce point : allègement de certains formulaires selon les remontées des utilisateurs finaux, ajout de comportements dynamiques dans les pages pour une interface plus simple, plus intuitive et plus conviviale (javascript, jQuery, ajax, ...), etc ...<br /><br />Donc, pour te répondre, j'ai eu en permanence le soucis de l'amélioration de la qualité de l'application existante, mais le chantier était assez conséquent : présence d'anciennes mauvaises pratiques en grand nombre. Je pense donc avoir augmenté cette qualité, un peu, notamment sur les parties que j'ai retouchées, mais il reste pas mal de points négatifs que je n'ai pas pu traiter (faute de moyens). Mais c'est un sujet que j'ai commencé à évoquer avec le client, et que je remettrai à l'ordre du jour lors de ma prochaine intervention (prévu d'ici quelques mois).<br /><br />Ai-je répondu à tes questions et attentes ?Xavier NOPREhttps://www.blogger.com/profile/05819244619625995331noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-57045586410855198862011-11-07T14:23:16.344+01:002011-11-07T14:23:16.344+01:00Bonjour et merci pour l'intérêt porté à ce REX...Bonjour et merci pour l'intérêt porté à ce REX et pour vos commentaires !<br /><br />@Marc : ce "Référentiel des fonctionnalités" n'est autre qu'un document texte rédigé avec mon traitement de textes préféré. Le cahier des charges initiale était composé de 2 parties :<br />- 1/ une partie "améliorations" pour répondre à une charte qualité, essentiellement basées sur des captures d'écrans annotées par du texte peu clair<br />- 2/ une liste d'anomalies existantes à corriger, parfois très précises (ex : "Mauvais code postal pour ..."), parfois très vague ("Manque certaines données quand on fait une recherche")<br /><br />C'est essentiellement dans la première partie qu'il y avait des expressions de "solutions" sur lesquelles j'ai pas mal travaillé avec le client pour comprendre son métier, l'application existante, et le véritable besoin. C'est comme cela que des "Ajouter une case à cocher ..." sont devenus des "Compléter la liste de choix existante ...", et inversement.<br /><br />Il y a donc effectivement eu un gros travail d'échanges et discussions avec le client pour comprendre tout le cahier des charge initial, le reformuler et donner des estimations en points. C'est comme ça qu'est né ce "Référentiel des fonctionnalités" correspondant au "Carnet de produit". Il reprend les 2 grandes parties du cahier des charges et présente les tâches sous forme de tableaux avec les informations suivantes :<br />- formulation initiale (pour que le client retrouve bien ses petits)<br />- reformulation ou complémentes d'informations<br />- estimation<br />- état (apparu à la fin de l'itération 1 pour noter les histoires réalisées et avoir ainsi un véritable "référentiel")<br /><br />Pour chaque partie, comme je l'ai dit, les histoires manquant de précisions et ne pouvant donc pas être chiffrées précisément, étaient présentées séparément, dans une sous-partie "A préciser". Il est intéressant de constater que ces chapitres n'ont quasiment pas bouger, pas de traitement de ces histoires, le client ayant compris très vite de lui même que ces tâches ne seraient pas traitées. La principale explication est que pour bon nombre de ces tâches, le client ne savaient plus bien de quoi il s'agissait, ni qui les avait fait remonter, donc impossible de les préciser ...<br /><br />Pour répondre à tes questions finales, le client et moi avons bien réussit cette étape en grande partie parce que je l'ai prise en charge à 100% : j'ai très vite compris qu'il avait exprimé ce qu'il pouvait comme il pouvait, la seule chose qu'il pouvait encore fournir, était de répondre à mes questions, à moi de poser les bonnes et reformuler le tout. <br /><br />Pour moi, cette étape n'a pas du tout été douloureuse, au contraire, un moment indispensable et néanmoins plaisant permettant de bien capter le besoin pour mieux satisfaire ensuite. Ce fut un gros travail en début de projet, mais également au cours de chaque "réunion d'itération".<br /><br />@Marc : mais qui es-tu exactement ? ;-)Xavier NOPREhttps://www.blogger.com/profile/05819244619625995331noreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-56549293473872610082011-11-06T12:42:19.529+01:002011-11-06T12:42:19.529+01:00Cela fait plaisir de lire un texte comme celui-ci ...Cela fait plaisir de lire un texte comme celui-ci autant dans le fond que dans la forme. Merci aussi pour nous avoir éviter le franglais qui semble devenu l'indispensable messe en latin des médiocres.Jean-Pierre Vickoffnoreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-47678566579062057472011-11-05T11:30:06.913+01:002011-11-05T11:30:06.913+01:00Bonjour Xavier,
Merci pour ce REX très intéressant...Bonjour Xavier,<br />Merci pour ce REX très intéressant.<br />Tu parles d'une application existante. As-tu pris/prévu du temps pour prendre connaissance de l'existant (architecture, technos, usine logicielle)? Ton client et toi avez-vous pu discuter de qualité d'application (ex : qualité de code (existante/souhaitée), couverture de tests, utilité des fonctionnalités...)? As-tu pris en charge de la dette technique (ex : dette de tests, refactoring...) au cours des itérations?Emilienoreply@blogger.comtag:blogger.com,1999:blog-7705671659201281415.post-63767028566564114802011-11-05T01:51:30.690+01:002011-11-05T01:51:30.690+01:00Bonjour, merci pour ce retour d'expérience.
Je...Bonjour, merci pour ce retour d'expérience.<br />Je suis assez curieux de savoir à quoi ressemble le "Référentiel des fonctionnalités". Tu dis qu'au départ, le cahier des charges se focalisait plus sur les solutions que sur les besoins. Par expérience, je trouve que l'écriture de bonnes user stories est l'une des choses les plus compliquées dans Scrum. Comment le client a réussi cette étape ? Tu l'as accompagné j'imagine, mais ça a pris longtemps ? C'était douloureux ?Marchttps://www.blogger.com/profile/11520890602540079002noreply@blogger.com