Jira

Mục đích / Kết quả

Làm quen với việc di chuyển trong Jira để bạn luôn tìm đúng không gian (project), board, hoặc work item. Mục tiêu là tốc độ: ít click hơn, ít rối hơn, và ít thời gian “đi săn” hơn.

• Phân biệt sidebar chính (global) và điều hướng bên trong từng project.
• Dùng trang “For you” để quay lại công việc gần đây.
• Gắn sao (favorite) các project/board bạn vào mỗi ngày.
• Dùng search để tìm work item, sau đó tinh chỉnh bằng filter.

Nằm ở đâu trong điều hướng + Tab liên quan

Nội dung này bám theo điều hướng sidebar của Jira Cloud và trải nghiệm trang “For you”.

• Liên quan: Work items, Boards/Backlog, Dashboards, Permissions (khi bạn không thấy cái gì đó).
• Khi nào nên chuyển tab: Nếu không tìm thấy item, hãy kiểm tra Permissions & roles.

Mô hình tư duy / Luồng

Hãy nghĩ điều hướng Jira như 2 vòng lặp:

1. Vòng lặp global: chọn project/không gian, mở dashboard, chạy filter đã lưu.
2. Vòng lặp trong project: làm việc qua các view (board/backlog/list/timeline) và cập nhật work item.

Đối tượng & Thuật ngữ

Các khái niệm chính bạn sẽ gặp ở khu vực này.

• Sidebar: Điều hướng chính tới project, filter, dashboard và các mục đã gắn sao.
• For you: Trang giúp bạn quay lại các công việc bạn vừa tương tác gần đây.
• Starred: Các lối tắt/shortcut được ghim để truy cập nhanh.
• Filter: Một truy vấn đã lưu, trả về một tập work item.

Các “việc cần làm” cốt lõi

• Mở đúng project nhanh (và tránh nhầm các project tên gần giống).
• Ghim 3–5 view bạn dùng nhiều nhất (board, backlog, dashboard).
• Tìm việc được giao cho bạn hôm nay bằng search + filter.
• Chia sẻ link tới một work item hoặc board cụ thể cho đồng đội.

Nên / Không nên & Bẫy thường gặp

• Nên: Gắn sao các project và dashboard dùng thường xuyên.
• Nên: Dùng project key và tiền tố nhất quán để search “đúng như dự đoán”.
• Nên: Lưu filter cho các view hay dùng (vd: “My open items”).
• Không nên: Chỉ dựa vào việc “bấm đi bấm lại”; hãy học cách tinh chỉnh search sớm.
• Không nên: Gửi screenshot khi link trực tiếp (deep link) tiện hơn.
• Không nên: Nghĩ item “mất” là bị xoá — nhiều khi là do quyền (permissions).

Thế nào là “tốt”

• Bạn mở được board của team và các view kiểu “My work” trong dưới 3 cú click.
• Bạn có ít nhất 1 filter đã lưu cho routine hằng tuần.
• Bạn nhanh chóng nhận ra mình đang ở đúng project hay không.

Checklist: Pre-check + Post-check

Bài thực hành (5–15 phút)

Mục tiêu: Thiết lập một routine điều hướng hằng ngày thật nhanh.

1. Mở “For you” và tìm một work item bạn vừa xem gần đây.
2. Gắn sao project chính và board/backlog chính.
3. Tạo một filter đã lưu cho “Được giao cho tôi AND chưa done”.
4. Dùng filter đã lưu và xác nhận nó trả về đúng item.

Happy path #1 — Thiết lập lối tắt hằng ngày

1. Mở project chính và xác định view bạn dùng nhiều nhất (board/backlog/list).
2. Gắn sao project và view chính để nó luôn được ghim.
3. Mở các dashboard bạn quan tâm và gắn sao cái hữu ích nhất.
4. Tạo một filter đã lưu cho hàng đợi cá nhân (vd: assigned to you, not done).
5. Thêm filter vào sidebar/favorites (nếu có).
6. Test nhanh: đóng tab rồi điều hướng lại chỉ bằng các mục đã gắn sao.

Happy path #2 — Tìm work item nhanh (search → tinh chỉnh)

