Discussion :

[Jonathan]

Tout le monde prétend suivre les méthodes agiles dans son travail
mais en réalité, peu de personnes le font vraiment

On entend très régulièrement parler de méthodes agiles et plusieurs personnes d'ailleurs disent les utiliser dans leur travail, mais bien souvent la réalité est toute autre. Il se trouve que ces personnes se servent plutôt de quelque chose de très différent des méthodes agiles conventionnelles. Tout d'abord, il faut savoir qu'une méthode agile est une méthode de gestion et de développement de projets ou programmes informatiques qui vise à satisfaire les besoins du client au terme du contrat de développement.

Lorsqu'elles sont bien appliquées, les méthodes agiles permettent d'organiser le travail de façon à rendre les équipes faisant partie du projet, très productives. Seulement, il a pu être observé que dans bon nombre d'entreprises qui disaient utiliser des méthodes agiles dans leurs projets, il subsiste de graves manquements qui n'existeraient pas si les méthodes agiles étaient correctement adoptées. En fait, malgré l'intention de ces entreprises d'adopter des méthodes agiles, elles sont parfois contraintes en raison de certaines difficultés, de finir par travailler d'une manière qui ne ressemble pas du tout à une méthode de travail agile.

Certaines entreprises, juste pour suivre la tendance, se lancent dans certaines pratiques plus ou moins agiles et qui parfois ne correspondent pas à leurs équipes. C'est le cas de celles qui décident d'organiser le travail en Sprints de 2 semaines au cours desquelles les équipes doivent pouvoir produire des livrables (solutions présentables au client). Cette façon de faire peut ne pas correspondre à toutes les équipes et entraîner des ralentissements dans le travail étant donné que parfois le livrable produit par une équipe ne peut fonctionner sans celui produit par une autre.

Les méthodes agiles impliquent de développer un produit dans sa forme la plus fine et de le mettre le plus rapidement possible entre les mains de véritables utilisateurs, afin que ces derniers le testent et donnent leurs avis. De plus en plus, les clients veulent participer au développement du produit qui leur sera proposé et non plus être des consommateurs passifs. Le fait que certains dirigeants d'entreprises ne s'en rendent pas compte peut aussi constituer une difficulté à la pleine adoption des méthodes agiles.

Bien que les dirigeants d'entreprises aient leur part de responsabilité puisqu'ils sont les décideurs, ils ne sont pas les seuls fautifs dans cette affaire. Les employés eux aussi peuvent constituer un problème dans le sens où ils s'opposent à la culture même des équipes agiles. En effet, pour fonctionner efficacement, les méthodes agiles s'appuient sur des personnes ayant une profonde expertise dans un domaine, un intérêt général et une volonté d'apprendre dans de nombreux autres domaines de compétences. Mais, il peut arriver qu'au sein d'une équipe, se trouvent des personnes qui s'en tiennent uniquement à un seul domaine d'expertise en refusant d'apprendre ou de contribuer dans un autre domaine.

A tout ceci, peuvent encore s'ajouter plusieurs autres éléments qui compromettent la pleine adoption des méthodes agiles dans les entreprises. Pourtant, à la question de savoir s'ils utilisent des méthodes agiles, plusieurs managers répondent par l'affirmative, ne sachant pas vraiment qu'en réalité, en ne respectant pas certains aspects qu'impose Agile, ils ont plutôt adopté quelque chose de très différent.

Source : QZ

Et vous ?

Que pensez-vous des méthodes agiles ? Pensez-vous comme certains qu'elles devraient être abandonnées ?
Que pensez-vous des Sprints ? Sont-ils adaptés à toutes les équipes ?
Pensez-vous que vous ou votre entreprise utilisez réellement les méthodes agiles ?

Voir aussi :

Les développeurs devraient abandonner les méthodes agiles selon Ron Jeffries, l'un des signataires du Manifeste Agile
Agile : entre Scrum et Kanban, laquelle des deux méthodologies est-elle la meilleure ? Le point dans une étude comparative
CollabNet : l'adoption des pratiques agiles augmente en entreprise, mais très peu d'organisations auraient un haut niveau de compétence

[supergeoffrey]

Pour rappel, il y a 4 règles qui définissent les méthodes agiles.

https://agilemanifesto.org/iso/fr/manifesto.html

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

