Có một khái niệm rất hay mà trong các sách vở về phát triển phần mềm hay nhắc đến, gọi là “technical debt” – “món nợ kĩ thuật”. Khái niệm này chỉ đến hiện tượng một phần mềm có thể được chuyển giao (deliver) tới khách hàng trong trạng thái còn bug (do chưa được test kĩ hoặc cố tính che lấp đi để khách hàng không nhìn thấy). Khi khách hàng dùng phần mềm thì phát hiện ra lỗi đó, và họ yêu cầu “hỗ trợ kĩ thuật” hoặc “bảo trì” – khi đó đơn vị sản
Technical Debt (IMG: Castsoftware)
xuất phải có nghĩa vụ thực hiện các việc “cực chẳng đã này”: trả nợ kĩ thuật.
Nhìn từ góc độ kinh tế, “nợ kĩ thuật” là rất rủi ro và có thể rất tốn kém. Bug được phát hiện càng lâu sau khi phần mềm bắt đầu được làm ra thì càng đắt đỏ. Một bug được phát hiện bởi developer trong lúc lập trình có thể có chi phí (phải fix) bằng 1/100, thậm chí 1/10.000 so với bug được phát hiện ra lúc thành phẩm đã đến tay người dùng cuối ( lúc đó cũng phải fix, nhưng với chi phí lớn hơn nhiều lần: cử người ra fix lỗi, vá lỗ hổng, deploy lại, v.v – mà hầu như không được trả tiền thêm). Do vậy, để giảm thiểu rủi ro về món nợ này chỉ có một cách duy nhất: làm ra phần mềm chạy tốt, ngay từ đầu.
Nhìn từ góc độ kĩ thuật, “món nợ kĩ thuật” ám chỉ sự yếu kém trong kĩ năng chuyên môn (do yếu kém trong đảm bảo chất lượng) hoặc đạo đức nghề nghiệp (do cố tình “che mắt” khách hàng các lỗi kĩ thuật), dẫn đến sản phẩm không đạt chất lượng lẽ ra nó vốn phải có. Đương nhiên, đơn vị sản xuất cũng phải trả món nợ này theo cách đắng cay nhất: tiền mất – tật mang ( vừa mất uy tín, vừa mất tiền).
Hiện nay nhiều quan điểm chất lượng (hời hợt) thường đổ dồn về phía khách hàng: khách hàng mà chấp nhận (acceptance) thì tức là chất lượng cao. Sự thực không đơn giản như thế, bởi khách hàng thì thường không nhìn vào dòng lệnh, nên bản thân họ không chắc chắn được 100% về cái hoạt động bên ngoài (external behavior) của phần mềm có thực sự là “chất lượng” hay không. Quan điểm chất lượng truyền thống (mang tính tiêu chuẩn) thì cho rằng phải có cái tốt “tự thân”: phần mềm được gọi là có chất lượng khi nó phải có các “đặc tính” tốt “vốn có” chứ không phải là bởi vì ai đó bên ngoài gọi nó là “tốt” hay không tốt. Cố nhiên, cái tốt đó phải hướng đến “khách hàng”, chứ không phải là cái tốt được vẽ ra từ trong đầu developer. Chỉ khi chúng ta chấp nhận cái quan điểm sau (tức quan điểm về đặc tính tốt vốn có) thì mới dễ dàng chấp nhận các chi phí cần thiết để đầu tư cho chất lượng, và không gắn vào sản phẩm các “món nợ kĩ thuật”, các quả bom nổ chậm có thể phát huy tác dụng phá hủy uy tín và túi tiền của đơn vị sản xuất phần mềm.
Scrum và các phương pháp agile khác thường nhấn mạnh giá trị chất lượng bằng khái niệm “built-in quality”- tức là giá trị có sẵn, tự thân, do chính người sản xuất (developer) làm nên chứ không phải dựa hoàn toàn vào người ngoài (QA, tester, khách hàng). Trách nhiệm đảm bảo chất lượng là của chính người sản xuất (developer) chứ không phải ai khác. Đó cũng là cách mà agile\Scrum giảm thiểu các “món nợ kĩ thuật” xuống mức thấp nhất có thể. Các cơ chế như TDD, BDD, ATDD, pair-programming sẽ không để các bug có cơ hội xuất hiện, vì ngay từ đầu, nó đã được developer chủ định “phòng ngừa” (bug-prevention).
