Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng nhìn vào một bảng JIRA và tự hỏi: "Tại sao issue này lại đứng yên ở 'In Progress' suốt ba tuần?", hay "Vì sao tôi không thể kéo task này sang 'Done' dù nó đã code xong?" — thì bạn đang chạm đúng vào trái tim của bài học hôm nay: Workflow (luồng công việc).
Workflow chính là bộ "luật giao thông" của dự án. Nó quy định một issue được phép đi từ trạng thái nào sang trạng thái nào, ai được phép đẩy nó đi, và khi nào thì nó thực sự "kết thúc". Với vai trò Business Analyst (BA), bạn không chỉ là người sử dụng workflow — bạn thường là người thiết kế hoặc đề xuất workflow sao cho phản ánh đúng quy trình nghiệp vụ thực tế của doanh nghiệp. Một workflow tốt giúp cả team minh bạch về tiến độ; một workflow tồi khiến mọi người "lách luật", cập nhật trạng thái sai, và báo cáo của bạn trở nên vô nghĩa.
Trong Bài 4, chúng ta đã học về các loại Issue (Epic, Story, Task, Bug, Sub-task). Hôm nay, ta sẽ trả lời câu hỏi tiếp theo: một issue di chuyển như thế nào trong vòng đời của nó? Cụ thể, bài này tập trung vào ba khái niệm nền tảng và thường bị nhầm lẫn nhất: Status, Transition và Resolution.
Khái niệm cốt lõi
Workflow là gì?
Hiểu đơn giản, Workflow là tập hợp của các Status (trạng thái) cộng với các Transition (chuyển tiếp) mà một issue có thể đi qua trong suốt vòng đời của nó. Hãy hình dung workflow như một tấm bản đồ: các Status là những "thành phố" (điểm dừng), còn các Transition là những "con đường" nối các thành phố lại với nhau. Issue của bạn là chiếc xe di chuyển trên bản đồ đó.
Điều quan trọng cần nhớ: workflow không phải là danh sách trạng thái rời rạc. Nó là một đồ thị có hướng — từ thành phố A bạn có thể đi tới B, nhưng chưa chắc đã đi ngược lại được, trừ khi có con đường (transition) cho phép.
Status — trạng thái hiện tại của issue
Status trả lời câu hỏi: "Issue này đang ở giai đoạn nào?" Đây là thông tin hiển thị rõ ràng nhất trên board, ví dụ: To Do, In Progress, In Review, Done.
Mỗi Status thuộc về một trong ba Status Category (nhóm trạng thái) do Atlassian định nghĩa sẵn, và đây là chi tiết nhiều BA bỏ qua:
- To Do (màu xám) — việc chưa bắt đầu.
- In Progress (màu xanh dương) — việc đang được thực hiện.
- Done (màu xanh lá) — việc đã hoàn tất.
statusCategory = Done) dựa vào nhóm này chứ không dựa vào tên status cụ thể. Nếu bạn tạo một status tên Closed nhưng vô tình gán nó vào nhóm "In Progress", thì biểu đồ burndown sẽ không bao giờ "cháy" hết — một lỗi kinh điển.Transition — con đường chuyển trạng thái
Transition là hành động chuyển một issue từ Status này sang Status khác. Khi bạn bấm nút "Start Progress" để chuyển từ To Do sang In Progress, bạn đang thực thi một transition.
Một transition có thể đi kèm nhiều thành phần nâng cao mà BA cần biết:
- Conditions (điều kiện): ai được phép thực hiện transition này. Ví dụ: chỉ Assignee mới được "Resolve".
- Validators (kiểm tra): bắt buộc điền thông tin trước khi chuyển. Ví dụ: phải nhập "Fix Version" trước khi đóng Bug.
- Post Functions (hành động sau): tự động làm gì đó sau khi chuyển. Ví dụ: tự gán Resolution, tự gửi thông báo.
Resolution — vì sao issue được đóng
Đây là khái niệm gây nhầm lẫn nhiều nhất, và là kiến thức "đẳng cấp BA". Resolution trả lời câu hỏi: "Issue này đã được giải quyết theo cách nào?" Các giá trị thường gặp: Done, Won't Do, Duplicate, Cannot Reproduce.
Điểm mấu chốt: Status và Resolution là hai trường hoàn toàn khác nhau. Status cho biết issue đang ở đâu; Resolution cho biết kết cục của nó. Một issue được coi là "đã đóng" (closed) trong JIRA khi và chỉ khi trường Resolution của nó được điền (set) — bất kể tên status là gì.
Quy tắc vàng cần thuộc lòng:
- Khi issue chuyển sang status kết thúc (như
Done), transition đó phải set Resolution. - Khi issue được mở lại (reopen), transition đó phải clear Resolution (đặt về trống).
Done nhưng issue vẫn bị tính là đang mở trong báo cáo, hoặc ngược lại — status To Do nhưng JQL resolution = Done vẫn trả về nó.Workflow Scrum mặc định
Khi bạn tạo một dự án Scrum mới trên Jira, workflow mặc định thường rất gọn:
To Do → In Progress → In Review → Done
↑__________________________ ___________
(có thể quay lại các bước trước)
Mỗi mũi tên là một transition. Status Done đi kèm post function set Resolution = Done. Đây là điểm khởi đầu hợp lý, nhưng hầu hết team BA sẽ cần tùy biến nó cho khớp quy trình thật.
Tình huống thực tế
Tình huống 1 — Công ty Fintech Việt và "ổ gà" Resolution
Tại MoMo Lab (giả định), một team phát triển tính năng ví điện tử dùng workflow To Do → In Progress → Done. BA tên Linh phụ trách báo cáo sprint. Cuối sprint, Scrum Master phàn nàn: biểu đồ burndown không bao giờ chạm đáy, dù mọi người khẳng định đã làm xong 18/20 story.
Linh điều tra và phát hiện: transition sang Done được tạo thủ công nhưng quên gán post function set Resolution. Kết quả là 18 issue có status Done nhưng Resolution vẫn trống. JIRA hiểu đây là issue chưa được giải quyết, nên burndown không trừ chúng đi.
Cách khắc phục: Linh vào Workflow editor, thêm post function Update Issue Field → Resolution → Done cho transition "Close" và một validator chặn việc đóng nếu chưa nhập kết quả. Đồng thời, cô viết một bulk operation (mass transition) để re-process 18 issue cũ. Sau đó burndown chạy mượt.
Bài học: Status đẹp không có nghĩa là dữ liệu sạch. BA phải kiểm tra Resolution có được set đúng tại các transition kết thúc hay không — đây là nguyên nhân số một khiến báo cáo sai.
Tình huống 2 — Tiki và workflow "quá thông minh hóa thành dở"
Một team nội bộ tại Tiki (giả định) muốn workflow phản ánh sát quy trình: họ tạo tới 11 status — Backlog, Analysis, Ready for Dev, In Dev, Code Review, Ready for QA, In QA, UAT, Staging, Ready to Release, Released. Nghe rất chi tiết. Nhưng sau hai sprint, team kêu trời: ai cũng quên cập nhật trạng thái, board lúc nào cũng "sai sự thật".
BA Hùng được giao rà soát. Anh đo thời gian trung bình issue nằm ở mỗi status và phát hiện: Analysis, Ready for Dev, và Backlog thực ra trùng chức năng (đều là "chưa làm"); Staging và Ready to Release gần như chuyển tức thời (0–2 giờ). Anh gộp lại còn 5 status: Backlog → In Progress → In Review → In QA → Done, và dùng labels cho các sắc thái phụ thay vì tạo status mới.
Sau khi tinh giản, tỷ lệ cập nhật trạng thái đúng tăng vọt vì mỗi lần kéo issue, lập trình viên không còn phải "đoán" nên chọn status nào.
Bài học: Số lượng status nên phản ánh các điểm ra quyết định hoặc bàn giao thực sự, không phải mọi thao tác nhỏ. Workflow càng nhiều status, chi phí duy trì độ chính xác càng cao. Quy tắc kinh nghiệm: 4–6 status là vùng "ngọt" cho đa số team Agile.
Tình huống 3 — Bộ phận pháp chế ngân hàng và transition có điều kiện
Tại một ngân hàng ở TP.HCM, phòng Compliance dùng JIRA để theo dõi các yêu cầu thay đổi quy trình. Yêu cầu nghiệp vụ: một issue không được phép chuyển sang Approved nếu chưa có trưởng phòng phê duyệt, và mọi issue bị từ chối phải ghi rõ lý do.
BA Mai thiết kế workflow như sau: transition "Approve" có Condition giới hạn ở nhóm compliance-managers — nghĩa là nút "Approve" chỉ hiện ra với trưởng phòng. Transition "Reject" có Validator bắt buộc điền trường "Rejection Reason". Khi "Reject", một post function tự động gán lại issue cho người tạo và gửi thông báo.
Kết quả: quy trình tuân thủ được "ép" ngay trong công cụ, không phụ thuộc vào việc con người nhớ làm đúng. Kiểm toán viên rất hài lòng vì mọi quyết định đều có dấu vết.
Bài học: Conditions, Validators và Post Functions biến workflow từ một bảng theo dõi thụ động thành một bộ máy thực thi quy trình nghiệp vụ. Đây chính là nơi BA tạo ra giá trị lớn nhất.
Hướng dẫn từng bước
Dưới đây là cách tạo và chỉnh sửa một workflow trong Jira Cloud (giao diện công ty quản lý — company-managed project, vì team-managed project tùy biến hạn chế hơn).
Bước 1 — Xác định trạng thái nghiệp vụ trước, công cụ sau. Đừng mở Jira vội. Ngồi với team, vẽ ra giấy: một công việc đi qua những giai đoạn ra quyết định nào? Mỗi giai đoạn có một "người chịu trách nhiệm" rõ ràng không? Nếu hai giai đoạn luôn có cùng người và chuyển tức thì, hãy gộp.
Bước 2 — Truy cập Workflow editor. Vào Settings (bánh răng) → Issues → Workflows. Bấm "Add workflow" để tạo mới, hoặc copy một workflow có sẵn rồi sửa (an toàn hơn là sửa trực tiếp workflow đang chạy).
Bước 3 — Thêm các Status. Trong chế độ Diagram, bấm "Add status". Khi tạo status mới, chú ý chọn đúng Status Category (To Do / In Progress / Done). Đây là bước hay bị làm ẩu nhất.
Bước 4 — Vẽ các Transition. Kéo mũi tên từ status nguồn sang status đích. Đặt tên transition theo hành động (động từ): "Start Progress", "Send to Review", "Reopen", thay vì đặt theo tên status đích.
Bước 5 — Cấu hình transition kết thúc để set Resolution.
Chọn transition đi vào status Done. Vào tab Post Functions, thêm "Update Issue Field" → chọn Resolution → giá trị Done. Ngược lại, với transition "Reopen", thêm post function clear Resolution.
Bước 6 — Thêm Conditions và Validators nếu cần. Ví dụ thêm Condition "User is in group" cho transition phê duyệt, hoặc Validator "Field required" cho trường bắt buộc.
Bước 7 — Gắn workflow vào Workflow Scheme và áp dụng cho dự án. Workflow không tự chạy. Bạn phải đưa nó vào một Workflow Scheme, gán scheme cho từng Issue Type, rồi associate scheme đó với dự án. Jira sẽ yêu cầu bạn "migrate" các issue hiện có sang status mới.
Bước 8 — Test bằng một issue thật. Tạo một issue nháp, đẩy nó qua từng transition, kiểm tra Resolution có set/clear đúng, và Condition có chặn đúng người không.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Status với Resolution. Tạo status tên "Closed" rồi tưởng issue đã đóng, trong khi Resolution vẫn trống. Hãy luôn nhớ: Resolution mới là thứ quyết định issue đóng hay mở.
Lỗi 2 — Quên clear Resolution khi Reopen. Issue được mở lại nhưng Resolution vẫn là Done, khiến nó hiện cả trong filter "đang mở" lẫn "đã đóng". Mọi transition reopen bắt buộc phải có post function clear Resolution.
Lỗi 3 — Đặt Resolution là một trường để người dùng tự điền trên màn hình tạo issue. Đừng bao giờ cho Resolution xuất hiện trên Create screen. Issue mới mà đã có Resolution sẽ bị tính là đã đóng ngay từ đầu — một lỗi cực kỳ phổ biến.
Lỗi 4 — Quá nhiều status. Như tình huống Tiki, mỗi status thừa làm tăng chi phí duy trì độ chính xác. Ưu tiên ít status, dùng label/field cho sắc thái.
Lỗi 5 — Sửa trực tiếp workflow đang vận hành. Luôn copy ra bản nháp, sửa, test, rồi mới publish. Một transition bị xóa nhầm có thể "nhốt" hàng trăm issue ở một status không lối thoát.
Mẹo: Dùng "global/All transition" cho các hành động như Cancel hoặc Close để người dùng đỡ phải đi vòng. Nhưng kiểm soát chúng bằng Condition để tránh lạm dụng.
Mẹo: Đặt tên transition bằng động từ, đặt tên status bằng danh từ/tính từ chỉ trạng thái. Quy ước này giúp cả team đọc workflow dễ hơn nhiều.
Bài tập thực hành
- Vẽ workflow trên giấy. Lấy quy trình xử lý một Bug trong một team mà bạn biết (hoặc tự nghĩ ra một startup giao đồ ăn). Vẽ đầy đủ Status, Transition, và đánh dấu transition nào set/clear Resolution.
- Tạo workflow trong Jira. Trong một dự án thử nghiệm, tạo workflow 5 status:
Backlog → In Progress → In Review → In QA → Done. Đảm bảo transition vàoDoneset Resolution = Done.
- Thêm một global transition "Cancel" đi từ mọi status tới một status
Cancelled, với post function set Resolution = "Won't Do".
- Tạo lỗi rồi sửa. Cố tình tạo transition "Reopen" mà không clear Resolution. Tạo một issue, đóng rồi reopen nó. Chạy JQL
resolution = Donevà quan sát issue "ma" vẫn xuất hiện. Sau đó thêm post function clear Resolution và kiểm tra lại.
- Viết một đoạn mô tả ngắn (150–200 từ) giải thích cho một stakeholder không rành kỹ thuật vì sao "status Done" và "issue đã đóng" không phải lúc nào cũng giống nhau.
Tóm tắt
- Workflow = Status + Transition, mô tả vòng đời mà một issue đi qua, theo dạng đồ thị có hướng.
- Status cho biết issue đang ở đâu; mỗi status thuộc một Status Category (To Do / In Progress / Done) — yếu tố quyết định cách báo cáo và burndown hoạt động.
- Transition là con đường chuyển status, có thể gắn Conditions (ai được làm), Validators (bắt buộc thông tin), và Post Functions (tự động hóa sau khi chuyển).
- Resolution là trường riêng biệt cho biết issue được giải quyết theo cách nào. Một issue chỉ thực sự "đóng" khi Resolution được set. Luôn set Resolution khi đóng, và clear khi reopen.
- Thiết kế workflow theo các điểm bàn giao/ra quyết định thực sự; tránh tạo quá nhiều status. Với vai trò BA, bạn chính là cầu nối biến quy trình nghiệp vụ thành một workflow vừa chính xác vừa dễ dùng.