Existe-t-il une alternative viable à la méthodologie de développement agile?

47

Les deux méthodologies de développement de logiciels prédominantes sont waterfall et agile. Lorsque nous discutons de ces deux aspects, nous mettons souvent l’accent sur les pratiques particulières qui les distinguent (programmation par paires, TDD, etc. par rapport aux spécifications fonctionnelles, grande conception initiale, etc.).

Mais les vraies différences sont beaucoup plus profondes, en ce sens que ces pratiques sont issues d’une philosophie.

Waterfall dit: Le changement est coûteux, il devrait donc être minimisé.
Agile dit: Le changement est inévitable, alors faites en sorte que le changement soit bon marché.

Ma question est la suivante: peu importe ce que vous pensez du TDD ou des spécifications fonctionnelles, la méthodologie de développement en cascade est-elle vraiment viable?

Est-ce que quelqu'un pense vraiment que minimiser les changements dans les logiciels est une option viable pour ceux qui souhaitent fournir des logiciels de valeur? Ou est-ce vraiment la question de savoir quelle sorte de pratiques fonctionnent le mieux dans nos situations pour gérer le changement inévitable?

Eric Wilson
la source
1
question interessante. dans l'attente des réponses.
DevSolo
3
@ FarmBoy - Bonne question. Je vois la philosophie agile un peu différemment. Je l’écrirais ainsi: "Agile dit: Le changement est inévitable, il est donc bon marché de déterminer le coût du changement." Le changement peut encore coûter très cher, mais en mode agile, vous pouvez le comprendre rapidement et à moindre coût, de sorte que nous connaissons toujours le coût du changement. Si on le formule autrement, les gens pensent que, puisqu'ils opèrent un changement agile, ce sera bon marché. Certains changements coûtent cher quel que soit le processus.
Mike Two
1
@Yannis Rizos: pourquoi fermez-vous cette question intéressante seule, sans un seul vote de la communauté?
1
@ Pierre303 à cause de cette question que la discussion ici a soulevée cette question.
Ryathal

Réponses:

59

Bien sûr, la cascade est viable. Cela nous a amené à la lune!

Et c'est un coach agile qui parle ici!

À moins que vous ne puissiez identifier clairement les problèmes liés à la façon dont vous gérez vos projets, il n’ya aucune raison valable de changer.

En guise d'alternative aux méthodologies Agile et Waterfall , je proposerai VOTRE méthodologie . Adapté à votre activité, à votre équipe, à vos produits, à votre façon de travailler, à votre culture d'entreprise ... C'est pourquoi Scrum est appelé un simple cadre plutôt qu'une méthodologie.

Vouloir implémenter une méthodologie parce que quelqu'un sur un blog dont vous aimez parler en parle est aussi stupide que de laisser les problèmes aller sans rien faire.


la source
10
+1 sur VOTRE méthodologie, le prochain entraîneur Agile me dira que SCRUM est le seul moyen d'obtenir un bon départ pour le dos;)
Martijn Verburg
1
@karianna: Je fais spécifiquement SCRUM, mais parfois, ce n'est tout simplement pas approprié. D'autre part, j'ai également vu une équipe essayer de vendre SCRUM à leurs patrons en pensant que cela résoudrait leur problème. Ils ont échoué parce que le problème n'était pas leurs chefs ni leur premier ministre. Il n'y a pas de règle unique. Chaque cas sa solution. Et oui, la plupart des problèmes d'organisation peuvent être résolus avec des techniques agiles, mais l'agile n'est pas une solution miracle.
5
Pas seulement la lune. La navette spatiale avait environ 1 M lignes de code C dans ses systèmes embarqués. Plus de 30 ans plus tard, ils n’avaient que 2 bogues à intégrer à la production.
Dan Neely
2
La cascade a également tué les trois premiers astronautes. Cette insistance sur l'utilisation de ce programme Apollo comme affiche pour Waterfall est, au mieux, ignorante. Waterfall est également citée comme responsable de la confusion totale entre les deux programmes et du fait que la navette est une "navette spatiale" trop ingénieuse, fragile et coûteuse, alors que la spécification initiale visait un "camion spatial". Je suis à peu près sûr que SpaceX serait en désaccord à propos de Waterfall.
4
@DanNeely, le logiciel de navette spatiale n’était pas à la hauteur de la qualité. Apparemment, le prix était de la taille de 1000 $ par ligne de code.
21

