Reprise du message précédent :
en meme temps si les gars veulent faire de l'agile, mais ne veulent chiffrer qu'un scenario , c'est peut être pas côté business qu'il y a un pb

Jubi tout ce qu'il attend c'est votre aval moral pour licencier la bande de tanches qui l'enquiquinent

Il peut pas dire ça, sinon il perd ses meilleurs développeurs. C'est la mode dans le développement autant que la coke dans le market.
 
Par contre j'ai un peu de mal à pleurer ou avoir envie d'aider en fait.
 
J'essaye de fabriquer des trucs pour des gens, pas de gérer des budgets et de manipuler des développeurs dans des contrats. La création du manifeste agile était la réaction à cette organisation.

du moment qu'il en embauchent des meilleurs avec des masses d $$ en télétravail

moi j'y vois aussi un problème de poule et de cochon.
 
si le scrum master n'a pas assez confiance dans son  équipe pour se dire que , d'une façon ou d'une autre, le produit te tiendras à l'abris de la pluie, du vent et de la neige, tout en respectant le niveau de qualité exigé a jubicorp (tdd, doc, anticipation de la maintenance, des migrations, ... ), faut peut etre qu'il change d'équipe ou de métier.  Si on parle d'un projet assez gros pour avoir de l'enjeu, ils l'ont forcement  cassé en plein de stories (skoi le terme français d'ailleurs ?) et de tâches, sinon, c'est de la rache, pas de l'agile.
 
Par contre si l'objectif du chiffrage est de définir la couleur du vernis de sous pente, alors c'est plutôt à jubi que je jetterai des cailloux pointus

fallait me dire, je t'aurais forwarde les videos de yelle a coachella

oui mais non.
oui, il faut de l'analyse avant. On commence pas nos projets avant un minimum d'analyse chez nous. On commence pas un projet avant de passer du temps la dessus, sinon Agile ou pas c'est perdu. Evidemment, ce temps d'analyse est pas inclus dans le budget du projet (pas ici en tout cas). mais ca evite les catastrophe plus tard: un planning base sur une mauvaise analyse sert a rien.
 
et non parce que tu definis quand meme tes deliverables et tes priorites, tes risques et leur mitigation (je pourrais jamais bosser dans une boite francaise ), ca empeche pas l'agile pour les cycles de development. L'agile simplifie (normalement, ton cas m'a l'air special ) ce processus de changement et d'incrementation, au lieu de faire du change request toutes les semaines.
 

+1 apres quand tu places ca dans une organisation de la taille de NN ou la mienne ben faut arrondir les angles

ah oui, mais ca a rien a voir avec l'agile ca

je suis la coquine entremetteuse, je suis chef des PM IT...donc je suis entre le business et le dev
 

je comprends ton point de vue, mais je te ferais humblement remarquer qu'à moins d'être un pur esprit vivant d'amour, d'eau fraiche et de debug ou d'avoir une fortune perso qui te met à l'abri du besoin, tu peux pas totalement écarter la notion financière de l'équation. Et dans la mesure où tu dépends qu'un gars te paye, tu peux essayer de comprendre pourquoi il te paye.
Je ne crois pas d'ailleurs que l'agile manifesto consiste à dire : écoute loulou, crache les thunes, on te donnera ce qu'on veut bien te donner, et tu seras bien content. Donc comme c'est sensé être customer oriented, ça peut etre malin à un moment ou à un autre de se préoccuper des problèmatiques de son client, et selon la typologie de client, sa problématique c'est d'investir l'argent qu'il a pour en tirer le maximum, et qu'il peut vouloir 2-3 garanties sur ce point.
De meme que c'est débile de s'engager sur une scope de 300 stories au micro poil de cul en promettant de tout livrer et d'atterir sur une pièce de 5 francs niveau budget, c'est tout aussi débile à mon sens de ne s'engager à rien, et de ne simplement avoir qu'une obligation de moyen.
La vérité est au milieu, et elle est aussi dans la confiance que peut inspirer l'équipe qui doit livrer. Si l'équipe ne s'engage jamais sur rien, ça n'inspire pas confiance.
Mon problème, c'est que je dois m'engager sur une roadmap de projets, pour une enveloppe globale. Depuis 2012 je dois pas me démerder trop mal, parce qu'on a livré, mais au prix de batailles incroyable avec l'équipe de dev qui persiste à penser que l'argent c'est un concept virtuel qui ne les engage pas.
J'essaye de leur expliquer que si on a 10 projets à livrer pour un budget de 100, le plus simple est de s'assurer que chaque projet livre pour 10. Je suis OK qu'un projet livre pour 15, si un autre projet peut livrer pour 5. Ca imprime pas en face visiblement, la notion de rigueur budgétaire.
 

