Reprise du message précédent :

This.
La norme que je pratique, c'est écrit texto : pour du soft, un cycle de développement en V doit être appliqué. Y'a quelques années ils ont même ajouté un schéma détaillé du cycle en V (j'imagine pour empêcher des petits malins de l'interpréter comme ils le veulent). Et précise que d'autres méthodes sont possibles (tant qu'elles intègrent "des processus disciplinés et structurés comprenant phases de conception et de test" ), mais en discutant avec un auditeur c'est à toi de faire la preuve que ton cycle de développement est au moins aussi sûr qu'un cycle en V

 
Nous aussi on a un process de gestion de projet parfaitement cadré et procéduré, avec tous les jalons similaire au cycle en V a quelques nuances près... Donc l'agile est pas du tout applicable dans nos équipes projets. Mais le central poussé pour qu'on "passe agile" parce que "agile c'est le futur, le GAFA est devenu GAFA grâce à la méthode agile" etc...  
 
Et vu que coté projet ils peuvent pas passer en agile, le management a décidé de faire passer ceux qui gèrent la routine en agile pour pouvoir répondre à la demande du central

Je bosse pour le G de GAFA. L’ingénierie est super, mais j’ai rarement vu des glands pareils niveau opérations. C’est le pire benchmark possible à prendre pour ça
 
C’est le truc qui me fait peur si je devais quitter G : retomber dans des boîtes capables de ce genre de mandat : la boîte X fait un truc qui marche, singeons la méthode sans comprendre l’état d’esprit, c’est sûr ça va marcher on va obtenir les mêmes résultats.

Tu es sûr que c'est la seule raison ? Est-ce qu'il n'y a pas des aspects particuliers de la méthode agile sur lesquels ils comptent, pour résoudre des problèmes de la méthode actuelle ? Si tu peux identifier ce qui inquiète les décideurs, tu peux essayer de mettre en place des changements ciblés pour répondre aux inquiétudes, et mettre un tampon agile dessus.

Vous allez avoir une formation agile ? Demandez comment ils comptent appliquer l'agile dans votre boulot au quotidien et exigez une formation pour toute l'équipe.

 
Non effectivement, les arguments sont:
 
-"Passer de releases en waterfall à des releases plus rapides afin d'avoir des gains plus rapides" -> On nous a rien allégé coté documentaire, nos "projets" sont toujours des upgrades ou corrections mineurs dont la priorité est dicté par les arrêts machines et les déviations.
 
-"Que vous ayez des priorités claires pour avancer efficacement sur les sujets" -> Notre priorité reste la routine donc, 6 heures de planification supplémentaire par tranche de 15 jours ne change rien au fait que les opérateurs en prod trouveront toujours de nouveaux moyens de planter les équipements qu'il faudra régler en ultra urgence.
 
-"Avoir tous les interlocuteurs autour de la table pour définir les priorités et donc travailler là où il a été défini qu'il y avait la plus grosse valeur ajoutée" -> Sauf qu'on est tous des spécialistes dans des domaines différents, la dernière itération par exemple j'avais quelque chose comme 6h de travail dans mon backlog (1 user story taille 1, si je me trompe pas ). J'ai fait deux semaines a 40h sur 4 jours malgré tout a cause des autres problématiques et dépannages...
 
Sachant qu'aucun KPI objectif n'a été défini pour valider si ça marchais ou apportait un véritable gain car trop durs à chiffrer, et que quatre autres équipes agiles sont déjà prévus pour la fin d'année  
 
Edit:

 
On nous a filé un consultant, qui fait coach agile. Sa seule occupation de la journée est d'animer nos boards. Son approche "l'agile permet d'avoir des gains dans tous les domaines, il faudra travailler ensemble et prendre du temps pour affiner la méthode a votre cas" et du coup fait juste la liste des remontées lors de l'itération rétrospective et le reporting au responsable de l'implémentation agile sur site.
Il a trouvé un filon en or le gars  