Tout d'abord, je vais être en désaccord avec vos déclarations:

Waterfall dit: Le changement est coûteux, il devrait donc être minimisé.
Agile dit: Le changement est inévitable, alors faites en sorte que le changement soit bon marché.

Mon interprétation est:

Waterfall dit: Le client sait ce qu'il veut.
Agile déclare: Le client ne sait pas ce qu'il veut et nous allons donc devoir créer quelques versions différentes.

La meilleure implémentation de «cascade» que j'ai jamais vue était un énorme projet d'intégration avec un très gros client financier et environ 40 sous-projets impliqués. Le package de bureau et de site Web que nous avons fourni ne comprenait qu’un de ces 40 sous-projets. Alors que je pensais qu'ils dépensaient de manière assez excessive dans l'argent des autres, ils avaient leurs affaires en commun et maintenaient plus de 40 navires différents en mouvement. Le projet a été mis en ligne à la date cible (la cible a été déplacée une fois au cours du projet) et, même si je pensais qu'ils auraient pu le faire de manière plus frugale et agile, cela s'est fait dans les délais et les spécifications. L'horaire de la soirée de lancement comprenait environ 100 pages, dont une quarantaine étaient les coordonnées d'urgence de toutes sortes de personnes impliquées. J'ai été très impressionné par ce client.

Ou bien, vous pouvez faire ce que nous faisons, faire le tour et faire le rapport de plainte / bogue le plus récent, et appeler cela agile.

Tangurena
la source
8
Selon Agile Dilbert: is.gd/lDoQgb
Peter K.
11
Cela ressemble plus à "Waterfall dit: le client ne sait pas ce qu'il veut, alors asseyons-nous, discutons-en et convenons-nous avant de commencer à en
parler
+1: très bonne réponse. Je pense que la communauté agile a un problème fondamental: l’agilité est bonne dans certains contextes pour certaines catégories de projets et de clients, mais ils ne réalisent pas qu’il existe des projets dans lesquels les exigences ne changent pas, des approches plus rapides et plus structurées constituent un meilleur choix. . Je pense que la communauté agile devrait essayer d'identifier de manière réaliste les domaines dans lesquels son approche est un meilleur choix (je pense que de tels domaines existent) et ne pas essayer de la pousser comme une solution générale, car ce n'est pas le cas.
Giorgio
6
@scrwtp - et Agile ressemble plus à "Mon client ne sait pas ce qu'il veut, ne peut pas / ne veut pas parler et ne réfléchit pas, et il change d'avis toutes les 5 minutes. Je dois lui mettre quelque chose en face pour obtenir des réponses significatives ". Sensationnel. Cela semble vraiment regrettable quand je l'écris.
Michael Kohne
1
@scrwtp: Je pense que la question à un million de dollars est la suivante: cette "conviction" est-elle que vous pouvez "vous asseoir et en discuter et être d'accord" viable? La réponse est: ça dépend, non? Cela dépend de plusieurs variables: quelle est la taille du projet? Savons-nous même quelle est sa taille? Combien de temps les clients ont-ils à s'asseoir avec nous? Pendant des décennies, nous avons essayé d'associer le développement logiciel à la construction, qui est presque 100% prescriptive. Le développement de logiciels se situe quelque part entre "totalement réactionnaire" et "100% normatif". Dans la plupart des magasins, on se rapproche davantage de "tout à fait réactionnaire", d'où l'adoption de l'agile.
Calphool
21

Vous commencez par dire:

Les deux philosophies de développement de logiciels prédominantes sont la chute d’eau et l’agilité.

C'est faux. Cette dichotomie a été construite par la communauté agile afin de créer un adversaire contre lequel se positionner. Avant que Agile ne soit à la mode, les gens parlaient d’une myriade d’approches différentes pour la construction de logiciels. Ils existent toujours aujourd'hui, mais d'une manière ou d'une autre, ils sont souvent regroupés dans un grand gâchis appelé "cascade" par des promoteurs agiles.

J'utilise OPEN / Metis et ses variantes depuis plus de 10 ans avec un grand succès. Ce n'est certainement pas agile, et certainement pas cascade. Des milliers de développeurs créent des logiciels extrêmement complexes pour les avions, les systèmes critiques, les opérations bancaires, etc., en utilisant des méthodes non agiles au quotidien.