Et c'est confortable? T'étouffe pas trop?

 
C'est là qu'il va falloir définir "garanties".
En l'occurrence une estimation n'est une garantie de rien, si ce n'est de donner la possibilité au client de faire virer quelqu'un parce qu'il a perdu sa thune sans avoir ce qu'il voulait.

ça dépend, une de mes stakeholders est une petite jeune ma fois...tout à fait charmante (won't pix it, yet it did happen)
 
disons que j'ai acquis bonne réputation parce que je livre ce que je dis que je livre, et ce depuis 3 ans, dans une boite où c'est pas la tradition. Donc on me respecte, donc on me casse pas trop les couilles quand je dis non. Mais une grosse partie de mon job consiste à faire redescendre les gens des nuages et les rappeler à la dure réalité de la vie dans une grosse boite.
 

 
par garantie j'entends : sauf imprévu, être capable de livrer au moins 30% du scope qui représente le core need sans lequel ça ne vaut même pas la peine de déployer la solution, ou sans lequel on foire totalement le projet business qui va avec (et oui, comme on est pas une boite IT, le projet IT n'est que la partie d'un projet total qui livre aussi d'autres trucs).
 
encore une fois, c'est de l'IT corporate, tous les projets sont pas rocket science.Le truc c'est que l'équipe de dev bosse, ils formalisent rien, donc la fois d'après ils sont infoutus de savoir combien coute un truc qu'ils ont déjà fait... en utilisant leur timesheets j'arrive à être plus précis qu'eux sur les estimations, sans ouvrir un seul fichier de code, ce qui craint un peu je trouve.
Ils sont en train de travailler là dessus, de se fabriquer des abaques, etc... mais c'est pas encore là

L'agile te donne un pouvoir que le contrat n'a pas: tu te barres quand tu veux, avec un produit dans l'état actuel, c'est une idée plus néo-capitaliste qu'aucune chemise rose n'oserait exprimer en dehors du club de golf. Si tu veux mettre de l'argent dans le manifeste agile, c'est toutes les semaines après le sprint, rien à voir avec un plan annuel et des engagements pluri-annuels, c'est beaucoup plus brutal.
 
Par contre on va parler des valeurs et des graduations un peu. Tu est un cadre bien payé dans une des boite les plus rentables du monde dans un des pays les plus chers du monde et dans une des villes les plus chères dudit pays. Y'a un concept que tu n'as absolument aucun droit d'évoquer c'est celui d'avoir besoin de bouffer. Je suis au chomedû depuis longtemps dans un pays soit disant au bord de la faillite dans une ville qui glande, et j'ai jamais manqué un repas pour une autre raison que "je dormais et maintenant tout est fermé". Ceci évacué, on nage tous dans le fric, et la question est de savoir comment on l'utilise. Ensuite, tu n'es le gardien de rien et surtout pas celui de la rentabilité, parce que la rentabilité on la voit tous les jeudi: CA du site moins les salaires des développeurs et leurs managers. C'est même pas de l'usage du fric dont on parle, mais des pratiques autour des usages des budgets, bref, c'est des loisirs. Le loisir de se branler la nouille en réunion, le loisir de choisir de faire un budget annuel (tu devrais lancer l'idée de faire des budgets bi-annuels ou semi-annuels, ça va les occuper et tous les 10ans tu changes: bon, maintenant c'est tous les 7 mois).
 
Ce que tu cherches c'est à utiliser une équipe de développeurs pour augmenter ta visibilité auprès de tes chefs pour gagner du galon et de l'argent. Ne l'oublie jamais, t'es pas là pour sauver le modèle de business traditionnel de la vague agile qui va ruiner notre civilisation. Tu as utilisé la vague agile pour attirer des bons devs parce qu'ils y sont sensibles comme un Vermonter au kale bio, tu as utilisé leur compétences pour effectivement avoir des premier succès professionnels mais maintenant tu arrives au bout du mensonge, pressé entre la volonté de rentrer dans le système existant d'engagement annuel et la possibilité de garder une équipe de devs qui tient la route pour sortir des projets qui vaudraient influence et promotion.
 
Tu es en train de te plaindre de gens dont le boulot est le plus vérifié et le plus vérifiable: y'a un bug ou pas sur le site ? y'a une nouvelle fonctionnalité ce jeudi ou pas ? Quand un manager fout rien ou fait une erreur, on s'en fout c'est que du papier. Quand un dev bloque la prod pendant 2min sur un gros site, tout le monde le sait et on peu chiffrer sa perte, y'a des dizaines d'indicateurs dans tous les sens qui vont mettre en exergue son erreur. Maintenant il faut donner une contrepartie à ces gens qui ont le boulot que tout le monde voit. Puisque ça ne passe manifestement pas par les salaires, et ben y'en a un autre : refuser de s'engager 6 mois à l'avance sur quel risque ils vont faire prendre au site et à leur carrière.

Me semble logique perso, le codage et les estimations de temps c'est orthogonal, si les estimations sont ni considérées ni revues en fin de tâches (dans le but d'entraîner/bâtir une intuition) il n'y a pas spécialement de raison pour que les devs (ou autres d'ailleurs) sachent estimer quoi que ce soit.

 
   
 
Excellent.

ça sent pas le vécu du tout

enfin, moi j'ai du mal avec les chefs, mon fantasme ça serait que le produit que je créé ait de la reconnaissance générale dans le public (reconnaissance positive hein, pas Taser ou RoundUp).

non, du tout en fait. et y a pas de thunes a proprement parle dans le manifesto.
 mais encore une fois, ca me semble que tes problemes ont rien a voir avec agile ou pas.

oui enfin la, y a un tech lead qui merde ou y a un souci. je jete un coup d'oeil a Jira pour savoir ce qu'on a fait y a 1 an et tout est la. C'est pas forcement du details, mais c'est suffisant pour planifier les prochains projets.

oui, tu me dis qui sont tes modeles?
 tu veux etre quoi? le prochain Matt Mullenweg ?

J'en sais rien moi, les modèles publics des personnes sont souvent trafiqués par les agences de comm'

Mais j'aime bien Steve Jobs, il a su être toujours vrai à lui-même toujours un côté connard avec qui on a peur de prendre l'ascenseur, ça m'inspire.
 
Mais tous nos héros ont des faiblesses, le fait qu'il ait reconnecté avec sa fille, le fait qu'il n'y a aucune histoire de violence physique envers des subalternes qui traine.  
 
Bref, c'est l'histoire d'une déception.

tu vas voir toi, le grand soir ...

 
Un développeur peut dire qu'il a travaillé dur durant 5 jours pour corriger un bug, alors qu'il a glandé 4 jours dès qu'il a vu que c'était corrigeable en une matinée...

 
John Resig ?

un manager peut aussi glander 4/5, ça ne les différencie pas.
Par contre, il va y avoir une pression constante durant les 5 jours sur le dev, parce que ça se voit.

Je trouve qu'il a une politique intéressante: 1 commit perso par jour.

@nico dans une boite ou "le developpeur", c'est 50 personnes , eventuellement un sous traitant
  Quelle responsabilité tu as dans ce cas , si ça pete ?  

Dans mon expérience , les problèmes pénibles arrivent toujours à la jonction entre les systèmes, là ou les responsabilité (techniques, fonctionnelles , ce que tu veux ) sont floues , là ou tu as injterêt à caler un peu les choses au début.

Certains de tes points sont tout à fait valides,  ,notamment qu'on est quand tous dans une boite pour y trouver un avantage individuel, à commencer par un salaire.

oui enfin, on part du principe que tu travailles pas avec des mauvais (et je veux pas dire faignant, juste des cons qui foutent rien). On parle pas de monitorer les dev (enfin je crois), juste de planifier correctement

y a Werner Vogels aussi. et plus proche de la physionomie de nraynaud

J'ai  pas vraiment d'avis sur l'agile mais j'aime bien ton approche du management.

Le pire c'est qu'une fois j'ai fait une connerie en tant que PM à PSA, j'ai demandé 5 jours à l'avance le déploiement d'un truc (le minimum, parce que je suis fast-paced moi), et en fait on a trouvé un bug entre temps. Bon, c'est une erreur de manager, j'ai juste à virer mon ordre du système et tout va bien.  
 
