Quy trình làm việc với agent: tool, flow, đối tượng và chỗ người phải đứng

00Câu hỏi gốc

Đang có nhiều CLI cho agent (mgctl, cpctl, wsctl, deskctl, minigate, rt) và nhiều flow test khai báo. Muốn tối ưu lại để tái dùng cho dự án sau. Chuỗi câu hỏi đã đi qua:

1. Cách đưa tool cho AI qua CLI và định nghĩa flow có phải hướng đi hợp lý so với cộng đồng không?
2. Ngoài tool, các đối tượng khác (env, role, flow, step, fixture, report…) tổ chức thế nào?
3. Các đối tượng đó định nghĩa ở đâu, có cần structure không?
4. Có nên sửa tool ngay trong lúc test / debug sản phẩm không?
5. Người nên tham gia ở bước nào?
6. Quy trình của cả dự án nên chia pha ra sao: nháp trước rồi lặp hồi quy đến khi khách ổn?
7. Khi làm việc với agent, tôi bắt đầu ở đâu: theo nguyên lý, và theo thư mục nào của dự án?

01Hiện trạng tóm tắt

Có 6 CLI và 4 “engine flow” khác nhau cùng một ý tưởng (flow JSON gồm steps, params, expect, shot, dùng testenv) nhưng mỗi cái tự viết schema và runner riêng. Code dùng chung bị chép tay giữa repo: find-common.js giống hệt ở 3 repo, schema.js giống ở desktop và mobile, util.js mỗi repo một bản, testenv.js và mgctl.js lệch dần.

• wsctl e2e đã rò rỉ ra JS. 473 bước eval và 325 sleep nghĩa là DSL không đủ diễn đạt, người viết nhảy xuống code và chờ cứng.
• minigate flow thực chất là shell script dạng JSON. Tốt cho agent (mỗi bước chạy tay được) nhưng không có lớp step nên 281 lần input tap dính thẳng vào testid.
• mgctl flow là lớp khác hẳn. Không chạm UI, chỉ điều phối vai trò, params, flow con, gọi CLI khác, lưu kết quả. Đây là lớp đáng giữ nhất.

Phần làm tốt và nên giữ: config + .local.json, testenv theo vai trò, mgctl api đăng nhập như app, bộ data + .runs báo cáo, doctor, quy ước testid module.screen.element dùng chung desktop và mobile.

02Hướng đi có hợp lý so với cộng đồng?

Có. “CLI cho AI + flow khai báo + testenv theo vai trò + bằng chứng mỗi lần chạy” là dòng chính 2025–2026.

• CLI thay vì tool-call / MCP. Anthropic (bài “code execution with MCP”) và OpenAI Codex đều chỉ ra: agent gọi lệnh rồi tự đọc output tiết kiệm token và dễ ghép hơn nạp hàng chục tool definition. Vercel ra agent-browser dạng CLI vì lý do này.
• Test như dữ liệu. Maestro (mobile) dùng YAML flow: tapOn, assertVisible, runFlow con. Cấu trúc flow JSON của MiniGate gần như song song.
• Progressive disclosure cho agent. help ngắn, _doc trong config, skill, doctor: đã có.
• Evidence và reproducibility. Bộ data + .runs khớp xu hướng.

Chỗ cộng đồng làm khác

1. Tránh DSL tự chế khi đã có sẵn. Maestro, Playwright, WebdriverIO có format ổn định, agent biết sẵn cú pháp. DSL riêng nên mỏng: giữ lớp nghiệp vụ, uỷ lớp tương tác cho engine chuẩn. Bốn runner tự viết là đi hơi xa.
2. Một lệnh một việc, in JSON. --json, stdout là kết quả, stderr là log, exit code có nghĩa, không hỏi khi không có TTY. mgctl đã theo, rt (menu + xác nhận) thì chưa.
3. Test chính tool. Ai test runner? Mobile có 2 file test, còn lại không.
4. Flaky là bài toán chính. Auto-wait, retry, trace là nơi Maestro / Playwright đầu tư nhiều nhất và DSL riêng phải tự gánh.

03Flow riêng so với Maestro và Playwright

Giữ gì, uỷ gì

Giữ (lớp nghiệp vụ, không ai có): testenv theo vai trò, as / needs, tài khoản bảo vệ, tiền tố [E2E] và dọn dữ liệu; mgctl flow làm bộ điều phối; lệnh đơn cho agent (api, shot, inspect, doctor); quy ước testid.