Ce n'est pas très compliqué à faire des méthodes agiles quand on y pense.

[Pierre Louis Chevalier]

Cet article est très réaliste. Ce mot est utilisé par pleins de gens pour faire croire qu'ils sont à la mode, mais dans les faits les processus sont rarement respectés.
D'une façon générale dans le secteur du développement il y a un manque flagrant de bons managers, car le management n'est pas tellement dans la culture des geeks qui constituent le plus gros de ceux qui vont dans la filière IT, et quand il y a de bons managers issu des filières de management et pas de l'IT ils sont le plus souvent largués sur la partie technique, donc les deux mondes ont du mal à se rejoindre de façon efficace. Ça peu parfois déboucher vers quelque chose chez un très petit nombre d'individus mais le plus souvent après un très grand nombre d'années d'expérience.

[Ryu2000]

Que pensez-vous des méthodes agiles ?

C'est toujours mieux que le cycle en V ! (excusez-moi j'ai un problème avec le cycle en V)
Mettre un peu d'agilité dans la gestion de projet c'est pas mal, ça permet d'être plus souple et plus proche des besoins du client.

Pensez-vous comme certains qu'elles devraient être abandonnées ?

Je pense qu'il faut laisser les équipes de développement bricoler comme elles veulent.
Il n'y pas besoin d'imposer une vision des choses aux autres.
Si des développeurs sont content de mettre un peu d'agilité dans leur gestion de projet, il faut les laisser faire. (à moins que le développement soit bloqué)

Que pensez-vous des Sprints ? Sont-ils adaptés à toutes les équipes ?

C'est juste une liste de tâches à réaliser...

Pensez-vous que vous ou votre entreprise utilisez réellement les méthodes agiles ?

Pas à la lettre, parce que ce serait de la folie.
Déjà SCRUM ce serait chiant, mais alors Extreme programming ce serait impossible.
Je crois que vouloir suivre le concept à la lettre ferait perdre du temps au final.

Certaines entreprises, juste pour suivre la tendance, se lancent dans certaines pratiques plus ou moins agiles et qui parfois ne correspondent pas à leurs équipes. C'est le cas de celles qui décident d'organiser le travail en Sprints de 2 semaines au cours desquelles les équipes doivent pouvoir produire des livrables (solutions présentables au client)

Ouais enfin c'est pas un vrai livrable, il faut juste faire des modifs pour montrer au client, mais le client ne pourra tester qu'à la prochaine vraie livraison d'alpha, beta, je sais pas quoi, qui peut tomber dans 6 mois.

Faire une réunion toutes les 2 semaines avec le client permet de ne pas tomber trop loin de ses besoins.
Comme ça il peut dire "je vous avais demandé ça, mais en fait j'ai besoin d'autre chose".

[pboulanger]

Globalement, dans toutes les entreprises, il y a des professionnels TRES agiles: ils sont extrèmement doués pour éviter les patates chaudes...

Dans une startup ou une équipe qui est très autonome, les méthodes agiles peuvent présenter un intérêt... Pour une boîte de 20000 personnes avec des dépendances/adhérences entre les équipes cela devient plus compliqué...

[grunk]

A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

Chez nous , on applique pas une méthode en particulier , on fait en sorte d'être le plus agile possible , c'est à dire répondre rapidement à des demandes/changements mais on s'impose surtout pas de contrainte du style réunion tt les jours , sprint de X jours tous les Y jours , etc;..

[sergio_is_back]

A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

Chez nous , on applique pas une méthode en particulier , on fait en sorte d'être le plus agile possible , c'est à dire répondre rapidement à des demandes/changements mais on s'impose surtout pas de contrainte du style réunion tt les jours , sprint de X jours tous les Y jours , etc;..