1. Dùng global search và nhập một từ khoá “đặc trưng” trong summary.
2. Mở work item có vẻ đúng và kiểm tra project key + trạng thái.
3. Nếu quá nhiều kết quả, tinh chỉnh theo project/không gian hoặc assignee.
4. Dùng history/recents nếu bạn đã xem nó trước đó.
5. Copy link và gửi cho đồng đội đang hỏi.
6. Nếu bạn sẽ tìm kiểu này nhiều lần, hãy lưu thành filter.

Điểm ra quyết định

Lỗi thường gặp (và cách tránh)

• Không gắn sao các trang quan trọng
  Tránh: Gắn sao 3–5 trang bạn mở hằng ngày.
• Chỉ lướt board để tìm item
  Tránh: Dùng search và filter đã lưu.
• Quên kiểm tra project key
  Tránh: Luôn sanity-check project/không gian trước khi chỉnh sửa.
• Nghĩ kết quả trống là không có item
  Tránh: Ưu tiên coi đó là vấn đề permissions hoặc filter trước.
• Lưu quá nhiều filter
  Tránh: Giữ các filter dùng hằng tuần; xoá/đổi tên phần còn lại.

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.

1. Chọn loại project (quyết định về governance).
2. Thiết lập board/backlog chính hoặc list view.
3. Định nghĩa cấu trúc (components, versions/releases) nếu cần.
4. 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

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.

1. Mở project và xác định view chính (board/backlog/list).
2. Đổ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.
3. Tạo 1 component và gán cho 1 work item.
4. Nếu phù hợp, tạo 1 version/release và gán 1 work item vào đó.

Happy path #1 — Cấu hình project để dùng hằng ngày

1. Mở project và chọn view chính (board/backlog hoặc list).
2. Xác nhận trạng thái workflow khớp với quy trình thực tế.
3. Thiết lập components nếu bạn cần route việc hoặc phân quyền theo khu vực.
4. Thiết lập versions/releases nếu bạn theo dõi mốc phát hành.
5. Dọn điều hướng: ghim view chính và ẩn các mục gây nhiễu.
6. 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ề

1. Liệt kê 2–4 nhóm công việc phổ biến nhất mà team hay dùng.
2. Chỉ tạo component cho nhóm có ownership rõ ràng.
3. Định nghĩa pattern đặt tên version đơn giản (vd: 2026.02 hoặc v1.4).
4. Cập nhật 1 work item để có component + version.
5. Review với team và chỉnh tên theo “ngôn ngữ” họ dùng.
6. Ghi rõ rule: khi nào dùng component, khi nào dùng version.

Điểm ra quyết định

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ỳ.

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.

1. Tạo work item → làm rõ phạm vi → gán người phụ trách.
2. Lập kế hoạch (backlog/sprint) → bắt đầu làm.
3. Cập nhật tiến độ (status, comment, link).
4. 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

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.

1. Tạo một work item với summary rõ và mô tả ngắn.
2. Thêm 2 gạch đầu dòng acceptance criteria.
3. Gán cho bạn và đặt priority.
4. Chuyển sang “In progress”, thêm comment mô tả bước tiếp theo.
5. Chuyển sang “Done” và thêm comment cuối ghi lại kết quả.

Happy path #1 — Tạo work item chất lượng cao

1. Search trước để tránh trùng (keyword + project).
2. Tạo work item và viết summary rõ ràng.
3. Thêm mô tả ngắn và 2–5 gạch đầu dòng acceptance criteria.
4. Set assignee, priority và label/component mà team dùng.
5. Link item liên quan (blocks/duplicates/parent) nếu có.
6. 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

1. Chuyển status sang trạng thái “đang làm” đầu tiên (vd: In progress).
2. Thêm comment ghi bước tiếp theo ngay lập tức (để người khác theo được).
3. Khi có thay đổi, cập nhật field (priority, component, due date) thay vì để thông tin cũ.
4. Nếu bị chặn, link blocker và ghi ngắn gọn bạn cần gì.
5. Khi xong, xác nhận acceptance criteria đã đạt.
6. Chuyển sang Done và ghi lại kết quả (kèm link bằng chứng).

Điểm ra quyết định

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ô.

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:

Đố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

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.

1. Mở backlog và chọn 3 item nhỏ đã sẵn sàng.
2. Tạo một sprint và kéo 3 item vào sprint.
3. Bắt đầu sprint, sau đó chuyển một item sang In progress.
4. Hoàn thành item và chuyển sang Done kèm một comment ngắn về kết quả.

