3.3.1 Trực quan quy trình làm việc
Bƣớc đầu tiên hƣớng tới việc trực quan quy trình làm việc, chính là phải hiểu hệ thống hiện tại của chúng ta hoạt động nhƣ thế nào.
* Hiểu về hệ thống cung cấp phần mềm
Để có thể đƣa ra quyết định đúng về việc làm thế nào tối ƣu quy trình làm việc, bƣớc đầu tiên là phải hiểu những gì chúng ta đang làm. Để hiểu đƣợc quy trình hiện tại của bạn cách tốt nhất là vẽ sơ đồ toàn bộ quy trình làm việc cung cấp phần mềm của chúng ta và không chỉ tập trung vào phần "phát triển".
Chúng ta có thể sử dụng bản đồ dòng giá trị (Value Stream Maps), biểu đồ trạng thái trong UML, sơ đồ quy trình công việc, hoặc một loại khác nào đó để xác định quy trình của mình.
Cách phổ biến nhất hiện nay là sử dụng khái niệm của hệ thống sản xuất Tinh gọn (Lean): bản đồ dòng giá trị (Value Stream Maps). Ở dạng đơn giản, một biểu đồ dòng giá trị mô tả các giai đoạn mà công việc của chúng ta trải qua, từ nguyên liệu thô đến thành phẩm, trong trƣờng hợp sản xuất phần mềm, từ ý tƣởng mơ hồ đến một tính năng làm việc trong sản phẩm. Điều quan trọng khi dùng nó để thấy đƣợc từng giai đoạn là hình dạng đầu tiên của thông tin. Ví dụ, một giai đoạn đƣợc gọi là "Kiểm thử" gồm nhiều việc hơn là chỉ để thử nghiệm (sửa chữa, phân tích, tái cấu trúc, thảo luận, cập nhật, vv), nhƣng kể từ khi hình dạng nguyên thủy của thông tin đến là "Kiểm thử", chúng ta sẽ xác định đƣợc công việc của chúng ta là đang trong giai đoạn "Kiểm thử", trong khi tất cả các hoạt động này đang xảy ra. Khoảng cách giữa các giai đoạn của chúng ta, nơi mà không có thông tin nào đƣợc thêm vào, đƣợc định nghĩa là "thời gian chờ đợi". Hình 3.1 cho thấy một ví dụ từ một dự án thực tế.
Hình 3.1: Ví dụ về bản đổ luồng giá trị mô tả 1 quy trình sản suất phần mềm
* Trực quan hệ thống
Khi đã có nắm đƣợc quy trình làm việc hiện tại, bƣớc tiếp theo là trực quan nó. Đơn giản nhất để làm điều này là sử dụng một tấm bảng, nhƣng nếu ta đang làm việc trong một nhóm phân tán bạn có thể sử dụng một công cụ quản lý công việc trực tuyến. Không có gì làm cho công việc của chúng ta có thể nhìn thấy tốt hơn là có nó ngay trƣớc mặt chúng ta ở tất cả các thời gian và có thể chạm vào nó.
`Thƣờng thì sẽ có ít nhất hai loại giai đoạn: giai đoạn “Hoạt động”, nơi mà hoạt động công việc đang đƣợc thực hiện, và các giai đoạn “Đệm”, nơi công việc đang chờ đợi sẽ đƣợc phát hành / phát triển, nhƣng sau này có thể phát sinh nhiều hơn.
Có một bảng cho nhóm làm việc, viết lên đó những gì ta muốn, đây là công cụ quản lý trực quan nhanh chóng. Ở phiên bản đầu tiên, bảng của chúng ta có thể trông giống một vài thứ nhƣ hình 3.2 (biểu diễn tất cả công việc cần để hoàn thành một chức năng, chứ không chỉ là việc phát triển)
Hình 3.2: Quy trình làm việc đƣợc trực quan trên bảng
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.
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
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).
Hình 3.4: Kéo và đẩy
Khi thảo luận về công việc đang làm, chúng ta thƣờng tập trung kỹ lƣỡng về số lƣợng các hạng mục đang xử lý. Tuy nhiên, chúng ta không nên quên rằng kích thƣớc là quan trọng. Các hạng mục lớn sẽ chặn các nguồn tài nguyên trong thời gian dài của thời gian và sẽ tạo ra sự xáo trộn trong dòng chảy, trong khi các hạng mục nhỏ hơn sẽ chảy nhanh hơn rất nhiều thông qua hệ thống và sẽ cung cấp cho chúng ta thông tin phản hồi ngay lập tức. Phân rã các hạng mục xuống để tổi thiểu tập tính năng thƣơng phẩm nhỏ nhất, đây là một nhiệm vụ khó khăn và nó đòi hỏi trí tƣởng tƣợng cũng nhƣ kỹ năng và kinh nghiệm.
3.3.3 Thiết lập các chính sách đảm bảo chất lƣợng
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.
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