Bản đồ công trìnhTờ này lắp: Kiểm thử, Repo & CI, Giám sát lỗi
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Vòng đời phần mềm: xây nhà, không phải dựng lều
Hãy nghĩ tới việc chị Lan mở chi nhánh Bánh Mộc thứ tư. Chị không thể sáng mai thuê thợ tới đập tường. Chị phải trả lời: mở ở đâu, phục vụ ai (ý tưởng); cần mấy bàn, bếp lớn cỡ nào, quầy đặt đâu (yêu cầu); bản vẽ mặt bằng, điện nước (thiết kế); thi công (xây dựng); kiểm tra điện, nước, phòng cháy (kiểm thử); khai trương (triển khai); rồi vận hành hằng ngày, sửa chữa, cải tạo (vận hành).
Phần mềm cũng có một vòng đời như vậy, gọi là SDLC (Software Development Life Cycle, vòng đời phát triển phần mềm). Có nhiều cách chia giai đoạn; chuỗi bài dùng bảy giai đoạn vì dễ nhớ và khớp với cách một doanh nghiệp nhỏ làm trong thực tế.
- 1. Ý tưởng
- 2. Yêu cầu
- 3. Thiết kế
- 4. Xây dựng
- 5. Kiểm thử
- 6. Triển khai
- 7. Vận hành
- Phát hiện lỗi
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- 1. Ý tưởng → 2. Yêu cầu
- 2. Yêu cầu → 3. Thiết kế
- 3. Thiết kế → 4. Xây dựng
- 4. Xây dựng → 5. Kiểm thử
- 5. Kiểm thử → 6. Triển khai
- 6. Triển khai → 7. Vận hành
- 7. Vận hành → 1. Ý tưởng (Phản hồi, số liệu, sự cố)
- 5. Kiểm thử → 4. Xây dựng (Phát hiện lỗi)
- 3. Thiết kế → 2. Yêu cầu (Thiếu thông tin)
Điều quan trọng nhất trong sơ đồ là mũi tên quay ngược. Vòng đời không phải đường thẳng mà là vòng lặp: vận hành sinh ra phản hồi và ý tưởng mới; kiểm thử phát hiện lỗi đưa về xây dựng; thiết kế phát hiện yêu cầu còn thiếu. Phần mềm tốt là phần mềm đi qua vòng này nhiều lần, mỗi lần một ít.
Bảy giai đoạn và sản phẩm đầu ra
Mỗi giai đoạn trả lời một câu hỏi trung tâm và tạo ra sản phẩm đầu ra (deliverable) cụ thể. Sản phẩm đầu ra là thứ cầm nắm được: một tài liệu, một sơ đồ, một đoạn code, một bản báo cáo. Nếu một giai đoạn không để lại gì cầm nắm được, rất có thể nó đã bị bỏ qua.
| # | Giai đoạn | Câu hỏi trung tâm | Sản phẩm đầu ra chính |
|---|---|---|---|
| 1 | Ý tưởng | Vấn đề gì đáng giải? Có cần phần mềm không? | Tuyên bố vấn đề, quyết định xây/mua, chỉ số thành công |
| 2 | Yêu cầu | Người dùng cần làm được gì? Phạm vi MVP là gì? | PRD, user story, tiêu chí chấp nhận, wireframe |
| 3 | Thiết kế | Hệ thống được tổ chức thế nào? | Mô hình dữ liệu (ERD), thiết kế API, kiến trúc, ADR, thiết kế giao diện |
| 4 | Xây dựng | Làm cho nó chạy được | Mã nguồn trong Git, spec tính năng, pull request |
| 5 | Kiểm thử | Nó có chạy đúng và an toàn không? | Bộ test tự động, báo cáo UAT, checklist bảo mật |
| 6 | Triển khai | Đưa tới người dùng thật một cách an toàn | Pipeline CI/CD, môi trường production, ghi chú phát hành |
| 7 | Vận hành | Giữ nó khỏe và ngày càng tốt hơn | Giám sát, runbook, postmortem, backlog cải tiến |
Dưới đây là cái nhìn ngắn về từng giai đoạn, kèm câu hỏi: AI thay đổi gì ở đây?
1. Ý tưởng
Đây là lúc xác định vấn đề, không phải giải pháp. “Bánh Mộc cần app” là giải pháp. “Bánh Mộc sót và sai đơn bánh kem đặt trước, mỗi mùa lễ mất khách và mất tiền” là vấn đề. Ở giai đoạn này, bạn cũng quyết định có nên tự xây không, hay mua phần mềm có sẵn.
AI thay đổi gì: AI là người phản biện và trợ lý nghiên cứu rất tốt: đặt câu hỏi “5 Whys”, liệt kê giải pháp có sẵn trên thị trường, ước tính chi phí. Nhưng AI không biết doanh nghiệp của bạn đau ở đâu. Rủi ro mới: vì xây giờ rẻ hơn, người ta dễ xây những thứ không nên xây.
2. Yêu cầu
Biến vấn đề thành mô tả cụ thể: ai dùng, làm gì, thế nào là đúng, cái gì không làm. Đầu ra là PRD (tài liệu yêu cầu sản phẩm), user story với tiêu chí chấp nhận, và phác thảo màn hình.
AI thay đổi gì: AI có thể phỏng vấn ngược bạn, phát hiện trường hợp biên bạn chưa nghĩ tới, viết nháp PRD từ ghi chú lộn xộn. Rủi ro mới: yêu cầu mơ hồ giờ không còn “rẻ” nữa, vì AI sẽ lấp chỗ trống bằng phỏng đoán, và phỏng đoán sai bị khuếch đại thành hàng nghìn dòng code sai.
3. Thiết kế
Quyết định cấu trúc: dữ liệu lưu thế nào, các phần nói chuyện với nhau ra sao, dùng công nghệ gì, ai được làm gì, giao diện trông thế nào. Những quyết định này khó thay đổi về sau, nên đáng được cân nhắc kỹ và ghi lại.
AI thay đổi gì: AI đề xuất được nhiều phương án, vẽ sơ đồ, phản biện mô hình dữ liệu. Rủi ro mới: agent sẽ tự ra quyết định thiết kế nếu bạn không ra trước, và mỗi phiên làm việc có thể quyết khác nhau. Đó chính là cách app vibe của chị Lan có bốn cách lưu đơn hàng.
4. Xây dựng
Viết code, giao diện, tích hợp. Đây là giai đoạn AI thay đổi nhiều nhất: những gì trước đây mất vài tuần, giờ có thể xong trong vài giờ với một agent được chỉ đạo tốt.
AI thay đổi gì: tốc độ và chi phí giảm mạnh. Rủi ro mới: khối lượng code tăng nhanh hơn khả năng review của con người; code “trông đúng” nhưng thiếu trường hợp biên; nợ kỹ thuật tích tụ nhanh.
5. Kiểm thử
Chứng minh phần mềm làm đúng điều nó cần làm, không làm điều nó không được làm, và an toàn. Gồm test tự động, kiểm thử thủ công, nghiệm thu với người dùng thật (UAT) và rà soát bảo mật.
AI thay đổi gì: AI viết test rất nhanh và có thể tự chạy test để tự kiểm chứng. Rủi ro mới: AI có thể viết test “cho có”, hoặc sửa test để test qua thay vì sửa code. Kiểm thử trở thành tín hiệu duy nhất để biết agent làm đúng, nên chất lượng của bộ test quan trọng hơn bao giờ hết.
6. Triển khai
Đưa phần mềm từ máy bạn lên internet, tới tay người dùng, một cách tự động, an toàn và có thể quay lui.
AI thay đổi gì: AI viết được file cấu hình CI/CD, hướng dẫn cấu hình tên miền, migration database. Rủi ro mới: agent có quyền chạy lệnh có thể vô tình chạm vào môi trường thật; một lệnh sai trên database production có thể xóa dữ liệu khách hàng.
7. Vận hành
Giám sát, xử lý sự cố, sửa lỗi, cập nhật thư viện, thu thập phản hồi, cải tiến. Phần lớn chi phí và thời gian sống của một phần mềm nằm ở đây.
AI thay đổi gì: agent đọc log, điều tra sự cố, đề xuất bản vá, tổng hợp phản hồi người dùng. Rủi ro mới: hệ thống do AI viết mà không ai hiểu sẽ rất khó vận hành; khi có sự cố lúc 7 giờ sáng ngày 20/10, bạn cần hiểu đủ để ra quyết định nhanh.
Chi phí của sai lầm tăng theo giai đoạn
Một nguyên lý lâu đời của nghề phần mềm: sai lầm phát hiện càng muộn, sửa càng đắt. Hiểu sai yêu cầu “tiền cọc tối thiểu 50% tiền bánh” (chẳng hạn tính trên tổng đơn gồm cả phí giao) ở giai đoạn yêu cầu chỉ tốn một cuộc trao đổi. Phát hiện ở giai đoạn kiểm thử thì phải sửa code và test. Phát hiện khi đã vận hành ba tháng thì phải sửa code, sửa dữ liệu cũ, đối soát lại tiền với hàng trăm khách, và giải thích với kế toán.
AI không thay đổi nguyên lý này. Nó chỉ làm cho giai đoạn xây dựng rẻ đến mức nhiều người bỏ qua giai đoạn trước để “làm luôn cho nhanh”. Kết quả là sai lầm vẫn đến, chỉ là đến muộn hơn và đắt hơn.
Waterfall, Agile và vòng lặp ngắn khi có agent
Đi qua bảy giai đoạn theo cách nào? Có ba mô hình chính.
Waterfall (thác nước): làm tuần tự từng giai đoạn, xong hẳn giai đoạn này mới sang giai đoạn sau. Viết đầy đủ yêu cầu cho cả hệ thống, rồi thiết kế toàn bộ, rồi xây toàn bộ, rồi kiểm thử toàn bộ. Ưu điểm là rõ ràng; nhược điểm là phản hồi rất muộn: tới khi người dùng thấy sản phẩm, có thể đã nhiều tháng trôi qua và yêu cầu đã thay đổi.
Agile (linh hoạt): chia sản phẩm thành những phần nhỏ, mỗi chu kỳ ngắn (thường một tới hai tuần) đi qua đủ các giai đoạn cho một phần nhỏ, đưa cho người dùng thử, học hỏi và điều chỉnh. Phản hồi nhanh, nhưng đòi hỏi kỷ luật để không biến “linh hoạt” thành “tùy hứng”.
Vòng lặp ngắn với agent: khi agent có thể xây một lát cắt tính năng trong vài giờ, chu kỳ co lại từ tuần xuống ngày, thậm chí giờ. Nhưng mỗi vòng nhỏ vẫn phải đi qua đủ các giai đoạn ở dạng thu nhỏ: nửa trang yêu cầu, một kế hoạch ngắn, code, test, commit, triển khai lên môi trường thử, xem phản hồi.
| Tiêu chí | Waterfall | Agile | Vòng lặp ngắn với agent |
|---|---|---|---|
| Độ dài một vòng | Nhiều tháng | 1–2 tuần | Vài giờ tới vài ngày |
| Tài liệu yêu cầu | Đầy đủ từ đầu | Vừa đủ, cập nhật dần | Spec ngắn cho từng lát, là đầu vào cho agent |
| Phản hồi người dùng | Cuối dự án | Cuối mỗi vòng | Rất thường xuyên |
| Rủi ro chính | Làm đúng thứ không ai cần | Mất định hướng tổng thể | Thay đổi nhanh hơn khả năng kiểm soát |
| Điều kiện để thành công | Yêu cầu ổn định | Đội kỷ luật, người dùng sẵn sàng góp ý | Spec rõ, test tự động, commit nhỏ, review chặt |
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Một vòng lặp ngắn với agent (vài giờ)
- Spec nửa trang → Kế hoạch agent đề xuất, bạn duyệt
- Kế hoạch agent đề xuất, bạn duyệt → Agent code
- Agent code → Kiểm chứng test, build, ảnh chụp
- Kiểm chứng test, build, ảnh chụp → Commit + PR
- Commit + PR → Triển khai bản thử
- Triển khai bản thử → Phản hồi người dùng
- Phản hồi người dùng → Spec nửa trang
AI là bộ khuếch đại
Báo cáo DORA 2025 về phát triển phần mềm có AI hỗ trợ đưa ra thông điệp trung tâm: AI là bộ khuếch đại. Nó phóng to những gì đã có sẵn trong tổ chức, cả điểm mạnh lẫn điểm yếu. Lợi ích lớn nhất không đến từ bản thân công cụ, mà đến từ việc cải thiện hệ thống làm việc bên dưới. Báo cáo nêu một số thực hành nền tảng giúp AI phát huy tác dụng, như có lập trường rõ ràng về cách dùng AI, quản lý phiên bản tốt, làm việc theo lô nhỏ, tập trung vào người dùng và có dữ liệu nội bộ mà AI truy cập được.
Hãy xem bộ khuếch đại hoạt động thế nào qua hai phiên bản của Bánh Mộc:
| Tình huống | Bánh Mộc “vibe” (2025) | Bánh Mộc “bài bản” (2026) |
|---|---|---|
| Có test tự động không? | Không. Agent không biết mình sai, sinh thêm code lỗi | Có. Agent tự chạy test, tự phát hiện và sửa |
| Có spec không? | Không. Mỗi phiên agent đoán một kiểu | Có. Mọi phiên đọc cùng một spec, kết quả nhất quán |
| Thay đổi lớn hay nhỏ? | Lớn. Một lỗi kéo theo cả màn hình | Nhỏ. Lỗi khoanh vùng trong một commit |
| Có Git không? | Không rõ ràng. Không quay lại được | Có. Quay lại bản trước trong vài giây |
| Tài liệu, file hướng dẫn agent? | Không. Agent lặp lại cùng sai lầm | Có AGENTS.md. Sai lầm được ghi lại để không lặp lại |
Cùng một công cụ AI, kết quả trái ngược. Bài học: đầu tư vào quy trình là cách tốt nhất để tận dụng AI. Mỗi bài trong chuỗi, xét cho cùng, là một mảnh của quy trình mà AI sẽ khuếch đại.
Bản đồ chuỗi bài theo giai đoạn
Chuỗi bài được sắp xếp theo vòng đời, cộng thêm hai module nền tảng ở đầu và ba module mở rộng, tổng kết ở cuối. Bảng dưới đây giúp bạn biết khi đang ở giai đoạn nào thì mở module nào.
| Giai đoạn SDLC | Module chính | Bắt đầu từ bài |
|---|---|---|
| Nền tảng (trước mọi giai đoạn) | M00 Khởi động, M01 Nền tảng máy tính và web, M02 Hiểu AI và agent coding | Phần mềm thực chất là gì01-01, LLM hoạt động thế nào02-01 |
| 1. Ý tưởng | M03 Từ ý tưởng đến yêu cầu (phần đầu) | Bắt đầu từ vấn đề03-01, Tự xây, đi mua hay no-code03-03 |
| 2. Yêu cầu | M03 (phần sau) | MVP và ưu tiên tính năng03-04, Viết PRD và spec03-06 |
| 3. Thiết kế | M04 Thiết kế hệ thống và kiến trúc, M05 Thiết kế UI/UX | Kiến trúc phần mềm là gì04-01, Nguyên tắc UX cơ bản05-01 |
| 4. Xây dựng | M06 Quy trình code với AI agent, M07 Quản lý mã nguồn và cộng tác | Thiết lập môi trường06-01, Git07-01 |
| 5. Kiểm thử | M08 Kiểm thử và chất lượng, M09 Bảo mật và dữ liệu | Vì sao kiểm thử08-01, Rủi ro bảo mật của code AI09-01 |
| 6. Triển khai | M10 Triển khai và DevOps | Deploy là gì10-01 |
| 7. Vận hành | M11 Vận hành, giám sát và bảo trì | Phần mềm là sinh vật sống11-01 |
| Vòng lặp tiếp theo: thêm AI vào sản phẩm | M12 Xây tính năng AI trong sản phẩm | Kiến trúc tính năng AI12-01 |
| Vòng lặp tiếp theo: mở rộng quy mô | M13 Mở rộng từ nhỏ đến lớn | Các giai đoạn trưởng thành của phần mềm13-01 |
| Tổng hợp toàn vòng đời | M14 Tổng kết và đồ án | Playbook từ ý tưởng đến sản phẩm14-01 |
Lưu ý hai điều. Thứ nhất, bảo mật (M09) không chỉ nằm ở giai đoạn kiểm thử: yêu cầu bảo mật phải có từ spec, được thiết kế ở kiến trúc, được kiểm tra ở mọi pull request. Thứ hai, bạn không cần đọc tuần tự mới làm được việc; bài Lộ trình học và cách học hiệu quả00-06 gợi ý ba lộ trình đọc khác nhau tùy vai trò.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-003
13.10.2026
- Chị LanChủ chuỗi
- Anh TuấnBếp trung tâm
- HàBán hàng online
Chị Lan dán bảng bảy giai đoạn lên tường văn phòng nhỏ ở chi nhánh Phú Nhuận, rồi tự đánh giá app vibe năm ngoái đã đi qua giai đoạn nào:
| Giai đoạn | App vibe 2025 | Kế hoạch Mộc OMS 2026 |
|---|---|---|
| 1. Ý tưởng | Bỏ qua (“cần app”) | Tuyên bố vấn đề, đo chi phí sai sót hiện tại |
| 2. Yêu cầu | Một câu prompt | Phỏng vấn Hà, anh Tuấn; PRD; user story cho MVP |
| 3. Thiết kế | AI tự quyết, mỗi lần một kiểu | ERD, ma trận quyền, ADR chọn stack |
| 4. Xây dựng | Một buổi tối | Từng lát cắt, mỗi lát một spec, commit nhỏ |
| 5. Kiểm thử | Bấm thử | Unit test cho tiền và trạng thái, E2E cho tạo đơn, UAT với nhân viên |
| 6. Triển khai | Nút “publish” | CI chạy test mỗi PR, staging, tên miền oms.banhmoc.vn |
| 7. Vận hành | Không có | Theo dõi lỗi, sao lưu, runbook, họp nhìn lại hằng tháng |
Chị cũng ánh xạ năm giai đoạn phát triển sản phẩm của Bánh Mộc vào vòng đời. Giai đoạn 0 “Khám phá” chính là bước 1–2 của vòng đời cho toàn bộ sản phẩm. Giai đoạn 1 “MVP Mộc OMS” là vòng đời đầy đủ lần đầu tiên. Các giai đoạn 2, 3, 4 sau đó (ra mắt và vận hành, thêm AI, mở rộng thành MộcOS) là những vòng lặp tiếp theo, mỗi vòng lại bắt đầu từ ý tưởng và yêu cầu. Bài Gặp gỡ Bánh Mộc00-05 trình bày chi tiết lộ trình này.
Quyết định quan trọng nhất của chị sau bài học: không bắt đầu Mộc OMS bằng việc mở coding agent. Chị dành hai tuần đầu cho giai đoạn 1–2: phỏng vấn nhân viên, ngồi cạnh Hà một buổi trực Zalo, đếm số đơn sai trong tháng trước. Anh Tuấn hỏi: “Sao chị không bảo AI làm luôn cho nhanh?” Chị cười: “Lần trước làm luôn cho nhanh, mình mất ba tháng.“
Prompt mẫu
Prompt dưới đây giúp bạn xác định dự án của mình đang ở giai đoạn nào và còn thiếu sản phẩm đầu ra nào:
Điền ô trống rồi sao chép
Tôi đang làm một phần mềm: [mô tả ngắn dự án và tình trạng hiện tại].
Những gì tôi đã có: [liệt kê: ghi chú, tài liệu, bản vẽ, code, test, môi trường chạy...].
Dựa trên vòng đời 7 giai đoạn (ý tưởng, yêu cầu, thiết kế, xây dựng, kiểm thử,
triển khai, vận hành), hãy:
1. Cho biết dự án của tôi đang ở giai đoạn nào trên thực tế (có thể khác điều tôi nghĩ).
2. Liệt kê sản phẩm đầu ra của các giai đoạn TRƯỚC mà tôi còn thiếu hoặc còn yếu.
3. Với mỗi thứ còn thiếu, nêu rủi ro cụ thể nếu tôi tiếp tục mà không bổ sung.
4. Đề xuất 3 việc nên làm trong tuần này, theo thứ tự ưu tiên.
Hãy thẳng thắn, đừng chỉ khen.Prompt thứ hai giúp bạn tạo “định nghĩa hoàn thành” cho một vòng lặp ngắn:
Điền ô trống rồi sao chép
Tôi sắp làm tính năng [tên tính năng] với coding agent trong một vòng lặp ngắn (1–2 ngày).
Hãy viết cho tôi một checklist "định nghĩa hoàn thành" gồm các mục cho 6 bước:
spec, kế hoạch, code, kiểm chứng, commit/PR, triển khai bản thử.
Mỗi bước tối đa 3 mục, mỗi mục kiểm tra được bằng có/không.Sai lầm thường gặp
-
Sự cố 01
Nhảy thẳng vào giai đoạn xây dựng.
Triệu chứngVì AI xây nhanh, người mới thường bắt đầu bằng “làm app cho tôi”.
Cách tránhtrước khi mở coding agent, phải có ít nhất tuyên bố vấn đề và danh sách tính năng MVP kèm danh sách “không làm”.
-
Sự cố 02
Coi kiểm thử là việc làm sau cùng, nếu còn thời gian.
Triệu chứngKhi đó kiểm thử thường bị cắt.
Cách tránhtiêu chí chấp nhận được viết ở giai đoạn yêu cầu, test được viết cùng lúc với code (hoặc trước code), và “chưa có test” nghĩa là “chưa xong”.
-
Sự cố 03
Nghĩ ra mắt là kết thúc.
Triệu chứngNgân sách và năng lượng dồn hết cho ngày ra mắt, không còn gì cho vận hành.
Cách tránhlên kế hoạch vận hành (ai theo dõi lỗi, ai sao lưu, ai nhận phản hồi) trước khi ra mắt; xem Sau ngày ra mắt11-01.
-
Sự cố 04
Hiểu Agile thành “không cần tài liệu”.
Triệu chứngAgile đề cao phần mềm chạy được hơn tài liệu thừa, nhưng không bỏ tài liệu cần thiết. Với agent, tài liệu (spec, AGENTS.md, ADR) còn là ngữ cảnh mà agent đọc mỗi phiên.
Cách tránhviết tài liệu ngắn, sống, nằm trong repo.
-
Sự cố 05
Mong AI sửa quy trình hộ mình.
Triệu chứngMua công cụ AI xịn hơn không chữa được quy trình lộn xộn; nó chỉ làm lộn xộn nhanh hơn.
Cách tránhtrước khi đổi công cụ, xem lại quy trình: có spec không, có test không, có commit nhỏ không.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Đánh giá một dự án cũ
Chọn một dự án phần mềm bạn từng làm, từng thuê làm, hoặc từng dùng thử ở công ty. Lập bảng bảy giai đoạn như chị Lan, ghi giai đoạn nào đã làm, làm sơ sài hay bỏ qua.
Kết quả mong đợi
bạn tìm được mối liên hệ giữa giai đoạn bị bỏ qua và vấn đề mà dự án gặp sau đó.
-
Bài 2
Cơ bản
Vẽ vòng đời cho dự án của bạn
Với dự án bạn định làm trong chuỗi bài, viết một dòng mô tả sản phẩm đầu ra bạn kỳ vọng ở mỗi giai đoạn, kèm ngày dự kiến.
Kết quả mong đợi
một bảng bảy dòng; nếu giai đoạn 1–3 chiếm chưa tới khoảng một phần tư tổng thời gian, hãy cân nhắc lại.
-
Bài 3
Nâng cao
Bài kiểm tra bộ khuếch đại
Liệt kê năm thói quen làm việc hiện tại của bạn hoặc đội của bạn (cách giao việc, cách kiểm tra, cách lưu tài liệu…). Với mỗi thói quen, viết điều gì xảy ra nếu nhân tốc độ làm việc lên mười lần.
Kết quả mong đợi
bạn xác định được ít nhất hai thói quen sẽ trở thành vấn đề lớn khi có agent, và một hành động cải thiện cho mỗi thói quen.
Thuật ngữ trong bài
- SDLC
- Software Development Life Cycle: vòng đời phát triển phần mềm
- Sản phẩm đầu ra (deliverable)
- Thứ cụ thể mà một giai đoạn tạo ra: tài liệu, sơ đồ, code, báo cáo
- PRD
- Product Requirements Document: tài liệu yêu cầu sản phẩm
- ERD
- Entity Relationship Diagram: sơ đồ thực thể và quan hệ dữ liệu
- ADR
- Architecture Decision Record: bản ghi một quyết định kiến trúc
- Waterfall
- Mô hình làm tuần tự, xong giai đoạn này mới sang giai đoạn sau
- Agile
- Mô hình làm theo chu kỳ ngắn, phản hồi và điều chỉnh liên tục
- UAT
- User Acceptance Testing: nghiệm thu với người dùng thật
- CI/CD
- Tích hợp liên tục và triển khai liên tục: tự động kiểm tra và đưa code lên môi trường chạy
- DORA
- Chương trình nghiên cứu về hiệu quả giao phần mềm, nổi tiếng với các báo cáo thường niên
Đọc thêm
- DORA: nghiên cứu về năng lực giao phần mềm và vai trò của AI.
- Spec-driven development06-04: cách vòng đời được nén lại khi lấy spec làm nguồn sự thật.
- Các giai đoạn trưởng thành của phần mềm13-01: mức đầu tư phù hợp cho prototype, MVP, sản phẩm, nền tảng.
- Playbook từ ý tưởng đến sản phẩm vận hành14-01: toàn bộ vòng đời cô đọng thành sổ tay.
Nghiệm thu tờ 00-03
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
