Cela fait-il de moi un mauvais programmeur si je n'aime pas la méthodologie Agile? [fermé]

10

J'aime les petites itérations. J'aime les tests unitaires. J'aime la révision du code. Ce que je n'aime pas, c'est le démarrage avec peu ou pas de documentation. Suis-je seul dans tout ça? Ai-je simplement une mauvaise compréhension du processus?

Toute réflexion sera apprécié.

agile documentation methodology

— Dan Appleyard
source

2

Tout d'abord, ne parlez pas de la méthodologie Agile. Le mouvement Agile est vraiment une philosophie de développement, qui encourage l'adoption d'une variété de pratiques et de méthodologies, le cas échéant.

— Eric Wilson

1

"avez une mauvaise compréhension du processus?" - oui

— vartec

2

"La méthodologie Agile qui doit être strictement suivie n'est pas une vraie méthodologie Agile"

1

Salut Dan, il ne semble pas y avoir de problème résoluble dans ta question, et des questions comme "Je pense / ressens X, les autres ressentent-ils la même chose?" ne sont pas sur le sujet ici . Si vous avez un problème spécifique pour lequel vous avez besoin d'aide, n'hésitez pas à poser des questions à ce sujet.

Tout le monde commence avec peu ou pas de documentation. La question est de savoir comment vous répartissez votre temps entre la documentation et le code - toute la documentation en premier? Ou seulement autant que nécessaire pour commencer?

— Carson63000

18

Rappelez-vous, Agile ne signifie pas aucune documentation, Agile signifie que vous comprenez que le "client" ne sait pas tout ce qu'il veut, donc il ne peut pas vous donner un document d'exigences énormes qui décrit tout. Agile préconise que vous parliez constamment au client et que vous disiez "Est-ce ce que vous voulez?" ou "Comment X fonctionnera-t-il lorsque Y arrivera?" ensemble, vous créez les exigences.

Cela dit, non, il n'y a rien de mal à vous si vous n'aimez pas une méthodologie particulière. La plupart des gens semblent choisir de toute façon divers aspects de différentes méthodologies.

— Wayne Molina
source

10

+1 Agile ne signifie pas aucune documentation . Les gens semblent penser que c'était Agile signifie; ce n'est pas. Il valorise les logiciels de travail par rapport à une documentation complète; il n'annule pas la valeur dans la documentation.

— Aaron McIver

10

La méthodologie Agile stipule que vous ne faites que ce dont vous avez besoin à ce moment-là. Si vous voulez / avez besoin de plus de documentation que ce qui est donné, alors c'est un problème avec le processus, et ce n'est pas vous. Il y a des moments où beaucoup de documentation est nécessaire pour que le projet continue. Ce n'est pas contraire à Agile d'en avoir besoin. Vous ne pouvez pas justifier de relâcher les exigences sous le couvert d'Agile. C'est en fait un gros problème que j'ai vu. Beaucoup de gens deviennent paresseux dès le départ et s'en remettent au processus. La vraie question doit être posée: "Les développeurs ont-ils ce dont ils ont besoin?" Si la réponse est non, alors plus de travail doit être fait.

Maintenant, cela peut être poussé à l'extrême, et quelqu'un peut dire: "Eh bien, je ne peux pas y travailler à moins que tout le programme ne soit documenté." Parfois, cela est vrai, mais l'équipe doit jeter un coup d'œil et voir si cela est vraiment nécessaire.

— kemiller2002
source

8

Je ne vois pas pourquoi cela ferait de vous un mauvais programmeur simplement parce que vous n'aimez pas une méthodologie particulière. Il peut être difficile pour vous de vous intégrer aux magasins qui le mettent en œuvre; cela étant dit, j'ai des doutes quant à l'efficacité de sa mise en œuvre partout.

Ce qui fait de vous un mauvais programmeur, c'est un mauvais code - facile je sais - mais vous pouvez aimer / être brillant dans toutes les méthodologies que vous aimez, et toujours être un mauvais programmeur parce que votre code n'est pas adéquat.

— temptar
source

3

L'idée de base d'Agile est qu'à moins d'avoir un don de précognition, vous ne pouvez pas prévoir un avenir lointain. Ainsi, vous ne pouvez pas documenter ce que vous ne pouvez pas prévoir.

Cela ne veut pas dire que vous n'avez aucune documentation. Vous documentez la conception technique des exigences actuelles (et bien sûr vous documentez les exigences elles-mêmes), et vous documentez l' implémentation actuelle . Vous n'êtes pas censé documenter à quoi ressemblera le système après 10 sprints supplémentaires, car vous vivez dans un monde dynamique, les exigences peuvent changer.

— vartec
source

2

Je pense que vous comprenez mal le processus. Quelle documentation souhaitez-vous? Avant de commencer, vous avez besoin d'une sorte d'objectif. Je commence par des cas d'utilisation que je recueille à partir de conversations avec mon client. Je ne passe pas des jours à faire des diagrammes fantaisistes. Nous parlons, puis j'écris une page Wiki, et nous passons en revue cela. Ensuite j'écris quelques tests. Ensuite, j'écris du code.

— Kevin Cline
source

2

Il existe une combinaison infinie de tailles d'équipe, de domaines, de langues, de personnalités, de budgets et d'exigences. Il n'y a pas de méthodologie unique adaptée à chaque situation. De même, beaucoup de gens ont des préférences et des styles personnels.

Même si vous ne l'aimez pas, cela vaut la peine d'essayer de nouvelles idées, analysez les résultats de manière critique. Il y a beaucoup de choses que je n'aime pas, mais après avoir essayé pendant un moment, apprendre à aimer. Comme les olives.

L'autre chose est que les modes changent régulièrement. J'ai grandi avec Waterfall, j'ai travaillé dans une équipe qui essayait de tout faire dans Rational Unified Process qui était la "meilleure chose" à l'époque. Bientôt, Agile sera remplacé par quelque chose de nouveau et de meilleur et personne ne mentionnera à nouveau le mot Agile.

Ne vous sentez donc pas obligé d'aimer une méthodologie comme Agile. (Personnellement, je n'aime pas ça) Cela ne fait pas de vous un mauvais programmeur.

— Richard
source