Happy path #1 — Groom backlog → lập kế hoạch sprint

1. Review các item top trong backlog và xoá các item trùng rõ ràng.
2. Làm rõ phạm vi từng item và thêm acceptance criteria.
3. Ước lượng/size item theo cách team bạn dùng (nếu có).
4. Link phụ thuộc và nhận diện blocker.
5. Tạo sprint và chỉ kéo các item đã sẵn sàng vào.
6. Đặt sprint goal và bắt đầu sprint.

Happy path #2 — Thực thi hằng ngày trên board

1. Bắt đầu từ board: nhận diện việc đang bị chặn hoặc bị “già” (aging).
2. Kéo item ưu tiên cao nhất tiếp theo khi có capacity.
3. Cập nhật status khi công việc di chuyển (tránh cột bị “mốc”).
4. Thêm comment nhanh cho handoff hoặc quyết định.
5. Giới hạn WIP: hoàn thành item trước khi bắt đầu item mới.
6. 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

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.

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:

1. Chốt câu hỏi (vd: “Sprint goal có đang on-track không?”).
2. Chọn đúng góc nhìn (report, dashboard gadget, hoặc insights).
3. Diễn giải theo ngữ cảnh (thay đổi scope, blocker, ngày nghỉ).
4. 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

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.

1. Chọn câu hỏi: “Tuần này đang bị chặn bởi cái gì?”
2. Tạo filter để tìm các item bị chặn (theo convention của team bạn).
3. Tạo dashboard và thêm một gadget dùng filter đó.
4. Chia sẻ dashboard cho team (chỉ xem).

Happy path #1 — Dashboard team trong 10 phút

1. Tạo saved filter cho ‘My open work’ (hoặc team queue).
2. Tạo dashboard mới với tên rõ ràng (Team — Weekly).
3. Thêm 3 gadget: filter results, sprint progress (nếu Scrum), và recently updated items.
4. Sắp xếp lại để gadget quan trọng nhất ở góc trên-trái.
5. Chia sẻ cho team ở chế độ chỉ xem.
6. 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

1. Xác định stakeholders quan tâm gì (deadline, scope, risk).
2. Tạo stakeholder dashboard với gadget “tầm cao” (tránh nhiễu).
3. Thêm gadget hiển thị top risks (item blocked/aging).
4. Chia sẻ trong Confluence để gắn với ngữ cảnh dự án.
5. Review hàng tuần và bỏ gadget không ai dùng.
6. Dùng dashboard trong status update thay vì slide deck.

Điểm ra quyết định

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.

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”.

1. Trigger: khi nào rule bắt đầu (vd: work item được tạo).
2. Condition: kiểm tra có nên chạy tiếp hay không.
3. Action: rule sẽ làm gì (set field, notify, tạo item).
4. 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

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.

1. Tạo rule với trigger “work item created”.
2. Thêm condition cho một work item type cụ thể.
3. Thêm action để add label (vd: triage).
4. Tạo 1 work item test khớp điều kiện, và 1 cái không khớp.
5. Xem audit log để xác nhận hành vi đúng.

Happy path #1 — Tạo rule tự động hoá đầu tiên

1. 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).
2. Chọn Create rule.
3. Chọn trigger khớp sự kiện (vd: item created).
4. Thêm condition để thu hẹp phạm vi (type, project, label).
5. Thêm action (set field, notify, tạo item).
6. 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)

1. Mở rule hiện có và ghi nhận hành vi hiện tại.
2. Sửa nhỏ (1 condition hoặc 1 action).
3. Giữ ở draft và test nếu môi trường của bạn cho phép test an toàn.
4. Kiểm tra audit log sau thay đổi để phát hiện lỗi hoặc edit lạ.
5. Publish thay đổi và theo dõi trong 1 ngày.
6. Nếu phát sinh ồn, disable nhanh rồi iterate tiếp.

Điểm ra quyết định

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.

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.

1. User có quyền vào Jira site chưa (global permission)?
2. User có quyền vào space/project không (permission scheme)?
3. Work item cụ thể có bị hạn chế không (security level/classification)?
4. 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

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.

