Jira với vai trò mô hình vận hành

Jira không chỉ là nơi ghi nhận ticket. Trong một tổ chức Agile, Jira là mô hình vận hành kết nối nhu cầu khách hàng, quyết định về sản phẩm, công việc triển khai và bằng chứng về tiến độ. Các lựa chọn thiết kế trong Jira quyết định liệu một nhóm có thể nhanh chóng trả lời những câu hỏi thực tế như: Chúng ta đang hướng tới kết quả nào? Việc gì đã sẵn sàng cho sprint tiếp theo? Công việc đang bị chờ ở đâu? Ai có thể thay đổi thứ tự ưu tiên? Công việc nào thực sự đáp ứng tiêu chuẩn hoàn thành đã thống nhất?

Hãy bắt đầu bằng cách xem một dự án Jira là ranh giới vận hành, không phải thư mục. Một dự án thường phục vụ một nhóm, lĩnh vực sản phẩm, dịch vụ hoặc luồng giá trị có chung backlog, workflow, nhu cầu báo cáo và quy tắc truy cập. Ví dụ, một nhóm sản phẩm phụ trách quy trình tiếp nhận khách hàng có thể dùng một dự án cho mọi công việc nhằm cải thiện việc thiết lập tài khoản. Một nhóm nền tảng riêng có thể cần dự án riêng vì nhóm này có quy trình kiểm soát phát hành, bên liên quan và công việc hỗ trợ kỹ thuật khác biệt. Tạo dự án cho từng sáng kiến sẽ làm phân mảnh báo cáo; đưa các nhóm không liên quan vào cùng một dự án thường buộc họ phải dùng một workflow thỏa hiệp.

Dự án cần có một chủ sở hữu nghiệp vụ được chỉ định và một người phụ trách triển khai được chỉ định. Chủ sở hữu nghiệp vụ chịu trách nhiệm về kết quả và các quyết định ưu tiên. Người phụ trách triển khai chịu trách nhiệm duy trì hệ thống làm việc sao cho dễ sử dụng, bao gồm tình trạng board, độ rõ ràng của workflow và kỷ luật báo cáo. Việc phân định trách nhiệm này giúp ngăn tình trạng thường gặp trong đó các trường, trạng thái và quyền ngày càng phình to mà không có người ra quyết định rõ ràng.

Chuyển hóa Product Backlog

Loại issue thể hiện các cấp độ và dạng công việc Agile khác nhau. Epic nhóm các công việc liên quan nhằm đạt được một kết quả có ý nghĩa đối với khách hàng hoặc doanh nghiệp. Story mô tả một phần giá trị nhỏ có thể hoàn thành trong một sprint. Task đại diện cho công việc cần thiết nhưng không phù hợp để diễn đạt rõ ràng thành câu chuyện về giá trị người dùng, chẳng hạn như chuẩn bị tài liệu tuân thủ. Bug ghi nhận hành vi khác với kết quả mong đợi. Sub-task chia một issue thành các phần có thể theo dõi khi mức độ chi tiết đó giúp nhóm phối hợp.

Hãy xem xét một công ty dịch vụ tài chính muốn giảm tỷ lệ bỏ dở khi mở tài khoản trực tuyến. Epic có thể là Giảm tỷ lệ bỏ dở quy trình mở tài khoản. Các Story có thể gồm lưu đơn đăng ký chưa hoàn tất, làm rõ yêu cầu xác minh danh tính và hiển thị tiến độ trong suốt quá trình đăng ký. Lỗi khiến màn hình xác minh không hoạt động trên một trình duyệt di động được hỗ trợ là Bug, không phải Story mới. Cấu trúc này giúp lãnh đạo thấy công việc đã hoàn thành đóng góp như thế nào vào mục tiêu kinh doanh mà không nhầm một Epic lớn với cam kết phù hợp cho một sprint.

Hãy sử dụng loại issue một cách nhất quán, vì phân loại thiếu nhất quán làm suy giảm chất lượng báo cáo và việc ưu tiên. Đừng tạo loại issue mới chỉ vì một bên liên quan muốn có nhãn riêng. Label, component hoặc custom field có thể là đủ. Chỉ thêm loại issue khi dạng công việc đó có vòng đời, mô hình sở hữu, nhu cầu báo cáo hoặc quy tắc hoàn thành riêng. Chẳng hạn, sự cố production có thể cần một loại issue riêng nếu chúng đòi hỏi mức độ khẩn cấp, đánh giá sau sự cố và cách xử lý quyền truy cập khác với các mục backlog thông thường.

