Dưới đây là quy trình chung khi sản xuất một phần mềm hoặc tính năng trong phần mềm - sau đây gọi tắt là một Epic


# Mô tả ngắn
Về mặt mô tả ngắn thì gồm các bước chính sau
- BP Draft + BP review
- Thực hiện: PO
- bước này thực hiện khi làm các proj cho doanh nghiệp, vì cần phải có sự tham gia của doanh nghiệp để validate luồng bussiness
- UX design + UX review + UX internal review
- Thực hiện: PO, BA
- mục đích chính là lên giao diện để đảm bảo phần mềm hoạt động đủ luồng, với các sản phẩm làm cho thị trường mass (không có bước BP draft phía trên) thì bước này sẽ bao gồm cả việc review BP luôn
- Architeture Design + Architeture review
- Thực hiện: TechPIC, Tech Lead
- Lên mô tả ở mức highlevel design bao gồm việc clear rõ objective, Design proposal, đảm bảo hiểu rõ Backward Compatitive và lên được Action Plan rõ ràng
- API design
- Thực hiện: TechPIC, Tech Lead
- Thiết kế API cho hệ thống, bao gồm việc edit API cũ, tạo API mới
- Break task
- Thực hiện: Tech Lead, PO, BA
- Đây thực chất là buổi họp với các team phát triển liên quan để làm rõ nội dung tính năng, clear các đầu việc cần làm, lên kế hoạch triển khai (estimate thời gian hoàn thành tính năng). Các thành viên tham gia bao gồm thành viên của các team liên quan, QC
- Coding
- Thực hiện: dev team, tech lead
- Quá trình thực hiện coding và thực hiện ghép các công đoạn vào nhau để có được tính năng như đã define, sau quá trình coding này, khi team dev đã hoàn thành xong hết các task trong action plan, tech lead cần review lại toàn bộ tính năng trước khi chuyển sang Ready for integration
- SIT testing
- Thực hiện: QC, dev team
- QC thực hiện test toàn bộ tính năng dự định sẽ release ở mức độ highlevel trên môi trường dev, bao gồm nhưng không bắt buộc test các tính năng đã phát triển trước đó để đảm bảo không có lỗi phát sinh trên các tính năng đã release. Nếu hệ thống pass tất cả các tcs > chuyển sang bước UAT testing. Nếu còn lỗi, QC cần log bug, kéo Epic quay lại Coding và thông báo cho Tech Lead và dev team để fix.
- UAT testing
- Thực hiện: PO, BA, khách hàng
- Để thực hiện bước này, team dev cần deploy phần mềm (đã validate bởi QC) lên môi trường staging, PO/BA sẽ vào môi trường stage để test đảm bảo phần mềm hoạt động đúng như những tính năng trong BP, UI/UX yêu cầu. Ngoài ra có thể invite một tệp customer để thực hiện test cùng. (trước đây trong các game như Võ lâm truyền kỳ hay có bản beta, đây chính là bước UAT testing này)
- Ready for production
- Thực hiện: PO, BA, Tech Lead, QC
- Khi sản phẩm chạy ổn định trên môi trường staging và đã pass UAT testing, Tech lead (người chịu trách nhiệm Architecture design) cần phải đưa ra một tài liệu release plan, bao gồm nhưng không đầy đủ: thời điểm release tính năng, thứ tự release theo từng service, các merge request, pipeline cần nhấn, kế hoạch rollback hệ thống nếu xảy ra lỗi. Ngoài ra QC cũng cần review tài liệu này và bổ sung các tcs quan trọng cần phải test trên prod. Cuối cùng PO cần chốt thời điểm release sản phẩm, lên tài liệu hướng dẫn sử dụng cũng như các tài liệu liên quan gửi tới KH
- Released to production
- Thực hiện: Tech Lead, dev team, QC
- Thực chất đây là bước release tính năng lên production
- Review outcome
- Thực hiện: PO, BA, Tech Lead
- Bước này là review xem tính năng khi lên production có được nhiều người sử dụng không, tính năng có mang lại trải nghiệm tốt cho người dùng không. Sau bước này có thể chuyển Epic sang Done - kết thúc một vòng đời phát triển sản phẩm

---

# Kinh nghiệm của một Tech Lead khi thực chiến với quy trình phát triển phần mềm

## UX review
Tốt nhất là Tech Lead nên join vào quy trình từ bước này để đảm bảo phần mềm/tính năng phía PO request không bị out-of-technical (đôi khi có các tính năng không thể thực hiện, BP design không hợp lý)

