Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 6 12345 ... DernièreDernière
Affichage des résultats 1 à 20 sur 101
  1. #1
    Chroniqueur Actualités

    Homme Profil pro Stéphane Le Calme
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    1 233
    Détails du profil
    Informations personnelles :
    Nom : Homme Stéphane Le Calme

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 1 233
    Points : 20 686
    Points
    20 686

    Par défaut Les développeurs sont ils condamnés à ne jamais respecter leurs cahiers des charges ?

    Les développeurs sont ils condamnés à ne jamais respecter leurs cahiers des charges ?
    un entrepreneur estime que les temps prévus doivent être multipliés par trois

    Dans une ère où le numérique occupe une place de choix dans les cultures du monde entier, les métiers du génie logiciel bénéficient de la forte demande en applications de toutes sortes.

    Les jeux vidéo et autres applications sont le résultat d’un dur travail en interne qui nécessite rigueur et discipline. Avant de se lancer dans la tâche, les ingénieurs doivent procéder à une analyse de projet pour établir un cahier des charges où il sera fait mention entre autre des besoins, des exigences et des contraintes.

    Michael Wolfe, un investisseur américain dans de nombreuses start-ups (Vontu, Kana, I/PRO, Pipewise), pense que les développements logiciels prennent régulièrement deux ou trois fois plus de temps que prévu.


    Avec une analogie assez amusante, il prend l’exemple d’une randonnée sur la côte de San Francisco à Los Angeles pour rendre visite à ses amis à Newport Beach. Tout est méticuleusement préparé sur la carte, les horaires sont déjà prévus d’avance ; la distance totale faisant 400 miles, le nombre d’heure de marche par jour est estimé à 10 à raison de 4 miles par heure soit 10 jours de marche au total.

    Mais voilà que sur le terrain il y a plein de contours imprévus qui rallongent encore la route de 100 miles. Un coup de fil est passé aux amis pour repousser un peu le jour d’arrivée. À cause du sable, de la fatigue, la vitesse est plus lente que prévue ; 2 miles par heure, la moitié de la performance envisagée. Un autre coup de fil pour repousser. Une tempête s’abat le lendemain rendant toute marche impossible. Un enchaînement d’évènements qui rendent le voyage plus long et plus pénible que « sur le papier ».

    Source : Quora

    Et vous ?

    Qu’en pensez-vous ? Les délais doivent-ils systématiquement être repoussés ?

  2. #2
    Expert Confirmé

    Homme Profil pro david
    Responsable développement
    Inscrit en
    décembre 2003
    Messages
    1 660
    Détails du profil
    Informations personnelles :
    Nom : Homme david
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Responsable développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2003
    Messages : 1 660
    Points : 2 850
    Points
    2 850

    Par défaut

    Bonjour.

    J'ai souvent remarqué que le délai de développement été connu seulement une fois le développement terminé...
    Media Foundation video decoder mpeg1/mpeg2, MediaSource Kinect
    http://sourceforge.net/projects/mfnode/

    http://jeux.developpez.com/faq/directx/?page=dshow

  3. #3
    Membre éprouvé
    Inscrit en
    décembre 2006
    Messages
    244
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 244
    Points : 453
    Points
    453

    Par défaut

    2 remarques :
    - l'analogie avec la côte de SF et la rando a déjà été utilisée, intéressant de la ressortir...
    - Dans cette ordre de Grandeur, Kirk a eu la puce à l'oreille que Scotty devait sa réputation de faiseur de miracles en multipliant systématiquement ses évaluations par 4.

    Sinon, tout développeur rebondit là dessus sur les thèmes "Méthodes Agiles", "Scrum", tout ça... Moi je rebondirai sur le TedxUCSD talk de Guy Kawazaki sur ce qu'il a appris de Steve Jobs et tout particulièrement le point "Real enterpreneurs ship" et son observation de comment ça se passe à la Sillicon Valley : on livre, puis on débeug... Et ça converge avec le point de vue de développeur. On a beau avoir le projet final, on prendra du retard, mais l'objectif devrait être d'avoir quelque chose de livrable à une date T et d'arrêter de se focaliser sur un projet complet, de toutes façons, il est mal définit.

  4. #4
    Membre régulier
    Inscrit en
    mai 2003
    Messages
    62
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 62
    Points : 95
    Points
    95

    Par défaut

    S'il suffisait de multiplier par 4 (ou un facteur quelconque déterminable), il n'y aurais plus aucun problème.

    La loi de Hofstadter est plus profonde : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». C'est ça qui est bon !

  5. #5
    Expert Confirmé Sénior
    Avatar de Paul TOTH
    Homme Profil pro Paul TOTH
    Freelance
    Inscrit en
    novembre 2002
    Messages
    5 609
    Détails du profil
    Informations personnelles :
    Nom : Homme Paul TOTH
    Âge : 45
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 5 609
    Points : 16 075
    Points
    16 075

    Par défaut

    Citation Envoyé par moldavi Voir le message
    Bonjour.

    J'ai souvent remarqué que le délai de développement été connu seulement une fois le développement terminé...
    Citation Envoyé par sympasteve Voir le message
    S'il suffisait de multiplier par 4 (ou un facteur quelconque déterminable), il n'y aurais plus aucun problème.

    La loi de Hofstadter est plus profonde : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. ». C'est ça qui est bon !
    tout est dit
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Produits : UPnP, RemoteOffice, FlashPascal
    Embarcadero : Ile de la Réunion, Dephi, C++Builder, RADPHP...TVA à 8,5%

  6. #6
    Rédacteur


    Avatar de arnolem
    Inscrit en
    février 2005
    Messages
    2 845
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations professionnelles :
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2005
    Messages : 2 845
    Points : 5 623
    Points
    5 623

    Par défaut

    On peut s'engager sur un périmètre ou sur un délai mais pas sur les deux a la fois.
    De plus, je rencontre systématiquement le problème inverse ou les porteurs de projets me demandent d'avoir le projet toujours plus tôt. Au delà de 2 mois de délai, c'est difficile de signer un projet web.

  7. #7
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 174
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 174
    Points : 10 476
    Points
    10 476

    Par défaut

    C'est un peu toujours le même débat, avec les mêmes arguments, qui portent juste sur un aspect différent. Mais, fondamentalement, un projet informatique est un projet tordu. Une "analyse de projet pour établir un cahier des charges où il sera fait mention entre autre des besoins, des exigences et des contraintes" n'est donc pas possible, en tous cas pas sans trou, erreurs ou décalages.

    En outre, l'expérience montre que le principal facteur de succès ou d'echec(hormis la taille brute, qui est un inconvénient) n'est pas la méthodologie, mais le facteur humain.

    Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.

    A celà, on rajoutera les exigences contradictoires des donneurs d'ordre("je veux un site mieux qu'Ebay en moins de deux mois", pour reprendre la situation d'arnolem). Exemple en cours : la recette sur un projet technique important est en retard. Raison immédiate : on a trouvé des anomalies qui ont retardé la recette. Cause profonde : la direction a exigé qu'on fasse un planning "si tout va bien", parceque de toutes façons les programmeurs auront tout bien testé, et que la recette ne trouvera quasiment pas d'anomalies.....

    Mon point de vue à moi c'est que l'informatique est un domaine de l'invisible. On ne sait pas ou on va, on a bien quelques techniques, mais il faut sans cesse les adapter, au contexte technique, fonctionnel, ou politique. Dans ces conditions-là, les estimations ne seront jamais plus que des estimations, ayant la même valeur que les pronostics sportifs(scoop : la Colombie va gagner la coupe du monde 1994).
    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.

  8. #8
    Expert Confirmé Sénior
    Homme Profil pro
    BI
    Inscrit en
    mars 2003
    Messages
    1 544
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : BI

    Informations forums :
    Inscription : mars 2003
    Messages : 1 544
    Points : 4 371
    Points
    4 371

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.
    Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

    Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

    Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.

  9. #9
    Membre Expert
    Développeur informatique
    Inscrit en
    avril 2009
    Messages
    462
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2009
    Messages : 462
    Points : 1 128
    Points
    1 128

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Par conséquent, un développement informatique sérieux partira sur l'idée qu'on ne fait pas de la production mais de la conception, qu'une approche adaptative est nécéssaire, et que "agile" est bien plus une manière de penser qu'une méthodologie.
    Je pense ceci dit que les méthodes agiles sont souvent comprises comme "pas de conception", ce qui est tout de même un sérieux problème. Et quand on lit le "agile manifesto" que tu as mis en lien, on peut penser que c'est vrai, malheureusement. Et quand je vois la tronche de certains cahiers des charges dans ma boîte, où on applique une certaine idée des méthodes agiles, c'est encore plus vrai... Résultat: aucun projet livré à temps, même les plus petits. Du coup j'aime bien l'article de Reeves que tu cites, qui remet bien les pendules à l'heure:

    Nevertheless, people keep insisting that my contention of "the source code is the design" means "don’t do design, just code." I never said anything of the sort. What I did say was:

    "In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be. Designers should use anything that helps. Structure charts, Booch diagrams, state tables, PDL, etc.—if it helps, then use it."

    Today, I would phrase it differently. I would say we need good architectures (top level design), good abstractions (class design), and good implementations (low level design). I would also say something about using UML diagrams or CRC cards to explore alternatives. Nevertheless, I will not back away from the following statement:

    "We must keep in mind, however, that these tools and notations are not a software design. Eventually, we have to create the real software design, and it will be in some programming language. Therefore, we should not be afraid to code our designs as we derive them."

    This is fundamental. I am not arguing that we should not "do design." However you want to approach the process, I simply insist that you have not completed the process until you have written and tested the code.

  10. #10
    Expert Confirmé
    Avatar de pmithrandir
    Homme Profil pro Pierre Bonneau
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    1 629
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Bonneau
    Âge : 31
    Localisation : Roumanie

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2004
    Messages : 1 629
    Points : 3 388
    Points
    3 388

    Par défaut

    Citation Envoyé par phili_b Voir le message
    Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?
    Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

    Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
    Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

    Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.

  11. #11
    Membre chevronné
    Homme Profil pro Gilles
    Inscrit en
    août 2011
    Messages
    244
    Détails du profil
    Informations personnelles :
    Nom : Homme Gilles
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : août 2011
    Messages : 244
    Points : 641
    Points
    641

    Par défaut

    Citation Envoyé par pmithrandir Voir le message
    Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

    Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
    Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

    Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.
    Euh ce n'est pas forcément le développeur qui merde hein... On peut aussi interpréter ça comme étant un moyen de s'assurer et que le client voulait aller à A et non à un B qui serait à 1000 bornes du A ! Sachant qu'en plus si le client sait qu'il veut aller à A (ce qui est déjà un petit miracle en soit) il y ait des chances qu'il ait dit A' voir C...

  12. #12
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 847
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 847
    Points : 6 798
    Points
    6 798

    Par défaut

    Citation Envoyé par phili_b Voir le message
    Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

    Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

    Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.
    Les différentes méthodes agiles ont un certain nombre de point commun, que tu retrouves aussi dans le manifeste : développement itératif (là, on retrouve une différence fondamentale avec le cycle en V), implication de la partie fonctionnelle, ce qui permet aussi de diminuer l'effet tunnel. Mais effectivement, l'agilité, c'est d'abord une manière d'envisager un projet logiciel : la volonté d'accepter le changement, ce n'est pas un point de méthodologie ! Mais c'est une volonté qui doit être présente chez toutes les parties impliquées : le refus du changement dans les spécifications par l'équipe de développement a quand même souvent beaucoup à voir avec le refus du client de rallonger les délais et le budget...
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  13. #13
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 847
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 847
    Points : 6 798
    Points
    6 798

    Par défaut

    Citation Envoyé par martopioche Voir le message
    2 remarques :
    - l'analogie avec la côte de SF et la rando a déjà été utilisée, intéressant de la ressortir...
    - Dans cette ordre de Grandeur, Kirk a eu la puce à l'oreille que Scotty devait sa réputation de faiseur de miracles en multipliant systématiquement ses évaluations par 4.

    Sinon, tout développeur rebondit là dessus sur les thèmes "Méthodes Agiles", "Scrum", tout ça... Moi je rebondirai sur le TedxUCSD talk de Guy Kawazaki sur ce qu'il a appris de Steve Jobs et tout particulièrement le point "Real enterpreneurs ship" et son observation de comment ça se passe à la Sillicon Valley : on livre, puis on débeug... Et ça converge avec le point de vue de développeur. On a beau avoir le projet final, on prendra du retard, mais l'objectif devrait être d'avoir quelque chose de livrable à une date T et d'arrêter de se focaliser sur un projet complet, de toutes façons, il est mal définit.
    Ca ne marche quand dans une certaine mesure. Dans tout projet logiciel, il y a un "coeur" de fonctionnalités essentielles sans lesquelles le logiciel est inutilisable. De manière saisissante, il est rare que les projets hiérarchisent les fonctionnalités entre les points indispensables et les autres. Il faut dire que quand on discute avec les commerciaux, on voit bien qu'ils ne savent pas eux-même le plus souvent. Dans un projet récent, un site web avec un moteur de recherche, l'autocomplétion du champ de recherche par une frappe prédictive est ainsi devenu un point bloquant sans lequel il était impensable de mettre en production. En tant qu'utilisateur de sites web, vous trouvez ça absolument indispensable, vous ?
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  14. #14
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 174
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 174
    Points : 10 476
    Points
    10 476

    Par défaut

    Citation Envoyé par phili_b Voir le message
    Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.
    Ben, en gros, c'est la manière de penser qui convient. Après, on peut la structurer avec des méthodes agiles, genre Scrum, qui imposent de livrer un truc à intervalles réguliers. Mais l'important, c'est bel et bien de chercher un feedback rapide, pour détecter très vite quand on fait fausse route.

    Citation Envoyé par phili_b Voir le message
    Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?
    Pas à ma connaissance. C'est toute la difficulté de la démarche agile : il ne suffit pas de lire le petit manuel. C'est quelque chose qui se pratique. Du Scrum appliqué à l'aveugle, ou on suit scrupuleusement le petit manuel sans se poser de questions, ça donne de mauvais résultats aussi. Quelqu'un qui n'a aucun talent ne pourra jamais faire du bon travail. Je n'ai jamais compris pourquoi la mode était au 4-2-3-1 au lieu du 4-4-2, c'est pourquoi je ne serait jamais un bon entraineur de football.

    Le truc, c'est quand même de limiter la doc au strict minimum. Exemple après le paragraphe suivant.

    Citation Envoyé par phili_b Voir le message
    Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.
    +1000.

    Tous les projets ne se prêtent pas forcément à une méthode agile, avec livraisons partielles. Spécialement, quand on fait une refonte technique, c'est en une fois : en Juillet, on passe par la vieille imprimante, en Aout, on passe par la nouvelle.

    Sur ce projet-là(170 jours de mon coté, c'est-à-dire l'extraction et le formatage des données de sortie), j'avais un début, et une fin. Mais on m'a foutu la paix. On ne m'a pas demandé d'écrire à l'avance tout ce que j'allais faire. J'ai fait le strict minimum : un dessin de chaine décrivant l'architecture des composants, puis un récapitulatif des formats de sortie, avec le composants qui génère chaque donné.

    Tout le reste, est dans le code. Nulle part je n'ai documenté le calcul de la taxe d'assurance pour les contrats automobiles. Ou le montant maximal permettant l'émission d'un TIP. Ce genre de documentation coute cher, se perd, est très vite obsolète. Le code ne peut pas se le permettre : si il est faux, on le corrige.

    Quand je me suis aperçu que j'avais besoin d'un outillage pour pouvoir tester mes valeurs(en comparant les anciennes valeurs aux nouvelles), j'ai demandé un mois. On me l'a donné, alors qu'il n'était pas planifié. Résultat : 1,5% de dépassement de budget, une livraison à la date prévue, et une seule anomalie en production.

    Pourtant, on était dans un espèce de cycle en V : j'ai fait le reverse engineering(le code avait 36 ans d'âge, autant dire non documenté), la MOA en a tiré des specs, j'ai codé les specs, j'ai testé unitairement, l'homologation est passée derrière, et j'ai livré en prod. Mais c'était souple. A tout moment, on pouvait dire "tiens, ça c'est faux, il faut corriger", et ça prenait 15 minutes. La présence d'un outillage de tests automatique permettait de valider en masse, et de detecter immédiatement les regressions.

    La méthode était linéraire, mais la démarche était agile. Donc c'était plus facile et moins cher. La seule documentation était celle indispensable : le dessin de chaine(pour comprendre ce qui se passe tous les mois), et la liste des données et leur programme de calcul(tiens, cette donnée est fausse, ou diable est-elle calculée). Ca n'était pas du cowboy, dans le sens ou on suivait ce qui se faisait. Et quelqu'un qui devait reprendre pouvait le faire, avec ce qu'il faut. Et surtout pas plus.

    Cowboy, pour moi, c'est "je fais ce que je veux et je ne documente pas". J'ai fait valider mon archi par la chef de projet(qui m'a fait corriger deux-trois petits trucs pour conformité avec les standards locaux). J'ai documenté l'essentiel. On a relu mon code(et j'ai fait 2-3 remises au standards). C'est un processus, pas du cowboy. Mais c'est léger. Et surtout, c'est mature : ça fournit le service demandé au moindre cout dans les moindres délais
    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.

  15. #15
    Rédacteur/Modérateur

    Avatar de Nathanael Marchand
    Homme Profil pro Nathanael Marchand
    Expert .Net So@t
    Inscrit en
    octobre 2008
    Messages
    3 614
    Détails du profil
    Informations personnelles :
    Nom : Homme Nathanael Marchand
    Âge : 28
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert .Net So@t
    Secteur : Conseil

    Informations forums :
    Inscription : octobre 2008
    Messages : 3 614
    Points : 8 020
    Points
    8 020

    Par défaut

    Citation Envoyé par phili_b Voir le message
    Là tu m'intéresses. Je voyais Agile de loin comme une méthode à l'arrache, mais tu dis que c'est une manière de penser. J'ai un responsable qui m'a appris à éviter l'effet tunnel, par exemple livrer un projet avec 80% des fonctionnalités demandées pour maintenant, plutôt que 100% des fonctionnalités dans 2 ans.

    Mais concrètement, et c'est là ma question car lire le manifesto ce n'est oas très parlant car théorique, est-ce que tu as, ou est-ce qu'il existe une comparaison du même projet avec la méthode en V et la méthode Agile pour que je comprenne ?

    Sachant que même sans connaitre Agile, on n'est non plus obliger de faire un cycle en V dans les moindre recoins, c'est-à-dire éviter certains projets bureaucratique qui font certes travailler plus de gens, mais rendent risibles leur cout démesuré quelques fois.
    Effectivement Agile c'est loin d'être La RACHE... Un exemple souvent utilisé par mes collègues formateur agiles : la bataille navale.
    Essaie de jouer en Cycle en V : tu envoies une dizaine de coups sans avoir de retour si tu as touché/coulé et ton adversaire joue en agile avec un retour touché/coulé à chaque coup.
    Tu me diras qui a gagné

  16. #16
    Membre éprouvé
    Inscrit en
    décembre 2006
    Messages
    244
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 244
    Points : 453
    Points
    453

    Par défaut

    Citation Envoyé par pmithrandir Voir le message
    Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

    Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
    Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

    Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.
    Dans la pratique, ça va dans les 2 sens, il ne s'agit pas de voir si le développeur a su lire la carte, mais aussi de vérifier qu'on a donné la bonne carte. Enfin, votre formulation laisse entendre que le plan de route est bon mais mal interprété.

    La base des méthodes Agile sont surtout l'implication de chacun : dev, concepteur, chef de projet, et utilisateur (ou son représentant). Car un projet peut "foirer" à tous ces niveaux et le but est de repérer les "problèmes" très tôt afin de ne pas partir dans de mauvaises directions. Cela veut donc bien dire redonner un coup de rêne au développeur, mais c'est aussi demander au dessus si c'est bien vers là qu'il veut aller.

  17. #17
    Membre éprouvé
    Inscrit en
    décembre 2006
    Messages
    244
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 244
    Points : 453
    Points
    453

    Par défaut

    Citation Envoyé par Traroth2 Voir le message
    Ca ne marche quand dans une certaine mesure. Dans tout projet logiciel, il y a un "coeur" de fonctionnalités essentielles sans lesquelles le logiciel est inutilisable. De manière saisissante, il est rare que les projets hiérarchisent les fonctionnalités entre les points indispensables et les autres. Il faut dire que quand on discute avec les commerciaux, on voit bien qu'ils ne savent pas eux-même le plus souvent. Dans un projet récent, un site web avec un moteur de recherche, l'autocomplétion du champ de recherche par une frappe prédictive est ainsi devenu un point bloquant sans lequel il était impensable de mettre en production. En tant qu'utilisateur de sites web, vous trouvez ça absolument indispensable, vous ?
    Exemple très intéressant car ce type de qualification (point bloquant ou non) devrait être définit par l'Usex... Ou la priorité par le marketing. Finalement, est-ce que les clients (donc les commerciaux) se sont investi dans la réalisation ? Car si ils reviennent avec un NoGo à cause du choix d'avoir une autocompletion, le "dev" a fait son job. Et à mon sens, là c'est une erreur commerciale : en attendant, le site n'est pas en ligne, il ne gagne pas en notoriété, la boite continue de perdre de l'argent (ou de ne pas en gagner) alors que la mise en ligne n'aurai pas empêché d'améliorer et faire un upgrade. We ship, then we test...

  18. #18
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro Pierre Caboche
    Inscrit en
    octobre 2005
    Messages
    2 653
    Détails du profil
    Informations personnelles :
    Nom : Homme Pierre Caboche
    Âge : 34
    Localisation : Singapour

    Informations forums :
    Inscription : octobre 2005
    Messages : 2 653
    Points : 8 927
    Points
    8 927

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Mon point de vue à moi c'est que l'informatique est un domaine de l'invisible. On ne sait pas ou on va, ...
    Ça me rappelle un proverbe Shadok :
    Quand on ne sait pas où l'on va, il faut y aller... et le plus vite possible !
    Ça date de la fin des années 60 / début 70, donc bien avant les méthodes Agiles... Et pourtant, qu'est-ce que ça colle bien !

  19. #19
    Membre habitué
    Inscrit en
    mars 2007
    Messages
    64
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 64
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par pmithrandir Voir le message
    Pour moi, la méthode agile est surtout une façon différente de penser. Elle propose plusieurs outils, mais le but est toujours le même.

    Au lieu de donner une carte à un développeur en espérant qu'il sache la lire et se repérer... pour se rendre compte au bout de 6 mois qu'il est à 1000km de la destination... on revient le voir régulièrement pour lui mettre un coup de rêne à gauche ou à droite histoire qu'il continue a cheminer globalement dans la bonne direction.
    Au final, il ne sera pas à la ligne d'arrivée bien sur(15 jours ca suffit pour se planter un peu) mais il devrait être a moins de quelques km de celle ci...

    Après, il y a aussi une part importante qui est la responsabilisation du client... si il veut que son projet réussisse, il faut aussi qu'il s'investisse. On se rend en effet compte que c'est vraiment dans la conception d'un système qu'on en découvre les incohérence et les limites... qui sont bien plus simple à réparer tout de suite qu'une fois que tout le reste est basé dessus.
    Cette histoire de carte me rappelle ce post de Stephen Palmer où il compare XP et FDD (Feature-Driven Development)The Coad Letter: Modeling and Design Edition, Issue 70, Feature Driven Development and Extreme Programming. Il précise :
    The enormous difference between XP and FDD is FDD's additional development of an overall domain object model. As developers learn of requirements they start forming mental images of the system, making assumptions and estimating on that basis. Developing an overall domain object model forces those assumptions out into the open, misunderstandings are resolved and a more complete, common understanding is formed.

    XP uses the analogy of driving a car - driving requires continual little course adjustments, you cannot simply point the car in the right direction and press the accelerator. A domain object model is the map to guide the journey; it can prevent you from driving around in endless circles. The domain object model provides an overall shape to which to add function, feature by feature.
    En gros, Palmer, dans sa comparaison, rappelle que avoir une idée (même incompléte) de l'objectif facilite le trajet...

    La plupart des méthodes agiles comportent une phase de conception, de XP qui va cependant favoriser le refactoring suite au retour utilisateur, à FDD qui se base sur la modélisation. Mais Scrum, Crystal, et quantités d'autres, comportent une phase plus ou moins importante de conception. L'accent qui y est mis varie selon le niveau de la méthode (XP est plus pour les développeurs, Scrum au niveau équipe, FDD pour les grosses équipes).

  20. #20
    Membre habitué
    Inscrit en
    mars 2007
    Messages
    64
    Détails du profil
    Informations forums :
    Inscription : mars 2007
    Messages : 64
    Points : 148
    Points
    148

    Par défaut

    Citation Envoyé par Nathanael Marchand Voir le message
    Effectivement Agile c'est loin d'être La RACHE... Un exemple souvent utilisé par mes collègues formateur agiles : la bataille navale.
    Essaie de jouer en Cycle en V : tu envoies une dizaine de coups sans avoir de retour si tu as touché/coulé et ton adversaire joue en agile avec un retour touché/coulé à chaque coup.
    Tu me diras qui a gagné
    Le Cycle en V est une aberration empruntée au génie civil. Il est difficile de faire un pont en plusieurs itérations, mais le logiciel est complétement différent, comme déjà indiqué plus haut.

    Winston Royce, bien que souvent associé au "Waterfall model", l'a dénoncé dès 1970 : original_waterfall_paper_winston_royce.pdf.
    Il préconise (fig. 7) de réaliser un premier jet sur lequel il sera possible de se baser pour évaluer les tâches et la durée du projet réel.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •