Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
je ne suis pas dev , mais quand jai squatte quelques uns de ces meetings dans mon ancienne boite , cest limpression que jai eu ! apres cest peut etre parce que je pige pas tout donc je portes attention a dautres details.Envoyé par Jitou
Jai assiste aux premiers meeting en janvier , sauf que en septembre les post it etaient toujours les meme !
Je crois que nous sommes ici devant des perversions induites par le management moderne, tel que pratiqué par les grands groupes au nom de l'enrichissement permanent, et par les cabinets de conseil.
Il fut un temps où j'étais développeur. Je consacrais 90% de mon temps de travail à développer, le reste à la machine à café ou pour le pause cloppe (à l'époque on pouvait fumer dans les bureaux). De temps en temps le directeur de la salle des marchés pour qui je bossais me demandait où j'en étais et je lui répondais. Quand j'avais besoin d'aide, je regardais si un collègue était la tête dans le guidon ou pas, et j'allais le voir si possible. Tout se passait bien, et mes dates de livraison étaient respectées.
Mes remplaçants, 5 ans plus tard me racontaient qu'ils devaient faire des rétro plannings, des etudes et tout ça. Resultat, moins de 80% de leur temps alloués au développement. Et du coup ils étaient à la bourre et devaient justifier les retards.
Maintenant quand je discute avec des développeurs, ils me disent qu'ils consacrent à peine 60% (dans le meilleur des cas) à leur travail : DEVELOPPER ! Le reste, c'est des stan-up meetings, des réunions, des centaines de mails par jour, des rapports d'activité, des enregistrement de temps passé sur les projets dans un soft de suivi d'activité, du reporting au chef, des présentations power point de 40 pages pour expliquer l'intéret d'un truc à un "top manager" qui de toutes façons ne verra au final que le prix à payer, des points d'équipe, des points clients, des points management, du suivi budgétaire, de al justification budgétaire... Résultat ils sont à la bourre, livent des trucs pas propres, plein de bugs, et doivent après tout justifier poru finalement se faire virer pour insuffisance professionnelle...
Un autre exemple : au début de ma carrière je faisais du support (aussi). Je passais mon temps à faire du support et tout allait bien, la mécanique tenait la route. Quand je regarde le temps réel de support que font maintenant les équipes support (je parle pas de la prise d'appel mais du support) je suis sidéré ! et encore plus quand un consultant KPMG (ou un autre) lui explique comment il doit maintenant faire son boulot suivant la sacro-sainte bible du management moderne, écrit par des brillants penseurs qui n'ont jamais fait de support de leur vie.
Je pense que l'informatique, qui est en passe de devenir aussi primordiale pour l'homme que l'air qu'il respire souffre de trois maux :
- la démocratisation qui fait que tout le monde s'auto bombarde "informaticien" sans en avoir ni les règles ni les bases ni la formation parce que "en troisième année d'ingénieur option informatique financière, j'ai fait un site web avec du java"
- le management moderne qui veut sans arrêt expliquer à tout le monde comment faire une chose qu'il ne sait pas faire lui même.
- cette manie insupportable de vouloir prendre des ingénieurs là où on a besoin de programmeurs, et qui nous fait des générations d'ingénieurs désabusés et des programmeurs au chômage...
Autant dire qu'il y a peu d'espoir que ça s'améliore...
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.
Je vais un peu faire mon suisse mais :
Cycle en V : c'est beau sur le papier, mais ça dérive énormément, notamment parce qu'à cause de l'effet tunnel qui fait que les spécifications prennent leurs temps, sont pas carrés, et au final un truc analysable correctement en début du projet coûte après 100 jh en fin de projet. En plus ça isole les développeurs qui demandent souvent qu'à mieux comprendre ce qu'ils font et intervenir sur le projet (sont jamais contents, les développeurs !)
Méthode(s) Agile(s) : c'est beau sur le papier, mais ça dérive énormément, on profite justement de l'absence de documentation pour faire tout et n'importe quoi et se déclarer agile. Souple. Flexible. En plus, ça force les développeurs qui demandent qu'à bosser dans leur coin et faire leur expertise technique (sont jamais contents, les développeurs !)
Là encore, je vais faire mon suisse, mais un minimum d'implication du développeur est nécessaire. Le problème c'est comme tu dis, le faire venir dans des réunions où il a juste à valider et finalement lui prendre 120 minutes de sa journée si ce n'est plus. Ceci dit je reconnais des missions dans lesquelles ton point était :Je crois que nous sommes ici devant des perversions induites par le management moderne, tel que pratiqué par les grands groupes au nom de l'enrichissement permanent, et par les cabinets de conseil.
Il fut un temps où j'étais développeur. Je consacrais 90% de mon temps de travail à développer, le reste à la machine à café ou pour le pause cloppe (à l'époque on pouvait fumer dans les bureaux). De temps en temps le directeur de la salle des marchés pour qui je bossais me demandait où j'en étais et je lui répondais. Quand j'avais besoin d'aide, je regardais si un collègue était la tête dans le guidon ou pas, et j'allais le voir si possible. Tout se passait bien, et mes dates de livraison étaient respectées.
Mes remplaçants, 5 ans plus tard me racontaient qu'ils devaient faire des rétro plannings, des etudes et tout ça. Resultat, moins de 80% de leur temps alloués au développement. Et du coup ils étaient à la bourre et devaient justifier les retards.
Maintenant quand je discute avec des développeurs, ils me disent qu'ils consacrent à peine 60% (dans le meilleur des cas) à leur travail : DEVELOPPER ! Le reste, c'est des stan-up meetings, des réunions, des centaines de mails par jour, des rapports d'activité, des enregistrement de temps passé sur les projets dans un soft de suivi d'activité, du reporting au chef, des présentations power point de 40 pages pour expliquer l'intéret d'un truc à un "top manager" qui de toutes façons ne verra au final que le prix à payer, des points d'équipe, des points clients, des points management, du suivi budgétaire, de al justification budgétaire... Résultat ils sont à la bourre, livent des trucs pas propres, plein de bugs, et doivent après tout justifier poru finalement se faire virer pour insuffisance professionnelle...
Un autre exemple : au début de ma carrière je faisais du support (aussi
Je pense que l'informatique, qui est en passe de devenir aussi primordiale pour l'homme que l'air qu'il respire souffre de trois maux :
- la démocratisation qui fait que tout le monde s'auto bombarde "informaticien" sans en avoir ni les règles ni les bases ni la formation parce que "en troisième année d'ingénieur option informatique financière, j'ai fait un site web avec du java"
- le management moderne qui veut sans arrêt expliquer à tout le monde comment faire une chose qu'il ne sait pas faire lui même.
- cette manie insupportable de vouloir prendre des ingénieurs là où on a besoin de programmeurs, et qui nous fait des générations d'ingénieurs désabusés et des programmeurs au chômage...
Autant dire qu'il y a peu d'espoir que ça s'améliore...
* une mission où il fallait redoubler d'arguments et de rhétorique pour dire non au "directeur des développements" (ça implique quoi ce poste ???) qui veut absolument faire passer un truc impossible, ou du moins infaisable dans les délais / budgets impartis, et qui va jusqu'à éteindre ton poste, te confisquer ta souris jusqu'à ce que tu dises oui, tout en usant de la menace / la pommade / faire l'idiot / être idiot. Et après se plaindre que tu n'as pas bosser pour d'autres => voir "l'expert en réunion" je vous laisse googler.
* une autre mission où le but était de faire du ping-pong pour prouver qu'on traite bien les mails. Tu as raté la réponse d'un mail d'un quart d'heure ? Pas biiiiieeen.
Bref, le service informatique idéal, à l'image de la société idéale, comme on le voit dans la pub pour les prud'hommes en 1996 (je vous laisse googler) c'est pas demain qu'on la verra...
@arkhamon
Je ne partage pas du tout ton pessimisme
Le fait qu'il y ait des mauvais managers ne justifie en rien de faire des généralités défaitistes de la sorte
Il y a des mauvais éléments dans tous les jobs et l'informatique s'est incroyablement développée ces 20 denières années
Autrement dit, il y a beaucoup plus d'informaticiens qu'avant, et donc de managers aussi, et proportionnellement, plus de mauvais managers aussi (idem pour les informaticiens, par ailleurs. Pas de jaloux)
Il ne faut pas faire d'une minorité visible une généralité.
Les métiers de l'informatique se sont énormément développés.
Il est parfaitement possible d'exercer un métier de l'informatique sans jamais écrire une seule ligne de code (SEO, graphiste, web analyste, community manager, etc.).
Je trouve très arrogant de croire que la seule façon de faire de l'info est décrire du code.
Un admin réseau n'a rien à voir avec un développeur Java et il n'est pas moins informaticien pour autant.
Ensuite, je trouve extrêmement bien que l'informatique se démocratise et ne soit plus réservée à une "caste" de privilégiés et souvent "d"incompris"
Au contraire, je trouve très bien que les gens s’intéressent enfin à ce que l'on fait
Et oui, on doit rendre des comptes comme tout le monde.
C'est fini le temps des développeurs sur leur tour d'ivoire
Il est temps de s'ouvrir au monde et savoir communiquer
Et c'est à nous, informaticiens, de nous adapter aux autres et d'apprendre à vulgariser notre façon de communiquer.
Ca, c'est du mauvais management.
Un manager n'est pas là pour te dire comment faire ton job mais au contraire, t'aider à mieux le faire et te fournissant tout l'environnement approprié.
Par contre, comme tu le dis, l'informatique est devenu ultra important et il fauit rendre des comptes.
Donc, oui, en échange, il faut donner de la visibilité sur ce que l'on fait.
Rendre des comptes régulièrement (tous les 2 jours à 1x/semaine) à ton manager en lui disant "voilà ce que j'ai fait depuis la dernière fois, ce je suis en train de faire, ce qu'il me reste à faire et combien de temps cela me prendra" ou encore "voilà quelles difficultés j'ai rencontrés et comment je les ai résolus et comment faire pour que cela ne se reproduise plus pour moi et mes camarades", je trouve ça très bien
Ca sort le développeur du guidon justement
Ca l'aide à prendre du recul sur son travail
De même, c'est fini le temps des développeurs seuls dans leur coin
Aujourd'hui, les projets sont de tailles et on travaille en équipe et ça implique de communiquer et de faire des points de synchro.
Là, pour le coup, je suis d'accord
Par contre, c'est typiquement franco-français et les choses changent
Certes, doucement, mais ça évolue dans le bon sens.
Agile ou ne pas être
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 !
Faute !
"au point ou"
Etes-vous d’accord avec le fait que le terme Agile a été détourné par les entreprises ? OUI
POUR CAR AGILE C'EST UN CANCER
IL PERD BEAUCOUPS DE TEMPS
Je suppose que tu as cette opinion suite à un retour d’expérience malheureux.
POUR CAR AGILE C'EST UN CANCER
IL PERD BEAUCOUPS DE TEMPS
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
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.
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.
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.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 )
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.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
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.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 )
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.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
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).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
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.
En ajout à ce qui a pu être dit :
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.
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
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...
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.
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?
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.
@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...
Le DevOps n'est pas de la gestion de projet.
Répondre avec citation
Partager