Le métier de développeur ne se cantonne pas à "pisser du code". La conception et la qualité, mentionnée par Saverok, font aussi parti du job. En quoi Est-ce de la gestion de projet?Envoyé par zecreator
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
Le métier de développeur ne se cantonne pas à "pisser du code". La conception et la qualité, mentionnée par Saverok, font aussi parti du job. En quoi Est-ce de la gestion de projet?
Ca me rappelle un client connu ça. Ca code, ça code, ça code avec des délais serrés, des méthodes de travail d'un autre temps, fondé sur "fait des heures et pisse du code, on gagne à mort en productivité; vas y ! vite on a des délais serrés; vas y petit faut que tu nous résolves tout t'es un champion". Ca marche du tonnerre effectivement... Trêves de blagounettes, ne me dis pas que tu ne te rends pas compte de l'utilité d'un planning poker et d'une modeste réunion de 10 minutes le matin pour coordonner l'ensemble des tâches ? J'aurais limite l'impression d'un troll là.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.
En fait, tu résumes ton métier à te mettre derrière un IDE et écrire des lignes de code en fonction des spécifications qu'on t'a donné. Personnellement j'appelle ça un ouvrier développeur. Je n'ai pas du tout la même vision que toi du mot "ingénieur en développement" qui nécessite des connaissances en abstraction, en conception, en modélisation, en chiffrage et en complexité de ce qui va être développé. Ces 5 éléments n'ont rien à voir avec la gestion de projet et sont du ressort d'un "bon" développeur. Dans les arguments déjà développés, beaucoup évoquait les problèmes de management ou de démocratisation de la profession. Personnellement, dans toutes les entreprises où j'ai pu mettre les pieds, ce sont avant tout des individus avec les qualités que je cite qui sont recherchés. Ecrire du code (dans l'informatique de gestion par exemple) n'est pas une tâche qui nécessite un bac+2 ou une embauche de cadre. Le statut de cadre de beaucoup d'informaticiens vient du fait que le développement n'est pas la seule corde à leur arc.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...
"Dans une hiérarchie, tout employé a tendance à s'élever à son niveau maximum d'incompétence" - Principe de Peter
"Il n’y a pas de langage informatique dans lequel vous ne puissiez pas écrire de mauvais programmes" - Dérivation de Murphy
Un scientifique doit douter de tout et connaître l'échec : http://fr.wikipedia.org/wiki/Corr%C3%A9lation_illusoire
Tr0n
Loin de moi l'idée de troller. J'argumente mon accord avec Erik Meijer : Arrêtons d'abrutir les développeurs avec des réunions quotidiennes et rendez-lui son vrai métier : coder !
Effectivement, le métier de développeur aujourd'hui nécessite d'avoir plusieurs casquettes (ça va je suis assez à jour sur le sujet). Ce qui me gêne c'est surtout que la philosophie Agile n'est vraiment applicable que dans le cas de projet massif. Dans mon cas, je ne vois pas comment je pourrais l'appliquer à du dev e-learning, dans une équipe qui compte 3 personnes et où je suis le SEUL développeur, voire la seule compétence technique.
Donc Agile, ça doit bien fonctionner en SII avec des équipes de 10 personnes sur des projets de type SIRH, mais sur une e-learning Flash, nous imposer de mettre en pratique Agile, je me marre.
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
En effet, mettre en place du Scrum dans une structure non adapté comme tu le décris n'a pas forcement de sens.
Scrum est adapté essentiellement à des équipes de 5 à 9 (au delà, faut faire plusieurs équipe) orienté très technique même s'il peux y avoir des équipiers d'autres disciplines et travaillant sur des projets plutôt long comprenant de nombreuses fonctionnalité.
Mais Attention de ne pas limité l'Agilité à seulement la méthode Scrum.
Il y a bien d'autre méthode et je pense en particulier à la méthode Kanban, moins cantonné au secteur du développement logiciel, c'est une méthode bien adapté sur les petits/micro projets où des personnes de compétences différentes (spécialistes métier, développeurs, graphistes, testeurs, administrateurs système, ...) peuvent être amené à intervenir.
Je crois déceler en filigrane de tes interventions que tu identifies l'agilité à un gros process fumeux et rigide imposée par la hiérarchie.
Mais non, le manifeste agile à l'origine c'est quasi que des codeurs issus de la base. Ils ont identifié de manière très pragmatique des problèmes récurrents dans les projets informatiques et ont proposé des principes et des pratiques pour les résoudre (au passage, les réunions quotidiennes ne sont pas dans le manifeste agile). Si tu n'as pas ces problèmes dans ton job et que ta façon de faire actuelle est pleinement satisfaisante, tu as le droit d'oublier complètement l'agilité.
La où la mauvaise foi commence par contre, c'est quand Monsieur Meijer 1/ fait l'amalgame entre une approche et les gens qui essaient de l'appliquer bêtement sans que le contexte s'y prête et 2/ par ignorance ou par biais argumentatif, fait l'amalgame entre une approche (Agile) et une méthodologie dérivée (Scrum) qui bien sûr a encore moins de chances de convenir dans toutes les situations.
Tout à fait d'accord avec toi ! Sauf qu'il faut se rappeler d'un truc : les daily meetings sont une des déviances de l'Agile très souvent dénoncée. A l'origine, il s'agit d'une réunion informelle à la machine à café, où participe qui veut, et où l'on parle de tout et n'importe quoi ; cela renforce la cohésion d'équipe et permet d'échanger sur divers points "hors du cadre du boulot" (genre tu n'as pas pu voir un collègue, et tu lui poses ta question à ce moment avant qu'il ne soit repris par son travail). Malheureusement, des chefs de projet / pseudo-scrum master l'ont transformé en réunion quotidienne à part entière, devenant ainsi une charge inutile et gênante pour le développeur.
Premier pilier du manifeste Agile : Les individus et leurs interactions plus que les processus et les outils. Donc prend ce qui t'arrange dans l'Agile et adapte le à ton équipe (adaptation au changement / situations, l'un des principaux but de l'Agile).Effectivement, le métier de développeur aujourd'hui nécessite d'avoir plusieurs casquettes (ça va je suis assez à jour sur le sujet). Ce qui me gêne c'est surtout que la philosophie Agile n'est vraiment applicable que dans le cas de projet massif. Dans mon cas, je ne vois pas comment je pourrais l'appliquer à du dev e-learning, dans une équipe qui compte 3 personnes et où je suis le SEUL développeur, voire la seule compétence technique.
Je ne dirais pas que c'est une "déviance de l'Agile", tout dépend l'utilisation qu'on en fait
Je ne sais pas d'où vient cette histoire de machine à café, dans Scrum c'est un rituel au contraire assez formel qui ne doit pas dépasser 15 minutes. Mais je suis d'accord que c'est une des pratiques les plus mal comprises et les plus souvent utilisées à mauvais escient, donc à ne pas faire sauf si on sait exactement ce qu'on en attend (ce qui devrait être valable pour tout d'ailleurs).
http://institut-agile.fr/daily.html
La seule fois de mon expérience où ça a été utile (en formalisé bien sûr), c'est quand l'équipe était divisée en petits groupes (3-4 personnes) s'occupant chacune d'une fonctionnalité du projet et que ces réunions s'articulaient pour faire un Speed Boat (ce qui rejoint ta dernière phrase). Sinon, toutes les erreurs citées dans ton lien se sont produites.Je ne dirais pas que c'est une "déviance de l'Agile", tout dépend l'utilisation qu'on en fait
Ca vient du tout début de l'Agile, avant les formalisations en Scrum, XP ... L'idée sous-jacente est queJe ne sais pas d'où vient cette histoire de machine à café, dans Scrum c'est un rituel au contraire assez formel qui ne doit pas dépasser 15 minutes.tousla majorité des développeurs buvant du café, ils se réunissent naturellement à la machine et discutent de façon conviviale, donc autant en profiter.
Il ne faut pas prendre l'expression "machine à café" au pied de la lettre.
L'idée est de sortir du cadre formel d'une réunion et de mettre tout le monde au même niveau.
Le but est de favoriser l'expression de tous, y compris et surtout vis à vis des plus introvertis.
La machine à café est particulièrement bien adaptée à l'univers des bureaux mais rien n'empêche d'avoir des variantes.
Dans ma société, on a une salle détente avec un babyfoot qu'on peut réserver pour faire des réunions informelles et ça fonctionne plutôt pas mal.
Agile guérit le cancer
Comme d’habitude qui a compris ce qu’était l’Agilité ?
En tout cas ici il y a une belle inversion des concepts !
Les méthodes Agile mettent le besoin CLIENT au cœur du développement, PAS LES CODEURS.
Et d’autre part citer des personnes qui ont critiqué l’Agile sans dire pourquoi, est source de confusion.
Effectivement, certains critiquent Scrum avec raison, d’autres tort. Prenons l’exemple du TDD. Pour rappel, le concept vient de l’Extrem programming et s’applique aussi bien à un cycle en cascade qu’à un cycle itératif. Si ce concept est profitable, cette implémentation du Test First est critiquée dans sa première version car elle est de trop bas niveau. Les développeurs préfèrent créer leurs bibliothèques de tests unitaires de non régression après le codage des fonctions et n’en voient pas la valeur ajoutée. C’est pourquoi le BDD qui s’intéresse à créer des tests à un niveau classes d’objets ou à un niveau fonctionnel réduit est venu après. Ainsi que l’ATDD qui nécessite des environnements proches de celui des utilisateurs et un niveau de développement du code du produit plus avancé.
Qu’est-ce que le Test First ?
C’est penser à ce que doit faire une fonction, une classe, un produit et de coder jusqu’à ce que l’objectif soit atteint. Le bénéfice est double : Avoir des tests de régression et coder le nécessaire et suffisant.
Il ne s’agit pas de modéliser des échecs !, et cela s’applique à tous les cycles de développement.
Non, Agile n’a pas été créé pour que le développement soit conduit par les ingénieurs !
Le Scrum meeting est une méthode de management d’équipe qui permet à chacun d’échanger sur les activités, de mettre en lumière les problèmes rencontrés et de profiter de plusieurs cerveaux pour les régler. Chaque membre de l’équipe est censé dire ce qu’il a fait, ses problèmes et ce qu’il va faire. Cela dure 20 minutes.
Laisser les codeurs développer comme ils le souhaitent me semble être antagoniste de l’Agile. Le codeur doit développer et tester de façon à ce que les exigences du client soit satisfaites. Cela consiste à réfléchir sur ce qui doit être fait, sur comment le tester pour valiser de codage, sur comment l’intégrer dans une chaine d’intégration continue, sur combien cela va couter.
Si le développeur ne souhaite que coder, qu’il change d’équipe et aille faire du cycle en V !
Agile n’a pas été créé pour que les ingénieurs, c’est-à-dire les codeurs, décident de la conduite du développement, mais pour tout le monde se comprenne, et comprenne le vrai besoin.
De plus, les échanges de ces petites réunions permettent de voir l’avancement des tâches, si elles sont bien découpées en durées maximum de 2/3 jours. Cela crée un sentiment d’avancement en commun. Cependant dans les organisations ou il faut livrer le produit, puis l’intégrer dans un SI et le déployer, ce serait une erreur de penser que les membres de l’équipe Agile sont seuls !
Merci de penser à ceux qui ont allouer un budget, monté une équipe Agile, et déterminé un backlog produit, c’est-à-dire les exigences à développer. Il est vrai que l’Agile ne concerne souvent que la partie développement, la partie définition du besoin et stratégie de développement et de test étant réalisée en amont par d’autres personnes, ce qui fait que les membres de l’équipe Agile croient être les acteurs principaux du projet.
Agile s’est-il détourné du droit chemin ?
Le constat est que certains projets sont dit Agile alors qu’il n’en est rien. Oui c’est vrai que certains projets parlent Agile au lieu de faire de l’Agile. Parce que certains veulent faire de l’Agile là où cela n’a pas lieu d’être.
Une contrainte de l’Agile est qu’il faut bien éliciter les exigences avec le client ou le responsable du produit, les prioriser en fonction de leur criticité et de leur coût, puis de les décliner en tâches dans les itérations. Mais certaines habitudes ont la vie dure et en fait de tâches il n’y a que des fonctions de haut niveau à développer qui n’ont pas été pensées ni donc chiffrées et dont on ne voit pas le bout de la fin. Il est aisé de mettre la faute sur les daily scrum qui empêchent le codeur d’avancer ou les SSII !
La force de l’Agile est que cela doit créer une équipe motivée, de taille réduite et de montrer un avancement satisfaisant pour tout le monde. Quand on a une bonne équipe tout va bien et Agile doit le permettre.
Que dire également des projets qui pensent qu’il n’a pas de documentation ! Non Agile dit que la documentation doit être adaptée au besoin. Ce que Agile permet c’est de fluidifier la communication et d’éviter que certains écrivent trop de documentation inutile car ils sont trop loin du projet et du besoin du client.
Une autres des contraintes du développement Agile est que les fonctions qui ne peuvent pas être développées par incrément soient développées en amont, comme les composants liés à l’architecture du produit, ou dans d’autres projet sous peine de décrédibiliser les méthodes Agile
Le problème est que les gens parlent souvent sans savoir, sans être formés, ou bien formés par des d’aucun qui ont surfé sur la mode des scrum master sans en avoir les compétences. Rendez-vous compte, certains pensent que les tests unitaires des développeurs et l’utilisation d’un outil de qualimétrie de code sont suffisants en Agile !
Heureusement certains dont L’ISTQB qui représente les bonnes pratiques d’assurance qualité logicielle dans le monde, ou Sogeti avec TMAP pour Scrum ou TMAP HD, ont analysé en profondeur les problèmatiques de l’Agilité et présenté des solutions.
Le syllabus ISTQB Testeur Agile est publiquement mis à disposition sur ce lien. Lisez-le avant de vous lancer dans le domaine. Vous y apprendrez également que le modèle en cascade a été remplacé il y a longtemps par le modèle en V !
Bien à vous,
Attention, modéliser des échecs est utile dans certains cas : paramètres erronés passés à un web service, fichier vide ... il faut juste que ce soit réaliste, donc pas inutile.
Je suis un fervent opposant au scrum meeting : dire ce que chacun fait chaque jour dans une réunion formalisée n'a pas vraiment d'intérêt, car chacun le dit naturellement en discutant. De plus, ce genre de réunion peut "bloquer" les plus timides et même donner l'impression que l'on cherche le mouton noir ; à l'inverse, les "grandes gueules" en profitent pour se faire mousser, ce qui dégrade encore plus la cohésion d'équipe.Le Scrum meeting est une méthode de management d’équipe qui permet à chacun d’échanger sur les activités, de mettre en lumière les problèmes rencontrés et de profiter de plusieurs cerveaux pour les régler. Chaque membre de l’équipe est censé dire ce qu’il a fait, ses problèmes et ce qu’il va faire. Cela dure 20 minutes.
...
De plus, les échanges de ces petites réunions permettent de voir l’avancement des tâches, si elles sont bien découpées en durées maximum de 2/3 jours. Cela crée un sentiment d’avancement en commun.
De plus, pour voir l'avancement des tâches, il y a les dashboards et les radiateurs (c'est encore mieux si tout est dans un outil avec des reporting en temps réel, genre TFS).
EDIT : à la place du scrum meeting, je préfère effectuer un Speed Boat, qui permet de formaliser les problèmes (ancres) et les aides / succès (voiles), et qui est facile à mettre en place dans les petites équipes (3 - 5 personnes). Ca n'a pas les travers du scrrum meeting et c'est nettement plus efficace.
C'est pour cela que le pair-programming est fortement recommandé : il y a forcément réflexion et consensus entre les deux développeurs. De plus, le chiffrage des users stories se fait à plusieurs aussi pour penser à ce genre de choses.Laisser les codeurs développer comme ils le souhaitent me semble être antagoniste de l’Agile. Le codeur doit développer et tester de façon à ce que les exigences du client soit satisfaites. Cela consiste à réfléchir sur ce qui doit être fait, sur comment le tester pour valiser de codage, sur comment l’intégrer dans une chaine d’intégration continue, sur combien cela va couter.
Tu as tout à fait raison. J'en profite pour étendre un peu le sujet, car à mon sens, ta remarque illustre le rôle du product owner (souvent absent des équipes, remplacé par le scrum master qui ne fait pas son boulot) et de la partie devops pour l'intégration dans le SI.Agile n’a pas été créé pour que les ingénieurs, c’est-à-dire les codeurs, décident de la conduite du développement, mais pour tout le monde se comprenne, et comprenne le vrai besoin.
Cependant dans les organisations ou il faut livrer le produit, puis l’intégrer dans un SI et le déployer, ce serait une erreur de penser que les membres de l’équipe Agile sont seuls !
Merci de penser à ceux qui ont allouer un budget, monté une équipe Agile, et déterminé un backlog produit, c’est-à-dire les exigences à développer. Il est vrai que l’Agile ne concerne souvent que la partie développement, la partie définition du besoin et stratégie de développement et de test étant réalisée en amont par d’autres personnes, ce qui fait que les membres de l’équipe Agile croient être les acteurs principaux du projet.
C'est vrai qu'il y a souvent des coqs qui prennent la parole dans les réunions et donc les stand up meeting...
C'est le monde à l'envers. Certes le besoin client doit être compris pour établir une stratégie de développement. Mais le coeur du développement reste le métier des développeurs, pas du client. Le problème que j'ai avec Agile, c'est que chacun à sa définition propre et sa méthode de mise en place. Agile c'est le "truc" qui fait "pro" auprès des clients, qu'il faut absolument pratiquer et maîtrise (sinon on est considéré comme un codeur has-been), alors que tout bon développeur serait capable de coder sans...
Dans les écoles d'ingé, on ne sert plus que ça. Agile, SCRUM... Bref, à la sortie, c'est plus des développeurs, mais des moitiés de développeurs qui ne développeront quasiment rien sans avoir fait X validation avant, et qui ne seront pas s'adapter à d'autres méthodes ("ben, c'est pas ce qu'on m'a apprit..."). Je le constate avec des stagiaires en ingé aujourd'hui, qui sont incapables de coder sur d'autres outils que ceux sur lesquels ils ont été formés (et surtout qui ne veulent pas apprendre autrechose, parce que c'est pas dans le profil attendu par les entreprises...).
Tain, elle est où l'époque où 1 mec seul dans son garage faisait TOUT seul un logiciel, moins buggé à la livraison qu'une équipe de 10 personnes aujourd'hui ?
Pas vraiment une évolution pour le métier tout ça...
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
"C'était mieux avant".... Désolant ! Regarde autour de toi, il y a du logiciel partout !! Si on en était encore à voir l'informatique et le logiciel comme un geek barbu dans le fond de son garage on en serais pas là...
Il n'y a que ceux qui ont connu la grande époque de l'informatique qui peuvent comprendre. Aujourd'hui, on code à la "vas-vite", comme des porcs pour être dans les délais. On optimise plus rien, voire on pique un bout de code à droite pour le coller à gauche avec un minimum de vérification (parce qu'on a pas que ça a faire). On passe plus de temps à débugger un malheureux code (et surtout à le comprendre) qu'à vraiment coder. On utilise des frameworks douteux, dont on ne contrôle pas le fonctionnement. je veux bien croire qu'il faut être plusieurs pour arriver à faire fonctionner du code dans un tel environnement.
Bref, la nouvelle génération de développeurs n'ont absolument rien à voir avec les "vrais" développeurs, qui sont surtout des passionnés du code et qui refusent de s'enfermer dans des méthodes mis en place par mesure de performance et de profits, et qui les freinent dans leur évolution. Après, chacun voit son métier comme il veut. Soit c'est juste un job, soit c'est une passion. Moi, je suis dans le deuxième cas.
Ceux qui veulent voir des vrais développeurs, je les encourage à visiter les rassemblements de demo maker, juste pour constater combien la plupart des développeurs dit "pro" et qui "bandent en équipe" devant les méthodes du type "Agile', dans des belles grosses SSII, sont aujourd'hui à la ramasse techniquement.
Et je suis fier d'être un barbu et d'avoir connu cette époque formidable de l'Amstrad, de l'Atari ST et de l'Amiga, qui nous a donné des développeurs formidables comme Eric CHACHI, Eric HERBULOT ou encore Jordan MECHNER, qui n'auraient pas pondu des oeuvres comme Prince of Persia ou Another World s'ils avaient les méthodes de dev d'aujourd'hui.
Merci à eux en passant...
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
Je trouve la caricature un peu grosse voir totalement grasse.
Les gens n'étaient pas plus passionnés avant qu'aujourd'hui.
Le truc, c'est qu'avant, l'informatique n'était franchement pas accessible donc pratiqué par très peu de monde.
Depuis, l'informatique s'est démocratisé.
Il y a certainement bien plus de passionnés qu'avant mais proportionnellement, c'est moindre.
Les routines "c'était mieux avant" sont tjrs à relativiser dans le contexte.
De même, avant, on ne se passionnait pas pour l'optimisation ou le debug.
Pour avoir pas mal échangé avec des vieux de la vieilles, la plupart avouent que c'était franchement pénible.
"A l'époque", le hardware était tellement limité que c'était une obligation.
C'est sûr qu'à l'époque où la capacité des disques durs se comptait en Mo et la RAM en Ko (quand il y en avait), on ne pouvait pas se permettre de s'étaler.
Et je ne parle même pas des CPU et du boot sur disquettes...
Pour finir, pour ce qui est de l'utilisation des frameworks, on en utilisait pas ou très peu à l'époque pour la simple et unique raison qu'ils se diffusaient très peu.
Soit c'était avant Internet ou aux prémisses avec les bonnes vieilles connexions 56K (si n'est 36k) et ce grésillement qui me donnent encore des boutons aujourd'hui.
Avec tout ça, va falloir m'expliquer en quoi c'était tellement mieux avant ?
L'idée du daily meeting n'est pas de se mettre dans un cadre informel. C'est de faire un point quotidien pour situer la progression de l'équipe vis-à-vis du but à atteindre dans l'itération, de remonter les problèmes rencontrés et de se répartir les tâches pour la journée.
Je ne suis pas sûr qu'un cadre informel favorise l'expression de tous, au contraire (la sociologie des groupes étant ce qu'elle est). Un cadre plus institutionnel et ritualisé permet de s'assurer que chacun ait un temps de parole équitable.
Sans vouloir faire mon "gros lourd", je dirais qu'avant on laissait la liberté au développeur d'utiliser les méthodes et technologies qu'il souhait. On ne lui imposait que des délais. Il y avait une vraie confiance et une relation "humain" à "humain". Le contexte était différent car la plupart des sociétés de développement informatique étaient tenues par des informaticiens qui avaient une vraie idée du métier.
C'est vrai, et on avait intérêt à être passionné, parce que pour débugger du code C, y avait pas d'outil. C'était un boulot de tronche bien vénère parfois ! En assembleur, c'était pire... Aujourd'hui on possède tous les outils pour vérifier/débugger, on a plus à faire ce boulot. D'un coté c'est bien, d'un autre le métier de développeur a perdu tout son jus. Il n'a plus à comprendre pourquoi il y a une erreur. L'outil le fait pour lui. Rien ne l'empêchera de faire la même sur un prochain projet.
Aujourd'hui, la rentabilité est devenue une priorité. Faut coder vite à moindre coût. On re-pompe du code que l'on adapte. Et pis si la release bug, c'est pas grave. On shootera des mises à jour quotidiennes s'il le faut... De toutes façons, l'utilisateur fini par être habitué.
Pour en revenir à la philosophie Agile, ce qui me gène c'est qu'un développeur n'ayant jamais pratiqué passe aujourd'hui pour un développeur "bas de gamme". Alors que si on le laissait utiliser ses propres méthodes il pourrait prouver qu'il est tout aussi capable d'être efficace qu'un autre. Aujourd'hui, ne pas avoir pratiqué Agile ne devrait pas être un frein à un recrutement.
Agile est une philosophie organisationnelle, pas une compétence. Faudrait que l'on explique cela aux recruteurs IT qui semblent voir en Agile un "tout".
"La révolution informatique fait gagner un temps fou aux hommes, mais ils le passent avec leur ordinateur !"
En faite, si on comprend bien l’esprit Agile, on reprendrait tout à fait ton argument: pour que l'agilité marche dans une équipe, il faut avant tout qu'elle soit acceptée (voir demandée) par les équipes elles-même.
Imposer l'Agilité à une équipe qui est réticente, qui y va à reculons est la meilleur solution pour que cela ne marche pas.
En Agilité, on demande à l'équipe de s'auto-organiser, de s'auto-gérer: comment voulez vous qu'ils y arrivent s'ils ne sont pas prêt à le faire?
Oui, je suis aussi d'accord avec toi, un grand nombre de recruteur ou commerciaux veulent de l'agilité partout, comme un mot magique, sans savoir ce que cela implique.
Pour vérifier si un développeur a la "compétence" agile, c'est très simple, une seul question suffit: "Voulez vous travailler dans une équipe autonome sans manager?"
La question est valable aussi pour l'entreprise: "Voulez vous que vos équipes soit autonome sans manager?"
Mais cette question, malheureusement, beaucoup ne sont pas prêt à ce la poser et encore moins à changer leur organisation en conséquence.
Ce que l'on vit dans notre entreprise depuis presque 3 ans, c'est que l'agilité nous a plus couté que rapporté du fait de multiples derives :
a/ les equipes auto gerées se generent aussi d'elles memes du boulot (l'agilité se traduit souvent par un refus de tout ce qui ne provient pas de l'equipe ! c'est plutot de la rigidité).
b/ lorsqu'un client exprime un besoin (ex: technique), l'equipe de dev en fait souvent plus (et donc deroule des heures pas forcement vendues). Un peu comme si c'etait un test technique qu'il fallait relever. resultat vecu : on nous demande d'implementer une interface selon 2 protocoles => au final 5 protocoles techniques sont implementés (derive des devs qui se sont faits plaisirs). Le client est content certes car on lui en donne plus que prevu; par contre nous on bouffe la culotte en consommant des heures non vendues.
c/ turn over donc generalement on se recupere des projets qui n'interessent plus personne (et pour lesquels de toutes façons les devs sont deja partis ailleurs); et l'on decouvre l'immensité du chantier. Le nouveau/interessant c'est plutot les autres projets.
D'ailleurs souvent passé la mise en prod le suivi/maintenance logiciel n'interesse plus ("du sale boulot") du coup c'est une catastrophe en maintenance.
De toutes nos equipes Agile, les prestas restent le temps de se former/jouer avec les technos (1 an ou 2) et nous laisse la merde en partant.
Personnellement je trouve ca vraiment usant pour ceux qui doivent passer derriere (et ca n'arrete pas).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager