Xây dựng hệ thống quản lý hoàn toàn miễn phí với Redmine

Chương 2 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này bắt đầu phần thực hành: tải và cài Redmine bằng gói Bitnami trên máy local (Windows). Bitnami đóng gói sẵn Redmine cùng web server và database nên bạn chỉ cần chạy một file cài đặt là xong. Nhưng điểm mấu chốt của cả bài không nằm ở việc bấm Next — mà ở chỗ chọn đúng phiên bản Redmine.

─── SAU BÀI HỌC, BẠN SẼ

• Biết tải gói Bitnami Redmine đúng phiên bản từ nguồn giảng viên cung cấp.
• Cài được Redmine chạy ở local trên Windows chỉ với vài bước.
• Tránh được cạm bẫy chọn nhầm bản mới nhất khiến plugin không tương thích.

─── NỘI DUNG CHÍNH

▸ 1. Tải Redmine từ Bitnami

Vào bitnami.com → Applications → Redmine. Bitnami có rất nhiều dạng cài: trên Cloud, trên Docker, hoặc bản chạy trực tiếp trên Windows. Vì đang cài ở local nên chọn bản Windows, tải file cài đặt về.

▸ 2. Mẹo quan trọng: chọn ĐÚNG phiên bản, đừng lấy bản mới nhất

Đây là chỗ dễ sai nhất và quyết định cả khóa học có chạy trơn hay không.

Redmine hoạt động cùng plugin, mà mỗi plugin chỉ tương thích với một số phiên bản Redmine nhất định. Nếu bạn tải bản Redmine mới nhất, sau này rất khó tìm plugin khớp — mỗi plugin phải đi lục lại từng bản, rất mất công.

Vì vậy giảng viên không dùng bản mới nhất mà dùng Redmine 4.2, phiên bản đã được kiểm chứng tương thích với bộ plugin của khóa học. Trong slide có sẵn link hướng dẫn tải đúng bản này (từ website của khóa, dẫn tới trang download). Hãy tải đúng phiên bản đó để mọi bài thực hành sau khớp với video.

▸ 3. Chạy file cài đặt ở local

Giải nén file tải về (bản đóng gói của Smart IT Soft), chạy file `.exe`:

• Chọn ngôn ngữ, bấm Yes / Next qua các bước.
• Cài vào đúng thư mục như trong hướng dẫn.
• Bỏ tick phần cấu hình cho server — vì đang cài ở local, không cần phần này.

Sau khi trình cài đặt chạy xong, Redmine đã sẵn sàng ở máy của bạn để bước sang các bài cấu hình roles, permission và workflow tiếp theo.

Chương 2 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trước khi phân quyền được cho ai, Redmine cần biết dự án của bạn có những vai trò nào. Bài này hướng dẫn dựng danh sách roles bám theo sơ đồ tổ chức thật của một dự án phần mềm, tận dụng chức năng Copy để khỏi cấu hình lại từ đầu, và sắp xếp thứ tự roles cho gọn khi hiển thị ở tab Overview.

─── SAU BÀI HỌC, BẠN SẼ

• Biết đường vào màn hình quản lý roles: Administration → Roles and permissions.
• Tạo được role mới bằng cách copy từ role có sẵn thay vì tick tay từng permission.
• Sắp xếp lại thứ tự roles để danh sách thành viên trong tab Overview đúng cấp bậc.

─── NỘI DUNG CHÍNH

▸ 1. Bắt đầu từ org chart, không phải từ Redmine

Giảng viên nhấn mạnh: hãy vẽ sơ đồ tổ chức dự án trước, rồi mới mở Redmine lên tạo. Bộ roles trong ví dụ gồm 8 vai trò: Project Manager, Business Analyst, Translator/Comtor, Team Leader, Developer, Tester, Team QA, Customer.

Con số 8 không phải luật. Dự án của bạn có bao nhiêu vai trò thì tạo bấy nhiêu — quan trọng là liệt kê ra giấy trước.

▸ 2. Mỗi role là một bộ permission

Bấm vào một role bất kỳ, bạn sẽ thấy danh sách rất dài các permission: được xem gì, sửa gì, thao tác gì trên hệ thống. Ở bài này bạn chưa cần hiểu hết — chi tiết sẽ được mổ xẻ ở bài kế tiếp.

▸ 3. Mẹo quan trọng: dùng Copy thay vì tạo mới

Đây là phần đáng giá nhất của bài.

Bấm New role đồng nghĩa với ngồi tick lại hàng chục permission — vừa lâu vừa dễ sót. Thay vào đó: chọn một role đã cấu hình xong (ví dụ Developer), bấm Copy, đặt tên mới (ví dụ Tester). Role mới mang nguyên bộ permission và workflow của role gốc; bạn chỉ cần chỉnh vài điểm khác biệt.

Trong video, giảng viên copy Developer → Tester, rồi copy tiếp Tester → Comtor, và cứ thế nhân bản cho các role còn lại. Những role có quyền hạn gần giống nhau thì copy từ nhau sẽ nhanh nhất.

▸ 4. Sắp xếp thứ tự roles

Sau khi tạo đủ, dùng chức năng sắp xếp để đưa role cấp cao lên trên, cấp thấp xuống dưới (Manager → Team Leader → Developer/Tester → Customer). Thứ tự này chính là thứ tự hiển thị danh sách thành viên ở tab Overview của dự án — sắp đúng thì nhìn vào biết ngay ai là ai.

Chương 2 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Có roles rồi thì phải quyết định mỗi role được làm gì — đó là permission. Bài này đi trọn quy trình thật: tạo user account theo sơ đồ tổ chức, add từng người vào project đúng role, rồi chỉnh permission cho từng role và xem hiệu ứng ngay lập tức qua hai cửa sổ đăng nhập song song. Điểm mấu chốt: phân quyền phải bám theo quy trình thực tế của công ty, không phải bật hết cho tiện.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được user và add thành viên vào project đúng role.
• Chỉnh permission trong Administration → Roles and permissions và kiểm chứng kết quả trực tiếp.
• Nắm nguyên tắc phân quyền theo cấp bậc và theo khách hàng.

─── NỘI DUNG CHÍNH

▸ 1. Tạo user và add vào project đúng role

Đăng nhập bằng account Administrator, vào tạo New user: nhập account, first name, email, password rồi Create. Làm lần lượt cho cả danh sách theo sơ đồ tổ chức.

Sau đó tạo project mới, vào Add member, thêm từng người và gán đúng role. Giảng viên nhấn mạnh: add đúng role là quan trọng nhất — vì mọi phân quyền phía sau dựa vào role này; add sai role thì quyền sẽ sai theo (khách hàng thành Customer, PM thành Project Manager, v.v.).

▸ 2. Mẹo hiển thị: đổi cách gọi tên thành viên

Nếu danh sách thành viên hiển thị bằng tên đầy đủ khó tra, vào Administration → Settings, đổi Users display format sang dạng account (login) — nhìn vào biết ngay ai là ai. Đây là chỉnh nhỏ nhưng giúp cả quá trình phân quyền dễ theo dõi hơn nhiều.

▸ 3. Sắp xếp thứ tự trong tab Overview

Trong màn hình Roles and permissions có phần sắp xếp thứ tự roles. Đưa role nào lên trước, role nào xuống sau ở đây thì danh sách thành viên trong tab Overview của project sẽ hiển thị theo đúng thứ tự đó — sắp theo cấp bậc cho gọn.

▸ 4. Mẹo quan trọng: kiểm chứng permission bằng hai cửa sổ song song

Đây là cách làm đáng học nhất của bài. Giảng viên mở hai session cùng lúc: một tab đăng nhập account admin để chỉnh, một tab đăng nhập account của Project Manager (Hải NV) để xem kết quả. Chỉnh xong ở tab admin, bấm Save, qua tab kia nhấn F5 là thấy ngay quyền bị bật/tắt — không phải đoán mò.

Ví dụ trong video: bỏ tick các permission Project của role PM (không cho tạo/xóa project) rồi save; F5 lại thì đúng là PM mất luôn nút đó.

▸ 5. Nguyên tắc phân quyền thực tế

• Bám theo quy trình công ty: ví dụ để đạt chứng nhận ISO, role PM không được tự tạo/xóa project — quyền đó thuộc admin. Đừng bật hết cho tiện.
• Role cấp cao hơn thì quyền nhiều hơn so với role dưới — đây là nguyên tắc chung khi rải permission.
• BA thường được quyền quản lý document (add/edit/delete), lưu query, xử lý các mục liên quan phân tích.
• Khách hàng (Customer): chỉ cho xem chi tiết issue cần thiết; bỏ quyền vào repository / SVN để họ không thấy dữ liệu nội bộ, mã nguồn private của dự án.

Chương 2 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Workflow trả lời câu hỏi: khi một người thao tác trên ticket, họ được chuyển ticket sang những trạng thái (status) nào — và trường nào bắt buộc phải điền khi ở trạng thái đó. Bài này cấu hình workflow riêng cho từng role trong Administration → Workflow, rồi kiểm chứng ngay bằng hai cửa sổ song song như bài permission. Điểm mấu chốt: workflow phải khớp với luồng công việc thật của dự án, mỗi role một kiểu.

─── SAU BÀI HỌC, BẠN SẼ

• Đọc và chỉnh được ma trận chuyển trạng thái (status transition) cho từng role.
• Đặt được trường bắt buộc (required) theo từng trạng thái để dữ liệu luôn đầy đủ.
• Biết dùng điều kiện Author / Assignee để phân luồng riêng cho người tạo và người được giao.

─── NỘI DUNG CHÍNH

▸ 1. Vấn đề: ai được chuyển status nào

Khi tạo mới một issue, ban đầu status thường chỉ là New. Việc từ New đi tiếp sang đâu (In Progress, Resolved, Closed…) không phải ai cũng được làm — điều đó do workflow của role quyết định. Đó là thứ bài này cấu hình.

▸ 2. Đọc ma trận chuyển trạng thái

Vào Administration → Workflow, chọn role (ví dụ Project Manager) và tracker (ví dụ Bug) rồi bấm Edit. Bạn thấy một ma trận: hàng là trạng thái hiện tại (current status), cột là trạng thái được phép chuyển tới (new statuses allowed). Tick vào ô nào là cho phép chuyển từ trạng thái đó sang trạng thái đó.

Ví dụ: ở trạng thái New, tick các ô để role được chuyển sang status khác; bỏ tick thì role đó mất quyền chuyển. Save xong, qua tab của Project Manager nhấn F5, tạo new issue — sẽ thấy đúng những status vừa được bật/tắt.

▸ 3. Điều kiện riêng cho Author và Assignee

Phía dưới ma trận chung còn hai khối điều kiện riêng:

• Author — người tạo ticket: khi họ ở trạng thái này thì được chuyển xuống status nào.
• Assignee — người được giao ticket: có luồng chuyển riêng của họ.

Khối trên là điều kiện chung; hai khối dưới cho phép tách luồng theo vai người tạo và người xử lý, phản ánh đúng quy trình thật.

▸ 4. Mẹo quan trọng: đặt trường bắt buộc theo trạng thái (Field permissions)

Đây là phần giúp dữ liệu dự án không bị bỏ trống. Sang tab Field permissions (cùng màn hình Workflow), với mỗi trạng thái bạn chọn mức cho từng field: Read-only hay Required (bắt buộc).

Ví dụ trong video: đặt Due date thành Required khi issue ở trạng thái New. Qua tab kia F5 lại, nếu người dùng không nhập Due date thì hệ thống báo lỗi, không cho lưu. Trường nào cần thì bật Required, trường nào không thì tắt.

▸ 5. Chỉnh workflow cho phù hợp dự án

