Peut-être que parler de quantité plutôt que de périmètre serait plus clair (le compromis avec qualité est naturel).
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 :
Peut-être que parler de quantité plutôt que de périmètre serait plus clair (le compromis avec qualité est naturel).
Site perso
Recommandations pour débattre sainement
Références récurrentes :
The Cambridge Handbook of Expertise and Expert Performance
L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})
Je n'ai pas lu l'article d'origine, mais ne vaudrait-il pas mieux dire "dont le concept Agile a été détourné du droit chemin" ?Envoyé par Michael Guilloux
Ce que les SSII soi-disant "agiles" ne comprennent pas (et ne veulent pas comprendre) c'est que l'agilité ne se limite pas à l'équipe de développement. Toute la structure doit devenir agile elle aussi et répondre aux besoins de l'équipe de dev. Tant que les commerciaux et autres directeurs de projets continueront à s'interposer entre les devs et les clients (imposer des dead lines, des fonctionnalités inutiles mais couteuses, ou rien que faire l'intermédiaire entre les 2), ça ne pourra pas marcher !
Il faut aussi accepter de payer plus cher une équipe agile car elle a plus de responsabilités, et il faut des développeurs aguerris (pas des stagiaires ou des débutants facturés comme des experts) car le maillon le plus faible de la chaine peut mettre en péril l'équipe.
Donc +1 avec ce qui a été dit plus haut, le problème ce n'est pas la méthodologie mais les équipes, et j'ajouterai la rigidité des entreprises elles-mêmes...
En un mot, pareil.
Avec un peu plus de détails, je plussoie au fait qu'une méthode, au même titre qu'un outil, n'est ni bonne ni mauvaise. C'est ceux qui les appliquent qui font les bons ou les mauvais choix, ceux qui en font la pub qui donnent les bons ou les mauvais tuyaux, etc. C'est facile de mettre les échecs des uns et des autres sur le dos d'une méthode, mais n'est-ce pas la plus grande preuve d'irresponsabilité ?
On a tenté d'appliquer telle méthode et ça a foiré. Bon. Maintenant, il y a ceux qui vont chercher ce qui a foiré et tenter de le corriger (changer de méthode, l'appliquer autrement, changer des membres de l'équipe, l'organiser autrement, etc.), et ceux qui vont passer leur temps à se plaindre et à chercher des coupables (et si toute l'équipe est comme ça, ce sera forcément la méthode la coupable, ce qui est stupide car on ne peut pas lui faire "payer", or c'est bien là le but de la responsabilité).
Site perso
Recommandations pour débattre sainement
Références récurrentes :
The Cambridge Handbook of Expertise and Expert Performance
L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})
Agile a fait des promesses impressionnantes, comme un développement conduit par les ingénieurs, afin que les décisions importantes ne soient pas prises sans les développeurs. Mais selon le CTO de June, dans la réalité, Agile et Waterfall partagent la même idée du développement conduit par l’entreprise. Les décisions techniques sont pilotées par la direction et imposées aux développeurs. « Le résultat final est le même Waterfall. Seul le nom a changé », explique-t-il. Il ajoute encore qu’Agile est plus toxique que les méthodes en cascade, car il rend le développeur beaucoup plus responsable du résultat sans lui donner l’autorité qui va avec sa responsabilité.En effet, si les décisions techniques sont pilotées par la direction, on corrompe ce principe de l'Agilité.
L'auto-organisation est un élément très important dans l'agilité.
Comment peut on alors dire "Agile, ça marche pas, c'est trop nul", si on ne respecte déjà pas l'ensemble de ses règles.
Comme si un parachutiste disait que son parachute ne marche pas alors qu'il n'a pas tiré sur la poignée: logique, on s'écrase
Et on peux pas dire que les 'règles' soient nombreuses et compliquées à comprendre : 12 principes à respecter.
Un équipe qui a vraiment compris le sens de l'agilité, mettra Scrum (ou autre méthode parfaite pour commencer) au placard et fera pleinement de l’amélioration continu de ses pratiques avec pour seule guide ces 12 principes.
Par contre, là où je suis plutôt d'accord, c'est que l'Agilité deviens tellement un effet de mode, que forcement on retrouve dans plein d'entreprise de très mauvaise mise en place et de mauvais consultant 'expert' catch-agile, ....
Mais voyez qui on retrouve sur les conférences agiles de France: la question de la légitimité des experts que l'on ne voit jamais se pose.
Ben oui. C'est toujours pareil : l'équipe qui a gagné la coupe du monde jouait en 4.2.3.1, donc plein d'équipes amateurs se sont mises à jouer en 4.2.3.1. Avec des résultats moins impressionnants. Est-ce surprenant?
Enfin, les crétins qui lisent le petit manuel et ensuite se proclament empereur du monde et emmènent leur organisation à sa perte, c'est vieux comme le monde.
Après, éviter leurs travers ne suffit pas à garantir le succès d'un projet. Avoir des gens compétents et humbles ne suffit pas toujours à assurer le succès d'un projet. Avoir un sponsor réaliste qui ne demande pas de refaire Amazon, en mieux, en 4 jours(mon père a reçu une offre de ce genre, et les 4 jours étaient payés 999€), c'est bien, mais ça ne suffit pas toujours à réussir le projet.
Notre putain de métier est difficile. Ce n'est pas le seul. On peut aligner des superstars du football et ne pas gagner la ligue des champions pendant des décennies. Comme bien d'autres, notre métier est difficile. Certaines théories peuvent être des outils utiles pour se planter moins souvent. Mais ça ne sont jamais que des outils. Dès lors qu'ils sont élevés au rang de religion, ils deviennent toxiques. Ça n'a rien de spécifique à l'agile.
Ma conclusion, c'est que les équipe compétentes, elles, sont plus fortes avec agile que sans. Les autres seront toujours des catastrophes, et ça c'est vrai depuis que le monde est monde.
J'en pense que tout ceci sont des effets de modes et que chaque développeur qui gère sa carrière et sa notoriété sur Twitter ou son blog se doit de faire parler de lui tout les x temps.
Prôner l'agilité était déjà un effet de mode à l'époque. C'était très vendeur. Relativiser sur l'agilité est devenu à la mode aujourd'hui.
Des articles qui remettent en cause les systèmes en place on en voit tout le temps en IT. C'est un des principes même de l'IT... comme il s'agit d’ingénierie, pas de science, n'importe qui peut remettre en cause tout ce qui a été mit en place par d'autres a tout moment et autant sur des sujets très techniques que sur des sujets divers tel que la méthodologies. Il est facile de dire, après coup, que tel technique n'est pas bonne. C'est comme ça qu'on fait parler de soit et qu'on crée de nouvelles modes. Et quand ça marche, que son idée fait le buzz et bien c'est aussi sa carrière qui fait le buzz.
Or ce n'est pas comme ça qu'il faut le voir. Toutes techniques, méthodologies peut toujours être remise en cause en fonction du contexte. Si aujourd'hui certain blogueur remettent en cause l'agilité c'est parce que effectivement dans certaines sociétés, équipes elle est mal utilisée. Bref on peut aujourd'hui s'amuser a remettre en cause les fondements même du développement si on veut s'amuser.
Bonjour
Moi, je me demande pourquoi dans l'informatique on veut "toujours" donner la méthode de travail utilisée par l'équipe.
quand je fais venir un artisan, des artisans chez moi pour intervenir, je ne leur demande pas si ils sont agiles, ou waterfall, ou merise, ou autre...
Je veux juste que le travail soit bien fait dans des couts raisonnables par rapport à l'intervention à réaliser.
Je ne comprends pas pourquoi ce besoin de toujours tout formaliser, toujours avec une méthode ou autre...
Ne peut-on simplement se baser et se concentrer sur la réalisation logicielle plutôt que d'introduire des méthodes qui, peuvent fonctionner, mais au final, la meilleure
organisation et la plus facilement acceptée, c'est celle que tout le monde choisie.
Perso (ok, je suis peut-etre un peu rebel et metalleuh...), ça me saoule de devoir faire autre chose que de la conception et du développement (test, etc..) quand je dois
livrer un logiciel...
Mon expérience n'est pas absolue, donc, difficile de dire que ce qui marche / a marché pour moi doit marcher pour tous les autres... mais je me souviens simplement
que sur des projets de 10 développeurs, une réunion de 1h par semaine pour valider l'avancement était largement suffisant... ensuite, le CP passait de temps en temps
voir chaque développeur pour "affiner" les choses, mais pas besoin d'une lourdeur d'un process bien "théorisé"...
Au final, on se rend compte que plus on met d'ordre (organisation, etc...) et plus ça gonfle les vrais développeurs qui sont, pour moi, avant tout des créateurs, des artistes...
Si l'artisan est tout seul il n'y a pas de problème de méthode, juste de tenu de planning.Bonjour
Moi, je me demande pourquoi dans l'informatique on veut "toujours" donner la méthode de travail utilisée par l'équipe.
quand je fais venir un artisan, des artisans chez moi pour intervenir, je ne leur demande pas si ils sont agiles, ou waterfall, ou merise, ou autre...
Je veux juste que le travail soit bien fait dans des couts raisonnables par rapport à l'intervention à réaliser.
Je ne comprends pas pourquoi ce besoin de toujours tout formaliser, toujours avec une méthode ou autre...
Ne peut-on simplement se baser et se concentrer sur la réalisation logicielle plutôt que d'introduire des méthodes qui, peuvent fonctionner, mais au final, la meilleure
organisation et la plus facilement acceptée, c'est celle que tout le monde choisie.
Perso (ok, je suis peut-etre un peu rebel et metalleuh...), ça me saoule de devoir faire autre chose que de la conception et du développement (test, etc..) quand je dois
livrer un logiciel...
Mon expérience n'est pas absolue, donc, difficile de dire que ce qui marche / a marché pour moi doit marcher pour tous les autres... mais je me souviens simplement
que sur des projets de 10 développeurs, une réunion de 1h par semaine pour valider l'avancement était largement suffisant... ensuite, le CP passait de temps en temps
voir chaque développeur pour "affiner" les choses, mais pas besoin d'une lourdeur d'un process bien "théorisé"...
Au final, on se rend compte que plus on met d'ordre (organisation, etc...) et plus ça gonfle les vrais développeurs qui sont, pour moi, avant tout des créateurs, des artistes...
Si il s'inscrit dans des plus gros travaux c'est le maitre d'oeuvre qui utilise une certaine méthode pour que tout le monde se marche pas dessus.
Bref dans tout métier tu as des méthodes, plus ou moins connues du client.
je sais bien que dans tous les métiers il faut des méthode...
je dis juste qu'imposer des méthodes, comme celà a déjà été dit, ne garantit en rien la réussite du projet...
Moi, j'aime bien créer quelque chose de différents à chaque fois en développement, sinon, je prends des patterns tout fait, des MVVM tout fait et mon métier devient
de l'assemblage, de la recopie, etc.. bref, plus il y a de méthodes en place, et moins, en général, il faut réfléchir... et se contenter d'appliquer des méthodes... et ça, mais
je suis peut-être atypique, ça me saoule
Tu te méprends complétement entre contrainte et variable. C'est bien le principe de la négociation et de la planification. Chaque élément à sa part de variabilité : la taille de l'équipe, sa force de travail, sa productivité, etc.
Prenons spécifiquement ton exemple. On ne construit pas "un enfant", ce n'est donc pas le projet. "Faire du enfant" c'est un projet. Est-ce que l'accouchement est l'aboutissement du projet ? Non. Même en admettant qu'il soit confié à quelqu'un d'autres, il y a forte probabilité non négligeable qu'il te revienne dans la tronche au bout de quelques années.. ca marche aussi avec les projets informatiques !
Bref, ce n'est ni butoir, ni figé. Admettons que nous ayons atteint le jalon "Tomber enceinte", la variabilité s'étend de 0 à 398 jours. Bon admettons que ce délai est fixé à 273 jours. Il est toujours possible de finir les peintures, acheter la chambre, coudre soi-même l'édredon après !
Mais on peut négocier ce qu'on fera avant de ce qui sera fait après. Et même renégocier selon l'avancement de chaque élément (puisque tout variable), y compris le terme de la grossesse.
Dans le vie tout se négocie
Premièrement, il convient de prioriser. Ce qui permet justement en cas d'aléa de savoir rapidement ce qui sera sacrifié. Pour cela l'implication de l'ensemble des acteurs est importante pour bien comprendre toutes les contraintes et la variabilité (que ce réglementaire, commercial ou logiciel). Ex : Un salon prévu en septembre pour montrer l'application des nouvelles mesures réglemtnaires applicables en janvier. On prévoit la partie IHM pour septembre et la gestion des données et des règles à minima pour janvier. Les statistiques et la génération des graphiques, etc. pour plus tard.
En sus de ce que je viens d'expliquer j'en reviens à l'article et aux premiers commentaires. L'agilité repose sur une gouvernance mutualiste de l'ensemble des acteurs (ou tout du moins des différentes parties). Et c'est également de ce que j'ai décrit ci-dessus. Or dans les faits cette gouvernance n'est pas partagée. C'est donc de l'eau que tu retires de ton moulin
Je voudrais introduire une autre notion que je n'ai pas évoqué au sujet de la planification : la gestion du risque. Il ne faut pas non plus s'étonner que des projets sont dans le fossé, si les risques ne sont pas pris en compte. L'abolissement de l'effet tunnel est une action de gestion du risque qui illustre parfaitement une cause d'échec des projets.
Je l'ai déjà dit nous jouons avec des paramètres variables. J'ai évoqué uniquement l'amplitude comme attribut de la variabilité mais il y en a d'autres comme la distribution de la probabilité, mais il faut aussi évoqué les coûts, les délais, etc. Ne pas en tenir c'est justement prendre le risque de voir tout simplement son projet échoué.
Concernant purement l'article, les gens vendent des méthodes avec le "nom" mais pas les valeurs. Je pense qu'il est plus intéressant de vendre : la libération des échanges (idées, conversation, travail) entre les acteurs, l'implication de l'ensemble des acteurs et l'amélioration continue.
Je pense que le sujet ici n'est pas l'auto-organisation mais surtout un libre échange d'idées sans intermédiaire pour les temporiser, les modifier ou les bloquer. Mieux l'idée circule plus elle est critiquée et meilleure elle est. En revanche pour cela il faut que l'ensemble des acteurs se sentent impliqués et sur un pied d'égalité. Par exemple qu'un "débutant" ne se sente pas "trop nul" et s'interdise de faire une remarque qui pourrait être extrêment pertinente. Ou à contratio un "expert" qui se sentant blasé sur une question, n'aurait pas le courage d'aller au bout de son idée.En effet, si les décisions techniques sont pilotées par la direction, on corrompe ce principe de l'Agilité.
L'auto-organisation est un élément très important dans l'agilité.
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Délimiter un projet a forcément une part d'arbitraire. Je ne vois pas ce que tu démontres en changeant le périmètre. Le fait qu'on ne peut pas négocier la durée d'une grossesse. Mais étrangement, on imagine pouvoir négocier la productivité des développeurs.Tu te méprends complétement entre contrainte et variable. C'est bien le principe de la négociation et de la planification. Chaque élément à sa part de variabilité : la taille de l'équipe, sa force de travail, sa productivité, etc.
Prenons spécifiquement ton exemple. On ne construit pas "un enfant", ce n'est donc pas le projet. "Faire du enfant" c'est un projet. Est-ce que l'accouchement est l'aboutissement du projet ? Non. Même en admettant qu'il soit confié à quelqu'un d'autres, il y a forte probabilité non négligeable qu'il te revienne dans la tronche au bout de quelques années
Bref, ce n'est ni butoir, ni figé. Admettons que nous ayons atteint le jalon "Tomber enceinte", la variabilité s'étend de 0 à 398 jours. Bon admettons que ce délai est fixé à 273 jours. Il est toujours possible de finir les peintures, acheter la chambre, coudre soi-même l'édredon après !
Mais on peut négocier ce qu'on fera avant de ce qui sera fait après. Et même renégocier selon l'avancement de chaque élément (puisque tout variable), y compris le terme de la grossesse.
A force de travail et productivité constante, il n'y a justement rien à négocier !Dans le vie tout se négocie
Voila revers de la médaille des délais au doigt mouillé décidé "en haut lieu" (c'est à dire par des gens qui n'y comprennent rien) : le cahier des charges - lettre au père Noël. Voila encore un domaine où l'agilité a complètement raté sa cible. Je ne vois pas en quoi moi, développeur, je devrais avoir mon mot à dire concernant le contenu du cahier des charges. Les gens du métier doivent savoir ce dont ils ont besoin. Ils sont là pour ça ! Je ne vois en quoi il y a là quelque chose à négocier. On est entre professionnels, pas sur un champs de course ! Le type qui dit "bon, pour raccourcir le délai, finalement ce bidule, on n'en aura pas besoin", pour moi, il a déjà complètement raté, professionnellement. Pourquoi demander qu'on développe un truc dont il n'a pas besoin ? Un cahier des charges doit toujours contenir le minimum nécessaire pour obtenir une application utilisable. Et là, on a un délai minimal. Ensuite, en se basant sur le retour des utilisateurs et sur un calcul de rentabilité, on peut enrichir. Supprimer l'effet tunnel ne devrait pas être seulement l'affaire de la DSI. Dans la vraie vie, la MOA demande tout ce qui lui passe par la tête. C'est lamentable.
Cette gouvernance mutualiste, tu la voies où, dans le manifeste agile ? Chacun son métier. Or, j'ai souvent l'impression que les développeurs sont les seuls dont on exige du professionnalisme.
En sus de ce que je viens d'expliquer j'en reviens à l'article et aux premiers commentaires. L'agilité repose sur une gouvernance mutualiste de l'ensemble des acteurs (ou tout du moins des différentes parties). Et c'est également de ce que j'ai décrit ci-dessus. Or dans les faits cette gouvernance n'est pas partagée. C'est donc de l'eau que tu retires de ton moulin
Les gens achètent ce qu'ils veulent acheter. Et ce qu'ils achètent souvent, c'est le droit de changer d'avis comme de chemise, la disparition d'un cahier des charges figé (mais souvent, il n'y a plus de specs du tout. La partie où la MOA maintient un backlog des fonctionnalités à développer passe facilement à la trappe) et la communication informelle qui permet de facilement prétendre qu'on n'a jamais dit ça. Bref, tout le poids du projet se retrouve exclusivement sur l'équipe technique. Forcément, ça finit par agacer.
Le développeur a pour rôle d'apporter son regard technique à un problème, d'expliquer et pourquoi pas proposer des solutions techniques pour répondre à un besoin fonctionnel, quantifier le travail a réaliser afin de permettre au client de prioriser les fonctionnalités souhaitées, etc.. Sans parler du fait que la présence des professionnels technique est plus rassurante pour un client qu'un "simple" commercial qui ne sais pas ce qu'il vend.
Désolé pour toi, mais la réalité est toute autre : un cahier des charges vise effectivement à expliciter les besoins, mais hélas on ne vit pas dans un monde formel où les règles sont connues à l'avance, et donc complètement prédictible ou tout au moins complètement formalisable. Pour établir un cahier des charges, il faut savoir de quoi le client a besoin, mais le client lui-même ne sait pas forcément ce dont il a besoin. Il a éventuellement un (souvent plusieurs) problème(s) bien cerné(s), mais n'a justement pas la compétence pour savoir ce qui résoudrait ce(s) problème(s), autrement il le réglerait lui même. De l'autre côté, il y a le dév, qu'on estimera être super compétent parce que c'est un pro, qui connaît donc son domaine sur le bout des doigts mais n'a jamais fait face aux problèmes que connaît le client, puisque ce sont des problèmes spécifiques au domaine du client et non à celui du dév. Et comme on ne trouve ni baguette magique en supermarché ni expert extrasensoriel sur le marché de l'emploi, pour établir le cahier des charges il faut que le client et le dév se mettent ensemble autour de la table et discute des problèmes du premier et des solutions que le second peut apporter. À cela, il faut ajouter qu'expliciter ce qu'on sait n'a rien de trivial, on fait d'ailleurs la différence entre :
- ce qu'on sait savoir (known knowns)
- ce qu'on sait ne pas savoir (known unknowns)
- ce qu'on ne sait pas savoir (unknown knowns)
- ce qu'on ne sait pas ne pas savoir (unknown unknowns)
Le cahier des charges s'établit sur la base de ce qu'on sait, c'est à dire les deux premiers points : le premier permettra d'identifier les besoins déjà connus, le second identifiera les travaux de veille techno à effectuer. Cependant, il reste les deux derniers points. Et notamment le 3e, qui est au sujet de ce dont on ne se rend pas compte qu'on le sait. Cette partie là concerne notamment toutes les connaissances qu'on a fini par automatiser, à tel point qu'on l'a oublié et que ça nous paraît évident. C'est notamment ce qui est à la source des biais de raisonnement, mais aussi un des principaux problèmes en ingénierie des exigences : le client ne dit pas tout, pas forcément parce qu'il veut cacher des choses, mais simplement parce qu'il ne voit pas l'intérêt de le dire, tellement ça lui paraît évident (le dév est donc censé déjà le savoir, inutile donc de l'écrire). En fait, c'est même plus vicieux que ça, car on ne parle pas là de quelque chose qui viendrait à l'esprit du client et qu'il se dirait "oh, il doit être au courant, je passe", mais bien de quelque chose qui ne passe même plus par la case conscience. De la même manière que quand on marche, on ne se rend même plus compte qu'on met un pied devant l'autre, ça vient juste "comme ça" (alors qu'on est bien passé par une phase d'apprentissage où il fallait faire attention à bien s'appuyer sur un pied avant de bouger l'autre et de faire suivre le corps).
Bien entendu, le 4e point (unknown unknowns) n'est pas en reste non plus : souvent, le client viendra avec une idée préconçue de ce qu'il lui faut, alors qu'il n'a pas les compétences pour ça. Mais de par les connaissances qu'il a lui, il pense que telle ou telle chose pourra résoudre son problème. Et c'est de là que démarre le cahier des charges : pas du problème à résoudre, mais de l'idée préconçue que le client a de la solution. Or, souvent le client n'a tout simplement pas idée de ce qui se fait de mieux, voire il ne connaît pas suffisamment la solution qu'il a en tête pour se rendre compte qu'en fait il est à côté de la plaque. Le cahier des charges pourra être rédigé de la meilleure des façons, si la solution proposée ne résout pas le problème, le projet échouera lamentablement (et le dév dira que c'est la faute du client de ne pas savoir et le client la faute du dév de ne pas comprendre).
Avec ça, on comprend aisément pourquoi il vaut mieux avoir un contact entre client et dév qui soit direct, ce que prônent les méthodes agiles. Seulement, le dév ne connaît/comprends pas (en général) l'intégralité du problème du client (après tout c'est pas son domaine), et le cahier des charges se focalisant sur la solution à implémenter on fait face à une situation où les deux parties ont une connaissance incomplète et doive donc s'aligner. Le dév doit essayer d'identifier le problème du client en fonction de la solution qu'il demande, ce qui n'a rien d'évident vu que ça peut être une solution foireuse, et demander des précisions sur pourquoi le client veut telle ou telle fonctionnalité. En face, le client n'est pas forcément capable de dire tous les tenants et aboutissant (on n'est pas tous pédagogues), on n'est donc jamais sûr d'avoir la meilleure vision du problème, et donc jamais sûr de la pertinence de la solution proposée. C'est une des raisons principales pourquoi des projets en Waterfall peuvent foirer et qu'on prône l'agile quand c'est possible : la solution établie dans le cahier des charges peut ne pas être la bonne, et donc on privilégie les remises en question pour éviter l'échec final.
Donc non, personne n'est "censé savoir". Chacun sait des choses, et c'est en combinant et discutant qu'on établit les besoins et priorités. C'est pas comme à l'école où les questions sont bien choisies et ne reste alors qu'à choisir la bonne réponse. En dehors de l'école, il faut aussi savoir chercher les bonnes questions, et c'est tout un art.
Site perso
Recommandations pour débattre sainement
Références récurrentes :
The Cambridge Handbook of Expertise and Expert Performance
L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})
Pour continuer sur le thème "ne blâmez pas la méthode, blâmez les gens qui l'utilisent mal", je conseille l'excellente réponse d'Uncle Bob Martin à cet article.
Tiens c'est marrant le point (5) me rappelle quelque chose
Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
Ceylon : Installation - Concepts de base - Typage - Appels et arguments
ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
Une solution vous convient ? N'oubliez pas le tag
Signature par pitipoisson
Absolument, et, sans re-rentrer pour la N'ième fois dans le détail, je suis atterré et l'ai dit X fois dans cette partie du forum, depuis plus de 8 ans, par la confusion (marketing, et en pratique et enseignée) qui s'est faite entre "le Manifeste" et des méthodologies..
Le Manifeste est ANTINOMIQUE d'une méthodologie quelconque..
Mais le monde de l'informatique veut des règles écrites.. un processus défini..
Je me suis déjà fait blasté au motif d'élitiste, mais je maintiens : l'agilité est faite pour des gens COMPETENTS et EXPERIMENTES..
XP, Scrum, etc, ne devraient pas exister ou être suivis... Il ne devrait pas y avoir de personnes "Scrum Master". Juste des rôles... mais la même personne peut être Master sur un projet et autre chose sur un autre projet..
Les gens qui me connaissent ici connaissent ma position, et je ne peux que me désespérer qu'une excellente pratique soit la cible de critiques infondées, simplement parce qu'on a voulu l'appliquer à tout et n'importe quoi avec n'importe qui..
Pour ceux qui le souhaite, je suis disposé à aller faire des présentations
compétents, de toutes façons, les pas compétents planteront un waterfall aussi surement, et n'oseront même pas faire du cowboy.
Expérimentés, ça aide, c'est sur. Mais je connais des gens qui, à peine diplômes, étaient parfaitement opérationnels dans un environnement hostile ou il leur fallait être, par défaut, agile. Sans jamais que le mot soit prononcé.
Non, le souci que moi je vois, c'est que dans un projet agile, le pouvoir est en bas de la pyramide hiérarchique : les utilisateurs finaux et les développeurs sont ceux qui créent de leur mains, et la hiérarchie est juste là pour leur trouver des machines et un réseau qui marche. Et ça, dans bien des structures, c'est inacceptable. Si le chef n'a pas le pouvoir de jouer au petit chef, alors il va tout faire pour reconquérir se pouvoir. Et donc empêcher la démarche agile de se déployer correctement.
Pas tellement d'accord. Ca reviendrait à dire que la pensée est antinomique de l'action, que le principe est antinomique de son application concrète et formalisée.
Parmi les auteurs du manifeste agile, au moins 4 ont par la suite ou avaient déjà créé leur propre méthodologie et tenté de la diffuser, preuve qu'ils étaient loin d'estimer qu'il ne pouvait pas y avoir de cadre concret et prescriptif à ces idées. Maintenant c'est vrai qu'ils souhaitaient ces processus les plus légers possibles. Le manifeste était d'ailleurs un groupe de réflexion sur les lightweight methods avant que le nom Agile soit choisi.
Compétents et expérimentés en quoi ? En technique ? En recueil de besoins ? En organisationnel ? Tout cela peut s'acquérir à condition qu'on se pose les bonnes questions.
Je dirais plutôt que l'agilité est faite pour des gens qui sont conscients d'avoir des problèmes auxquels l'agilité répond, et veulent s'améliorer.
Le mot Master est sans doute maladroit, mais il correspond bel et bien à un rôle avec des tâches définies. Scrum ne dit nulle part que le Scrum Master doit être le même de projet en projet.
Absolument, mais c'est aussi vrai pour les méthodologies agiles que les valeurs et principes du manifeste lui-même.
Tu prends un bon développeur RUP à l'ancienne, tu le mets avec des geeks agiles... 2 options, le dev deviens mauvais de caractère ou il fait un burn out.
Répondre avec citation
Partager