Sur la gestion de projet:
Sur ce qui est du projet de la NASA, déjà il a eu lieu pendant une période de forte tension (Guerre Froide en force!), les normes de Management de l'époque étaient encore très diversifiés et pas du tout commune. Je n'ai aucune idée du process mis en place à cette époque. Les normes de Management ont réellement explosé durant cette période là (vers les années 70-80), les incidents tels que Tchernobyl ayant aidé à leur conception. Alors oui, peut être qu'avant on s'en foutait d'envoyer une fusée se faire défoncer pour que dalle, on s'en foutait de faire bosser des ingé à 30-45k€/an sur des projets qui servaient à rien pendant les 30 glorieuses, oué ça je dis pas. Maintenant en 2007 je crois qu'avec le marché ultra concurrentiel, tout est calculé au plus tôt.
La politique actuelle c'est plutôt ça: http://fr.wikipedia.org/wiki/Gestion_de_projet et ça: http://fr.wikipedia.org/wiki/ISO_9001 (bon y en a d'autres, mais là c'est l'essentiel) et en gros c'est pas: "Ouais les gars on est tous de bonne intention, alors se tiens main dans la main et on avance" et là trois mois plus tard on arrive à un constat désolant: "Merde ça marche pas".
Donc non, un projet qui avant son lancement d'application n'est pas capable de dire: A la date X (avec une marge définie) l'indicateur Y sera passé au seuil Z, ben ce projet ne sert vraiment à rien. Vous n'avez aucune certitude de résultats, vous avez juste espoir que la situation s'améliore. En gros vous lancez un dé de 100 sur l'avenir, ce qui est idiot. Y a des gars qui vont alors croire que la situation va s'améliorer alors qu'on avait des outils et des méthodes qui auraient pu montrer que non ça ne marchera pas ou que du moins on pouvait faire mieux, et ce projet qui servira à rien, va réconforter des personnes dans l'idée que la situation va s'améliorer (alors là c'est la catastrophe).
Pour le son:
Bien le management est clairement foireux. On a donc si j'ai bien compris (On suit une flèche que quand l'étape en cour se passe bien): OEI a fait des modifications sur un 2DA et peut être sans demander au client (Atari) l'autorisation de le faire => cette modification a ou n'a pas été envoyé à Atari => Atari a ou n'a pas fait les modifications suffisantes de son côté sur les versions localisées pour suivre la modification => Atari n'a peut être pas fait de contrôle qualité sur ces produits localisés (Utch ) => La publication de la mise à jour n'a pas été empêché suite au rapport de contôle qualité négatif (et d'ailleurs à cette étape là, si OEI avait fait les modifications sans que ce soit validé par le client (c'est la première étape), Atari est en droit (si le contrat est bien fait) de faire payer à OEI les réparations).
Après OEI fait du beta test que sur la version US (ok ils sont payés par Atari pour ça), c'est lamentable qu'on est pas du beta test FR pour les versions FR.
Sur la gestion de projet:
Sur ce qui est du projet de la NASA, déjà il a eu lieu pendant une période de forte tension (Guerre Froide en force!), les normes de Management de l'époque étaient encore très diversifiés et pas du tout commune. Je n'ai aucune idée du process mis en place à cette époque. Les normes de Management ont réellement explosé durant cette période là (vers les années 70-80), les incidents tels que Tchernobyl ayant aidé à leur conception. Alors oui, peut être qu'avant on s'en foutait d'envoyer une fusée se faire défoncer pour que dalle, on s'en foutait de faire bosser des ingé à 30-45k€/an sur des projets qui servaient à rien pendant les 30 glorieuses, oué ça je dis pas. Maintenant en 2007 je crois qu'avec le marché ultra concurrentiel, tout est calculé au plus tôt.
La politique actuelle c'est plutôt ça: http://fr.wikipedia.org/wiki/Gestion_de_projet et ça: http://fr.wikipedia.org/wiki/ISO_9001 (bon y en a d'autres, mais là c'est l'essentiel) et en gros c'est pas: "Ouais les gars on est tous de bonne intention, alors se tiens main dans la main et on avance" et là trois mois plus tard on arrive à un constat désolant: "Merde ça marche pas".
Donc non, un projet qui avant son lancement d'application n'est pas capable de dire: A la date X (avec une marge définie) l'indicateur Y sera passé au seuil Z, ben ce projet ne sert vraiment à rien. Vous n'avez aucune certitude de résultats, vous avez juste espoir que la situation s'améliore. En gros vous lancez un dé de 100 sur l'avenir, ce qui est idiot. Y a des gars qui vont alors croire que la situation va s'améliorer alors qu'on avait des outils et des méthodes qui auraient pu montrer que non ça ne marchera pas ou que du moins on pouvait faire mieux, et ce projet qui servira à rien, va réconforter des personnes dans l'idée que la situation va s'améliorer (alors là c'est la catastrophe).
L'ISO 9001:2000 est principalement utilisée pour tout ce qui est sous traitance, et d'ailleurs son but principal est de permettre de tirer le max de son sous traitant c'est à dire de lui imposer de dire qu'il fait de la merde quand il en fait (et de lui faire payer ces erreurs).
En ce qui concerne son utilisation, EDF l'impose à ces sous traitants (ainsi souvent que la norme environnementale (la 14000 je crois) mais ça c'est l'image de marque, développement durable ça fait cool), Véolia l'impose également, Renault et PSA aussi (vous savez ces pauvres usines qui fournissent les sièges, les montes vitre électriques, etc), EADS ne marche presque qu'a ça, Thalès l'utilise également de façon très large, bref quasiment toute l'industrie impose à ces sous traitants d'être certifiés 9001:2000, quand tu dis que ça touche que le bâtiment je me demande où tu bosses.
Après que tu me dises qu'on utilise pas ça en interne dans une boite (EDF ne l'utilise pas en interne à ma connaissance), je pense que ça va de soit. C'est une méthode qui se veut très lourde car elle impose de tout faire valider par les parties prenantes, elle est énormément basée sur des accords signés (afin de mettre des pénalités en cas de défaut), alors qu'en interne on estime qu'une poignée de main ou une chose dites est une chose qui sera tenue. Mais quand un process global montre un dysfonctionnement clair, c'est souvent ce qu'on met en place pour tout recadrer. C'est lourd, mais ça permet souvent assez vite à la direction de trouver les maillons faibles et de les dégager, sans ça, les "responsables" rejettent toujours la faute sur les autres alors que quand c'est marqué "X est responsable de Y" si Y est pas fait X saute.
Pour la méthode Agile, je suis vraiment pas spécialisé en management de projet informatique, je n'y connais pas grand chose. Ce que j'y ai compris c'est je crois énormément basé sur le fait que les personnes qui participent sont dans une optique positive (tous les participants sont là pour bosser). l'ISO 9001 c'est fait pour flinguer ceux qui sont là pour glander et tenir les objectifs fixés.
Je n'ai à aucun moment parlé de qualité de produit, que ce soit dans le premier ou dans le second post.
Donc non, un projet qui avant son lancement d'application n'est pas capable de dire: A la date X (avec une marge définie) l'indicateur Y sera passé au seuil Z, ben ce projet ne sert vraiment à rien. Vous n'avez aucune certitude de résultats, vous avez juste espoir que la situation s'améliore. En gros vous lancez un dé de 100 sur l'avenir, ce qui est idiot. Y a des gars qui vont alors croire que la situation va s'améliorer alors qu'on avait des outils et des méthodes qui auraient pu montrer que non ça ne marchera pas ou que du moins on pouvait faire mieux, et ce projet qui servira à rien, va réconforter des personnes dans l'idée que la situation va s'améliorer (alors là c'est la catastrophe).