Alors oui, bien sûr, il existe une alternative viable à l'agile.

CesarGon
la source
6
Je ne suis pas en mesure de comprendre rapidement ce que sont OPEN / Metis à partir de ce lien. (Habituellement, vous n'avez pas besoin de télécharger une méthodologie.) Ma question est la suivante: quelle est sa philosophie, notamment en ce qui concerne le changement? Veut-il minimiser le changement ou en réduire le coût? N'oubliez pas que ma question portait sur la philosophie agile et non sur les pratiques agiles.
Eric Wilson
OPEN / Metis a un cycle de vie itératif qui construit des systèmes de manière incrémentielle. Le changement est reconnu comme quelque chose de non seulement qui se produit, mais aussi de très bien quand cela se produit, car le but même du développement d'un système d'information est de provoquer certains changements. Le coût du changement, cependant, est contrôlé et géré selon un cycle de vie approprié et les pratiques associées.
CesarGon
1
En ce qui concerne votre remarque sur les "méthodes de téléchargement", eh bien ... vous ne téléchargez pas de méthodes, je suis d’accord. Vous téléchargez des documents décrivant des méthodologies. Sinon, comment apprenez-vous à leur sujet? Regardez la myriade de livres décrivant XP, Scrum, etc.
CesarGon
10

Oui, diverses techniques de développement logiciel sont toutes viables en fonction de votre domaine de problème. C'est "Des chevaux pour les cours".

Par exemple, vous écrivez un logiciel pour contrôler une centrale nucléaire ou pour piloter la navette spatiale de la NASA. Ce type de domaine problématique est probablement mieux adapté à une approche en cascade (ou même plus stricte), vous voulez régler tous les problèmes à l’avance si possible (ou BOOM!).

Construire la dernière interface utilisateur web 2.0 / 3.0 / buzzy marketing? L’agilité est une bien meilleure solution (vous avez besoin de retours rapides et de changements).

Il y a ce que j'appellerais des principes d'artisanat du logiciel qui peuvent toujours être appliqués quelle que soit la méthodologie utilisée, par exemple:

  • Contrôle de la source
  • construire et CI
  • programmation en binôme
  • TDD
  • Je donne un ^% $$ &

et plus.

Quoi que vous fassiez, n'écoutez pas les fanatiques de chaque côté de l'équation, faites ce qui est juste pour vous, votre équipe et votre domaine de problèmes.

Martijn Verburg
la source
La cascade fonctionne si vous pouvez vous le permettre. Quelqu'un d’autre supérieur a affirmé que le logiciel du projet Moon de la NASA coûtait environ 1 000 dollars par ligne de code. La plupart des magasins ont besoin de 1 à 10 dollars par ligne de code et l'agilité convient mieux à ce genre de situation. Cependant, je ne prétends pas qu’agile offre globalement une meilleure qualité. En gros, vous pouvez vous permettre de payer beaucoup d'argent pour être certain que le logiciel est correct ou est-il moins coûteux de trouver la solution une fois que vous découvrez que le logiciel n'est pas correct?
Mikko Rantalainen
2

Le problème provient de la complexité du logiciel. La cascade est idéale pour la construction de ponts et le pavage de routes, car la physique ne change jamais. Bien sûr, nous allons développer un nouvel asphalte à un moment donné, mais cela ne révolutionnera pas la façon dont les routes sont construites. L'acier dans la suspension d'un pont est soit la bonne taille, soit ce n'est pas le cas. Vous ne pouvez pas cogner ou stub un véritable projet de construction comme vous pouvez le faire avec un logiciel.

Changements de logiciel. Le logiciel change rapidement. La loi de Moore stipule que le nombre de transistors sur une puce double tous les 18 à 24 mois. En corollaire, le nombre de lignes de code dans un programme double également. La complexité entre ces lignes de code augmente donc avec un bigO de quelque chose comme 2 ^ (2t).

Le logiciel change rapidement et sa complexité augmente de manière exponentielle.

Lorsque vous contrôlez le coût du logiciel, vous souhaitez contrôler les facteurs exponentiels , pas simplement les facteurs multiplicatifs ou additifs. Changer de code augmente la complexité (et devient exponentiellement plus complexe à mesure que le projet avance) de manière exponentielle.

Le changement est inévitable. La nature même de la programmation étend le langage avec des classes et des méthodes personnalisées, modifiant ainsi le langage lui-même. Vous ne pouvez faire cela dans aucune autre discipline d'ingénierie (comme la construction de routes. Vous n'inventez pas de nouveaux trottoirs pour simplement paver une route du Kansas sur la Californie).