Rhaa, les professionnels de santé en libéral/clinique privée, ces gens dévoués au bien commun...

Après l'affaire des rdv d'orthodontie de Madame non honorés cause COVID, mais dont le paiement a été réclamé parce que "c'est un forfait de suivi", sans que ça les choque de rien suivre pendant 6 mois mais de prendre les thunes quand même , et l'argument massue "oui mais c'est remboursé, c'est pas grave", avec une gestion .... Disons floue (la secrétaire du cabinet prend les chèques au nom du dentiste, tu peux aussi payer directement par virement sur le compte perso de la dentiste, et ensuite il y a un pointage des paiements sur les relevés pour savoir combien tu as payé... Magique)

Le dépassement d'honoraires variable : 378.01 de dépassement sur le devis, mais 456.24 sur la facture...

Coup de fil a la clinique : ah oui, c'est une erreur, on va vous rembourser et vous rééditer la facture...
Sauf que si tu fais pas gaffe, ça passe crème, et la mutuelle doit rembourser exactement pareil...
Je me demande quel est la taux d'erreurs.

Ça plus la chambre individuelle pas demandée mais "imposée" (on n'a plus de place en double), et facturée (mais indiquée dans une petite ligne du devis sans le montant sous l'appellation "forfait confort, voir tarif sur l'annexe 1.b, hôtellerie" ), ça représente pas loin de 100 balles facilement gagnés sur le dos de la solidarité.

Bon courage vylkor, déjà que l'agile ça ne fonctionne pas pour les projets IT, alors pour du run pharmaceutique j'imagine même pas

Et les coach agiles... Sûrement la plus grande arnaque de ces dernières années, j'en ai pas vu un de bon / utile

Qu'est-ce qu'il te manque avec rectangle ?

TIL que BetterTouchTool fait aussi du gestionnaire de fenêtres

En même temps tes TL sont des tocards, tes dév sont nuls, tes archis à la rue, tes PO totalement à l'ouest, ...    

 
Je pense que ce qui compte derrière tous ces trucs, c'est la réflexion que cela apporte sur les workflows et sur plein d'autres aspects. Retenir et tenter d'appliquer une méthode à la lettre, c'est la pire des solutions quelque soit la méthode. Les coach agiles sont des arnaques si tu ne les utilises pas correctement.  
 
Chez nous par exemple, nous n'avons plus de deadlines sur les tasks (sauf exception liée à des incidents de support par exemple) et ce sont les employés qui choisissent leur tasks dans les backlogs. Mais c'est le fruit d'une réflexion et d'une évolution.

 
C'est un ressenti sur mes 5 dernières années, pas seulement cette dernière mission
 

Mes fiches ne sont pas à jour mais il me semble que sur ta mission précédente tu n'étais pas ébahi devant le talent de tes collègues, et peut être celle encore avant.
Et il y avait aussi un audit qui semblait totalement claqué ?
 
Enfin le sentiment que cela (me) donne c'est que tu es souvent sur des missions pas top, ou en tout cas qui donne l'impression que tu n'es pas ravi par le niveau des gens dans ton écosystème pro

La mission précédente il y avait de bons techos : les TL et les Ops. Le problème c'était plutôt l'archi et l'orga

C'est vrai que j'ai rarement était sur une mission où les bonnes conditions pour moi étaient réunies : sujet intéressant, dev meilleurs que moi et impliqués, bonne orga projet.

Mais en fait peut-être que ça n'existe pas

 
Mais je réponds à une offre d'emploi ou à une app de dating

 
+1000
 
le process actuel est toujours le fruit d'un jeu de contraintes, et d'une certaine vision des choses: quelles sont-elles, est-ce qu'on est pret à en remettre certaines en questions ? Est-ce qu'on doit changer notre point de vue ?
 
