Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2205 connectés 

  FORUM HardWare.fr
  Programmation

  [blabla@olympe] Le topic du modo, dieu de la fibre et du monde

 
 


Sujet auquel vous répondez
Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde
seabee Nom de l’employeur
Adresse de l’entreprise
Nom
Prénom
Adresse
 
Madame, Monsieur,
 
Je vous informe que j’ai pris la décision de démissionner de mon poste de (fonction) que j’occupe actuellement dans votre entreprise.
 
Je souhaite être dispensé d’effectuer :
 
1ère hypothèse : mon préavis
 
2ème hypothèse : une partie de mon préavis, soit (nombre de mois/semaines)
 
par dérogation aux dispositions de la convention collective (ou de l’accord d’entreprise ou de mon contrat de travail). Je vous remercie de prendre en considération ma demande afin que je puisse quitter mon emploi le (date).
 
Dans l'attente de votre réponse par retour de courrier,
 
Je vous prie de croire, Madame (ou Monsieur), en l’expression de mes sentiments les meilleurs.
 
Signature

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
lorill O NOES!
seabee 50 par post, cool
el muchacho

mareek a écrit :


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 y a souvent moyen, mais reste à savoir si au niveau du coût, on privilégie le court terme ou le long terme.
seabee [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
 [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]  [:warkcolor]
schnapsmann [:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0]
[:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0]
[:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0]
[:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0]
[:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0][:wark0]
schnapsmann

kadreg a écrit :

[:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  


taiste
kadreg [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]
 [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]  [:kadreg]
mareek

Jubijub a écrit :

j'y bosse pas sur ce projet...et le directeur de programme est plus occupé à sauver son cul qu'à implémenter des méthodes inovantes IMHO
 
 
y faudrait que qqn le fasse, mais vraiment on est une boite très old school : y'aura une grosse résistance client (oui j'ai pas que ça à foutre de prioriser le backlog, tiens je vais prendre des IT pour qu'ils le fassent, et je validerai...), t'en chieras beaucoup pour cadrer le projet sous l'angle de la business value (j'ai assisté à des meetings UI de 2h pour savoir si il fallait 1 ou 2 boutons)
 
ensuite nos clients arbitrent toujours à petit budget (10j RTU avec la doc ? oh ben non, vous avez dédé, je sais qu'il peut le faire en 4j sur un coin de nappe, mettez dédé sur le projet)
 
et je te parle pas des réticences coté IT (on a jamais fait comme ça, c'est pas possible, etc...) et du fait que 75% de nos dev (en fr en tout cas) sont formattés Mainframe et procédural...
y'aurait déjà un boulot énorme de sensibilisation à des notions d'encapsulation, d'interface, de couplage faible, etc... avant meme de penser changer les méthodes de gestion de projet...


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.

el muchacho a écrit :

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 ground up, ça va pas être facile de découper ça.


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.
el muchacho

Jubijub a écrit :

je vais prendre un exemple concret : on a uniformisé nos systèmes de product development, architecturés autour d'un PDM qui nous permet de décrire la configuration des camions d'une nouvelle façon, uniforme pour toutes les marques.
En gros c'est là dedans qu'on dit que si tu prends le pack grand froid, ça exclut le pare-brise athermique et la monte de pneus Michelin "bidule", mais que ça oblige à avoir l'option chauffage du carburant, et que c'est pas compatible avec l'option double réservoir (j'invente, mais c'est l'idée) : ce sont les notions de bases, de variantes, etc...
problème : nos systèmes de prod actuels ne comprennent pas cette nouvelle description des camions : il faut leur apprendre.

 

on a donc un projet gigantesque qui est une campagne de patch énorme pour faire comprendre à tous nos systèmes mainframe ce nouveau système.
le programme IT contient 5-6 projets, et doit embaucher un truc genre 150 personnes...je parle pas de l'équipe client, qui est énorme aussi


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.
seabee

Jubijub a écrit :


 
et t'es obligé de démissionner ? Ils peuvent pas gérer ça administrativement ?


Ce sont des boites différentes. C'est juste qu'on est lié niveau capitalisation boursière tout ça.
En fait j'y connais pas grand chose.
mareek

Dion a écrit :


"non mais tu comprends, chez nous c'est pas pareil ça a aucune chance de fonctionner, on a trop de specificites. Puis tu sais bien que dans un contexte avec beaucoup de prestation... Puis comme ca on manque de visibilite, c'est pas evident, surtout pour les budgets.... Non retourne sur le planning de 9mois, je passe en copil demain et il faut leur annoncer qu'on a un peu rippé"


PQ

drasche a écrit :

CarmackG [:sadnoir]
 
On parie que ID perd ses atoux d'ici 12 mois?


ID software a un seul atout: Carmack.  
 
Le seul truc qui m'inquiète c'est que le communiqué de presse indique que cramack assurera la direction du studio alors qu'il a toujours dit qu'il ne savait pas manager et qu'il ne voulait pas le faire. J'espère que c'est juste du blabla de PR fait pour rassurer les joueurs et que ça ne reflète pas la réalité.

Jubijub a écrit :

La grosse contrainte, inhérente à l'archi pourrie de nos systèmes mainframe, c'est que pour qu'un changement soit testable, il faut que la chaine d'appli entière applique le changement...(le mockup c pas super simple en mainframe)


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.

Jubijub a écrit :

le cycle en V + effet tunnel, c'est le reproche #1 de nos clients...
 
le problème c'est quand tu hérites d'un système créé y'a 30 ans avec les pires pratiques de dev possible (y'a des systèmes qu'on maintient parce que t'as 150 applis qui vont lire en direct un champs dans la base associée, y'a 0 encapsulation), c'est difficile d'appliquer des méthodes qui présupposent des bonnes pratiques de dev et d'archi...
 
et la boite n'a pas fait le choix de faire ce que fait le bancaire par exemple, qui est d'isoler les vieux systèmes derrière des interfaces, et de les remplacer petit à petit...nous on fait grossir le monolite, tout en se plaignant qu'il est trop gros, donc trop dur à scinder...


"On ne refactorise pas notre usine à gaz parce qu'on ne refactorise pas notre usine à gaz"
J'aime beaucoup ta logique [:implosion du tibia]

Jubijub

seabee a écrit :


C'est réglé, je me barre pour la maison mère (je bosse pour une filiale de ma future boite), et les DSi ont arrangé le truc entre eux.


 
et t'es obligé de démissionner ? Ils peuvent pas gérer ça administrativement ?

drasche Moi j'avais fait plus court, j'ai spécifié la date du 31/12 pour la fin de contrat et ils ont accepté [:petrus75] (en même temps c'était logique vu que les contrats avec le client sont renouvelés par trimestre)
Harkonnen

Taiche a écrit :


Il va leur falloir un sirop pour l'atoux [:petrus75]


dans mes bras, padawan [:petrus75]
seabee

drasche a écrit :

:jap:


Han Yong  :jap:  

Dion a écrit :


Mais tu le négocies pas plutot a l'oral (anti pervers/muchacho proff) avant d'ecrire ta lettre ?


C'est réglé, je me barre pour la maison mère (je bosse pour une filiale de ma future boite), et les DSi ont arrangé le truc entre eux.

zapan666 a écrit :


 [:transparency] encore ?


Han Yong  :jap:  

LePhasme a écrit :


Je quote ça devrait me servir bientot ça :o


Han Yong  :jap:

Jubijub

Dion a écrit :


C'est inapplicable car on fait des mauvais choix.
 
Ok lol...


 
j'y bosse pas sur ce projet...et le directeur de programme est plus occupé à sauver son cul qu'à implémenter des méthodes inovantes IMHO
 

Dion a écrit :


Ou alors que tu portes l'idée, que tu prennes un peu de risques, etc...


y faudrait que qqn le fasse, mais vraiment on est une boite très old school : y'aura une grosse résistance client (oui j'ai pas que ça à foutre de prioriser le backlog, tiens je vais prendre des IT pour qu'ils le fassent, et je validerai...), t'en chieras beaucoup pour cadrer le projet sous l'angle de la business value (j'ai assisté à des meetings UI de 2h pour savoir si il fallait 1 ou 2 boutons)
 
ensuite nos clients arbitrent toujours à petit budget (10j RTU avec la doc ? oh ben non, vous avez dédé, je sais qu'il peut le faire en 4j sur un coin de nappe, mettez dédé sur le projet)
 
et je te parle pas des réticences coté IT (on a jamais fait comme ça, c'est pas possible, etc...) et du fait que 75% de nos dev (en fr en tout cas) sont formattés Mainframe et procédural...
y'aurait déjà un boulot énorme de sensibilisation à des notions d'encapsulation, d'interface, de couplage faible, etc... avant meme de penser changer les méthodes de gestion de projet...

LePhasme

seabee a écrit :

Nom de l’employeur
Adresse de l’entreprise
Nom
Prénom
Adresse
 
Madame, Monsieur,
 
Je vous informe que j’ai pris la décision de démissionner de mon poste de (fonction) que j’occupe actuellement dans votre entreprise.
 
Je souhaite être dispensé d’effectuer :
 
1ère hypothèse : mon préavis
 
2ème hypothèse : une partie de mon préavis, soit (nombre de mois/semaines)
 
par dérogation aux dispositions de la convention collective (ou de l’accord d’entreprise ou de mon contrat de travail). Je vous remercie de prendre en considération ma demande afin que je puisse quitter mon emploi le (date).
 
Dans l'attente de votre réponse par retour de courrier,
 
Je vous prie de croire, Madame (ou Monsieur), en l’expression de mes sentiments les meilleurs.
 
Signature


Je quote ça devrait me servir bientot ça :o
zapan666

seabee a écrit :

OK
 
 
NOW'S THE FUCKING TIME
 
 
DEMISSION WITH THE MIGHTY DISPENSION OF THE PREADVICE


 [:transparency] encore ?

Dion

seabee a écrit :

Nom de l’employeur
Adresse de l’entreprise
Nom
Prénom
Adresse
 
Signature


Mais tu le négocies pas plutot a l'oral (anti pervers/muchacho proff) avant d'ecrire ta lettre ?
drasche :jap:
seabee MIGTHYYYY
seabee Nom de l’employeur
Adresse de l’entreprise
Nom
Prénom
Adresse
 
Madame, Monsieur,
 
Je vous informe que j’ai pris la décision de démissionner de mon poste de (fonction) que j’occupe actuellement dans votre entreprise.
 
Je souhaite être dispensé d’effectuer :
 
1ère hypothèse : mon préavis
 
2ème hypothèse : une partie de mon préavis, soit (nombre de mois/semaines)
 
par dérogation aux dispositions de la convention collective (ou de l’accord d’entreprise ou de mon contrat de travail). Je vous remercie de prendre en considération ma demande afin que je puisse quitter mon emploi le (date).
 
Dans l'attente de votre réponse par retour de courrier,
 
Je vous prie de croire, Madame (ou Monsieur), en l’expression de mes sentiments les meilleurs.
 
Signature
seabee OK
 
 
NOW'S THE FUCKING TIME
 
 
DEMISSION WITH THE MIGHTY DISPENSION OF THE PREADVICE
Dion

Jubijub a écrit :


 
le cycle en V + effet tunnel, c'est le reproche #1 de nos clients...
 
le problème c'est quand tu hérites d'un système créé y'a 30 ans avec les pires pratiques de dev possible (y'a des systèmes qu'on maintient parce que t'as 150 applis qui vont lire en direct un champs dans la base associée, y'a 0 encapsulation), c'est difficile d'appliquer des méthodes qui présupposent des bonnes pratiques de dev et d'archi...
 
et la boite n'a pas fait le choix de faire ce que fait le bancaire par exemple, qui est d'isoler les vieux systèmes derrière des interfaces, et de les remplacer petit à petit...nous on fait grossir le monolite, tout en se plaignant qu'il est trop gros, donc trop dur à scinder...
 


C'est inapplicable car on fait des mauvais choix.
 
Ok lol...
 
 

Jubijub a écrit :


:jap: très intéressant...mais pour appliquer ça je vais devoir changer de boite :/


Ou alors que tu portes l'idée, que tu prennes un peu de risques, etc...

Dion

Jubijub a écrit :

je vais prendre un exemple concret : on a uniformisé nos systèmes de product development, architecturés autour d'un PDM qui nous permet de décrire la configuration des camions d'une nouvelle façon, uniforme pour toutes les marques.
En gros c'est là dedans qu'on dit que si tu prends le pack grand froid, ça exclut le pare-brise athermique et la monte de pneus Michelin "bidule", mais que ça oblige à avoir l'option chauffage du carburant, et que c'est pas compatible avec l'option double réservoir (j'invente, mais c'est l'idée) : ce sont les notions de bases, de variantes, etc...
problème : nos systèmes de prod actuels ne comprennent pas cette nouvelle description des camions : il faut leur apprendre.
 
on a donc un projet gigantesque qui est une campagne de patch énorme pour faire comprendre à tous nos systèmes mainframe ce nouveau système.
le programme IT contient 5-6 projets, et doit embaucher un truc genre 150 personnes...je parle pas de l'équipe client, qui est énorme aussi
 
La grosse contrainte, inhérente à l'archi pourrie de nos systèmes mainframe, c'est que pour qu'un changement soit testable, il faut que la chaine d'appli entière applique le changement...(le mockup c pas super simple en mainframe)
 
là où j'ai du mal à voir comment appliquer SCRUM sur ce type de projet, c'est qu'il te faut une vue super transversale du besoin, vu que t'impacte 50 systèmes à la fois...
 
et du coup la division pyramidale, j'ai du mal à voir comment elle peut marcher...
 
après je doute qu'on ait l'état d'esprit qui va bien ici pour implémenter ça (le dev objet c'est toujours qualifié de nouvelle techno chez nous, quand tu parles d'XP on te regarde comme un alien, même si on a 2-3 projets qui sont "modernes", la majorité reste du gros pacbase vilain)


 
Effectivement si tu changes la maniere dont tu manages les projets, il risque d'y avoir des impacts sur l'organisation de ces projets  [:aslan117]  
 
Et donc vu que tu ne fais pas le choix de decouper le projet, tu peux pas prendre une methodo qui se base la dessus en tant que prerequis
 
Et effectivement si tu veux garder un unique projet de 150 personnes, t'auras du mal a etre agile.
Taiche

schnapsmann a écrit :


harkaiche  :ouch:


[:kbchris]
boulax

uriel a écrit :

note pour plus tard: ne pas utiliser le "Alert me" dans sharepoint [:pingouino]
 
 
 je pars manger, 15mn apres: 18 mails [:ciler]


Ca me fait pareil avec monster  [:pierre_tramo]

drasche

Xavier_OM a écrit :

[:grammar nazi]


[:sisicaivrai]
schnapsmann

Taiche a écrit :


Il va leur falloir un sirop pour l'atoux [:petrus75]


harkaiche  :ouch:

Taiche

drasche a écrit :

On parie que ID perd ses atoux d'ici 12 mois?


Il va leur falloir un sirop pour l'atoux [:petrus75]
Jubijub

Dion a écrit :


"non mais tu comprends, chez nous c'est pas pareil ça a aucune chance de fonctionner, on a trop de specificites. Puis tu sais bien que dans un contexte avec beaucoup de prestation... Puis comme ca on manque de visibilite, c'est pas evident, surtout pour les budgets.... Non retourne sur le planning de 9mois, je passe en copil demain et il faut leur annoncer qu'on a un peu rippé"

 

le cycle en V + effet tunnel, c'est le reproche #1 de nos clients...

 

le problème c'est quand tu hérites d'un système créé y'a 30 ans avec les pires pratiques de dev possible (y'a des systèmes qu'on maintient parce que t'as 150 applis qui vont lire en direct un champs dans la base associée, y'a 0 encapsulation), c'est difficile d'appliquer des méthodes qui présupposent des bonnes pratiques de dev et d'archi...

 

et la boite n'a pas fait le choix de faire ce que fait le bancaire par exemple, qui est d'isoler les vieux systèmes derrière des interfaces, et de les remplacer petit à petit...nous on fait grossir le monolite, tout en se plaignant qu'il est trop gros, donc trop dur à scinder...

 
zapan666 a écrit :


 [:cosmoschtroumpf] désolé d'être compétant.

 

Jubijub > http://xp-france.net/sessions2007/S724-Medina.pdf


:jap: très intéressant...mais pour appliquer ça je vais devoir changer de boite :/
Xavier_OM

drasche a écrit :

[:oh hai]
 
On parie que ID perd ses atoux d'ici 12 mois?
 


 
 [:grammar nazi]

Jubijub je vais prendre un exemple concret : on a uniformisé nos systèmes de product development, architecturés autour d'un PDM qui nous permet de décrire la configuration des camions d'une nouvelle façon, uniforme pour toutes les marques.
En gros c'est là dedans qu'on dit que si tu prends le pack grand froid, ça exclut le pare-brise athermique et la monte de pneus Michelin "bidule", mais que ça oblige à avoir l'option chauffage du carburant, et que c'est pas compatible avec l'option double réservoir (j'invente, mais c'est l'idée) : ce sont les notions de bases, de variantes, etc...
problème : nos systèmes de prod actuels ne comprennent pas cette nouvelle description des camions : il faut leur apprendre.
 
on a donc un projet gigantesque qui est une campagne de patch énorme pour faire comprendre à tous nos systèmes mainframe ce nouveau système.
le programme IT contient 5-6 projets, et doit embaucher un truc genre 150 personnes...je parle pas de l'équipe client, qui est énorme aussi
 
La grosse contrainte, inhérente à l'archi pourrie de nos systèmes mainframe, c'est que pour qu'un changement soit testable, il faut que la chaine d'appli entière applique le changement...(le mockup c pas super simple en mainframe)
 
là où j'ai du mal à voir comment appliquer SCRUM sur ce type de projet, c'est qu'il te faut une vue super transversale du besoin, vu que t'impacte 50 systèmes à la fois...
 
et du coup la division pyramidale, j'ai du mal à voir comment elle peut marcher...
 
après je doute qu'on ait l'état d'esprit qui va bien ici pour implémenter ça (le dev objet c'est toujours qualifié de nouvelle techno chez nous, quand tu parles d'XP on te regarde comme un alien, même si on a 2-3 projets qui sont "modernes", la majorité reste du gros pacbase vilain)
drasche [:oh hai]
 

Dion a écrit :

Putain mais ils chient du pognon chez bethesda ?


CarmackG [:sadnoir]
 
On parie que ID perd ses atoux d'ici 12 mois?
 

masklinn a écrit :

Ptin on peut se faire TT pour "non respect des forumeurs" [:pingouino]


[:obvious]
Dion

el muchacho a écrit :


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.


"non mais tu comprends, chez nous c'est pas pareil ça a aucune chance de fonctionner, on a trop de specificites. Puis tu sais bien que dans un contexte avec beaucoup de prestation... Puis comme ca on manque de visibilite, c'est pas evident, surtout pour les budgets.... Non retourne sur le planning de 9mois, je passe en copil demain et il faut leur annoncer qu'on a un peu rippé"
zapan666

Dion a écrit :

 

Ah oui, si on est payé sur un truc ça marche forcément.


 [:cosmoschtroumpf] désolé d'être compétant.

 

Jubijub > http://xp-france.net/sessions2007/S724-Medina.pdf
mareek

Jubijub a écrit :

avant hier on a eu une conf de chef de projet, et y'avait la CIO Renault Trucks.
un mec des méthodes déroule sa prez SCRUM, et il s'est fait descendre en flamme par la CIO parce que en gros son truc ça avait l'air inapplicable, un grand moment :D


Il est suivi par un psychologue ce gars ? parce que présenter une méthode agile au DSI d'une boite brontausorienne comme la tienne c'est un comportement suicidaire :/

Jubijub a écrit :

ceci dit la plupart de nos projets sont en fait une collection de patchs sur des applis mainframe, avec des équipes énormes de gens que t'as qu'à 50%, je doute que ce soit SCRUM compliant ;)


Forcément, les mauvaises pratiques c'est rarement compatible avec les bonnes pratiques [:petrus75]

Jubijub a écrit :

d'ailleurs dans la prez le mec dit qu'une SCRUM team ça doit pas exéder 10 personnes, et que si t'as plus faut cascader les équipes...
en pratique vous l'avez testé ? ça marche ? ça me parait super douteux l'espèce de pyramides d'équipes, où chaque équipe envoit des représentant à l'étage du dessus


Vous n'avez pas une organisation pyramidale chez vous ? t'as bien un chef qui a d'autres subordonnés que toi et ce chef à lui mêmme un chef etc. :spamafote:
Dion

zapan666 a écrit :


oui ça marche, je suis payé pour.

 

Ah oui, si on est payé sur un truc ça marche forcément.
zapan666

Jubijub a écrit :


 
avant hier on a eu une conf de chef de projet, et y'avait la CIO Renault Trucks.
un mec des méthodes déroule sa prez SCRUM, et il s'est fait descendre en flamme par la CIO parce que en gros son truc ça avait l'air inapplicable, un grand moment :D
 
ceci dit la plupart de nos projets sont en fait une collection de patchs sur des applis mainframe, avec des équipes énormes de gens que t'as qu'à 50%, je doute que ce soit SCRUM compliant ;)
 
