J'ai une dignité.

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

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

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

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

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

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

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.

Putain mais ils chient du pognon chez bethesda ?

Ptin on peut se faire TT pour "non respect des forumeurs"

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

"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é"

  désolé d'être compétant.

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

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

Il va leur falloir un sirop pour l'atoux

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

harkaiche  

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)

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

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

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

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

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

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

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

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

  encore ?

Je quote ça devrait me servir bientot ça

Il va leur falloir un sirop pour l'atoux

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.

"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é"

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

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)

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

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

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

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

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.