BMAD Framework: Review Thực Tế Sau Khi Áp Dụng Vào Dự Án

Bạn đã thử dùng AI để code và nhận ra một vấn đề: AI làm nhanh thật, nhưng không ai trong team biết project đang đi về đâu. Document thì cũ, requirement thì mơ hồ, và mỗi lần đưa context cho AI lại mất thêm 20 phút giải thích lại từ đầu.

BMAD Framework sinh ra để giải quyết đúng chỗ đó. Dưới đây là review thực tế sau khi áp dụng vào các dự án tại TEDU — không phải tóm tắt tài liệu, mà là những điều thực sự hoạt động và những chỗ cần cân nhắc.

Lưu ý về tên: BMAD có hai cách diễn giải tên viết tắt được dùng song song trong cộng đồng — "Breakthrough Method for Agile AI-Driven Development" (phổ biến hơn) và tên gốc chính thức là "Build More Architect Dreams". Cả hai đều đúng.

BMAD Là Gì? Agile Nhưng Được Thiết Kế Cho AI Agent

BMAD (Breakthrough Method for Agile AI-Driven Development) là một framework phát triển phần mềm tuân theo các nguyên tắc Agile — sprint, epic, story, retrospective — nhưng điểm khác biệt cốt lõi là nó không được thiết kế cho người dùng trực tiếp. Toàn bộ workflow, skill và artifact của BMAD được tối ưu để AI Agent đọc và thực thi.

Nếu team bạn đang chạy theo hướng AI Driven Development — nghĩa là AI làm phần lớn công việc coding, còn người kiểm soát chiến lược và review output — thì BMAD là bộ khung chính thức hóa luồng đó, thay vì mỗi người mỗi kiểu.

Không Phải Một AI Generic — BMAD Là Cả Một Team AI Chuyên Biệt

Đây là điểm quan trọng nhất mà nhiều người bỏ qua khi nghe về BMAD lần đầu. Framework không dùng một AI duy nhất làm mọi thứ — nó định nghĩa một tập hợp AI Agent có vai trò chuyên biệt, mỗi agent là một file Markdown mô tả rõ chuyên môn, trách nhiệm và output kỳ vọng.

Các vai trò chính trong BMAD core team bao gồm:

•      Analyst — khám phá vấn đề, xác định constraint, tạo product brief

•      Product Manager — chuyển brief thành PRD với functional và non-functional requirements

•      Architect — thiết kế full stack, component map, data flow, integration strategy

•      Scrum Master — phân rã PRD thành user story có acceptance criteria, ưu tiên theo sprint

•      UX Designer — wireframe, UX flow, design guideline

•      Developer — implement theo story, tuân theo architecture và convention đã định sẵn

•      QA / Tech Writer / Test Architect — review, test, tài liệu hóa

BMAD core method thường chạy 12–19 agent tùy cấu hình, và có thể mở rộng lên 21 agent nếu tính toàn bộ module ecosystem. Mỗi agent handoff công việc cho nhau qua artifact rõ ràng — giống một team Agile thật, nhưng chạy bằng AI.

Ngoài ra BMAD còn có Party Mode — tính năng cho phép kéo nhiều agent persona vào cùng một session để cùng thảo luận, phản biện và brainstorm. Hữu ích khi cần simulate một cuộc họp đa vai trò mà không cần đủ người.

Không Can Thiệp Code Có Sẵn, Chỉ Thêm 2 Folder

Một trong những điểm đầu tiên tôi kiểm tra khi thử framework mới là: nó có làm xáo trộn codebase hiện tại không? Câu trả lời với BMAD là không.

BMAD chỉ tạo ra 2 folder trong project:

•      _bmad — chứa config và skill của framework

•      bmadoutput — chứa toàn bộ artifact được sinh ra: architecture doc, epic, story, test plan...

Điều này giải quyết một pain point kinh điển: tài liệu luôn lạc hậu so với code. Khi document nằm ngay trong repo, được sinh ra và cập nhật theo vòng đời phát triển, khoảng cách đó thu hẹp đáng kể.

Tích Hợp Tốt Với Claude Code, Copilot và Codex

BMAD không bắt bạn dùng một AI Agent cụ thể nào. Khi setup ban đầu, bạn chọn agent mình đang dùng — Claude Code, GitHub Copilot, hay Codex — và BMAD tự tạo file skill phù hợp cho từng loại.

Thực tế khi làm việc: thay vì phải giải thích lại context mỗi lần mở session mới, AI Agent đọc trực tiếp từ bmadoutput — architecture, coding convention, UX design đã được chuẩn bị sẵn. Công việc của developer lúc này gần như chỉ là chọn story tiếp theo và review output.

Docs as Code — Tại Sao Tài Liệu Không Còn Lạc Hậu Nữa

