Chính sách rõ ràng hiển thị trên bảng

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Nghiên cứu phương pháp Kanban và áp dụng phát triển phần mềm quản lý con dấu (Trang 34 - 35)

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.

3.3.4 Đo dòng chảy

Đo dòng chảy (Measure Flow) có thể là một trong những khía cạnh dễ hiểu sai và áp dụng sai nhất trong phát triển phần mềm. Thông thƣờng, các thƣớc đo đƣợc sử dụng để ngƣời quản lý dự án chịu trách nhiệm cho các lĩnh vực họ không kiểm soát đƣợc ngay từ đầu nhƣ là các chuẩn sản xuất cố định đƣợc lập ra lúc đầu.

* Hiểu về thước đo

Khi thảo luận vê thƣớc đo, một quy tắc luôn nhớ: “Hệ thống phân phối phần mềm của ta chỉ có một năng xuất nhất định”. Nếu cố gằng ép hệ thống của chúng ta vƣợt quá khả năng của nó, sẽ dẫn tới chất lƣợng thấp hơn, tốc độ không bền vững, chi phí bảo trì cao hơn, hoặc tất cả mọi thứ.

Tất nhiên ta có thể nâng cao khả năng của chúng ta theo thời gian bằng cách thuê nhiều ngƣời hơn hoặc bằng cách tối ƣu hóa quy trình. Có thể hiểu kế hoạch của ta nhƣ một công cụ để căn chỉnh, chứ không phải là chuẩn thành công, và việc đo dòng chảy của ta để xác định ta vẫn còn đúng hƣớng. Cái chúng ta muốn là hệ thống phân phối phần mềm của chúng ta có thể dự đoán đƣợc, vì vậy chúng ta có thể tạo ra các quyết định đúng về thời hạn, phụ thuộc, biên chế và phạm vi ngân sách.

* Đo cái gì?

Làm thế nào để đo đƣợc dòng chảy của chúng ta? Có thể bắt đầu với 4 cái sau đây: sơ đồ luồng tích lũy (Cumulative Flow Diagram), Cycle Time, tỷ lệ khiếm khuyết (Defect Rate) và các hạng mục cản trở (Blocked Items).

* Sơ đồ luồng tích lũy- Cumulative flow diagrams (CFD)

Sơ đồ luồng tích lũy dễ dàng hơn để cập nhật và cung cấp cho ta cái nhìn sâu hơn về tình trạng hệ thống. Với những ngƣời không quen với khái niệm CFD, chúng chỉ đơn giản là sự hiển thị tổng số công việc hiện tại trong hệ thống cho một giai đoạn theo thời gian. Điều này có thể nghe có vẻ đơn giản, nó có thể cung cấp cho ta cùng một loại thông tin nhƣ việc vẽ biểu đồ truyền thống thì còn thêm nhiều thứ nữa. Hình 3.6 là một ví dụ về CFD.

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Nghiên cứu phương pháp Kanban và áp dụng phát triển phần mềm quản lý con dấu (Trang 34 - 35)

Tải bản đầy đủ (PDF)

(68 trang)