Mỗi role, mỗi tracker (Bug, Feature, Support…) nên có workflow riêng. Muốn cấu hình đúng, bạn phải hiểu các status và luồng công việc của dự án mình, rồi chỉnh ma trận + field permissions cho khớp. Cấu hình workflow chuẩn ngay từ đầu cũng giúp phần thống kê, báo cáo về sau chính xác hơn.

Chương 2 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi công ty đã có sẵn tài khoản nhân viên trên Active Directory (Windows Server), bạn không nên bắt mọi người tạo lại tài khoản Redmine từ đầu. Bài này hướng dẫn nối Redmine với AD qua LDAP, để người dùng đăng nhập Redmine bằng chính tài khoản domain của họ. Điểm mấu chốt: Redmine chỉ đóng vai trò hỏi AD xem mật khẩu có đúng không, còn tài khoản vẫn do AD quản lý.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu ý tưởng xác thực tập trung: một tài khoản domain dùng chung cho nhiều hệ thống.
• Biết đường vào cấu hình LDAP trong Redmine và các thông tin cần điền.
• Phân biệt được tài khoản LDAP và tài khoản Internal khi tạo user.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị phía Windows Server

Trước tiên bạn cần một Windows Server đã cài Active Directory và tạo sẵn ít nhất một user để test. Phần dựng AD và bật dịch vụ LDAP trên server không nằm trong bài này — giảng viên cố ý bỏ qua vì trên mạng (YouTube) đã có rất nhiều hướng dẫn. Bạn chỉ cần nhớ: đầu ra của bước này là một tài khoản domain hoạt động được.

▸ 2. Khai báo LDAP trong Redmine

Vào Administration → LDAP authentication → New, rồi điền các thông tin kết nối tới AD: địa chỉ server, port, tài khoản bind, base DN và cách ánh xạ các trường (tên, email…). Điền xong bấm Create.

▸ 3. Mẹo quan trọng: bấm Test trước khi tin

Sau khi tạo, đừng vội cho người dùng đăng nhập. Hãy bấm nút Test ngay trên màn hình cấu hình. Nếu kết nối tốt, Redmine báo "Successful connection" — đó là tín hiệu Redmine đã nói chuyện được với AD. Nếu báo lỗi, gần như chắc chắn sai địa chỉ server, port hoặc tài khoản bind, sửa lại rồi test tiếp.

▸ 4. LDAP hay Internal khi tạo user

Khi tạo một tài khoản mới trong Redmine, hệ thống hỏi bạn chọn nguồn xác thực: LDAP hay Internal.

• Chọn LDAP: mật khẩu do AD giữ, người dùng đăng nhập bằng tài khoản domain.
• Chọn Internal: Redmine tự quản lý mật khẩu, không dính tới AD — hợp cho tài khoản khách hoặc người ngoài domain.

Lưu ý thêm: máy demo trong video chạy Windows 11 nên không có sẵn LDAP; giảng viên phải mượn một máy Redmine khác đã nối AD để test. Với bạn, hãy chuẩn bị đúng môi trường Windows Server trước khi làm theo.

Chương 2 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bản Redmine mặc định khá "trơ" — chưa đủ tính năng để dựng nên hệ thống trong bản demo đầu khóa. Bài này hướng dẫn bạn cài plugin để bổ sung tính năng: chép plugin vào đúng thư mục, chạy vài câu lệnh cài đặt, rồi restart dịch vụ. Điểm mấu chốt phải nhớ: mỗi plugin chỉ chạy đúng với một phiên bản Redmine nhất định.

─── SAU BÀI HỌC, BẠN SẼ

• Biết plugin nằm ở thư mục nào trong bộ cài Redmine (Bitnami).
• Cài được plugin qua các câu lệnh: cài dependency rồi migrate vào hệ thống.
• Tự đọc thông báo lỗi để xử lý xung đột phổ biến giữa các plugin.

─── NỘI DUNG CHÍNH

▸ 1. Lấy plugin và chép vào đúng chỗ

Giảng viên đã gom sẵn bộ plugin cần dùng trên trang tài liệu của khóa (mục Download, có mật khẩu giải nén). Tải về, giải nén, rồi copy toàn bộ các thư mục plugin vào thư mục `plugins` bên trong `apps/redmine/htdocs` của bộ cài. Mỗi plugin là một thư mục con — bỏ hết vào cùng một chỗ.

▸ 2. Chạy lệnh cài đặt

Mở Command Prompt bằng quyền Administrator (dùng file `use_ruby.bat`/`use_redmine.bat` mà Bitnami cung cấp để nạp đúng môi trường). Sau đó chạy hai bước theo thứ tự:

1. Cài các thư viện mà plugin cần (bundle install).
2. Chạy migrate để build plugin vào cơ sở dữ liệu Redmine.

Các câu lệnh này giảng viên đã để sẵn để bạn copy–paste, không phải gõ tay.

▸ 3. Restart và kiểm tra

Migrate xong, vào Bitnami service manager bấm Restart lại dịch vụ Redmine. Quay lại Redmine, mở Administration → Plugins, bạn sẽ thấy danh sách plugin vừa thêm hiện ra — nghĩa là đã cài thành công.

▸ 4. Lưu ý khi cài: phiên bản và xung đột

Đây là phần dễ vấp nhất.

• Đúng phiên bản: không phải plugin nào cũng cài được. Mỗi plugin ghi rõ nó hợp với version Redmine nào; cài lệch version là hỏng. Kiểm tra trước khi tải.
• Xung đột khi cài nhiều plugin: khi bỏ nhiều plugin vào cùng lúc, đôi khi hai plugin bị trùng (duplicate) khai báo với nhau và migrate báo lỗi. Cách xử lý: đọc kỹ thông báo lỗi, nó chỉ ra chỗ đụng, rồi chỉnh lại. Nếu đọc lỗi mà chưa rõ, giảng viên gợi ý liên hệ để được hỗ trợ.

Bài này mới dừng ở việc cài plugin; cách dùng từng plugin sẽ được hướng dẫn ở các bài sau.

Chương 2 · Bài 7 — Phần 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài "xương sống" của chương 2: từ một Redmine trống, bạn dựng nên một dự án phần mềm hoàn chỉnh. Giảng viên đi theo một outline soạn sẵn (dự án mẫu tên gsit21, có ngày start/end) rồi lần lượt bật module, tạo custom field, tracker, cấu hình workflow, dựng Gantt chart và import task. Điểm mấu chốt: thiết kế trên giấy trước, thao tác trên Redmine sau — biết cần trường nào, tracker nào rồi mới mở hệ thống lên làm.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được dự án, bật đúng module và điền thông tin mô tả (customer, thời gian…).
• Tạo custom field và tracker (task, bug, issue, report…) đúng nhu cầu dự án.
• Đặt được ràng buộc field theo workflow và dựng Gantt chart từ target version.

─── NỘI DUNG CHÍNH

▸ 1. Tạo dự án và bật module

Cách nhanh nhất là copy một dự án đã có rồi sửa lại tên, mô tả, ngày tháng và bấm Save. Vào Settings → Modules của dự án, tick những module cần dùng (issue tracking, gantt, wiki, news…), lưu lại. Xóa các issue cũ còn sót từ dự án gốc để bắt đầu sạch.

▸ 2. Custom field và tracker

Vào Administration → Custom fields → New để tạo các trường riêng của dự án: Category, QC Activity, Screen ID, Credit action/Credit list… Mỗi trường chọn đúng kiểu dữ liệu (list/drop-down, text area…), gán cho tracker nào (thường là bug), cho dự án nào, và có cho phép filter hay không. Sau đó tạo tracker: task, bug, issue, issue read, report. Mẹo: những tracker gần giống nhau thì dùng Copy để nhân bản cho nhanh, rồi chỉnh vài field khác biệt.

▸ 3. Mẹo quan trọng: ràng buộc field bằng workflow

Đây là phần giá trị nhất. Vào Administration → Workflow → Fields permissions, chọn role + tracker + trạng thái, rồi đặt trường thành Required (bắt buộc) hay để trống. Ví dụ trong video: với task, trường due date là bắt buộc; với bug, khi chuyển sang trạng thái closed/resolved thì các trường phân tích (màn hình, category…) đều bắt buộc phải nhập. Nhờ vậy dữ liệu dự án luôn đầy đủ, không ai "đóng bug" mà bỏ trống thông tin. Nhớ chọn hết các role liên quan chứ đừng chỉ chọn một role, kẻo ràng buộc bị thiếu.

▸ 4. Target version, Gantt chart và import task

Vào Settings → Versions → New version để tạo các target version (setup, coding, unit test, feedback…). Sau đó import task từ file CSV: export mẫu ra để lấy đúng cấu trúc header, đưa dữ liệu vào Google Sheets, tải xuống dạng CSV, rồi dùng Import (chọn format ngày dd/mm, encoding UTF-8, map các field cho khớp). Có task rồi, gán mỗi task vào một target version và chỉnh start/due date; màn hình Gantt sẽ tự vẽ đường tiến độ. Khi task đóng 100%, phần trăm hoàn thành của cả nhóm tự cộng lên; task quá hạn hiện màu đỏ.

Chương 2 · Bài 7 — Phần 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là phần tiếp nối trực tiếp của Phần 1. Sau khi đã có dự án với đầy đủ tracker, custom field, workflow và Gantt chart, bài này tập trung vào hai công cụ giúp nhìn thấy dữ liệu dự án: Chart (biểu đồ thống kê) và Query (bộ lọc issue lưu sẵn). Điểm mấu chốt: cấu hình một lần, dùng lại mãi — mỗi lần họp team chỉ cần mở chart/query ra là thấy ngay tình hình, không phải tổng hợp tay.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được các biểu đồ thống kê task/bug theo version, theo Screen ID, theo trạng thái.
• Dựng bộ lọc (Query) và lưu lại để cả team dùng chung.
• Biết lọc task trễ hạn bằng điều kiện due date "in the past".

─── NỘI DUNG CHÍNH

▸ 1. Tạo Chart để thống kê

Vào phần Chart, bấm New chart. Với mỗi biểu đồ bạn chọn: chart type (column, curling/burndown…), tracker (task hay bug) và trục nhóm — ví dụ nhóm theo target version hay theo Screen ID. Trong video giảng viên dựng vài biểu đồ tiêu biểu: task theo version, bug theo version, task/bug đang open theo Screen ID. Bấm Submit là biểu đồ hiện ra. Khi họp, nhìn biểu đồ là biết ngay màn hình nào còn nhiều bug, phần nào sắp xong.

▸ 2. Tạo Query (bộ lọc lưu sẵn)

Mở màn hình danh sách Issues. Bản chất một Query chính là bộ filter hiện tại mà bạn bấm Save lại để tái sử dụng. Cách làm: đặt điều kiện lọc (theo assignee, theo tracker, theo trạng thái…), chọn tracker và trạng thái mong muốn, rồi lưu với một cái tên gợi nhớ. Ví dụ "Task open by me": lọc tracker = task, status = open, assignee = me (chính tôi). Có thể thêm điều kiện author = me để ra đúng những issue do tôi tạo và đang giao cho tôi.

▸ 3. Mẹo quan trọng: lọc task trễ hạn bằng due date

Muốn tìm nhanh những task quá hạn, dùng điều kiện trên trường Due date. Redmine cho các lựa chọn tương đối như yesterday, next week, this month và đặc biệt là "in the past" / less than N days ago — tức mốc thời gian đã trôi qua. Chọn "in the past" nghĩa là mọi task có due date nhỏ hơn ngày hôm nay đều bị coi là trễ. Bỏ điều kiện assignee đi thì bộ lọc cho ra toàn bộ task trễ của cả dự án — rất hợp để rà soát trong buổi họp.

▸ 4. Query dùng chung cho cả team