Đây là triết lý cốt lõi của BMAD và cũng là lý do giải thích tại sao document không còn bị out-of-date. Trong BMAD, source code không phải nguồn sự thật duy nhất — PRD, architecture design và user story mới là. Code chỉ là sản phẩm phái sinh từ các specification đó.

Cách tiếp cận này — gọi là Spec-Driven Development — đảo ngược thứ tự làm việc thông thường: thay vì code trước rồi viết doc sau (hoặc không bao giờ viết), BMAD bắt buộc spec phải hoàn chỉnh trước khi AI Developer agent được phép viết một dòng code. Mọi thứ đều versioned trong Git cùng codebase.

Hệ quả thực tế: khi một developer mới join team, hoặc khi AI Agent mở session mới, context không bị mất — toàn bộ quyết định kiến trúc, convention và business logic đều đã được ghi lại dưới dạng artifact có thể đọc được ngay lập tức.

Tiết Kiệm Token Nhờ Front-Loaded Planning

Một lợi ích ít được nhắc đến nhưng rất thực tế khi dùng AI Agent trong phát triển phần mềm là chi phí token. Cách làm thông thường — giải thích lại context mỗi session — tiêu tốn rất nhiều token lặp đi lặp lại cho cùng một thông tin.

BMAD giải quyết điều này bằng cơ chế front-loaded planning: toàn bộ effort tạo context được tập trung vào phase đầu, sinh ra artifact một lần và tái sử dụng xuyên suốt. AI Agent đọc từ bmadoutput thay vì phụ thuộc vào lịch sử hội thoại — gọn hơn, chính xác hơn và rẻ hơn về token.

BMAD cũng có cơ chế sharding — Scrum Master agent tự động chia story file khi context quá lớn, tránh tình trạng AI nhận quá nhiều thông tin trong một lần và bắt đầu bỏ sót hoặc hallucinate.

Developer Muốn Làm Sản Phẩm? BMAD Lấp Đúng Chỗ Hổng

Phần này có lẽ là giá trị lớn nhất với những ai có background kỹ thuật nhưng muốn build sản phẩm độc lập. Developer giỏi code, nhưng thường yếu ở Research & Analysis, Planning và UX — đúng những thứ cần làm trước khi viết dòng code đầu tiên.

BMAD chia quy trình thành 4 phase:

•      Analysis — brainstorm, research thị trường, product brief

•      Planning — requirements, epic, story, sprint planning (vai trò của BA và PM)

•      Solutioning — architecture, UX design, coding convention

•      Implementation — coding, review, demo, retrospective

Hai phase đầu là chỗ BMAD fill gap tốt nhất. Nếu bạn đã từng bắt đầu code ngay khi có ý tưởng rồi 2 tuần sau mới nhận ra mình đang build sai thứ — Analysis và Planning trong BMAD chính là thứ ngăn điều đó xảy ra.

Phase Implementation: AI Làm, Developer Review

Khi đã có đủ epic, story và architecture doc, phase Implementation trở nên khá nhàn ở góc độ tư duy. AI biết phải làm gì, biết làm theo thứ tự nào, và biết tuân theo convention nào. Bạn không cần nhắc lại context mỗi lần.

BMAD cũng có skill review code để đảm bảo output khớp với requirement. Cộng thêm các Agile event như Sprint Demo và Retrospective cũng được hỗ trợ — toàn bộ vòng lặp khép kín.

Tùy Chỉnh Theo Quy Mô Của Từng Team

BMAD không bắt buộc áp dụng toàn bộ. Một developer solo có thể dùng nhẹ — chỉ cần phase Analysis và Implementation là đủ. Một team lớn hơn có thể bật full flow với BA, PM, và cross-team sharing qua bộ skill dùng chung.

Đây là điểm hay: bạn define đến đâu thì framework hoạt động đến đó, không bị ép theo chuẩn cứng. Và khi công ty muốn đóng gói best practice để share cross-team — BMAD chính là bộ công cụ để làm điều đó.

Kết Luận: Dùng Được Nếu Bạn Nghiêm Túc Với AI Driven Development

BMAD là một framework thực sự hữu ích — không phải vì nó là silver bullet, mà vì nó hệ thống hóa được những thứ các team AI Driven thường làm nhưng chưa bao giờ viết ra thành quy trình chính thức.

Tại TEDU, quan điểm chúng tôi giữ nguyên: con người là cổng kiểm duyệt cuối cùng ở mỗi bước trong SDLC. BMAD phù hợp với triết lý đó vì nó không tự động hóa quyết định — nó tự động hóa context, để người review có đủ thông tin mà không mất thời gian tổng hợp.

Bạn Đang Muốn Áp Dụng AI Driven Development?

Nếu bạn hoặc team đang tìm cách triển khai quy trình phát triển phần mềm theo hướng AI một cách có hệ thống, TEDU có thể hỗ trợ tư vấn và hướng dẫn. Liên hệ với chúng tôi qua website tedu.com.vn để trao đổi thêm.