7. Quản lý chất lượng, kiểm thử trong quản lý dự án Agile
Mục lục
📘 7.1. Chất lượng là gì trong Agile?
🧭 Định nghĩa “Chất lượng” – Không chỉ là kỹ thuật
Trong các dự án phát triển phần mềm hoặc giải pháp CNTT, “chất lượng” thường bị hiểu lầm chỉ là:
- Không có lỗi (bug-free)
- Hiệu năng cao
- Giao diện đẹp
Tuy nhiên, trong Agile nói chung và DSDM nói riêng, chất lượng được hiểu rộng hơn và gắn với giá trị sử dụng thực tế.
🔑 Định nghĩa cốt lõi:
“Chất lượng là sự phù hợp với mục đích sử dụng” (Fitness for Purpose)
Nói cách khác, một giải pháp được xem là có chất lượng nếu:
- Nó đáp ứng được nhu cầu thật sự của người dùng
- Nó được xây dựng theo quy trình hiệu quả, minh bạch, dễ kiểm soát
- Nó có thể duy trì, mở rộng, sửa chữa hoặc nâng cấp khi cần
🎯 Chất lượng trong hai khía cạnh
1. Chất lượng giải pháp (Solution Quality)
- Sản phẩm làm ra có thực sự hữu ích, dễ sử dụng và ổn định?
- Người dùng có hài lòng khi sử dụng không?
- Có đạt được mục tiêu đề ra không?
📌 Ví dụ: Một phần mềm khảo sát người dùng có thể không đẹp nhưng nếu thu thập đủ dữ liệu một cách tiện lợi và chính xác thì vẫn được xem là có chất lượng.
2. Chất lượng quy trình (Process Quality)
- Dự án có được triển khai bài bản không?
- Có lắng nghe phản hồi và cải tiến không?
- Có kiểm tra chất lượng thường xuyên và chủ động không?
📌 Agile đánh giá chất lượng quy trình qua các hoạt động như:
- Retrospective cuối Timebox
- Họp kiểm tra liên tục (review, daily standup)
- Phối hợp chặt chẽ giữa người dùng và nhóm kỹ thuật
🔄 Chất lượng là một quá trình – không phải điểm đến
Trong mô hình Waterfall truyền thống, kiểm tra chất lượng thường xảy ra cuối chuỗi – sau khi tất cả tính năng đã hoàn thiện.
Trong khi đó, Agile xem chất lượng là thứ được xây dựng từng bước, trong suốt vòng đời phát triển.
🧠 “Bạn không thể kiểm tra chất lượng vào sản phẩm – bạn phải lập trình nó ngay từ đầu.”
🛠 Vai trò của kiểm thử trong đảm bảo chất lượng
Chất lượng không thể đảm bảo nếu thiếu kiểm thử liên tục, bao gồm:
- Kiểm thử đơn vị (unit test)
- Kiểm thử tích hợp
- Kiểm thử chức năng
- Kiểm thử bởi người dùng (UAT)
- Trình diễn và kiểm tra nguyên mẫu
Các kỹ thuật như Test-Driven Development (TDD) và Fail Fast được khuyến khích trong Agile để phát hiện lỗi sớm, từ đó giảm chi phí và công sức sửa lỗi về sau.
🔎 Chất lượng gắn liền với phản hồi
Một trong những điểm mạnh của Agile là khả năng phản hồi liên tục. Điều này không chỉ giúp điều chỉnh yêu cầu, mà còn:
- Phát hiện sai lệch chất lượng ngay lập tức
- Điều chỉnh quy trình phát triển, kỹ thuật, hoặc giao tiếp nhóm
- Gắn trách nhiệm chất lượng với từng thành viên chứ không đổ lỗi cho kiểm thử viên
✅ Kết luận
“Chất lượng” trong Agile là:
- Sản phẩm đúng – làm đúng việc
- Làm đúng – sản phẩm được xây dựng theo quy trình hợp lý
- Tiến hóa – không ngừng cải tiến theo thời gian và phản hồi thực tế
💬 “Chất lượng là sự cam kết dài hạn – không phải kết quả của một bài kiểm thử.”
🛡 7.2. Đảm bảo chất lượng trong DSDM (Quality Assurance)
🧩 Chất lượng không tự nhiên mà có – nó được đảm bảo có hệ thống
Trong DSDM, chất lượng không được phó mặc cho riêng khâu kiểm thử, mà là trách nhiệm của cả nhóm dự án xuyên suốt vòng đời phát triển.
Khác với các mô hình truyền thống – nơi kiểm thử chỉ diễn ra vào cuối, DSDM thực hiện kiểm tra chất lượng liên tục, thông qua nhiều hoạt động được tích hợp vào từng Timebox (chu kỳ làm việc ngắn).
📌 Các nguyên tắc kiểm tra chất lượng trong DSDM
DSDM đặt ra một loạt câu hỏi cốt lõi để đảm bảo chất lượng được duy trì:
| Câu hỏi kiểm tra | Ý nghĩa kiểm soát |
|---|---|
| Người dùng có tham gia đầy đủ không? | Đảm bảo sản phẩm đúng mục tiêu |
| Nhóm có quyền tự chủ không? | Tạo điều kiện phát huy năng lực |
| Có tuân theo quy trình vòng đời không? | Bảo vệ tính hệ thống và minh bạch |
| Sản phẩm có được tạo đúng không? | Kiểm tra đầu ra đúng với kế hoạch |
| Phản hồi review có được áp dụng không? | Thể hiện sự tiến hóa và học hỏi |
| Có thể quay lại khi cần không (backtracking)? | Giảm thiểu rủi ro sai lệch |
| Có giữ đúng ưu tiên theo MoSCoW không? | Tập trung vào điều quan trọng nhất |
| Có giữ đúng khung thời gian không? | Tránh trễ hẹn, kiểm soát khối lượng việc |
💬 “Nếu một nhóm trả lời ‘có’ cho tất cả câu hỏi trên, đó là dấu hiệu cho thấy họ đang vận hành theo Agile chất lượng cao.”
🔄 Chất lượng gắn liền với cải tiến vòng lặp
Một trong những đặc điểm nổi bật của DSDM là việc đánh giá liên tục thông qua:
- Timebox Review: Sau mỗi vòng phát triển, sản phẩm được trình bày – nhận phản hồi trực tiếp
- Retrospective: Cả nhóm cùng nhìn lại quy trình, ghi nhận điều tốt và chưa tốt → hành động cải tiến
- Evolving Solution: Sản phẩm luôn được cập nhật dần dần – mỗi bản mới là một bước hoàn thiện chất lượng
🔁 Chất lượng không phải là mục tiêu đạt được một lần, mà là hành trình cải tiến không ngừng.
📜 Liên hệ với tiêu chuẩn ISO 9001
DSDM vận dụng cách tiếp cận “3 bước kiểm soát chất lượng” từ ISO 9001:
| Bước | Nội dung | Trong DSDM là gì? |
|---|---|---|
| 1. Nói bạn sẽ làm gì | Thiết lập kế hoạch và tiêu chí thành công | Timebox Plan, Definition of Done |
| 2. Làm điều đó | Thực hiện đúng theo kế hoạch | Evolving Solution, Daily Stand-up |
| 3. Chứng minh bạn đã làm | Có sản phẩm, có báo cáo, có feedback | Timebox Review Record, Testing |
Đây là cách làm giúp minh bạch hóa chất lượng, không chỉ bằng cảm tính mà bằng bằng chứng cụ thể.
🧠 Vai trò của từng thành viên trong đảm bảo chất lượng
- Business Ambassador: Đưa ra tiêu chuẩn chất lượng theo quan điểm người dùng
- Developer: Tuân thủ coding guideline, TDD, viết tài liệu kỹ thuật
- Tester: Đảm bảo các test case được chạy đầy đủ, ghi nhận lỗi đúng mức độ
- Agile PM: Theo dõi tổng thể tiến độ, rủi ro và phản hồi để phát hiện sai lệch sớm
✅ Trong Agile, chất lượng là văn hóa, không chỉ là vai trò riêng của Tester.
✅ Kết luận
Đảm bảo chất lượng trong DSDM là:
- Một quá trình liên tục – chủ động – toàn diện
- Gắn liền với thái độ học hỏi và cải tiến
- Không thể thiếu sự tham gia của người dùng và cả đội nhóm
- Dựa trên phản hồi thật, sản phẩm thật – không phải tài liệu hình thức
💬 “Chất lượng không bắt đầu từ test – nó bắt đầu từ tư duy trách nhiệm của từng thành viên.”
🧰 7.3. Tính Bảo Trì (Maintainability) và Chi Phí Chất Lượng
🔍 Tại sao phải nghĩ đến bảo trì ngay từ đầu?
Một sản phẩm phần mềm không kết thúc khi giao cho người dùng. Thực tế:
- Nó sẽ tiếp tục được sử dụng, sửa đổi, nâng cấp, vá lỗi, tích hợp
- Do đó, khả năng bảo trì là một phần cốt lõi của chất lượng lâu dài
🛠️ Một sản phẩm khó sửa, khó nâng cấp = chi phí chất lượng về sau cao.
📌 Maintainability là gì?
Maintainability (tính bảo trì) là:
- Khả năng sửa chữa, nâng cấp hoặc thay đổi phần mềm dễ dàng và nhanh chóng
- Giảm thời gian và chi phí khi xảy ra lỗi, thay đổi yêu cầu, hoặc tích hợp với hệ thống khác
🔧 Một sản phẩm bảo trì tốt là sản phẩm có cấu trúc rõ ràng, tài liệu đầy đủ, và quy tắc mã nguồn thống nhất.
🧮 Chi phí chất lượng (Cost of Quality – CoQ)
Chi phí chất lượng không chỉ là:
- Chi phí kiểm thử
- Chi phí dụng cụ đo lường
Mà còn gồm cả:
- Chi phí phòng ngừa (preventive): đào tạo, quy trình chuẩn, EDUF
- Chi phí đánh giá (appraisal): review, kiểm thử
- Chi phí lỗi nội bộ (internal failure): lỗi phát hiện trong dự án
- Chi phí lỗi bên ngoài (external failure): lỗi phát hiện bởi người dùng sau khi giao hàng
📉 Bài học:
Chi nhiều cho phòng ngừa và kiểm soát = ít chi cho sửa chữa và khủng hoảng
⚠️ Các quyết định chiến lược về bảo trì – 3 hướng đi
DSDM yêu cầu nhóm phải xác định rõ quan điểm bảo trì ngay từ đầu dự án, thường theo một trong ba hướng:
| Hướng đi | Mô tả | Khi nào nên chọn |
|---|---|---|
| ✅ Ưu tiên bảo trì | Đầu tư vào thiết kế sạch, tài liệu rõ ràng, quy trình nghiêm ngặt | Sản phẩm dùng lâu dài, tích hợp nhiều hệ thống |
| ⚠️ Không cần bảo trì | Làm nhanh, dùng một lần hoặc trong thời gian rất ngắn | Hệ thống thử nghiệm, prototype, MVP |
| ⏩ Tối ưu tốc độ, chấp nhận chi phí về sau | Giao hàng nhanh, fix sau nếu có lỗi | Khi tốc độ thị trường quan trọng hơn chất lượng kỹ thuật ban đầu |
🧠 Mỗi hướng đều đúng nếu chọn đúng bối cảnh – sai khi chọn mù quáng.
🧪 Ví dụ minh họa
Dự án phát triển hệ thống quản lý thi trực tuyến cho kỳ thi tuyển sinh quốc gia:
- Nếu định dùng 5 năm, phục vụ hàng trăm ngàn lượt thi → cần đầu tư bảo trì
- Nếu chỉ dùng cho một đợt thi thử nội bộ → có thể chấp nhận bỏ qua bảo trì dài hạn
🚨 Rủi ro nếu bỏ qua bảo trì
- Sửa một lỗi nhỏ cũng mất 2 ngày vì không hiểu code
- Người mới vào nhóm không thể đọc hiểu logic cũ
- Không nâng cấp được framework → dính lỗ hổng bảo mật
- Tốn 200% chi phí sau khi sản phẩm được triển khai
✅ Kết luận
Tính bảo trì là yếu tố không thể thiếu của chất lượng:
- Phải xác định quan điểm bảo trì từ đầu
- Phải đầu tư thông minh: code sạch, tài liệu hóa, tiêu chuẩn chung
- Tư duy bảo trì = tư duy phát triển bền vững
💬 “Chất lượng thực sự không dừng ở lúc bàn giao – nó thể hiện khi người khác tiếp quản được công việc bạn để lại.”
🗂 7.4. Cấu hình là gì? (Configuration Management – CM)
🔍 Vì sao cần quản lý cấu hình trong Agile?
Trong một dự án phần mềm, nhóm thường phải làm việc với:
- Nhiều phiên bản mã nguồn
- Hàng loạt tài liệu (yêu cầu, kiến trúc, test case, hướng dẫn)
- Các gói phần mềm trung gian (build, release)
- Sự thay đổi liên tục từ người dùng
📌 Nếu không có một cơ chế kiểm soát cấu hình, bạn sẽ gặp tình trạng:
- Không biết đâu là bản mới nhất
- Hai người sửa trùng file → đè lên nhau
- Đổi một thành phần → hỏng cả hệ thống
🧠 Agile = thay đổi nhanh → cần kiểm soát tốt để đổi không rối và linh hoạt mà vẫn an toàn
🧭 Configuration Management là gì?
Configuration Management (CM) là quá trình:
👉 Xác định – kiểm soát – theo dõi – xác minh các thành phần trong một hệ thống
Nó bao gồm:
| Bước | Nội dung |
|---|---|
| Lập kế hoạch CM | Xác định cách thức và mức độ quản lý cấu hình |
| Định danh cấu hình (CI) | Gán mã định danh duy nhất cho từng thành phần (file, module, tài liệu) |
| Kiểm soát thay đổi | Thiết lập thủ tục khi muốn thay đổi một thành phần |
| Báo cáo trạng thái | Biết hiện tại đang dùng phiên bản nào, ai sửa, có lỗi gì |
| Xác minh | Đảm bảo trạng thái hệ thống thực tế khớp với hồ sơ cấu hình |
🧩 Thành phần cấu hình – Configuration Items (CI)
Một CI có thể là:
- File mã nguồn (.java, .py, .php…)
- Tài liệu thiết kế (.docx, .drawio, .md…)
- Gói phần mềm (.zip, .jar, Docker image)
- Dữ liệu test, scripts CI/CD
- Environment file, Dockerfile, v.v.
📦 Nếu thành phần đó có thể thay đổi và ảnh hưởng đến sản phẩm, thì nó là một CI và cần được quản lý.
🛑 Change Control là gì?
Là thủ tục chính thức khi muốn thay đổi một CI:
- Gửi yêu cầu thay đổi (RFC – Request for Change)
- Người phụ trách CM xét duyệt
- Nếu chấp nhận, thực hiện thay đổi
- Cập nhật mã phiên bản, log thay đổi
📌 Trong Agile, thủ tục này cần nhẹ nhàng nhưng rõ ràng – tránh gây trì trệ, nhưng vẫn kiểm soát tốt.
🧠 Tại sao CM là chìa khóa đảm bảo chất lượng?
- Giúp biết rõ ai đang làm gì, với phiên bản nào
- Tránh lỗi do “làm sai file” hoặc “sửa nhầm phiên bản”
- Phục hồi nhanh nếu có lỗi → Rollback dễ dàng
- Là điều kiện cần cho CI/CD (Continuous Integration/Delivery)
🧩 Không có CM → Dự án Agile sẽ dễ loạn như “đàn cá không đầu”
👥 Ai chịu trách nhiệm quản lý cấu hình?
- Nhóm nên chọn một người giữ vai trò CM Champion
- Không nên đợi đến khi “bên ngoài kiểm tra mới làm”
- Trách nhiệm CM nằm trong nội bộ nhóm, không đẩy cho QA hay quản lý
🧪 Baselining – Đặt mốc phiên bản
Baselining là hành động:
✅ “Chụp ảnh” toàn bộ trạng thái cấu hình tại một thời điểm xác định
Ứng dụng:
- Sau khi hoàn tất 1 Timebox → tạo baseline
- Trước khi bàn giao, trình diễn
- Trước khi test chính thức (UAT)
Giúp:
- So sánh giữa các phiên bản
- Khôi phục lại nhanh nếu phiên bản sau hỏng
✅ Kết luận
Configuration Management là:
- Lá chắn an toàn cho sự thay đổi trong Agile
- Đảm bảo kiểm soát trong môi trường phát triển nhanh
- Gắn liền với chất lượng và khả năng bảo trì
💬 “Agile không có nghĩa là hỗn loạn – CM là cách để linh hoạt có tổ chức.”
🧪 7.5. Kiểm thử trong Agile – Phản hồi sớm, cải tiến liên tục
📍 Khác biệt cốt lõi: Kiểm thử không chỉ là giai đoạn, mà là văn hóa
Trong mô hình phát triển truyền thống (Waterfall), kiểm thử thường được coi là bước cuối cùng – sau khi hoàn tất coding. Tuy nhiên, cách tiếp cận này dẫn đến nhiều vấn đề:
- Lỗi phát hiện muộn → chi phí sửa chữa cao
- Không còn thời gian để phản hồi và sửa đổi
- Người kiểm thử không hiểu mục tiêu kinh doanh
Ngược lại, trong Agile, kiểm thử là một hoạt động xuyên suốt vòng đời phát triển, bắt đầu ngay từ đầu, và là trách nhiệm của cả nhóm – không chỉ của QA.
💬 “Nếu kiểm thử là một giai đoạn thì bạn luôn đến quá muộn. Nếu nó là một tư duy, bạn luôn đi đúng lúc.”
🧭 Nguyên tắc kiểm thử trong Agile / DSDM
| Nguyên tắc | Ý nghĩa thực tế |
|---|---|
| ✅ Collaborative (Hợp tác) | Tester, developer, người dùng cùng lên test case |
| ✅ Repeatable (Lặp lại được) | Test có thể chạy lại dễ dàng (manual hoặc automated) |
| ✅ Prioritised (Ưu tiên hóa) | Tập trung kiểm thử chức năng “Must Have” trước |
| ✅ Risk-based (Dựa trên rủi ro) | Kiểm kỹ những phần dễ sai, quan trọng |
| ✅ Independent (Độc lập) | Có người kiểm thử không trực tiếp code tính năng |
| ✅ TDD-friendly | Hỗ trợ Test-Driven Development – viết test trước code |
| ✅ Fail Fast | Khuyến khích lỗi xảy ra sớm để sửa nhanh và rẻ |
| ✅ End-to-End Experience | Kiểm thử hành vi thực tế của người dùng cuối |
🛠 Các kỹ thuật và công cụ hỗ trợ kiểm thử Agile
- Mô hình hóa yêu cầu (Modeling)
→ Giúp tạo test case rõ ràng, thống nhất - MoSCoW
→ Sử dụng để ưu tiên các test case – giống như ưu tiên yêu cầu - Workshop kiểm thử
→ Tester, developer, người dùng cùng họp để xác định cách kiểm thử và tiêu chí chấp nhận - CI/CD + Automated Testing
→ Mỗi lần đẩy code đều chạy test tự động → phản hồi ngay lập tức
🧪 Các cấp độ kiểm thử trong Agile
| Cấp độ | Mục tiêu |
|---|---|
| Unit Test | Kiểm từng chức năng nhỏ của code – do dev viết |
| Integration Test | Kiểm tra khi các phần tích hợp lại |
| System Test | Kiểm toàn hệ thống như một khối thống nhất |
| User Acceptance Test (UAT) | Kiểm tra bởi người dùng, xác nhận hệ thống “đủ tốt để dùng” |
🔄 Các cấp độ này có thể diễn ra song song, lặp lại nhiều lần, không tuyến tính như trong Waterfall.
🧠 Vai trò kiểm thử trong từng Timebox
Trong mỗi Timebox (chu kỳ phát triển), tester sẽ:
- Tham gia họp kế hoạch để biết tính năng mới
- Viết/sửa test case (manual hoặc auto)
- Chạy test mỗi ngày hoặc sau mỗi commit
- Ghi lỗi, báo cáo – tham gia vào review cuối kỳ
Tester không đứng ngoài – họ là một phần của nhóm phát triển.
🧩 Tư duy “Fail Fast” – cho phép sai sớm, sửa sớm
- Càng phát hiện lỗi muộn → càng khó, tốn kém
- Agile khuyến khích tạo môi trường an toàn để thất bại sớm
- Nếu lỗi xảy ra ở Timebox 1 → dễ sửa
Nếu lỗi phát hiện ở cuối → nguy cơ “cháy deadline”
✅ Kết luận
Kiểm thử trong Agile là:
- Một quy trình xuyên suốt, không phải giai đoạn riêng biệt
- Dựa trên giao tiếp, ưu tiên, phản hồi nhanh
- Là trách nhiệm chung, không chỉ của người test
- Gắn liền với giá trị thực tế và hành vi người dùng
💬 “Một tính năng chưa được kiểm thử không phải là tính năng – nó là giả định.”
