2017/01/05

TiDD: No Ticket, No Commit

TiDD là gì?
Ticket-Driven Development (Phát triển hướng ticket).

Ai phát triển TiDD
Một bác Nhật xây dựng và đặt tên cách quản lý dựa trên ticket, lấy ticket làm trung tâm là TiDD. 

Khởi nguồn của TiDD
Tác giả của TiDD dùng Redmine, là task management tool để phát triển dự án phần mềm. 

"No Ticket, No Commit"
  1. Đây là nguyên tắc cơ bản của TiDD.
  2. Phải có ticket trước thì mới commit.
  3. Một commit phải tương ứng với một ticket nào đó.
  4. Ticket này là yêu cầu công việc, là lý do mà một developers commit mã nguồn của anh ta.

Vì sao cần "No Ticket, No Commit"
  1. Để biết vì sao, ta làm cái gì.
  2. Để biết DoD (Definition of Done) ra sao 
  3. Để mọi người hiểu được công việc rõ ràng hơn (không chỉ developers)

Có ticket nào không tương ứng với commit?
  1. Có, những task không liên quan đến mã nguồn như hỗ trợ khách hàng, tìm hiểu.
  2. Không. Nếu hiểu "commit" rộng hơn nghĩa "commit mã nguồn" và đối tượng của việc commit là "thay đổi một cái gì đó của hệ thống". 
  3. Hiểu rộng hơn, "cái gì đó" ở đây là "configuration" (như trong CM: Configuration Management". 

"Cấu hình" là gì?
  1. Cấu hình (Configuration) bao gồm mã nguồn, tài liệu, cấu hình hệ thống, máy chủ, server...
  2. Việc chỉnh sửa cấu hình là việc của những người liên quan đến dự án.
  3. Việc chỉnh sửa mã nguồn (một loại cấu hình) là việc chính của developers.
  4. Việc chỉnh sửa các cấu hình khác thuộc về thành viên dự án, ví dụ: Chỉnh sửa file ảnh, chỉnh sửa tài liệu hướng dẫn sử dụng, sử dụng tài liệu thiết kế hệ thống.

Quản lý cấu hình thế nào?
  1. Một cách lý tưởng, mọi thứ (cấu hình) được quản lý trong một hệ thống có hỗ trợ version (Version Control System: VCS).
  2. SCCS (Source code Control System) là công cụ quản lý mã nguồn. 

Một số biểu hiện (người/cách làm) không tuân theo TiDD
  1. Developers tự nhiên commit, không rõ lý do,
  2. Comment trong git trống không,
  3. Developers hotfix mà không hiểu vì sao ,
  4. Thay đổi của hệ thống không được theo dõi (tracking),
  5. Thông tin về quản lý hệ thống/phần mềm không thông suốt,
  6. Release Note không đủ, rõ ràng, phải làm bằng tay.

Quan điểm về TiDD
  1. Việc quản lý dự án lấy ticket làm trung tâm.
  2. Việc phân chia công việc và quản lý tiến độ dựa trên ticket.
  3. Không có ticket thì cấm commit.

Quy định trong TiDD
  1. *No Ticket, No Commit 

Một số loại tickets
  1. Bugs
  2. Yêu cầu thay đổi
  3. Phát triển chức năng mới
  4. Phân tích tính khả thi của công nghệ mới
  5. Tạo tài liệu thiết kế 
  6. Hãy release vào ngày 2017/01/01 với 30 yêu cầu có ticket ID như sau 

TiDD đem lại điều tốt lành gì?
  1. Ai, bao giờ, làm gì: đều track được từ ticket. Qua đó communication thông suốt hơn,
  2. Việc quản lý thay đổi của nội dung/yêu cầu công việc dễ dàng hơn (chỉ cần thay đổi ticket tương ứng),
  3. Release dễ hơn,
  4. Test dễ hơn (dựa trên ticket),
  5. Workflow của dự án tuân theo workflow của ticket, dễ nhìn hơn.

Cần gì để thực hiện TiDD 

  1. (Bắt buộc) Source code management system như git, subversion,
  2. (Bắt buộc) Ticket managment system như redmine, backlog, Jira...
  3. Wiki hay một hệ thống quản lý văn bản hỗ trợ versioning,
  4. Hệ thống versioning khác để quản lý CM (tài liệu...)


--
Best Regards,
Nguyen Hung Vu [aka: NVH] (in Vietnamese: Nguyễn Vũ Hưng, グェン　ヒュン　ウー, 阮武興)
vuhung16plus{remove}@gmail.dot.com , YIM: vuhung16 , Skype: vuhung16plus, twitter: vuhung, MSN: vuhung16.
vuhung's facebook  Nguyễn Vũ Hưng's blog on Free and Open Source, Blog tiếng Nhật, Vietnamese LibreOffice, Mozilla & Firefox tiếng Việt

Disclaimer: When posted to social networking groups include, but not limited to Linux Users' Groups, Free and Open Sources forums, mailing lists, the above is my personal opinion and is *not* the opinion of my employer(s), associations and/or groups I join.
投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)