Các trường hỗ trợ ra quyết định

Các trường chỉ hữu ích khi giúp cải thiện một quyết định được đưa ra thường xuyên. Mỗi hạng mục trong backlog cần nêu rõ mục đích và quyết định tiếp theo. Với Story, thông thường cần có phát biểu ngắn gọn về kết quả mong muốn, tiêu chí chấp nhận, mức độ ưu tiên, ước tính và liên kết đến các phụ thuộc liên quan. Phần mô tả cung cấp bối cảnh, còn tiêu chí chấp nhận nêu các điều kiện có thể quan sát để xác định hạng mục đã hoàn thành. Nhóm cần có thể thảo luận về hạng mục trong buổi refinement mà không phải tìm lại nội dung trong các cuộc trò chuyện hoặc phụ thuộc vào người yêu cầu ban đầu.

Mức độ ưu tiên thể hiện tính cấp thiết tương đối về mặt kinh doanh, không phải ai yêu cầu gần đây nhất hay ai nói lớn tiếng nhất. Hãy thống nhất một quy tắc chung. Ví dụ, Product Owner có thể xếp hạng công việc dựa trên tác động đến khách hàng, rủi ro doanh thu, mức độ ảnh hưởng đến quy định và mức độ phù hợp với chiến lược. Sau đó, nhóm có thể ước tính công sức và xác định những điểm chưa chắc chắn. Mức độ ưu tiên và ước tính trả lời hai câu hỏi khác nhau: mức độ ưu tiên giúp quyết định nên làm gì trước; ước tính giúp dự báo khối lượng công việc có thể hoàn thành trong phạm vi năng lực sẵn có.

Hạn chế các trường bắt buộc ở mức cần thiết. Yêu cầu điền mọi trường trên mọi issue sẽ dẫn đến dữ liệu kém chất lượng vì mọi người nhập nội dung giữ chỗ chỉ để tiếp tục công việc. Hãy yêu cầu thông tin vào đúng thời điểm cần đến nó. Story được đưa vào Sprint Planning cần có kết quả rõ ràng, tiêu chí chấp nhận, ước tính phù hợp với nhóm và các phụ thuộc đã biết. Bug được phân loại có thể cần mức độ nghiêm trọng, môi trường và thông tin để tái hiện lỗi. Hãy rà soát các trường tùy chỉnh không được sử dụng theo quý và xóa hoặc ẩn những trường không còn hỗ trợ việc ra quyết định.

Thiết kế quy trình làm việc có ý nghĩa

Các trạng thái nên thể hiện những giai đoạn bàn giao quan trọng, thay vì ghi lại mọi cuộc trao đổi. Một quy trình đơn giản theo hướng Scrum có thể gồm To Do, In Progress, In Review và Done. Nhóm cần xác thực từ bên ngoài có thể bổ sung Ready for Acceptance. Câu hỏi quan trọng là mỗi trạng thái có làm thay đổi việc nhóm cần làm tiếp theo, người chịu trách nhiệm hoặc cách đo lường công việc hay không. Nếu không, trạng thái đó có thể chỉ làm tăng gánh nặng hành chính thay vì tăng khả năng quan sát.

Hãy xác định rõ ý nghĩa của Done. Với một Story hướng đến khách hàng, Done có thể yêu cầu đáp ứng các tiêu chí đã thống nhất, được đồng nghiệp rà soát, vượt qua các kiểm tra tự động, được triển khai lên môi trường đã thống nhất và được Product Owner chấp nhận nếu đó là một phần trong thỏa thuận của nhóm. Trạng thái này không nên có nghĩa là quá trình phát triển đã bắt đầu, mã đã được viết hoặc ai đó cho rằng công việc có lẽ đã hoàn tất. Trạng thái Done không rõ ràng sẽ làm tăng giả tạo velocity và tạo ra sự tự tin sai lệch trong báo cáo phát hành.

Các bước chuyển trạng thái trong quy trình cũng nên cho thấy công việc đang bị cản trở. Một số nhóm dùng trạng thái Blocked; các nhóm khác giữ nguyên trạng thái hiện tại và dùng cờ hoặc trường hiển thị rõ ràng. Cách nào cũng hiệu quả nếu hỗ trợ hành động. Nhóm cần xác định trở ngại, người phụ trách, ngày ghi nhận và lộ trình báo cáo cấp cao hơn. Trong Daily Scrum, hãy xem xét các hạng mục bị cản trở hoặc đã ở trạng thái đang thực hiện quá lâu trước khi xem các công việc mới bắt đầu. Cách này chuyển trọng tâm trao đổi từ hoạt động của từng cá nhân sang dòng chảy giá trị.

