Mọi chức năng bắt đầu từ các ý tƣởng lờ mờ trong cột “Hàng đợi đầu vào” (hình 3.2) và kết thúc trong cột "Phát hành", nơi một chức năng đƣợc rời đi khi nó thực sự làm việc. Nguyên tắc chung là "bạn chỉ có thể quản lý công việc bạn có thể thấy".
Trực quan công việc cho một số lợi ích, quan trọng nhất là:
- Tập trung vào "tổng thể" ( Focus on “The Whole”) Có thể thể nhìn thấy chính xác công việc của chúng ta ảnh hƣởng đến những ngƣời khác nhƣ thế nào, và ngƣợc lại.
- Minh bạch (Transparency) Mọi ngƣời đều biết chính xác những gì đang xảy ra và không có thông tin nào bị che dấu.
- Xác định các lãng phí (Identifying waste) Tự nhiên chúng ta bắt đầu đặt câu hỏi về lý do tại sao chúng ta đang làm mọi thứ theo cách ta đang làm.
3.3.2 Giới hạn công việc đang tiến hành
Khi ta đã làm chủ đƣợc việc trực quan công việc, chúng ta đã sẵn sàng để tiếp tục sang bƣớc tiếp theo - hạn chế công việc đang làm (WIP).
* Hiểu về công việc đang tiến hành.
Để hiểu lý do tại sao giới hạn WIP có ý nghĩa, chúng ta xem xét thuật ngữ: Thời gian quay vòng (Cycle time ) = Công việc trong tiến trình (WIP) / lƣu lƣợng (Throughput) trên đơn vị thời gian.
Cycle time mô tả thời gian một hạng mục công việc đi qua hệ thống của chúng ta, hoặc nói cách khác, "bao nhiêu lâu từ lúc một chức năng đƣợc lựa chọn để thực hiện cho đến khi nó đƣợc dùng trong sản xuất". Xác định việc "lựa chọn để thực hiện" nhƣ thế nào phụ thuộc vào hoàn cảnh của chúng ta.
WIP mô tả số lƣợng công việc đang xử lý của hệ thống. Có bao nhiêu “story points”/”user stories”/”backlog items” hiện tại đang tiến hành trong hệ thống? Nó phụ
thuộc vào hoàn cảnh. Một số ngƣời cho rằng nó bao gồm tất cả các hạng mục đang chờ xử lý, trong khi những ngƣời khác cho rằng nó chỉ bao gồm các hạng mục đƣợc lựa chọn để thực hiện.
Lƣu lƣợng trên đơn vị thời gian đơn giản là số lƣợng trung bình của công việc đã hoàn thành trong một thời gian nhất định.
Điều này có nghĩa là cho một một hệ thống với 100 câu chuyện ngƣời sử dụng (công việc đang làm) và lƣu lƣợng là 2 câu chuyện ngƣời dùng trên / 1 tuần, cycle time trung bình là 100/2 = 50 tuần hoặc gần nhƣ một năm. Để giảm cycle time xuống 25 tuần có thể đƣợc thực hiện bằng cách hoặc là tăng gấp đôi lƣu lƣợng là 4 câu chuyện ngƣời dùng/ 1 tuần hoặc bằng cách giảm số lƣợng câu chuyện ngƣời dùng đang tiến hành xuống còn 50. Trong hầu hết các trƣờng hợp giảm công việc đang làm hơn là tăng lƣu lƣợng.
Chúng ta có thể ƣớc lƣợng, việc giới hạn công việc đang làm là giảm tất cả cycle time để tăng lƣu lƣợng và giảm thiểu số lƣợng công việc mà chúng ta đã đầu tƣ thời gian và nguồn lực, nhƣng vẫn chƣa tạo ra bất kỳ giá trị kinh doanh nào.
Chúng ta thực hiện việc này nhƣ thế nào? Việc đầu tiên chúng ta phải làm là tao ra sự nỗ lực tốt nhất của bản thân để xác định bao nhiêu hạng mục mà chúng ta sẽ cho phép trong mỗi giai đoạn trên bảng ở mỗi lần. Tốt nhất là để hoạt động này đƣợc dẫn dắt bởi các chính sách mà nhóm của ta có thể áp dụng.
* Trực quan các giới hạn công việc đang làm
Trực quan giới hạn nhƣ thế nào là tùy vào chúng ta. Trong hình 3.3, bảng chia các giai đoạn hoạt động thành hai giai đoạn con “đang làm” và “làm xong”, các giới hạn công việc đang làm đƣợc viết trên mỗi tiêu đề cột. Điều này có thể làm cho ta nhìn sâu sắc vào hệ thống của chúng ta đang làm việc nhƣ thế nào và đây là cách phổ biến để thực hiện nó trong công nghệ thông tin.
Hình 3.3 Trực quan các giới hạn công việc đang làm sử dụng việc đánh số trên tiêu đề cột.
* Tìm ra các giới hạn công việc đang làm đúng
Chúng ta nên thiết lập giới hạn công việc đang làm chặt chẽ ngay từ đầu. Cách thứ nhất là quan sát hệ thống của chúng ta và thiết lập các giới hạn vừa đủ cho quy trình làm việc hiện tại. Sau đó, xác định nơi tắc nghẽn và điều chỉnh giới hạn ở một thời điểm. Một cách tiếp cận triệt để hơn để thiết lập các giới hạn trên các cột ở giai đoạn hoạt động chặt chẽ hơn để hệ thống có thể để xử lý và làm bƣớc đệm cho từng giai đoạn. Sau đó, quan sát nơi mà công việc bị tích tụ lại, và nới lỏng dần cho đến khi công việc trôi qua hệ thống. Cả hai đều đòi hỏi một số kinh nghiệm, vì vậy đừng mong đợi để làm đƣợc nó ngay lần đầu tiên. Không có kết luận cuối cùng là cái nào tốt hơn, nhƣng việc thiết lập các giới hạn với các chính sách trong đầu dƣờng nhƣ sử dụng cả hai cách này.
Trong mọi tình huống, quan trọng là phải thiết lập một chính sách rõ ràng để quyết định tách hoặc thay đổi giới hạn sẽ thực hiện nhƣ thế nào. Một cách hay là cả nhóm cùng đƣa ra quyết định. Điều này đảm bảo rằng mọi ngƣời đều đƣợc nói lên ý kiến của mình và hiểu đƣợc quyết định.
Luôn luôn nhớ rằng giới hạn ban đầu là suy đoán tốt nhất, đƣợc đặt ra trong thời gian mà ở đó số lƣợng thông tin sẵn có ít nhất. Khi có đƣợc thêm thông tin về hệ thống , các giới hạn nên đƣợc điều chỉnh liên tục để chúng ta tìm ra những cách làm việc tối ƣu. Nếu vẫn đang làm việc với các giới hạn ban đầu không khác gì các giai đoạn 3 tháng sau khi bắt đầu, có thể ta đã bỏ qua bƣớc quan trọng nhất, cụ thể là bƣớc cải tiến liên tục, sẽ giới thiệu chi tiết hơn sau đây. Các giới hạn mà quá bé sẽ cản trở dòng chảy và sẽ làm cho mọi ngƣời nhàn rỗi quá lâu, trong khi giới hạn đƣợc quá lớn sẽ làm tăng thời gian quay vòng (cycle time) và sẽ làm cho hạng mục công việc trễ quá lâu.
Chúng ta sẽ nhanh chóng nhận ra với các giới hạn WIP đúng chỗ, hệ thống có thể chỉ làm việc đúng công xuất. Chúng ta cần phải kết thúc công việc rồi mới đƣợc phép bắt đầu một việc mới. Mặc dù nghe có vẻ tầm thƣờng, nhƣng nó là khái niệm cốt lõi của một hệ thống lập lịch kéo của Lean và là một công cụ mạnh mẽ đáng kinh ngạc trên
hành trình đi đên một hệ thống phân phối phần mềm hiệu quả, bền vững hơn và có thể dự đoán trƣớc đƣợc.
Một phép ẩn dụ phổ biến là hệ thống nhƣ một chuỗi các kẹp giấy. Càng kéo nó càng đi theo một đƣờng thẳng đẹp, nhƣng nếu thay vào đó ta đẩy nó, tất cả chúng đều sụp đổ với nhau trong một đống hỗn độn, mỗi mục hạng mục sẽ chặn các phần còn lại (đƣợc minh họa trong hình 3.4).