2.

Các bước triển khai dự án

Sơ đồ triển khai dự án

System-Engineering-Circle

System-Engineering-Circle

Sơ đồ lưu trữ thông tin trong quá trình triển khai dự án

Documentation workflow

Bước 1: Thu thập yêu cầu

a) Đối tượng cần thu thập

PO (Product Owner)
Khách hàng (Client)

b) Nội dung thu thập

Đây là vấn đề/sản phẩm gì? (cần mô tả được vấn đề)
Ai là người sử dụng sản phẩm?
Sản phẩm được sử dụng trong trường hợp nào?
Mối quan hệ giữa các đối tượng sử dụng sản phẩm
Mối quan hệ của sản phẩm này đối với các sản phẩm khác ra sao?
Thời gian hoàn thành như thế nào?
Thu thập các tài liệu liên quan đến các yêu cầu dự án.

c) Phương án/cách thức triển khai

Tổ chức cuộc họp với PO/Client để lấy yêu cầu
Trao đổi về những chức năng chính của dự án

d) Review toàn bộ các bước trên

Sau khi thu thập yêu cầu, QM thực hiện tổng hợp lại toàn bộ những yêu cầu đó.
Mục đích:
Hệ thống lại yêu cầu
Hiểu rõ và ghi nhớ yêu cầu

Bước 2: Đóng gói problem

a) Nội dung chi tiết

Sau khi làm rõ yêu cầu và tìm hiểu tài liệu, QM sẽ thực hiện những việc sau:

Liệt kê những vấn đề/use case cần giải quyết.

Mối quan hệ/logic giữa các đối tượng của problem
Sắp xếp những vấn đề cần giải quyết theo mức độ quan trọng ưu tiên

b) Yêu cầu cụ thể

Vấn đề cần được thể hiện ở mức độ tổng quan và chi tiết.
Các kiến thức liên quan đến vấn đề cần được liệt kê và nẵm rõ.
Vấn đề phải được đóng gói chi tiết và đầy đủ về phạm vi ứng dụng.
Vấn đề phải ăn khớp với yêu cầu thực tế từ PO/ Khách hàng

Bước 3: Phân tích yêu cầu và đưa ra giải pháp

a) Nội dung chi tiết

Tiền đề để phân tích yêu cầu và đưa ra giải pháp:
Yêu cầu từ PO/ Khách hàng
Tài liệu chuyên ngành liên quan
Mối quan hệ giữa các chức năng
 Để nhìn được bức tranh tổng thể cũng như đưa ra giải pháp cho các vấn đề, QM cần:
Nghiên cứu kĩ các tài liệu liên quan
Xây dựng diagram
Liệt kê các giải pháp cho từng vấn đề đã được đóng gói.
Giải pháp đưa ra phải đáp ứng những yêu cầu sau:
Giải quyết được vấn đề của dự án
Đơn giản và mang tính tối ưu cao
Phù hợp với định hướng, yêu cầu của PO/ Khách hàng

b) Yêu cầu cụ thể

Hiểu biết tốt về những kiến thức chuyên ngành
Xây dựng được model chức năng cho dự án
Thành thạo việc xây dựng sơ đồ phân tích (Sequence diagram, activity diagram, vv)
Nắm rõ các concept liên quan tới dự án

Bước 4: Biên soạn tài liệu hướng dẫn SRS (Software Requirement Specification
Documentation)

a) Thành phần
Template: SRS Template
Mục đích: Hướng dẫn một cách chi tiết và rõ ràng cho người dùng sử dụng các chức năng của sản phẩm
Đối tượng hướng tới: Người dùng (User)
Hình thức trình bày: Bố cục rõ ràng, các bước thực hiện chức năng cần được đánh số và chú thích rõ ràng
Ngôn ngữ viết: Tiếng Anh/Tiếng Việt
Nội dung: bao gồm các bước thực hiện các chức năng của sản phẩm như Template hướng dẫn

b) Yêu cầu cụ thể

Đầy đủ chức năng của sản phẩm
Mô tả phạm vi ứng dụng của sản phẩm
Văn phong rõ ràng, ngắn gọn, dễ đọc hiểu và dễ thực hiện
Hình ảnh minh họa, ghi chú, phụ lục đầy đủ

