Agile Mythes et les idées fausses

Question

Quels sont les mythes ou idées fausses relatives à l'Agile?

Il y a beaucoup d'idées fausses relatives à l'Agile qu'un moyen nouveau venu peut tomber. Quelles sont les idées fausses dans la méthode Agile monde et comment justifiez-vous que c'est vraiment une idée fausse?

---

Mise à jour: Résumé de l'Agile Mythes

• Agile ne permet pas de documentation
• Les méthodes agiles ne sont pas à l'échelle
• Agile signifie pas de plan
• TDD couvre tous les besoins tests unitaires
• La programmation en binôme est toujours plus facile de code
• Agile est une solution miracle pour logiciel des problèmes d'ingénierie (Il y a une solution miracle)
• Agile n'a pas besoin de up avant la conception
• Nous faisons de la mêlée, donc nous n'avons pas besoin de faire TDD, Refactoring Paire de Programmation, etc.
• On peut apprendre Agile à partir d'un livre
• Agile ne fonctionne que pour trivial projets
• Agile utilise toujours des "User Stories"

Lire les réponses suivantes pour plus d'informations sur les mythes ci-dessus et pour plus de mythes.

Answer 1

"Le logiciel de travail plus exhaustif de la documentation" signifie que vous n'avez pas besoin d'une spécification fonctionnelle...

Faux!!! Il signifie simplement que vous pouvez repasser les rides de manière itérative avec les utilisateurs de la langue en tant que vendeur, vous avez encore besoin d'une bonne documentation pour aider avec l'assurance de la qualité et la signature des phases...

Answer 2

1. "Nous faisons de Mêlée, donc nous n'avons pas besoin d' (paire | refactor | ne ATS | ...)" en Fait la Mêlée fondateurs - Ken et Jeff ont dit que tous les haut de la productivité de mêlée, les équipes mettent en place la gamme complète des pratiques de l'Extreme Programming.

2. Développement piloté par les tests ne trouverez pas tous les bugs / n'est pas facile à appliquer à tout - donc, nous n'allons pas essayer! - L'apprentissage TDD n'est pas un "tout ou rien" et vous obtenez mieux à même de juger ce qu'il faut tester et comment le faire efficacement. J'ai fait ça pendant dix ans maintenant et je suis toujours à trouver de meilleures façons de le faire et de nouvelles choses à considérer.

3. Je peux apprendre tout ce que je besoin d'appliquer des méthodes agiles à partir d'un livre. - Vous avez besoin d'apprendre par la pratique et que, souvent, les moyens de coaching et de rencontrer d'autres personnes qui peuvent les aider. Beaucoup de choses vont mal quand les gens essaient d'apprendre à partir d'un livre.

4. Hystérique (et tout à fait réel) ", Le candidat doit prendre la direction de, et de soutenir le scrum master" (à Partir d'un travail spec, j'ai été envoyé la semaine dernière...) - Le scrum master n'est pas censé dire aux gens quoi faire. Il/Elle est là pour faciliter - par exemple, pour aider l'équipe à apprendre à trier les choses eux-mêmes. C'est un énorme échec de la mode - avoir un scrum master qui "commandes" les gens!

5. Parler de "la méthodologie agile" - grande incompétence de l'indicateur. Tout d'abord, parler de "agile" comme c'est une chose en particulier alors que c'est un très vague termes génériques pour beaucoup de choses différentes. Deuxièmement, l'utilisation de "la" méthode agile - il y a des tas d'entre eux, et des tas de façons différentes de faire de nombreux d'entre eux! Troisièmement, beaucoup de gens dans la communauté agile eu ici dans la réaction contre les gros, lourds, UML-laden méthodes des années nonante. Ces gens n'ont pas tendance à utiliser le mot "méthode"...

6. Vous avez besoin, en particulier, des personnes de talent pour développer des logiciels en mode agile. Jeff Sutherland dit qu'ils ont considéré à l'aide de la "chef programmeur de l'équipe de" modèle pour la gestion des équipes dans les banques - mais a constaté qu'ils n'ont pas quelque chose comme assez "chefs". Scrum est conçu pour obtenir la meilleure productivité de beaucoup de modérément en mesure de programmeurs. En fait, la suppression de l'une, de manière disproportionnée productif membre de l'équipe qui ne veut pas aider les autres peut "débloquer" la médiocrité des membres de l'équipe et apporter leurs combinés de la productivité jusqu'à plus que compenser pour le super-productif ancien membre de l'équipe... c'est ce Que Jeff dit de toute façon...

Il y a pas mal d'autres XP liés à ceux que nous avons eu dans un espace ouvert de l'atelier que j'ai donné récemment: http://xpday-london.editme.com/WhereHasXpGone

Answer 3

Mythe: en utilisant les pratiques de développement Agile est une solution miracle pour logiciel des problèmes d'ingénierie.

Answer 4

Mythe: le Test-d'abord le développement des forces de votre projet, afin de disposer de tests unitaires.

Fait: de Nombreux développeurs de devenir paresseux, et les tests unitaires, ils écrivent avant de leur code sont souvent faibles et insuffisantes.

Mythe: la programmation en binôme est toujours plus facile de code.

Fait: les Programmeurs ont tendance à être légèrement anti-sociaux, et ont significativement différents processus de pensée de l'un à l'autre. Avoir quelqu'un respirer en bas de votre cou comme vous le code est très désagréable, et le résultat est souvent une ambiance de travail tendue, avec une réduction à la fois de la qualité du code et la quantité.

Answer 5

Mythe: Agile signifie pas de documentation

Fait: Agile valeur des logiciels fonctionnant plus qu'une documentation exhaustive, mais cela ne signifie pas l'absence de documentation. La Documentation doit être écrit juste à temps, et juste assez. Et non, Agile ne veut pas dire que l'on devrait toujours utiliser les user stories. Utilisez-les si, et seulement si elles sont appropriées!

Mythe: Agile signifie pas de plan

Fait: Agile ne prend pas en charge le développement, sans planification. Agile utilise en continu de la planification et de l'estimation des coûts et maximiser le retour sur investissement. En fait, Agile est au sujet de la portée de la gestion.

Mythe: Agile signifie pas de discipline

Fait: Agile, les développeurs doivent être plus discipliné pour le succès.

Mythe: Agile ne fonctionne que pour trivial projets

Fait: Agile (en fait Scrum ici) a été utilisé pour

• Approuvé par la FDA, la vie de logiciels critiques pour les rayons x et Irm,
• Financière des applications de paiement,
• 24x7 avec 99.99999% des exigences de disponibilité,
• Plusieurs téraoctets applications de base de données,
• etc

Mythe: Agile n'est pas à l'échelle

Fait: Sutherland utilisé Mêlée dans les groupes de+ de 500, Cohn utilisé Mêlée dans les groupes de+de 100