Chƣơng 3 PHƢƠNG PHÁP KANBAN
3.3.8 Thiết lập thỏa thuận mức độ dịch vụ
Việc theo dõi sự thực thi của hệ thống sẽ cho ta khả năng thiết lập các thỏa thuận mức độ dịch vụ mà ta thực sự đáp ứng. Điều này sẽ giúp ta giữ cho hệ thống đúng vị trí và tránh đƣợc những trở ngại truyền thống nhƣ việc chữa cháy và xáo trộn một khi các sáng kiến của Kanban không còn mới và tỏa sáng nữa. Vậy làm thế nào để thực hiện điều này.
* Thiết lập thỏa thuận mức độ dịch vụ đúng
Trong khi các phƣơng pháp linh hoạt truyền thống nhƣ Scrum, đặt giá trị cao vào khả năng dự đoán về mặt cam kết, thì một hệ thống Kanban làm việc trên niềm tin rằng ta sẽ đạt đƣợc khả năng dự đoán bằng cách có một hệ thống phân phối phần mềm mà làm việc trong một cách dự đoán đƣợc. Có một sự khác biệt rất nhỏ giữa hai cách tiếp cận khả năng dự báo này, mà không nên đánh giá thấp. Một là dựa trên phƣơng pháp định hƣớng lập kế hoạch (plan-driven approach) trong khi cái kia đƣợc dựa trên dòng chảy (flow-based).
Một thỏa thuận mức độ dịch vụ nên bao gồm mục tiêu thời gian thực hiện từ khi một mục công việc đi vào hàng đợi đầu vào tới khi nó đƣợc chuyển giao. Mức độ dịch vụ đại diện cho lời hứa với khách hàng cho một mục công việc của một loại nhất định của lớp dịch vụ.
Các mục công việc nên đƣợc theo dõi và đo đạc khi chúng chuyển từ bƣớc này sang bƣớc kia qua hệ thống. Hiệu suất của các mức độ dịch vụ nên đƣợc theo dõi và báo cáo tại các cuộc họp báo cáo hoạt động. Các cải tiến quy trình nên đƣợc thực hiện để cải tiến khả năng dự đoán sự hứa hẹn với khách hàng đƣợc xác định trong mức độ dịch vụ. Các mức độ dịch vụ nên khớp với năng lực của hệ thống, hệ thống đƣợc cải tiến để khớp với mong đợi của khách hàng và nhu cầu của thị trƣờng.
Nếu xử lý các lớp dịch vụ khác nhau cùng một cách ở mọi lần và đo kết quả các nỗ lực cải tiến, rất có thể là cycle time, chất lƣợng và chi phí sẽ cải thiện theo thời gian. Điều này cung cấp cho ta thấy khả năng chia sẻ dữ liệu này với khách hàng. Các lớp dịch vụ đƣợc đề cập trƣớc đó có thể nhận đƣợc một thỏa thuận mức dịch vụ giống thế này:
-Lớp chuẩn Thỏa thuận mƣc dịch vụ Trung bình: 15 ngày 90% trong vòng 15 ngày Tất cả trong vòng 30 ngày. -Lớp xúc tiến nhanh Thỏa thuận mức dịch vụ
Trung bình 2 ngày 90% trong vòng 3 ngày Ttất cả trong vòng 4 ngày -Lớp cố định hạn chót Thỏa thuận mức dịch vụ 98% trong thời hạn -Lớp ƣu tiên Thỏa thuận mức dịch vụ Trung bình : 8 ngày 90% trong vòng 13 ngày tất cả 18 ngày
Điều quan trọng ở đây là để chúng ta biết những con số này, không phải vì dự đoán bị hạn chế mà bởi vì chúng ta đang theo dõi việc thực thi của hệ thống và đã thu thập đƣợc dữ liệu cần thiết. Nếu một nhu cầu phát sinh cho chúng ta nhƣ phải cung cấp thông tin chi tiết hơn, chúng ta có thể dễ dàng điều chỉnh các số liệu của chúng ta cho phù hợp. Ví dụ nó chỉ ra rằng các hạng mục công việc của lớp chuẩn khác nhau rất nhiều về kích cỡ, chúng ta có thể muốn thêm vào các chi tiết sau để cho thấy các khách hàng của chúng ta hiệu quả trực tiếp.
-Lớp chuẩn
Thỏa thuận mức dịch vụ: 200-300 câu chuyện (Lớn) Trung bình 21 ngày
90% trong vòng 25 ngày Tất cả trong vòng 30 ngày
Thỏa thuận mức dịch vụ 100-200 câu chuyên (Vừa) Trung bình 13 ngày
90% trong vòng 18 ngày Tất cả 25 ngày
Thỏa thuận mức dịch vụ 10 – 100 câu chuyện (Nhỏ) Trung bình: 10 ngày
90% trong vòng 14 ngày Tất cả 18 ngày.
Đối với nhiều khách hàng, thông tin này rất có giá trị về mặt xác định ƣu tiên, điều này cho thấy một lƣợng lớn độ tin cậy và hợp tác vƣợt xa những gì mà hầu hết đã trải qua trong các dự án trƣớc đây. Ngoài ra, điều này sẽ cho thấy lợi ích trực tiếp của việc phân rã công việc thành các kích cỡ nhỏ hơn, cả về rủi ro, chi phí và thời gian quay vòng.
Giữ cho một chu kỳ liên tục cải tiến là yêu tố khó khăn và quan trọng nhất khi thực hiện Kanban. Nhƣ đã đề cập ở các bƣớc trƣớc, Kanban là một phƣơng pháp hƣớng tới sự thay đổi tiến hóa, và tin tức tốt đi qua các bƣớc trƣớc sẽ làm cho quy trình này liên tục cải tiến dễ dàng hơn rất nhiều.
Số lƣợng thông tin phát ra cuối cùng đƣợc tạo ra thông qua sự trực quan của quy trình làm việc, các chính sách rõ ràng và các thỏa thuận mức dịch vụ cho mỗi lớp dịch vụ đã chứng minh là để thúc đấy một cuộc đối thoại về các cơ hội cải tiến xa hơn những cái đã thấy trong các dự án truyền thống. Hàng ngày chúng ta bị ép phải đƣa ra các quyết định đúng về cách tốt nhất để xử lý công việc trong hệ thống. Trong khi đó là một cơ sở tốt cho cải tiến liên tục, thực tế này cũng có vẻ kích động một sự hiểu biết sâu sắc hơn về khái niệm Agile và Lean cho những ngƣời đang làm việc trong hệ thống Kanban và do đó ít có khả nằng trở lại với các quy trình cũ.
Kể từ lúc chúng ta thu thập dữ liệu thực tế, Kanban cũng cho chúng ta cơ hội để thực hiện và phê duyệt các thử nghiệm của chúng ta trong một cách khoa học hơn các dự án Agile truyền thống. Các sáng kiến để cải tiến cycle time dẫn đến một hiệu quả có thể đo đƣợc thực sự. Điều này tạo ra việc cải tiến liên tục trong một hệ thống Kanban nhiều tin cậy hơn và từ khi chúng ta nhìn thấy và đo đƣợc hiệu quả của các sáng kiến thay đổi của chúng ta, chúng ta có khả năng tiếp tục nâng cao.
Đối với một vài ngƣời, làm việc với Kanban là lần đầu tiên họ bắt đầu thấy một hệ thống phân phối phân mềm là một tổng thể. Điều này cho phép một cái nhìn sâu sắc rộng lớn vào công việc của ngƣời khác, chúng phụ thuộc vào ta nhƣ thế nào, và ngƣợc lại. Điều này cũng có nghĩa là các cơ hội để tối ƣu hóa nhiều hơn là các ấp ủ cá nhân phát sinh trong các cuộc thảo luận giữa các nhóm liên quan. Nếu tình cờ nhìn thấy một tester, chủ sở hữu sản phẩm và một nhà phát triển thảo luận việc cải tiến dòng chảy bên cạnh một bảng Kanban, có thể chắc chắn rằng chúng ta đang tiến hành tốt.
3.4 Kết chƣơng
Các bƣớc trên có thể là đầy đủ để hƣớng dẫn làm thế nào để sử dụng một hệ thống Kanban đầy đủ. Có nhiều yếu tố khác, nhiều điểm tốt để xem xét, nhiều kịch bản và các tình huống để khám phá cần nghiên cứu bổ xung và sự hiểu biết.
Ví dụ, vẫn có những vấn đề mà sẽ cần đƣợc xử lý trong hệ thống của tổ chức. Chúng ta sẽ đi vào các tình huống mà không có một ai trong nhóm suy nghĩ về nó trƣớc đó, sẽ cần đối phó với chúng một cách thích hợp. Mục tiêu của hệ thống Kanban là giám sát và cải tiến quy trình. Tập trung vào dòng chảy công việc thông qua quá trình, cải tiến lợi nhuận của quy trình. Chúng ta muốn chắc chắn rằng công việc đƣợc thực hiện cành nhanh càng tốt, càng chính xác càng tốt, và chi phí thấp nhất có thể mà không bị mất chất lƣợng.
Cách tiếp cận tốt nhất để làm việc với phƣờng pháp Kanban là hãy bắt đầu. Không cần thiết phải thực hiện 5 nguyên lý cốt lõi ban đầu. Chúng có thể đƣợc giới thiệu dần dần và đƣợc điều chỉnh với nhu cầu của tổ chức và văn hóa của nó.
Chƣơng 4. ÁP DỤNG PHƢƠNG PHÁP KABAN VÀO PHÁT TRIỂN PHẦN MỀM QUẢN LÝ CON DẤU
Trong chƣơng 3, chúng ta biết các bƣớc để bắt đầu đƣa Kanban vào tổ chức. Phần này sẽ áp dụng thử nghiệm phƣơng pháp Kanban vào phát triển phần mềm quản lý con dấu.
Thử nghiệm đƣợc tiến hành trên phân mềm quản lý con dấu của Văn phòng Công an Tỉnh Tuyên Quang.
Vì chỉ là một bộ phận nhỏ chuyên phát triển phần mềm cho Công an tỉnh nên tổ chức cũng rất gọn nhẹ. Đứng đầu là trƣởng phòng, ngƣời đóng vai trò đƣa ra các quyết định, đồng thời cũng là ngƣời trực tiếp quản lý các dự án. Ngoài ra còn có đội trƣởng phụ trách công việc chung của nhóm phát triển. Nhóm gồm 3 ngƣời, đứng đầu là trƣởng nhóm (đội phó). Gọi chung là nhóm phát triển nhƣng cả 3 thành viên sẽ đảm nhận tất cả công việc liên quan đến chuyên môn nhƣ: phân tích, thiết kế, lập trình, kiểm thử, triển khai, bảo trì….
Đối với những ngƣời lãnh đạo (Trƣởng phòng, đội trƣởng) – ngƣời chịu tránh nhiệm về sản phẩm, đây là những ngƣời hiểu rõ chuyên đặc trƣng trong ngành công an, luôn ủng hộ việc đƣa ra và áp dụng các cải tiến. Đây cũng là một trong những điều kiện tốt để có thể áp dụng mô hình thử nghiệm.
4.1 Quy trình làm việc hiện tại
Việc đƣa phƣơng pháp Kanban vào tổ chức phải đƣợc tiến hành dần dần từng bƣớc, bƣớc đầu tiên là phải xác định đƣợc quy trình hiện tại. Quy trình phát triền phần mềm của chúng tôi đƣợc tổ chức nhƣ sau:
Giai đoạn 1: Khảo sát, ở giai đoạn này, bƣớc đầu là tìm hiểu hệ thống làm việc của khách hàng, sau đó lấy yêu cầu ngƣời dùng thông qua phỏng vần trực tiếp ngƣời có chuyên môn, nghiệp vụ. Kết quả công việc của giai đoạn này là tập các yêu cầu ngƣời dùng cuối cùng. Giai đoạn này chúng tôi thƣờng mất 3 tuần để hoàn thành,
Giai đoạn 2: Lập kế hoạch, đây là giai đoạn phân bổ công viêc cho mọi ngƣời và hạn chế thời gian hoàn thành. Việc lập kế hoạch chỉ diễn ra vào 2 giờ đồng hồ,
Giai đoạn 3: Phát triển, các thành viên trong nhóm tiến hành phát triển số lƣợng công việc của mình đƣợc giao cho đến khi hoàn thành phiên bản đầu tiên với đầy đủ các yêu cầu. Giai đoạn này thƣờng mất 4 tháng,
Giai đoạn 4: Đƣa ra sản phẩm, phiên bản đầu tiên sẽ đƣợc đƣa ra cho ngƣời dùng thẩm định. Nếu họ thỏa mãn thì đƣa vào sử dụng, nếu họ yêu cầu sửa đổi, bổ xung thì quay lại giai đoạn phát triển để cập nhật sản phẩm.
Giai đoạn 5: Bảo trì, khi sản phẩm đƣợc đƣa vào sản xuất, khách hàng có yêu cầu tiếp về sản phẩm thì lại quay về giai đoạn phát triển để cập nhật sản phẩm tiếp.
Giai đoạn 6: Kết thúc, khi khách hàng đã thỏa mãn với sản phẩm, sản phẩm cuối đƣợc chuyển giao cho khách hàng thì tiến hành kết thúc dự án.
Hình 4.1 Biểu đồ trạng thái UML mô tả quy trình làm việc
Khi đã hiểu quy trình làm việc hiện tại của mình, chúng tôi trực quan nó lên một cái bảng. Vì nhóm phát triển chỉ là một bộ phận nhỏ của văn phòng, nên không gian làm việc nhỏ và không có sự riêng tƣ nên sau buổi thảo luận giữa các thành viên trong nhóm chúng tôi quyết định sử dụng một công cụ quản lý điện tử. Có rất nhiều công cụ quản lý điện tử để lựa chọn, chúng tôi sử dụng kanban tool để phục vụ cho việc quản lý của mình. Đây là bảng Kanban online. Để sử dụng bảng online này chúng tôi đăng ký tài khoản của mình trên trang http://kanbantool.com/ và tạo bảng làm việc cho cả nhóm - Ban đầu, bảng của chúng tôi có dạng nhƣ hình 4.2
Sản phẩm cuối Khảo sát Phân bổ năng lực, hạn chế thời gian Lấy yêu cầu ngƣời dùng Thiết kế Xây dựng Kiểm thử Cập nhật sản phẩm Kết thúc Bảo trì Đƣa ra sản phẩm Phát triển Lập kế hoạch Khách hàng phê duyệt 3 tuần 2 giờ 4 tháng 1 ngày
Hình 4.2 Trực quan quy trình làm việc hiện tại của nhóm làm việc
4.2 Phát triển phần mềm4.2.1 Giai đoạn khảo sát 4.2.1 Giai đoạn khảo sát
Công việc chính chúng tôi thƣờng làm ở giai đoạn này là:
- Khảo sát: Tìm hiểu về khách hàng, những lĩnh vực hoạt động của khách hàng, gặp gỡ ngƣời đứng đầu, để từ đó có một cái nhìn chung về những công việc của khách hàng. Thực hiện bằng cách nghiên cứu các tài liệu, thảo luận. Sau bƣớc này, cần chỉ ra các mảng cần phải lấy yêu cầu, cũng nhƣ cần phải làm việc với những ai để cụ thể hoá yêu cầu.
- Xác định yêu cầu chung: Sau khi khảo sát, cần tiến hành gặp gỡ những ngƣời có chuyên môn, nghiệp vụ phù hợp để đƣa ra đƣợc các yêu cầu chung nhất. - Chi tiết hoá các yêu cầu: Các thông tin ban đầu sau khi đƣợc phân tích sơ bộ
sẽ đƣợc tập hợp lại, phân thành các đầu mục nhỏ hơn. Chúng tôi thƣờng làm công việc này bằng cách gặp trực tiếp khách hàng để hỏi trực tiếp ngƣời có chuyên môn, nghiệp vụ. Công việc này có thể đƣợc tiến hành nhiều lần để có thể thu đƣợc một tập hợp các phiếu yêu cầu đầy đủ và rõ ràng.
Giai đoạn này công việc chủ yếu là gặp gỡ khách hàng, sau khi có thông tin bƣớc đầu về công việc của khách hàng, chúng tôi phân tích sơ bộ những thông tin này, để xác định phần nào đƣợc phát triển, phần nào không cần thiết đƣa vào hệ thồng. Buổi phân tích đƣợc thảo luận trƣớc bảng làm việc của nhóm. Tất cả các thông tin ban đầu của khách hàng đƣợc trực quan trên bảng. Mỗi công việc của khách hàng đƣợc ghi vào một thẻ. Thông tin trên mỗi thẻ hiển thị đầy đủ các mô tả về mỗi công việc nhƣ: Tên công việc, vị trí ngƣời thực hiện nó, thực hiện nó qua những bƣớc nào...Hình 4.4 ví dụ về thông tin công việc trên một thẻ. Sau khi trực quan công việc của khách hàng chúng tôi lần lƣợt thảo luận về các công việc này và đƣa ra quyết định cuối cùng. Mỗi thẻ thảo luận xong, nếu công việc ghi trên đó đƣợc giữ lại phát triển sẽ đƣợc gắn sang
phần làm xong của cột khảo sát, công việc nào không cần đƣa vào phát triển chúng tôi sẽ rời nó đi. Các thẻ đƣợc giữ lại sẽ đƣợc tái sử dụng cho lần làm việc tiếp theo trong ở giai đoạn này. Hình 4.3 mô tả các thẻ công việc đƣợc gắn vào bảng làm việc.
Hình 4. 3 Gắn thẻ công việc vào bảng
Sau khi đã xác định đƣợc các yêu cầu chung cần giữ lại để phát triển, chuyển sang bƣớc tiếp theo là chi tiết hóa các yêu cầu. Chúng tôi lại có buổi làm việc với khách hàng dể lấy các thông tin chi tiết cho các yêu cầu.
Khi đã có thông tin chi tiết chúng tôi, bắt đầu dựa vào đó để phân rã các yêu cầu chung đã đƣợc tập hợp trong các thẻ trên bảng. Ở bƣớc chi tiêt hóa yêu cầu này, các thẻ đƣợc sử dụng lại sẽ đƣợc gắn lại vào phần đang tiến hành, trên thẻ sẽ đƣợc ghi tên ngƣời thực hiện, ngày thực hiện, ngày kết thúc. Nhiệm vụ của mọi ngƣời trong nhóm là phân rã các yêu cầu có ghi tên mình trên thẻ.
Giai đoạn chi tiết hóa các yêu cầu đƣợc lặp nhiều lần để đƣa ra đƣợc các yêu cầu đầy đủ rõ ràng
Hình 4.4 Thông tin chi tiết một thẻ công việc
Do chƣa có kinh nghiệm làm việc với Kanban, nên ở giai đoạn này chúng tôi chƣa thể giới hạn công việc đang làm (WIP). Ở giai đoạn này chính sách của nhóm là: sử dụng phƣơng pháp phỏng vấn trực tiếp khách hàng để lấy thông tin. Sau 2 tuần làm việc đầu tiên, chúng tôi đã thu đƣợc một tập các yêu cầu ngƣời dùng.
Dƣới đây là quy trình cấp phát và quản lý con dấu:
- Đơn vị tổ chức đƣợc cơ quan có thẩm quyền cho phép sử dụng con dấu sẽ nộp