Discussion :

[singman]

Enfin quelqu'un qui ose taper sur la table et dénoncer les manipulations de la méthode Agile.
Cette méthode est née pour permettre aux programmeurs de continuer a travailler alors qui n'ont pas la capacité d'organisation suffisante. Tout le reste s'est construit autour de cette idée. Alors oui, il y a bien quelques notions intéressantes dans la méthode Agile, mais sur le long terme, c'est une vaste fumisterie qui conduit trop souvent dans le mur ou aboutie a des projets absolument impossible a maintenir / modifier / terminer.
Je parle bien évidement ici de projets d'une certaine taille, pas du bout de code pondu en 1 journée pour un client.

[chouetz]

Ce qui est idiot c'est de faire du tout Agile. C'est une autre alternative au cycle en V qui comme le precedent a ses avantages et inconvenients.
On pourrait tres bien jongler entre les methodes selon les projet au gre du bon sens des managers.
Un cycle en V quand tout le monde joue le jeu ca marche aussi tres bien, c'est toujours pareil.

Bref, ca va faire comme la gueguerre C/Java ou Nadal/Federer, les debats sont pas finis entre les partisants enflames pas toujours objectifs, plutot que d'essayer de voir les avantages des 2 parties.

[Bono_BX]

@Jitou : pour avoir vu des projets en Agile et en Cycle en V réussir comme échouer, je me permets de te faire part de mon expérience pour te répondre.

Je me suis trouvé souvent ridicule dans ces stand-up imposés tous les matin, déjà pourquoi se lever et abandonner sa concentration alors qu'on bosse les uns en face des autre pour se faire une réunion du genre les alcooliques anonymes dans un coin de la pièce ?

Enfin pendant ces réunions on a souvent rien à se dire et il faut quand même se farcir ce que les autres ont a dire sur le travail alors que l'on ne partage pas les mêmes sujets, d'ailleurs plus personne n'écoute personne mais il faut le faire ... encore une fois ridicule et inefficace.

Tu as tout à fait raison. Cela vient d'une perversion du stand-up meeting : à l'origine, c'était très informelle, genre à la machine à café, mais ce n'était pas du tout une réunion. Y participait qui veut, quand il peut, et on parlait aussi bien du code que du dernier film que l'on est allé voir que de la fille que l'on a rencontré ce week-end. L'intérêt, c'est de créer un moment convivial où les gens sont accessibles. Par exemple, tu avais une question à poser à Truc, mais il était plongé dans son code et tu ne pouvais pas le déranger ; à la machine à café il est libre et là tu peux lui poser ta question, sans l'interrompre dans son travail.
Malheureusement, c'est devenu une réunion à part entière qui, comme tu le dis, ne sert à rien et gêne les développeurs dans leur travail. Il faut, dans ces cas là, revenir au principe de base (message à faire passer au chef de projet / team leader).

Ensuite les petits post-it sur le tableau encore une invention ridicule, on a l'impression qu'une panne d’électricité et survenu et que l'on se mets alors à gérer le projet à l'ancienne ... de toute manière les papiers plus personnes ne les lit maintenant ils ne servent plus qu'à donner bonne conscience au directeur de projet et à égayer le mur fades de papiers colorés.

Encore une fois, tu as raison. Les post-its sont juste un point de départ des méthodes agiles. Maintenant, il existe des outils permettant de gérer les user stories / defects en se débarrassant de cette contrainte (si vous voyez un jour mon écriture, vous comprendrez pourquoi c'en est une !), et de manière bien plus efficace.

On en a un peu ras le bol de ces méthodes contraignantes élaborées par des consultants et qui visent à déposséder le développeur de son travail. J'ai expérimenté d'autres méthodes "agiles" qui elles marchent et je n'ai pas eu besoin qu'on me dise quoi ou comment faire.

Si, à nouveau, on revient aux origines de l'Agile, on se rend compte que ce n'est ... que du simple bon sens. Souvent, un bon développeur seul ou une équipe compétente saura s'auto-organiser, et fera de l'agile sans même le savoir, et ça fonctionnera parfaitement ! Et effectivement, il y a danger quand on voit débarquer sur un projet un "consultant-chef de projet-team leader" spécialisé dans l'agile qui veut mettre en place une méthode avant même de regarder la nature du projet, ses contraintes et le besoin du client.

[Laurent 1973]

N'oublions pas qu'il n'y a pas une méthode Agile, mais des méthode Agiles.

J'ai un ami qui travaillait dans une Web entreprise.
Ils avaient voulu faire un virage à l’agilité mais après quelque temps ils ont laissé tombé.

En faite, ils ont voulut appliquer Scrum.
Or, leurs projets pour les clients étaient pratiquement que des développements de quelque jours, faisant intervenant des personnes de compétences différences (infographiste, développeur, production, ....).
Et bien sur, chaque personne était à cheval sur plusieurs projets en même temps.
Il est évident que Scrum ne pouvait pas marché dans ce contexte.
L'itération régulière de colle pas avec le rythme de livraison client.
La spécificité de chaque équipier ne permet pas à rendre chacun polyvalent sur un projet.

Par contre, ils auraient utilisé Kanban, je pense qu'ils auraient pu faire vraiment évoluer leurs façon de travailler dans le bon sens.
Les livraisons en production auraient pu suivre la logique du développement en intégrant ces personnes dans les projets.
Ils auraient pu mieux anticiper les goulots d'étranglement (ex: le spécialiste SGBD a trop de projets en même temps)
Ils auraient une meilleur réactivité sur la réalisation des besoins de leurs clients.

@Jitou: c'est peut être ton cas, Scrum correspondait peut être pas à votre équipe. Une autre organisation agile aurait peut être pu être plus bénéfique que celle là.

Maintenant, Agile est une méthode d'analyse plus que de développement.

Scrum est en effet une méthode fortement appuyé sur l'analyse du produit client, mais Scrum n'est pas à lui seul l'agilité.
Prend par exemple la méthode eXtrem Programming (XP) et là, tu auras peut d'analyse produit mais une collection d'outils d’ingénierie agile (TDD, pair programming, Intégration Continue, ...) pour aider le développement d'application informatique.

Quand une entreprise à bien compris l'esprit de l'agilité, elle peut même trouver sa propre organisation en mélangeant plusieurs concepts de plusieurs méthodes (parfois un mixte entre Scrum, Kanban, XP et autres ).
L'important alors:

• Ne pas oublier que l'on développe un produit informatique pour un client et des utilisateurs qui ont leurs besoins et leurs contraintes propres.
• Avoir toujours un temps de rétrospective afin de bien se poser, en équipe, la question de ses pratiques et de voir comment on peut toujours les améliorer.

Mais sinon, l'agilité est très ouverte.

[Tr0n33]

L'Agile c'est utile quand on n'essaie pas de te le vendre à tout bout de champ. Ca ne s'adapte malheureusement pas à toutes les entreprises ou tous les projets. Mais globalement tout le monde utilise des méthodes de travail qui se rapproche de Scrum. Le souci c'est que beaucoup veulent l'appliquer à tout sous le prétexte que c'est magique. Ca ne s'adapte pas à toutes les entreprises, pas à tous les projets. J'ai par exemple vu du Scrum dans une TMA sans développement. Scrum c'est chouette, mais pas dans des structures monolithiques gigantesques. Allez donc organiser en Scrum la refonte de tout un SI dans 3 ou 4 technologies différentes. Scrum est une plaie, un cancer causé par les gens qui l'utilisent n'importe comment . Le TDD c'est comme tout, il n'est pas besoin d'en faire des tonnes, l'objectif étant de développer. Trop de développeurs vont se lancer dans un désir de perfection monstrueux sans comprendre l'aspect jetable de certaines choses pour gagner du temps.

Et beaucoup de choses sont informelles dans Scrum. Y a pas besoin d'organiser une réunion tous les jours si les différents parties savent se causer à la machine à café.

J'ai passé de bons moments en Scrum comme de bons en cycle en V (et de très mauvais moments dans les deux).

Bref. Ca ne s'apprend pas sur un coin de bureau l'Agile, ni avec 50 ppt... C'est une mise en pratique quotidienne d'éléments qu'on peut faire évoluer ou disparaître quand les gens sont habitués. C'est un "cadre".

[gabriel.klein]

L'agilité marche bien dans certains cas, mais pas partout. Cette méthode n'est pas faite pour tout le monde, elle demande à des "pisseurs de code" qui ont l'habitude d'être très bien gérés une certaine adaptation.

De plus c'est un système ou on "casse la hiérarchie". J'aime bien inverser visuellement le système hiérarchique dans l'agilité, le chef se trouve tout en bas, les "codeurs" tout en haut. Le but du chef est d'être au service des autres.

D’expérience il faut environ "une année" pour qu'un profil non agile expérimenté s'adapte à une méthodologie agile: "je n'ai pas assez d'informations, je peux pas travailler sans un projet bien défini.". Quelqu'un qui sort des école s'adaptera en quelques jours.

Pour terminer, l'agilité est une très bonne chose si on fait un projet pour la première fois, qu'on ne sait pas exactement ou on va. Qu'on doit s'adapter, qu'il y a beaucoup d'inconnus, de recherche. Le daily meeting, retrospective sont des choses qui forcent des gens qui sont souvent un peu dans leur monde à communiquer, et c'est une excellente chose. Les développeurs sont souvent des gens moins ouverts que des commerciaux, alors il faut les aider à partager des informations, à discuter ensemble.

Si on fait un projet pour la 10ème fois, une méthode de gestion de projet très structurée (ex: Waterfall), un management de proximité, est mieux. Car on sait exactement ou on va, on connais les problèmes, on a souvent déjà une base précédente pour gérer un projet.

[javatd]

Pour ma part, un bon projet géré avec des méthodes classiques, nous a laissé deux ans et demi sans voir une ligne de code, ni même un bout de programme qui fonctionne et nous a coûté 1,3 M €.
Ou comment emmener le client le plus loin possible afin qu'il ne puisse faire machine arrière et soit obligé de casquer 2 fois le prix en 2 fois plus de temps, bravo IBM !

[RedGuff]

"au point ou"

[napi15]

Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ? OUI

Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
POUR CAR AGILE C'EST UN CANCER

Agile freine-t-il l’écriture du code ?
IL PERD BEAUCOUPS DE TEMPS

[Laurent 1973]

Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ? OUI

Que pensez-vous des déclarations d’Erik Meijer ? Pour ou contre ? Pourquoi ?
POUR CAR AGILE C'EST UN CANCER

Agile freine-t-il l’écriture du code ?
IL PERD BEAUCOUPS DE TEMPS

Je suppose que tu as cette opinion suite à un retour d’expérience malheureux.
Tu peux un peu détailler ?

Tu travaillais sur un gros projet ou un petit?
Quel organisation agile aviez vous ? (Scrum, Kanban, autre..)
As tu eu une meilleur expérience sur un projet gérer en waterfall (en V) ?

[napi15]

Je suppose que tu as cette opinion suite à un retour d’expérience malheureux.
Tu peux un peu détailler ?

Tu travaillais sur un gros projet ou un petit?
Quel organisation agile aviez vous ? (Scrum, Kanban, autre..)
As tu eu une meilleur expérience sur un projet gérer en waterfall (en V) ?

Oui Oui , j'ai fait un stage dans une grande ^entreprise en génie logicielle . Je peux te dire que Le scrum n'etait qu'un outil depressive.

Voici les mauvaises expérience vécu et pourquoi JE DETESTE cette methode :

1) on m'a chialer sur plusieurs reprise car j'ai travaillé sur des tasks hors du scoop du sprint ( c'est des tasks super facile a résoudre et les utilisateurs ont apprécier la rapidité d’exécution de leur demandes ) MAIS ca ne respect pas la méthode agile donc....on me taper le derrière mais ....c'est pas sa ce que un développeur est senser de faire ? (satisfaire le demande des utilisateurs dans le moindre délai et coup possible ) c'est ce que m'a appris toujours a l’école

2) le scrum master a trop pris des décisions concernant le code ( alors qu'il est seulement senser de s'occuper du coup et du temps ) LE CODage c'est le travail du DEVELOPPEUR

3) BEAUCOUPS de délai a finir les taches car il dépendant d'autre tasks (encore une fois il était interdit de travailler sur les autres task -> car la méthodologie agile l’autorise pas )
4) On travailler sur la maintenance de plusieurs projet (2-3) dont un qui est assez sophistiquée et on était une équipe de 4 développeur expérimenté et un stagiaire qui est moi . Et je pense qu'on est assez mature pour juger et prendre des décisions par nous mêmes sans avoir un cauchemar qui s’appelle scrum a nous guider

en conclusion , Agile , scrum et bla bla bla c'est un enfer pour un développeur . Par contre , c'est un bon outil pour la gestion de projet , je répète bien GESTION DE PROJET et non Développer un projet , c'est un bijoux pour les gestionnaires les project manager etc ( excellent pour gérer l'argent et le temps et la date de livraison des projets) ... mais pour un développeur c'est un cauchemar

[el_slapper]

(.../...)la méthodologie agile l’autorise pas(.../...)

Voilà.

Ca, c'est de la connerie. C'est ce que t'ont dit tes chefs, mais c'est de la connerie. Mais c'est pareil en waterfall, hein, sauf qu'en waterfall c'est assumé. En waterfall, j'ai fait une tâche non planifiée, et j'ai eu une enguelade de 20 minutes(et en fait, ils étaient très contents, mais ils n'avaient pas le droit de le dire). Le principe de l'agile, c'est justement de faire ce qu'il faut faire, quand il faut le faire, même si ça n'est pas prévu.