Khi lưu Query, đặt phạm vi hiển thị cho to any user (mọi thành viên) thay vì chỉ mình bạn. Nhờ đó ai vào dự án cũng thấy bộ lọc, và điều kiện assignee = me sẽ tự áp dụng cho chính người đang xem — mỗi người mở ra là thấy đúng phần việc của mình. Query của Redmine tuy không mạnh bằng Jira nhưng dùng hằng ngày là quá đủ. Đến đây bạn đã có một dự án cơ bản hoàn chỉnh, khép lại bài 7 chương 2.

Chương 2 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trong một dự án đông người, người tạo ticket (khách hàng, người dùng cuối) thường không biết nên giao việc cho ai. Họ chỉ biết vấn đề của mình thuộc loại nào. Bài này hướng dẫn dùng Issue category để: người tạo chỉ cần chọn đúng danh mục, còn Redmine tự động gán (auto-assign) ticket cho đúng người phụ trách danh mục đó. Điểm mấu chốt: gắn sẵn "người phụ trách" vào category một lần, về sau ticket tự chảy về đúng địa chỉ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu khi nào nên dùng auto-assign theo category thay vì giao việc thủ công.
• Tạo được issue category và gán người phụ trách cho từng danh mục.
• Áp dụng mô hình này cho các hệ thống kiểu support center / help desk.

─── NỘI DUNG CHÍNH

▸ 1. Bài toán: người báo lỗi không biết giao cho ai

Hãy hình dung một hệ thống support center của phòng IT. Công ty có nhiều IT, mỗi người phụ trách một mảng: mạng, máy tính, phần cứng, cấu hình dự án… Người dùng gặp sự cố chỉ biết vấn đề của mình thuộc mảng nào, chứ không biết tên người xử lý. Tương tự trong dự án phần mềm: khách hàng báo một bug UAT nhưng không biết bug đó nên giao cho ai trong team.

▸ 2. Cách làm: gán người phụ trách vào category

Vào Settings → Issue categories của dự án, tạo các category theo mảng công việc (ví dụ: Network, Bug UAT, Phần cứng…). Với mỗi category, ở ô Assigned to chọn sẵn người sẽ nhận — chẳng hạn category Bug UAT gán cho một PM, category Network gán cho IT phụ trách mạng. Đây chính là chỗ tạo nên hành vi tự động.

▸ 3. Kết quả: ticket tự chảy về đúng người

Khi người dùng bấm New issue, họ chỉ cần chọn đúng category rồi bấm Create — không cần chạm vào ô Assignee. Ngay lúc tạo, Redmine tự điền người phụ trách đã cấu hình cho category đó. Ví dụ trong video: khách hàng tạo một bug, chọn category Bug UAT, để trống người nhận; tạo xong hệ thống tự forward ticket sang đúng người chịu trách nhiệm mảng đó.

▸ 4. Lưu ý khi áp dụng

Cách này phát huy giá trị nhất ở các hệ thống tiếp nhận yêu cầu từ nhiều người ngoài dự án (support center, help desk). Bí quyết vận hành: hướng dẫn người tạo ticket chỉ cần log đúng theo category/bộ phận, phần "giao cho ai" để hệ thống lo. Nhờ đó giảm nhầm lẫn, ticket không bị lạc và người phụ trách nhận việc ngay.

Chương 2 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trong một dự án, có trường bắt buộc nhập, có trường không. Và cùng một trường, với tracker này thì bắt buộc nhưng với tracker khác lại không cần. Bài này hướng dẫn hai mức đặt ràng buộc cho custom field trong Redmine: ràng buộc cứng (áp cho mọi trường hợp) và ràng buộc theo tình huống (theo role, tracker, trạng thái). Điểm mấu chốt: chọn đúng mức ràng buộc để dữ liệu vừa đầy đủ vừa không phiền người nhập.

─── SAU BÀI HỌC, BẠN SẼ

• Đặt được một custom field thành bắt buộc cho tất cả tracker (ràng buộc cứng).
• Đặt ràng buộc linh hoạt: bắt buộc với task nhưng bỏ với bug/issue.
• Biết ràng buộc còn có thể phụ thuộc vào issue status trong workflow.

─── NỘI DUNG CHÍNH

▸ 1. Hai cách ràng buộc một field

Redmine cho bạn hai chỗ để bắt một trường phải nhập:

• Ràng buộc cứng — ở chính custom field: tick ô Required khi cấu hình field. Field đó lập tức bắt buộc nhập cho mọi tracker, mọi trạng thái. Nhanh nhưng "một size cho tất cả".
• Ràng buộc theo tình huống — ở Workflow: để field không Required, rồi vào workflow đặt riêng cho từng role/tracker. Linh hoạt hơn nhiều.

▸ 2. Ví dụ với trường Severity

Giảng viên minh họa bằng trường Severity. Cách cứng: vào Administration → Custom fields, chọn Severity, tick Required, lưu lại — từ đó tạo bất kỳ issue nào cũng bắt nhập Severity. Nhưng thực tế bạn chỉ muốn task bắt buộc, còn bug thì không. Vậy hãy bỏ Required ở custom field, rồi chuyển sang cấu hình workflow.

▸ 3. Mẹo quan trọng: dùng Fields permissions để ràng buộc linh hoạt

Đây là phần đáng nhớ nhất. Vào Administration → Workflow → Fields permissions, chọn role (nên chọn tất cả role liên quan) và tracker, rồi với mỗi trường đặt trạng thái: Required (bắt buộc), Read-only hoặc để trống. Ví dụ trong video: với tracker task, trường Severity đặt Required; quay lại tracker bug, cùng trường đó để không required. Kết quả: tạo task thì bị bắt nhập Severity, còn tạo bug thì không — đúng như mong muốn.

▸ 4. Ràng buộc còn phụ thuộc trạng thái

Bảng Fields permissions còn chi tiết đến từng issue status. Nghĩa là bạn có thể quy định: ở trạng thái New thì trường A chưa bắt buộc, nhưng khi chuyển sang Resolved/Closed thì trường A trở thành Required. Nhờ vậy dữ liệu được ép đầy đủ đúng vào thời điểm cần — ví dụ chỉ khi đóng bug mới bắt buộc điền kết quả phân tích. Hãy cân nhắc: field nào thật sự cần cứng thì tick Required ở custom field, còn lại nên đưa vào workflow để điều khiển theo tình huống.

Chương 2 · Bài 10

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Giao diện Redmine mặc định khá đơn điệu, chưa "đẹp và chuyên nghiệp". Bài này hướng dẫn cách đổi giao diện bằng cách cài thêm theme miễn phí tải trên mạng. Điểm mấu chốt: cài theme trong Redmine cực kỳ đơn giản — chỉ là chép thư mục theme vào đúng chỗ rồi chọn nó trong phần cài đặt, không cần lệnh migrate hay restart như khi cài plugin.

─── SAU BÀI HỌC, BẠN SẼ

• Tìm và tải được theme Redmine miễn phí trên mạng.
• Cài theme bằng cách chép vào đúng thư mục của bộ cài.
• Kích hoạt và đổi qua lại giữa các theme trong Administration.

─── NỘI DUNG CHÍNH

▸ 1. Tìm theme miễn phí

Dùng Google tìm với từ khóa kiểu "redmine free theme", bạn sẽ thấy rất nhiều theme kèm link trang web và link download. Giảng viên cũng để sẵn một theme miễn phí trên trang tài liệu của khóa để bạn tải nhanh. Chọn theme nào ưng ý rồi tải file nén về.

▸ 2. Chép theme vào đúng thư mục

Giải nén file vừa tải, bạn được một thư mục theme. Copy thư mục đó vào đường dẫn theme của bộ cài Redmine: trong Bitnami là `apps/redmine/htdocs/public/themes`. Đây là toàn bộ thao tác cài đặt — chỉ paste vào đúng chỗ là xong, không cần chạy lệnh gì thêm.

▸ 3. Kích hoạt theme

Quay lại Redmine, vào Administration → Settings → Display. Ở mục Theme, chọn theme bạn vừa chép vào rồi Save. Giao diện đổi ngay lập tức. Đây cũng chính là chỗ để đổi qua lại: muốn thử theme khác hay quay về theme cũ, chỉ cần vào lại Display chọn theme khác và lưu.

▸ 4. Lưu ý khi cài theme

Theme khác plugin ở chỗ rất nhẹ nhàng: không migrate, không restart dịch vụ, đổi là thấy liền. Bạn có thể tải nhiều theme, chép hết vào thư mục themes rồi thử lần lượt trong phần Display để chọn cái hợp nhất với hệ thống của mình.

Chương 3 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Số liệu dự án chỉ có ý nghĩa khi bạn nhìn được nó thành biểu đồ. Bài này mở đầu Chương 3 và hướng dẫn dùng plugin Chart để dựng các biểu đồ thống kê ngay trong dự án Redmine: tiến độ đóng/mở, số task hay bug open của từng người, phân bố theo status. Điểm mấu chốt: chọn đúng kiểu chart và đúng cách group by thì một cái nhìn là biết dự án đang đứng ở đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Bật/tắt được module Chart trong phần Settings của dự án.
• Tạo được biểu đồ mới bằng New chart, chọn tracker, khoảng thời gian và cách group by.
• Đọc được biểu đồ để phân bổ lại công việc cho hợp lý.

─── NỘI DUNG CHÍNH

▸ 1. Bật Chart và tạo biểu đồ mới

Chart là một module bật/tắt ở cấp dự án: vào Settings của dự án, tick cho module Chart hiển thị. Sau đó tab Chart xuất hiện trên menu dự án, bấm vào rồi chọn New chart.

Mỗi chart bạn cần khai báo vài thứ:

• Public / Private — Public thì mọi thành viên nhìn thấy, để mặc định (private) thì chỉ mình bạn thấy.
• Tracker — chọn tất cả tracker, hoặc loại bớt loại bạn không quan tâm (ví dụ chỉ giữ Task).
• Khoảng thời gian — ví dụ thống kê trong một năm qua.
• Trạng thái — chỉ những issue đang open, hay toàn bộ.
• Group by — nhóm theo cái gì: theo status, theo người phụ trách (assignee)…

▸ 2. Ba dạng thống kê hay dùng nhất

Giảng viên demo đúng những chart mà dự án thật cần đến:

• Tiến độ đóng/mở — dùng pie chart, group by status. Nguyên tắc quản trị: mọi tracker được đóng thì mới coi là xong. Trong demo, dự án đang ở mức ~96,8% chưa xong, chỉ ~3% đã đóng.
• Task open theo từng người — dùng column chart, group by assignee. Nhìn cột cao/thấp là biết ai đang gánh nhiều task, ai còn rảnh, từ đó phân bổ lại.
• Bug open theo từng người — tương tự nhưng đổi tracker sang Bug (hoặc Task request). Biết ai đang ôm nhiều lỗi để can thiệp kịp.

▸ 3. Mẹo quan trọng: chọn kiểu chart theo mục đích đọc

Đừng dựng chart cho có. Pie chart hợp để xem tỷ lệ (bao nhiêu phần trăm đã xong); column chart hợp để so sánh giữa các người hoặc các nhóm. Chọn tracker và group by phải trả lời được đúng câu hỏi bạn đang cần: "dự án xong chưa" thì group by status, "ai đang quá tải" thì group by assignee. Chọn sai chiều group by thì biểu đồ đẹp nhưng vô dụng.

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi bạn @ tên một người trong ticket, họ chỉ thực sự nhận được thông báo nếu Redmine đã biết cách gửi email. Bài này hướng dẫn hai việc phải làm song song: cấu hình SMTP (email server) trong file config của Redmine, và khai báo đúng Host name / URL trong Administration để link trong email nhảy về đúng ticket. Điểm mấu chốt: plugin Mention chỉ phát huy khi email đã thông.

─── SAU BÀI HỌC, BẠN SẼ

• Cấu hình được SMTP (ví dụ Gmail) trong file `configuration.yml` của Redmine.
• Restart đúng cách để service email có hiệu lực.
• Khai báo Host name và các mốc email notification để mention gửi mail và link về đúng ticket.