Je rejoint ton expérience là : Je suis dans une petite boite (seulement 4 dév dans l'équipe) et ce qui prime surtout en fin d'exercice quand il va falloir faire le bilan c'est de livrer tout ce qui est possible de livrer alors on prend des chemins de traverse , plus d'assurance qualité (alors que pendant le reste de l'année c'est : revue de projet, analyse, point d'avancement, etc...) là on jette le tout aux orties pendant les 3 trois derniers mois de l'exercice... Ceci ça m'a toujours fait rire... Quand je vois la tête de notre consultant qualité lorsqu'on lui que pendant les trois prochains mois il peut se carrer ses formulaires qualité dans l'oignon... et le directeur lui dit devant tout le monde que c'est bien beau mais qu'il faut penser au chiffre d'affaire en priorité...

Et puis les méthodes agiles... en vieillissant ça devient de plus en dur (j'ai passé la cinquantaine)....

[tanaka59]

La méthode agile sera celui le plus soumi et documentant le moins son travail. C'est excellent quand vous devez reprendre un projet et qu'aucun interlocuteur n'a de document .. que vous êtes tout seul qui plus est ...

Travailler en mode agile c'est faire aujourd'hui ce qui était necessaire hier ... vous êtes pas content ? C'est de l'insubordination ? C'est le même tarif vous attendrez .

[youtpout978]

A chaque fois qu’on m’en parle je dis que je connais mais jamais appliquée complètement, quand on m’a sorti le pipo ici on pratique la méthodologie agile je les vois arriver avec leur gros sabots, au finale le client prend ce qui lui arrange, résultat des réunions de 30-45 min tous les matins, ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...

[Ryu2000]

résultat des réunions de 30-45 min tous les matins

Hein ?
Normalement ce n'est pas censé être un stand-up meeting et durer moins de 5 minutes ? On dit ce qu'on a fait hier, ce qu'on a prévu de faire aujourd'hui et si on a vu un problème qui pourrait empêcher d'attendre les objectifs du sprint ?
Il y a des concepts qui sont mal appliqués.

Moi l'aspect agile que j'aime bien c'est de montrer régulièrement au client la progression du développement et de récupérer ses retours sur la dernière version qu'il lui a été livré.

[blbird]

La méthode agile a pas mal d'avantages, mais pour moi un gros inconvénient qui en découle : celui d'avoir du mal à définir un budget et une date de livraison globale précise.

Quand je l'ai vu fonctionner à 100%, c'était uniquement avec de gros ou très gros clients : soit en interne d'une grosse entreprise, soit avec des clients ayant beaucoup de moyens.

[Marco46]

La méthode agile a pas mal d'avantages, mais pour moi un gros inconvénient qui en découle : celui d'avoir du mal à définir un budget et une date de livraison globale précise.

J'ai du mal à te suivre. L'agile avec SCRUM c'est justement un budget fixe avec des dates de livraison figées et un scope qui varie. C'est ça le principe. T'as des échéances de livraisons prédéfinies et tu livres ce que tu as terminé (variable) à ces dates.

[Marco46]

ils veulent qu’on respecte les délais des sprints sans nous en laisser le temps ...

C'est juste que vous faites pas de l'agile. Le principe de base de l'agile c'est que le contenu d'un sprint n'est pas un engagement sur un périmètre. Il y a des dates de livraisons fixes avec un scope variable. Les tâches sont estimées et ensuite on voit le consommé réel. En aucun cas on ne peut exiger une livraisons d'un scope figé à une date figée. C'est justement pour arrêter de faire ça que l'agile a été créé.

La situation que tu décris c'est une organisation qui faisait du waterfall ou du Cycle en V et qui essaie de se mettre à l'agile sans avoir changé fondamentalement sa manière de travailler. C'est un problème très courant du à un manque de compréhension de l'agile à tous les échelons de l'organisation (chef qui veut sa feature à date).

[Marco46]

A moins de ne pas avoir de client et/ou de boss je vois pas bien comment il est possible d'appliquer à la lettre quelconque méthode (agile ou pas).

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

Ça c'est du forfait. Ce n'est pas compatible avec de l'agile.

[micka132]

Pour rappel, il y a 4 règles qui définissent les méthodes agiles.

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan

C'est exactement le 1er point dont il s'agit ici.
Certains estiment que "ce n'est pas agile" parce que ne respecte pas l'un des cahiers de charges d'une des méthodes agiles reconnu.
Agile ou pas, c'est le boulot du manager de faire qu'une équipe fonctionne bien pour délivrer un bon produit. Le gars qui pense que "faire de l'agilité" va régler les problèmes ce fout le doigt dans l’œil. En fait le problème c'est de croire qu'on peut être un bon manager à partir d'un bouquin, alors qu'une méthode va juste permettre de donner un cap. Il ne faut surtout pas l'appliquer à la lettre, mais bien l'adapter à l'équipe, avec pourquoi pas un mélange de 12 autres méthodes.
Un bon manager est agile par nature mais pas forcement parcequ'il applique une méthode dite "agile".

[blbird]

J'ai du mal à te suivre. L'agile avec SCRUM c'est justement un budget fixe avec des dates de livraison figées et un scope qui varie. C'est ça le principe. T'as des échéances de livraisons prédéfinies et tu livres ce que tu as terminé (variable) à ces dates.

Ces 2 points ne vont pas avec un plan budgétaire initiale précis, fixe et très peu variable voulu par les clients, ce qui est malheureusement souvent le cas.

L'agile ne convient pas à tous les projets, ni tous les clients.

[Marco46]

Ces 2 points ne vont pas avec un plan budgétaire initiale précis, fixe et très peu variable voulu par les clients, ce qui est malheureusement souvent le cas.

Parce que tu fais un lien entre budget et scope fonctionnel. Ça s'appelle du forfait. Le forfait n'est pas compatible avec l'agile, c'est antinomique.

L'agile ne convient pas à tous les projets, ni tous les clients.

Tout à fait d'accord. Je dis simplement qu'on ne peut pas dire qu'on fait de l'agile en prétendant figer un scope ET une date de livraison, c'est totalement contradictoire.

[xbrossard]

"Les individus et leurs interactions plus que les processus et les outils": chacun utilise ses propres outils et plus rien n'est compatible ensemble. Par exemple, l'un fait les docs en markdown, l'autre utilise Word. Après c'est un bordel total.
"Des logiciels opérationnels plus qu’une documentation exhaustive": le retour des logiciels sans doc et non maintenables 1 an après. Et le créateur du logiciel redevient le seul maître à bord (alors que l'objectif des méthodes de conception était justement de partager la connaissance avec le client)
"La collaboration avec les clients plus que la négociation contractuelle": le dialogue impossible avec le client, soit parce qu'il n'est pas toujours disponible (alors que c'est indispensable en Agilité), soit parce qu'il changera sans arrêt selon son bon plaisir. Et pas de négociation contractuelle, c'est une blague à l'heure des centres de services en SSII où tout les échanges sont minutieusement contractualisés étant donné que la responsabilité de la SSII est maintenant engagé (engagement de résultat et plus de moyen)
"L’adaptation au changement plus que le suivi d’un plan" : comme il faudra toujours être à la pointe de la technique, le logiciel sera toujours en béta, ultra-buggué et non maintenable. En plus, comme il n'y aura plus d'architecture (trop contraignant) le logiciel ne satisfera plus les exigences techniques du cahier des charges (performance, sécurité, maintenabilité)

Bref, l'agilité pour les petits projets en interne d'une boite, ça peut marcher...mais ça représente environ 5% des projets

[pschiit]

Hein ?
Normalement ce n'est pas censé être un stand-up meeting et durer moins de 5 minutes ? On dit ce qu'on a fait hier, ce qu'on a prévu de faire aujourd'hui et si on a vu un problème qui pourrait empêcher d'attendre les objectifs du sprint ?
Il y a des concepts qui sont mal appliqués.

Moi l'aspect agile que j'aime bien c'est de montrer régulièrement au client la progression du développement et de récupérer ses retours sur la dernière version qu'il lui a été livré.

on en est pas loin,
5-10 min de sprint planning par jour
60 min "sprint planning 1" par sprint pour qualifier les taches (compter 2h d'étude avant le SP2)
60 min "sprint planning 2" par sprint finir la qualification et l'attribution des taches
90 min " sprint review" par sprint
60 min de retrospective par sprint.

Au final l'agilité se transforme en une torture de réunions sans fin

[koala01]

Salut,

Quand un client te dis je veux une version pour dans 3 jours parce que il avait oublié cette échéance hyper importante , tu peux pas vraiment lui répondre
- "ha ba non là du coup en vient de commencer un sprint de 2 semaines , va falloir attendre" , ou encore ,
- "euh ... on à fait qu'une branche du V, va falloir attendre ..."

Tu dis plutôt "Oui monsieur , merci monsieur ce sera prêt " et tu jette par la fenêtre toutes les bonnes pratiques en vigueur dans le but de satisfaire ton client et pas perdre une commande.

C'est peut-être justement là qu'est le problème.

Les gens sont tous près de croire que l'informatique c'est soit simple soit magique.

Sur un forum concurrent, j'ai même rencontré quelqu'un qui m'a sorti un truc du genre de

ben, le développement informatique, c'est simple : il suffit d'écrire du code

Mais, si tous les développeurs prenaient l'habitude de refuser ces délais impossibles qu'on essaye de leur imposer à la dernière minutes, en faisant comprendre au client que le développement ce n'est ni facile ni magique, et que

Désolé, monsieur, mais on avait convenu d'une semaine, qui correspond au délais dont j'ai besoin pour arriver à un résultat valable, et que je suis aussi incapable de compresser le temps que vous de parcourir 700 km en voiture en deux heures

les gens arrêteraient peut être de nous prendre pour des sur hommes ou des magiciens

Après, j'ai bien conscience que la première règle du business est "le client a toujours raison", mais quand même!!!

Après quand tu es éditeur de soft , avec un planning de release prédéfini c'est déjà beaucoup plus facile de travailler comme ça. Par contre quand ton dév est dirigé par les appel d'offre et le commerce c'est mission impossible.

C'est justement là qu'est le véritable problème!

Tant que l'on ne se décidera pas à utiliser des commerciaux qui savent ce qu'est le développement, qui prennent en compte le triangle d'or, les mentalités ne pourront pas évoluer.

EDIT

"Les individus et leurs interactions plus que les processus et les outils": chacun utilise ses propres outils et plus rien n'est compatible ensemble. Par exemple, l'un fait les docs en markdown, l'autre utilise Word. Après c'est un bordel total.

Tu semble ne pas comprendre le sens réel de cette phrase.

Elle veut surtout dire que le client doit venir avec le "quoi" et l'équipe de dev (dans son ensemble) avec le "comment". C'est donc à "l'équipe de dev" de choisir les outils adaptés à la fourniture du comment obtenir le quoi demandé par le client.

"Des logiciels opérationnels plus qu’une documentation exhaustive": le retour des logiciels sans doc et non maintenables 1 an après. Et le créateur du logiciel redevient le seul maître à bord (alors que l'objectif des méthodes de conception était justement de partager la connaissance avec le client)

Une fois encore, tu ne sembles pas avoir compris le sens de cette phrase.

Elle signifie que l'on va préférer fournir un logiciel fonctionnel, qui fonctionne selon les envies et les besoins du client plutôt que de passer son temps à écrire un bouquin de 500 à 2500 pages (que personne ne lira de toutes manières jamais dans son ensemble) décrivant toutes les fonctionnalités et comment les utiliser.

En plus, il y a plusieurs types de documentations, qu'il s'agit de distinguer très clairement:

D'un coté, tu as la documentation utilisateur qui explique comment utiliser le programme (et que la méthode agile considère comme "ne devant pas être exhaustive"), et, de l'autre, tu as la documentation développeur, qui explique le but des différentes fonctionnalités qui ont été développées.

Mais, même pour la documentation développeur, si tu indiques:

• le but d'une fonctionnalité quelconque
• les prérequis (pré conditions) qui doivent être respectées lorsqu'on veut y faire appel
• les impératifs qui doivent être respectés lorsqu'elle a fini son travail (post conditions)
• (éventuellement) les fonctionnalités similaires entre lesquelles il faudrait faire un choix, et, dans ce cas, le critère de choix à utiliser

Tu fournis plus qu'assez d'informations, et il ne sert à rien d'ajouter une explication sur l'algorithme qui est utilisé (et qui sera de toutes manières changé dans deux jours )

Nous en arrivons donc "tout simplement" à faire une distinction claire entre une documentation "suffisante" (comprends : assez complète que pour permettre au développeur d'utiliser une fonctionnalité), et une documentation exhaustive (comprends : qui passe le moindre détail en revue)

"La collaboration avec les clients plus que la négociation contractuelle": le dialogue impossible avec le client, soit parce qu'il n'est pas toujours disponible (alors que c'est indispensable en Agilité),

Ca, c'est effectivement un réel problème : la méthode agile oblige les deux parties à communiquer en permanence. Que "quelqu'un de l'équipe de dev" doit pouvoir répondre n'importe quand au client, mais aussi (et surtout) qu'il faut quelqu'un chez le client qui doive pouvoir répondre à l'équipe de dev.

soit parce qu'il changera sans arrêt selon son bon plaisir.

Et c'est donc à nous d'essayer de le "garder dans les clous" (qu'il a lui-même planté, d'une certaine manière), en lui rappelant la décision diamétralement opposée qu'il avait prise la semaine précédente

Et pas de négociation contractuelle, c'est une blague à l'heure des centres de services en SSII où tout les échanges sont minutieusement contractualisés étant donné que la responsabilité de la SSII est maintenant engagé (engagement de résultat et plus de moyen)

C'est malheureux à dire, mais là, on récolte juste ce que l'on a semé depuis plus de vingt ans (et que certains développeurs continuent à semer aujourd'hui)...

Les SSII, ce sont, d'abord et avant tout des société commerciales, qui s'intéresse au quota d'heures qu'elle doivent payer à leurs employés par rapport au forfait qu'elles ont pu "extorquer" à leur client.

Et, depuis plus de vingt ans, les développeurs ont préféré satisfaire leur patron (en passant "le moins de temps possible" sur une mission donnée) que d'essayer de satisfaire pleinement le client (en lui fournissant un logiciel de qualité, correspondant réellement à ses besoins).

Comment peux-tu t'étonner qu'il y ait maintenant une obligation de résultats dans de telles conditions

Et puis, beaucoup trop de développeurs semblent oublier que leur principal outil n'est pas leur clavier, mais que c'est leur cerveau!

Il arrive encore beaucoup trop souvent que des développeurs utilisent l'excuse du "oui, mais quand on n'a pas le temps" pour justifier l'écriture de code cradingue.

J'écris particulièrement vite en dactylographie, et, pourtant, je réfléchis encore plus vite que ce que je n'arrive à écrire. Et je suis sur que c'est le cas de tout le monde.

Il serait temps que les développeurs finissent par se rendre compte qu'il vaut mieux écrire dix lignes après une minute de réflexion que d'en écrire cinquante ou cent sans y avoir accordé de réflexion

"L’adaptation au changement plus que le suivi d’un plan" : comme il faudra toujours être à la pointe de la technique, le logiciel sera toujours en béta, ultra-buggué et non maintenable.

La (non) maintenabilité et l'(in)adaptabilité, c'est surtout la conséquence du (non) respect de quelques règles simples, pour lesquelles trop de développeurs vont nous sortir l'excuse du "oui, mais il y a toujours des exceptions" pour justifier qu'ils n'essayent même pas de les suivre

Dans le pire des cas, on parle de cinq principes (SOLID), de trois lois (Déméter, emmerdement maximum et Finagle, les deux dernières étant des lois empiriques ) , de quelques acronyme (YAGNI, DRY, KISS) et de conventions de nommage (spécifiques à un projet) à respecter, mais qui permettent de rendre un projet maintenable dans le même délais (et même parfois encore plus vite) que quand ces principes, ces loi, ces acronyme ne sont pas pris en compte

Un logiciel développé rapidement n'est pas forcément synonyme de logiciel buggé. Il faut juste que les développeurs apprennent à utiliser leur cerveau

Après, qu'il faille être à la pointe de la technique, ca, c'est un tout autre problème

En plus, comme il n'y aura plus d'architecture (trop contraignant) le logiciel ne satisfera plus les exigences techniques du cahier des charges (performance, sécurité, maintenabilité)

Je suis développeur C++, qui est un langage particulièrement proche de l'architecture, vu que certains types de base ont des tailles potentiellement différentes en fonction de l'architecture, justement.

Et pourtant, j'arrive à faire en sorte que mon code soit portable (qu'il puisse être compilé aussi bien sur une architecture 8bits que sur une architecture 32 ou 64bits), qu'il présente des performances plus que respectables, une sécurité qui ne sera pas prise en défaut, et le tout, en assurant une maintenabilité maximale.

Or, je peux t'assurer que je ne suis pas un extra-terrestre... Je veille simplement à appliquer des règles simples et à utiliser les bons outils

Bref, l'agilité pour les petits projets en interne d'une boite, ça peut marcher...mais ça représente environ 5% des projets

J'admets que, pour les projets externes, l'agilité n'est pas forcément la meilleure solution.

Mais tu me semble pour le moins pessimiste en parlant de 5% des projets

Maintenant, je présume que cela dépend aussi grandement du domaine d'application et du langage utilisé