Tham khảo: Documentation system

Example

Example

Bước 5: ER model và Screen Flow

a) Nội dung chi tiết

QM cần tiến hành vẽ ER model để thể hiện mối liên hệ giữa các entity trong dự án. Đây là sơ đồ quan trọng để giúp BE và FE hiểu được yêu cầu của dự án và là
cơ sở để BE xây dựng data model.
Việc thiết kế screen flow là tiền đề phục vụ cho việc thiết kế sản phẩm cũng như giúp team BE và FE hiểu về luồng hoạt động của dự án.
Template tham khảo:
ER model
Screen Flow

b) Yêu cầu cụ thể

ER model phải thể hiện đầy đủ các entity và mối liên hệ của chúng (1-n, n-n, 1-1, vv.)
Screen flow phải mô tả đầy đủ luồng hoạt động của các screen trong dự án, có thể là luồng hoạt động với các dự án liên quan

Bước 6: Lên kế hoạch triển khai

a) Nội dung chi tiết

Với từng dự án cần có kế hoạch một cách cụ thể để dễ dàng bám sát thực hiện và theo dõi tiến độ.
Các bước lên kế hoạch triển khai như sau:
Bước 1: Xây dựng timeline cho từng bước của dự án:
Timeline Template
Bước 2: Phân bổ công việc trên kanban
Tạo epic
Tạo các user story trong epic của phòng
Tạo sprint theo từng giai đoạn của dự án
Sắp xếp các user story vào sprint tương ứng
:::info Lưu ý: Ứng với mỗi user story, QM có thể phân thành những task nhỏ để dễ dàng thực hiện công việc

:::

Phân bổ công việc trên kanban cho giai đoạn thiết kế:

Tạo Epic, Sprint, User story theo quy tắc thống nhất sau đây:

Epic: Phải có tên mã (1-2 từ), có thể là bất cứ thứ gì miễn là nó “unique” và dễ nhớ

Ví dụ : QM - Saturn- Provider Onboarding Process

User story: Được đặt tên bằng danh từ

Ví dụ : [QM] Data assessment

Sprint: Tên dự án + sô series

Ví dụ : Credential-QM-01

:::info Lưu ý: Plan phải được sign off bởi PO trước khi release bắt đầu

:::

b) Yêu cầu cụ thể

Thu thập tất cả dữ liệu bạn có thể, bao gồm:
Mục tiêu chính và ưu tiên của chúng là gì?
Các lựa chọn là gì (tức là đánh đổi)?
Tình hình hiện tại như thế nào?
Thiết kế / vẽ / lập tài liệu & thu thập càng nhiều phản hồi càng tốt
Liệt kê tất cả các hạng mục công việc (mà chúng tôi có thể).
Thiết lập cấu trúc dự án và đàm phán về phạm vi, thời gian và nguồn lực.
Nêu rõ các rủi ro, kế hoạch điều chỉnh, các kịch bản dự phòng
Vạch ra kế hoạch chi tiết.
Kế hoạch triển khai đầy đủ và chi tiết
Tiến độ phù hợp, hoàn thành trong 80% thời gian yêu cầu, 20% còn lại dự phòng cho các thay đổi.
Phân chia task sao cho khối lượng công việc và thời gian thực hiện một cách khả thi
Sử dụng kanban, excel, các tools liên quan thành thạo.
Đặt tên các Epic, User story, Issue,.. đúng quy chuẩn

Bước 7: Thiết kế sản phẩm

Thiết kế là bước quan trọng nhất trong quá trình triển khai dự án. Bản thiết kế làm tiền đề cho team FE và BE thực hiện develop sản phẩm.

a) Nội dung chi tiết

Việc thiết kế sản phẩm cần tuân theo những quy tắc nhất định, để những sản phẩm có sự thống nhất với nhau về mặt giao diện và bố cục

Quy tắc thiết kế:

Yêu cầu về Layout

