12 nguyên tắc, feedback loop và mấy khái niệm liên quan
12 nguyên tắc Agile
Nếu 4 giá trị là tư tưởng thì 12 nguyên tắc là cách biến tư tưởng đó thành hướng đi thực tế.
- Giao hàng sớm và liên tục (Early and continuous delivery)
Đưa phần mềm có giá trị đến tay khách sớm và đều đặn. Thay vì chờ cả năm mới có đủ chức năng, chia ra: Sprint 1 làm Login, Sprint 2 Product, Sprint 3 Cart, Sprint 4 Checkout. Mỗi lần giao phải dùng được thật, không phải đống code nằm đó chưa chạy. - Chào đón thay đổi yêu cầu (Welcome changing requirements)
Kể cả khi dự án đã đi khá xa. Ví dụ ban đầu chỉ thanh toán COD, sau khách bảo “user toàn xài MoMo” thì team cân nhắc thêm MoMo. Thay đổi không hẳn là kẻ thù, nhiều khi nó giúp sản phẩm hợp thị trường hơn. - Giao phần mềm chạy được thường xuyên (Deliver working software frequently)
Thay vì 1 năm mới release 1 lần, chia thành các chu kỳ, làm xong phần nào đáp ứng yêu cầu thì phát hành phần đó. - Business và developer làm việc cùng nhau mỗi ngày
Đừng để kiểu: business gửi requirement, dev im lặng làm 3 tháng, rồi “ủa sao làm sai vậy?”. Hai bên nên trao đổi yêu cầu và kiểm tra cách triển khai thường xuyên. - Xây dự án quanh những người có động lực (Motivated individuals)
Cho họ môi trường và sự hỗ trợ cần thiết, rồi tin họ làm được. Ví dụ đừng chỉ đạo từng thao tác nhỏ, hãy để dev tự chọn cách triển khai kỹ thuật. - Nói chuyện trực tiếp (Face-to-face conversation)
Nói chuyện trực tiếp thường là cách truyền đạt thông tin hiệu quả nhất. Không bắt buộc ngồi chung phòng, team remote dùng video call, share màn hình cũng được. Cốt lõi là giảm hiểu nhầm. - Phần mềm chạy được là thước đo tiến độ chính
Không đo bằng “đã viết 500 trang tài liệu”, “họp 30 tiếng”, hay “Jira có 100 task”. Phải nhìn sản phẩm thật đã chạy được gì. - Phát triển bền vững (Sustainable development)
Giữ nhịp làm việc ổn định lâu dài. Tuần 1 cày 80 tiếng, tuần 2 cày 80 tiếng, tuần 3 kiệt sức thì chất lượng, sức khỏe và tiến độ đều đi xuống. Agile hướng tới nhịp đều, không chạy nước rút ngắn hạn. - Chú trọng chất lượng kỹ thuật và thiết kế tốt
Code nhanh cho chạy được nhưng kiến trúc dở thì bug tăng, sửa khó, mỗi lần thay đổi càng tốn kém. Nên Agile không có nghĩa là code ẩu cho nhanh. Chất lượng code và kiến trúc tốt chính là thứ giúp team thay đổi sản phẩm mà không phải trả giá quá đắt. - Đơn giản hóa (Simplicity)
Nghệ thuật tối đa hóa lượng việc không cần làm. Ví dụ khách đòi AI recommendation trong khi web còn chưa có tìm kiếm sản phẩm. Thay vì lao vào AI + Machine Learning + Vector Database + Recommendation Engine, ưu tiên Search + Filter + recommendation cơ bản trước. Đừng làm thứ chưa thật sự cần. - Team tự tổ chức (Self-organizing teams)
Kiến trúc, yêu cầu, thiết kế tốt thường đến từ team tự chủ động bàn bạc và quyết định, thay vì việc gì cũng chờ một người chỉ đạo. - Thường xuyên nhìn lại và điều chỉnh (Regular reflection)
Định kỳ team ngồi lại xem làm gì chưa tốt, rồi chỉnh. Ví dụ sau Sprint 1:
- PR review quá chậm
- API documentation thiếu
- FE/BE phối hợp tốt
Ở buổi Retrospective, team quyết định: PR phải được review trong 24 giờ, BE phải document API, giữ cách FE/BE đang phối hợp. Sprint sau thử cách mới, đo kết quả, retro tiếp, cải thiện tiếp. Đây là Continuous Improvement (cải tiến liên tục).
Agile không phải làm nhanh hay làm tùy hứng
- Agile ≠ làm nhanh. Không phải cắm đầu code thật lẹ hay ép mọi deadline ngắn lại.
- Agile ≠ làm tùy hứng. Không phải muốn làm gì thì làm, bỏ qua kế hoạch và quy trình.
- Agile = tạo giá trị, nhận feedback, thích nghi. Tạo giá trị, kiểm tra kết quả, nhận phản hồi, đổi khi cần.
Agile không đảm bảo sản phẩm hoàn hảo. Nó giúp team liên tục điều chỉnh dựa trên phản hồi và bằng chứng thật.
Feedback Loop (vòng lặp phản hồi)
Là quá trình lấy thông tin từ kết quả thực tế, dùng nó để điều chỉnh rồi làm tiếp. Ví dụ:
- Team nghĩ: “User sẽ thích Product Filter này”
- Build chức năng
- User dùng thật
- Nhìn analytics/feedback, phát hiện 80% user không dùng filter
- Team đổi hướng dựa trên dữ liệu
- Build bản mới
- Đo lại xem thay đổi có hiệu quả không
Qua vòng này team nhận ra giả định ban đầu sai và kịp đổi hướng.
Build – Measure – Learn – Adapt
Chu trình phát triển sản phẩm dựa trên việc học từ thực tế: Build (xây) → Measure (đo) → Learn (học từ kết quả) → Adapt (điều chỉnh) → rồi Build tiếp.
Chu trình này dính tới nhiều khái niệm khác:
| Thuật ngữ | Là gì |
| Lean Startup | Phương pháp xây sản phẩm dựa trên vòng Build–Measure–Learn |
| MVP (Minimum Viable Product) | Bản sản phẩm tối thiểu để kiểm chứng giả định |
| Product Management | Quản lý sản phẩm |
| DevOps | Kết hợp Development và Operations để phát triển, triển khai, vận hành tốt hơn |
| CI/CD | Tự động hóa tích hợp, kiểm tra, phân phối/triển khai phần mềm |
| A/B Testing | Thử hai phiên bản để so sánh kết quả |
| Product Analytics | Phân tích dữ liệu người dùng dùng sản phẩm thế nào |
Phương pháp và công cụ hay đi kèm Agile
| Thuật ngữ | Là gì |
| Kanban | Quản lý luồng việc bằng cách trực quan hóa và giới hạn số việc đang làm cùng lúc |
| XP | Tập trung mạnh vào thực hành kỹ thuật |
| Crystal | Chú trọng con người, giao tiếp và bối cảnh dự án |
| Scrum | Framework giúp team phát triển và duy trì sản phẩm phức tạp |
| Jira | Công cụ theo dõi, quản lý công việc, hay dùng trong team Agile |
| Git | Quản lý phiên bản mã nguồn |
| GitHub | Nền tảng lưu repo Git và hỗ trợ cộng tác |
| CI/CD, DevOps | Như bảng trên |
Lưu ý: không phải thứ nào trong đây cũng thuộc riêng Agile. Mấy công cụ và phương pháp này dùng được trong nhiều mô hình phát triển khác nhau.
Bài viết khác
SDLC&STLC
1. Tổng quan nền tảng về quy trình phát triển và kiểm thử phần mềm Trong bất kỳ một dự án công nghệ thông tin nào, dù là ứng dụng di động nhỏ hay hệ thống phần mềm doanh nghiệp khổng lồ, việc để sản phẩm đi đến thành công không thể dựa vào sự […]
Kanban vs Scrum, Scrumban và phần nâng cao
Kanban vs Scrum, Scrumban và phần nâng cao So sánh Kanban và Scrum Tiêu chí Kanban Scrum Bản chất Phương pháp quản lý dòng chảy liên tục Framework phát triển theo chu kỳ Nhịp làm việc Dòng chảy liên tục Khung thời gian cố định (Sprint 1-4 tuần) Cam kết phạm vi Theo khả năng […]
Kanban từ đâu ra và nó thực chất là gì
Kanban từ đâu ra và nó thực chất là gì Chuyện bắt đầu ở Nhật Sau Thế chiến 2 (1945), kinh tế Nhật tan hoang: thiếu vốn, thiếu tài nguyên, hạ tầng bị phá nát. Ngành ô tô Nhật lúc đó gặp bài toán sống còn: thị trường cần nhiều mẫu mã nhưng mỗi mẫu […]
Backlog Refinement, ước lượng, công cụ thực tế
Backlog Refinement, ước lượng, công cụ thực tế Backlog Refinement Là hoạt động làm rõ Product Backlog: chia nhỏ, làm rõ, ước lượng, sắp xếp lại các item khi cần. Ví dụ ban đầu backlog có một mục “Product Search” quá to. Sau khi refine thì tách thành: Search UI, Search API, Search by name, […]
Scrum cơ bản, vai trò và các sự kiện
Scrum cơ bản, vai trò và các sự kiện Scrum sinh ra để làm gì? Hiểu Agile xong thì sẽ nảy ra câu hỏi: Agile bảo phản hồi nhanh, thích nghi, cải tiến liên tục, nhưng làm thật thì tổ chức công việc kiểu gì? Scrum ra đời để trả lời câu đó. Theo Scrum […]
Agile là gì, và 4 giá trị cốt lõi
Agile là gì, và 4 giá trị cốt lõi Agile thực sự là gì? Agile nghĩa là linh hoạt, thích nghi. Nó là một bộ giá trị và nguyên tắc để định hướng cách làm phần mềm, chứ không phải một framework cố định, cũng không phải quy trình bắt mọi team phải làm y […]
Khoá học lập trình game con rắn cho trẻ em 