La méthode agile vous fournit également une plate-forme pour gérer les versions futures et les corrections de bugs. Vous avez déjà les outils de gestion, les processus et les employés formés pour développer des logiciels versionnés. Avec une méthode en cascade, vous auriez besoin de recycler votre équipe pour gérer les corrections de bugs, même mineurs.

de toute façon, mes 2 cents.

Stephen Furlani
la source
2
De nombreux aspects de la conception de logiciels sont aussi absolus que les lois de la physique. Agile est un outil au même titre que les méthodologies en cascade ou autres, et comme d'autres personnes l'ont signalé, de nombreuses analyses de rentabilisation n'ont pas de sens. Je serais surpris si je vous voyais faire la queue pour monter dans un avion où Boeing a déclaré qu'ils étaient au milieu d'un processus agile sur le logiciel de contrôle de vol et qu'ils avaient besoin de clients pour itérer si l'avion ne se retournait pas dans les airs sans raison. raison.
Hounshell
Et juste pour fusil de chasse plus de trous dans votre argumentation, il y a la route conceptions étant conçu en ce moment qui serait approprié pour une route entre le Kansas et la Californie, mais pas entre New York et Boston. Et de nouvelles techniques de traitement de l'asphalte apparaissent tout le temps.
Hounshell
2
Et enfin, vous dites "Avec une méthode en cascade, vous auriez besoin de recycler votre équipe pour gérer les corrections de bugs, même mineurs." C'est tellement ignorer comment fonctionne le processus de la cascade. Vous devriez essayer un bon magasin de cascade avant votre tribune pour expliquer en quoi cela est inapproprié pour chaque scénario de développement logiciel.
Hounshell
1
Bonjour Stephan, les exigences logicielles ne changent pas toujours.
Paul Nathan
1
Les affaires changent toujours ; une entreprise qui ne change pas et ne s'adapte pas est une entreprise en train de mourir. Le temps est une constante , qui n'interagit pas bien avec le changement. Un système qui a la philosophie qui reconnaît que le changement est attendu peut accueillir le changement, sinon, le temps doit s'adapter au changement, et c'est une constante inouïe!
2

Pour répondre à la question, existe-t-il une alternative viable, pour les logiciels peut-être pas - ou pas encore, du moins dans le cas général. Je pense que cela dépend de la nature du logiciel. Les logiciels, étant des informations, peuvent être dupliqués gratuitement. Contrairement à un pont ou une maison. Cela signifie qu'avec de la pratique, je pourrais bien construire une maison et opérer dans un domaine relativement simple. À quel moment, pourquoi ne pas utiliser une approche ponctuelle?

Mais comme les logiciels ne génèrent aucun coût de duplication, pourquoi voudriez-vous faire la même chose deux fois? Le logiciel tend à s'éloigner de la fabrication. Donc, si tous les logiciels sont la création d'un nouveau produit, nous travaillons toujours dans un domaine complexe où, dans une certaine mesure, nous ne savons pas ce que nous faisons. Ou cela coûte cher de savoir à l’avance et moins cher de le savoir en le faisant. Dans un domaine complexe et risqué, je voudrais essayer des expériences, incrémenter et itérer.

Les centrales nucléaires et les systèmes fly-by wire sont souvent cités en exemple de logiciel que vous voudriez utiliser en cascade. Mais le système avionique de la navette n'a-t-il pas été développé de manière itérative? Comme étaient les systèmes de contrôle du trafic aérien canadien et américain?

Et si OPEN / Metis est itératif et incrémental, pour moi, cela ressemble à une philosophie agile même s’il ne s’associe pas à d’autres pratiques agiles courantes.

AlanMJackson
la source
2
Alors maintenant, agile essaie de prendre le crédit pour itérative et incrémentielle? Peu importe le fait que les aspects itératifs et incrémentaux ont été des éléments essentiels du développement des chutes d’eau depuis le début de mon développement en 1992.
Dunk
1

La méthode des chutes d’eau est certainement viable et est aussi philosophiquement valable que toute autre approche. N'oubliez pas que Waterfall existe depuis beaucoup plus longtemps qu'Agile, mais notez qu'il ne s'agit pas d'un argument pour affirmer qu'une méthodologie est meilleure qu'une autre.