Sử dụng hệ thống grid 12 columns
Width: 1920px, Height: 916px (Height không cố định, có thể thay đổi tùy theo từng màn hình)
Độ căn chỉnh chính xác.
Ví dụ: Width 1800px => 120px width của mỗi column + 30px phần ngăn cách các column.
Khoảng cách giữa các thành phần phải tạo nên sự hài hòa cho tổng thể.
Yêu cầu về Structure:
Đặt tên rõ ràng cho từng screen
Sử dụng component
Sắp xếp và căn chỉnh màn hình hợp lý:
Trục X: Luồng hoạt động của một chức năng cụ thể
Trục Y: Luồng chức năng của màn hình trước đó
Yêu cầu về Elements:
Lựa chọn màu và phông chữ từ kiểu đã xác định trước thay vì tạo ra từng mẫu một.
Style về màu và font chữ của QM : Theme
Yêu cầu về Component và Naming:
QM thống nhất với Front-end team về những component và cách đặt tên để hai team làm việc với nhau một cách trơn tru, không bị mâu thuẫn về vấn
đề UI/UX.
Component phải đảm bảo chính xác về kích thước, màu sắc, phông chữ. Nếu một trong hai team có sự khác nhau về component thì cần phải bàn bạc,
trao đổi để đưa ra component phù hợp nhất.
Một số component đã được thiết kế : Component

b) Yêu cầu cụ thể

Hiểu rõ khái niệm hi-fi mockup và nắm vững quy tắc thiết kế
Giao diện hài hòa, dễ sử dụng, đáp ứng 80-90 % yêu cầu từ khách hàng
Đảm bảo đầy đủ chức năng cần thiết
Chú thích rõ ràng cho từng màn hình
Prototype phải thể hiện được đầy đủ luồng hoạt động của ứng dụng.
Bước 8: Release

a) Nội dung chi tiết

Theo quy trình công ty, release sản phẩm sẽ theo các bước như sau:

Smoke test 1 (SM1): Đây là giai đoạn đầu tiên. QM phần lớn tập trung vào việc phân tích vấn đề và đưa ra các chức năng cơ bản. Giai đoạn này là optional,
nhưng nếu có thì cần plan rõ ràng tước khi release bắt đầu.
Smoke test 2(SM2): Giai đoạn đi vào thiết kế chi tiết cho những chức năng đã được phác thảo ở SM1 và điều chỉnh giao diện theo phản hồi từ FE team và BE
team. Giai đoạn này là optional, nhưng nếu có thì cần plan rõ ràng tước khi release bắt đầu.
Release candidate (RC):
Là giai đoạn quan trọng trong quá trình thiết kế.
Phải đáp ứng được trên 80% yêu cầu từ PO/ Khách hàng.
Phải được release trước deadline 1 tuần và có khả năng trở thành bản Final Release.
Phải tuân theo quy trình review hoàn toàn giống với bản Finale Release
Final Release (FR): .
Là giai đoạn cuối cùng trong thiết kế dự án
Phải đáp ứng được 100 % yêu cầu từ PO/ Khách hàng.
Phải có release notes
Phải được gói gọn dưới dạng archive (hoặc git tag)
Phải được sign off bởi down-stream department (BE Manager, FE Manager)
Phải được lưu trữ trong kanban như một release note story
Bản final release sau khi đã hand-off vẫn không tránh khỏi những thay đổi phía PO cũng như khách hàng. Do đó QM phải có kế hoạch rõ ràng trong việc cập
những, sửa đổi bản thiết kế để tránh không làm rối đi luồng hoạt động ban đầu của nó.

Công việc cần làm:

Trước release:
Viết file changelog ghi lại những chức năng đã hoàn thành
Push lên git bản release của dự án, đặt tên folder theo ngày release.
Tạo merge request cho Department Manager (DM)
Release:
Đối với SM1, SM2 và RC: Tạo user story (US) bao gồm:
Changelog
Link bản design
Link git của bản release
ER model diagram
Danh sách các thuật ngữ, concept của project
Ghi chú cho các complex case
Các bên liên quan (Thêm vào watchers của user story đó)
Đối với bản final release:
Cập nhật changelog và link git mới cho US của Release Candidate
Gửi email release cho PO và các bên liên quan

b) Yêu cầu cụ thể

Changelog rõ ràng, liệt kê đầy đủ các chức năng đã hoàn thành trong bản thiết kế
Bản release phải được DM duyệt và merge vào nhánh master trên git của project đó
Cần được sign off từ DM của FE và BE đối với bản RC và FR

Bước 9: Chuẩn bị cho kiểm tra chất lượng sản phẩm/dự án