Ce genre d'imbécile est juste imperméable à ce genre de principe, et est tout perdu dès qu'on sort du planning. Agile ou pas, ça ne changera jamais. Tu est tombé sur des imbéciles, pas sur des agiles.

[Tr0n33]

Outch.

En conclusion, de mon point de vue, tu n'as pas utilisé du Scrum mais un ensemble de processus régulé par l'entreprise.

on m'a chialer sur plusieurs reprise car j'ai travaillé sur des tasks hors du scoop du sprint ( c'est des tasks super facile a résoudre et les utilisateurs ont apprécier la rapidité d’exécution de leur demandes )

Et heureusement qu'on t'a rappelé à l'ordre. Imagine que contractuellement ta task soit disant très simple, plante sur la mise en production et décale des éléments d'un sprint. Tu prends la responsabilité de payer les pénalités ? Être développeur ne veut pas dire ne faire que du développement mais aussi être au courant des tenants et aboutissants de son travail. Un développeur, développe oui, mais il développe ce qu'on lui demande. Les développeurs qui décident dans leur coin, c'est ce qu'il y a de pires dans un projet.

le scrum master a trop pris des décisions concernant le code ( alors qu'il est seulement senser de s'occuper du coup et du temps ) LE CODage c'est le travail du DEVELOPPEUR

Ce n'est donc pas la méthode Scrum qui a été appliqué dans ton cas car si le scrum master avait fait son travail, c'est à dire si la méthode avait été respectée, tu n'aurais pas râlé sur ce point. Tu râles sur un élément qui n'a rien à voir avec Scrum mais avec un individu qui dévie la méthode. Donc ce n'est pas la méthode qui est critiquable mais le processus de l'entreprise dans laquelle tu as travaillé. La nuance est de taille.

3) BEAUCOUPS de délai a finir les taches car il dépendant d'autre tasks (encore une fois il était interdit de travailler sur les autres task -> car la méthodologie agile l’autorise pas )

