Имена в вашем списке не все методологии, и они масштабируются на разных уровнях:
- Итеративный является характеристикой, чертой, разделяемой несколькими методами и техниками. Скрам - это итеративная методология, TDD - итеративная методика.
- Я вижу Agile как методологическую надстройку, которая остается на концептуальном / философском уровне. В объектно-ориентированном программировании вы можете описать его как абстрактный - это набор ценностей и принципов, которые не могут быть созданы и должны быть получены и реализованы. Это то, что делают Scrum и XP.
- Чистая комната, RAD, RUP, Спираль, Водопад, XP, Lean, Scrum, V-Model являются правильными методологиями, то есть процессами разработки программного обеспечения (хотя Scrum утверждает, что является легкой «структурой» в отличие от тяжелого процесса)
- Прототипирование и TDD - это техники, действия. TDD - это практика XP.
Различение, основа которого - трудная работа. Очевидно, что вы можете провести историческую линию, но методология редко напрямую основана на другой. Они скорее пересекаются, заимствуют друг у друга, иногда отвечают друг другу ... Я не вижу четко определенной классификации, хотя вы, вероятно, могли бы выделить несколько больших семей.
Еще один способ взглянуть на это с точки зрения поколения. Что касается корпоративного программного обеспечения, я бы сказал, что мы знаем 2 поколения методологий. Первыми, среди которых Waterfall и V-Model, были в основном уже существующие процессы из других инженерных дисциплин, применяемых к программному обеспечению. Второе поколение (его можно назвать Agile, но оно началось задолго до того, как появился термин Agile) было инициировано в ответ на тяжесть процессов первого поколения, когда люди начали понимать, что программное обеспечение было совершенно другим животным и что критерии, которые делают его хорошим программное обеспечение и шаги, которые могут гарантировать, что эти критерии были действительно конкретными и все еще должны быть изучены.
Наконец, вы должны заметить, что в программном обеспечении может быть даже больше, чем в других дисциплинах, методологии не являются рецептами, которые вы можете просто применить, чтобы заставить вещи работать. Разработка программного обеспечения имеет столько же человеческих аспектов, сколько технических аспектов, и команда или менеджер, разрабатывающие методологию «серебряной пули» и контрольный список вещей, которые нужно слепо применять, могут ожидать некоторых сюрпризов. Просто взглянув на исследования показателей успешности программных проектов, таких как Отчет о хаосе год за годом, вы можете сказать, что история методологий программного обеспечения больше связана с серией неудачных попыток, чем с правилом надежных, научно обоснованных, воспроизводимых процессов.