Để tham gia được vào buổi họp UX review này cần đảm bảo
- Hiểu rõ hệ thống bản thân đang nắm (đôi khi hệ thống là nhận từ dev cũ đã nghỉ việc)
- Có kiến thức rộng về các technical hiện có trên thị trường (ví dụ kafka, queue pub-sub, các kỹ thuật scale hệ thống,...)
- Tốt hơn nữa là có mind set về phát triển sản phẩm (nhớ về nguyên tắc 80/20 - 20% công việc sẽ mang lại 80% giá trị của sản phẩm) để góp phần phản biện và đưa ra các option (bao gồm cả pros&cons) cho PO/BA (có khi là cả ban giám đốc) chọn lựa

## Architecture Design
- Đảm bảo hiểu rõ các hệ thống có sẵn trong công ty (bao gồm công nghệ, cách sử dụng,...) để lên plan tích hợp nếu cần (ví dụ có những công ty sử dụng service gửi email internal để dễ dàng ghi log và quản lý chi phí,...)
- Hiểu rõ hệ thống mà team đang nắm có những ưu và nhược điểm gì
- Khi Arch design cần đảm bảo đủ
- Hiểu rõ **Objective** của Epic
- Nêu được **Background**: hệ thống hiện tại của team & của công ty đang có gì
- **Design Proposal**: đây không gì hơn là lời giải cho bài toán mà PO đã đưa ra. Cần lưu ý một bài toán sẽ có nhiều cách giải. Thứ mà sếp cần ae là đưa ra ít nhất 2-3 cách giải và nêu được pros & cons của mỗi cách, mục tiêu để người đọc có càng nhiều thông tin càng tốt, cuối cùng việc lựa chọn giải pháp nào sẽ do chính bạn là người đề xuất hoặc sẽ có phản biện từ sếp/commitee.
- Dataflow: đây là vizualize quan trọng để dev-team sử dụng và làm theo trong khi coding. Cũng là tài liệu để sếp, QC tham khảo
- **Backward Compatitive**: hiểu đơn giản là tính tương thích ngược, tính năng mới đưa ra cần đảm bảo không làm crash tính năng cũ, không crash hệ thống. Một số ví dụ:
- 1. nếu muốn đổi column name trong DB, cần tạo column mới > copy data từ column cũ sang > deploy code để đọc dữ liệu từ column mới > đảm bảo ổn định mới drop column cũ.
- 2. muốn đổi tên param trong API, cần thông báo sẽ deprecated param cũ > tạo param mới, cho phép sử dụng cả 2 param mới/cũ khi call API và đảm bảo các phiên bản FE, mobile cũ chạy ổn định > khi tất cả KH chuyển sang sử dụng client mới thì mới thực hiện deprecated param cũ
- ...
- **Action Plan**: nêu được các công việc cần làm và mô tả rõ đầu vào, đầu ra cho từng việc
- Đôi khi một Arch Design cần có sự tham gia của nhiều Tech Pic vì có thể tính năng liên quan đến nhiều team, khi này bạn cần nêu được đầu vào, đầu ra mong muốn và trao đổi với các Tech Lead của các team liên quan để nhờ họ hỗ trợ

## API documentation
- Trước khi design API cần **review kỹ UI/UX** vì sẽ có những thông tin nhỏ dù không được nêu rõ trong Highlevel design nhưng PO có define trong UI
- API cần đính kèm Dataflow để người đọc hiểu rõ nó được sử dụng trong ngữ cảnh nào
- Khi define API mới cần nêu rõ sẽ sử dụng cho tính năng nào, các API params, request body, response param có ý nghĩa gì
- Trường hợp sửa API cũ cần đảm bảo tính tương thích ngược. Nêu rõ ý nghĩa khi bổ sung API params, request body, response param
- Có thể ghép API create/update vào thành 1 API
- Liên quan đến chuyển đổi trạng thái (ví dụ hợp đồng có 10 trạng thái khác nhau có thể thay đổi) nên được tách thành 1 API update riêng để dễ dàng scale
- Nếu có thời gian có thể define sẵn một vài mã lỗi của API

## Break task
Bản chất đây là buổi họp với team dev, vì vậy phải làm sao đảm bảo các dev hiểu được hết nội dung công việc của 1 Epic. Buổi họp này cũng cần phải define được plan thực hiện công việc để các task ở các team giảm tối đa việc bị phụ thuộc nhau

Cuối cùng cần có board để monitor nhằm để PO và bản thân có thể nắm được tiến độ chung của Epic. Ví dụ board sau

