Déjà, une équipe de dev sur un projet, SCRUM ou non, ça ne devrait pas dépasser 10 personnes. Au dela, le projet grossit tellement rapidement qu'il se transforme vite en usine à gaz que personne ne maitrise. Il devrait être divisé en sous-projets ("diviser pour régner" ) qui ont chacun leur CP, leur archi, leurs livraisons, etc. Et éventuellement, pour les très gros projets, une équipe de dev transverse qui fournit des ressources et des building blocks à tout le monde. En pratique, bien sûr que ça marche, c'est même comme ça que ça fonctionne à peu près partout.

Il y a souvent moyen, mais reste à savoir si au niveau du coût, on privilégie le court terme ou le long terme.

50 par post, cool

Je quote ça devrait me servir bientot ça

 
Si vous avez un environnement de test (et le contraire m'étonnerai), je ne vois pas pourquoi vous devriez tout implémenter avant de pouvoir tester.
 
"On ne refactorise pas notre usine à gaz parce qu'on ne refactorise pas notre usine à gaz"
J'aime beaucoup ta logique

Vous êtes déjà en mode usine à gaz monolithique avec tous les inconvénients qui vont avec, donc oui, c'est la merde. A moins d'avoir la volonté de recréer un système from the ground up, ça va pas être facile de découper ça. Mais de toute façon, je ne pense pas que quiconque ici ait eu l'expérience de bosser sur un mastodonte préhistorique dans votre genre donc notre avis reste limité.
edit: et vu que tout le monde est contre, et qu'il n'y a pas de volonté managériale, pour le changement de mentalité chez vous, il faut voir un horizon à 20 ans... donc effectivement, sensibiliser les équipes avec des méthodes de dev un peu remises au goût du jour, ça sera déjà pas mal.

Ce genre de changement ne s'applique pas du jour au lendemain à toute la boite. Il vaut mieux commencer par un projet modeste avec des gens motivés et étendre la méthode au reste de l'entreprise.

C'est faux, il y a toujours moyen d'améliorer l'existant. C'est compliqué, ça prend du temps et les changements ne sont pas toujours évidents dans un premier temps mais ce n'est jamais impossible.

il va juste falloir éviter d'appliquer le droit du travail Français en Belgique

  désolé d'être compétant.
 
Jubijub > http://xp-france.net/sessions2007/S724-Medina.pdf

Non mais à ce niveau, pas besoin de modifier la lettre.

question sérieuse : les droits du travail se ressemblent à ce point ?
Genre avec un code du travail, des convention sociales dont certaines sont étendues par le ministère ? (et deviennent obligatoires dans la profession)

 
depuis quand on peut poster + de 10 smileys ?

j'pense que chez les costards, t'as plus de chances avec SCRUM qu'avec XP.
 
parce que XP ça parle de pratique, de choses concrètes qui ont un putain d'impact au quotidien (genre les intégrateurs continu, les binômes etc.). Avec SCRUM, on peu plus ou moins faire du business as usual mais avec des fiches cartonnées (puisqu'il ny a aucune prescription d'ingénierie).
Et prendre une decision forte, c'est mettre sa tête sur le billot chez les grands comptes. Quand bien même un mec un peu excentrique arriverait à monter à un poste suffisant, son supérieur a peu de chances d'être excentrique lui-aussi.

 
depuis quand on peut poster + de 10 smileys ?

http://forum.hardware.fr/forum2.ph [...] #t18947311
 

Quelqu'un pour tester la limite smileys (de tous types) + images dans un post ?

6 smileys/compte en bonus
 

ça va minorer chérie

Non.  

dans mes bras, padawan

ça va minorer chérie

http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg
http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg
http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg
http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg
http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg
http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg
http://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpghttp://imagesforum.doctissimo.fr/m [...] k-juiz.jpg

1/ pour te donner une idée à 10km au dessus, quand t'as le web de commande qui appelle le sap de commande (qui appelle le système financier) qui appelle le mainframe de commande, qui appelle le mainframe qui explose la commande (1 camion) en pièces (un moteur, une cabine, un longeron, des ponts etc...le tout en récursif (1 moteur = 1 fonte, 10 cylindres, 1 vilbrequin, 3 faisceaux électriques, etc...) (pour info une commande donne en gros 100.000 items une fois "décodifiée" ), qui appelle tous les mainframe logistique (cabine, moteur, etc...) qui appelle le mainframe de séquencement en prod, qui appelle le mainframe qui gère les stocks usines, etc et j'en passe environ 50, pour tester si changer la description de la variante réservoir à droite fait bien que le stock usine se voit toujours décrémenté d'une attache réservoir à droite, c'est pas trivial...
la seule solution serait de faire du mockup (un gros bouchon au cul de chaque système pour tester unitairement), mais c'est pas possible parce que les systèmes sont boite blanche : ils partagent leurs bases de données, sont ultra fortement couplés, et donc c pas jouable (et oui c'est immonde)
j'appelle pas ça un monolite pour rien...

2/ vu l'age des applis, la qté de ligne de codes à changer, la mauvaise documentation du système (pour avoir une vague idée de ce que fait par exemple le système de commande, faut reprendre la spec de 78, et y appliquer environ 3000 diff liés à toutes les évols qu'il y a eu dessus, sans parler des bidouilles quick & dirty en maintenance qui sont pas documentées), y'en a pour des centaines de millions d'€...et vu d'en haut, y'a pas de business case (moi je pense que si mais on est minoritaire si tu veux)

c'est ce qu'on fait : y'a de petits projets .NET et java qui implémentent SCRUM et XP, avec de bons retours clients, l'idée c'est que ça fasse école...le risque étant aussi une réaction de type "oh oui mais vot' truc ça marche que sur les petits projets"

+1...mais parfois le changement a un cout qui le rend inintéressant aux yeux du management : prend une appli qui a 30 ans, qui est virtuellement bug free pour l'usage qu'on en a parce que ça fait 30 ans qu'on la maintient...expliquer qu'il faut claquer 20m€ pour la réécrire en .NET ou java pour finalement un niveau de features identique, avec les risques que ça comporte (régression, cassage des liens forts, etc...), ben y'a pas un manager qui risquera son cul là dessus...et c'est dommage

question sérieuse : les droits du travail se ressemblent à ce point ?
Genre avec un code du travail, des convention sociales dont certaines sont étendues par le ministère ? (et deviennent obligatoires dans la profession)

 
sad but true...je suis d'accord avec nraynaud là dessus
 
j'étais assis pas loin des CIO, et l'un d'entre eux a présenté à la suite de SCRUM ce qu'il comptait faire avec dans sa BU, et le truc le plus mis en avant c'est la conformité de la livraison au besoin client, et la fin de l'effet tunnel
le truc le plus vu comme un obstacle c'était la forte dispo client demandée, et le fait que le Product Owner doit connaitre le fonctionnel (c'est pas toujours le cas coté client, parfois le CP client ne connait rien au domaine)

OH NOES
Marc haz opend teh pandora door

 
Manque plus que 50 flache par post et c'est bon, on est docti

Elmofacho
Mes images