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
Test Automation(Kiểm thử tự động)
1.Test Automation (Kiểm thử tự động) là gì? Trong các dự án phát triển phần mềm truyền thống trước đây, toàn bộ quy trình kiểm thử (Testing) đều được thực hiện thủ công (Manual Testing) bởi con người. Các kiểm thử viên trực tiếp thao tác trên giao diện, nhập dữ liệu, kiểm tra kết […]
Logging – Monitoring – CI/CD
Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]
Redis & Caching là gì?
Redis & Caching là gì? Hướng dẫn sử dụng Redis trong Go 1. Caching là gì? Vì sao cần cache khi đã có database? Caching (bộ nhớ đệm) là kỹ thuật lưu tạm dữ liệu thường được truy cập để có thể lấy lại nhanh chóng khi cần, thay vì phải thực hiện lại toàn […]
Background Jobs & Queues
1. Background Jobs & Queues là gì? Trong một ứng dụng backend, không phải công việc nào cũng cần hoàn thành ngay trong lúc xử lý HTTP request. Ví dụ, khi người dùng đăng ký tài khoản, hệ thống có thể cần: Lưu thông tin người dùng vào database. Gửi email xác nhận. Gửi thông […]
Saga Pattern
Saga Pattern là gì? Quản lý Transaction trong kiến trúc Microservices 1. Saga Pattern là gì? Saga Pattern là một mẫu thiết kế được sử dụng để quản lý các nghiệp vụ phân tán gồm nhiều bước xử lý, trong đó mỗi bước có thể thực hiện một local transaction tại một service hoặc Database […]
Two-Phase Locking (2PL)
Two-Phase Locking (2PL) là gì? Cơ chế khóa hai pha trong Database 1. Two-Phase Locking (2PL) là gì? Two-Phase Locking (2PL — khóa hai pha) là một giao thức quản lý khóa trong Database, quy định cách một transaction được phép lấy và giải phóng lock trong quá trình thực thi. Khi nhiều transaction cùng […]
Khoá học lập trình game con rắn cho trẻ em 