1. Chọn một tài khoản teammate (hoặc test user) có quyền hạn chế.
2. Thử mở một project và thực hiện một hành động (vd: tạo item).
3. Nếu bị chặn, kiểm tra global permissions rồi đến project scheme.
4. Chỉnh membership của role (ưu tiên) thay vì cấp admin.
5. Test lại và xác nhận chỉ đúng quyền mong muốn thay đổi.

Happy path #1 — Cấp quyền cho teammate vào project

1. Xác nhận họ cần làm gì (chỉ xem vs tạo/sửa/transition).
2. Kiểm tra họ có vào Jira được không (global permission).
3. Thêm họ vào đúng group/role của project.
4. Xác nhận permission scheme cấp đúng quyền cần thiết cho role đó.
5. Nhờ họ logout/login (nếu cần) và test lại.
6. 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”

1. Xác nhận key work item và project.
2. Kiểm tra user có xem được item khác trong cùng project không.
3. Nếu không, kiểm tra permission scheme/role membership của project.
4. Nếu có, kiểm tra issue security level hoặc hạn chế classification.
5. Kiểm tra filter/board có đang ẩn item (không phải lỗi quyền).
6. Áp dụng fix nhỏ nhất và test lại với user.

Điểm ra quyết định

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.

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.

1. Xác định cái gì là nhạy cảm (và cái gì không).
2. Đặt mặc định để ngăn sai sót (classification/security).
3. Chỉ áp dụng kiểm soát chặt hơn khi thực sự cần.
4. 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

Bài thực hành (5–15 phút)

Mục tiêu: Khoá an toàn một work item.

1. Tạo một work item test với nội dung placeholder không nhạy cảm.
2. Đặt hoặc kiểm tra classification mặc định (nếu project hỗ trợ).
3. Đổi security level của work item sang nhóm người xem bị giới hạn.
4. Nhờ một teammate không có quyền thử mở (hoặc dùng test user).
5. Hoàn tác/điều chỉnh nếu phạm vi truy cập quá rộng hoặc quá hẹp.

Happy path #1 — Đặt mặc định an toàn cho work item mới

1. Xác định mức nhạy cảm phổ biến của work trong project.
2. Đặt classification mặc định cho work items (nếu có).
3. Tạo item test và xác nhận classification tự áp dụng.
4. Giải thích cho team ý nghĩa nhãn và khi nào cần override.
5. Rà soát sau 1 tuần: overrides có được dùng đúng không?
6. Đ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

1. Mở work item và xác nhận có nội dung nhạy cảm.
2. Chọn đúng security level / restriction.
3. Kiểm tra roles cần thiết vẫn truy cập được.
4. Xác minh user không được phép không thể xem.
5. Thay nội dung nhạy cảm ở các trường công khai bằng tham chiếu an toàn.
6. Ghi lại lý do và các thay đổi đã thực hiện.

Điểm ra quyết định

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ế.

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.

1. Thêm work sources (spaces/projects/boards) vào plan.
2. Chọn mô hình lập lịch (sprints vs dates vs releases).
3. Xem và xử lý dependencies/cảnh báo.
4. 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

Bài thực hành (5–15 phút)

Mục tiêu: Tạo một plan nhỏ bao phủ hai spaces.

1. Tạo plan và thêm 2 work sources (spaces/projects).
2. Chuyển sang timeline view và lọc phạm vi nhỏ.
3. Lập lịch 1 work item bằng sprints hoặc dates.
4. Thêm 1 dependency giữa các items (nếu phù hợp).
5. Lưu thay đổi và chia sẻ view với teammate.

Happy path #1 — Tạo plan phối hợp nhỏ giữa các team

1. Xác định 2–3 team/spaces cần điều phối.
2. Tạo plan và thêm các spaces đó làm work sources.
3. Chọn cách lập lịch (sprints hoặc dates) theo cách team vận hành.
4. Dùng timeline/list để xác minh work hiển thị đúng.
5. Thêm/kiểm tra dependencies quan trọng và gán owner để xử lý.
6. 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ó)

1. Chuẩn bị: đảm bảo các team đã cấu hình sprints/releases nhất quán.
2. Mở program board view của plan.
3. Đưa các work items chính vào sprint/iteration mục tiêu.
4. Rà soát đường dependency và xử lý xung đột rõ ràng.
5. Điều chỉnh capacity và thứ tự (sequencing) khi cần.
6. Publish/chia sẻ plan view để đồng bộ.

Điểm ra quyết đị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.