Discussion :

[Ryu2000]

à chaque SCRUM, on répétait la même chose sans avoir vraiment avancé

Vous faisiez des sprints de combien de temps ?
Normalement tu as une liste de petites tâches à réaliser pendant la période du sprint et à a fin tu dois les avoir toutes terminé ou presque (si il y a eu un problème et qu'une tâche prend plus de temps que prévu, ou si le temps nécessaire à réaliser une tâche a été mal évalué).
C'est bizarre que vous n'avanciez pas.

[koala01]

Quand je fais un POC, le POC n'est pas utilisable en prod, il ne peut devenir un provisoire définitif.

Ca, ca reste encore malheureusement à voir...

Si la fonctionnalité pour laquelle on te demande un POC ne se raccroche en rien aux données métier existantes, tu peux effectivement rendre ton POC inutilisable en production.

Mais, quand la fonctionnalité doit se raccrocher, d'une manière ou d'une autre, à ton modèle de données, tu fais comment

Un simple exemple:

Tu as une application en C++, qui manipule des données stockées dans une base de données quelconque. et le programme fonctionne relativement bien.

Le client se prend de l'idée que

Tiens, ce serait pas mal de pouvoir afficher ces données dans un navigateur web

Bah, c'est pas forcément ton problème, vu que tu es dans l'équipe C++, et que cet aspect sera géré par l'équipe web non

Sauf que, voilà, l'équipe de développement web n'ayant aucune idée de ton modèle de données va demander s'il est possible de créer -- au choix -- une dtd, une sxslt ou n'importe quel autre modèle de traitement de données adapté au format XML, ce qui est -- d'ailleurs -- parfaitement compréhensible

Et, avant de prendre sa décision, ton chef de projet te demande explicitement

Pourrais tu me faire un POC, pour savoir si c'est possible, si on ne va pas s'arracher les cheveux à mettre se truc en place et à le maintenir à jour

Ben, comme ca n'a pas l'air bien compliqué, tu acceptes, et tu commence donc à créer la DTD en incluant à peu près dix pourcent de ton modèle de données actuel. Cela te prend deux jours, elle n'est pas forcément parfaite, mais elle est correcte, et elle valide correctement les données transmises.

Tu montre ton travail au chef de projet, qui te demande si tu pourrais pas rajouter le support d'un autre aspect des données, qui va -- lui aussi -- couvrir environ 10% de ton modèle de données. Comme tu es payé pour le faire et que c'est "pas trop chiant" (même si tu préférerais t'arracher les yeux sur du code C++ :S) tu acceptes bien sur de le faire

Et comme cela, au fur et à mesure des ajouts, de deux jours en deux jours, on en arrive à une couverture de près de 100% du modèle de données actuel. Et tu as -- bien sur -- rappelé au moins cinq fois à ton chef de projet qu'on est dans une période de POC .

Si bien que, à la fin, tu es tout surpris d'être convié à une réunion pour s'assurer que la DTD que tu as mise au point couvre effectivement l'ensemble de ton modèle de données, à la virgule près. Faut il encore rappeler que c'était une POC, et que son but était simplement de démontrer que c'était faisable sur un jeu limité de données

Bien sur, cette réunion met quelques manquements en évidence (après tout, je n'ai jamais prétendu être infaillible, surtout en ce qui concerne les DTD ), mais rien de catastrophique. Et on décide quand même d'y apporter les corrections.

Au final, on se retrouve avec un DTD, écrite par quelqu'un qui reconaît ses propres lacunes en XML en particulier dans la rédaction de DTD, et qui n'a pas fait "plus attention que cela" à la manière dont il l'écrivait (bien qu'il ait quand même essayé de la formater de manière relativement rigoureuse, plus pour arriver à s'y retrouver qu'autre chose ) parce qu'il était sensé créer ... un POC.

Oui, mais... Quelle preuve je peux avoir, moi, que ce POC ne sera pas utilisé tel quel en production

Ne rigole pas, parce que j'ai eu le coup

Soit ça marche pas longtemps, soit ça ne marche que dans une infra très particulière et dans la plupart des cas ça fait le job sur un jeu de donnée échantillon, quelquefois avec une fonctionnalité balaise qui n'existe pas encore mais sait juste donner le résultat qui va bien sur l’échantillon de donnée.

Ou cela marche avec l'ensemble de modèle de données actuel, dans une application créée par une équipe tout à fait différente, qui l'utilisera comme une version qualifiée et tu ne le sauras jamais

Pour être tout à fait honnête, c'est parce que j'ai eu ce genre de blague que je me méfie comme de la peste des POC qui sont décrétées "provisoirement définitives"...

[petitours]

Je ne rejoins pas du tout ce contre exemple sur le POC

un POC pour valider que l'on peut connecter telle ou telle bdd n'est pas un POC, c'est un développement puisque oui on peut toujours connecter tel ou tel jeu de donnée et ce n'est que de la technique, il y a aucun bénéfice client dans le fait de connecter une base.

Un POC ça concerne pour moi un bénéfice client, ce qu'il va faire des fameuses données que l'on sait connecter .Tu as des données, tu as un métier et ton POC montre qu'en cliquant sur 1 truc tu obtiens ceci ou cela qui a une valeur client incroyable.
Pour un tel POC tu ne vas surtout pas dépenser 1seconde de temps à faire des connexions à une base de donnée.
etape 1 tu fais un truc de façade qui a l'air beau et ou quand l'utilisateur clique tu obtiens le truc de la mort attendu (et pour ça tu ne fera surtout pas la moins connexion à quoi que ce soit, tu fera à l'inverse un truc bug proof autant que possible)
etape 2 tu fais de l’analyse de donnée avec un outil ad-hoc (R ou PowerBI dans mon cas) et tu synthétises l'ensemble des cas réels ciblés par le POC pour que le client, rassuré sur le fait qu'il a juste un clic à faire, puisse se concentrer sur le potentiel économique (ou autre) de la chose.

S'il y a un début de définitif dans un POC c'est éventuellement sur l'interface/aspect (pour ne pas dérouter les gens) mais le POC reste totalement inexploitable en prod car ne connait qu'un cas d’école qui fonctionnera de manière certaine le jour de la démo.

[el_slapper]

+1 avec Koala.

"tu nous fait un truc rapide, jetable, c'est juste pour vérifier 3 données - tu colles 2 select dans un jetable COBOL, et ça fait le job"

"bon, en fait, il y en a qui sont erronées, tu peux me rajouter un update?"

et 6 semaines plus tard, on a un monstre non architecturé et encore moins maintenable qui devient un outil incontournable. Le truc, c'est qu'au bout de 3 semaines, le gars qui avait commencé quittait la mission(c'était prévu de longue date), et m'a dit explicitement qu'il regrettait fortement de ne pas avoir architecturé le truc de base. C'était un euphémisme. J'ai retenu la leçon : même quand on me dit de faire sale, j'essaye de faire aussi propre que possible.

C'était même pas un POC.

[petitours]

C'était même pas un POC.

Ben oui c'est pas du POC ce que tu décris, c'est du développement méthode la rache.

Faire un POC est tout sauf de la rache, au contraire c'est une étape ou on qualifie (et ajuste) le bénéfice client pour pouvoir développer ensuite un truc qui aura d'autant plus de facilité à être structuré