d'ailleurs dans la prez le mec dit qu'une SCRUM team ça doit pas exéder 10 personnes, et que si t'as plus faut cascader les équipes...
en pratique vous l'avez testé ? ça marche ? ça me parait super douteux l'espèce de pyramides d'équipes, où chaque équipe envoit des représentant à l'étage du dessus
 


oui ça marche, je suis payé pour.
el muchacho Oui monsieur, je m'appelle pas Dion. [:natas]

Jubijub a écrit :


avant hier on a eu une conf de chef de projet, et y'avait la CIO Renault Trucks.
un mec des méthodes déroule sa prez SCRUM, et il s'est fait descendre en flamme par la CIO parce que en gros son truc ça avait l'air inapplicable, un grand moment :D

 

ceci dit la plupart de nos projets sont en fait une collection de patchs sur des applis mainframe, avec des équipes énormes de gens que t'as qu'à 50%, je doute que ce soit SCRUM compliant ;)

 

d'ailleurs dans la prez le mec dit qu'une SCRUM team ça doit pas exéder 10 personnes, et que si t'as plus faut cascader les équipes...
en pratique vous l'avez testé ? ça marche ? ça me parait super douteux l'espèce de pyramides d'équipes, où chaque équipe envoit des représentant à l'étage du dessus


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.
Dion

el muchacho a écrit :


J'ai une dignité. [:thalis]


 [:rofl]  [:rofl]  [:rofl]  
 [:rofl]  [:rofl]  [:rofl]  
 [:rofl]  [:rofl]  [:rofl]


Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)