Jira
Jira là công cụ quản lý dự án và theo dõi issue phổ biến cho đội ngũ phát triển. Hỗ trợ Scrum/Kanban, backlog, sprint, theo dõi lỗi, báo cáo, phù hợp với phát triển phần mềm.
- Jira Cloud
- Điều hướng & Tìm công việc
- Quản lý không gian
- Làm việc
- Tạo với Scrum & Kanban
- Theo dõi và phân tích
- Tự động hóa
- Phân quyền & Vai trò
- Bảo vệ dữ liệu
- Lập kế hoạch và Xem công việc
Thiết lập Jira Cloud
Hướng dẫn cho người mới • Jira Cloud- Tạo hoặc tham gia một site Jira Cloud, sau đó xác nhận bạn truy cập đúng không gian (project/dự án).
- Chốt sớm: dự án do công ty quản lý (company-managed) hay do team quản lý (team-managed) — lựa chọn này ảnh hưởng trực tiếp tới cấu hình và quản trị.
- Kết nối các công cụ quan trọng (Confluence, Slack, nhà cung cấp Git) để work item luôn có đủ ngữ cảnh.
Mục đích / Kết quả
Có một site Jira Cloud “chạy được” để team dùng thật: bạn đăng nhập được, vào đúng không gian/dự án, và tạo work item với các trường cần thiết. Phần này tập trung vào các quyết định setup trong ngày đầu để tránh phải làm lại đau đầu về sau.
- Xác nhận bạn đang ở đúng Atlassian cloud site (kiểm tra URL và tên site).
- Xác nhận vai trò: site admin vs product admin vs project admin (quyết định bạn sửa được gì).
- Chọn template khởi đầu khớp workflow (Scrum, Kanban, business, ...).
- Xác định bộ “trường bắt buộc” tối thiểu cho work item (người phụ trách, hạn chót, độ ưu tiên, ...).
- Đặt quy ước đặt tên cho không gian/dự án và board để việc tìm kiếm luôn gọn, sạch.
Mô hình tư duy / Luồng
Hãy nghĩ theo tầng: Site → Không gian (project/dự án) → Board/View → Work item. Phần lớn công việc hằng ngày diễn ra trong một không gian/dự án, còn admin sẽ quản lý các kiểm soát và quyền ở cấp site.
- Tạo/chọn một site và xác nhận đăng nhập (authentication).
- Tạo/chọn một không gian (project) bằng template.
- Chọn một view (board, backlog, list, timeline) phù hợp loại công việc.
- Tạo work item và chuyển chúng qua các trạng thái.
Các “việc cần làm” cốt lõi
Các việc setup phổ biến trong tuần đầu.
- Tạo một không gian/dự án mới cho team và chọn đúng template.
- Xác nhận điều hướng và trang “For you” để ai cũng tìm được việc nhanh.
- Tích hợp Jira với các app Atlassian khác và công cụ bên ngoài.
- Import công việc hiện có (CSV hoặc nguồn khác) vào Jira.
- Chốt cách theo dõi release/versions (nếu bạn phát hành phần mềm).
Nên / Không nên & Bẫy thường gặp
- Nên: Dùng một quy ước đặt tên cho project, board và component.
- Nên: Giữ số field bắt buộc ở mức tối thiểu để người mới thao tác không bị “vấp”.
- Nên: Thử nghiệm với một nhóm pilot nhỏ trước khi rollout toàn tổ chức.
- Không nên: Thêm hàng chục custom field ngay ngày 1 “phòng khi cần”.
- Không nên: Trộn team-managed và company-managed nếu chưa có kế hoạch governance rõ ràng.
- Không nên: Bỏ qua permissions — cấu hình sai sẽ gây hỗn loạn “tôi không thấy/không sửa được”.
Dữ liệu & Tích hợp
Jira Cloud có thể kết nối với các app Atlassian khác và app bên ngoài để work item liên kết trực tiếp tới code, tài liệu và chat.
- Kết nối Confluence để chia sẻ board, backlog, dashboard và thông tin release ngay trong trang tài liệu.
- Liên kết công cụ phát triển để work item hiển thị commit, branch, PR và deployment (nếu bật).
- Dùng app Marketplace khi cần workflow đặc thù (nhưng hạn chế “nở” app quá sớm).
- Lên kế hoạch import: map cột sang field và chạy một lần import thử nhỏ trước.
Thế nào là “tốt”
- Người dùng mới tìm được việc được giao trong dưới 30 giây.
- Mỗi work item đều có người phụ trách, mô tả ngắn rõ ràng, và trạng thái tiếp theo.
- Board phản ánh thực tế: cột khớp các bước thật, không phải “quy trình ước mơ”.
- Tích hợp bổ sung ngữ cảnh (link, thông tin dev) nhưng không làm ngập thông báo.
Checklist: Pre-check + Post-check
Pre-check (trước khi mời tất cả)
- Site + đăng nhập đã xác nhận cho admin.
- Đã tạo 1 không gian/dự án khởi đầu bằng template.
- Chốt bộ field tối thiểu (người phụ trách, độ ưu tiên, hạn chót).
- Team truy cập được board/view.
- Đã rà soát mặc định thông báo (tránh spam).
Post-check (sau 1 tuần pilot)
- Người dùng tạo và chuyển trạng thái work item được.
- Tìm kiếm ra công việc theo field chính (assignee, status).
- Các tích hợp quan trọng đã kết nối và dùng ít nhất 1 lần.
- Các điểm hay gây nhầm được ghi lại (note nội bộ ngắn).
- Vấn đề quyền đã được xử lý bằng một cách sửa lặp lại được.
Bài thực hành (5–15 phút)
Mục tiêu: Tạo một không gian/dự án khởi đầu và 1 work item, rồi xác nhận điều hướng.
- Tạo không gian/dự án mới với template phù hợp team.
- Tạo 1 work item có summary, description, người phụ trách và độ ưu tiên.
- Ghim (star) không gian/board để nó xuất hiện trong mục yêu thích ở sidebar.
- Dùng search để tìm work item theo từ khoá và theo assignee.
Luồng chuẩn (Happy paths)
Happy path #1 — Tạo một không gian/dự án khởi đầu
- Vào Jira home và chọn tạo một không gian/project mới.
- Chọn template (Scrum, Kanban hoặc business) khớp workflow.
- Đặt tên theo quy ước của team (vd: TEAM-PRODUCT).
- Mời 2–5 người dùng pilot và xác nhận họ mở được board.
- Tạo 1 work item mẫu và gán cho một người trong nhóm pilot.
- Nhờ nhóm pilot kéo item qua các trạng thái để xác nhận luồng chạy đúng.
Happy path #2 — Kết nối một tích hợp bạn dùng mỗi ngày
- Chọn 1 tích hợp có giá trị ngay (vd: Confluence hoặc công cụ chat).
- Kết nối app từ phần cài đặt tích hợp của Jira hoặc Marketplace.
- Liên kết 1 work item với một “vật chứng” bên ngoài (page, PR, deployment, ...).
- Xác nhận ngữ cảnh liên kết hiển thị trên work item.
- Kiểm tra thông báo: đảm bảo team nhận “tín hiệu” chứ không phải “nhiễu”.
- Ghi lại hướng dẫn 3 bước “cách liên kết” cho team.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Cần governance chặt và tiêu chuẩn dùng chung? | Ưu tiên company-managed projects (cấu hình tập trung). | Ưu tiên team-managed projects (tự chủ cho team). |
| Đang migrate dữ liệu hiện có? | Import CSV thử và kiểm chứng map field trước. | Bắt đầu mới và chỉ import công việc đang active/giá trị cao. |
| Nhiều team dùng chung một workflow? | Dùng workflow và permission scheme nhất quán. | Cho mỗi team tuỳ biến không gian, nhưng phải tài liệu hoá khác biệt. |
| Chưa rõ nên tích hợp gì? | Bắt đầu từ app Atlassian trước, rồi mới thêm app ngoài. | Chỉ thêm 1 app ngoài mỗi lần và kiểm chứng tác động. |
Lỗi thường gặp (và cách tránh)
- Tuỳ biến quá nhiều ngay ngày 1
Tránh: Pilot trước, rồi thêm field/workflow dựa trên nỗi đau thực tế. - Làm người dùng rối vì quá nhiều board
Tránh: Giữ 1–2 view chính; ẩn hoặc archive các view thừa. - Không có quy ước đặt tên
Tránh: Chuẩn hoá project key, tên board và component sớm. - Bỏ qua quyền truy cập (permissions)
Tránh: Dùng khái niệm permission scheme chính thức và test bằng một user không phải admin. - Cố import tất cả mọi thứ
Tránh: Chỉ import item active/giá trị cao; phần còn lại lưu/đóng ở nơi khác.
Link tài liệu chính thức
- Jira Cloud resources — Điểm vào cho setup, quản lý project/không gian, làm việc trong project, team-managed projects và gói dịch vụ.
- Navigate to your work — Cách sidebar và trang ‘For you’ giúp bạn tìm item gần đây và item đã star.
- Use Jira Cloud with other apps — Hướng dẫn tích hợp từ Atlassian Support.
Quản lý không gian Jira Cloud (project)
Hướng dẫn cho người mới • Jira Cloud- Không gian (project) là nơi công việc của team “sống” — chọn đúng loại rồi cấu hình các view.
- Chỉ dùng component/version/timeline khi nó thực sự giúp team rõ ràng hơn.
- Giữ thay đổi cấu hình nhỏ gọn và thông báo cho người dùng.
Mục đích / Kết quả
Cấu hình một không gian Jira (project) để nó khớp với cách team bạn làm việc thực tế. Bạn sẽ thiết lập các view (board/backlog/list/timeline), cấu trúc (components/versions) và điều hướng.
- Quyết định loại project (team-managed vs company-managed) theo nhu cầu quản trị.
- Cấu hình board/view mà team dùng hằng ngày.
- Dùng components và versions để tổ chức công việc khi có ích.
- Giữ điều hướng của project gọn gàng để người mới không bị “ngợp”.
Mô hình tư duy / Luồng
Một không gian (project) là “container” có cài đặt và các view. Các thay đổi bạn làm sẽ ảnh hưởng đến cách team tạo và di chuyển work item.
- Chọn loại project (quyết định về governance).
- Thiết lập board/backlog chính hoặc list view.
- Định nghĩa cấu trúc (components, versions/releases) nếu cần.
- Rà lại điều hướng và quyền để đúng người có thể làm việc.
Đối tượng & Thuật ngữ
Các khái niệm chính bạn sẽ gặp ở khu vực này.
- Không gian / Project: Không gian làm việc cho một team, chứa work item, view và cài đặt.
- Company-managed: Cấu hình tập trung và các scheme chuẩn hoá.
- Team-managed: Team có quyền tự chủ nhiều hơn trong project.
- Component: Cách nhóm work (thường theo subsystem/khu vực).
- Version / Release: Cách lập kế hoạch và theo dõi các mốc phát hành.
- Timeline: View để nhìn lịch và phụ thuộc ở mức cao.
Các “việc cần làm” cốt lõi
- Tạo hoặc tái cấu trúc project để công việc được sắp xếp hợp lý.
- Thiết lập view Scrum/Kanban và giữ cột/trạng thái đồng bộ.
- Dùng components để điều hướng/route việc tới đúng nhóm.
- Theo dõi releases/versions để phục vụ phát hành và báo cáo.
- Chỉnh điều hướng project để làm nổi bật các view dùng nhiều nhất.
Quyền & Vai trò
Quyền truy cập cấp project được điều khiển bởi permissions và roles của Jira. Nếu bạn không phải admin, phần này có thể bị giới hạn.
- Xác nhận ai được phép tạo work item và chuyển trạng thái.
- Dùng roles để nhóm người dùng (vd: Developers, QA, Stakeholders).
- Test thay đổi bằng một tài khoản không phải admin trước khi thông báo.
- Nếu bạn không thấy phần cài đặt quyền: phối hợp với Jira admin.
Nên / Không nên & Bẫy thường gặp
- Nên: Giữ 1 board “nguồn sự thật” cho mỗi team.
- Nên: Căn cột theo đúng các bước workflow thực tế.
- Nên: Chỉ dùng components/versions khi team sẽ duy trì nó.
- Không nên: Tạo nhiều board chồng chéo cho cùng một công việc.
- Không nên: Đổi tên trạng thái mà không giải thích thay đổi gì.
- Không nên: Đổi cài đặt giữa sprint mà không có kế hoạch rollback.
Thế nào là “tốt”
- Công việc mới rơi vào một inbox/backlog rõ ràng và được triage nhanh.
- Cột và trạng thái trên board ổn định ít nhất trong một sprint.
- Components và versions được dùng nhất quán (không “điền nửa vời”).
- Stakeholders xem được tiến độ mà không cần chỉnh workflow cốt lõi.
Checklist: Pre-check + Post-check
Pre-check
- Đã chốt loại project (team-managed vs company-managed).
- Đã chọn board chính (Scrum hoặc Kanban).
- Đã thống nhất Definition of Done với team.
- Có cần components/versions không? (có/không).
- Đã chỉ định người chịu trách nhiệm cấu hình project.
Post-check
- Board khớp với các trạng thái workflow.
- Có routine triage backlog.
- Điều hướng hiển thị trước 3 view quan trọng nhất.
- Quyền đã test cho team + stakeholders.
- Đã publish 1 trang ghi chú “team dùng project này như thế nào”.
Bài thực hành (5–15 phút)
Mục tiêu: Làm cho project “dùng được” với một teammate mới.
- Mở project và xác định view chính (board/backlog/list).
- Đổi tên hoặc sắp xếp lại mục điều hướng để các view quan trọng dễ tìm.
- Tạo 1 component và gán cho 1 work item.
- Nếu phù hợp, tạo 1 version/release và gán 1 work item vào đó.
Luồng chuẩn (Happy paths)
Happy path #1 — Cấu hình project để dùng hằng ngày
- Mở project và chọn view chính (board/backlog hoặc list).
- Xác nhận trạng thái workflow khớp với quy trình thực tế.
- Thiết lập components nếu bạn cần route việc hoặc phân quyền theo khu vực.
- Thiết lập versions/releases nếu bạn theo dõi mốc phát hành.
- Dọn điều hướng: ghim view chính và ẩn các mục gây nhiễu.
- Chạy pilot: nhờ một teammate tạo và kéo một work item đi hết vòng đời.
Happy path #2 — Thêm cấu trúc nhưng không làm nó nặng nề
- Liệt kê 2–4 nhóm công việc phổ biến nhất mà team hay dùng.
- Chỉ tạo component cho nhóm có ownership rõ ràng.
- Định nghĩa pattern đặt tên version đơn giản (vd: 2026.02 hoặc v1.4).
- Cập nhật 1 work item để có component + version.
- Review với team và chỉnh tên theo “ngôn ngữ” họ dùng.
- Ghi rõ rule: khi nào dùng component, khi nào dùng version.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Cần kiểm soát tập trung cho nhiều team? | Dùng company-managed với scheme dùng chung. | Dùng team-managed để team tự chủ. |
| Cần theo dõi phát hành? | Dùng versions/releases và review mỗi tuần. | Bỏ versions; dựa vào sprint hoặc milestone chỗ khác. |
| Công việc thiên về trực quan? | Ưu tiên board và WIP limits. | Ưu tiên list/timeline nếu công việc theo lịch nhiều. |
| Nhiều nhóm con dùng chung một project? | Dùng components để tách ownership. | Tách thành nhiều project để giảm phụ thuộc. |
Lỗi thường gặp (và cách tránh)
- Quá nhiều components
Tránh: Chỉ tạo component khi có owner và mục đích dùng rõ. - Cột board không khớp trạng thái
Tránh: Căn cột theo workflow statuses để việc kéo thẻ có ý nghĩa. - Đổi cấu hình mà không báo team
Tránh: Thông báo và gửi note “đổi gì” trong 1 phút. - Tạo board trùng lặp cho cùng một việc
Tránh: Chốt 1 board chính và archive cái còn lại. - Dùng versions nhưng không cập nhật
Tránh: Gán owner và review versions định kỳ.
Link tài liệu chính thức
- Jira Cloud resources — Manage Jira Cloud spaces — Danh mục chính thức về cấu hình và quản lý project/space.
- Learn how company-managed and team-managed spaces differ — Giúp chọn mô hình governance phù hợp.
- Manage and visualize your software space on the timeline — Cơ bản về Timeline view để lập kế hoạch.
Làm việc trong các không gian Jira Cloud (work items)
Hướng dẫn cho người mới • Jira Cloud- Work item là đơn vị công việc — tạo, giao, cập nhật và kéo qua các trạng thái.
- Dùng comment, tệp đính kèm và liên kết để giữ “vì sao” và “bước tiếp theo” ngay trong work item.
- Dùng chỉnh sửa hàng loạt (bulk edit) cẩn thận để vừa nhanh vừa nhất quán.
Mục đích / Kết quả
Học các kỹ năng dùng hằng ngày: tạo, cập nhật, tìm kiếm và đẩy tiến độ work item trong Jira. Kết quả là thực thi đáng tin cậy: work item luôn đúng và board phản ánh thực tế.
- Tạo work item với đúng trường cần thiết (tóm tắt, mô tả, người phụ trách, mức ưu tiên).
- Đẩy tiến độ qua các trạng thái và cập nhật kịp thời.
- Tìm nhanh “hàng đợi” của bạn bằng search và filter.
- Phối hợp bằng comment, mention và tệp đính kèm.
Mô hình tư duy / Luồng
Work item di chuyển qua một workflow (các trạng thái). Việc của bạn là giữ trạng thái, ownership và ngữ cảnh của item luôn chính xác.
- Tạo work item → làm rõ phạm vi → gán người phụ trách.
- Lập kế hoạch (backlog/sprint) → bắt đầu làm.
- Cập nhật tiến độ (status, comment, link).
- Hoàn tất và xác nhận tiêu chí done.
Đối tượng & Thuật ngữ
Các khái niệm chính bạn sẽ gặp ở khu vực này.
- Work item / Issue: Một task, bug, story hoặc đơn vị công việc có thể theo dõi.
- Status: Một bước trong workflow (vd: To do, In progress, Done).
- Assignee: Người chịu trách nhiệm cho hành động tiếp theo.
- Reporter: Người tạo/khởi xướng item.
- Priority: Mức độ gấp/quan trọng của item.
- Work item security: Giới hạn quyền xem cho item nhạy cảm (nếu được bật).
Máy trạng thái / Vòng đời
Vòng đời điển hình dựa trên trạng thái. Instance của bạn có thể khác.
- To do → sẵn sàng để bắt đầu.
- In progress → đang được thực hiện.
- In review / QA → bước xác minh (nếu workflow có).
- Done → đạt Definition of Done của team.
Các “việc cần làm” cốt lõi
- Tạo work item mới nhanh với format nhất quán.
- Cập nhật field và status để board luôn chính xác.
- Bulk edit theo lô (vd: set component/version) một cách an toàn.
- Liên kết các việc liên quan (trùng lặp, blocker, cha/con).
- Tích hợp dev tools để code và deployments hiện ngay trên item.
Nên / Không nên & Bẫy thường gặp
- Nên: Viết summary rõ ràng (động từ + đối tượng) và mô tả phải “làm được”.
- Nên: Giữ assignee chính xác — một owner cho bước tiếp theo.
- Nên: Dùng comment để ghi quyết định và bước tiếp theo.
- Không nên: Đổi status mà không cập nhật ngữ cảnh (gây hiểu nhầm).
- Không nên: Bulk edit “mù” — luôn preview trước.
- Không nên: Tạo trùng; hãy search trước và link nếu liên quan.
Dữ liệu & Tích hợp
Work item có thể mang ngữ cảnh từ các tool khác (docs, chat, code). Dùng điều này để giảm câu hỏi kiểu “thông tin ở đâu?”.
- Liên kết trang Confluence cho spec và quyết định.
- Bật thông tin phát triển để item hiển thị branch/PR/deployment (nếu org dùng).
- Dùng form (nếu space có) để chuẩn hoá intake.
- Nếu nhạy cảm, áp dụng security level hoặc phân loại (nếu được bật).
Checklist: Pre-check + Post-check
Pre-check (trước khi bắt đầu)
- Summary rõ và cụ thể.
- Có acceptance criteria / điều kiện done.
- Đã set assignee (hoặc để unassigned nhưng có kế hoạch rõ).
- Đã link phụ thuộc (đã nhận diện blocker).
- Priority khớp mức độ gấp.
Post-check (trước khi chuyển done)
- Status đã cập nhật đúng trạng thái “done”.
- Đã ghi kết quả (comment hoặc cập nhật summary).
- Link/đính kèm đã cập nhật (PR, docs, release notes).
- Đã tạo và link các việc follow-up (nếu có).
- Đã thông báo stakeholders (nếu yêu cầu).
Bài thực hành (5–15 phút)
Mục tiêu: Tạo và đẩy tiến độ một work item với “vệ sinh” tốt.
- Tạo một work item với summary rõ và mô tả ngắn.
- Thêm 2 gạch đầu dòng acceptance criteria.
- Gán cho bạn và đặt priority.
- Chuyển sang “In progress”, thêm comment mô tả bước tiếp theo.
- Chuyển sang “Done” và thêm comment cuối ghi lại kết quả.
Luồng chuẩn (Happy paths)
Happy path #1 — Tạo work item chất lượng cao
- Search trước để tránh trùng (keyword + project).
- Tạo work item và viết summary rõ ràng.
- Thêm mô tả ngắn và 2–5 gạch đầu dòng acceptance criteria.
- Set assignee, priority và label/component mà team dùng.
- Link item liên quan (blocks/duplicates/parent) nếu có.
- Lưu, rồi share link cho team nếu cần phối hợp.
Happy path #2 — Đẩy work item từ bắt đầu đến done
- Chuyển status sang trạng thái “đang làm” đầu tiên (vd: In progress).
- Thêm comment ghi bước tiếp theo ngay lập tức (để người khác theo được).
- Khi có thay đổi, cập nhật field (priority, component, due date) thay vì để thông tin cũ.
- Nếu bị chặn, link blocker và ghi ngắn gọn bạn cần gì.
- Khi xong, xác nhận acceptance criteria đã đạt.
- Chuyển sang Done và ghi lại kết quả (kèm link bằng chứng).
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Work item chưa rõ? | Thêm acceptance criteria và làm rõ phạm vi trước khi bắt đầu. | Tách thành item nhỏ hơn nếu quá lớn. |
| Bị chặn bởi team khác? | Link blocker và comment bạn cần gì. | Escalate theo quy trình của team nếu gấp. |
| Nhiều task tương tự? | Dùng bulk edit + field nhất quán (có preview). | Edit thủ công nếu chỉ vài item. |
| Công việc nhạy cảm? | Áp dụng security/classification nếu được bật. | Tránh đăng dữ liệu nhạy cảm vào comment nếu không kiểm soát được. |
Lỗi thường gặp (và cách tránh)
- Summary mơ hồ kiểu “Fix bug”
Tránh: Nêu rõ khu vực và hành vi mong đợi. - Để item unassigned quá lâu
Tránh: Có triage owner hoặc routine để gán nhanh. - Đổi status mà không cập nhật ngữ cảnh
Tránh: Thêm comment hoặc cập nhật mô tả khi status đổi có ý nghĩa. - Quên link phụ thuộc
Tránh: Dùng link types (blocks/relates/duplicates) sớm. - Bulk edit mà không preview
Tránh: Test trên 1–2 item trước rồi mới áp dụng cả lô.
Link tài liệu chính thức
- Work in Jira Cloud spaces — Danh mục chính thức: tạo, tìm kiếm và làm việc với work items.
- Protect your team’s data — Bảo mật/phân loại và security level cho work items.
- View insights in Jira Cloud — Nơi xem insights về board/backlog/deployments.
Board, backlog & sprint (Scrum/Kanban)
Hướng dẫn cho người mới • Jira Cloud- Board giúp trực quan hoá luồng; backlog giúp lập kế hoạch; sprint “đóng khung thời gian” để thực thi.
- Giữ WIP và các cột khớp workflow để tránh board “đẹp nhưng vô dụng”.
- Groom backlog thường xuyên để sprint kế tiếp luôn sẵn sàng.
Mục đích / Kết quả
Dùng Jira board để lập kế hoạch và theo dõi công việc. Team Scrum thường dùng backlog + sprint; team Kanban tập trung vào dòng chảy liên tục và WIP. Kết quả là một board mà cả team tin tưởng.
- Hiểu view Scrum vs Kanban và khi nào nên dùng mỗi cái.
- Dùng backlog để xếp hạng và chuẩn bị công việc.
- Tạo và quản lý sprint (cho Scrum).
- Giữ các cột trên board có ý nghĩa và ổn định.
Mô hình tư duy / Luồng
Vòng lặp Scrum vs vòng lặp Kanban:
Scrum
- Groom backlog
- Lập kế hoạch sprint
- Thực thi trên board
- Review + retro
Kanban
- Kéo việc tiếp theo
- Giới hạn WIP
- Chảy đến done
- Cải tiến liên tục
Đối tượng & Thuật ngữ
Các đối tượng chính bạn sẽ gặp ở khu vực này.
- Board: Góc nhìn trực quan của work item khi di chuyển qua các cột.
- Backlog: Danh sách ưu tiên các việc sắp làm (Scrum).
- Sprint: Một vòng lặp có thời hạn, nơi team cam kết và bàn giao công việc.
- Giới hạn WIP: Trần số lượng item có thể “đang làm” cùng lúc (phổ biến trong Kanban).
- Epic: Nhóm công việc lớn gom các item liên quan (nếu project dùng).
Các “việc cần làm” cốt lõi
- Groom và xếp hạng backlog để item sẵn sàng bắt đầu.
- Tạo sprint và kéo các item đã chuẩn bị vào sprint.
- Vận hành hằng ngày trên board và giữ status chính xác.
- Tách nhỏ khi một item quá lớn cho một sprint.
- Dùng insights/reports để cải thiện planning và flow.
Nên / Không nên & Bẫy thường gặp
- Nên: Giữ cột khớp với status và định nghĩa thực tế.
- Nên: Groom backlog hàng tuần để sprint planning nhanh gọn.
- Nên: Dùng giới hạn WIP (kể cả không chính thức) để giảm switching ngữ cảnh.
- Không nên: Chuyển Done khi chưa đạt acceptance criteria.
- Không nên: Để backlog thành “nghĩa địa” không ai review.
- Không nên: Bắt đầu quá nhiều việc cùng lúc; hãy hoàn thành nhiều hơn số bạn bắt đầu.
Thế nào là “tốt”
- Các item top của backlog đã sẵn sàng (phạm vi rõ, có owner, biết phụ thuộc).
- Sprint có mức cam kết thực tế và phần lớn hoàn thành đúng kế hoạch.
- Board thể hiện trạng thái thật; stakeholder nhìn qua là tin.
- Việc bị chặn (blocked) lộ rõ và được xử lý nhanh.
Checklist: Pre-check + Post-check
Pre-check (trước khi sprint bắt đầu)
- Các item top trong backlog đã được xếp hạng và refine.
- Có acceptance criteria cho các item trong sprint.
- Phụ thuộc đã được link hoặc xử lý.
- Đã tính capacity (thời gian, nhân sự, ngày nghỉ).
- Đã viết sprint goal (1–2 câu).
Post-check (cuối sprint)
- Các item done là done thật (đã verify).
- Các item chưa xong được ước lượng lại và triage lại.
- Insights/reports được review cùng team.
- Tạo action item cho một cải tiến quy trình.
- Backlog được cập nhật cho chu kỳ tiếp theo.
Bài thực hành (5–15 phút)
Mục tiêu: Làm một bài tập planning sprint mini.
- Mở backlog và chọn 3 item nhỏ đã sẵn sàng.
- Tạo một sprint và kéo 3 item vào sprint.
- Bắt đầu sprint, sau đó chuyển một item sang In progress.
- Hoàn thành item và chuyển sang Done kèm một comment ngắn về kết quả.
Luồng chuẩn (Happy paths)
Happy path #1 — Groom backlog → lập kế hoạch sprint
- Review các item top trong backlog và xoá các item trùng rõ ràng.
- Làm rõ phạm vi từng item và thêm acceptance criteria.
- Ước lượng/size item theo cách team bạn dùng (nếu có).
- Link phụ thuộc và nhận diện blocker.
- Tạo sprint và chỉ kéo các item đã sẵn sàng vào.
- Đặt sprint goal và bắt đầu sprint.
Happy path #2 — Thực thi hằng ngày trên board
- Bắt đầu từ board: nhận diện việc đang bị chặn hoặc bị “già” (aging).
- Kéo item ưu tiên cao nhất tiếp theo khi có capacity.
- Cập nhật status khi công việc di chuyển (tránh cột bị “mốc”).
- Thêm comment nhanh cho handoff hoặc quyết định.
- Giới hạn WIP: hoàn thành item trước khi bắt đầu item mới.
- Kết thúc ngày với board phản ánh đúng thực tế (không có “tiến độ bí mật”).
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Team làm theo iteration? | Dùng Scrum backlog + sprint. | Dùng Kanban board với WIP và flow liên tục. |
| Item quá lớn cho sprint? | Tách nhỏ trước khi cam kết. | Đưa vào epic và lên kế hoạch theo “lát cắt”. |
| Item bị chặn? | Đánh dấu blocked (label/status) và link blocker. | Escalate nếu đe doạ sprint goal. |
| Quá nhiều item đang làm? | Áp dụng WIP limit và “swarm” để hoàn thành. | Đánh giá lại ưu tiên và tạm dừng việc giá trị thấp. |
Lỗi thường gặp (và cách tránh)
- Backlog không bao giờ được groom
Tránh: Đặt “nghi lễ” groom hàng tuần và giữ các item top luôn sẵn sàng. - Cột không khớp workflow
Tránh: Căn cột/status để transition có ý nghĩa. - Over-commit khi planning
Tránh: Dùng capacity và throughput quá khứ làm “lan can”. - Bắt đầu quá nhiều item
Tránh: Kỷ luật WIP; hoàn thành nhiều hơn số bạn bắt đầu. - Coi Done chỉ là ‘dev done’
Tránh: Có Definition of Done rõ ràng và bước verify.
Link tài liệu chính thức
- Use your scrum backlog — Hướng dẫn chính thức về cách dùng backlog trong Scrum.
- Coordinate and monitor work with sprints — Danh mục chính thức về nền tảng và vận hành sprint.
- View insights in Jira Cloud — Nút insights trong các view board/backlog.
Báo cáo, dashboard & insights
Hướng dẫn cho người mới • Jira Cloud- Dùng report để nhìn xu hướng (sprint, version, loại công việc) và phát hiện rủi ro sớm.
- Dashboard gom các gadget để theo dõi realtime; chia sẻ cho stakeholders.
- Insights là “góc nhìn sức khoẻ” nhanh, mở được từ các view chính như board/backlog.
Mục đích / Kết quả
Biến dữ liệu Jira thành khả năng quan sát. Mục tiêu không phải có nhiều biểu đồ hơn—mà là ra quyết định tốt hơn: phát hiện scope creep, nút thắt cổ chai và rủi ro giao hàng từ sớm.
- Chọn 2–3 report phù hợp với cách team vận hành (Scrum vs Kanban).
- Tạo dashboard cho stakeholders (nắm tiến độ mà không micromanage).
- Dùng insights trên board/backlog để “check sức khoẻ” nhanh.
- Review chỉ số theo nhịp (thường tuần 1 lần là đủ).
Mô hình tư duy / Luồng
Báo cáo hiệu quả nhất khi chạy theo vòng lặp:
- Chốt câu hỏi (vd: “Sprint goal có đang on-track không?”).
- Chọn đúng góc nhìn (report, dashboard gadget, hoặc insights).
- Diễn giải theo ngữ cảnh (thay đổi scope, blocker, ngày nghỉ).
- Chốt 1 hành động (giảm scope, swarm, gỡ chặn).
Đối tượng & Thuật ngữ
Các đối tượng chính bạn sẽ gặp ở khu vực này.
- Report: Trực quan hoá dựng sẵn về xu hướng công việc (sprint, version, …).
- Dashboard: Tập hợp gadget hiển thị thông tin realtime; có thể chia sẻ.
- Gadget: Widget trên dashboard (biểu đồ, filter, tổng hợp).
- Insights: View insight nhanh, truy cập từ board/backlog/deployments (tuỳ nơi hỗ trợ).
Các “việc cần làm” cốt lõi
- Tạo dashboard đơn giản cho team (My work, Sprint progress, Blocked items).
- Tạo dashboard cho stakeholders (tiến độ tổng quan, tín hiệu roadmap).
- Dùng insights để phát hiện nút thắt khi planning hoặc đang chạy sprint.
- Chia sẻ dashboard trong Confluence để tăng visibility.
Nên / Không nên & Bẫy thường gặp
- Nên: Bắt đầu với 1 dashboard rồi lặp cải tiến theo câu hỏi mọi người hay hỏi.
- Nên: Dùng field nhất quán (component, version) để tăng chất lượng report.
- Nên: Chia sẻ dashboard read-only để giảm tải “status meeting”.
- Không nên: Dùng metrics làm “vũ khí” (dễ tạo hành vi xấu).
- Không nên: Dựng dashboard trên dữ liệu bừa bộn—hãy sửa hygiene trước.
- Không nên: Tạo cả tá gadget mà không ai xem.
Thế nào là “tốt”
- Team tự dùng dashboard hàng tuần (không cần nhắc).
- Stakeholders tự xem trạng thái từ dashboard được chia sẻ.
- Report dẫn đến hành động (gỡ chặn, re-scope) chứ không chỉ tranh luận.
- Insights giúp team phát hiện rủi ro trong planning/thực thi.
Checklist: Pre-check + Post-check
Pre-check
- Chốt 3 câu hỏi quan trọng nhất cần trả lời.
- Đảm bảo field được dùng nhất quán (assignee, status, sprint/version).
- Chọn đối tượng dashboard (team vs stakeholders).
- Chọn tối đa 3–6 gadget cho phiên bản đầu.
- Thiết lập quyền chia sẻ phù hợp.
Post-check
- Dashboard thực sự được vào xem hàng tuần.
- Gadget hiển thị đúng project/filter.
- Gadget lỗi thời được xoá hoặc thay.
- Insights/report được review theo nhịp.
- Chốt 1 hành động cải tiến từ buổi review.
Bài thực hành (5–15 phút)
Mục tiêu: Dựng một dashboard nhỏ trả lời đúng 1 câu hỏi.
- Chọn câu hỏi: “Tuần này đang bị chặn bởi cái gì?”
- Tạo filter để tìm các item bị chặn (theo convention của team bạn).
- Tạo dashboard và thêm một gadget dùng filter đó.
- Chia sẻ dashboard cho team (chỉ xem).
Luồng chuẩn (Happy paths)
Happy path #1 — Dashboard team trong 10 phút
- Tạo saved filter cho ‘My open work’ (hoặc team queue).
- Tạo dashboard mới với tên rõ ràng (Team — Weekly).
- Thêm 3 gadget: filter results, sprint progress (nếu Scrum), và recently updated items.
- Sắp xếp lại để gadget quan trọng nhất ở góc trên-trái.
- Chia sẻ cho team ở chế độ chỉ xem.
- Hỏi 1 teammate: ‘Thiếu gì?’ rồi iterate.
Happy path #2 — Minh bạch cho stakeholders mà không cần thêm họp
- Xác định stakeholders quan tâm gì (deadline, scope, risk).
- Tạo stakeholder dashboard với gadget “tầm cao” (tránh nhiễu).
- Thêm gadget hiển thị top risks (item blocked/aging).
- Chia sẻ trong Confluence để gắn với ngữ cảnh dự án.
- Review hàng tuần và bỏ gadget không ai dùng.
- Dùng dashboard trong status update thay vì slide deck.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Team Scrum? | Dùng report/gadget tập trung sprint. | Dùng view tập trung flow/throughput (kiểu Kanban). |
| Dữ liệu có vẻ sai? | Sửa kỷ luật workflow/field hygiene trước. | Thu hẹp phạm vi báo cáo vào phần dữ liệu sạch hơn. |
| Cần chia sẻ rộng? | Chia sẻ dashboard read-only và embed vào Confluence. | Giữ riêng cho team iterate trước. |
| Quá nhiều gadget? | Giảm còn 3–6, mỗi cái trả lời một câu hỏi thật. | Tách thành 2 dashboard theo đối tượng. |
Lỗi thường gặp (và cách tránh)
- Dùng dashboard như “vanity metrics”
Tránh: Mỗi gadget phải gắn với một quyết định/hành động. - Chia sẻ dashboard nhưng chưa set quyền
Tránh: Check người xem có quyền xem project và filter nền hay không. - Giữ gadget lỗi thời
Tránh: Review hàng tháng; xoá cái không dùng. - Không chuẩn hoá field
Tránh: Chốt convention đơn giản (blocked label, components, versions). - Đọc chart mà thiếu ngữ cảnh
Tránh: Luôn bàn cùng scope change và blocker song song với số liệu.
Link tài liệu chính thức
- Work with dashboards in Jira Cloud — Cơ bản về dashboard: bố cục, chia sẻ, gadget, wallboard.
- Theo dõi và phân tích công việc của team bằng reports — Điểm vào chính thức cho hướng dẫn Jira reports.
- View insights in Jira Cloud — Insights nằm ở đâu và cách mở từ các view chính.
Tự động hoá & quy trình (workflows)
Hướng dẫn cho người mới • Jira Cloud- Dùng rule tự động hoá để giảm việc lặp (điều phối, cập nhật field, thông báo).
- Rule được ghép từ trigger → condition → action (và branch).
- Bắt đầu từ rule đơn giản, theo dõi audit log và tránh spam/loop rule.
Mục đích / Kết quả
Tự động hoá giúp team chạy nhanh hơn bằng cách xử lý các bước lặp lại: gán người phụ trách, gắn nhãn, cập nhật field, hoặc gửi thông báo. Kết quả là ít click thủ công hơn và quy trình được thực thi nhất quán hơn.
- Hiểu các khối xây dựng của rule (trigger, condition, action).
- Tạo 1 rule đơn giản và kiểm tra bằng work item thử nghiệm.
- Theo dõi trạng thái rule (enabled/disabled/draft) và kết quả trong audit.
- Tránh rule gây ồn (spam) hoặc tự lặp vô hạn.
Mô hình tư duy / Luồng
Automation rule có cấu trúc rất “đoán được”.
- Trigger: khi nào rule bắt đầu (vd: work item được tạo).
- Condition: kiểm tra có nên chạy tiếp hay không.
- Action: rule sẽ làm gì (set field, notify, tạo item).
- Branch (tuỳ chọn): áp action lên các work item liên quan.
Đối tượng & Thuật ngữ
Các đối tượng chính bạn sẽ gặp ở khu vực này.
- Rule: Tập các bước tự động chạy theo tiêu chí.
- Trigger: Sự kiện khởi chạy rule.
- Condition: Điều kiện phải đúng để action chạy.
- Action: Thao tác rule thực hiện.
- Branch: Chạy action trên issue liên quan (parent/child/…).
- Audit log: Nơi xem rule đã chạy gì, thay đổi gì, và lỗi.
Máy trạng thái / Vòng đời
Automation rule có vòng đời vận hành đơn giản.
- Enabled: rule chạy khi được trigger.
- Disabled: rule không chạy.
- Draft: có thay đổi nhưng chưa publish.
Các “việc cần làm” cốt lõi
- Tự gán người xử lý theo component/label.
- Tự set priority hoặc due date khi tạo một loại work item nhất định.
- Thông báo vào kênh khi có work item ưu tiên cao được tạo.
- Tạo task follow-up khi work item được chuyển sang Done.
- Dùng branch để cập nhật item con khi item cha thay đổi.
Quyền hạn & Vai trò
Quyền dùng Automation phụ thuộc cấu hình Jira và vai trò của bạn. Nếu bạn không tạo được rule, hãy nhờ project admin hoặc site admin.
Không áp dụng cho tab này nếu vai trò của bạn không cho phép cấu hình automation.
Nên / Không nên & Bẫy thường gặp
- Nên: Bắt đầu 1 rule đơn giản và test ở project/space không quan trọng.
- Nên: Thêm condition để thu hẹp phạm vi (tránh bắn vào mọi thứ).
- Nên: Xem audit log sau mỗi lần thay đổi.
- Không nên: Tạo rule thông báo cho mọi thay đổi nhỏ (spam).
- Không nên: Tạo rule vòng lặp (A trigger B rồi B trigger lại A).
- Không nên: Để draft treo nhiều tuần—publish hoặc bỏ có chủ đích.
Thế nào là “tốt”
- Rule tiết kiệm thời gian và giảm lỗi (đo được: ít sửa tay hơn).
- Audit log cho thấy chạy thành công ổn định, ít fail.
- Thông báo đúng người, đúng chỗ, đúng lúc.
- Có owner rõ ràng và rule được mô tả ngắn gọn.
Checklist: Pre-check + Post-check
Pre-check
- Viết mục tiêu rule trong 1 câu.
- Liệt kê trigger, conditions, actions theo đúng thứ tự.
- Chỉ ra khả năng loop hoặc chạy trùng.
- Chọn 1 project/space nhỏ để test.
- Chốt owner để bảo trì về sau.
Post-check
- Chạy 3 test case (bình thường, edge, không được trigger).
- Kiểm tra audit log xem có lỗi hoặc edit ngoài ý muốn.
- Xác nhận thông báo đến đúng audience.
- Ghi lại rule name + intent.
- Bật/tắt có chủ đích; tránh “rule bí ẩn”.
Bài thực hành (5–15 phút)
Mục tiêu: Tạo 1 rule an toàn: tự thêm label cho item mới theo một type nhất định.
- Tạo rule với trigger “work item created”.
- Thêm condition cho một work item type cụ thể.
- Thêm action để add label (vd: triage).
- Tạo 1 work item test khớp điều kiện, và 1 cái không khớp.
- Xem audit log để xác nhận hành vi đúng.
Luồng chuẩn (Happy paths)
Happy path #1 — Tạo rule tự động hoá đầu tiên
- Mở phần automation settings theo ngữ cảnh Jira Cloud của bạn (project/space hoặc global tuỳ cấu hình).
- Chọn Create rule.
- Chọn trigger khớp sự kiện (vd: item created).
- Thêm condition để thu hẹp phạm vi (type, project, label).
- Thêm action (set field, notify, tạo item).
- Lưu/publish, rồi test với 2–3 work item và kiểm tra audit log.
Happy path #2 — Cải tiến rule an toàn (draft → publish)
- Mở rule hiện có và ghi nhận hành vi hiện tại.
- Sửa nhỏ (1 condition hoặc 1 action).
- Giữ ở draft và test nếu môi trường của bạn cho phép test an toàn.
- Kiểm tra audit log sau thay đổi để phát hiện lỗi hoặc edit lạ.
- Publish thay đổi và theo dõi trong 1 ngày.
- Nếu phát sinh ồn, disable nhanh rồi iterate tiếp.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Cần xử lý item liên quan? | Dùng branch cho parent/child/related. | Chỉ xử lý item đã trigger rule. |
| Lo spam? | Siết chặt condition và giới hạn thông báo. | Ưu tiên action cập nhật field thay vì nhắn người. |
| Rule ảnh hưởng nhiều project? | Phối hợp admin và ghi rõ ownership. | Giới hạn vào 1 project/space trước. |
| Rule chạy sai? | Disable ngay, rồi debug bằng audit log. | Rollback edit gần nhất và đơn giản hoá logic. |
Lỗi thường gặp (và cách tránh)
- Tạo rule mà không có condition
Tránh: Luôn thu hẹp phạm vi để không trigger “mọi thứ”. - Quá tải thông báo
Tránh: Chỉ notify khi tín hiệu cao và đúng kênh. - Vòng lặp automation
Tránh: Soi trigger và action để tránh feedback loop. - Không có owner
Tránh: Gán owner và ghi mục đích ngay trong tên/mô tả rule. - Bỏ qua audit log
Tránh: Dùng audit log để validate hành vi và xử lý lỗi.
Link tài liệu chính thức
- Jira Cloud automation — Tổng quan và điểm vào chính thức cho các chủ đề automation.
- Tạo và chỉnh sửa Jira automation rules — Luồng tạo rule từng bước.
- Bật/tắt Jira automation rules — Trạng thái rule: enabled/disabled/draft.
Quyền hạn & vai trò
Hướng dẫn cho người mới • Jira Cloud- Quyền (permissions) quyết định ai xem được gì và làm được gì (cấp site, cấp space/project, và cấp work item).
- Permission schemes định nghĩa quyền cho space/project; roles giúp bạn gán quyền theo “nhóm vai trò” thay vì từng người.
- Khi ai đó nói “mình không thể…”, hãy xử lý như một luồng troubleshooting về quyền.
Mục đích / Kết quả
Làm cho việc truy cập trở nên dự đoán được và an toàn. Kết quả đơn giản: đúng người thì tạo/chuyển work được, và work nhạy cảm thì được giới hạn.
- Hiểu các loại quyền (global, cấp space/project, và bảo mật theo work item).
- Dùng permission schemes để kiểm soát truy cập theo space/project.
- Dùng roles/groups để quản trị thành viên ở quy mô lớn.
- Gỡ lỗi quyền truy cập theo cách có hệ thống.
Mô hình tư duy / Luồng
Quyền có dạng nhiều lớp. Bắt đầu từ lớp rộng, rồi thu hẹp dần.
- User có quyền vào Jira site chưa (global permission)?
- User có quyền vào space/project không (permission scheme)?
- Work item cụ thể có bị hạn chế không (security level/classification)?
- Hành động có bị chặn bởi workflow conditions/validators không (nếu có cấu hình)?
Đối tượng & Thuật ngữ
Các đối tượng chính bạn sẽ gặp ở khu vực này.
- Global permissions: Kiểm soát quyền ở cấp site (vd: quyền truy cập Jira).
- Permission scheme: Định nghĩa user làm được gì trong một space/project.
- Role: “Giỏ” người dùng có tên, dùng trong permission schemes.
- Group: Tập người dùng, thường quản lý qua nhà cung cấp định danh (IdP).
- Work item security: Giới hạn khả năng nhìn thấy theo từng work item (khi bật).
Máy trạng thái / Vòng đời
Không áp dụng cho tool/tab này.
Các “việc cần làm” cốt lõi
- Cấp quyền cho teammate vào một space/project.
- Cho một nhóm user được transition hoặc edit item (nhưng không phải tất cả).
- Giới hạn work item nhạy cảm bằng security level (nếu có cấu hình).
- Chẩn đoán vì sao user không thấy hoặc không sửa được thứ gì đó.
Quyền & Vai trò
Các thực hành quan trọng để duy trì quyền an toàn.
- Dùng roles trong schemes (vd: Developers, Viewers) thay vì gán từng user.
- Org lớn: ưu tiên groups; phân bổ theo từng project: ưu tiên roles.
- Thay đổi quyền theo từng bước nhỏ và test bằng tài khoản không phải admin.
- Ghi rõ ai sở hữu thay đổi quyền (site admin vs project admin).
Nên / Không nên & Bẫy thường gặp
- Nên: Dùng permission schemes để chuẩn hoá truy cập giữa các project khi cần.
- Nên: Gỡ lỗi theo thứ tự global → project → issue security.
- Nên: Giữ “dấu vết” thay đổi (ai đổi gì và vì sao).
- Không nên: Cấp quyền admin rộng chỉ để fix một lỗi truy cập lẻ.
- Không nên: Nhét user cá nhân khắp nơi trong schemes; không scale được.
- Không nên: Bỏ qua issue security/classification khi xử lý dữ liệu nhạy cảm.
Thế nào là “tốt”
- Yêu cầu cấp quyền được xử lý nhanh bằng checklist lặp lại được.
- Project có roles nhất quán và ít “quyền ngoại lệ”.
- Nguyên tắc tối thiểu (least-privilege): user có đủ dùng, không phải “có hết”.
- Work nhạy cảm chỉ hiển thị với đúng đối tượng được duyệt.
Checklist: Pre-check + Post-check
Pre-check (trước khi đổi quyền)
- Xác định chính xác hành động user không làm được.
- Xác nhận đúng project/space và đúng work item.
- Kiểm tra global access trước.
- Kiểm tra permission scheme của project.
- Kiểm tra issue security/classification nếu liên quan.
Post-check (sau khi đổi)
- User vào được project và làm được hành động cần thiết.
- Không vô tình cấp quyền cho người khác.
- Thay đổi được ghi lại (ticket/note).
- Roles/groups được cập nhật nhất quán.
- Follow-up: gỡ quyền tạm thời (nếu có cấp).
Bài thực hành (5–15 phút)
Mục tiêu: Chạy thử một bài “drill” gỡ lỗi quyền.
- Chọn một tài khoản teammate (hoặc test user) có quyền hạn chế.
- Thử mở một project và thực hiện một hành động (vd: tạo item).
- Nếu bị chặn, kiểm tra global permissions rồi đến project scheme.
- Chỉnh membership của role (ưu tiên) thay vì cấp admin.
- Test lại và xác nhận chỉ đúng quyền mong muốn thay đổi.
Luồng chuẩn (Happy paths)
Happy path #1 — Cấp quyền cho teammate vào project
- Xác nhận họ cần làm gì (chỉ xem vs tạo/sửa/transition).
- Kiểm tra họ có vào Jira được không (global permission).
- Thêm họ vào đúng group/role của project.
- Xác nhận permission scheme cấp đúng quyền cần thiết cho role đó.
- Nhờ họ logout/login (nếu cần) và test lại.
- Ghi lại thay đổi (ai, cái gì, vì sao).
Happy path #2 — Gỡ lỗi “mình không thấy work item này”
- Xác nhận key work item và project.
- Kiểm tra user có xem được item khác trong cùng project không.
- Nếu không, kiểm tra permission scheme/role membership của project.
- Nếu có, kiểm tra issue security level hoặc hạn chế classification.
- Kiểm tra filter/board có đang ẩn item (không phải lỗi quyền).
- Áp dụng fix nhỏ nhất và test lại với user.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| User không vào Jira được? | Kiểm tra global permissions / product access. | Chuyển sang kiểm tra cấp project. |
| User thấy project nhưng không thấy một item cụ thể? | Kiểm tra issue security/classification. | Kiểm tra filters/thiết lập board. |
| Nhiều project cần cùng mô hình quyền? | Chuẩn hoá bằng permission schemes dùng chung. | Giữ tùy biến theo project nhưng phải ghi tài liệu. |
| Cần quyền tạm thời? | Cấp tối thiểu và có kế hoạch gỡ sau. | Tránh kiểu “cho làm admin cho nhanh”. |
Lỗi thường gặp (và cách tránh)
- Fix bằng cách cấp admin
Tránh: Cấp tối thiểu: thêm vào role/group phù hợp. - Gán từng cá nhân trực tiếp vào schemes
Tránh: Dùng roles/groups để scale. - Bỏ qua kiểm tra issue security
Tránh: Với item nhạy cảm, xác minh security level/classification. - Không ghi lại thay đổi quyền
Tránh: Ghi nhận để audit và dễ troubleshooting về sau. - Giả định luôn là lỗi quyền
Tránh: Cũng kiểm tra filters, board query, và phạm vi search.
Link tài liệu chính thức
- Permission schemes trong Jira là gì? — Giải thích chính thức về permission schemes trong Jira Cloud.
- Cấp quyền cho space bằng permission schemes — Cách cấp quyền bằng schemes.
- Hiểu quyền space và roles — Tổng quan về quyền và quyền truy cập.
Bảo mật & bảo vệ dữ liệu
Hướng dẫn cho người mới • Jira Cloud- Dùng phân loại dữ liệu (data classification) và bảo mật work item (issue security) để kiểm soát các nội dung nhạy cảm.
- Đặt phân loại mặc định giúp giảm lỗi do con người khi tạo item mới.
- Luôn kiểm tra lại ai có thể xem/sửa sau khi thay đổi thiết lập bảo mật.
Mục đích / Kết quả
Bảo vệ thông tin nhạy cảm trong Jira để chỉ đúng người mới truy cập được. Kết quả là cộng tác an toàn hơn mà không làm chậm công việc hằng ngày.
- Áp dụng mức phân loại dữ liệu mặc định cho work items (nếu có).
- Dùng các mức bảo mật work item để hạn chế khả năng xem.
- Xác minh quyền truy cập sau khi thay đổi (test bằng user điển hình).
- Tránh đặt dữ liệu nhạy cảm vào các trường/bình luận không bị giới hạn.
Mô hình tư duy / Luồng
Bảo mật = phòng ngừa + xác minh.
- Xác định cái gì là nhạy cảm (và cái gì không).
- Đặt mặc định để ngăn sai sót (classification/security).
- Chỉ áp dụng kiểm soát chặt hơn khi thực sự cần.
- Test quyền truy cập và điều chỉnh permissions khi cần.
Đối tượng & Thuật ngữ
Các đối tượng chính bạn sẽ gặp ở khu vực này.
- Data classification: Nhãn/mức để chỉ độ nhạy cảm của work items.
- Security level: Thiết lập giới hạn ai có thể xem một work item.
- Permission scheme: Kiểm soát truy cập chung; security level có thể siết chặt thêm.
Máy trạng thái / Vòng đời
Không áp dụng cho tool/tab này.
Các “việc cần làm” cốt lõi
- Đặt phân loại mặc định cho work item mới để giảm sai sót.
- Đổi security level của work item cho các item nhạy cảm.
- Audit và rà soát nội dung nhạy cảm định kỳ.
- Hướng dẫn team nơi nên/không nên lưu thông tin nhạy cảm.
Quyền & Vai trò
Thiết lập bảo mật sẽ tương tác với permissions. Nếu bạn siết bảo mật, hãy đảm bảo roles/groups đúng vẫn truy cập được.
- Xác định ai bắt buộc phải truy cập item nhạy cảm (roles/groups).
- Test quyền bằng tài khoản không phải admin.
- Ghi rõ quy tắc: khi nào dùng security level, khi nào dùng quyền bình thường.
- Phối hợp với admin nếu security schemes được quản lý tập trung.
Nên / Không nên & Bẫy thường gặp
- Nên: Dùng mặc định cho classification khi có thể.
- Nên: Chỉ áp dụng security levels khi cần (tránh siết quá mức).
- Nên: Xác minh quyền truy cập sau khi thay đổi.
- Không nên: Để bí mật trong comment/attachment không bị giới hạn.
- Không nên: Nghĩ “dashboard riêng tư” là đủ bảo vệ một work item nhạy cảm.
- Không nên: Quyết định bảo mật kiểu tuỳ hứng; hãy có policy đơn giản.
Thế nào là “tốt”
- Item nhạy cảm được gắn nhãn/phân loại rõ ràng.
- Chỉ đúng người được xem các item bị hạn chế.
- Người mới không vô tình đăng nội dung nhạy cảm vào trường công khai.
- Thiết lập bảo mật dễ hiểu và có tài liệu ngắn gọn.
Checklist: Pre-check + Post-check
Pre-check
- Định nghĩa cái gì được xem là nhạy cảm trong tổ chức.
- Quyết định mức phân loại mặc định (nếu dùng).
- Xác định roles/groups cần truy cập.
- Chọn một test user để kiểm tra quyền.
- Lên kế hoạch nơi lưu secrets (tránh lưu trong Jira fields).
Post-check
- Quyền truy cập của test user đúng như mong muốn.
- Item bị hạn chế không xuất hiện trong search diện rộng với user không có quyền.
- Team biết cách đặt/đổi security level khi cần.
- Dashboards/reports không làm lộ chi tiết của item bị hạn chế.
- Policy và hướng dẫn nhanh được chia sẻ cho team.
Bài thực hành (5–15 phút)
Mục tiêu: Khoá an toàn một work item.
- Tạo một work item test với nội dung placeholder không nhạy cảm.
- Đặt hoặc kiểm tra classification mặc định (nếu project hỗ trợ).
- Đổi security level của work item sang nhóm người xem bị giới hạn.
- Nhờ một teammate không có quyền thử mở (hoặc dùng test user).
- Hoàn tác/điều chỉnh nếu phạm vi truy cập quá rộng hoặc quá hẹp.
Luồng chuẩn (Happy paths)
Happy path #1 — Đặt mặc định an toàn cho work item mới
- Xác định mức nhạy cảm phổ biến của work trong project.
- Đặt classification mặc định cho work items (nếu có).
- Tạo item test và xác nhận classification tự áp dụng.
- Giải thích cho team ý nghĩa nhãn và khi nào cần override.
- Rà soát sau 1 tuần: overrides có được dùng đúng không?
- Điều chỉnh mặc định nếu quá chặt hoặc quá lỏng.
Happy path #2 — Hạn chế một work item nhạy cảm
- Mở work item và xác nhận có nội dung nhạy cảm.
- Chọn đúng security level / restriction.
- Kiểm tra roles cần thiết vẫn truy cập được.
- Xác minh user không được phép không thể xem.
- Thay nội dung nhạy cảm ở các trường công khai bằng tham chiếu an toàn.
- Ghi lại lý do và các thay đổi đã thực hiện.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Phần lớn work là nhạy cảm? | Dùng default classification cao hơn và hướng dẫn user hạ xuống khi an toàn. | Dùng default thấp hơn và chỉ hạn chế các trường hợp đặc biệt. |
| Cần chia sẻ với bên ngoài? | Tạo bản tóm tắt an toàn, tránh chia sẻ trực tiếp nội dung bị hạn chế. | Giữ nội bộ và cập nhật qua kênh được phê duyệt. |
| User không thấy item bị hạn chế? | Xác nhận họ thuộc audience được phép của security level. | Nếu họ cần thấy, chỉnh membership role/group (least privilege). |
| Lo rò rỉ qua dashboards? | Dùng filters và permissions; tránh gadget lộ chi tiết bị hạn chế. | Hạn chế chia sẻ dashboard và giữ nội bộ. |
Lỗi thường gặp (và cách tránh)
- Nghĩ “dashboard private” là dữ liệu an toàn
Tránh: Bảo vệ chính work item bằng classification/security levels. - Đăng secrets trong comments
Tránh: Dùng vault; chỉ link tham chiếu thay vì nhúng secrets. - Siết quá mức mọi thứ
Tránh: Chỉ siết cái cần siết; giữ cộng tác bình thường dễ dàng. - Không test quyền truy cập
Tránh: Luôn xác minh bằng user không phải admin sau khi đổi. - Không có policy chung
Tránh: Viết guideline ngắn: phân loại gì và khi nào cần hạn chế.
Link tài liệu chính thức
- Bảo vệ dữ liệu của team — Hướng dẫn chính thức về classification và security levels cho work items.
- Permission schemes trong Jira là gì? — Nền tảng về các lớp kiểm soát truy cập.
- Hiểu quyền space và roles — Cách roles và permissions phối hợp với nhau.
Kế hoạch (lập kế hoạch nhiều space)
Hướng dẫn cho người mới • Jira Cloud- Plans giúp bạn xem công việc xuyên suốt nhiều team/space, bao gồm phụ thuộc (dependencies) và các đợt phát hành (releases).
- Bắt đầu với một plan nhỏ, rồi thêm team và nguồn work dần dần.
- Dùng các view (timeline/list/calendar/program board) để trả lời các câu hỏi lập kế hoạch khác nhau.
Mục đích / Kết quả
Plans cho phép bạn điều phối công việc giữa nhiều space (project), team, và các đợt phát hành. Kết quả là sự đồng bộ: một bức tranh chung về phạm vi, thời gian và phụ thuộc.
- Tạo một plan và kết nối đúng các nguồn công việc (work sources).
- Lập lịch công việc bằng sprints, ngày tháng hoặc releases.
- Quản lý dependencies và tín hiệu về năng lực (capacity).
- Chia sẻ/xuất các view của plan cho stakeholders.
Mô hình tư duy / Luồng
Plans là một lớp tổng hợp (aggregation) nằm trên các spaces và work items.
- Thêm work sources (spaces/projects/boards) vào plan.
- Chọn mô hình lập lịch (sprints vs dates vs releases).
- Xem và xử lý dependencies/cảnh báo.
- Lặp lại tinh chỉnh bằng các view (timeline/list/calendar/program board).
Đối tượng & Thuật ngữ
Các đối tượng chính bạn sẽ gặp ở khu vực này.
- Plan: Một view lập kế hoạch đa space, tổng hợp các work items.
- Work source: Space/project/board được đưa vào plan.
- Dependency: Mối quan hệ cho thấy work bị chặn bởi hoặc liên quan tới work khác.
- Iteration: Thường là các giai đoạn lập lịch theo sprint.
- Program board: View để lập kế hoạch theo quý và quản lý dependencies ở mức cao hơn (nếu có).
Máy trạng thái / Vòng đời
Không áp dụng cho tool/tab này.
Các “việc cần làm” cốt lõi
- Tạo plan bao gồm đúng team và spaces cần thiết.
- Lập lịch work items theo sprint hoặc ngày tháng.
- Theo dõi releases xuyên suốt nhiều spaces.
- Nhận diện và quản lý dependencies giữa các team.
- Chia sẻ hoặc xuất dữ liệu plan (CSV/ảnh/nhúng embed) cho stakeholders.
Dữ liệu & Tích hợp
Plans thường được chia sẻ qua nhiều công cụ để tạo sự đồng bộ.
- Nhúng plans vào các app Atlassian (nếu hỗ trợ) để tăng khả năng quan sát.
- Xuất CSV để phân tích offline khi cần (tránh biến nó thành mặc định).
- Dùng tên sprint/release nhất quán giữa các spaces để giảm nhầm lẫn.
- Giữ kích thước plan vừa phải để đảm bảo hiệu năng.
Nên / Không nên & Bẫy thường gặp
- Nên: Bắt đầu với plan cho 2–3 team, rồi mở rộng sau khi ổn định.
- Nên: Định nghĩa lịch sprint và lịch release nhất quán.
- Nên: Rà soát cảnh báo về dependencies thường xuyên.
- Không nên: Dùng plans để thay thế board/backlog ở cấp team.
- Không nên: Bỏ qua khuyến nghị/giới hạn về hiệu năng.
- Không nên: Lập lịch mọi thứ đến từng ngày nếu tổ chức không vận hành theo kiểu đó.
Thế nào là “tốt”
- Các team đồng ý plan phản ánh thực tế (không phải “ngày ảo”).
- Dependencies hiển thị rõ và có người chịu trách nhiệm xử lý.
- Stakeholders dùng plan để hiểu tradeoff, không phải để micro-manage task.
- Các view trả lời câu hỏi cụ thể (timeline cho ngày, list cho scope, calendar cho milestones).
Checklist: Pre-check + Post-check
Pre-check
- Những spaces/projects nào bắt buộc phải đưa vào?
- Các team dùng sprints hay lập lịch theo ngày?
- Đã thống nhất quy ước đặt tên releases.
- Ai sở hữu việc quản lý dependencies?
- Xác định audience của plan (lãnh đạo, PMs, teams).
Post-check
- Plan chỉ gồm các work sources liên quan.
- Các mốc quan trọng/ngày release hiển thị rõ.
- Dependencies được rà soát và theo dõi.
- Cảnh báo được điều tra (thiếu items, xung đột lập lịch).
- Plan được chia sẻ với đúng permissions.
Bài thực hành (5–15 phút)
Mục tiêu: Tạo một plan nhỏ bao phủ hai spaces.
- Tạo plan và thêm 2 work sources (spaces/projects).
- Chuyển sang timeline view và lọc phạm vi nhỏ.
- Lập lịch 1 work item bằng sprints hoặc dates.
- Thêm 1 dependency giữa các items (nếu phù hợp).
- Lưu thay đổi và chia sẻ view với teammate.
Luồng chuẩn (Happy paths)
Happy path #1 — Tạo plan phối hợp nhỏ giữa các team
- Xác định 2–3 team/spaces cần điều phối.
- Tạo plan và thêm các spaces đó làm work sources.
- Chọn cách lập lịch (sprints hoặc dates) theo cách team vận hành.
- Dùng timeline/list để xác minh work hiển thị đúng.
- Thêm/kiểm tra dependencies quan trọng và gán owner để xử lý.
- Lưu thay đổi và chia sẻ plan cho stakeholders.
Happy path #2 — Lập kế hoạch theo quý với program board (nếu có)
- Chuẩn bị: đảm bảo các team đã cấu hình sprints/releases nhất quán.
- Mở program board view của plan.
- Đưa các work items chính vào sprint/iteration mục tiêu.
- Rà soát đường dependency và xử lý xung đột rõ ràng.
- Điều chỉnh capacity và thứ tự (sequencing) khi cần.
- Publish/chia sẻ plan view để đồng bộ.
Điểm ra quyết định
| Tình huống | Nếu A | Nếu B |
|---|---|---|
| Các team dùng sprints? | Lập lịch theo sprints và theo dõi trạng thái sprint. | Lập lịch theo ngày bắt đầu/kết thúc và milestones. |
| Plan bị chậm/quá lớn? | Giảm scope và tách thành nhiều plans. | Bỏ work sources giá trị thấp và work đã archive. |
| Dependencies không rõ? | Thêm link dependency rõ ràng và gán owner. | Dùng warnings và các buổi review để lộ ra link còn thiếu. |
| Stakeholders muốn export? | Ưu tiên share view/nhúng embed; export CSV khi thật sự cần. | Tránh dùng spreadsheet thủ công làm “source of truth” chính. |
Lỗi thường gặp (và cách tránh)
- Cố gắng lập kế hoạch cho cả tổ chức ngay từ đầu
Tránh: Bắt đầu nhỏ và mở rộng dần. - Dùng plans để micro-manage task
Tránh: Dùng plans cho alignment; team chạy execution trên boards. - Tên sprint/release không nhất quán
Tránh: Chuẩn hoá lịch và quy ước đặt tên giữa các spaces. - Bỏ qua warnings và các work item bị thiếu
Tránh: Review warnings định kỳ và xử lý nguyên nhân gốc. - Lập lịch quá chi li
Tránh: Dùng mức độ chi tiết phù hợp với tổ chức.
Link tài liệu chính thức
- Jira Cloud resources — Plans — Danh mục chính thức về plans và lập kế hoạch nhiều space.
- Bắt đầu với plans — Trang nhập môn về cơ bản và cấu hình plan.
- Xem và quản lý dependencies trong plans — Hướng dẫn chính thức về quản lý phụ thuộc.