─── NỘI DUNG CHÍNH

▸ 1. Cấu hình email trong file config

Việc gửi mail không nằm ở giao diện mà ở file cấu hình. Mở file tại đường dẫn kiểu redmine/apps/redmine/htdocs/config/configuration.yml rồi điền thông tin SMTP — trong demo là SMTP của Gmail (host, port, tài khoản, mật khẩu ứng dụng). Đây là mail server bạn muốn Redmine dùng để gửi đi; bạn thay bằng Gmail hay mail server của công ty đều được.

▸ 2. Restart Bitnami Redmine để có hiệu lực

Sửa file config xong, mail chưa chạy ngay. Mở chương trình Bitnami Redmine (Manager), Restart toàn bộ server để service nạp lại cấu hình. Sau khi restart, đăng nhập lại vào Redmine. Đây là bước rất dễ quên: sửa config mà không restart thì email vẫn im.

▸ 3. Dùng Mention và kiểm tra email

Vào một ticket, khi bạn tạo mới hoặc cập nhật và @ một account, Redmine lấy cấu hình SMTP vừa khai để gửi noti tới email của người đó. Mở Gmail của account được @ là thấy mail "Mention Hello…", bấm vào là mở đúng ticket.

▸ 4. Lưu ý khi link trong email bị sai

Nếu bấm link trong email mà báo không tìm thấy ticket, gần như chắc chắn bạn chưa khai Host name / URL của hệ thống. Vào Administration → Settings → General, điền đúng Host name (domain Redmine của bạn) rồi lưu — link trong email mới ghép đúng địa chỉ ticket. Ngoài ra, ở Administration → Settings → Email notifications bạn chọn những sự kiện nào thì gửi mail (ví dụ khi có người update status, khi issue được thêm mới…) và đặt email admin để nhận phản hồi. Chọn đúng các mốc này để tránh vừa bị thiếu thông báo cần, vừa bị spam thông báo thừa.

Chương 3 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Additionals là một plugin "đa năng" gom nhiều tiện ích nhỏ vào một chỗ: hiện thông báo ở trang login, tùy biến giao diện, ẩn/hiện module, và quan trọng nhất là bộ Macro dùng ngay trong nội dung wiki và issue. Bài này đi qua từng tab của Additionals và chỉ cách bật/dùng Macro. Điểm mấu chốt: mọi cấu hình nằm ở Administration → Additionals, chia thành các tab General, Wiki, Macro, Issue, Web API, Menu.

─── SAU BÀI HỌC, BẠN SẼ

• Biết đường vào Administration → Additionals và hiểu từng tab dùng để làm gì.
• Đặt được message ở trang login và ẩn/hiện module khi tạo dự án.
• Dùng được Macro (ví dụ chèn ngày, link tới issue) và ẩn bớt macro không cần.

─── NỘI DUNG CHÍNH

▸ 1. Tab General — thông báo và tinh chỉnh giao diện

Ở tab General bạn có thể đặt các message hiển thị ở những vị trí cố định: text ở trang login (ví dụ hướng dẫn cho người muốn đăng ký), sidebar, footer, message phía trên phần issue. Bật lên, Apply, rồi qua trang tương ứng là thấy ngay. Cũng ở đây có các tùy chọn tiện lợi như mở link ra new tab, thêm nút Go to top — bật thì trang dài cuộn xuống có nút nhảy lên đầu, tắt thì mất nút.

▸ 2. Ẩn module khi tạo dự án (Disable modules)

Mỗi lần tạo project, Redmine cho rất nhiều module mặc định. Trong Additionals bạn có thể disable trước một số module (ví dụ Files, Documents) — từ đó dự án mới tạo ra sẽ không còn các module đó, đỡ phải tắt tay từng cái. Chọn theo đúng nhu cầu chuẩn của công ty bạn.

▸ 3. Tab Wiki — định nghĩa nội dung mặc định

Tab Wiki cho phép định nghĩa sẵn content/sidebar cho trang wiki: khi cấu hình thì trang wiki mới có sẵn khung sidebar, nội dung mẫu; xóa cấu hình đi thì sidebar cũng biến mất. Đây là chỗ chuẩn hóa bố cục wiki cho cả hệ thống.

▸ 4. Mẹo quan trọng: dùng và ẩn Macro

Đây là phần "được việc" nhất của plugin. Tab Macro liệt kê toàn bộ macro có sẵn để dùng ngay trong ô nội dung của issue/wiki. Trong khung soạn thảo, bấm biểu tượng macro để chèn — ví dụ macro chèn ngày hôm nay, hay macro tạo link tới một issue/new issue. Muốn xem hướng dẫn chi tiết, mở Additionals documentation (New tab) — trong đó có đủ ví dụ chèn user, chỉnh màu, v.v.

Macro nào bạn không muốn cho dùng thì vào tab Macro, tick ẩn nó đi rồi Apply — ví dụ ẩn macro Twitter thì thanh công cụ soạn thảo sẽ không còn nút Twitter nữa. Các tab còn lại (Web API để nhúng key như Google Maps, Menu để tự định nghĩa mục menu trỏ tới URL của bạn kèm quyền chỉ member thấy) hoạt động theo cùng nguyên tắc: khai ở Administration, hiện ra ở giao diện.

Chương 3 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Một issue lớn thường gồm nhiều đầu việc con. Plugin Checklist cho phép thêm danh sách các mục cần làm ngay trong issue, tick dần khi hoàn thành, và có thể cho phần trăm % Done tự tăng theo số mục đã tick. Điểm mấu chốt: checklist chỉ tự cập nhật tiến độ khi bạn bật đúng tùy chọn — nếu không, bạn tick nhưng % Done vẫn đứng im.

─── SAU BÀI HỌC, BẠN SẼ

• Thêm được checklist với nhiều item vào một issue khi tạo mới.
• Tick từng item và hiểu vì sao % Done có (hoặc không) tự tăng.
• Bật cấu hình để checklist liên kết với tiến độ issue.

─── NỘI DUNG CHÍNH

▸ 1. Tạo checklist trong issue

Sau khi cài plugin, phần Checklist xuất hiện khi bạn tạo issue. Chọn tracker (ví dụ một loại content/task), rồi ở mục Checklist gõ lần lượt các item: check item 1, check item 2, check item 3… Bấm Create là issue đã có sẵn danh sách việc con.

▸ 2. Đánh checklist và theo dõi % Done

Mở issue ra, ở chế độ update bạn tick từng item đã xong. Nếu đã bật liên kết tiến độ, mỗi lần tick thì trường % Done tự nhích lên tương ứng — không phải chỉnh tay. Đây là cách chia nhỏ một đầu việc lớn và nhìn được nó đang đi được bao nhiêu phần.

▸ 3. Lưu ý quan trọng: bật liên kết % Done, nếu không tick vô ích

Đây là chỗ dễ sai nhất trong bài. Trong demo, giảng viên tạo một issue thứ hai với hai item nhưng không bật tùy chọn liên kết — kết quả là tick đủ mà % Done vẫn không tăng. Muốn checklist điều khiển tiến độ, bạn phải vào cấu hình Checklist bật tùy chọn cho phép tick item cập nhật % Done (và, nếu cần, tự đóng issue khi tick hết). Nếu chỉ muốn checklist làm danh sách nhắc việc thuần túy thì tắt tùy chọn đó — nhưng khi ấy đừng trông chờ phần trăm tự nhảy.

Chương 3 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mỗi lần tạo ticket mà phải gõ lại y nguyên một khuôn nội dung là rất mất công và dễ sót. Plugin Issue Template giải quyết đúng chuyện đó: bạn soạn sẵn form mẫu để người tạo ticket chỉ việc chọn và điền. Điểm mấu chốt: template có hai cấp — Global (áp cho toàn bộ hệ thống, mọi dự án) và theo từng dự án — chọn đúng cấp là điều bạn phải nắm.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được template cấp Global và template riêng của một dự án.
• Tạo được một Issue Template mới, gắn tracker và enable để dùng.
• Áp template vào issue để chuẩn hóa nội dung ticket cho cả team.

─── NỘI DUNG CHÍNH

▸ 1. Hai cấp template: Global và theo dự án

Vào Administration → Global Issue Templates để làm template dùng chung cho mọi dự án trong hệ thống Redmine. Còn nếu chỉ muốn khuôn mẫu cho một dự án, vào chính dự án đó, mở phần Issue Template của nó — template này chỉ sống trong dự án đấy. Ở phần Settings của plugin, bạn còn quyết định có cho phép áp Global Template ra toàn hệ thống hay không.

▸ 2. Tạo và bật một template

Bấm Add, đặt tên (ví dụ "Task Template 01"), chọn Tracker mà template áp dụng (ví dụ Task), rồi điền phần nội dung mẫu — mô tả, các mục cần liệt kê, checklist việc cần làm. Quan trọng: phải tick Enable thì template mới dùng được, sau đó chọn dự án áp dụng (hoặc để trống nếu là Global) và Create. Quay lại màn tạo issue, Refresh để template mới hiện ra.

▸ 3. Áp template khi tạo issue

Khi tạo issue mới, chọn Tracker (ví dụ Task) rồi chọn template tương ứng — nội dung mẫu tự đổ vào ô mô tả, bạn chỉ điền phần biến động. Template Global sẽ hiện chung với template riêng của dự án, phân biệt qua nhãn "Global Issue Template".

▸ 4. Vì sao template đáng dùng trong dự án thật

Công ty thường có nhiều quy trình, mỗi quy trình lại nhiều form mẫu (task, bug, Q&A, form tiếng Nhật/tiếng Anh…). Thay vì in giấy hay copy tay, bạn dựng sẵn mỗi form thành một Issue Template và quy định: role nào, tracker nào thì bắt buộc dùng template nào. Người tạo ticket cứ theo khung mà điền cho đủ — dữ liệu vào đồng nhất, ít thiếu sót, và người quản lý đọc ticket cũng nhanh hơn hẳn.

Chương 3 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Thông báo quan trọng mà nhắn trong group chat thì dễ bị trôi — người vào sau không thấy. Plugin Banner giải quyết bằng một dải thông báo dán cố định trên trang Redmine, ai vào cũng thấy. Điểm mấu chốt: banner có hai cấp — Global (toàn hệ thống) và theo dự án — kèm lựa chọn vị trí và màu theo mức độ quan trọng.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được banner Global hiển thị cho toàn hệ thống Redmine.
• Tạo được banner riêng cho một dự án và chọn trang hiển thị.
• Chọn vị trí (header/footer) và màu message phù hợp với mức độ khẩn.

─── NỘI DUNG CHÍNH

▸ 1. Banner Global — thông báo toàn hệ thống

Vào phần Banner ở cấp Administration, bật Step ahead, chọn message style (vị trí: header, footer, hoặc cả hai) và nhập nội dung — ví dụ "Server interrupt" hay lịch nâng cấp hệ thống. Chọn màu theo mức độ: đỏ cho cảnh báo quan trọng, xanh cho thông tin thường. Bấm Apply, banner hiện ngay ở đầu/cuối mọi trang, mọi người đều thấy. Xong việc thì tắt đi.

▸ 2. Banner theo dự án

Khi vào một dự án, phần Banner riêng nằm trong dự án đó. Nhập message rồi chọn phạm vi hiển thị: chỉ trang Overview, chỉ trang New issue, cả Overview và Issue, hay tất cả các trang. Ví dụ thực tế: "Thông báo có Change request từ khách hàng ở ticket…" — dán ở dự án để cả team đang làm dự án đó đều nhìn thấy. Bấm active/tắt để ẩn khi hết hiệu lực.

▸ 3. Lưu ý khi dùng: chọn đúng vị trí và màu

