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

Actualités Discussion :

Comment garantir le succès d’un projet IT

  1. #21
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    Novembre 2002
    Messages
    8 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : Novembre 2002
    Messages : 8 964
    Points : 28 430
    Points
    28 430
    Par défaut
    Citation Envoyé par alksddfh Voir le message
    Je reviens sur cette phrase qui m'a un peut choqué la première fois que je l'ai lue parce que je l'ai vécu. Je me suis déjà exprimé plus tôt mais je veut vraiment insister parce que c'est un piège. Une direction qui dit "bon, c'est important, demerdez-vous pour que ça marche", et qui vient vérifier tous les 3 mois qu'on avance, c'est une direction qui cherche à se déresponsabiliser des risques d'un échec. Maintenant c'est dans doute vrai pour une grosse société avec des gros moyen et un projet de plusieurs années mais pour une plus petite structure cette attitude est, selon moi, irresponsable. Je trouve aussi que ça manque d’ailleurs de respect pour ses développeurs. La direction lance un projet, elle s'y intéresse.

    Un autre critère de réussite d'un projet est, selon moi, le position du service IT dans l'entreprise. Il y a des entreprise ou l'IT est vue comme un service, elle n'a pas de pouvoir, elle fait le bon petit soldat pour citer mon responsable de l'époque. Et il y a des entreprise ou l'IT façonne le business. l'IT est au coeur de l'entreprise et elle a un réel pouvoir de modifier les procédures et la manière de fonctionner de l'entreprise. Si vous faite partie d'une équipe IT qui a du pouvoir il se peut que votre projet ai des conséquences au delà de votre secteur IT. Surtout quand votre solution informatique a des conséquences sur les emplois de certains travailleurs. Croyez moi, sur des projets à conséquence vous avez besoin de l'implication de votre direction et du reste de l'entreprise aussi d'ailleurs.
    en fait c'est en effet un peu plus compliqué que cela, ce qu'il faut c'est que chacun joue son rôle. c'est une évidence mais c'est rarement le cas.

    la direction peux très bien être moteur innovant avec des projets fous qui sont des projections vers ce que serait le projet idéal. Mais elle doit accepté que la réalisation soit plus réaliste ou moins ambitieuse que cela en fonction des compétences, de la charge de travail ou du temps accordé au projet. Mais dans ce cas c'est un société qui produit, et non une prestataire qui répond à la demande d'un client.

    une direction exigeante qui pousse à l'excellence tout en reconnaissant la qualité et la compétence de ses développeurs et les respectant tant humainement que financièrement pourra probablement aller très loin.

    En fait en relisant la news je me rends compte qu'elle est très mal rédigée:

    l'introduction commence par "un projet doit se plier à des contraintes de coût, de délai et de respect des exigences définies par le cahier de charges[...]les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères." Ce qui balaie toute notion de relation humaine.

    Quand on reprend les propos de Partho on trouve "l’implication", "cartographie des personnes [...]impliquées[...] que leurs besoins et fonctions ont bien été considérés", "délais plus réalistes", "très bonnes compétences", "motiver et inspirer", "maintenir le projet réel"

    Finalement Partho ne parle ni de coût, ni de délai ni d'exigences du CdC mais au contraire invite à plus de considération et de réalisme

    NB: je n'ai pas lu la source mais que l'article de DVP.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Paul TOTH Voir le message
    en fait c'est en effet un peu plus compliqué que cela, ce qu'il faut c'est que chacun joue son rôle. c'est une évidence mais c'est rarement le cas.
    C'est ça que je voulais dire : l'implication d'une direction peut être positif - si il se limite aux compétences de ladite direction. La plupart des implications que j'ai vue étaient bien trop ciblées, et empêchaient les équipes de faire ce qu'il y avait à faire. Après, l'inverse est vrai aussi. Une direction qui abandonne ses équipes peut être fautive. Mais ça fait souvent moins de dégâts qu'un choix de technologie inspiré par un article des échos, sans considérations pour l'existant ou le savoir-faire des équipes.
    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.

  3. #23
    Membre à l'essai
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2015
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 54
    Localisation : Hong-Kong

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

    Informations forums :
    Inscription : Avril 2015
    Messages : 4
    Points : 12
    Points
    12
    Par défaut
    Citation Envoyé par transgohan Voir le message
    Pourquoi cela serais-ce moins irresponsable pour une grande société ?
    Dans une petite structure 3 ou 6 mois de développements à mettre à la poubelle ça peut être fatal. Une grosse société a certainement plus de budget pour se sortir de ce genre de situation. Aussi une grosse société peut posséder de haut niveaux de hiérarchie et il est plus 'normal' que la toute haute direction ne soie pas au courant de l'évolution du projet au jours le jour.

  4. #24
    Membre régulier
    Profil pro
    manager
    Inscrit en
    Juin 2007
    Messages
    44
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : manager

    Informations forums :
    Inscription : Juin 2007
    Messages : 44
    Points : 79
    Points
    79
    Par défaut Echec... Succès
    Bref, à l'Est, rien de nouveau.
    On raconte la même chose depuis plus de 30 ans et on fait toujours les mêmes constats, ce qui ravit les cabinets de conseil et les intégrateurs.

    Maintenant, succès ou échec, tout dépend du point de vue. Un succès d'aujourd'hui sera un échec demain, et vice-versa.
    Il serait certainement plus intéressant de s'intéresser aux raisons de fond, notamment d'un point de vue sociologique.
    Mais tout le monde sait que sciences humaines et sociales (SHS) et finances ne font pas bon ménage

  5. #25
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 352
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 352
    Points : 20 359
    Points
    20 359
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Selon Partho, le principal facteur de succès ou d’échec d’un projet est l’implication de la haute direction. Il fait partie de ceux qui partagent l’avis selon lequel « il n’y a pas de projets informatiques, mais seulement des projets d’entreprise ». autrement dit, les projets IT doivent impliquer et rassembler l’entreprise dans son ensemble et pas seulement le service informatique. La haute direction qui doit avoir un intérêt particulier dans la réussite du projet doit veiller à cela.
    sujet intéressant.
    C'est exact mais lorsqu'on se lance dans un projet informatique il faut vraiment savoir..où l'on va
    Ecrit comme ça c'est une banalité, le faire c'est autre chose.

    Démarrer un projet informatique c'est une entreprise relativement périlleuse parce qu'il faut souvent tout recréer et surtout bien comprendre les besoins clients,la partie au final la plus difficile.
    Or le traitement de l'information l'informatique donc n'est pas forcément la panacée c.a.d que tout vouloir informatiser n'a pas toujours un sens.
    Ensuite lorsque je mentionne le fait de tout recréer c'est que chaque projet informatique est différent en informatique de gestion.
    Si on prend exemple sur un jeu vidéo commercial , le studio va capitaliser sur son savoir faire et il aura une idée assez précise de là où il veut aller.
    Dans le cas d'un projet d'informatique de gestion le classique une entreprise A demande des prestations à une société de service B ( SSII ) de lui réaliser un projet informatique là c'est différent.
    Il faut que la SSII B comprenne bien le métier du client A , effectue une analyse assez pointue...


    Bref pour les chefs de projets et directeurs de projets qui vont me lire si je me permets quelque vision des chose ( après plusieurs années d'expérience ),pour réussir un projet

    démarrer sur un projet relativement simple quitte à l'améliorer par la suite
    se donner des limites , cela rejoint le point précédent.
    Ce qui risque de faire couler un projet c'est d'ajouter de manière incessante des fonctionnalités ce qui fait augmenter le coût.
    Le gros problème du logiciel c'est que le client A il s'attend à avoir un clone de Google ou Microsoft Word , la majorité des logiciels sont faciles à utiliser.
    Par contre ça cache une terrible complexité ( "code behind") et qui dit complexité dit coûts importants à engager.

    utiliser des méthodes si cela apporte de la pertinence et une amélioration de la productivité sinon trop de méthodologie risque de rigidifier la gestion du projet..

    impliquer véritablement les équipes techniques cela rejoint ce fil de discussion lorsque le terme de cartographie est évoqué..

    bref il y en a beaucoup à écrire à ce sujet


    Citation Envoyé par alksddfh Voir le message
    Aussi une grosse société peut posséder de haut niveaux de hiérarchie et il est plus 'normal' que la toute haute direction ne soie pas au courant de l'évolution du projet au jours le jour.
    c'est exact mais trop de hiérarchie c'est un aspect des choses qui risque de mener un projet à sa faillite

  6. #26
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2015
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

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

    Informations forums :
    Inscription : Avril 2015
    Messages : 14
    Points : 23
    Points
    23
    Par défaut On le sait déjà tout ça.
    c'est trop général. Du concret svp.

  7. #27
    Membre du Club
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    48
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2007
    Messages : 48
    Points : 44
    Points
    44
    Par défaut Que la direction sache que...
    le SEUL truc qui marche c'est:

    LAISSE FAIRE LE PROFESSIONNEL QUI SAIT !

    Donc --> que la direction s'implique pour que tous les gêneurs, les emmerdeurs, les fouineurs, les sculpteurs de nuages soient tenus le plus loin possible de ceux qui bossent...

    Et qu'une fois les specs bien définies, on s'y tienne !

  8. #28
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Pour réussir le succès d'un projet je rajouterai: ne pas mélanger Why, What et How

    Why: Pourquoi on veux ce projet?
    Quel est le sens du projet?
    Quel est le problème qui incite à réaliser ce projet?
    Qu'est ce que cela doit rapporter au "client" demandeur?

    What: Qu'est ce que l'on veux que le "système" (au sens large) face ?
    Là, on va parler de fonctionnalité et de besoins utilisateurs.
    Attention à bien identifier tout les utilisateurs (opérateur "neuneu", administrateur système qui déploie, commercial qui fait une démo, ...).

    How: Comment on veux le faire?
    Quel est l'équipe qui va le réaliser?
    Quelles technologies on va utiliser?
    Délai, suivi, feet-back avec les utilisateurs, ...

    Le risque, dans un projet IT, et de mélanger le Why, What et le How

    Imaginons un client exprimer un besoin du genre "je veux que la gestion de tel et tel truc via Oracle DB, me sorte un état, comme sur le logiciel Machin, via export Excel mais mieux pour que je puisse gagner plein de temps sur mon travail"
    Visiblement, dans cette demande le why, c'est pouvoir gagner du temps sur une tache actuellement répétitive.
    Le what n'est pas très clair (comme Machin), ce qui nous donne un grosse difficulté.
    Et en plus le client impose le how (oracle + excel) sans étudier si ces technologie pourront au mieux correspondre au deux premier point.

    Et parfois, en creusant, on s’aperçoit que notre client parle d'Excel, mais lui s'en fou: mais le logiciel Machin lui sortait un export Excel ce qui lui permettait de réalisé sa belle courbe des états avec les données.
    Finalement, si on lui propose un affichage directement de la courbe des états ce sera encore mieux:
    • Notre client gagnera encore plus de temps
    • Le besoin est déjà plus claire (bien qu'il reste encore a affiner "comme Machin")
    • La technologie sera choisi au mieux par l'équipe IT au mieux (pas d'Excel et pourquoi Oracle DB).

  9. #29
    Invité
    Invité(e)
    Par défaut
    Ca fait maintenant longtemps que je déploie des réseaux et mon expérience me permet de conclure que tout pendant que :

    - le big boss s'amuse avec PowerPoint,
    - le Directeur de projets avec Excel,
    - les Chefs de Projets avec Word,
    - les Ingés avec Visio et Notepad,
    en théorie, chacun est à sa place et les choses restent potentiellement contrôlables


    Citation Envoyé par Michael Guilloux Voir le message
    Quels sont les facteurs qui pourraient compromettre la réussite d’un projet informatique ?
    Il suffit de reprendre les 4 assertions plus haut et mélanger un peu les cartes

    Par exemple, lorsque :

    - le boss commence à manipuler des spreadsheet Excel,
    - les Ingés font du PowerPoint,
    - les Chefs de Projets commencent à faire des copier/coller dans Notepad pour rectifier des scripts de config

    généralement, ça part à la catastrophe.
    Je vous invite à essayer d'autres combinaisons, je suis sûr que vous en trouverez au moins une qui vous rappellera des choses

    Bon, vous avez compris, le succès d'un projet IT, c'est déjà que les bonnes personnes soient à la bonne place. Notamment, quand je dis "bonnes personnes", ça sous-entend la compétence et l'expertise attendues pour l'objectif du projet. Inutile de m'étendre davantage sur cet aspect du succès d'un projet IT.

    Le 2ème point-clé dans un projet, c'est la communication.
    Si pas de communication, pas de fil conducteur. Et sans fil conducteur, difficile de mobiliser et de coordonner des "îlots isolés".
    Ca doit aller du haut vers le bas et ça doit être continu dans le temps. J'ai horreur des Boss/Directeur/Chefs de Projets qui essaient de passer pour des super Boss/Directeur/Chefs de Projets le vendredi entre 14 et 18h au moment du comité de pilotage hebdomadaire, surtout quand t'arrives pas à leur faire prendre une décision entre lundi et jeudi
    Et la communication, c'est pas que des mails... Perso, et c'est peut-être lié à mon ADN de souche bretonne et vendéenne, j'aime bien célébrer les "quick wins"
    Et là, j'avoue, je suis comme un gamin
    Dès que j'arrive à pinguer un truc qui se trouve dans un autre fuseau horaire, même si c'est une simple machine à café, je dis, "woua, mais c'est un pas de géant qu'on a fait là, ça mérite bien quelques bières", et puis on va célébrer ça dans le troquet du coin en sortant du bureau. Je suis très sensible à la reconnaissance parce que c'est quelque chose qui se perd, il faut donc instaurer ces moments de communion entre techos

    Bon, j'y vais, j'ai un copil dans une demi-heure et j'ai pas fini ce f*****g dashboard qu'on m'a imposé et que je suis le seul à comprendre

    Steph

  10. #30
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Joratois Voir le message
    Et qu'une fois les specs bien définies, on s'y tienne !
    Autrement dit, impossible de changer d'avis ou de rectifier une trajectoire ????

    Sur un mini projet de quelques semaines, ça va
    Mais que fait on sur un projet de plusieurs mois ?
    Que se passe t'il s'il y a des cas non prévus dans la spec ?

    Il est indispensable d'éviter les effets tunnels car c'est le meilleurs moyen de "perdre" les utilisateurs et d'avoir une levée de boucliers lors de la livraison
    Il est indispensable d'impliquer les utilisateurs que se soit à la qualif du besoin, à la conception, aux dev et à la recette
    C'est ainsi qu'on les implique et qu'on obtient leur adhésion

    Tu auras beau faire la plus merveilleuse des appli sur le plan IT, si les utilisateurs n'en veulent pas, elle finira dans un carton et ça sera un échec retentissant
    Bien pire qu'une appli bugguée

  11. #31
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    Tu veux parler de "Accueillez positivement les changements de besoins, même tard dans le projet." (2ème principe - http://agilemanifesto.org/iso/fr/principles.html)

    Il faudrait alors parler des besoins réels à des utilisateurs tout au long du développement de ton projet pour voir s'ils évoluent.
    Et puis, ça voudrait dire avoir du feed-back de leur part sur ce que tu fais et donc leur proposer régulièrement une "version de démo".
    Mais qui dit proposer une telle version, voudrait dire d'avoir régulièrement un produit qui marche, qui est fonctionnel, qui est testé ...

    Attention, on est à deux doigts de basculer dans le monde de l'Agilité

  12. #32
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Tu veux parler de "Accueillez positivement les changements de besoins, même tard dans le projet." (2ème principe - http://agilemanifesto.org/iso/fr/principles.html)

    Il faudrait alors parler des besoins réels à des utilisateurs tout au long du développement de ton projet pour voir s'ils évoluent.
    Et puis, ça voudrait dire avoir du feed-back de leur part sur ce que tu fais et donc leur proposer régulièrement une "version de démo".
    Mais qui dit proposer une telle version, voudrait dire d'avoir régulièrement un produit qui marche, qui est fonctionnel, qui est testé ...

    Attention, on est à deux doigts de basculer dans le monde de l'Agilité
    Tu m'as percé à jour
    Moi qui pensais avancer masquer

  13. #33
    Futur Membre du Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Novembre 2013
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

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

    Informations forums :
    Inscription : Novembre 2013
    Messages : 2
    Points : 5
    Points
    5
    Par défaut Réussite d'un projet IT
    Pour la majorité des propos, je suis d'accord, de plus il y a un autre facteur qui est l'audite des procédures et leurs l'égalité, pour ne pas avoir a tout refaire. Un projet réussi c'est un projet qui ne pose pas des problèmes lors de sa mise en production que se soit technique, procédural ou législatif.

  14. #34
    Membre éprouvé
    Avatar de landry161
    Homme Profil pro
    C#,PHP,MySQL,Android...
    Inscrit en
    Juillet 2010
    Messages
    423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : C#,PHP,MySQL,Android...

    Informations forums :
    Inscription : Juillet 2010
    Messages : 423
    Points : 1 059
    Points
    1 059
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par psychadelic Voir le message
    Oui, c'est le premier problème.
    Le commercial est la pour "vendre" des projets, et non pour les réaliser.

    Mais au bout du compte, et bien trop souvent, les équipes de dev sont loin de travailler dans la sérénité d'un contrat bien bordé.

    Après ,pour ce qui en est du travail d'équipe, je suis plutôt catastrophé de voir combien peu nombreux sont ceux qui connaissent l'usage d'un simple Kanban (et les méthodes agiles et Scrumb, n'en parlons même pas...)
    Tu as tout à fait raison.

  15. #35
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 552
    Points : 18 446
    Points
    18 446
    Par défaut
    Pour qu'un projet soit un succès il est possible d'utiliser de la gestion de projet agile.

    Si on fonctionne en vieille gestion de projet déprécié depuis un bail comme le cycle en V, voilà ce qu'il ce passe (en exagérant) :
    - le client donne un cahier des charges
    - l'entreprise répond "ok on te fait ça, ce sera livré dans 2 ans"
    - 2 ans passent
    - l'entreprise livre
    - le client répond "en faite à l'origine on avait mal exprimé nos besoin dans le cahier des charges, et de toutes façons ils ont changé depuis" (en réalité on montre au client l'avancement du projet plusieurs fois pendant les 2 ans)

    Alors qu'avec SCRUM par exemple, le client peut définir la problématique (en gros) et ensuite l'entreprise développe petite fonctionnalité par petite fonctionnalité.
    Il est possible d'avoir des réunions très régulière avec le client (le plus cour pouvant être 1 semaine).
    Comme ça le client peut réagir et exprimer ce dont il a réellement besoin. (en plus il a accès à une version de test mise à jour régulièrement).
    Des nouvelles idées apparaissent et le projet répond vraiment bien aux besoins du client.

    Le truc chiant c'est pour prévoir la durée du projet total...
    Vu que le client va demander plus de fonctionnalités.
    Keith Flint 1969 - 2019

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

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    @Ryu2000 : je t'ai downvoté parceque tu présentes SCRUM comme une solution parfaite répondant à tous les problèmes. Ce n'est pas vrai. Ca répond favorablement à un certains nombre de critiques, mais ça n'est jamais qu'une méthode, et comme totue méthode, elle peut foirer(et je ne parle même pas du faux agile qui pullulle amené par des consultants peu scrupuleux, hein, seulement du vrai).
    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.

  17. #37
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 552
    Points : 18 446
    Points
    18 446
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    comme totue méthode, elle peut foirer(et je ne parle même pas du faux agile qui pullulle amené par des consultants peu scrupuleux, hein, seulement du vrai).
    C'était juste pour dire qu'avec un dialogue régulier avec le client, on peut rester proche du besoin.

    Parce que sinon le client exprime mal ses besoins (il demande des choses qu'il n'a pas besoin, il ne demande pas des choses dont il a besoin), les ingénieurs interprètent mal le cahier des charges, à la fin ça peut donner n'importe quoi.
    Alors qu'en montrant souvent les progrès on peut réorienter le projet dans la bonne direction.

    Les méthodes agiles peuvent effectivement foirer, mais il y a des côtés sympa. (il y a un gros retour du client, il peut s'investir dans le projet)
    Keith Flint 1969 - 2019

Discussions similaires

  1. comment structurer une modél. UML - projet J2EE avec pattern
    Par RocketArena dans le forum Architecture
    Réponses: 18
    Dernier message: 20/07/2007, 20h20
  2. Comment organiser les fichiers de projet ?
    Par Zen_Fou dans le forum Général Conception Web
    Réponses: 4
    Dernier message: 03/05/2006, 18h21
  3. [Outils][InstallWIz.Net]Comment l'utiliser pour mon projet?
    Par fantomchris dans le forum EDI/Outils
    Réponses: 30
    Dernier message: 19/04/2006, 19h35
  4. [Droits] Comment garantir au mieux la confidentialité ?
    Par mencaglia dans le forum Décisions SGBD
    Réponses: 2
    Dernier message: 06/02/2006, 10h39
  5. Réponses: 13
    Dernier message: 22/07/2005, 19h25

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