Uỷ cho engine ngoài (lớp tương tác): web và Electron → Playwright, bước UI dịch 1:1 hoặc bước playwright: <spec> để mgctl flow gọi rồi thu report. Mobile → Maestro cho input / expect, giữ app, shot, net, biometric, notif, log của minigate; hai máy thì mgctl flow điều phối 2 Maestro.

04Các đối tượng ngoài tool

Tool là động từ, các đối tượng là danh từ, và danh từ quyết định tái sử dụng được hay không. Xếp theo hai trục: thuộc về ai (mọi dự án, một dự án, một repo, một máy, một lần chạy) và đổi nhanh hay chậm.

Quan hệ giữa các đối tượng

flow ──needs──▶ role ──resolve qua──▶ env ──đọc──▶ secret
 │                                      │
 ├──use──▶ step ──dùng──▶ testid (quy ước)
 ├──with──▶ fixture
 ├──chạy trên──▶ profile (máy)
 └──nhận──▶ dataset ──sinh ra──▶ run / evidence

• Flow không chứa URL, tài khoản, đường dẫn máy. Chỉ tên vai trò và tên fixture.
• Step là nơi duy nhất biết testid. UI đổi testid thì sửa một chỗ.
• Dataset tách khỏi flow để một flow chạy nhiều đợt, mỗi đợt có .runs riêng.

Quyết định tổ chức cụ thể

• Một bảng vai trò cho toàn hệ thống; mobile cần 2 máy thì ánh xạ A → chat1, B → chat2.
• Đặt tên flow theo module/hành-vi, không theo thiết bị. 4 flow chat-hai-nguoi-0..3 nên là 1 flow mgctl gọi 4 bước trên 2 vai.
• Tag (smoke, that, quyen, hoi-quy) thay cho hậu tố tên file.
• Fixture bất biến; thứ flow tạo ra mang [E2E] {run.id} và có bước dọn.
• Mỗi run ra một report.json cùng schema dù bước chạy bằng engine nào.
• Mỗi thư mục flows / steps / fixtures có README ngắn; skill chỉ trỏ tới, không chép.

05Định nghĩa ở đâu, có schema không

Schema tập trung trong kit, nội dung phân tán theo chủ sở hữu; có structure cho mọi thứ máy đọc, không cần cho thứ chỉ người và agent đọc.

Hiện đã có tầng 2, 3, 4. Thiếu tầng 1: schema đang nằm trong repo app nên mỗi repo một bản. Đưa schema lên kit là thay đổi cấu trúc duy nhất cần làm. Mỗi file instance khai "$schema", runner validate lúc load.

• Schema phải có version và lệnh migrate, nếu không kit đóng băng.
• Mở rộng có kiểm soát: additionalProperties:false ở khung, cho phép x-<repo>-* hoặc with tự do trong bước.
• Kit là repo riêng, không phải thư mục trong common, vì common chứa secrets và dữ liệu MiniGate.

mg-cli-kit/                      # tầng kit
  schemas/ env · role · flow · step · report · profile · config
  conventions.md
  template/                      # mgctl init-cli sinh từ đây

common_minigate/                 # tầng dự án
  config/test-env.json  config/profiles/  flows/<module>/  secrets/test-env/