Banner mạnh ở chỗ không trôi, nên đừng lạm dụng — để quá nhiều banner cùng lúc thì người dùng sẽ ngó lơ hết. Dùng màu đỏ cho việc thật sự khẩn (downtime, sự cố), xanh cho nhắc nhở thường. Với thông báo chỉ liên quan một dự án thì đặt banner ở cấp dự án và giới hạn trang hiển thị, đừng đặt Global để khỏi làm phiền các dự án khác. Nhớ tắt banner khi thông tin đã hết giá trị.

Chương 3 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nhiều công ty sống trên Slack, nên mỗi thay đổi trong Redmine mà tự nhảy vào channel Slack thì team nắm việc rất nhanh. Bài này hướng dẫn tích hợp Redmine với một Slack group qua Incoming Webhook: mỗi khi có update issue, Slack nhận noti. Điểm mấu chốt: xương sống của tích hợp là URL webhook — lấy từ Slack, dán vào Settings của dự án Redmine.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được một Slack App và bật Incoming Webhook cho channel của mình.
• Dán URL webhook vào phần message của dự án Redmine để nối hai hệ thống.
• Hiểu cơ chế kế thừa webhook từ dự án cha xuống dự án con.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị Slack và tạo App

Trước tiên bạn phải có workspace và channel Slack (trong demo là workspace gg621, channel private). Vào api.slack.com → Your Apps, bấm Create New App, đặt tên (ví dụ "gg621.noti") và chọn workspace. Slack tạo xong app là bạn sang bước bật webhook.

▸ 2. Bật Incoming Webhook và lấy URL

Trong app vừa tạo, mở Incoming Webhooks, bật On, rồi Add New Webhook to Workspace và chọn channel đích. Slack sinh ra một Webhook URL — đây chính là "đường ống" để Redmine bắn tin sang. Copy URL này lại.

▸ 3. Cấu hình phía Redmine và demo

Về Redmine, vào dự án của bạn, mở Settings, tìm phần message/Slack của plugin và dán URL webhook vào, rồi Save. Ở đây có nhiều option bạn có thể tùy chỉnh: icon, channel, username hiển thị của message — thường để mặc định là đủ. Xong, thử chuyển status một issue hoặc edit message: Slack channel lập tức nhận noti về thay đổi đó. Wiki update cũng được đẩy sang.

▸ 4. Lưu ý quan trọng: dự án con kế thừa URL của dự án cha

Một điểm dễ bỏ sót: nếu phần message URL của một dự án để trống, plugin sẽ không im lặng mà dùng URL của dự án cha. Nghĩa là với dự án con, bạn có thể không cần khai lại webhook — nó tự lấy của dự án cha để noti. Nắm điều này để tránh bối rối khi một dự án con vẫn gửi noti dù bạn chưa điền URL cho nó, hoặc để cố tình cho cả nhánh dự án cùng bắn về một channel.

Chương 3 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Redmine mặc định quản lý thông tin người dùng rất sơ sài — vào My Account bạn gần như chỉ có username, password và email. Bài này giới thiệu plugin People: sau khi cài, mỗi user có một hồ sơ đầy đủ hơn hẳn (avatar, giới tính, ngày sinh, số điện thoại, phòng ban…), và bạn quản lý con người trong tổ chức ngay trên Redmine thay vì để rải rác nơi khác.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao thông tin user mặc định của Redmine là chưa đủ để quản lý nhân sự dự án.
• Cài và dùng plugin People để bổ sung các trường hồ sơ cho từng account.
• Biết cách gom user theo phòng ban và gắn người quản lý trực tiếp.

─── NỘI DUNG CHÍNH

▸ 1. Thông tin user mặc định quá ít

Mở My Account trên bản Redmine gốc, bạn chỉ thấy vài trường cơ bản: username, password, email. Với một dự án thật, chừng đó không đủ — bạn còn cần biết người này thuộc phòng ban nào, ai quản lý, liên hệ ra sao.

▸ 2. Plugin People bổ sung hồ sơ đầy đủ

Sau khi cài plugin People, vào danh sách users, chọn một account rồi bấm Edit. Lúc này màn hình có thêm nhiều trường: avatar, status, giới tính, ngày sinh, số điện thoại và các thông tin cá nhân khác. Bạn nhập vào đây để hồ sơ mỗi người đầy đặn hơn, tiện tra cứu và quản lý về sau.

▸ 3. Quản lý theo phòng ban và người quản lý trực tiếp

Điểm mạnh của People là gom nhóm con người: bạn tạo các phòng ban (department), xếp user vào đúng phòng ban, và chỉ định ai quản lý trực tiếp ai. Bạn có thể tạo liên tục nhiều department tùy theo cơ cấu tổ chức thật của công ty. Nhờ vậy, nhìn vào Redmine là thấy được sơ đồ nhân sự chứ không chỉ là một danh sách account rời rạc.

▸ 4. Lưu ý khi dùng

Đây là plugin tiện cho khâu quản trị con người, không bắt buộc để chạy dự án. Nếu tổ chức của bạn cần theo dõi nhân sự — phòng ban, cấp trên, thông tin liên hệ — thì cài People sẽ gọn hơn nhiều so với quản lý bằng file rời bên ngoài.

Chương 3 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trình soạn thảo mặc định của Redmine dùng cú pháp Textile — gõ chữ đậm, chèn ảnh, chèn link đều khó và dễ sai. Bài này hướng dẫn cài plugin WYSIWYG (Visual Editor) để có một khung soạn thảo giống Word: thấy sao ăn vậy, thao tác bằng nút bấm thay vì nhớ cú pháp. Điểm mấu chốt là một setting nhỏ giúp editor hiển thị đủ 3 tab, dùng thoải mái hơn hẳn.

─── SAU BÀI HỌC, BẠN SẼ

• Nhận ra sự khác biệt giữa editor mặc định và Visual Editor khi tạo issue.
• Cài và bật plugin WYSIWYG từ khu vực Administration.
• Chỉnh setting để chuyển editor sang chế độ nhiều tab, dễ dùng nhất.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao cần Word Editor

Khi tạo New issue trên Redmine gốc, phần mô tả chỉ là ô text thô theo cú pháp Textile. Muốn in đậm một đoạn, bạn phải bôi chọn rồi bấm nút và nó chèn ký hiệu vào; chèn ảnh hay link còn rắc rối hơn. Nhìn khó và dễ nhầm. Plugin Visual Editor sinh ra để giải quyết đúng chỗ này.

▸ 2. Cài và bật plugin

Vào phần admin, cài plugin editor (WYSIWYG / Visual Editor). Sau khi cài, vào Settings của plugin và bật nó lên. Khi tạo issue mới, khung soạn thảo lúc này là Visual Editor — chèn ảnh, chèn link, chèn chữ, chèn bảng đều làm bằng nút bấm trực quan, không cần nhớ cú pháp.

▸ 3. Mẹo quan trọng: bật chế độ Tab

Mặc định editor chỉ hiện 2 chế độ. Trong phần setting của plugin, tích chọn Use tab for mode switch rồi bấm Apply. Tải lại trang tạo issue, bạn sẽ thấy editor chuyển thành 3 tab. Giảng viên khuyên dùng kiểu này vì thao tác dễ hơn, chuyển qua lại giữa các chế độ soạn thảo nhanh gọn.

▸ 4. Khi vẫn muốn dùng cú pháp thô

Nếu bí, cạnh ô soạn thảo có nút Help liệt kê toàn bộ cú pháp Textile để tự gõ tay. Nhưng bảng cú pháp này khó nhìn — với đa số trường hợp, cứ dùng Visual Editor cho nhanh.

Tóm lại: cài plugin editor → vào Settings bật lên → chọn Use tab for mode switch → dùng Visual Editor cho mọi issue.

Chương 3 · Bài 10

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đôi khi bạn muốn chỉnh giao diện Redmine — đổi màu, ẩn một phần tử, thêm một tính năng nhỏ — nhưng không muốn sửa thẳng file mã nguồn trên server. Bài này giới thiệu plugin View Customize: một chỗ để chèn JavaScript, CSS hoặc HTML vào Redmine ngay từ giao diện web, áp dụng theo từng trang. Đây là plugin rất nổi tiếng và mạnh, cộng đồng chia sẻ sẵn vô số đoạn mẫu.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao nên dùng View Customize thay vì sửa trực tiếp file JS/CSS trên server.
• Tạo được một mục customize với đúng phạm vi trang (path pattern) và vị trí chèn code.
• Biết tìm và tái sử dụng các đoạn code mẫu có sẵn trên mạng.

─── NỘI DUNG CHÍNH

▸ 1. Hai cách can thiệp giao diện

Cách thủ công: bấm chuột phải chọn Inspect để soi phần tử, rồi sửa trực tiếp trong file JS/CSS của server. Cách này được nhưng rủi ro và khó quản lý. Cách gọn hơn là cài plugin View Customize và chèn code qua giao diện, không đụng vào mã nguồn gốc.

▸ 2. Cách tạo một mục customize

Vào phần View Customize, tạo mới và khai báo:

• Path pattern — mẫu đường dẫn để quy định code này áp dụng cho trang nào (ví dụ trang issue).
• Insertion / vị trí chèn — như head of page hoặc chèn vào phần thân, để đoạn code override lên phần mặc định.
• Loại code — JavaScript, CSS hay HTML.
• Enable để bật, rồi Save.

Trong video, giảng viên demo thêm hiển thị progress của dự án (Redmine gốc không hiện), và dùng CSS `display: none` để ẩn một phần text không muốn thấy. Sau khi save và F5, thay đổi xuất hiện ngay.

▸ 3. Ví dụ hữu ích: Copy to Clipboard

Một đoạn code đáng nhớ là Copy to Clipboard: mặc định Redmine không cho dán thẳng ảnh trong clipboard vào issue. Thêm đoạn code này qua View Customize, bạn chụp màn hình rồi Ctrl+V là ảnh được đưa vào luôn — tiện hơn hẳn.

▸ 4. Mẹo quan trọng: tận dụng code mẫu có sẵn

Không cần tự viết từ đầu. Lên mạng tìm "View Customize sample" sẽ ra rất nhiều đoạn code cộng đồng chia sẻ; plugin cũng có guideline của tác giả. Việc của bạn chỉ là copy đoạn phù hợp, dán vào một mục customize mới, chọn đúng path pattern và bật lên.

Chương 4 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở màn Chương 4 — chương dựng một dự án phần mềm thật trên Redmine. Bài đầu tiên điểm lại các roles (vai trò) thường có trong một dự án phần mềm và cách kiến trúc thứ bậc quyền hạn giữa chúng. Điểm mấu chốt: role không cố định con số, nhưng phải sắp theo tầng — role càng cao thì permission càng rộng.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm bộ role điển hình của một dự án phần mềm và vai trò của từng người.
• Hiểu nguyên tắc "role cao hơn thì quyền cao hơn" để tự kiến trúc phân quyền.
• Biết tạo thêm role mới trong Administration khi dự án có vai trò đặc thù.

─── NỘI DUNG CHÍNH

▸ 1. Toàn cảnh Chương 4

Chương 4 gồm nhiều bài đi từ giới thiệu role, cấu hình phân quyền từng role, phân loại các issue, cấu hình issue và workflow, import issue từ file CSV, dựng Gantt, thêm template cho task/bug/report, truy vấn query theo thành viên… Giảng viên sẽ làm trên một dự án cụ thể để bạn theo dõi từng bước.

▸ 2. Bộ 8 role điển hình

Trên trang đã setup ở chương trước, ví dụ có 8 role: Project Manager, BA, Team Leader, Developer, Tester, Comtor, QA, Customer. Trong đó:

• Project Manager — người coi cao nhất, có full quyền nhưng chỉ trong phạm vi dự án này, không phải trong dự án khác hay toàn hệ thống.
• Comtor — người phiên dịch, trao đổi (thường có trong dự án làm với khách nước ngoài).
• Các role kỹ thuật như Developer, Tester nằm ở tầng thực thi.

