Qu'est-ce que la méthodologie agile? [fermé]

Quelqu'un peut-il expliquer la méthodologie agile en phrases simples?

Agile, c'est beaucoup de choses et de pratiques, mais je pense que l'essentiel est juste un développement itératif.

Itératif: pensez à un tas de très petites cascades. Autrement dit, la méthode de la cascade (exigences-> spécifications-> code-> test), mais au lieu de le faire au cours d'une année ou plus, vous le faites au cours de quelques semaines pour une partie gérable de l'ensemble projet. À la fin de «itération / sprint / incrément», vous disposez d'un ensemble restreint mais complet et testé de fonctionnalités supplémentaires.

Cela vous permet de changer rapidement le cours du projet s'il s'avère que ce que vous faites n'est pas ce que le client veut, ou si les besoins de l'entreprise changent, ou quoi que ce soit. D'où le terme «agile».

Je pense que rien ne le met mieux que le Manifeste Agile lui-même:

Nous découvrons de meilleures façons de développer des
logiciels en le faisant et en aidant les autres à le faire.
Grâce à ce travail, nous avons pris de la valeur:

Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration avec le client sur la négociation des contrats
Répondre au changement en suivant un plan

Autrement dit, bien qu'il y ait de la valeur dans les éléments de
droite, nous valorisons davantage les éléments de gauche.

depuis http://agilemanifesto.org/

Pour moi, l'idée la plus importante est la suivante:

Des changements d'exigences vont se produire parce que nous sommes obligés de concevoir un logiciel au nadir de la connaissance de ce qui est nécessaire (le début du projet) et les exigences ne deviendront plus claires au cours du projet.

Les approches traditionnelles (cascade) tentent d'atténuer ce changement en enfermant tout le monde dans un contrat au début du projet en les faisant approuver sur des spécifications complètes. Cela peut fonctionner en tant qu'ACY, mais cela ne rend personne heureux de livrer quelque chose qui ne répond pas aux besoins des utilisateurs, surtout si leurs objections sont satisfaites par "Eh bien, vous avez signé!"

Les méthodes agiles sont conçues pour accepter les changements inévitables au lieu de les protéger de l'équipe de développement. Il le fait de plusieurs manières, dont la principale est le développement itératif et la participation continue des parties prenantes au processus. D'après mon expérience, cela laisse tout le monde plus heureux à la fin, même si cela peut être plus inconfortable pour certains types de gestion qui sont des planificateurs inconditionnels.

En une phrase, cela ressemble à ceci:

Le développement logiciel agile est un groupe de méthodologies de développement logiciel basées sur le développement itératif et incrémentiel , où les exigences et les solutions évoluent grâce à la collaboration entre des équipes auto-organisées et interfonctionnelles .

Cela vient de la définition de wikipedia, et je l'aime beaucoup. J'ai souligné les principes fondamentaux.

Je voudrais également ajouter ce que l'Agile n'est PAS. Il y a beaucoup de magasins qui prétendent être Agiles mais d'une manière qui signifie simplement qu'ils ne sont pas intéressés par la planification de leurs projets et s'attendent à ce que les choses se fassent dans un laps de temps déraisonnablement court.

Agile! = Pas de plan de projet. Il est difficile de gérer les personnes qui pensent implicitement que cette déclaration est fausse car elles ont tendance à être de type gestion et pas toujours faciles à contredire.

Andy s'est déjà lié au Manifeste Agile, que je pense à peu près couvrir.

Je pense qu'il est utile de regarder d'où vient le Manifeste Agile. Il y avait un certain nombre de méthodologies qui avaient des éléments communs et beaucoup de motivations similaires: Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming (liste d' Alistair Cockburn ). Les personnes proposant ces méthodologies ont décidé de trouver un terme de marketing pour couvrir les choses qu'elles avaient en commun afin que la force de ce qu'elles disaient soit renforcée.

Fait intéressant (selon ce que quelqu'un m'a dit), il y avait un certain nombre de noms sur la liste restreinte qui auraient pu être choisis au lieu de "Agile" - dont l'un était "Adaptatif". Personnellement, je pense que comme un seul mot qui résume mieux ce qu'est vraiment agile, c'est mieux que "agile"!

L'utilisation d'une méthodologie agile revient à mettre l'accent sur la livraison de produits de qualité par rapport à d'autres aspects du développement de produits et à réaliser que les commentaires de la communauté des utilisateurs sont un élément essentiel de la création de produits de qualité.

Comparez cela avec une approche de développement traditionnelle / en cascade qui met l'accent sur la conception, la documentation et la définition d'interface initiales tout en minimisant la mise en œuvre et la transition du produit du développement à la sortie.

À mon avis, il y a une qualité intrinsèque qu'une équipe peut intégrer dans un produit, je vois cela sous la forme de vérifier qu'un produit fonctionne comme l'équipe de développement le souhaitait et peut raisonnablement s'adapter aux améliorations prévisibles. Il existe également des facteurs de qualité entièrement basés sur la perception qui mesurent dans quelle mesure un produit répond aux besoins de ses utilisateurs.

Les approches agiles ont tendance à fournir des produits de manière itérative , intégrant les commentaires des utilisateurs et des développeurs à chaque itération, et favorisent la fourniture de chaque incrément de fonctionnalité lorsqu'elle atteint la viabilité minimale en tant que fonction de forçage pour obtenir des commentaires fréquents des utilisateurs et contrecarrer la tendance des activités de développement à se poursuivre. de longues périodes sans rétroaction de ses utilisateurs. À mon avis, d'autres aspects d'une approche agile tendent à soutenir ces principes clés.

• Mettre l'accent sur la collaboration fréquente avec les clients génère des commentaires des utilisateurs tout en restant flexible aux changements des exigences permet au développement de produits d'intégrer régulièrement ces commentaires
• L'intégration fréquente dans les configurations et les environnements de déploiement pertinents va de pair avec l'identification continue des configurations et des environnements qui restent pertinents afin de garantir que le produit reste valable et pertinent pour les utilisateurs fournissant des commentaires.
• L'auto-organisation et la promotion d'équipes interfonctionnelles permettent de créer une responsabilité personnelle au sein de l'équipe et de permettre à l'équipe de déterminer la meilleure façon de supprimer les obstacles de manière efficace sans être freiné par des rôles préétablis et une hiérarchie de gestion au sein de l'équipe