La méthodologie Agile ne restreint rien du tout ! Da fuk ! La règle numéro 1 de toutes les méthodes agiles c'est de dire qu'on fait les choses quand on en a besoin et qu'on est capable de les adapter au fur et à mesure du développement. Elle fait primer l'humain au processus. Encore une fois, ce n'est pas la méthode agile qui restreint mais le processus de gestion de projet dans ton entreprise. La nuance est colossale.

4) On travailler sur la maintenance de plusieurs projet (2-3) dont un qui est assez sophistiquée et on était une équipe de 4 développeur expérimenté et un stagiaire qui est moi . Et je pense qu'on est assez mature pour juger et prendre des décisions par nous mêmes sans avoir un cauchemar qui s’appelle scrum a nous guider

Justement la méthode Scrum considère que les développeurs et les utilisateurs sont au centre du système. Tu n'as juste appliqué dans l'entreprise que les bouts de Scrum qui plaisait à la direction tout en gardant les superbes processus classiques d'entreprise en France. J'appelle ça de la soupe pseudo agile à laquelle on appose une marque. Ca n'a rien à voir avec les méthodes agiles justement.

en conclusion , Agile , scrum et bla bla bla c'est un enfer pour un développeur . Par contre , c'est un bon outil pour la gestion de projet , je répète bien GESTION DE PROJET et non Développer un projet , c'est un bijoux pour les gestionnaires les project manager etc ( excellent pour gérer l'argent et le temps et la date de livraison des projets) ... mais pour un développeur c'est un cauchemar

Un enfer ? Un bijou pour les gestionnaires ? C'est justement le gros problème en France : de réussir à imposer au management la "vraie" méthode Scrum. Le centre de la méthode agile c'est justement "l'agilité" contrairement à la rigueur de la gestion. C'est tout le contraire. Le coeur c'est le client, le développement et l'interfaçage entre les deux. Déjà quand je lis que tu le pratiques dans le cadre d'une TMA, je bondis. Mais je bondis très haut car c'est encore des chefs qui ont brandi la méthode comme la croix dans une église. Ils n'ont rien compris à son fonctionnement, s'empare de certains bouts qui justifient leur gestion de projet et oublie la première de toutes les règles (elle est écrite dans l'article).

C'est fou comme on peut confondre la méthode et les processus d'entreprise.

D'ailleurs le métier du développement ça n'est pas juste développer ou prendre des décisions sur le code. J'ose espérer que le génie logiciel c'est un peu plus que ça justement.

[ZenZiTone]

En ajout à ce qui a pu être dit :

(encore une fois il était interdit de travailler sur les autres task -> car la méthodologie agile l’autorise pas )

Il me semble qu'on ne parle pas de tâches, mais de fonctionnalités en Scrum et dans les méthodes agiles en générales. Si ces fonctionnalités ont bien été identifiées, hormis quelques exceptions, les dépendances sont inexistantes.

Et je pense qu'on est assez mature pour juger et prendre des décisions par nous mêmes sans avoir un cauchemar qui s’appelle scrum a nous guider

Tout dépend du niveau des décisions... Le fonctionnel c'est pour le client, le technique c'est pour l'entreprise ou le team leader. Si chacun fais sou bouiboui dans son coin on fonce droit au mur

c'est un bijoux pour les gestionnaires les project manager etc ( excellent pour gérer l'argent et le temps et la date de livraison des projets) ... mais pour un développeur c'est un cauchemar

Je pense que, au contraire, la tâche est plus compliquée pour le gestionnaire de projet, ou "Scrum Master", qui doit faire un effort supplémentaire tout au long du projet pour faire appliquer la méthode. Grossièrement le développeur n'a qu'a prendre son post-it sur le Scrum Board, développer sa fonctionnalité et faire part de ces difficultés/remarques/propositions/etc.. durant les réunions...