▸ 3. Số role không phải luật cứng

Con số 8 chỉ là ví dụ. Dự án của bạn cần bao nhiêu vai trò thì tạo bấy nhiêu. Ngoài bộ cơ bản, bạn có thể thêm những role đặc thù như:

• Reporter — người chuyên làm báo cáo.
• Configuration Management (CM) — người quản lý cấu hình dự án (quản lý CM, LAN, CC…).

Cách tạo: vào Administration → Roles and permissions → New role, đặt tên là xong.

▸ 4. Kiến trúc thứ bậc quyền hạn

Nguyên tắc cốt lõi: nhìn dự án từ trên xuống dưới, role nào cao hơn thì permission cao hơn. Ví dụ Dev Leader ngang Test Leader; BA cao hơn; Project Manager cao nhất. Bạn dựa vào quy định của dự án để define role nào trên role nào — làm rõ điều này trước thì bước cấu hình phân quyền ở bài sau sẽ mạch lạc.

Chương 4 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp bài trước, bài này đi vào chi tiết: mở từng role ra và tick chọn permission cho đúng cấp bậc. Giảng viên duyệt qua cả 8 role, cho thấy càng xuống thấp thì quyền càng ít. Điểm mấu chốt cần nhớ: quyền delete gần như dành riêng cho Project Manager, các role khác chỉ được view/add/edit trong phạm vi của mình.

─── SAU BÀI HỌC, BẠN SẼ

• Biết vào Administration → Roles and permissions để chỉnh permission của từng role.
• Hiểu logic phân quyền theo nhóm: dự án, issue, wiki, query, checklist, message.
• Nắm những giới hạn quan trọng: ai được delete, ai chỉ được sửa phần của mình.

─── NỘI DUNG CHÍNH

▸ 1. Phân quyền theo từng nhóm

Bấm vào một role, permission được chia theo nhóm: Project, Issue, Wiki, Query, Checklist, Repository, Time tracking, Message, Agile/Banner…. Với mỗi nhóm, bạn tick những gì role đó được làm. Duyệt lần lượt từ role cao xuống role thấp và siết dần quyền.

▸ 2. Role quản lý (PM, BA)

Với BA/PA: không cho tạo dự án, nhưng cho quản lý category, version, design, banner, chart, template. Về Issue: được view, add, edit (kể cả edit issue của người khác), copy, manage, tạo sub-task, set public/private, add/edit note. Về Wiki: view, edit, rename, manage. Nhưng không cho delete — kể cả delete issue lẫn delete wiki.

▸ 3. Role thực thi (Developer, Tester)

Quyền hẹp hơn rõ rệt. Về Issue thường chỉ view, add, edit của mình (Edit my issue), được copy issue, add/view/delete watcher, view + done checklist. Về Query chỉ được save query, không được edit query người khác. Với chat/message chỉ view, không tạo. Template thì chỉ được dùng (show), không được quản lý hay tạo. Wiki gần như chỉ xem, không cho edit — vì edit nhầm có thể xóa mất nội dung.

▸ 4. Comtor và Customer

Comtor có quyền cao hơn trong khu vực issue/message vì phải dịch: được edit tất cả phần nội dung liên quan, share query — nhưng không được manage version. Customer giới hạn ở mức xem và thao tác cơ bản (edit all trong phạm vi cho phép, view watcher), không được delete.

▸ 5. Lưu ý khi cấu hình: khóa chặt quyền delete

Xuyên suốt bài, quy tắc lặp lại là chỉ PM mới được delete. Muốn xóa issue hay bài wiki nào, các role khác phải báo PM. Đây là cách bảo vệ dữ liệu dự án khỏi bị xóa nhầm — hãy giữ nguyên tắc này khi tự phân quyền cho dự án của bạn.

Chương 4 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trong Redmine, mọi thứ bạn theo dõi đều là một issue, và mỗi loại issue được gắn một tracker khác nhau. Bài này giải thích ý nghĩa của từng loại tracker thường gặp trong dự án phần mềm — Task, Bug, Change Request, Issue, Risk, Q&A, Report — cùng những trường thông tin đặc trưng của mỗi loại. Nắm đúng bản chất từng loại giúp bạn phân loại công việc chuẩn ngay từ đầu.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được các tracker phổ biến và biết khi nào dùng loại nào.
• Biết những trường thông tin quan trọng cần điền cho Task và Bug.
• Hiểu rõ khác biệt giữa Issue (đã xảy ra) và Risk (chưa xảy ra).

─── NỘI DUNG CHÍNH

▸ 1. Task và Bug

• Task là công việc cần làm. Trường tối thiểu: title, status, priority, start date / due date, estimate time, người được assign; có thể thêm checklist để chia nhỏ đầu việc.
• Bug là lỗi — của hệ thống hoặc của tài liệu. Ngoài mô tả, ảnh, bước tái hiện, bug cần ghi lỗi thuộc khâu nào (review tài liệu, code review, unit test, integration test…), thuộc file/màn hình nào. Khi sửa, có hai trường quan trọng: nguyên nhân gây lỗi và hành động sửa chữa (ví dụ sửa ở class/CSS nào, ghi vào code review action).

▸ 2. Change Request (Change Event)

Trong quá trình vận hành dự án luôn có thay đổi. Những thay đổi đó gắn tracker Change Request: title, nội dung thay đổi, mã màn hình/file liên quan, người xử lý, thời gian tốn. Đặc biệt cần đánh giá mức độ impact của thay đổi.

▸ 3. Issue và Risk — điểm dễ nhầm nhất

• Issue là vấn đề đã xảy ra rồi. Ví dụ trời đang mưa (đã mưa): bạn phải đối ứng — mua áo mưa (tốn chi phí) hoặc chấp nhận ướt.
• Risk là rủi ro chưa xảy ra. Ví dụ khách hẹn giao tài liệu ngày 20/4; hôm nay mới mùng 3, nên "khách có thể trễ hạn" là risk. Nếu tới 20/4 khách chưa giao, nó chuyển thành issue. Với risk có hai cách đối ứng: chấp nhận hoặc chủ động phòng ngừa — nhưng phòng ngừa (ví dụ ngày nào cũng nhắc khách) đều tốn chi phí tracking.

▸ 4. Q&A và Report

• Q&A là hỏi–đáp với khách hàng trong quá trình làm tài liệu hoặc coding. Nên hỏi ngay trên hệ thống để có thứ tự và evidence; ghi rõ hỏi về tài liệu nào, mong muốn kết quả gì, và cập nhật deadline của Q&A. Q&A có nhiều loại: nghiệp vụ, kỹ thuật, chung.
• Report dùng cho báo cáo định kỳ (ví dụ report tuần cho khách): chọn tracker Report, ghi kỳ báo cáo từ ngày nào đến ngày nào rồi đính kèm file.

Chương 4 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài "ráp mọi thứ lại": cấu hình workflow — quy định từ trạng thái này được chuyển sang trạng thái nào, ứng với từng role và từng tracker — và quy định trường nào bắt buộc / chỉ đọc ở mỗi trạng thái. Điểm mấu chốt: bảng workflow là một ma trận current status → new status, và bạn phải cấu hình riêng cho từng cặp role–tracker thì hệ thống mới chạy đúng luồng.

─── SAU BÀI HỌC, BẠN SẼ

• Định nghĩa được bộ issue status và hiểu thế nào là issue "đóng" (closed).
• Đọc và cấu hình được bảng workflow dạng ma trận chuyển trạng thái.
• Thiết lập trường bắt buộc theo từng trạng thái cho mỗi loại tracker.

─── NỘI DUNG CHÍNH

▸ 1. Ba chỗ phải cấu hình

Để một dự án chạy trơn tru, cần cấu hình ăn khớp ở ba nơi: role permission (đã làm ở bài trước), tracker/issue và workflow. Bài này tập trung vào tracker và workflow.

▸ 2. Định nghĩa Issue Status

Trước hết dựng danh sách trạng thái, ví dụ: New, In-progress, Result, Feedback, Reset, Pending và một trạng thái hay bị quên là Cancel (hủy — issue coi như không cần làm gì nữa). Khi khai báo status, chú ý đánh dấu status nào là closed ("issue đóng") — với dự án của giảng viên, Pending cũng coi như đã đóng. Tracker nào chưa được gán workflow thì chưa dùng được, phải cấu hình vào.

▸ 3. Mẹo quan trọng: đọc bảng workflow dạng ma trận

Vào Workflow, chọn cặp role + tracker rồi tick Only display statuses that are used by this tracker cho gọn. Bảng hiện ra là ma trận: hàng là current status, cột là new status được phép chuyển tới. Ví dụ với role Customer: nếu chỉ cho New được chuyển thành New, thì khi tạo issue người dùng chỉ thấy đúng trạng thái đó; mở thêm Indirect/Result/Feedback thì các lựa chọn tương ứng mới xuất hiện. Cứ đánh dấu theo chiều dọc rồi chiều ngang cho từng ô.

Workflow còn cho thêm điều kiện đặc biệt: một số bước chuyển chỉ mở cho author hoặc user được assign. Ví dụ role thường chỉ được chuyển sang Result, nhưng nếu người đó là author thì được thêm quyền quay về New — luồng vừa chặt vừa linh hoạt.

▸ 4. Cấu hình trường bắt buộc theo trạng thái

Cuối bài, giảng viên đặt quy tắc field required / read-only cho từng tracker theo trạng thái. Ví dụ với Bug: sang Result thì bắt buộc điền đủ nguyên nhân lỗi, QC activity, file, test run; khi Cancel/Pending thì không bắt buộc. Với Q&A chỉ cần chọn phase (UT/IT). Làm lần lượt cho từng role – từng tracker là hoàn tất phần status transition, rồi sắp xếp lại thứ tự status và tracker cho gọn.

Chương 4 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Khi cần tạo hàng chục, hàng trăm issue một lúc, việc gõ tay từng cái là bất khả thi. Bài này chỉ cho bạn cách nạp cả loạt issue vào Redmine từ một file CSV. Điểm mấu chốt: đừng tự bịa cấu trúc file — hãy export sẵn từ Redmine ra để lấy đúng bộ cột làm template, điền dữ liệu rồi import ngược lại.

─── SAU BÀI HỌC, BẠN SẼ

• Lấy được đúng template CSV bằng cách export issue có sẵn từ Redmine.
• Chuẩn bị dữ liệu import trên Google Sheets với các cột cốt lõi và tải về dạng CSV.
• Import file CSV vào dự án và kiểm tra kết quả trước khi ghi vào hệ thống.

─── NỘI DUNG CHÍNH

▸ 1. Lấy template bằng cách export trước

Bí quyết của cả bài nằm ở đây: muốn biết file import cần những cột nào, bạn export ra trước rồi mới import lại. Giảng viên tạo vài ticket mẫu (một task, một bug) để hệ thống có đủ dữ liệu, sau đó dùng chức năng Export → CSV với tùy chọn xuất toàn bộ cột. File nhận về chính là khuôn mẫu chuẩn của Redmine — bạn không phải đoán tên hay thứ tự trường.

▸ 2. Dựng dữ liệu trên Google Sheets

Mở file vừa export, copy phần khung cột sang một sheet mới trên Google Sheets. Xóa dòng dữ liệu mẫu, chỉ giữ lại các cột thật sự cần điền: Tracker, Tag (ID), Parent tag, Status, Subject… rồi nhập dữ liệu thật của bạn vào. Làm trên Sheets giúp tách cột theo dấu phẩy sạch sẽ và ít lỗi định dạng hơn mở trực tiếp bằng Excel. Xong xuôi, Download sheet đó về dạng CSV.

▸ 3. Import CSV vào Redmine

