Méthodologie agile: rapide et sale ou planifier en premier?

Question agile: est-ce que l'agile croit qu'il faut faire fonctionner les choses de la manière «rapide et sale» - ou est-ce que l'agile préfère construire solidement à partir de zéro? Ou n'est-ce pas une question de méthodologie, et plus une question que vous évaluez au cas par cas?

Je suis en train de "refaire" techniquement les fondations du système, après avoir déjà construit une grande partie de la structure elle-même ... ce n'est pas une quantité monumentale de travail ... aurait agile aurait voulu que je spécifie tout le flux d'abord, l'analyser, peaufiner, puis construire? J'ai l'impression que c'est mieux comme ça ... une fois que j'ai mis en place un système en désordre, je vois mieux comment cela doit être fait ... d'un autre côté, il n'est pas si organisé ... juste curieux de savoir quel meilleur développement la pratique est à cet égard.

Je crois que cette question est quelque peu différente d' Agile et de protyping car je ne pose pas de question sur le prototypage et le code jetable; Je suis intéressé par l'agile pour le code de production.

La méthodologie agile est planifiée en premier. Ce n'est tout simplement pas tout planifier en premier. En fait, vous rassemblez les exigences, la conception, le code, le test, le déploiement et la présentation. Vous faites tout cela en moins de quinze jours (donner ou prendre) sur la toute petite fonctionnalité que vous pouvez déployer et obtenir des commentaires. Ensuite, vous recommencez en ajoutant une autre fonctionnalité ou en ajustant une ancienne.

La clé est d'écrire du code qui accepte le changement de sorte que lorsque vous voyez enfin "comment tout le flux doit se passer", vous pouvez changer le code pour le faire. De cette façon, quand "la façon dont le flux devrait aller" (ou quoi que ce soit) change à nouveau, ce n'est pas traumatisant.

Vous ne pouvez pas écrire rapidement et sale. Rapide et sale vous donne du code ridgid. Soyez rapide en travaillant petit. Restez flexible en ne diffusant pas de connaissances . Idéalement, tout changement de fonctionnalité unique devrait avoir un impact sur un seul endroit dans le code.

Vous ne pouvez pas passer des tonnes de temps à ne rien faire d'autre qu'à planifier. Vous pouvez planifier, mais vous devez être en mesure de modifier le plan. Vous devez découvrir rapidement les raisons de modifier le plan. Lorsque la planification se déroule sans heurts, sans surprise, c'est lorsque la planification dure trop longtemps. La planification et le codage doivent se faire à proximité les uns des autres. Si vous apprenez, plus le plan est ancien, plus il est stupide.

À long terme, vous devez prévoir de devenir plus intelligent. Écrivez un code flexible. Ensuite, devenir plus intelligent ne mène pas au regret.

Je n'aime pas que pour la plupart des gens, ce soit "rapide et sale" ou "grand design d'avance". Ils ne considèrent même pas qu'il existe d'autres options.

Agile consiste à construire un système, où le changement, même tard dans le développement, est insignifiant. Cela se fait en construisant le logiciel en petits morceaux incrémentiels et en bloquant le comportement de ces morceaux avec des tests automatisés robustes. Et en utilisant un déploiement automatisé fréquent en production pour valider la valeur de ces changements.

En ayant des tests automatisés robustes, il devient trivial de changer même les parties les plus difficiles de l'architecture, en effectuant un refactoring incrémentiel sur de plus longues périodes. Donc, même si vous réalisez que votre architecture pourrait être améliorée à mi-parcours du projet, il est réaliste de faire le changement relativement rapidement.

Certaines personnes disent que «un peu de design à l'avance» est bon avec l'agilité. Mais si vous avez l'intention de répéter cette conception par la suite, vous devez toujours vous assurer que votre culture de développement produit un système facile à changer. Ainsi, "SDUF" n'invalide pas la nécessité de tests robustes, d'une refactorisation agressive et d'un déploiement continu.

En intégrant la «facilité de changement» dans le système, vous n'avez pas besoin de réfléchir sérieusement à la conception initiale de votre projet, car cela peut être modifié ultérieurement. L'approche «rapide et sale», la plupart des gens l'appellent «pic», n'est utilisable que si vous stabilisez les fonctionnalités que vous trouvez précieuses. Mais vous ne devez pas laisser trop longtemps des morceaux de code piraté dans votre base de code, car ils ralentissent le changement.

Ni.

C'est "Commencez simplement et améliorez pendant que vous avancez".

Rapide et sale est fragile, mais rapide (si le projet est suffisamment petit et de courte durée).

Le plan est d' abord rigide, mais stable (si le projet se termine avant de rencontrer des contraintes financières ou temporelles).

Agile est une alternative aux 2 ci-dessus. Il s'appuie sur une approche itérative où les fonctionnalités sont terminées une par une, fonctionnalité par fonctionnalité, et les connaissances acquises lors de l'achèvement de ces éléments entièrement fonctionnels du programme sont utilisées pour étoffer et ajuster le plan au fur et à mesure du développement. Pour ce faire, il faut planifier à l'avance - vous avez besoin d'au moins suffisamment de planification pour pouvoir estimer la quantité de travail requise par les fonctionnalités individuelles - mais comme Agile s'attend à des changements, une planification excessive entraîne des pertes.

L'une des principales caractéristiques d'Agile est de faire de courtes itérations puis de réévaluer. Vous allez de l'avant pour explorer de nouveaux territoires, en tirer des leçons, puis faire un plan. De cette façon, votre plan sera meilleur. Et si vous échouez (trouvez que votre idée de cours ne fonctionne pas), vous aurez "échoué rapidement", ce qui est bien.

Votre approche est donc très bien. Mais le danger est alors de dire "Nice, ça marche, j'ai fini. Et ensuite?". Vous n'avez pas terminé, il y a beaucoup de recoins à redresser et vous devriez prendre / prendre le temps de le faire correctement une fois qu'il est clair que votre approche donne un système fonctionnel et fonctionnel. Cela pourrait être d'écrire des tests, de documenter, de StyleCop, d'optimiser, d'éduquer vos collègues sur ce que vous avez fait et comment vous l'avez fait, de le faire réviser, etc.

Pour compléter les réponses ci-dessus, un principe clé est YAGNI . Si votre conception et votre planification initiales permettent l'étape suivante, alors tout va bien. Mais si cela permet une étape future hypothétique dont vous ne pouvez pas prouver la nécessité, alors supposez YAGNI.

Une grande partie de la conception, de haut en bas et de bas en haut, suppose qu'il y aura une réutilisation importante du code. L'expérience montre que la réutilisation du code n'est tout simplement pas courante, car vous résolvez rarement exactement le même problème. Si vous devez résoudre une variante de ce problème à l'avenir, refactorisez votre conception à l'avenir pour ajouter cette variante, mais ne la considérez pas pour le moment.

En d'autres termes, planifiez la tâche immédiate, mais ne planifiez rien de plus.