methodatlas
Vergleich

Methoden Seite an Seite ansehen.

Wähle bis zu vier Methoden. Ergänze sie über die Suche und teile den Vergleich über seinen Link.

Kriterium
Papierillustration einer Polarity Map mit zwei Polen und vier Quadranten
Systems Thinking
Polarity Mapping
Papierillustration einer IBIS-Karte aus Fragen, Positionen und Argumenten
Knowledge Modeling
IBIS
Papierillustration von Request for Comments (RFC) mit dem methodenspezifischen Arbeitsmodell.
Architecture
Request for Comments
Papierillustration: Szenarien und Architekturentscheidungen sind mit den erkannten Risiken verbunden.
Architecture
ATAM (Architecture Tradeoff Analysis Method)
Zweckunterschiedlich
Polarity Mapping macht Spannungen zwischen zwei gegensätzlichen Polen greifbar, etwa Standardisierung und Anpassung oder Kontrolle und Autonomie. Die Methode schützt davor, scheinbare Entweder-oder-Entscheidungen vorschnell zu treffen.IBIS strukturiert Denken über komplexe Fragen als Folge von Issues, Ideas und Arguments. Die Methode hält Diskussionen offen, ohne sie in vorschnellen Konsens zu drücken.Ein RFC hält größere Architektur- oder Produktänderungen als prüfbaren Vorschlag fest. Die Methode schafft einen transparenten Weg von Motivation über Alternativen bis zur Entscheidung.ATAM hilft, Architekturentscheidungen bei konkurrierenden Qualitätszielen abzuwägen. Dazu betrachtet das Team Geschäftsziele, Erwartungen der Beteiligten und technische Entscheidungen gemeinsam. Die Bewertung zeigt, welche Risiken weiter untersucht werden sollten.
Komplexitätunterschiedlich
MittelMittelMittelHoch
Zeitunterschiedlich
1-2 h1-3 h1-3 Wochen vom Draft bis zur EntscheidungMehrere Termine plus Vorbereitung und Analyse; Gesamtaufwand fallabhängig
Teilnehmendeunterschiedlich
3-122-83-20 ReviewerBewertungsteam, Architekturverantwortliche und relevante Stakeholder
Formatunterschiedlich
WorkshopWorkshop + AsyncAsyncWorkshop + Async
Outputunterschiedlich
Polarity Map, Warning Signs, Balance ActionsIssue Map, Positions, Argument NotesRFC-Dokument, Reviewer-Kommentare, Entscheidung mit Begründung, Folge-ADR oder TicketsPriorisierte Qualitätsszenarien im Utility Tree, Architekturrisiken mit Begründungen und Annahmen, Sensitivitätspunkte und Trade-off-Punkte, Ergebnisbericht mit offenen Untersuchungen
Tagskeine Überschneidung
SystemdenkenZielkonflikteFührung
BegründungWissenEntscheidung
ArchitekturEntscheidungAsynchronGovernance
ArchitekturQualitätRisikoZielkonflikteStakeholder
Weitere Methoden hinzufügen