Sauf que là y'avait pas de procédure pour virer mon ordre, et pire, le grouillot, lui, avait des métriques sur ses ordres exécutés, et il se serait pris un blâme s'il avait simplement ignoré mon ordre et évité à un bug de partir en prod. Au final on a réussi à changer l'ordre et à faire partir un autre truc non-buggé en prod à la place (je dis "on", parce que là il a fallu appeler des experts de procédures internes et bloquer la connerie est devenu un team work de chemises roses). On a réussi à sauver nos utilisateurs du bug, à pas faire passer sous le camion un travailleur (en fait il serait pas passé sous le camion son chef aurait sauvé les métriques d'abord et envoyé le truc buggé en prod je pense), trois jours de chemises roses pour ne *pas* exécuter un script.
 
Inutile de vous dire que j'avais aucune métrique associée à cet ordre, qu'aucun de mes collègues ou mon chef s'en est souvenu, être responsable de ses actes c'est pour les cols bleus (et puis franchement, j'avais fait découvrir SVN à la SI, j'étais le roi, indestructible).

Ma conclusion, c'est traitez au minimum avec les cols bleus, y'a toujours un problème avec eux : ils ont pas l'argent pour aller au même resto que toi le midi, ils peuvent pas venir au café parce que la cloche de la pause a pas sonné, dans le boulot ils sont pas souple parce qu'ils ont des métriques partout. Bref, ils font globalement chier, je les évite.

Je sais pas trop quoi penser de ce débat...

Ici on a pas ces problèmes parce qu'on est une toute petite structure, même si on est assez organisés (Git flow, Kanban avec Trello pour gestion de la prio).

D'ailleurs, depuis que Kanban est là pour éviter de faire 36 trucs en même temps, on a beaucoup progressé en terme d'efficacité. Et moi je m'y repère nettement mieux dans la liste des trucs à faire (pour décider c'est vachement bien).

Ceci dit on a encore des axes d'amélioration sur les profils non-techniques, avec qui j'ai du mal à gérer les tâches en cours et avoir des estim de charge. Mais bon j'ai pas spécialement le temps de tout piloter alors je laisse rouler de ce côté là.

et apres tout ca, y a eu procedure mise en place pour virer les ordres?

Y'a quoi que tu comprends pas dans "on ne demande des comptes qu'aux cols bleus" ?

ca depend. Je bosse dans la branche IT/IS de la branche R&D d'une enterprise de la taille d'un dinosaure et on a pas ces problemes.  
Tout est pas parfait mais on fonctionne relativement independament du reste de la structure et nos process changents rapidement avec les besoins et selon le feedback des equipes en internes. Et pourtant on est efficace. Alors y a des trucs qui tombent de temps a autre mais la liberte et creativite ont un prix et il est accepte

j'ai pas compris si t'etais un col bleu ou rose dans l'histoire.

rose.

 
Eh ben ta bien de la chance

 
Nray il est beyond budgeting
Et dis pas que ça peux pas marcher il a géré plus d'entreprises que toi

je vais répondre, parce que c'est argumenté, même si évidemment je ne suis pas d'accord avec tout (j'ai reçu un gros paté anonymisé d'un dev qui pensait la même chose, j'ai répondu, et ça leur a troué le cul que je le fasse
 

Mais ça ça joue dans une boite où c'est admis de bosser comme ça. Genre Plam il décide dans sa boite qu'on bosse en agile, on bosse en agile, et c'est plié. Tu sais comme moi que les grosses boites s'y mettent parce que ça fait tendance, mais c'est très orthogonal avec les process existant dans ladite boite. Et là en l'occurence ce sont les devs qui ont poussé pour l'agile, en évitant soigneusement de se demander ce qu'il allait se passer en dehors de leur équipe (je rappelle que quand ils mis l'agile en place, ils n'ont pas pris la peine de s'assurer qu'on aurait un product owner...et sont parti du principe que mon équipe le ferait par défaut. Sachant que je ne suis pas le business mais un proxy, hilarity ensues)
 

j'ai jamais parlé de finances perso, mais allons-y : avant d'être un cadre hyper bien payé j'étais un cadre 2 métallo pas très bien payé (quoique en FR 2300€net c'est déjà pas mal), et avant ça j'étais un étudiant pauvre qui vivais chez sa mère qui vivait (et vit tjs) avec les minima sociaux. On peut faire un concours de bite, mais je suis pas sur de perdre.
 