## Coding
Ở bước này đầu tiên Tech Lead cần define được code base để cả team follow theo, việc này nhằm mục đích dễ dàng handle MR, team có tiếng nói chung khi làm việc. Ngoài ra team member cũng làm việc với QC để viết Unit test. Overall, code base cần đảm bảo:
- Có folder tree rõ ràng, phân chia folder rõ ràng, phân tách và gộp các layer đảm bảo tính dễ quản lý và dễ scale
- Có sẵn luồng dockerize, luồng git ci/cd phù hợp với hạ tầng của công ty
- Có readme.md và docker-compose.yaml rõ ràng để người mới dễ dàng tiếp cận
- Có luồng unit test rõ ràng, dễ dàng deploy unitest lên Jira or các công cụ tương đương. Có test coverage
- Tích hợp với monitor, alert của công ty để team có thể giám sát

Một số tip, trick để team có thể coding hiệu quả
- Đảm bảo quy trình test ở CI, dựng thành công các môi trường test, dev, stage
- Define quy trình quản lý source code trên git, member phải clear được mình sẽ checkout branch name ntn, team follow quy trình trunk base hay git flow
- Cần define các rule đảm bảo clean code: đặt tên hàm, tên biến, comment trong code, cách tổ chứng config trong env để tránh bị phình dẫn tới khó kiểm soát sau này
- Cho phép member review code chéo nhau
- Member nên xin QC bộ tcs để dễ dàng handle việc viết unit test
Trước khi kéo Epic sang Ready for Integration, Team Lead cần validate tính năng trên môi trường DEV để đảm bảo luồng chính tính năng hoạt động ok và tránh được một số lỗi cơ bản.

## SIT testing
Setup được event để push lên slack mỗi khi QC tạo bug. Làm việc với QC về các case lỗi để clear trước khi chuyển cho team member, by pass các trường hợp những bug không quan trọng

## UAT testing
Khi QC kéo Epic sang UAT, team dev cũng cần đảm bảo tính năng được push và setup trên STAGE

## Ready for production
Như đã nói ở trên, TL cần lên danh sách các MR, thứ tự merge, release và phương án backup để tránh incident trên prod. Mục tiêu là giảm thời gian team cần handle bước release xuống càng ngắn càng tốt, và đảm bảo hệ thống an toàn > team an toàn & ngủ ngon

## Released to production
Team cần chọn thời điểm thích hợp để release và nên có thông báo trước cho KH nếu cần. Thường sẽ release sản phẩm vào ban đêm. Khi này nên lên plan để có cả QC involve thực hiện test live ngay sau khi hệ thống release đảm bảo tính năng mới vận hành ổn định.

Ngoài ra Tech Lead cần handle monitor và setup alert để có thể hiểu rõ tính năng khi release có người sử dụng không, có bug nào phát sinh không và khi có lỗi trên prod, cả team tự động có notification để có hướng xử lý ngay lập tức.

# Kết luận
> Guide này khá ngắn gọn, cần bổ sung thêm nhiều thông tin nhưng các thông tin chính đã được list ra đầy đủ. Sẽ cố gắng bổ sung sau khi có kinh nghiệm làm việc nhiều hơn

# Bổ sung

## Coding convention
- Đặt tên biến có ý nghĩa theo camelCase hoặc snake_case.
- Tên class và tên biến thường sử dụng danh từ. (VD class TicketService(BaseService): ...)
- Tên hàm sử dụng động từ. (def get_leads(): …)
- Không sử dụng magic number (dùng số trực tiếp trong code) mà cần đặt tên riêng cho hằng số

## Quy tắc Scrum Sprint
- Mỗi Sprint kéo dài 2 tuần
- Bao gồm 3 loại cuộc họp
- Sprint Planing: vào cuối mỗi sprint để tổng kết công việc của sprint hiện tại + define công việc sprint tiếp theo
- Sprint Demo: vào sau 1 ngày của Sprint Planing để demo các task đã hoàn thành trong sprint trước đó
- Daily Meeting: hàng ngày vào 9h, diễn ra tối đa 15p để keep tiến độ công việc của member + raise vấn đề đang gặp phải nếu có
- Nên setup bot để cảnh báo các task chuẩn bị/sắp bị quá due date
- Nên setup bot để push noti cho cả team mỗi khi QC tạo bug

## Git process
- Khi làm Epic mới: checkout branch từ master, đặt tên branch là EpicName
- Khi làm feature mới: checkout từ branch EpicName và đặt tên branch là feature/[task_code]
- Viết commit có ý nghĩa. (tránh git commit -m “Add code”)
- Không push -f sau khi review.
- Sau khi push new MR cần báo team member để review, service owner/maintainer sẽ có nhiệm vụ merge