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

27

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

Chankey Pathak
la source
3
selon mon professeur CompSci au collège, "méthode de la cascade, juste plus vite"
Malfist
11
@Malfist espérons qu'il / elle reste dans le milieu universitaire, où les dommages sont limités au cerveau ;-)
Steven A. Lowe
@Steven A. Lowe, ce qui est triste, c'est que le troisième chapitre de notre manuel est "Développement logiciel agile" et il n'a toujours aucune idée de ce que c'est.
Malfist
2
@Malfist Je me trouvais sur un grand campus universitaire dans une grande ville au milieu des années 1990, et je me suis promené pour parler avec le doyen de CS. Il se trouvait qu'il était d'humeur bavarde, alors nous avons parlé un peu de l'état de l'art et de la façon dont cela se reflétait dans le programme d'études du collège. Il m'a dit que "la programmation orientée objet n'est qu'une mode, nous ne l'enseignons pas ici". Très triste.
Steven A. Lowe
1
La méthodologie agile est comme la langue chinoise - vous ne la comprenez pas avant de l'avoir apprise;)
Job

Réponses:

22

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».

Fishtoaster
la source
Ce n'est vraiment pas la bonne réponse. Agile n'est pas une méthodologie, c'est une philosophie.
RibaldEddie
32

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/

Andy Lowry
la source
1
Le seul problème est qu'à moins que vous n'ayez vu un mauvais processus, le manifeste ne se rend tout simplement pas justice. Il faut une comparaison avec le mal pour vraiment savoir ce que dit le manifeste. Pourtant, +1 parce que trop de gens confondent agile et Scrum ces jours-ci. Et même alors, ils confondent SCRUM avec Scrum + XP.
MIA
2
Cependant, l'agilité peut parfois se contredire. Fondamentalement, "nous apprécions la flexibilité mais nous dévaluons les outils et les processus nécessaires pour obtenir cette flexibilité". De bons outils flexibles sont absolument essentiels pour répondre au changement. Par exemple, les migrations Ruby-on-Rails contre le système ORM semi-cuit maison de quelqu'un qui pourrait nécessiter une semaine pour apporter un changement simple au modèle de données.
user8865
2
Vous vous demandez simplement comment «individus et interactions» pourraient remplacer «processus et outils» ou comment «un logiciel fonctionnel pourrait-il être contre une documentation complète»? Ce sont toutes des choses différentes ... Peu importe, je ne suis pas tombé amoureux d'Agile et je suppose que je ne le serai pas.
NoChance
13

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.

JohnFx
la source
6

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.


la source
3

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.

q303
la source
Depuis que j'ai posé la question jusqu'à ce jour, je fais partie de certaines de ces sociétés et je suis d'accord avec vous.
Chankey Pathak
D'accord. Beaucoup de personnes agiles ne sont qu'un moyen peu coûteux de faire les choses.
SmallChess
2

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"!

FinnNk
la source
2

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
deaks
la source