après une grosse partie de mon job c'est de controler comment on dépense l'argent IT, donc oui c'est ma responsabilité, c'est même écrit dans ma jobdesc. Et sur un modèle de retail direct, selon ce qu'on livre, ça peut impacter très directement le business (quand on lance une nouvelle machine aux US avec 40+ MCHF de budget marketing, sans parler des années de R&D, et que tous les flyers/pub/etc pointent sur le site, le site il est up le jour J.
 

je vais te prendre une métrique simple pour te montrer mon job. Avant que je prenne la responsabilité de tout le portefeuil de projet eCommerce, on livrait en moyenne 3-4 projets par an, avec un dépassement de 200-300% environ, et on lançait 1-3 nouveaux pays par an.
L'année dernière, on a livré plus de 15 projets feature dans le budget (on a meme rendu du fric), on a lancé 23 pays, et lancé une nouvelle app mobile dans 36 pays.
La différence ? j'ai monté un team de PM et de BA : les PM drivent et controlent que le busines parte pas en vrille, et que les devs sautent pas sur l'occasion pour dev des trucs funs qui coutent 3x plus chers et ne sont pas demandés, et des BA qui sont aussi system analyst, et qui permettent d'éviter des devs en montrant ce que le système supporte.
Pour ça j'ai été très grassement augmenté, j'ai une excellente notation, et notre programme a été nominé 2x à un award interne donné par le CEO, award qu'on a gagné en 2013. Et j'ai insisté pour que dans les vidéos et sur scène, j'ai des représentants de chaque team...ben y'a que les testers qui ont vu l'intéret, les autres ont dit "non moi je fais pas ce genre de trucs". Donc faut pas me faire chier sur la visibilité des pauvres dev, même quand on leur donne ils ne la prennent pas.
 

c'est là ton erreur, ma boite est hélas dysfonctionelle : tout est sur le cul des PM :
- on livre pas ? c'est la faute du PM
- on dépasse les budgets ? c'est montré dans un rapport tous les mois en Copil devant le CIO, avec des pastilles de couleurs pour montrer à quel point le PM a mal fait son job (ou bien fait, selon)
- on doit faire un scope change ? c'est parfois 0.5 jours de boulot pour écrire les stories manquantes, et 3j pour le PM pour faire toute la paperasse pour demander le fric, sans compter que je dois passer en COPIL pour vendre le scope change, et que selon les humeurs, ça passe ou pas.
 
si ça merde ou ne livre pas, le dev n'est jamais exposé : c'est par design, le chef du département de dev étant un ancien dev, il a voulu protéger les devs dans du coton, rien ne leur arrive jamais. RIEN. Je te promets qu'ils se ramasseraient 10% de ce que je prends dans la gueule du business et de ma hiérarchie quand un projet merde, ça changerait des comportements, et c'est de ça dont je me plains.
Et c'est idem si la qualité de la release est à chier, ou introduit des régressions, ou si la release prend 2 mois dans les dents.
 
J'ai fait l'XP : sur un dérapage récent, le business a convoqué un meeting pour savoir pourquoi on décallait de 3 mois, j'ai invité le lead dev (je l'ai défendu parce que je suis pas une pute, mais je voulais juste qu'il voit l'ambiance du meeting). Il est ressorti tout pâle, curieusement
 
c'est tellement le bordel au dev que y'a meme des devs qui se barrent tellememt ils se sentent pas managé dans leur équipe...
 

cf supra : j'ai établi que sur 2013-2014, le dev dépasse en moyenne de 42%, chiffres à l'appui sur l'ensemble des projets. Il ne s'est rien passé.
ce qui a changé, c'est qu'un nouveau manager de l'équipe de dev qui venait d'arriver a fait une enquete de satisfaction qu'il a rendu publique (les résultats aggrégés), et que l'équipe de dev s'est fait laminer sur ce point, et qu'il a poussé pour changer les choses.
 

 
Tu leurs donnes assez de responsabilités ou c'est juste des engrenages? Perso je les comprends (en tant que dev), si c'est pas un truc que j'ai fait (et par la je veux dire que j'ai au moins décidé de comment le faire), je suis moyen intéressé par l’aumône de mes chefs. Dit autrement, si c'est un truc que j'ai mené j'en parle aux autres avec plaisir; si j'ai juste pisse du code, je vois pas l’intérêt de faire le mariolle devant des cols roses.