Vous utilisez la méthode Waterfall lorsque vous comprenez très bien le domaine du problème et ce que le client souhaite obtenir dans un progiciel. Vous avez probablement indiqué un prix fixe lors de la prise du contrat, et votre client comprend qu'il ne peut pas déroger aux exigences convenues. Votre processus est strictement un processus qui passe par une série d’approbations entre les différentes étapes du développement, et il est fréquent que chaque étape soit complétée par une équipe différente - parfois même une entreprise différente contact avec les autres. Vous voyez souvent que Waterfall est appliquée à bon escient dans les projets militaires et gouvernementaux lorsqu'ils sont confiés à des entrepreneurs extérieurs. Lorsque Waterfall et d’autres approches similaires ont mauvaise réputation, c’est lorsque les développeurs rencontrent des problèmes, comme une mauvaise estimation, des calendriers planifiés sans temps de réserve ou une compréhension médiocre ou incomplète du domaine problématique. La question n’est jamais vraiment une faute de la méthodologie, mais dans l’application de celle-ci.

La comparaison entre Agile et toute méthodologie est fausse. Agile n'est pas une méthodologie, c'est une philosophie, ou peut-être serait-il préférable de dire que c'est un terme générique qui représente une manière différente de voir comment vous allez développer un logiciel. Une méthodologie est simplement un outil et, en tant que telle, sa valeur sera toujours inférieure aux individus et aux interactions qui sont au cœur de ce que signifie être agile .

Est-ce que quelqu'un pense vraiment que minimiser les changements dans les logiciels est une option viable pour ceux qui souhaitent fournir des logiciels de valeur?

Chaque opportunité de minimiser les changements est précieuse pour le développeur et le client. Les modifications peuvent faire glisser un calendrier ou laisser des fonctionnalités de côté afin de respecter un calendrier. C'est la façon dont vous gérez les effets du changement qui influe sur la valeur de vos projets.

Ou est-ce vraiment la question de savoir quelle sorte de pratiques fonctionnent le mieux dans nos situations pour gérer le changement inévitable?

Vos pratiques peuvent aider à gérer le changement, ou peuvent ignorer complètement le changement. Ce qui compte, c’est la combinaison de vos pratiques de développement et de la gestion de votre relation avec vos clients, et de savoir si ces éléments fonctionnent ensemble de manière efficace pour toutes les parties concernées.

Ceux d’entre nous qui sommes à toutes fins utiles Agile comprennent que vous choisissez une méthode qui fonctionne pour vous. Si vous aimez une approche particulière, suivez-la. Si cela ne vous convient pas, changez-le. La manière dont vous concevez un logiciel consiste réellement à utiliser au mieux les ressources dont vous disposez et à minimiser les pratiques qui peuvent conduire votre projet à l’échec. Vous constaterez souvent que vous devez modifier votre méthode en fonction projet particulier à portée de main.

C’est vraiment une chose de dire «OK, alors nous sommes maintenant agiles», et c’est une toute autre chose que de vivre et de travailler selon la philosophie de l’agile. Que vous utilisiez Waterfall, Incremental, Spiral, SCRUM, XP, FDD ou toute autre méthode, vous êtes fondamentalement agile où vous appréciez:

  • Individus et interactions sur les processus et les outils
  • Logiciel de travail sur une documentation complète
  • Collaboration client sur négociation de contrat
  • Répondre au changement au sujet d'un plan

et où vous apportez vos outils, votre méthode et votre expérience pour mettre en application ces valeurs avec succès.

S.Robins
la source
2
Sensationnel. Il y a tellement de choses étranges ici. La cascade est viable sur la base d'être plus longtemps? La cascade est justifiée sur la base de l'utilisation dans les contrats de défense? Chaque opportunité de minimiser les changements est-elle vraiment dans l'intérêt du client ou conduit-elle à offrir ce qu'il pensait vouloir plutôt que ce qu'il souhaitait réellement? Puisque vous semblez vous soucier de cela, j'ai essayé de comprendre d'où vous venez, mais quelque chose me manque.
Eric Wilson
1
@EricWilson Waterfall existe depuis longtemps et a été utilisé avec succès bien avant que la philosophie Agile ne soit discutée. Il est viable car il existe et s’il est correctement appliqué, il convient à ceux qui souhaitent l’utiliser. Je n’ai pas justifié son utilisation, mais j’ai simplement cité un exemple où j’ai eu une expérience personnelle où j’ai vu que cela fonctionnait, et oui, j’ai aussi vu quelques échecs spectaculaires. Vous ne recherchez pas des opportunités pour minimiser les changements, vous voulez des opportunités pour introduire des changements, mais vous devez le faire de manière sensée, sinon votre client aura soit moins que ce qu'il voulait ou une échéance décalée.
S.Robins
0

