2nd/10_Wiki/Topic_Programming/Architecture/Dynamic Systems Development Method (DSDM).md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-dynamic-systems-development-meth	Dynamic Systems Development Method (DSDM)	10_Wiki/Topics	verified	self	DSDM Atern AgilePF	none	B	0.85	applied	agile methodology project-management architecture		2026-05-10	pending	language framework methodology agile

Dynamic Systems Development Method (DSDM)

매 한 줄

"매 fix the time/cost, flex the features". 1994년 UK consortium 의 RAD 의 evolution 의 develop, 매 원조 agile method (Agile Manifesto 2001 보다 7년 앞섬). 매 2026 의 매 niche — 매 SAFe / Scrum / Kanban 의 dominate, 매 DSDM 의 enterprise governance 의 좋은 reference.

매 핵심

매 8 Principles

1. Focus on the business need.
2. Deliver on time.
3. Collaborate.
4. Never compromise quality.
5. Build incrementally from firm foundations.
6. Develop iteratively.
7. Communicate continuously and clearly.
8. Demonstrate control.

매 MoSCoW Prioritization

• Must have — 매 minimum viable.
• Should have — 매 important 이지만 매 not vital.
• Could have — 매 nice-to-have.
• Won't have (this time) — 매 explicit out-of-scope.

매 Phases

1. Pre-project — feasibility approval.
2. Feasibility — high-level scope.
3. Foundations — business / solution / management approach.
4. Evolutionary Development — timeboxed iterations (2-6 weeks).
5. Deployment — release.
6. Post-project — benefits realization.

매 Roles

• Business Sponsor / Visionary / Ambassador — 매 business side.
• Technical Coordinator / Solution Developer / Tester — 매 dev side.
• Project Manager / Team Leader — 매 facilitation.

매 응용

1. Government / regulated projects — 매 audit trail required.
2. Fixed-deadline launches — 매 features 의 flex.
3. Hybrid waterfall→agile transitions.

💻 패턴

Pattern 1: MoSCoW backlog (JSON)

{
  "must": [
    {"id": "AUTH-1", "title": "User login", "effort": 5},
    {"id": "PAY-1", "title": "Stripe checkout", "effort": 8}
  ],
  "should": [
    {"id": "PAY-2", "title": "Saved payment methods", "effort": 5}
  ],
  "could": [
    {"id": "UI-1", "title": "Dark mode", "effort": 3}
  ],
  "wont": [
    {"id": "PAY-3", "title": "Cryptocurrency", "reason": "out of scope v1"}
  ]
}

Pattern 2: Timebox tracking

interface Timebox {
  id: string;
  name: string;
  startDate: Date;
  endDate: Date;        // 매 fixed
  must: Story[];        // 매 100% required
  should: Story[];      // 매 80% target
  could: Story[];       // 매 20-60% expected
}

function timeboxHealth(tb: Timebox): "green"|"amber"|"red" {
  const mustDone = tb.must.filter(s => s.status === "done").length / tb.must.length;
  if (mustDone < 0.5) return "red";
  if (mustDone < 1.0) return "amber";
  return "green";
}

Pattern 3: Facilitated Workshop agenda

# Foundations Workshop (Day 1)
09:00 — Business vision (Sponsor)
10:00 — Solution architecture sketch (Tech Coord)
11:00 — MoSCoW first pass (all)
13:00 — Risk / dependency mapping
15:00 — Timebox plan
16:30 — Commitment / sign-off

Pattern 4: Modeling — high level only

flowchart LR
  User[(User)] --> API
  API --> Auth
  API --> Order
  Order --> Payment[(Stripe)]
  Order --> DB[(Postgres)]

Pattern 5: Daily Stand-up (DSDM flavor)

Yesterday:    what advanced Must/Should items
Today:        which Must/Should items
Blockers:     escalate to Project Manager same day
Timebox burn: x days remaining / y stories left

매 결정 기준

상황	Approach
Fixed deadline (regulatory)	DSDM (timebox + MoSCoW)
Feature-driven product	Scrum
Continuous flow ops	Kanban
Large enterprise (>100 devs)	SAFe + DSDM principles
Modern startup	Scrum-ish or Shape Up

기본값: 매 Scrum 으로 시작, 매 fixed-deadline 시 DSDM MoSCoW 의 borrow.

🔗 Graph

• 부모: Agile
• 변형: Scrum · Extreme Programming (XP)
• 응용: Timeboxing

🤖 LLM 활용

언제: 매 enterprise / regulated agile 의 reference, 매 MoSCoW 의 prioritization. 언제 X: 매 modern product team — 매 Scrum / Shape Up 의 simpler.

❌ 안티패턴

• MoSCoW 의 abuse: 매 모두 Must — 매 prioritization 의 lost.
• Timebox 의 extend: 매 DSDM core 의 violate.
• Heavy documentation: 매 RAD 의 origin 의 betray.
• No business presence: 매 Ambassador role 의 essential.

🧪 검증 / 중복

• Verified (DSDM Consortium / Agile Business Consortium handbook, ISO/IEC TR 29110).
• 신뢰도 B (매 niche method, 매 modern usage 의 limited).

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 8 principles + MoSCoW + timebox