Bao gồm 2 phần:

Xây dựng Test case

Xây dựng Release checklist

1. Xây dựng test case

a) Nội dung chi tiết

Mục đích:

Tiết kiệm thời gian kiểm thử

Tránh bị thiếu sót trường hợp kiểm thử
Dễ giao tiếp với các bên liên quan khi gặp ứng dụng gặp lỗi

Quy định:

Liệt kê đầy đủ các trường hợp kiểm thử bao gồm giao diện và chức năng.
Có sự thống nhất giữa các thành viên trong team, và tuân theo quy tắc đã đề ra.

Cấu trúc cơ bản của Test case:

 Test src: Liệt kê những trường hợp, chức năng cần được kiểm thử
Test run: Liệt kê những trường hợp, chức năng đã được kiểm thử

Các nội dung chi tiết liên quan đến test case tham khảo Kế hoạch cho quản lý và xây dựng test case

b) Yêu cầu cụ thể

Cấu trúc tuân theo một chuẩn thống nhất

Đảm bảo chính xác, rõ ràng
Sử dụng đầy đủ hình ảnh minh họa cho từng trường hợp
Bao quát toàn bộ chức năng của dự án

2. Xây dựng Release Checklist

a) Nội dung chi tiết

Mục đích:

Tổng hợp toàn bộ những chức năng đã và chưa hoàn thành của dự án
Liệt kê những vấn đề còn tồn đọng
Đánh giá mức độ thống nhất về mặt giao diện và chức năng của các dự án
Đánh giá mức độ hoàn thành dự án
Giúp các thành viên khác trong dự án dễ dàng theo dõi và sửa lỗi

Quy định:

Các chức năng được liệt kê dưới dạng checklist

Cần có hình ảnh chứng minh đi kèm hoặc link issue trên kanban đối với những chức năng chưa hoàn thành hoặc có bug.
Đặt tên file theo thời gian release dự án

Cấu trúc cơ bản của file release checklist:

General: Liệt kê những chức năng chung và những component chung của toàn bộ dự án
Từng dự án: Liệt kê toàn bộ những chức năng và vấn đề về giao diện của dự án đó

b) Yêu cầu cụ thể

Liệt kê ngắn gọn, đầy đủ các chức năng

Bố cục trình bày rõ ràng
Hình ảnh, link issue đầy đủ

Bước 9: Kiểm thử và báo cáo kết quả (release checklist)

a) Nội dung chi tiết

Các giai đoạn kiểm thử:

Ứng với 4 giai đoạn của quá trình thiết kế hifi mockup sẽ có 4 giai đoạn để kiểm thử phần mềm.
SM1: Trong giai đoạn này, thời gian kiểm thử diễn ra trong vòng 1 ngày và không cần viết release checklist.
SM2: Trong giai đoạn này, thời gian kiểm thử diễn ra trong vòng 1 ngày và không cần viết release checklist
RC: Trong giai đoạn này, thời gian kiểm thử trong vòng 1 tuần. Cần viết release checklist để liệt kê những chức năng cũng như những vấn đề (issue) của
sản phẩm.
FR: Đây là thời điểm Department hoàn thành tất cả các issue và nhận được sign-off của các phòng và PO, tuyên đố release sản phẩm của phòng.

Công việc cụ thể:

Tạo issue trên kanban của dự án đang thực hiện kiểm thử khi phát hiện bug
Assign người liên quan tới issue đó
Cập nhật file release checklist

:::info Lưu ý:

Bản final release của ứng dụng từ team FE vẫn không tránh khỏi những sai sót về kỹ thuật cũng như giao diện. Vì thế team FE sẽ cập nhật các bản vá tiếp theo
sau giai đoạn final release. QM sẽ tiếp tục thực hiện việc kiểm thử khi nhận được email của FE team về bản vá và cập nhật file checklist.

:::

b) Yêu cầu cụ thể

Thực hiện kiểm thử nhanh chóng và kịp thời
Tạo issue dễ hiểu
Những issue mang tính cấp bách phải được thiết lập ở chế độ ưu tiên
Viết test run chính xác và đầy đủ hình ảnh.
Cần đưa ra bằng chứng cụ thể về lỗi ứng dụng trong file checklist (hình ảnh, issue, vv)