Oui, les modèles de processus hybrides Waterfall, Spiral, Itérative et autres sont tous viables, mais le changement est inévitable. Le processus ne concerne pas seulement la façon de gérer le changement, et (j’affirme que) le plus important facteur est votre degré de connaissance / compréhension du problème et la précision avec laquelle vous pouvez planifier et prédire.

Affirmer que "les deux méthodologies de développement de logiciels prédominantes sont la cascade et l'agilité" est dérisoire, car il existe un large éventail de processus de développement de logiciels, et de nombreuses entreprises synthétisent leur propre version du modèle de processus, changeant souvent pour un projet donné. Il existe plus de deux approches viables pour le développement de logiciels. Bien que Waterfall et Agile aient tendance à tomber aux extrémités opposées du spectre du "changement", il est raisonnable de caractériser ces méthodologies concurrentes comme suit:

Waterfall dit: Le changement est coûteux, il devrait donc être minimisé.

Agile dit: Le changement est inévitable, alors faites en sorte que le changement soit bon marché.

Mais ce n'est pas toute l'histoire. Les entreprises doivent pouvoir planifier et prévoir, mais les logiciels sont un processus créatif et les estimations sont souvent fausses. Rappelez-vous le bon triangle - rapide - pas cher? Ajoutez une quatrième dimension, processus, et vous constaterez que la réduction des efforts de processus peut également comprimer le calendrier, lorsque les estimations se révèlent fausses et qu'un projet risque d'être retardé. Le logiciel est un processus fongible (modifiable) et Agile, Itératif, Spiral offrent tous la possibilité de fournir des fonctionnalités incrémentielles à des intervalles plus rapprochés.

Les modèles de processus basés sur Waterfall et sur d’autres exigences ont des contrôles pour gérer le changement. Il est donc inexact de dire que Waterfall minimise les changements, il est plus précis de dire que Waterfall reconnaît et gère les changements et communique l’impact de ces changements (car les changements ont un impact avoir des exigences et concevoir à l’avant). Lorsque vous créez un produit ou avez besoin de définir complètement les exigences (fonctionnalités), vous êtes amené à l'un des modèles hybrides.

Et lorsque les estimations sont fausses, le processus (la quatrième branche du triangle de fer) est souvent sacrifié pour respecter le calendrier.

ChuckCottrill
la source
Je n'étais pas hypocrite. Après cinq années de développement dans diverses entreprises, je n’en ai rencontré que deux, et l’une n’est qualifiée que de parjorative. Spirale? Jamais entendu parler.
Eric Wilson
Je voulais dire que je ne les avais pas rencontrés dans le monde réel. Toutes sortes de choses sont présentes sur les sites Web, mais je ne vais pas les chercher maintenant, simplement parce que je posais une question en 2010.
Eric Wilson
-1

Les approches agiles matures et en cascade sont indiscernables. Votre hypothèse concernant l'objectif de l'approche en cascade est incorrecte. Ils ont tous deux pour objectif de produire un logiciel de qualité. Lorsque vous ne disposez pas d'une approche de développement solide pour l'ensemble de la société , vous devez déterminer quelle approche générera le moins de friction possible lors de l'adoption. À la fin, des cycles de développement courts, une équipe d’assurance qualité solide et une entreprise qui pilote le développement sont les éléments les plus importants pour la production de logiciels de premier ordre.

Charles Lambert
la source
1
Je mettrais une réserve à votre commentaire. La cascade nécessite des personnes talentueuses ou elle tombera à plat ventre. Apprendre à bien concevoir est difficile. Apprendre à coder est relativement très facile. OMI, c'est la raison principale pour laquelle la plupart des développeurs semblent préférer l'agilité.
Dunk
4
Je peux dire la même chose de l'agile. Les développeurs Jr. sans conseils peuvent créer un désordre agile avec rapidité.
Charles Lambert