Ngôn ngữ • Language
- VI
- EN
Feature-Driven Development (FDD)
FDD là một framework Agile phù hợp cho dự án lớn và team đông: chia việc theo feature, có mô hình tổng thể rõ ràng, rồi lập kế hoạch → thiết kế → xây dựng theo từng feature để giao hàng nhanh.
TL;DR – FDD trong 1 phút
- FDD (Feature-Driven Development) là Agile nhưng có cấu trúc, thường được mô tả là model-driven (làm rõ domain/model để giảm hiểu sai và rework).
- Trọng tâm: xây dựng feature list và delivery theo feature.
- Kết hợp incremental + iterative: chia nhỏ, làm theo vòng lặp ngắn, giao từng phần có giá trị.
- 5 tiến trình cốt lõi:
- Develop an Overall Model
- Build a Feature List
- Plan by Feature
- Design by Feature
- Build by Feature
- Phù hợp nhất khi: dự án phức tạp, nhiều module, nhiều người, cần predictability và kỷ luật thiết kế.
- Không phù hợp khi: team nhỏ, MVP giai đoạn đầu, bài toán quá mới cần thử nghiệm liên tục.
Nếu đề nhấn mạnh “large/complex project + need structure + delivery by features”, kèm các cụm như overall model, plan/design/build by feature → nghĩ đến FDD.
1) FDD là gì?
Feature-Driven Development (FDD) là một phương pháp Agile “định hướng theo feature”: sản phẩm được phát triển bằng cách thiết kế và xây dựng từng feature nhỏ — mỗi feature là một “kết quả hữu ích” mà khách hàng đánh giá là có giá trị.
PMI-safe wording: FDD là customer-centric (ưu tiên giá trị khách hàng), đồng thời mang tính model-driven (có bước làm rõ domain/model để tạo nền tảng cho delivery).
So với Scrum/Kanban:
- Scrum cũng có “feature”, nhưng Scrum nhấn cadence (Sprint) và empiricism (inspect & adapt).
- FDD nhấn mạnh cấu trúc: model tổng thể, feature list theo domain, và ownership rõ để quản trị dự án lớn.
2) “Feature” trong FDD nghĩa là gì?
Trong FDD, feature là một kết quả nhỏ, hữu ích, và được khách hàng đánh giá có giá trị.
Ví dụ nhanh:
- “Tính tổng tiền hoá đơn” (calculate invoice total)
- “Tạo hoá đơn / tạo đơn mua hàng” (create invoice / purchase order)
- “Gửi biên nhận bán hàng” (send sales receipt)
- CRM: “Nhập lead tiềm năng vào hệ thống” (capture a lead)
Khi làm dự án lớn (ví dụ e-commerce), bạn sẽ có một feature list rất dài, rồi nhóm feature theo subject areas (nhóm chủ đề/domain) để quản trị.
3) 5 tiến trình chính của FDD
FDD có 5 tiến trình “xếp lớp” — bước sau dựa trên nền tảng của bước trước (cấu trúc rõ ràng nhưng vẫn Agile).
3.1 Develop an Overall Model – Phát triển mô hình tổng thể
- Làm rõ domain: chúng ta đang xây cái gì, ranh giới hệ thống là gì?
- Tổ chức workshop với domain experts (chuyên gia nghiệp vụ).
- Tạo “bức tranh chung” để các nhóm làm cùng hướng, giảm hiểu sai và giảm rework.
3.2 Build a Feature List – Xây dựng danh sách feature
- Chuyển mô hình/domain thành danh sách feature có thể triển khai.
- Nhóm feature theo subject areas (checkout, catalog, payment, tax...).
- Làm rõ value của từng feature (feature nào tạo giá trị, cho ai, khi nào cần).
3.3 Plan by Feature – Lập kế hoạch theo feature
- Lập lịch triển khai feature theo thứ tự giá trị/phụ thuộc.
- Gán ownership rõ ràng để theo dõi tiến độ.
- Tạo predictability cho dự án lớn (điều mà team đông rất cần).
3.4 Design by Feature – Thiết kế theo feature
- Nhóm nhỏ tạo thiết kế chi tiết cho feature (luồng xử lý, cấu trúc code, thứ tự thực hiện).
- Thiết kế bám theo overall model để tránh “mỗi người một kiểu”.
3.5 Build by Feature – Xây dựng theo feature
- Code → test → integrate cho feature.
- Feature thường hoàn thành theo short iterations (thường ~2 tuần, có thể điều chỉnh).
- Mục tiêu: deliver working software đều đặn để nhận feedback sớm.
4) Roles & Ownership: vì sao FDD hợp dự án lớn?
Điểm mạnh của FDD là ownership rõ để giảm “hỗn loạn phối hợp” khi team đông. Một số thuật ngữ có thể gặp (không cần nhớ chi tiết vai trò để làm PMI-ACP, nhưng cần hiểu ý):
- Chief Programmer: dẫn dắt kỹ thuật/thiết kế ở mức feature/module.
- Class Owner: chịu trách nhiệm cho một phần code/class/module cụ thể.
PMI-ACP note: Nếu đề mô tả “gán ownership cho class/module để track progress” hoặc “team lớn cần cấu trúc thiết kế mạnh” → rất khớp FDD.
5) FDD phù hợp nhất khi nào? Không phù hợp khi nào?
5.1 Phù hợp
- Dự án lớn, phức tạp, nhiều domain/module.
- Team đông, cần structure để đồng bộ cách làm.
- Cần predictability và design discipline để giảm rework.
- Bài toán “đã có khuôn mẫu” tương đối (có domain model/kinh nghiệm sẵn để chuẩn hoá).
5.2 Không phù hợp
- Team nhỏ làm MVP giai đoạn đầu (cần thử nghiệm, pivot, học nhanh).
- Bài toán quá mới/thiếu mô hình tham chiếu (R&D nặng, thay đổi liên tục theo khám phá).
6) Exam tips & traps (PMI-ACP)
- “Large team + complex system + need structured approach” → FDD là ứng viên mạnh.
- “Upfront domain modeling + feature list + plan/design/build by feature” → signature của FDD.
- “Delivery nhanh” nhưng vẫn kỷ luật kỹ thuật (design/testing) → FDD phù hợp.
- Nhầm FDD với Scrum chỉ vì đều nói “feature”.
→ Scrum nhấn cadence + empiricism; FDD nhấn model + ownership + feature-centric processes. - Hiểu sai “model-driven” = “waterfall ”.
→ FDD vẫn incremental/iterative, vẫn giao từng phần có giá trị. - Dùng FDD cho MVP team nhỏ và yêu cầu pivot liên tục.
→ thường “nặng cấu trúc” hơn mức cần thiết.
7) Keyword map (VI ↔ EN)
| VI | EN (PMI-safe) | Ý nghĩa dùng trong đề |
|---|---|---|
| Feature | Feature | Kết quả nhỏ, có giá trị khách hàng |
| Mô hình tổng thể | Overall model | Nền tảng hiểu domain chung |
| Chuyên gia nghiệp vụ | Domain experts | Workshop để hiểu đúng bài toán |
| Danh sách feature | Feature list | Backlog theo feature (nhóm theo domain) |
| Lập kế hoạch theo feature | Plan by feature | Schedule + ownership |
| Thiết kế theo feature | Design by feature | Thiết kế chi tiết cho từng feature |
| Xây dựng theo feature | Build by feature | Code/test/integrate |
| Gia tăng | Incremental | Giao dần theo phần |
| Lặp | Iterative | Lặp vòng học–sửa–tối ưu |
| Định hướng mô hình | Model-driven | Domain/model foundation |
| Lấy khách hàng làm trung tâm | Customer-centric | Value do customer định nghĩa |
8) Checklist học nhanh
Checklist – Feature-Driven Development (FDD) (VI)
Mini-mock – Feature-Driven Development (FDD)
- FDD = feature-centric + structured + model-driven, hợp dự án lớn.
- Signature: overall model + feature list + plan/design/build by feature.
- Dùng đúng bối cảnh: team đông, phức tạp, cần kỷ luật thiết kế và predictability.
Feature-Driven Development (FDD)
FDD is an Agile framework that fits large, complex projects and larger teams: it organizes delivery around features, starts with a shared overall model, then plans → designs → builds feature by feature to deliver working software quickly.
TL;DR – FDD in 1 minute
- FDD (Feature-Driven Development) is Agile but more structured, often described as model-driven (clarify the domain/model to reduce misunderstanding and rework).
- Core focus: build a feature list and deliver by features.
- Combines incremental + iterative delivery: small chunks, short cycles, frequent value delivery.
- 5 core processes:
- Develop an Overall Model
- Build a Feature List
- Plan by Feature
- Design by Feature
- Build by Feature
- Best fit: large/complex systems, larger teams, strong need for predictability and design discipline.
- Not ideal: small teams, early-stage MVP work, or highly uncertain R&D-style problems.
If a scenario emphasizes “large/complex project + need structure + delivery by features” and mentions overall model or plan/design/build by feature → think FDD.
1) What is FDD?
Feature-Driven Development (FDD) is a feature-centric Agile approach: you deliver the product by designing and building small customer-valued features.
PMI-safe wording: FDD is customer-centric (value is defined by the customer), and often model-driven (establish a shared domain/model as a foundation).
Compared to Scrum/Kanban:
- Scrum can also deliver features, but it emphasizes cadence (Sprints) and empiricism (inspect & adapt).
- FDD emphasizes structure: an overall model, domain-based feature lists, and clear ownership to manage large efforts.
2) What is a “feature” in FDD?
In FDD, a feature is a small, useful result that the customer values.
Quick examples:
- Calculate invoice total
- Create an invoice / purchase order
- Send a sales receipt
- CRM: capture a lead into the system
On large programs (e.g., full e-commerce), you build a large feature list, then group features by subject areas (business domains) for manageability.
3) The 5 core processes of FDD
FDD uses five layered processes — each step builds on the previous one. It is structured, but still Agile.
3.1 Develop an Overall Model
- Clarify the domain: what are we building and where are the boundaries?
- Run workshops with domain experts.
- Create a shared “big picture” to reduce misunderstanding and rework.
3.2 Build a Feature List
- Translate the model/domain into implementable features.
- Group features by subject areas (catalog, checkout, payment, tax, etc.).
- Clarify each feature’s customer value.
3.3 Plan by Feature
- Create an implementation schedule for the feature list (value and dependencies).
- Assign clear ownership to track progress in large teams.
- Increase predictability — a key need on complex programs.
3.4 Design by Feature
- Small teams produce detailed designs for a feature (flow, code structure, sequence of tasks).
- Design stays consistent with the overall model to avoid fragmentation.
3.5 Build by Feature
- Code → test → integrate the feature.
- Features are typically built in short iterations (often ~2 weeks, adjustable).
- Goal: deliver working software frequently for early value and early feedback.
4) Roles & Ownership: why FDD fits large teams
A key strength of FDD is clear ownership, which reduces coordination chaos at scale. You may see role terms like:
- Chief Programmer: technical/design leadership for feature/module work.
- Class Owner: accountable for specific classes/modules.
PMI-ACP note: If a question highlights “assigning ownership to modules/classes to track progress” or “large team needs strong design structure” → that aligns well with FDD.
5) Where does FDD fit best? When is it not ideal?
5.1 Best fit
- Large, complex systems with multiple domains/modules.
- Larger teams that need structure for alignment.
- High need for predictability and design discipline to reduce rework.
- Problems with reasonably known patterns (domain models exist or can be stabilized).
5.2 Not ideal
- Small teams doing early-stage MVPs (heavy experimentation and pivots).
- Highly novel R&D problems with no stable model and frequent discovery-driven change.
6) Exam tips & traps (PMI-ACP)
- “Large team + complex system + need a structured approach” → FDD is a strong candidate.
- “Upfront domain modeling + feature list + plan/design/build by feature” → FDD signature.
- “Fast delivery with engineering discipline (design/testing)” → consistent with FDD.
- Confusing FDD with Scrum just because both talk about “features”.
→ Scrum emphasizes cadence + empiricism; FDD emphasizes model + ownership + feature-centric processes. - Thinking “model-driven” means “waterfall”.
→ FDD still delivers incrementally and iteratively. - Using FDD for a tiny MVP team that needs constant pivots.
→ often heavier structure than needed.
7) Keyword map (EN ↔ VI)
| EN (PMI-safe) | VI | Exam meaning |
|---|---|---|
| Feature | Feature | Small customer-valued result |
| Overall model | Mô hình tổng thể | Shared domain picture |
| Domain experts | Chuyên gia nghiệp vụ | Workshops to clarify domain |
| Feature list | Danh sách feature | Domain-based feature backlog |
| Plan by feature | Lập kế hoạch theo feature | Schedule + ownership |
| Design by feature | Thiết kế theo feature | Detailed feature design |
| Build by feature | Xây dựng theo feature | Code/test/integrate |
| Incremental | Gia tăng | Deliver in increments |
| Iterative | Lặp | Short cycles, learn & refine |
| Model-driven | Định hướng mô hình | Domain/model foundation |
| Customer-centric | Lấy khách hàng làm trung tâm | Value defined by customer |
8) Checklist & Mini-mock
Checklist – Feature-Driven Development (FDD) (EN)
Mini-mock – Feature-Driven Development (FDD)
- FDD = feature-centric + structured + model-driven, built for scale.
- Signature: overall model + feature list + plan/design/build by feature.
- Use it in the right context: large teams, complex domains, predictability, design discipline.