c'est souvent un cheminement, sur la base d'échec / problèmes résolus, qui font bouger les lignes petit à petit. C'est ce déverrouillage qui permet que le nouveau process fonctionne.
Par ex en agile un des gros verrous à débloquer c'est le fait de rendre les équipes responsables de leur temps et de leur choix, par opposition à des directives qui viennent de dessus. C'est aussi le fait d'évaluer une équipe à sa création de valeur, et non au nombre de cases cochées dans un workplan. Si tu vis dans un monde de directive top down, l'agile c'est juste une utopie.
 
Mais bon, je pense qu'il est impossible d'empecher le leadership d'essayer de singer des méthodes auxquelles ils ne comprennent rien. On voit ça partout, c'est pas propre à l'IT.  
- notre concurrent a un site ecommerce ! Vite, nous aussi, comme ça on sera omnichannel (c) (ton site fait 2 ventes par jour, c'est un gouffre à pognon, mais OK)
- il faut etre présent sur les réseaux sociaux, vite, embauchons un community manager ! (tu vends des machines outils mec, ta clientèle c'est Roger qui a 50 ans, mais OK)
- optimisons nos dépenses media, il faut passer au programmatic media buying ! (t'as pas la foutre moindre idée de qui sont tes clients parce que tu vends via des supermarchés, mais allons-y ciblons des gens qu'on ne sait pas reconnaitre. Celle là a du causer un de mes plus grand moment de gêne professionelle, où j'ai du expliquer le plus diplomatiquement du monde à notre SVP of Marketing chez N que non, essayer de viser les clients Perrier sur la base d'une segmentation de leur sens de l'humour (quirky, dry, etc...) ça allait pas marcher (en marketing les gens aiment bien avoir des persona basées sur des profils psychométriques, donc les descriptions sont très fleuries, genre Josianne, 37.5 ans, like knitting flower patterns, is finance savvy but only buys sustainable companies stocks, has a dry sense of humour and like Vodka martini stirred THEN shaken - c'est super pour faire des visuels de pubs, mais c'est inutile pour acheter du media, aucun de ces attributs n'étant ciblable)

 
Un pti mail la ca mange pas d'pain
 
https://www.ameli.fr/assure/adresse [...] utre-sujet
 

 
Une annonce cool pour t'attirer --> un salaire de merde derrière oué un date donc

Il n'existe pas de solution "one size fits all", et il y a toujours des adaptations à faire, mais entre de l'agile et du cycle en V, je prendrai de l'agile 9 fois sur 10.
Du cycle en V, j'en ai bouffé et c'est pas beau à voir. J'ai même quitté un boulot à cause de ça. Quand toute l'équipe passe 2 mois complets à ne rien faire parce que les specs ne sont pas prêtes, on a envie d'aller voir ailleurs.

2h de perdues ce matin parce qu'on a reçu une mise en demeure de ECA-Assurances, pour 2 contrats qu'on avait jamais souscris.

L'adresse email utilisée est une adresse qu'on n'a jamais créé, mais le numéro de téléphone est le bon, et le pire c'est que le code renvoyé pour signer les document (via docusign), n'a jamais été fourni par ma compagne, donc je ne sais pas comment ils ont pu faire.

J'étais là le jour où un courtier l'a appelé et elle a été clair qu'elle ne donnerai jamais de code et qu'elle veut recevoir par courrier les informations de ces contrats avant de signer.

Donc ce matin :
- Appel à ECA-Assurance en énumérant les infos qu'on a et en demandant des informations, surtout l'adresse email utilisée qui était : <prenom><codepostalerroné>@outlook.fr
 On a aussi demandé les coordonnées du courtier en question
- Appel au courtier en lui énumérant les faits et que ce n'était pas normal
- Envoi d'un email à l'adresse de réclamation, email bien long qui explique tous les faits, et le rappel du RGPD (merci chatGPT), évidemment j'ai relu le mail et corrigé si ça me plaisait pas.
- Création d'une préplainte en ligne afin d'aller porter plainte.

Voilà on ne laisse rien passer.

EDIT : Et la blague c'est que le RIB qui a été utilisé devait être un vieux RIB d'un ancien compte de ma compagne.

Ouais enfin ça fait penser à un problème fondamental au dessus, ptet que changer de méthodologie donne l’occasion de pêter quelques rotules et de changer les habitudes mais j’ai vécu l’agile où le client change d’avis toutes les deux semaines (mais les délais et le périmètres sont fixes ofc) et c’est à chier aussi.

 
Dans ces cas là je rêve d'avoir des feuilles avec entête d'un cabinet d'avocats    

Parle de SAFe à tes boss, dis-leur que c'est ça l'avenir.

Il faut surtout pas louper le train.

Non mais les problèmes du cycle en V sont parfaitement connus et identifiés.
Le votre c'est de ne pas facturer les changements d'avis du client. L'agile permet de corriger les erreurs de conception plus tôt mais en aucun cas cela veut dire que le travail dû à des demandes supplémentaires est gratuit.

Ah mais payer ils hésitaient pas une seconde Ils étaient super OK de payer pour avoir 9 femmes qui accouchent en 1 mois, c’était pas ça le problème, bien au contraire.

Bordel...
J'avais un jour de 5mm entre le tuyau PVC d'evac des eaux pluviales et le tuyau qui passe sous le trottoir...

J'ai sorti environ 10m de racines

quand on pense que Harko a sorti la même chose de son urètre !

 
on dirait un compactage de poil de chat...mon chat vomit des trucs comme ça de temps en temps

Le mien m'en a laissé sur le bord de la fenêtre de la cuisine ce matin

 
haha mettre du sucre dans le réservoir, du bon sabotage ça

https://twitter.com/EmmanuelMacron/ [...] 0368035848
 
Ça promet

J'suis dans une "formation" Rust à distance (qui en fait est une présentation). Le mec est perdu, il lit tout le temps ses notes. Trois fois sur quatre, le mec sait pas répondre à nos questions.
"Pourquoi on utilise pas const partout si let est par défaut immutable ?" - "je sais pas".
"Pour la diff entre String et str, me posez pas de questions svp je saurais pas vous répondre."

On verra si la suite empire ou pas.

 
Qui finance ca ?

Mais qu’est-ce que vous vous retrouvez avec un mec qui a besoin de formation à donner la formation?

Merci pour toutes les réponses, de ce que j'en comprend, oui on avais besoin d'un rework de nos méthodes de travail pour gagner en vitesse dans les delivery, et ils ont décidés que l'agile était la solution magique sans plus de réflexion...  
 
Donc au final, un truc qui vas échouer car qui ne tacle pas les root causes
 

 
C'est pas encore de la gestion de projet ça? De ce que j'ai lu vite fait c'est plus pour du projet large offrant plusieurs produits?

 
Ne rentre pas dans le troll ne parle jamais de ça

 
Dion.
 

 
 
 
Oui je connaissais un peu les réponses. N'importe quelle video de présentation de Rust l'explique. C'est pour ça que je suis étonné du niveau du gars.

Depuis quand on apprend des choses dans les formations d'IT ?

DEPUIS nullepart,  
Perso, c'est le genre de formation ou tu passes une semaine à faire des trucs, suivre un mec, à la fin de la semaine tu as des questions ou un exercice, mais au final tu vas oublier tout ça au bout de 2 semaines, parce que surtout tu n'en as pas besoin et tu n'en as rien à foutre.
Et tu vas payer ça 1000 balles minimum par tête.
 
Alors qu'un bouquin c'est 50 balles.

Un bouquin en 2023. Soyons sérieux.

Quand c'est bien fait, c'est comme une video d'une 1h sur youtube, sauf que là tu peux direct poser tes questions et avoir les réponses. Voire même débuter un ptit projet. Ca permet juste de découvrir beaucoup plus vite.  

Et dans le cas de Rust, voir des éléments importants en prio, plutôt que d'être noyé dans le cookbook.