Quyền và trách nhiệm chung

Phân quyền là một phần trong thiết kế hoạt động bàn giao. Những người đóng góp cần có quyền tạo, chỉnh sửa, bình luận và chuyển trạng thái cho công việc họ phụ trách. Product Owner cần có quyền sắp xếp thứ tự backlog và làm rõ yêu cầu. Các bên liên quan thường cần quyền xem và bình luận để phản hồi kịp thời mà không làm thay đổi cấu hình quy trình. Quản trị viên Jira nên giữ quyền kiểm soát các scheme, trường tùy chỉnh, automation và những thay đổi cấu hình trên diện rộng, vì một thay đổi chưa được kiểm thử có thể làm gián đoạn hoạt động của nhiều nhóm.

Hãy thiết lập quyền truy cập dựa trên mức độ nhạy cảm của công việc cũng như cơ cấu nhóm. Một dự án xử lý khiếu nại của khách hàng hoặc phát hiện bảo mật có thể cần bảo mật issue để chỉ nhóm liên quan mới xem được một số bản ghi nhất định. Hạn chế đó cần có mục đích rõ ràng và được ghi lại; giữ bí mật quá mức sẽ cản trở cộng tác và khiến việc tháo gỡ trở ngại khó khăn hơn. Khi công việc trải rộng qua nhiều dự án, hãy dùng liên kết issue và các bước bàn giao đã thống nhất thay vì cấp quyền quản trị rộng như một giải pháp tắt.

Một điểm kiểm tra quản trị hữu ích là đặt câu hỏi: ai có thể thay đổi điều gì, vì sao, và thay đổi đó được ghi lại qua dấu vết kiểm toán nào? Ví dụ, Delivery Manager có thể được quyền quản lý board, trong khi chỉ Product Owner mới được thay đổi mức độ ưu tiên kinh doanh của các hạng mục backlog đã cam kết. Thiết kế cụ thể tùy theo tổ chức, nhưng quyền ra quyết định phải đủ rõ để việc thay đổi mức độ ưu tiên không âm thầm làm vô hiệu hóa Sprint Goal.

Kiểm tra hệ thống

Cấu hình Jira cần được kiểm tra như bất kỳ quy trình kinh doanh nào khác. Ít nhất một lần mỗi sprint, hãy xem xét liệu các cột trên board có tương ứng với trạng thái thực tế của quy trình làm việc hay không, công việc có được chuyển tiếp kịp thời hay không và liệu các hạng mục có còn mở vì tiêu chí chấp nhận chưa hoàn tất hay không. Số lượng issue lớn ở trạng thái In Progress thường cho thấy lượng công việc đang thực hiện quá nhiều, quyền sở hữu chưa rõ ràng hoặc các yếu tố phụ thuộc chưa được giải quyết. Thêm việc hiếm khi khắc phục được vấn đề đó.

Hãy dùng báo cáo để gợi mở quyết định, không phải để đánh giá từng cá nhân. Mức độ hoàn thành Sprint Goal cho biết nhóm có đạt được kết quả dự kiến hay không. Cycle time cho thấy công việc mất bao lâu từ lúc bắt đầu thực hiện đến khi hoàn tất. Công việc tồn đọng lâu giúp xác định những hạng mục có thể đang bị đình trệ. Biểu đồ luồng tích lũy có thể cho thấy hàng đợi ở bước xem xét hoặc chấp nhận đang tăng lên. Các chỉ số này hữu ích nhất khi được thảo luận cùng với nguyên nhân thực tế, chẳng hạn như môi trường kiểm thử dùng chung, phản hồi chậm từ các bên liên quan hoặc phạm vi công việc quá lớn.

Cách kiểm chứng thiết lập Jira có thực tiễn hay không rất đơn giản: một thành viên mới trong nhóm phải có thể hiểu cấu trúc phân cấp, nhận biết việc gì quan trọng ở thời điểm hiện tại, cập nhật công việc mà không gặp trở ngại không cần thiết và nhận ra khi nào cần trợ giúp. Hãy bắt đầu với một thiết kế nhỏ gọn và nhất quán. Chỉ thay đổi khi bằng chứng thực tế từ quá trình bàn giao cho thấy mô hình hiện tại cản trở việc đưa ra quyết định tốt hơn hoặc che khuất một rủi ro thực sự.