<repo>/cli/                      # tầng repo
  steps/<module>.json  flows/<module>/*.json  fixtures/ + fixtures.json  config/<lệnh>.json

work/<ngày>/<tác vụ>/            # ngoài repo
  env.json  params.json  .runs/<id>/report.json

06Sửa tool trong lúc test / debug sản phẩm

Nên, nhưng phân tầng. Nhu cầu thật về tool chỉ lộ ra khi đang test; cấm sửa là tự bịt nguồn phát hiện. Hai rủi ro cần chặn: nhiễm kết quả (pass vì sản phẩm đúng hay vì tool vừa đổi cách đo; agent có xu hướng nới expect, tăng timeout, thêm sleep) và trôi thiết kế (mỗi lần kẹt thêm một ngoại lệ).

Ba kỷ luật

1. Tách commit và tách run. Sửa tool xong chạy lại từ sạch; report có field toolVersion.
2. Sửa tool chỉ được chặt hơn hoặc rộng hơn, không lỏng hơn. Nới ngưỡng, bỏ assert, thêm sleep là che lỗi; ghi gap thay vì sửa. Đưa vào skill / CLAUDE.md cho agent.
3. Mỗi lệnh sửa có một check đi kèm trong doctor hoặc test của CLI.

Nhịp: trong sprint sửa tầng 1 thoải mái, tầng 2 khi kẹt, tầng 3 chỉ ghi gap. Cuối đợt đọc gaps, gom cái lặp từ 2 repo trở lên lên kit. Test / debug là nơi phát hiện nhu cầu tool, không phải nơi thiết kế tool.

07Người đứng ở đâu

Người ở chỗ đặt ý định và chỗ phán xét; agent ở chỗ thực thi và thu thập. Bốn cổng người bắt buộc đứng, mọi chỗ khác agent tự chạy:

• Người xem ở mức tóm tắt. Phải mở từng ảnh hoặc đọc log thô là tool chưa đạt. Mục tiêu: vài phút cho một đợt vài chục flow.
• Sự tham gia giảm dần theo độ chín. Flow mới xem kỹ lần đầu xanh, sau chỉ xem khi fail. Tool mới review lúc lên kit, sau tin doctor.

08Quy trình một tính năng (hoặc một request)

• Bước 3 trước bước 4 là thay đổi lớn nhất: tiêu chí nghiệm thu được máy hoá trước khi code.
• Bước 2 cho phép song song backend và client trên spec + mock.
• Người chỉ xuất hiện ở 1, 3 (lần đầu), 5, 6, 7.
• Ba điểm ép: không có goal và danh sách flow thì không vào bước 4; report là đầu vào duy nhất cho deploy; flow đã dùng nghiệm thu tự thành hồi quy.
• Sửa lỗi nhỏ: 1 (mô tả + cách tái hiện) → 3 (một flow tái hiện, phải đỏ) → 4 → 5.

09Quy trình cả dự án

“Nháp → hồi quy → fix → lặp đến khi khách ổn” về cơ bản đúng, với agent càng đúng vì code nháp rẻ. Ba chỗ hay vỡ: “khách thấy ổn” không phải điều kiện dừng; nháp bị khoá thành kiến trúc (rủi ro lớn nhất khi dùng agent); hồi quy phình không kiểm soát. Giữ vòng lặp nhưng đặt vào 5 pha có điều kiện ra.

• Khách tham gia hai lần với hai câu hỏi khác nhau: pha 1 “đây có phải thứ anh muốn không”, pha 3 “đây có chạy đúng như đã chốt không”. Trộn hai câu là lý do vòng lặp không kết thúc.
• Pha 0 và 1 khoảng 20% thời gian, pha 2 là phần lớn.

10Nơi bắt đầu khi làm việc với agent

Theo nguyên lý

Bắt đầu bằng định nghĩa “xong là gì”, viết xuống ở một chỗ tồn tại lâu hơn cuộc trò chuyện. Agent làm tốt phần “làm thế nào” và kém phần “đúng là gì”. Bắt đầu bằng mô tả cách làm là làm thay agent việc nó giỏi và bỏ trống việc chỉ người làm được. Bắt đầu trong chat thì ý định mất khi phiên kết thúc, phiên sau agent lại đoán.

Một việc nên là một request lưu lại, khoảng 5 dòng: title, goal, roles, không được, nghiệm thu (tên flow + tag). Steps, expect, fixture, spec, code là việc của agent. Thấy mình đang viết bước thao tác hay chọn tool là đã đi xuống tầng của agent.

Theo thư mục

Mở phiên ở thư mục trung tâm của dự án, đứng ngoài mọi repo (với MiniGate là ~/work), không mở trong một repo.

• Tiêu chí và phán xét cắt ngang nhiều repo; bắt đầu trong repo là tự giới hạn tầm nhìn theo ranh giới code.
• Bộ data và bằng chứng (work/<ngày>/<tác vụ>/, .runs) nằm ở đây, không trong repo.
• Memory của agent gắn với thư mục khởi động; một chỗ cố định thì tích luỹ, đổi thư mục là đổi bộ nhớ.
• Bản đồ repo đã nạp sẵn, agent tự vào repo khi làm; chiều ngược lại không có.

Chỉ mở trong repo khi việc nằm trọn trong repo đó và cần ngữ cảnh riêng (CLAUDE.md, skill, quy tắc store). Đó là phiên “làm” của agent theo request, không phải phiên người đặt tiêu chí. Hai loại phiên tách nhau.

Thư mục trung tâm cần ba thứ: nơi viết ý định (todo / request), nơi chứa bộ data và kết quả chạy, nơi đọc lại (notes, review). Nên có một CLAUDE.md tại đó nói rõ “đây là bàn làm việc, bắt đầu bằng đọc bằng chứng hôm qua rồi mới nhận việc mới”. Dự án sau giữ nguyên nguyên tắc: một thư mục bàn làm việc ngoài mọi repo, chứa bản đồ repo, bộ data, bằng chứng, ghi chú.

11Việc còn mở để nghĩ tiếp

Mục tiêu đã nêu: tối ưu quy trình làm việc nhóm để chủ dự án không phải tham gia quản lý nhiều. Những quyết định còn chờ:

1. DSL flow dừng ở lớp nào? Uỷ hẳn lớp tương tác cho Playwright / Maestro, hay phương án giữa (chuẩn hoá schema step, thêm auto-wait)? Bắt đầu từ wsctl e2e.
2. Flow JSON thuần hay cho phép JS? Đề xuất JSON thuần, logic ở driver.
3. Kit là repo riêng? Đề xuất có, common là consumer đầu tiên.
4. Schema report.json là gì, đủ để người đọc vài phút một đợt? Đây là điểm nối cho mọi thứ còn lại, nên làm sớm.
5. Ai giữ cổng nào khi nhóm lớn hơn một người: cổng ý định và phán xét có thể giao cho PO / QA, cổng dữ liệu thật và kit nên giữ ở người vận hành. → Trả lời ở mục 14 và 15.
6. Thứ tự chuyển: deskctl → minigate → wsctl e2e (theo độ gần với mgctl flow), hay wsctl e2e trước (theo mức rò rỉ)?
7. Template request hiện chỉ có title; thêm goal / roles / không được / nghiệm thu và chặn vào bước làm khi thiếu goal hoặc nghiệm thu.
8. CLAUDE.md tại thư mục trung tâm mô tả vòng ngày (đọc bằng chứng → phán xét → giao việc).
9. Kiểm kê bước 1: bảng lệnh nào thuộc lõi hay dự án, trùng ở đâu, để quyết phạm vi kit trước khi thiết kế API.

12Đối chiếu với các phương pháp cộng đồng đánh giá cao

Mục tiêu thật của ghi chú này không phải tối ưu hiện trạng mà là tìm một quy trình thực hiện dự án tận dụng tối đa agent. Chưa có quy trình thống nhất, đang tự đúc rút. Đối chiếu với các nguồn được trích dẫn nhiều nhất 2025–2026 cho thấy hướng đi ở các mục trên đã rất gần đồng thuận, ở ba điểm:

• “Xong là gì” viết ra chỗ bền hơn cuộc trò chuyện chính là tinh thần của spec-driven development: spec phải nằm trong repo, không thì mục nát.
• Bốn cổng người gần với cách HumanLayer khuyên đội nhóm: review plan, không chỉ review code.
• CLI cho AI, mỗi lệnh một việc, xuất JSON, exit code rõ khớp với bài “Writing tools for agents” của Anthropic. Đội của họ tốn thời gian tối ưu tool nhiều hơn tối ưu prompt.

Gợi ý cụ thể

1. Thêm pha nghiên cứu trước hợp đồng. Agent đọc code, truy vết luồng dữ liệu, ghi research.md. Đây là bước có đòn bẩy cao nhất đang bị bỏ qua.
2. Phân tầng việc theo kích cỡ. Bug có repro rõ thì làm thẳng. Việc chạm nhiều file thì plan mode cộng test. Tính năng mới thì đủ bộ research, spec, plan, tasks. Chi tiết ở mục 13.
3. Chuẩn hoá thư mục mỗi tính năng trong repo: research.md, spec.md, plan.md, tasks.md. Request 5 dòng ở mục 10 thành phần đầu của spec.
4. Tách CLAUDE.md thành ba lớp. Quy ước ngắn trong CLAUDE.md, quy tắc chi tiết trong rules, thứ bắt buộc làm hook. “Report là đầu vào duy nhất cho deploy” nên là hook chặn, không nên là câu dặn.
5. Mỗi task một phiên sạch. Xong một task thì ghi tiến độ vào tasks.md, commit, phiên mới đọc lại từ file. Giải bài “một ngày đọc bằng chứng hôm qua trước”.
6. Vòng lặp kiểu Ralph cho pha ổn định. Pha 3 chỉ sửa không thêm, tiêu chí là flow xanh: bài toán lý tưởng để chạy loop qua đêm với ngân sách lượt chạy.
7. Gaps thành bộ nhớ của agent. Đầu ra của bước gom gaps là cập nhật rules hoặc AGENTS.md, không chỉ là danh sách chờ sửa tool.
8. Đo tool bằng eval. Bộ việc mẫu cho kit, đọc transcript, sửa thông báo lỗi.

Khung thống nhất tối thiểu

Bước tiếp theo hợp lý: chọn một tính năng thật, chạy đủ khung này một lần, ghi lại chỗ bị cản rồi chỉnh.

13Hồ sơ theo loại task

Câu hỏi: các loại task khác nhau (tạo tính năng, fix bug, tối ưu UI/UX…) có nên là các quy trình khác nhau không? Nên khác, nhưng khác ở cổng và bằng chứng, không khác ở khung. Mỗi loại task một quy trình riêng thì đội không nhớ nổi và agent không có một file quy tắc chung để đọc. Cách hợp lý là một bộ khung với các cổng bật tắt được; mỗi loại task là một hồ sơ chọn cổng nào bật.

Khung chung giữ nguyên bốn thứ: hợp đồng viết ra trước khi làm, bằng chứng do máy sinh ra, người giữ cổng ở đúng chỗ, bài học gom về rules. Thứ thay đổi theo loại task là ba câu hỏi: hợp đồng là gì, bằng chứng là gì, người đứng ở cổng nào.

Phân loại theo hai trục chứ không theo tên task: độ mơ hồ của “đúng là gì” và phạm vi ảnh hưởng. Fix bug có repro rõ: mơ hồ thấp, phạm vi hẹp. Tính năng mới: mơ hồ cao, phạm vi rộng. Tối ưu UI/UX: mơ hồ cao nhưng phạm vi hẹp, nên cần hồ sơ riêng. Tên task chỉ là nhãn tiện gọi.

Bảy loại gặp nhiều nhất

• UI/UX là loại duy nhất mà hợp đồng chữ không đủ. Tiêu chí kiểm thử được gần như không viết nổi cho “nhìn thoáng hơn”. Vòng lặp phải ngắn: agent sửa, chụp ảnh, người nhìn, nói một câu, lặp. Thứ cần chặt là danh sách không được phá và flow hồi quy giữ chức năng nguyên vẹn.
• Fix bug cấm bắt đầu khi chưa có repro đỏ. Điểm ép tương đương “không có goal thì không code” của tính năng. Agent rất hay sửa triệu chứng nếu không bị buộc tái hiện trước.
• Refactor và hiệu năng chung một nguyên tắc: hành vi không đổi, bằng chứng là bộ hồi quy hiện có. Hồi quy chưa đủ phủ thì việc đầu tiên là bổ sung flow, chưa được chạm code.
• Một task có thể đổi hồ sơ giữa chừng. Bug nhỏ truy ra lỗi thiết kế thì dừng, chuyển sang hồ sơ tính năng hoặc spike. Cần quy ước cho agent nói rõ “việc này vượt hồ sơ” thay vì cố làm tiếp.

Sự cố và vận hành

Dữ liệu và hợp đồng giao tiếp

Chất lượng và dọn dẹp

Sản phẩm và nội dung

Nền và meta

14Chia người theo cổng, không theo chức danh hay loại task

Câu hỏi: nên chia người theo vai cũ (PM, dev, QA…), theo ai thực hiện loại task nào, hay cách khác? Chia theo cổng mà họ chịu trách nhiệm.

• Chia theo vai cũ là chia theo năng lực sản xuất. Khi agent làm phần lớn việc sản xuất, cái khan hiếm là người hiểu đúng là gì, người phán xét bằng chứng, người chịu trách nhiệm khi sai. Giữ vai cũ thì dev thành người ngồi nhìn agent, QA thành người chạy lại thứ agent đã chạy.
• Chia theo loại task còn tệ hơn, vì loại task là thuộc tính của việc, không phải của người. Người “chuyên fix bug” không có context module nào, trong khi context module mới quyết định chất lượng khi điều khiển agent.

Cách hợp lý hơn là hai trục: trục ngang là cổng, trục dọc là module.

Trục cổng: năm vai

Bốn vai đầu là vai giữ cổng, số người ít, không phụ thuộc loại task. Vai thứ năm là vai sản xuất mới, đông nhất, phân theo trục dọc.

Trục module

Mỗi người lái agent sở hữu một hoặc vài module và làm đủ mọi loại task trên module đó. Loại task chỉ quyết định hồ sơ nào bật, tức phải ghé cổng nào. Fix bug ở module thanh toán thì người lái thanh toán làm, qua cổng chủ bằng chứng. Tính năng mới cùng module vẫn người đó, qua thêm cổng chủ ý định, và cổng chủ kit nếu động vào schema.

Kết quả là một bảng phân công gọn: hàng là loại task, cột là cổng, ô là ai phải ký. Người lái nhìn hồ sơ là biết gõ cửa ai, không cần họp.

• Đội nhỏ thì một người đội nhiều mũ, nhưng phải nói rõ đang đội mũ nào khi đứng ở cổng. Hiện chủ dự án là chủ ý định kiêm chủ kit kiêm chủ vận hành. Ghi ra để khi đội lớn lên tách mũ mà không phải vẽ lại quy trình. Đây là câu trả lời cho câu hỏi mở số 5 ở mục 11.
• Tách người viết request và người phán xét kết quả với task phạm vi rộng. Người viết spec rất dễ nhìn thấy cái mình muốn thấy.
• QA không biến mất mà đổi chất. Chủ bằng chứng là vai tăng giá trị nhất, vì toàn bộ niềm tin vào agent đứng trên chất lượng của flow và report. Tham gia từ lúc viết spec để tiêu chí nghiệm thu kiểm thử được.
• Agent cũng có vai, nhưng theo context chứ không theo chức danh. Agent nghiên cứu, agent thực thi, agent review là ba phiên tách biệt để agent review không thiên kiến bởi code nó viết. Không cần mô phỏng cả đội agile kiểu BMAD, vì phần phán xét vẫn là người.
• Chuyển người từ vai cũ theo thế mạnh sẵn có. Dev giỏi hệ thống sang chủ kit. Dev giỏi nghiệp vụ lái module lớn. QA giỏi thiết kế case sang chủ bằng chứng. Người thích vận hành giữ cổng vận hành.

15Phòng ban theo vai hay theo dự án

Theo dự án cho phần giao hàng, theo vai chỉ cho những thứ phải sống lâu hơn dự án. Mô hình lai, nhưng ranh giới đặt theo câu hỏi “thứ này có cần tồn tại sau khi dự án kết thúc không”, không theo chức danh.

Thời agent làm lệch cán cân so với trước ở ba chỗ:

• Chi phí bàn giao giữa người thành chi phí lớn nhất. Agent viết code trong vài phút thì một ngày chờ phòng QA hay phòng design xếp lịch là vô lý. Phòng ban theo vai sinh hàng đợi, hàng đợi giết tốc độ của agent. Chủ ý định, chủ bằng chứng, người lái phải ngồi trong dự án.
• Đòn bẩy lớn nhất nằm ở kit và quy ước. Một cải tiến tool cho agent, schema flow hay rules có lợi cho mọi dự án cùng lúc. Để kit trong từng dự án thì bị chép tay giữa repo, đúng tình trạng ở mục 1. Cần một chủ sở hữu sống lâu hơn bất kỳ dự án nào.
• Dữ liệu thật và secret cần ít tay chạm. Mỗi dự án tự giữ secret là mỗi dự án một lỗ hổng.

Gần với kiểu squad cộng chapter, nhưng đơn vị nền tảng ở đây có sản phẩm thật là kit, khách hàng thật là các dự án, thước đo thật là số gap đóng được mỗi đợt.

Tỷ lệ nhân sự tham khảo: một dự án vừa cần khoảng một chủ ý định, một chủ bằng chứng, hai đến năm người lái. Đơn vị kit một đến ba người phục vụ nhiều dự án, vì việc của họ là sửa tool theo đợt, không trả lời yêu cầu hằng ngày.

16Sơ đồ tổ chức và luồng gap

Hai đơn vị dùng chung ở trên, các dự án ở dưới. Kit đi xuống theo version, gap đi lên theo đợt, report đi sang cổng vận hành để deploy. Đường đứt nét ngang là cộng đồng theo vai, không có quyền điều phối.

Đọc sơ đồ theo một vòng: dự án lấy kit theo version → người lái làm task theo hồ sơ → bằng chứng sinh ra → chủ bằng chứng và chủ ý định phán xét → report xanh đi sang cổng vận hành để deploy → chỗ nào kit cản thì ghi gap → đơn vị kit gom gap theo đợt, ra version mới → dự án pin version mới khi sẵn sàng.