IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #41
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    7 949
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 7 949
    Points : 14 040
    Points
    14 040
    Par défaut
    Citation Envoyé par hotcryx Voir le message
    à 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.

    Keith Flint 1969 - 2019

  2. #42
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    octobre 2004
    Messages
    11 462
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : octobre 2004
    Messages : 11 462
    Points : 29 687
    Points
    29 687
    Par défaut
    Citation Envoyé par petitours Voir le message
    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"...
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #43
    Membre éprouvé Avatar de petitours
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    février 2003
    Messages
    1 636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2003
    Messages : 1 636
    Points : 1 229
    Points
    1 229
    Par défaut
    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.
    Il y a 10 sortes de personnes dans le monde : ceux qui comprennent le binaire et les autres

  4. #44
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 513
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 513
    Points : 30 480
    Points
    30 480
    Par défaut
    +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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #45
    Membre éprouvé Avatar de petitours
    Homme Profil pro
    Ingénieur développement matériel électronique
    Inscrit en
    février 2003
    Messages
    1 636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement matériel électronique
    Secteur : Industrie

    Informations forums :
    Inscription : février 2003
    Messages : 1 636
    Points : 1 229
    Points
    1 229
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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é
    Il y a 10 sortes de personnes dans le monde : ceux qui comprennent le binaire et les autres

Discussions similaires

  1. Invitation à découvrir les méthodes Agiles en PACA
    Par mamat.83 dans le forum Méthodes Agiles
    Réponses: 0
    Dernier message: 28/02/2009, 16h39
  2. Méthodes Agiles dans les entreprises françaises
    Par HokutoNoOlivier dans le forum Méthodes Agiles
    Réponses: 0
    Dernier message: 04/08/2008, 16h25
  3. Sources sur les méthodes agiles
    Par __Ez__ dans le forum Méthodes Agiles
    Réponses: 1
    Dernier message: 25/05/2008, 10h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo