Tại sao chất lƣợng lại quá quan trọng? Đó có phải phải là vấn đề chính để chúng ta sửa chữa các lỗi để tìm đƣờng đi vào sản xuất hay không? Câu trả lời đơn giản là các vấn đề chất lƣợng đắt hơn ta nghĩ nhiều. Trong Kanban, chúng ta tập trung vào việc xây dựng các chính sách rõ ràng để tối ƣu chất lƣợng và tính thống nhất trong hệ thống phân phối phần mềm, và chúng ta sử dụng điều đó nhƣ một căn cứ cho việc cải tiến liên tục.
* Hiểu về chất lượng
Cho dù một ngƣời dùng không thể hoàn thành một nhiệm vụ vì hệ thống thiếu một giao diện trực quan hoặc một lỗi ngăn cản quy trình làm việc, thì chúng đều là hai vấn đề về chất lƣợng và chúng gây áp lực lên hệ thống của chúng ta và tạo ra một vòng lặp hoàn toàn lãng phí. Điều này đƣợc gọi là “nhu cầu thất bại” trong hệ thống Lean, mô tả tất cả các hoạt động và công việc bổ xung có liên quan đến sản phẩm không đƣợc
thiết kế phù hợp lúc ban đầu. Thỉnh thoảng điều này đƣợc chấp nhận, vì khi phát hành phần mềm sẽ lấy đƣợc thống tin phản hồi thực tế, đây là cách rẻ nhất để mua thông tin. Cũng có thể có trƣờng hợp tìm ra lỗi này để xử lý trƣớc có thể đòi hỏi chúng ta nhiều thời gian và tiền bạc hơn là sửa chữa nó sau đó.
Vậy tại sao nó đắt nhƣ vậy? Hãy xem xét một vài tình huống phổ biến trong phát triển phần mềm.
Một ngƣời sử dụng (hãy gọi anh ta là A) không thể hoàn thành nhiệm vụ của anh ta bởi vì một lỗi trong hệ thống của chúng ta. Hoặc A viết một báo cáo bị lỗi hoặc gọi hỗ trợ cấp độ đầu tiên để giải quyết vấn đề này. Tuy nhiên, A không biết nhiều về cái gì cần cho một ngƣời phát triển có thể khảo sát vấn đề hoặc có thể ngƣời hỗ trợ ở cấp độ đầu tiên không hiểu hệ thống nhƣ anh ta phải làm. Trong cả hai trƣờng hợp, thông tin sai lệch hoặc không đầy đủ đƣợc đƣa đến ngƣời phát triển, họ có thể theo đuổi việc giải quyết một vấn đề khác (cái mà có thể thực sự không phải là một vấn đề, nhƣng thay vào đó dẫn đền một lỗi khác) hoặc đơn giản là bỏ cuộc. Điều này tiếp diễn cho tới tận cuối cùng, các mối đƣợc giải quyết hết. Tuy nhiên, không chỉ làm cho A không hoàn thành nhiệm vụ, thông tin sai đã bị ghi vào cơ sở dữ liệu, cái mà bây giờ cần một tập lệnh SQL phức tạp đề chuyển sang trạng thái có ý nghĩa. Không phải là không phổ biến các tình huống xảy ra giống nhƣ vậy, nguồn nhân lực bỏ ra so với việc bỏ ra thời gian giới thiệu các lỗi ở nơi đầu tiên.
Hơn nữa, vấn đề chất lƣợng khiến chúng ta phải chuyển đổi nhiệm vụ và có thể phải chữa cháy. Chúng ta tự nhiên phải đặt một công việc mà chúng ta đang làm sang một bên để sửa chữa một lỗi nghiêm trọng hoặc các vấn đề có tính khả dụng trong sản phẩm, khi đó sau nửa ngày các vấn đề cuối cùng cũng đƣợc sửa xong thì chúng ta không thể nhớ ra các vấn đề phức tạp nào mà chúng ta đang làm trƣớc đó và phải mất thêm nửa giờ trở lại trạng thái làm việc lúc đầu.
* Trực quan các chính sách
Làm thế nào để đƣa các chính sách vào phát triển phần mềm? Chúng ta đã trực quan công việc trên bảng và đặt ra giới hạn công việc trên đó. Tất cả là ta cần làm bây giờ là thêm các chính sách ta đang sử dụng để đảm bảo chất lƣợng và tính nhất quán. Để làm điều này, bảng của ta có thể nhƣ hình 3.5.
Lƣu ý rằng toàn bộ các giai đoạn có thể có chính sách bảo đảm chất lƣợng và các chính sách đó cũng có thể đƣợc dùng để bảo đảm tính nhất quán và chất lƣợng trong chính quy trình của nó (ví dụ theo dõi cycle time và tỷ lệ lỗi).
Hình 3.5: Chính sách rõ ràng hiển thị trên bảng
Luôn luôn ghi nhớ rằng ta không bao giờ là nô lệ cho các chính sách và các danh sách kiểm tra của chính chúng ta. Chúng ta là một nhân viên có kiến thức chuyên môn không ngừng học hỏi và cố gắng cải tiến hệ thống ta làm việc chứ không phải là một robot. Bắt đầu bằng cách thêm các thủ tục ta đang sử dụng hiện tại và thêm/xóa/thay đổi chúng khi ta tìm ra cách thức mới tốt hơn để đảm bảo chất lƣợng. Mọi sai sót là một cơ hội để suy nghĩ về việc quản lý bên trong hệ thống nhƣ thế nào.
Khi sử dụng Kanban, điều quan trọng là tất cả mọi ngƣời cam kết tôn trọng các chính sách đã thỏa thuận (đầu tiên chúng chỉ mô tả quy trình hiện tại của chúng ta) và nó cần một quyết định của cả nhóm mới thay đổi đƣợc chúng. Nhớ rằng, khi muốn phá vỡ một chính sách, thƣờng là lý do tốt là khởi đầu hoàn hảo cho một cuộc thảo luận cần thiết. “Thay đổi chúng; không phá vỡ chúng” là nguyên tắc luôn luôn lặp lại nhiều lần khi thực hiện Kanban.