[Laurent 1973]

1) on m'a chialer sur plusieurs reprise car j'ai travaillé sur des tasks hors du scoop du sprint ( c'est des tasks super facile a résoudre et les utilisateurs ont apprécier la rapidité d’exécution de leur demandes ) MAIS ca ne respect pas la méthode agile donc....on me taper le derrière mais ....c'est pas sa ce que un développeur est senser de faire ? (satisfaire le demande des utilisateurs dans le moindre délai et coup possible ) c'est ce que m'a appris toujours a l’école

Et heureusement qu'on t'a rappelé à l'ordre. Imagine que contractuellement ta task soit disant très simple, plante sur la mise en production et décale des éléments d'un sprint. Tu prends la responsabilité de payer les pénalités ? Être développeur ne veut pas dire ne faire que du développement mais aussi être au courant des tenants et aboutissants de son travail. Un développeur, développe oui, mais il développe ce qu'on lui demande. Les développeurs qui décident dans leur coin, c'est ce qu'il y a de pires dans un projet.

L'autre cas où on ne doit pas faire de fonctionnalité (pour pas dire tache, vu qu'il y avait une valeur client d'après toi), c'est que tu ne sais pas forcement les négociations commerciales qu'avaient ta boite avec des clients.
De ne pas vouloir prendre une fonctionnalité "facile" dans le backlog trop tôt peux aussi faire partie d'une stratégie de ton Product Owner pour des futures ventes par exemple.
En poussant ta jolie amélioration dans la livraison courant, tu peux avoir enclenché un dilemme du PO: livrer quant même la version du sprint (mais perdre une renégociation de contrat) ou ne pas livrer (et se retrouver en faute avec un client).
=> Bon, l'agilité impose de la transparence et dans ces cas là il est bon aussi que le PO soit claire sur ce type de démarche de sa part.

Scrum, avec son principe de contrat de sprint, impact aussi toute la chaîne de commercialisation d'un logiciel.
Donc, si tu voulais faire cette fonctionnalité dans le sprint, il fallait la demander à ta réunion de "Sprint planing" pour qu'elle soit ajouté dans le "Sprint backlog"
A ce moment là, la fonctionnalité fait partie du sprint et même le PO peux l'annoncer au client.
Même si la conséquence n'est pas aussi importante, le PO avait peut-être annoncer au client que la fonctionnalité en question serait dans 2 itérations et là il passe pour une buse qui ne sait pas ce que les développeurs font.
Et pour un commercial, se faire prendre pour un incompétent par un client c'est trèèèèèès désagréable.

Et puis, même si cette fonctionnalité était facile à réalise (développement + tests + doc + validation fonctionnelles + .... enfin respectant votre Definition of Done) il aurait été mieux que tu aides tes collègues sur les autres fonctionnalités, quitte à être en Pair Programming et en apprendre un peu plus sur d'autre partie du logiciel.

Dans ton retour d’expérience, il me semble qu'il y a 2 soucis qui se sont téléscopés:

• Comme le dit Tr0n33, l'entreprise n'est pas réellement Agile, mais très dirigiste dans ses procédure en saupoudrant de concepts vaguement Scrum
• Toi même, tu me sembles un peu un "chien fou", très indépendant, qui a du mal à accepter des règles d'entreprises.
  Tu es jeunes, on l'a été aussi, mais essaye d'être plus humble dans ton travail.
  Croire que "on est assez mature pour juger et prendre des décisions par nous même" dans ta position est une erreur, on a rarement la vision global d'un produit informatique sur lequel on travail.

[zecreator]

Je ne connais pas les concepts Agile et ne les pratiques pas. Mais si "développer dans un environnement Agile" veut dire "passer sa vie en réunion en se tirer la nouille en se demandant Pourquoi ? Comment ? Qui ? Quand ?", ben merci mais non merci. Je suis développeur, je code... Si j'avais envie de passer mes journées en réunion à rien foutre, je serai Chef de projet !

[Laurent 1973]

Je ne connais pas les concepts Agile et ne les pratiques pas. Mais si "développer dans un environnement Agile" veut dire "passer sa vie en réunion en se tirer la nouille en se demandant Pourquoi ? Comment ? Qui ? Quand ?", ben merci mais non merci. Je suis développeur, je code... Si j'avais envie de passer mes journées en réunion à rien foutre, je serai Chef de projet !

On ne passe pas sa vie en réunion en Agile.
Par exemple, en Scrum, pour des itérations de 4 semaines, tu auras seulement:
- 8 heures de Sprint Planing
- 1/4 heures de Daily meeting chaque jours
- 4 heures de Sprint review
- 3 heures de Retrospective
=> total = 19h30 de réunion par mois.

Et sinon, combien de temps passe tu en réunion pour ton projet actuellement ?
Fait le compte, ça va très vite.

Autre question: tu code, d'accord, mais quoi et pourquoi?

[zecreator]

Bien évidemment les réunions sont utiles. En règle générale il y a :
- une réunion de cadrage avec le client (afin de déterminer ses besoins et son environnement technique) = de 2 à 3 heures
- une réunion à chaque livraison de version afin de déterminer les corrections à apporter = 30 min max X par le nombre de livraison (3 à 4)
- une réunion de livraison finale (avec Champagne, binouze et petits fours) = de 1h à toute la nuit

Il y a aussi des réunions avec le client pour valider les contenus, le storyboard... Mais les développeurs n'ont pas besoin d'être présents.
En tout, sur un projet de 2 mois je dois passer 5h en réunion grand max.

Par exemple, nous venons de livrer 2 gros projets avec des délais très serrés. A livrer au même moment pour 2 clients différents. Pas question de passer 20h par mois et par projet en réunion. Pendant que je suis en train de taper la discute sur la beauté de mon code, y a personne derrière mon PC pour programmer à ma place. Et les 20h de réunion où j'ai pas codé, j'ai pas envie de les rattraper le soir après le bureau ou le week-end pour rester dans les délais.

[Saverok]

@zecreator
Si la seule chose qui t'intéresse c'est le développement et rien d'autre, tu n'as pas le profil pour travailler sur un projet Agile.
Je ne porte aucun jugement
Tu as parfaitement le droit d'être focalisé sur l'implémentation.

Pour travailler en mode Agile, on a besoin de profils plus transverses, limite DevOps
Les développeurs ne font jamais que du dev dans un projet Agile
Il font également la conception technique et fonctionnelle, de la qualité, etc.
Bref, c'est beaucoup d'échange en direct avec le client qui implique de savoir s'adapter à son interlocuteur et comprendre son besoin pour le traduire techniquement.
L'organisation n'est absolument pas pyramidale où chaque rôle est cloisonné à une fonction.

[zecreator]

@zecreator
Si la seule chose qui t'intéresse c'est le développement et rien d'autre, tu n'as pas le profil pour travailler sur un projet Agile.
Je ne porte aucun jugement
Tu as parfaitement le droit d'être focalisé sur l'implémentation.

Pour travailler en mode Agile, on a besoin de profils plus transverses, limite DevOps
Les développeurs ne font jamais que du dev dans un projet Agile
Il font également la conception technique et fonctionnelle, de la qualité, etc.
Bref, c'est beaucoup d'échange en direct avec le client qui implique de savoir s'adapter à son interlocuteur et comprendre son besoin pour le traduire techniquement.
L'organisation n'est absolument pas pyramidale où chaque rôle est cloisonné à une fonction.

Comment un développeur peut faire de la gestion de projet sans avoir la formation qui va avec ? Faut que l'on m'explique comment on arrive à vendre ça au client...