Những quy định nên được đặt ra để sử dụng redmine một cách hiệu quả

Bài sau dịch từ một bài viết trên qiita 決めておいた方が良いRedmine運用ルール

Những quy định nên được đặt ra để sử dụng redmine một cách hiệu quả. Đây là bài viết tổng hợp các kinh nghiệm được rút ra trong quá trình sử dụng redmine để phát triển hệ thống, website hay DTP(DeskTop Publishing) từ trước tới nay.

Vì có thể sẽ có những chỗ không đúng, nên nếu có thể rất mong bạn đọc comment để chỉ ra những chỗ đó.

Phương châm cơ bản

• Nâng cao độ tập trung thông tin
• Đây không phải việc định nghĩa ra các thiết lập cứng nhắc mà là việc ứng dụng các thiệt lập đơn giản một cách linh hoạt

Nhất định phải thay đổi theme

Trong trường hợp với mỗi một công việc bạn lại phải tạo ra những môi trường redmine khác nhau, vì sẽ xuất hiện những tiêu chuẩn nên việc mình đang login vào redmine nào rất khó xác định nếu chỉ nhìn bằng mắt thường và sẽ có những sai lầm nguy hiểm về nơi post thông tin.

Để có thể nhận biết được mình đang access vào môi trường nào một cách trực quan thì bạn nên thiết lập theme với mỗi môi trường khác nhau.

Và tôi đã tổng hợp những gợi ý về theme cho redmine ở bài viết Tôi đã đưa các plugin tiện lợi sau vào redmine để có được theme đẹp, các bạn có thể vào để tham khảo.

Không sử dụng những module mà tính năng không rõ ràng

Document, forum, file là những tính năng có thể trở thành nguyên nhân gây rò rỉ thông tin vì chúng được phân chia cách sử dụng với chức năng ticket và wiki. Những module khác mặc dù có thể thay thế nhưng nếu không có nhiều lý do thì nên OFF là tốt nhất.

• Khi upload Attach file lên wiki, ticket hay new, cũng không sử dụng module [File]

  • Tính năng tìm kiếm của module file cũng có hiệu quả rất thấp nếu so sánh với ticket và wiki, file càng tăng lên thì càng khó phân chia và càng lộn xộn
  • Số lượng file của một project được phân tầng hóa là rất lớn, vì vậy rất khó để tìm kiếm

• Có thể mô tả trực tiếp document trong wiki, vì vậy không sử dụng chức năng document

  • Document là chức năng có mục đích để upload những file đính kèm, là những giải thích đơn giản để access hoặc những từ ngữ trong tài liệu
  • Những thông tin về text có thể nhập trực tiếp vào wiki, vì vậy chỉ attach file khi thực sự cần thiết

• Có thể sẽ lãng phí dung lượng không cần thiết, do vậy nên để file trên 1 file sever và chỉ note link file path lên ticket hoặc wiki là được

• Không tranh luận bên trong ticket rồi biến nó thành một “forum” (thực hiện tranh luận/trao đổi tại nơi khác)

Trong trường hợp project được phân nhỏ thành nhiều lớp, phải tập hợp những thông tin chung vào wiki của các project cha

Quá trình phát triển Project thường được chia thành các phase khác nhau, cũng như tạp chí được chia thành những số khác nhau theo định kỳ. Vì vậy, những thông tin hữu ích thường được dồn vào wiki của các dự án con (Phase con).

Tuy nhiên, kiểu gì cũng sẽ có project con chứa các thông tin không được cập nhật mới nhất, do vậy nên tập trung ở project cha để quản lý thông tin dễ dàng hơn. Hơn nữa, cũng có thể tập hợp tất cả thông tin chỉ ở project cha cũng được.

Sử dụng category để hạn chế việc gia tăng tracker

Nếu vẫn có một ticket sử dụng tracker ở đâu đó thì ta không thể xóa tracker này.

Với dự án, khi các tracker và workflow tăng lên, thì việc đặt tên cũng trở nên khó khăn. Mặc dù đã điều chỉnh nhưng vì những cái không thể xóa nên chúng trở nên rất mập mờ.

Vả lại, vì người sử dụng redmine không có hứng thú với trạng thái của ticket như các nhà quản lý, nên việc tạo ra quá nhiều tracker và workflow quá chi tiết trở nên lãng phí.

Tracker chỉ nên được tập trung thành 5 loại khác nhau, và tôi khuyên bạn nên sử dụng category để phân nhỏ hoặc phân loại chi tiết hơn từ 5 tracker đó.

Ví dụ, cùng là 1 task tracker tuy nhiên vì bạn có thể phân chia ra thành 2 category là [Development] và [Design] nên việc group và filer rất tiện lợi. Với mỗi project bạn có thể định nghĩa category một cách tự do nên việc đặt tên và quản lý sẽ trở nên dễ dàng hơn rất nhiều.

Nên tránh tạo các ticket con, thay vào đó hãy tạo ra các ticket và version liên quan

Việc quản lý ticket con có độ khó cao nên tôi khuyên bạn không nên sử dụng.

Ví dụ nhé. Bạn có 1 ticket ban đầu là task, tuy nhiên bạn chia nhỏ nó và ticket mới cũng được assign chồng chéo với ticket cha, vậy đâu là trạng thái của nó?

Dù người chịu trách nhiệm ticket cha và ticket con cùng là 1 người hay những người khác nhau thì việc hiểu được ai là người chịu trách nhiệm cho task cũng rất khó (Theo quan điểm cả nhân, tôi nghĩ trong tình huống này thì người được assign trong ticket cha không có ý nghĩa gì cả )

Vả lại, ngày kết thúc của ticket cha được tự động cập nhật theo ngày kết thúc của ticket con có deadline gần nhất và độ ưu tiên cao nhất, do vậy công việc quản lý có thể không như những gì chúng ta mong đợi. Kể cả khi ticket con đã được closed thì vẫn còn tồn đọng những ticket khác nên sẽ rất sốt ruột.

Từ ticket đã có sẵn, ta tách thành các ticket khác nhau, vì hầu hết chỉ cần 10 case là có thể phản ánh một cách đơn thuần rồi nên sử dụng linh hoạt những ticket liên quan thì sẽ tốt hơn sử dụng ticket con.

Thảm khảo tài liệu Tạo mối quan hệ giữa các ticket.

Ngoài ra, tôi cũng khuyên bạn nên sử dụng chức năng version và road map để quản lý toàn bộ tiến trình thực hiện nhiều ticket.

Tham khảo tài liệu Giải thích các từ khóa của Redmine Road Map

Thông tin thêm

ngày kết thúc của ticket cha được tự động cập nhật theo ngày kết thúc của ticket con có deadline gần nhất và độ ưu tiên cao nhất

Mặc dù có nêu ra ở trên, tuy nhiên từ Redmine 3.1 vấn đề có thể được giải quyết thông qua thiết lập project

Feature #5490: Thêm option không liên kết độ ưu tiên, ngày bắt đầu, deadline, % tiến độ của ticket cha với ticket con. (Quản lý -> Thiết lập-> Ticket Tracking [Cách tính các giá trị của ticket cha] )

Tham khảo Redmine 3.1 CHANGELOG (Chỉ thêm chức năng-Có dịch tiếng Nhật)