Quay lại màn hình issue của dự án, chọn chức năng Import, trỏ tới file CSV vừa tải. Redmine hỏi ký tự phân tách (dấu phẩy) và định dạng — chọn cho khớp với file. Sau đó ánh xạ các cột của file với trường của Redmine; nếu khớp, bảng preview sẽ hiển thị dữ liệu đầy đủ ngay trong app.

▸ Lưu ý khi map cột

Hãy soát kỹ bảng review trước khi bấm nút import cuối cùng. Đối chiếu Tracker, Status, Subject xem đã vào đúng trường chưa — sai một cột là cả loạt issue lệch theo. Khớp hết rồi mới xác nhận, hệ thống báo import thành công là xong.

Chương 4 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Gantt chart trong Redmine không phải thứ bạn "vẽ" tay — nó tự sinh ra từ dữ liệu bạn nhập vào issue. Bài này chỉ cho bạn mắt xích quan trọng nhất: gom các issue vào target version rồi đặt deadline, và Gantt chart sẽ tự chạy theo dòng thời gian, tự tính phần trăm hoàn thành cho từng nhóm việc.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo và quản lý target version trong Settings → Versions của dự án.
• Gán issue vào đúng target version bằng cách chỉnh trường Target version.
• Đọc được Gantt chart: mốc thời gian, phần trăm tiến độ và cảnh báo trễ hạn.

─── NỘI DUNG CHÍNH

▸ 1. Target version là "xương sống" của Gantt

Sau khi đăng nhập vào dự án, vào Settings → Versions. Đây là nơi bạn khai báo các mốc/gói công việc như Setup, Coding, Unit test, Test case… Mỗi version giống một cột mốc để nhóm các issue liên quan lại với nhau. Muốn Gantt chart có gì để vẽ, trước tiên phải có bộ target version này.

▸ 2. Gán issue vào target version

Lọc ra nhóm issue cần gom (ví dụ tìm theo Subject hoặc nội dung), chọn hết rồi chuột phải → Target version, gán vào version tương ứng. Khi đã gán, chuyển sang tab Gantt, bạn sẽ thấy các thanh tiến độ trải dài theo thời gian. Zoom out để nhìn toàn cảnh cả dự án.

▸ 3. Đặt deadline và cập nhật tiến độ

Với mỗi issue, bạn đặt due date (ví dụ 8/11) rồi Save. Khi cập nhật kết quả và chỉnh status lên 100%, Redmine tự tính lại: estimate bao nhiêu, spend bao nhiêu, hoàn thành mấy phần trăm. Con số phần trăm này hiện ngay trên thanh Gantt của version đó — bạn không phải cộng tay.

▸ Lưu ý khi đọc Gantt

Điểm đắt giá của Gantt trong Redmine là cảnh báo trễ tự động. Khi tổng hợp theo target version, hệ thống tự đo mục nào đúng hạn, mục nào quá deadline và tô màu đỏ những phần bị trễ. Nhờ vậy, chỉ liếc vào biểu đồ là biết ngay dự án đang đúng tiến độ hay đã chậm ở đâu, thay vì phải dò từng issue.

Chương 4 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mỗi lần tạo issue mà phải gõ lại bố cục nội dung từ đầu vừa mất thời gian vừa dễ thiếu thông tin. Bài này hướng dẫn tạo sẵn issue template cho từng loại tracker — Bug, Task, Q&A, Report — để khi tạo ticket mới, khung nội dung tự bung ra đầy đủ. Điểm mấu chốt: mỗi template gắn với một tracker và bắt buộc phải được enable thì mới dùng được.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo issue template riêng cho từng tracker trong màn hình Global issue template.
• Thiết kế bố cục nội dung chuẩn cho Bug, Q&A, Report (daily/weekly).
• Enable và áp template đúng cách để nó tự hiện khi tạo issue mới.

─── NỘI DUNG CHÍNH

▸ 1. Tạo template theo từng tracker

Vào phần Global issue template (thuộc plugin issue template trong Administration). Bấm Add new template, chọn Tracker áp dụng, đặt tên và dán bố cục nội dung vào. Cứ mỗi loại việc bạn tạo một template riêng: một cho Q&A, một cho Task, một cho Bug, một cho Report. Giảng viên làm lần lượt từng cái để bạn thấy chúng độc lập với nhau.

▸ 2. Nội dung nên có trong từng loại

Mỗi loại tracker có khung khác nhau, ví dụ:

• Bug: các bước tái hiện (step), kết quả hiện tại, kết quả mong muốn — để dev đọc là biết lỗi ở đâu, đáng lẽ ra sao.
• Q&A: phần đặt câu hỏi (question) rõ ràng.
• Report: tách daily report và weekly report, có sẵn tag ngày hôm nay, danh sách issue đã làm.

Nhờ khung dựng sẵn, người điền chỉ việc điền vào chỗ trống, không bỏ sót mục nào.

▸ 3. Mẹo quan trọng: phải Enable thì template mới hiện

Đây là chỗ dễ vấp nhất. Tạo template xong, bạn bắt buộc tick Enable và chọn phạm vi áp dụng (apply). Nếu quên bật enable, template sẽ không xuất hiện khi bạn tạo issue — nhìn như chưa tạo gì cả. Giảng viên nhắc lại điều này tới hai lần, nên hãy ghi nhớ.

▸ 4. Kiểm chứng bằng cách tạo issue mới

Sau khi enable, bấm New issue rồi đổi Tracker. Chọn Bug thì khung bug bung ra, chọn Report → Daily report thì khung báo cáo hiện đủ. Bấm Create và bạn có ngay một ticket theo khuôn đẹp, thống nhất — tiện hơn hẳn so với gõ tay mỗi lần.

Chương 4 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Một dự án phần mềm có thể có tới hàng nghìn issue — nhìn bằng mắt thường thì chịu. Bài này chỉ cho bạn dùng query (truy vấn) để lọc và lưu sẵn các góc nhìn quản lý thường dùng: việc phải xong hôm nay, việc đã trễ, việc bị delay, và các câu hỏi cần khách hàng trả lời. Lưu một lần, mỗi ngày chỉ cần bấm vào là ra danh sách cần theo dõi.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo và Save query với bộ filter theo due date, start date, status, author.
• Dựng được 5 query nền tảng để tracking tiến độ và chăm sóc khách hàng.
• Tinh chỉnh cột hiển thị, group by và sort để đọc kết quả nhanh hơn.

─── NỘI DUNG CHÍNH

▸ 1. Năm query nền tảng nên có sẵn

Giảng viên dựng lần lượt 5 truy vấn, mỗi cái giải một nhu cầu quản lý:

1. Việc phải xong hôm nay — filter `Due date = today`, lọc các issue còn open.
2. Task trễ (overdue) — `Due date` quá hạn từ một ngày trở lên, kết hợp `Status is not` Resolve/Close/Reject/Cancel để chỉ còn việc thật sự chưa xong.
3. Task delay — đã tới `Start date` mà status vẫn là New, tức đáng lẽ phải bắt đầu nhưng chưa khởi động. Delay khác với trễ (overdue).
4. Q&A gửi khách hàng — issue tracker Q&A đang open, gán cho role Customer, để nhờ khách trả lời.
5. Issue do khách hàng tạo — filter theo `Author = khách hàng` để ưu tiên phản hồi feedback của họ.

Mỗi query lưu lại kèm tên và phạm vi, hôm sau chỉ việc click là có ngay danh sách.

▸ 2. Mẹo quan trọng: cẩn thận khi chia sẻ query cho khách hàng

Query rất mạnh, nhưng đừng để khách hàng nhìn thấy những gì không nên thấy. Nếu bạn share một query để khách theo dõi tiến độ, hãy bỏ role Customer khỏi bộ lọc ở những query nội bộ và thu hẹp phạm vi lại. Với query dành riêng cho khách (như Q&A cần trả lời), bạn có thể copy đường link gửi thẳng và nhờ họ vào trả lời hết.

▸ 3. Group by, sort và cột hiển thị

Query còn cho phép Group by (ví dụ nhóm theo người phụ trách để thấy ai đang gánh bao nhiêu việc) và bật cột spent time để biết trễ mấy ngày, mấy giờ. Trong phần Settings của query, chỉnh default column cho phù hợp từng dự án — những cột đáng giữ gồm checker, status, priority, subject, due date, target version, estimate time, screen/function id. Phím tắt s giúp mở nhanh bộ lọc.

Chương 4 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đọc một bảng dài toàn chữ thì lâu, nhưng nhìn một biểu đồ là nhận xét được ngay. Bài này hướng dẫn dựng chart trên Redmine (qua plugin) để biến danh sách issue thành hình ảnh trực quan: ai đang gánh nhiều việc nhất, dự án hoàn thành bao nhiêu phần trăm, còn bao nhiêu task theo từng nhóm. Điểm mấu chốt là chọn đúng cách group by để chart trả lời đúng câu hỏi bạn quan tâm.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo chart từ issue với tùy chọn loại (column chart, pie chart).
• Group by theo người phụ trách, theo status hoặc theo screen ID để xem các góc khác nhau.
• Đọc nhanh khối lượng công việc và tiến độ tổng thể của dự án qua biểu đồ.

─── NỘI DUNG CHÍNH

▸ 1. Chart theo người — nhìn khối lượng công việc

Câu hỏi hay gặp nhất là "ai đang ôm nhiều việc". Bạn tạo một column chart, đặt khoảng thời gian (ví dụ 1–2 năm đổ lại tới hiện tại), lọc task đang Open rồi Group by theo người phụ trách (assignee). Kết quả: mỗi người một cột, ai cao nhất là đang gánh nhiều task nhất — thấy ngay không cần đếm. Tương tự, bạn có thể tạo chart theo tracker Bug để xem lượng bug rơi vào ai.

▸ 2. Chart theo status — đo tiến độ tổng thể

Muốn biết dự án hoàn thành tới đâu, dùng pie chart với tổng số task, group by theo status. Biểu đồ tách ngay tỷ lệ: bao nhiêu phần trăm còn New, bao nhiêu phần trăm đã Close. Nhìn vào là biết dự án còn nhiều việc dở dang hay sắp về đích, thay vì mở bảng cộng tay.

▸ 3. Chọn loại chart và tiêu chí group by phù hợp

Cùng một bộ dữ liệu, đổi tiêu chí group by là ra góc nhìn khác. Ngoài người và status, bạn còn có thể group by theo screen ID / function ID để thấy từng màn hình còn bao nhiêu task tồn. Mỗi chart nên đặt tên rõ (C01, C02, C03…) và bật Public nếu muốn cả nhóm cùng xem.

▸ Lưu ý khi dùng chart để họp

Chart mạnh nhất khi dùng cho thống kê nhanh hằng ngày: liếc một cái là nắm được ai quá tải, dự án chậm ở đâu, nhóm màn hình nào còn nhiều việc. Hãy tạo sẵn vài chart cố định theo các tiêu chí bạn quan tâm để lần nào cần cũng có, không phải dựng lại từ đầu.

Chương 5 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu Chương 5 — chương tích hợp Redmine với Excel / Google Spreadsheet để làm báo cáo tự động. Bài đầu tiên này chỉ cho bạn bước nền tảng nhất: trích xuất dữ liệu issue ra file CSV. Điểm mấu chốt cần nhớ ngay: đừng mở thẳng file CSV bằng cách nhấp đúp — hãy dùng chức năng Import trong Excel/Google Sheets để tránh lỗi phông và lệch cột.

─── SAU BÀI HỌC, BẠN SẼ

• Export dữ liệu issue của dự án ra file CSV theo hai cách: full hoặc đã lọc.
• Chọn đúng bộ cột và encoding phù hợp với ngôn ngữ dữ liệu.
• Tránh được lỗi phông chữ khi đưa CSV vào Excel/Spreadsheet.

