Nazwy na liście nie są metodologiami i są skalowane na różnych poziomach:
- Iteratywna jest cechą wspólną dla kilku metod i technik. Scrum to iteracyjna metodologia, TDD to technika iteracyjna.
- Widzę Agile jako nadzór metodologiczny, który pozostaje na poziomie konceptualnym / filozoficznym. W programowaniu obiektowym można to opisać jako abstrakcyjne - jest to zbiór wartości i zasad, których nie można utworzyć, a które trzeba wyprowadzić i zaimplementować. Tak właśnie robią Scrum i XP.
- Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model są odpowiednimi metodologiami, tj. Procesami tworzenia oprogramowania (chociaż Scrum twierdzi, że jest lekkim „szkieletem” w przeciwieństwie do ciężkiego procesu)
- Prototypowanie i TDD to techniki, działania. TDD to praktyka XP.
Wyróżnienie, które jest podstawą, jest trudną pracą. Oczywiście możesz narysować linię historyczną, ale metodologia rzadko opiera się bezpośrednio na innej. Raczej się pokrywają, pożyczają od siebie, czasem reagują na siebie ... Nie widzę jasno określonej klasyfikacji, choć prawdopodobnie można by zarysować kilka dużych rodzin.
Innym sposobem spojrzenia na to jest z perspektywy generacji. Jeśli chodzi o oprogramowanie dla przedsiębiorstw, powiedziałbym, że znamy 2 generacje metodologii. Pierwsze z nich, w tym Waterfall i V-Model, były w większości wcześniejszymi procesami z innych dziedzin inżynierii stosowanych w oprogramowaniu. Druga generacja (można ją nazwać Agile, ale rozpoczęła się na długo przed stworzeniem terminu Agile) została zainicjowana w reakcji na ciężkość procesów pierwszej generacji, kiedy ludzie zaczęli zdawać sobie sprawę, że oprogramowanie było zupełnie innym zwierzęciem i że kryteria, które spełniają oprogramowanie i kroki, które mogą zapewnić, że te kryteria były naprawdę konkretne i nadal wymagały zbadania.
Na koniec należy zauważyć, że w oprogramowaniu może nawet bardziej niż w innych dyscyplinach, metodologie nie są przepisami, które można po prostu zastosować, aby wszystko działało. Tworzenie oprogramowania ma tyle ludzkich aspektów, co aspekty techniczne, a zespół lub menedżer wymyślający srebrną kulę i listę kontrolną rzeczy, które ślepo stosować, mogą spodziewać się niespodzianek. Patrząc na badania dotyczące wskaźników powodzenia projektu oprogramowania, takie jak raport Chaos rok po roku, możesz stwierdzić, że historia metodologii oprogramowania ma więcej wspólnego z serią nieudanych prób niż reguła solidnych, naukowo potwierdzonych, powtarzalnych procesów.