Khảo sát và yêu cầu
Làm rõ vấn đề, người dùng, ràng buộc, phạm vi và tiêu chí nghiệm thu.
G-ADD · GENKI AI-DRIVEN DELIVERY
Phát triển phần mềm với AI.Con người kiểm soát chất lượng.
G-ADD là cách Genki đưa AI vào dịch vụ phát triển phần mềm, từ yêu cầu đến kiểm thử và bàn giao. Con người phê duyệt các bước quan trọng. Hiệu quả được đánh giá bằng kết quả nghiệm thu, chất lượng và tổng công sức, không chỉ tốc độ viết mã.
G-ADD không phải hệ thống tự vận hành và không thay thế trách nhiệm của con người.
Luồng delivery có checkpointCó phê duyệt của con người
- 01Yêu cầuPhạm vi · Con người phê duyệt
- 02Kế hoạch
- 03Phát triểnThay đổi quan trọng · Con người phê duyệt
- 04Kiểm thửTest case · Con người phê duyệt
- 05Review
- 06Bàn giaoKết quả · Con người phê duyệt
xác minhđặc tả · kiểm thử · dấu vết
Video giới thiệu
G-ADD trong 3 phút
Video giải thích vì sao một task coding nhanh hơn không đồng nghĩa dự án nhanh hơn, và cách G-ADD quản lý effort, chất lượng cùng trách nhiệm phê duyệt.
Nhìn toàn hệ thống
Một task nhanh hơn không tự động làm cả dự án nhanh hơn
Dự án phần mềm không chỉ có coding. Công việc còn bao gồm hiểu yêu cầu, căn chỉnh scope, thiết kế, review, test, bảo mật, tích hợp, phối hợp và nghiệm thu.
Thiết kế
Căn chỉnh luồng, dữ liệu, kiến trúc, đánh đổi và xử lý ngoại lệ.
Coding
Tạo thay đổi kỹ thuật theo đặc tả. Đây chỉ là một phần của tổng effort.
Review và kiểm thử
Đối chiếu code với đặc tả; kiểm tra hành vi, bảo mật và tích hợp.
Phối hợp
Chờ quyết định, quản lý phụ thuộc, phối hợp vai trò và truyền đạt thay đổi.
Phát hành và bàn giao
Nghiệm thu, tài liệu, phát hành thủ công và chuyển giao trách nhiệm.
Khi coding tăng tốc, nút thắt có thể chuyển sang review, test và tích hợp.
Minh họa tổng effort
Coding nhanh gấp 2 hoặc 10 lần — toàn dự án thay đổi thế nào?
Baseline
Coding nhanh gấp 2 — điều kiện lý tưởng
Coding nhanh gấp 2 — thêm 10 ngày review hoặc rework
Coding nhanh gấp 2 — thêm 20 ngày review hoặc rework
Coding nhanh gấp 10 — điều kiện lý tưởng
BaselineĐiều kiện lý tưởng · họa tiết chéoReview hoặc rework phát sinhVượt baseline · cảnh báo
| Kịch bản | Tổng ngày công | Giải thích |
|---|---|---|
| Baseline | 100 | Mốc tham chiếu của biểu đồ. |
| Coding nhanh gấp 2 — điều kiện lý tưởng | 85 | Coding giảm từ 30 xuống 15 ngày công; phần việc khác không đổi. |
| Coding nhanh gấp 2 — thêm 10 ngày review hoặc rework | 95 | Review và rework bù lại một phần effort đã giảm. |
| Coding nhanh gấp 2 — thêm 20 ngày review hoặc rework | 105 | Cảnh báo: tổng effort vượt baseline 5 ngày công. |
| Coding nhanh gấp 10 — điều kiện lý tưởng | 73 | Coding giảm từ 30 xuống 3 ngày công; phần việc khác không đổi. |
100 xuống 85 ngày công
Toàn dự án khoảng 1,18 lần trong điều kiện lý tưởng100 xuống 73 ngày công
Toàn dự án khoảng 1,37 lần trong điều kiện lý tưởngNếu coding chiếm 30% tổng effort, tăng tốc coding không thể tăng tốc toàn dự án theo cùng tỷ lệ. Phần việc còn lại vẫn tồn tại.
Các số liệu minh họa giới hạn của tối ưu cục bộ. Kết quả thực tế phải được đo theo baseline của từng dự án.
WORKLOAD VÀ CHẤT LƯỢNG
Khi tốc độ tạo code vượt quá năng lực kiểm soát
Code được tạo nhanh hơn có thể làm workload chuyển sang review, kiểm thử và tích hợp. Nếu yêu cầu chưa rõ hoặc test không phản ánh đúng đặc tả, task có thể hoàn thành nhanh nhưng feature vẫn chưa sẵn sàng để nghiệm thu.
AI chỉ tập trung sinh code
- Yêu cầu còn mơ hồ
- Code đến review quá nhanh
- Test xác nhận code thay vì xác nhận spec
- Rework xuất hiện muộn
- Technical debt tăng
- Chất lượng có nguy cơ giảm
AI trong workflow G-ADD
- Scope được làm rõ
- Test case được duyệt
- Expected output được khóa
- Code được so sánh với spec
- Adversarial Review tìm khoảng trống
- Definition of Done kiểm soát hoàn thành
- Reasoning Trace ghi quyết định
G-ADD bổ sung điểm kiểm soát. G-ADD không bảo đảm loại bỏ mọi lỗi hoặc rủi ro.
Ví dụ feature
Code có thể đúng kỹ thuật nhưng sai nghiệp vụ
API trả về khung giờ tư vấn còn trống
Yêu cầu ban đầu: Tạo endpoint nhận ngày và mã tư vấn viên, sau đó trả về danh sách khung giờ còn trống để người dùng đặt lịch.
GET /consultants/:id/available-slots?date=...Câu hỏi cần làm rõ trước khi chốt đặc tả
- Dùng múi giờ nào?
- Hai người đặt cùng lúc thì sao?
- Lịch nghỉ được xử lý thế nào?
- Thử lại có tạo booking trùng không?
- Ai có quyền thay đổi lịch?
- Khung giờ đã qua được xử lý thế nào?
- Thông báo lỗi có ảnh hưởng booking không?
Tốc độ sinh code không thay thế việc làm rõ nghiệp vụ và xác định tiêu chí nghiệm thu.
11 bước có kiểm soát
G-ADD đưa AI vào đúng luồng delivery
AI tạo cấu trúc và đề xuất. Con người phê duyệt quyết định quan trọng, kiểm tra đầu ra và chịu trách nhiệm cuối cùng.
- 01Checkpoint
Làm rõ yêu cầu
- AI
- Tổng hợp câu hỏi, mâu thuẫn và phần còn thiếu.
- Con người
- Xác nhận nghiệp vụ và nguồn đúng.
- Đầu ra
- Yêu cầu đã làm rõ.
- 02Phê duyệt scope
Xác định scope
- AI
- Đề xuất phạm vi, giả định và phần loại trừ.
- Con người
- Phê duyệt scope và ưu tiên.
- Đầu ra
- Scope được chốt.
- 03
Tạo WBS và kế hoạch
- AI
- Phân rã công việc, phụ thuộc và effort dự kiến.
- Con người
- Chỉnh thứ tự, người phụ trách và ràng buộc.
- Đầu ra
- WBS và kế hoạch.
- Các bước từ 4 trở đi được lược bớt trong phần giới thiệu này.
Nguyên tắc vận hành
Năm trụ cột kiểm soát
Một task, một phiên
Mỗi phiên có mục tiêu, vai trò, kế hoạch và sản phẩm bàn giao cụ thể.
Định nghĩa hoàn thành và kiểm thử trước
Chốt tiêu chí hoàn thành và test case theo đặc tả trước khi triển khai.
Bất biến kiểm thử
Expected output đã duyệt không được sửa chỉ để code pass. Nếu đặc tả chưa rõ, quy trình quay lại bước phê duyệt.
Review phản biện và review độc lập
Chủ động tìm tình huống test chưa bao phủ. Task rủi ro cao có thể dùng reviewer với ngữ cảnh độc lập.
Dấu vết lập luận
Ghi trạng thái hoàn thành, deliverable, quyết định, lý do, effort và vấn đề để bàn giao và cải tiến.
Đo đúng phạm vi
Đo kết quả delivery, không chỉ đo tốc độ coding
Thông lượng task
- Thời gian coding
- Số task hoàn thành
- Số dòng code hoặc thay đổi
- Thời gian từ bắt đầu đến code complete
Kết quả delivery
- Tổng effort theo giai đoạn
- Thời gian review và test
- Số vòng rework
- Defect trước nghiệm thu
- Defect sau nghiệm thu
- Tỷ lệ task đạt tiêu chí lần đầu
- Thời gian chờ phê duyệt
- Số thay đổi scope
- Feature đã tích hợp và nghiệm thu
Một task được code xong chưa được coi là kết quả delivery nếu chưa đạt tiêu chí hoàn thành.
Dịch vụ phát triển với AI, không chỉ cung cấp công cụ
G-ADD phù hợp với doanh nghiệp muốn đánh giá việc sử dụng AI trong một phạm vi phát triển phần mềm cụ thể, có người duyệt yêu cầu và nghiệm thu. AI hỗ trợ tạo đầu ra; con người kiểm tra, phê duyệt và chịu trách nhiệm trong quy trình. Đây không phải lời hứa xây dựng chatbot hoặc mô hình AI cho mọi nhu cầu.
Nếu chưa làm rõ yêu cầu, chưa có dữ liệu được phép sử dụng hoặc chưa xác định người nghiệm thu, cần giải quyết các điều kiện này trước khi bắt đầu. AI không thay thế việc thống nhất phạm vi và trách nhiệm.
Bảo mật mã nguồn và dữ liệu cần được thống nhất trước
Trước khi dùng AI trong dự án, hai bên cần xác nhận công cụ được phép dùng, dữ liệu được phép xử lý, quyền truy cập và yêu cầu lưu trữ. Điều kiện phụ thuộc công cụ, cấu hình và thỏa thuận dự án; không mặc định mọi dịch vụ AI có cùng chính sách.
- Xác định mã nguồn, tài liệu và dữ liệu nào được phép cung cấp cho công cụ.
- Ưu tiên dữ liệu giả lập hoặc đã xử lý phù hợp; không đưa mật khẩu hay khóa truy cập vào yêu cầu.
- Kiểm tra điều khoản lưu trữ, sử dụng dữ liệu và bên thứ ba trước khi cấp quyền.
- Thống nhất người phê duyệt, cách thu hồi quyền và đầu mối xử lý sự cố.
Đánh giá G-ADD trước khi quyết định
Kiểm soát chất lượng mã do AI tạo
Đối chiếu hạng mục kiểm tra, bằng chứng nghiệm thu và người xác nhận.
Bảo vệ mã nguồn và dữ liệu khi dùng AI
Phân loại dữ liệu, xác nhận quyền sử dụng và lưu bằng chứng phê duyệt.
Đo hiệu quả phát triển phần mềm với AI
Dùng mẫu ghi nhận và ví dụ tính giờ công tiết kiệm sau rà soát, sửa lỗi.
Thử nhỏ, đo đủ
Bắt đầu bằng một pilot có kiểm soát
Phạm vi đề xuất
- Một feature nhỏ
- Một sprint hoặc chu kỳ delivery ngắn
- Repo sandbox hoặc dữ liệu được phép sử dụng
- Baseline được thống nhất trước
- Người phê duyệt scope, test case và kết quả được xác định rõ
Thống nhất đầu ra và cách đánh giá trước khi thử
Phạm vi thử nghiệm đề xuất gồm một chức năng có giới hạn rõ, dữ liệu được phép sử dụng và người có quyền nghiệm thu. Đầu ra cần thỏa thuận gồm yêu cầu, mã nguồn trong phạm vi, kết quả kiểm thử, vấn đề còn tồn tại và báo cáo công sức thực tế.
Thời gian, chi phí, quyền bàn giao và khả năng tiếp nhận được xác nhận sau khi trao đổi. Đây không phải gói miễn phí hoặc cam kết tiết kiệm cố định. Gửi biểu mẫu là đề nghị trao đổi, chưa phải xác nhận bắt đầu thử nghiệm.
Chỉ mở rộng khi đầu ra đạt tiêu chí chất lượng, không vi phạm yêu cầu dữ liệu và có kết quả đủ để đánh giá. Nếu chưa đạt hoặc chưa đủ bằng chứng, thu hẹp phạm vi, điều chỉnh cách làm hoặc dừng thử nghiệm.
- 01Ghi nhận baseline.
- 02Làm rõ yêu cầu và phạm vi.
- 03Tạo đặc tả, WBS và tiêu chí hoàn thành.
- 04Duyệt test case cùng expected output.
- 05Phát triển và review theo đặc tả.
- 06Thực hiện review phản biện.
- 07Kiểm tra tiêu chí hoàn thành và ghi dấu vết lập luận.
- 08So sánh thông lượng task với kết quả delivery.
- 09Ghi phần effort được giảm, dịch chuyển và phát sinh.