─── NỘI DUNG CHÍNH

▸ 1. Bức tranh cả Chương 5

Trước khi làm, giảng viên phác lộ trình cả chương: bài 1 export dữ liệu ra CSV; bài 2 import vào Excel/Spreadsheet; bài 3 dựng báo cáo thống kê bug/task/issue trên Excel; bài 4 làm tương tự trên Google Spreadsheet; bài 5 lấy dữ liệu trực tiếp từ Redmine qua API. Đích đến là một trang báo cáo bấm một phát ra số liệu, kèm bonus đo timeline tiến độ dự án.

▸ 2. Hai cách export

Vào dự án, mở tab Issues. Chức năng export nằm cuối danh sách, bạn chọn định dạng CSV. Có hai hướng:

• Export full — xuất toàn bộ issue của dự án.
• Filter rồi export — lọc trước theo query rồi mới xuất, chỉ lấy phần cần.

Về cột, có Select column (chỉ những cột đang hiển thị trên màn hình) hoặc All column (lấy hết, kể cả description và last note). Chọn tùy nhu cầu báo cáo.

▸ 3. Mẹo quan trọng: chọn encoding và đừng mở trực tiếp

Ở bước export, hãy chọn encoding UTF-8 nếu dữ liệu có tiếng Nhật, tiếng Hàn hay ký tự đặc biệt — chọn sai là chữ hiển thị lỗi hết. Sau khi tải file về, đừng nhấp đúp mở thẳng: mở kiểu đó rất hay bị lỗi phông và dồn cột. Thay vào đó, dùng chức năng Import trong Excel, hoặc tốt hơn là Google Sheets — nhanh và chính xác hơn. Có file CSV sạch trong tay rồi, bài tiếp theo sẽ hướng dẫn import vào bảng tính để dựng báo cáo.

Chương 5 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Ở bài trước bạn đã export dữ liệu issue từ Redmine ra file CSV. Bài này chỉ ra cách import file CSV đó vào đúng cách — vào Excel và vào Google Spreadsheets. Điểm mấu chốt: đừng bao giờ click đúp mở thẳng file CSV, vì nó sẽ bị lỗi font (dấu tiếng Việt vỡ hết). Phải đi qua chức năng import chuẩn thì dữ liệu mới sạch để làm báo cáo.

─── SAU BÀI HỌC, BẠN SẼ

• Import file CSV vào Excel qua Data → From Text/CSV, chọn đúng mã hóa và dấu phân cách.
• Import cùng file đó vào Google Spreadsheets qua File → Import → Upload.
• Đưa dữ liệu về dạng bảng để sẵn sàng pivot và thống kê ở các bài sau.

─── NỘI DUNG CHÍNH

▸ 1. Lưu ý quan trọng: đừng click đúp mở file CSV

Nếu bạn mở CSV bằng cách click đúp, Excel đọc sai mã hóa và dữ liệu bị lỗi font rất nhiều. Luôn mở chương trình lên trước, rồi import từ trong — đó là cách duy nhất giữ được tiếng Việt và định dạng đúng.

▸ 2. Import vào Excel

Mở Excel lên, vào tab Data → From Text/CSV, trỏ tới folder chứa file CSV vừa export. Excel sẽ hiện cửa sổ xem trước và tự nhận diện mã hóa Unicode UTF-8, dấu phân cách là dấu phẩy (comma). Kiểm tra một lượt xem các cột đã tách đúng chưa, thấy ổn thì bấm Load để đổ dữ liệu vào dưới dạng bảng.

Có bảng rồi, bạn có thể pivot ngay để thống kê — ví dụ đếm số lượng theo tracker (nhớ chọn Count chứ không phải Sum), rồi Insert biểu đồ tùy ý.

▸ 3. Import vào Google Spreadsheets

Với Spreadsheets thì tạo một tài liệu mới, vào File → Import, qua tab Upload và tải file CSV lên. Google sẽ hỏi chèn vào đâu — chọn Insert vào current sheet (sheet hiện tại), chọn dấu phân cách là dấu phẩy, rồi import. Dữ liệu đổ vào xong là bạn cũng có thể pivot và thống kê y như bên Excel.

Cả hai công cụ đều miễn phí, và cách import chuẩn này là nền tảng cho toàn bộ phần báo cáo ở các bài kế tiếp.

Chương 5 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Có bảng dữ liệu issue trong Excel rồi (từ bài import CSV), bài này dạy bạn dùng PivotTable để thống kê task/bug/issues theo nhiều góc độ: theo tracker, theo trạng thái, theo người phụ trách. Điểm mấu chốt: một khi dữ liệu đã ở dạng bảng, bạn chỉ kéo-thả vài trường là ra được báo cáo — và mỗi lần dữ liệu đổi, chỉ cần Refresh là pivot cập nhật theo.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo PivotTable đếm số lượng issue theo tracker (task/bug/Q&A).
• Thống kê theo phần trăm và theo trạng thái (status), lọc đúng cái mình cần.
• Refresh pivot khi dữ liệu nguồn thay đổi, và vẽ biểu đồ minh họa.

─── NỘI DUNG CHÍNH

▸ 1. Pivot đầu tiên: đếm theo tracker

Chọn bảng, bấm Insert → PivotTable, đưa ra một sheet mới. Kéo Tracker vào phần Rows, rồi kéo Tracker vào phần Values — nhớ đổi phép tính thành Count. Kết quả: tổng cộng 92 task. Đây là con số nền để so sánh.

▸ 2. Sửa dữ liệu và Refresh

Giảng viên sửa vài dòng thành bug và Q&A cho dữ liệu đa dạng, dễ nhìn hơn. Sau khi sửa nguồn, qua tab Data → Refresh để pivot tự cập nhật. Giờ bảng có đủ Task, Bug và Q&A.

▸ 3. Thống kê theo phần trăm và theo status

Tạo thêm pivot, đặt phép tính hiển thị dưới dạng % của tổng để xem tỷ lệ — ví dụ Q&A chiếm 25%, Task chiếm 61%. Copy pivot xuống (Ctrl+C, Ctrl+V) để tái sử dụng, rồi thêm trường Status để chỉ thống kê những issue đang Open (hoặc New, Resolved…). Cùng một tracker, tách theo status bạn thấy ngay cái nào mới, cái nào đã xử lý.

▸ 4. Thống kê theo người và mẹo Recommended Charts

Bỏ tracker/status ra, kéo trường người phụ trách (assignee) vào để đếm số ticket mỗi người — ví dụ một người có 43 ticket. Bạn có thể search/filter để soi từng người. Một mẹo đáng nhớ: khi đã có pivot, bấm Insert → Recommended Charts, Excel gợi ý sẵn nhiều dạng biểu đồ phù hợp — chọn cái nào hợp để trực quan hóa báo cáo mà không phải tự dựng chart từ đầu.

Chương 5 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước bạn pivot trên Excel; bài này làm lại đúng thao tác đó trên Google Spreadsheets. Dữ liệu issue đã import từ clip trước, giờ bạn dùng Pivot table của Spreadsheets để thống kê task/bug/issues theo tracker, theo người, theo status. Điểm mấu chốt: Spreadsheets miễn phí, chạy trên trình duyệt, và cách kéo-thả gần như y hệt Excel.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo Pivot table trong Google Spreadsheets từ bảng dữ liệu issue.
• Thống kê theo tracker, theo người phụ trách và theo status.
• Bỏ hàng Grand Total, thêm filter, và thống kê cả estimate (giờ ước lượng).

─── NỘI DUNG CHÍNH

▸ 1. Tạo pivot table đầu tiên

Bấm Ctrl + A để chọn hết dữ liệu, rồi Insert → Pivot table, chọn tạo mới. Kéo Tracker vào Rows, kéo Tracker vào Values với phép tính COUNTA — ra 92 task. Giống hệt bài Excel, chỉ khác giao diện.

▸ 2. Sửa dữ liệu, thêm biểu đồ

Sửa vài dòng thành bug và Q&A để dữ liệu phong phú; pivot của Spreadsheets tự chạy theo. Chọn pivot rồi Insert → Chart để có biểu đồ count theo tracker.

▸ 3. Thống kê theo người và theo status

Copy pivot xuống, xóa trường cũ, kéo người phụ trách (senior/nhân viên) vào, thêm cột Status để xem mỗi người có bao nhiêu New, bao nhiêu Resolved, tổng bao nhiêu. Insert thêm chart để nhìn cho rõ.

▸ 4. Lưu ý: bỏ Grand Total, thêm filter, thống kê estimate

Vài mẹo tinh chỉnh đáng nhớ:

• Hàng Total (Grand Total) lấy gộp tất cả — nếu không cần, bấm Remove để bỏ, chỉ giữ đúng các dòng account bạn muốn.
• Thêm Filter để lọc bớt, ví dụ chỉ xem status là New — bỏ các status khác ra thì bảng gọn hơn.
• Khi tổng các thành phần là 100%, nên chọn biểu đồ dạng tròn/100% để thấy tỷ lệ (ví dụ Resolved 1%, còn lại là New).
• Muốn thống kê estimate (giờ ước lượng) thì kéo trường estimate vào Values là xong.

Chương 5 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Thay vì export CSV rồi import thủ công như các bài trước, bài này giới thiệu một công cụ web có sẵn giúp lấy dữ liệu trực tiếp từ Redmine đổ thẳng vào Google Spreadsheets — kèm sẵn thống kê tiến độ và lời khuyên xử lý. Điểm mấu chốt: chỉ cần nhập URL Redmine, tài khoản và API key là công cụ tự sinh ra một file báo cáo tiến độ đầy đủ.

─── SAU BÀI HỌC, BẠN SẼ

• Dùng công cụ trên trang sva.smartitsoft.com → Tools → Progress để kéo dữ liệu Redmine về Spreadsheets.
• Lấy được API key trong Redmine và trỏ báo cáo về đúng một file cố định để chạy lại nhiều lần.
• Hiểu vì sao tiến độ chỉ tính task chứ không tính phần "01 setup".

─── NỘI DUNG CHÍNH

▸ 1. Nhập thông tin kết nối

Vào trang công cụ, chọn Tools → Progress. Điền Redmine URL, username, và API key. Ô Spreadsheet ID là optional: để trống thì công cụ tạo file mới; điền vào thì đổ dữ liệu vào file đó.

Lấy API key: vào My account → Show (hiện API access key) rồi copy dán vào. Bấm Submit và đợi một chút.

▸ 2. Kết quả: báo cáo tiến độ tự động

Công cụ sinh ra một Spreadsheet thống kê đầy đủ: tổng số task, phần trăm dự án đã chạy, ai làm nhanh ai làm trễ, ai sắp hết việc ai còn nhiều việc, danh sách các task đã bị trễ kèm lời khuyên xử lý (task quá ngày start mà chưa làm, quá ngày trả…). Mỗi phần đều có chart riêng.

▸ 3. Trỏ về đúng một file để chạy lại

Nếu bạn đã dựng thêm sheet báo cáo trên file này và muốn lần sau chạy lại vẫn đổ vào đúng file cũ: copy ID của document từ URL Spreadsheet, dán vào ô Spreadsheet trong công cụ rồi Submit. Lần chạy sau dữ liệu sẽ đổ trúng file này chứ không tạo file khác.

▸ 4. Lưu ý: tiến độ chỉ tính task, không tính "01 setup"

Phần call tiến độ chỉ tính task, bỏ qua các file dạng "01 setup". Muốn loại một nhóm khỏi tính tiến độ, bạn tạo một custom view đặt tên "01 setup", add vào rồi save — khi chạy tiến độ, phần đó sẽ không bị tính. Hoàn thành khóa học, giảng viên sẽ tặng bạn file mẫu tiến độ đã dựng sẵn nhiều công thức tính, có giải thích để bạn tự chỉnh cho dự án của mình.