Tài liệu quy trình phát triển dự án bao gồm các team Design, QC, Dev.

1. Product Working Process
Build & Update
Build process:
1. Nội dungbuild:
a. Nội dungmới.
b. Nội dungđối tác request.
c. Bug listtồnđộng của buildtrước.
2. Timeline build:
a. Team productsẽ tiếpnhậnBug & Requesttínhnăng/nội dungmới từđối tác và chốt các
nội dungchính của tính năngsắp xếpvới kế hoạch update buildcủanội bộ đang có để
chốt nội dung.
b. Tiếnhànhhọp teamnội dung build.
c. Chốt timeline release:
i. Dev
ii. Test
iii. Production
3. Test:
a. Dev:Release builddev(testnội bộ).
b. QC: Reportlỗi phátsinh.
c. Dev:Tiếnhành fix lỗi.
d. QC: recheckbugvà tính năng.
e. Dev:release bảnbuildfinal (môitrườngtest)
f. QC & Khách hàng tiếnhànhtest.
i. Trường hợpcác BUG nhỏ có thể pass được: bảo lưucho buildtiếptheo.
ii. Trường hợpvẫncòn BUG critical:quay lại bước(c).
g. Trường hợpbước(f) đã thoả các điềukiệnrelease:teamupdate lênproductionvàđóng
Build.

2. Quản lý Redmine
Tầng 1 – Build version
1. Đặt tên buildlớn:[versionnumber.mini version.miniupdate] –[nội dungupdate]
a. Versionnumber:sốversionchínhthứccủa một build lớn.Sốnàysẽ được nâng khi có
cập nhật lớnliênquanđếntrải nghiệmngười dùnghoặcthayđổi về luồngdữ liệu.
b. Mini version:sốnày sẽ nâng khi có update liênquanđếntính năngcủa buildlớn.
c. Mini update:số nàysẽ nâng (+1) khi có các update nhỏliênquanđếnviệcfix bughoặc
điềuchỉnh tính năng đã có sẵn.
2. VD:
a. 1.0.0 – Phiênbảnmới.
b. 1.1.0 – Phiênbảncó update thêmtínhnăng của phiênbản.
c. 1.1.1 – Phiênbảncó update sửalỗi và điềuchỉnh tính năng hiệncó.
Tầng 2 – Nội dung tracking
1. Nội dungbuild (document):
a. Mô tả.
b. UI/UX.
2. Bug list:
a. Bug tồn độngcủa phiênbảntrước.
b. Bug mới của buildhiệntại có phásinh.
3. Devcontent:
a. API
b. Code

4. 4. Quản lýIssue:
a. Product:tiếpnhậnrequestcontentvàcác tính năng mới,tổnghợpvà update tài liệu
assigncho Dev(addwatchingcho QC).
i. Cungcấp UI/UX.
ii. Cungcấp tài liệumôtả.
iii. Sau khi phiênbảnđã hoàn tất (đã release production):đóngbuild
b. QC:
i. Dựng testcase.
ii. Testtính năng
iii. Reportbug (cũ& mới) – assignchodevnếucó phátsinhtừ buildnội bộvà từ
khách hàng.
iv. Sau khi Devfix bug – resolve issue.
c. Dev:
i. Tiếpnhậnnội dung từ Producttự add các issue liênquanđếnphiênbản.
ii. Fix lỗi tiếpnhậntừ QC – assigncho QC.
iii. QC confirmlỗi đã fix – resolve issue.
d. Phânloại ưu tiênxửlýissue:
i. Xử lýcác case tiếpnhận từ môi trườngkhách hàngđang sử dụng.
 Với buggây cản trở trải nghiệmhoặcảnh hưởngdữ liệucủangười
dùng:xử lýngay.
 Với các bug liênquanUI, text,vàkhôngcó quá nhiềuảnhhưởngtrực
tiếptrải nghiệmcó thể move vàocác phiênbảnupdate sau.
ii. Xử lýcác case liênquanđếnversiontrongtimelineupdate:
 Với buggây cản trở trải nghiệmhoặcảnh hưởngdữ liệucủangười
dùng:xử lýngay.
 Với các bug liênquanUI, text,vàkhôngcó quá nhiềuảnhhưởngtrực
tiếptrải nghiệmcó thể move vàocác phiênbảnupdate saunếuảnh
hưởngđếntimeline.
iii. Nội dungbáo bug:
 Title:[Critical] tênlỗi
 Nội dunglỗi:mô tả cụ thể các bước thao tác phát sinhlỗi.Yêucầu cần
có Hình ảnh/Video.
iv. Các bước tiếpnhậnlỗi và phảnhồi:
 QC sẽ là người tiếpnhậnlỗi trực tiếptừ kháchhàng.
 QC reportbằng issue Redmine,assignchodev.
 Devcheck và phảnhồi thời gianhoàn thành.
 Productphản hồi khách hangvề timeline hoànthànhupdate.
v. Các bước tiếpnhậnnội dung vàphản hồi:
 Producttiếpnhậncác yêucầu chỉnh sửa/bổsung từ khách hàng.
 Sau khi chốt nội dungvà tính khả thi của tính năngProduct sẽ cập nhật
nội dungvào lộ trình phiênbảnphùhợp.
 Sau khi chốt được lộtrình cập nhậtyêucầu, Productsẽ chốt timeline
với kháchhàng.