Đ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.
Hình 3. 6: Ví dụ về sơ đồ luồng tích lũy
Đƣờng cong của vùng “Hoàn thành” mô tả tốc độ làm việc của chúng ta theo thời gian, khoảng trống giữa đƣờng này và đƣờng “Công việc cần làm” có thể xác định là công việc đang làm.
- Nếu độ rộng của một phần của vùng công việc đang làm tăng lên, nó có thể là tín hiệu một tắc nghẽn đang xảy ra.
- Nếu đƣờng cong của vùng “Công việc cần làm” dốc hơn so với đƣờng cong của vùng “Hoàn thành”, đó là một tín hiệu rõ ràng ta đang thêm nhiều công việc vào hệ thống hơn khả năng của nó.
- Chiếu vào nơi đƣờng con “Công việc cần làm” và “Hoàn thành” giao nhau là nơi ƣớc chừng tốt nhất của hạn phát hành cuối cùng.
- Cycle Time trung bình và số lƣợng công việc trong hàng đợi có thể cũng có thế đƣợc tạo ra từ sơ đồ này.
* Cycle time
Mặc dù sơ luồng tích lũy sẽ cho ta biết cycle time trung bình, theo dõi cycle time của cá nhân có thể rất hữu ích về mặt dự đoán trƣớc.
Theo dõi Cycle Time thậm chí còn dễ dàng hơn việc cập nhật CFD. Tất cả các việc phải làm là đăng ký ngày bắt đầu công việc vào một hạng mục. Khi công việc đã hoàn thành, ta vẽ sơ đồ số ngày hoàn thành nó và sơ đồ của chúng ta có thể giống nhƣ trong hình 3.7. Mỗi bƣớc trên trục x đơn giản là biểu diễn một hạng mục công việc đã hoàn thành, các nhóm thƣờng chọn là đề mặc nó mà không cần đơn vị.
Mặc dù đơn giản, một biểu đồ cycle time cho chúng ta biết nhiều về việc hệ thống đang làm việc nhƣ thế nào:
- Mức độ của tính nhất quán có cao không hay là những con số rời rạc.
- Có đi đúng xu hƣớng không.
- Một cơ hội để điều tra ngƣời ở ngoài (tích cực hay tiêu cực)
Hình 3.7 Ví dụ về biểu đồ Cycle time
Nếu 90% hạng mục công việc mất dƣới một tuần, chúng ta có thể nói với khách hàng là họ có thể kỳ vọng rằng 9 trong số 10 lần, công việc sẽ đƣợc hoàn thành trong 1 tuần. Tuy nhiên, nên nhớ rằng Cycle Time là một chỉ báo lạc hậu. Điều này có nghĩa là chúng ta chỉ nhìn thấy vẫn đề sau khi chúng đã xảy ra, tự nhiên nó là quá muộn đề làm bất cứ điều gì về nó. Vì vậy chúng ta phải sử dụng các sơ đồ Cycle Time, cùng với một CFD, để có thể đóng vai trò chủ động.
* Tỷ lệ lỗi
Nhƣ đã đề cập ở trƣớc, vấn đề chất lƣợng là vô cùng tốn kém và do đó ta muốn giữ chúng dƣới con mắt thận trọng. Theo dõi tỷ lệ lỗi và tổng số lỗi trong hệ thống của chúng ta là một cách dễ dàng để đảm bảo các vấn đề của chất lƣợng trong tầm tay của mình.
Ít tổ chức sử dụng tỷ lệ khiếm khuyết nhƣ một KPI (chỉ số thực thi quan trọng - Key Performance Indicator), mặc dù thực tế nó cho ta biết nhiều về tình trạng dự án của chúng ta:
- Tại sao số các lỗi mới đang tăng lên? Chúng ta đã nới lỏng một vài chính sách đảm bảo chất lƣợng?
- Mức độ các lỗi cao nhƣ thế nào trong tuần 20 ảnh hƣởng đến cycle time.
- Cái gì tác động lên biểu đồ luồng tích lũy khi số các lỗi tăng lên.
- Thông thƣờng, luôn cẩn thận không để tạo ra quá nhiều kết luận dựa trên tập dữ liệu cá nhân. Một tuần tồi tệ có thể chỉ là một sự ngẫu nhiên. Nhìn vào xu hƣớng để xem nếu ta đang di chuyển đúng hƣớng. Hình 3.8 là một ví dụ về biều đồ tỷ lệ lỗi.
Hình 3.8 Ví dụ về biểu đồ tỷ lệ lỗi
Việc giữ tổng số các lỗi giữa 0 và 20 là một chính sách tốt cho hầu hết các dự án. Một khi danh sách lớn hơn, nó trở nên khó khăn cho ngƣời quản lý và ta phải mất thời gian kiểm tra gấp đôi đầu vào, các vấn đề lỗi thời và những thứ mà đã đƣợc cố định.
* Các hạng mục cản trở
Dòng chảy là quan trọng đối với khả năng dự đoán trƣớc của hệ thống và để cho các quy trình riêng biệt hoạt động có hiệu quả. Hầu hết mọi ngƣời làm việc trong bối cảnh linh hoạt và phi linh hoạt sẽ có kinh nghiệm là các hạng mục cản trở trong một thời gian ngắn hơn hoặc dài hơn vì nhiều lý do. Măc dù điều này sẽ hiển thị trên biểu đồ luồng tích lũy và biểu đồ Cycle Time. Hầu hết các nhóm tìm thấy nó mang lại lợi ích rõ ràng và trực quan để theo dõi khả năng của nhóm để xử lý và khắc phục các vấn đề đang chặn một hay nhiều chức năng trong hệ thống. Một vài công ty thậm chí còn sử dụng cái này nhƣ một chỉ số thực thi quan trọng hàng đầu (Key Performance Indicator -KPI), vì họ nhận thấy rằng các hạng mục bị chặn có ảnh hƣởng lâu dài trên hệ thống. Các hạng mục bị chặn nên luôn luôn đƣợc hiển thị trên bảng, và theo dõi trạng thái theo thời gian là cách tốt nhất để biết liệu nhóm đang đi đúng hƣớng. Hình 3.9 là một ví dụ về sơ đồ các hạng mục cản trở.
Hình 3.9: Ví dụ về biểu đồ các hạng mục bị chặn.
Cách thông thƣờng để trực quan các hạng mục bị cản trở trên bảng đơn giản là gắn một nhãn màu hồng tới một chức năng cụ thể, với lý do bị chặn và ngày nó bị chặn viết lên đó. Hình 3.10 biểu diễn một bảng có gắn nhãn mầu hồng đánh dấu một hạng mục bị chặn.
Hình 3.10: Trực quan hạng mục bị chặn với nhãn mầu hồng