Delivery Team ต้องทำอะไร ในวันที่ AI สร้าง Product ได้

10 min read

Delivery Team ต้องทำอะไร ในวันที่ AI Agent สร้าง Product ได้แล้ววันนี้

บทความนี้อธิบาย workflow ที่ทีม Product Delivery ทำงานร่วมกันกับ AI agent เพื่อเตรียม AI-Spec ให้สมบูรณ์ก่อนเริ่ม implement โดยทุก Role รู้หน้าที่ของตัวเองชัดเจนในแต่ละ Phase

AI-Spec คืออะไร

AI-Spec คือชุดไฟล์ที่ทำให้ AI Agent สามารถ implement feature ได้โดยไม่ต้องถาม Human เพิ่ม ประกอบด้วย:

[feature-name]/
├── PLAN.md                        ← สัญญาว่า Feature นี้ทำอะไร + implementation detail
├── CHECKLIST.md                   ← Tasks + Subtasks ที่ tick ได้ทีละขั้น
├── HANDOFF.md                     ← context สำหรับ session ถัดไปเมื่อ AI session เต็ม
└── tests/
    ├── feature-test-scenarios.md  ← E2E / acceptance test ระดับ Feature
    ├── story-N.N-[name].md        ← acceptance criteria ระดับ Story
    └── task-N.N-[type]-[name].md  ← test spec ระดับ Task

AI-Spec สมบูรณ์ = ทุกไฟล์พร้อมก่อนเริ่ม implement — ไม่มีงานค้างให้ Human เตรียมกลางทาง

โครงสร้าง SDLC ที่ใช้

บทความนี้ใช้โครงสร้าง Agile SDLC เป็น foundation — โดย Feature คือ unit ที่เล็กที่สุดที่ deliver business value ได้ครบในตัวเอง ซึ่งเป็นหลักการเดียวกับ User Story Mapping และ Vertical Slicing ใน Agile methodology

System (Project)
└── Epic (Module)
    └── Feature ⭐         ← unit ที่เล็กที่สุดที่ deliver business value ได้ครบในตัวเอง
        └── Story           ← ความสามารถ 1 อย่างภายใน Feature
            └── Task        ← งานระดับ Dev ที่จับต้องได้ [API]/[FE]/[FE-BL]/[Config]/[CHORE]
                └── Subtask ← implementation steps (AI generate)

6 Phases: Human × AI

Phase 1: Define

ใครทำ: PM/PO เป็นหลัก + Tech Lead และ QA รับรู้ตั้งแต่แรก

สิ่งที่ต้องทำ:

  • PM/PO เปิดไฟล์ plan/todos/[feature-name]/PLAN.md ใหม่
  • เขียน 3 ส่วนแรกให้ครบ:
## Goal
[User ได้อะไรจาก Feature นี้ — 2 บรรทัด ภาษา business]

## Scope (ทำ)
| Capability | Story |
|---|---|
| [สิ่งที่ User เห็นและใช้ได้] | TBD |

## Out of Scope (ไม่ทำ)
- [สิ่งที่ defer] → ทำใน `[feature-name]`
- [สิ่งที่ตัดออก] (เหตุผลสั้นๆ)

Tech Lead เพิ่ม Technical Constraint ใน Out of Scope คือสิ่งที่ดูเหมือนทำได้ใน Feature นี้ แต่จริงๆ ต้องรอ infra / dependency / architecture decision

## Out of Scope (ไม่ทำ) — ตัวอย่าง Technical Constraint ที่ Tech Lead เพิ่ม

- Real-time update (WebSocket) → ทำใน `articles-realtime`
  (ต้องเพิ่ม infra ใหม่ ไม่ใช่แค่ code)

- Image optimization pipeline → ทำใน `media-service`
  (ต้องรอ CDN config พร้อมก่อน)

- Server-side caching → ทำใน `performance-phase2`
  (ยังไม่มี Redis instance ใน environment)

- Full-text search → ทำใน `search-feature`
  (DB schema ปัจจุบันยังไม่ support)

Output: PLAN.md shell พร้อมส่งต่อ

Roleหน้าที่
PM / PO ✍️เขียน Goal + Scope + Out of Scope
Tech Lead 👀เพิ่ม technical constraint ใน Out of Scope
QA 👀อ่าน Goal + Scope เพื่อเริ่มคิด acceptance scenario

Phase 2: Expand

ใครทำ: Dev ที่ได้รับ Assignment เป็นคนหลัก + AI Assistant (Chat) ช่วย draft

สิ่งที่ต้องทำ:

  • Dev prompt AI Assistant (Chat) ให้ขยาย PLAN.md shell ให้สมบูรณ์
  • AI Assistant เติม: Current State → Stories → Tasks + implementation detail (= subtasks)
  • Dev review และแก้ให้ตรงกับ implementation ที่ตัวเองจะทำจริง

ทำไม Dev ต้องเป็นคนทำ Phase นี้: Dev ที่ implement เองคือคนที่รู้ implementation detail ดีที่สุด ถ้า Tech Lead เขียนแทน Dev ต้องมาแก้ใหม่ = waste รอบ review โดยไม่จำเป็น

Output: PLAN.md สมบูรณ์พร้อม Stories + Tasks + implementation detail ทุกตัว

Roleหน้าที่
Dev ✍️ 🤝 AI Assistantprompt AI Assistant expand + review implementation detail
Tech Lead 👀review architecture + ตรวจว่า scope ไม่บาน
PM / PO 👀review Scope table — ถูก business intent ไหม
QA 👀review Stories — ครอบคลุม scenario ที่จะ test ไหม

Phase 3: Test Spec

ใครทำ: QA + AI Assistant (Chat) เขียน Story + Feature test / Dev + AI Assistant (Chat) gen Task test

สิ่งที่ต้องทำ:

QA 🤝 AI Assistant gen:
├── tests/feature-test-scenarios.md   ← E2E / business flow ทั้งหมด
└── tests/story-N.N-[name].md         ← acceptance criteria ทุก Story

Dev 🤝 AI Assistant gen:
└── tests/task-N.N-[type]-[name].md   ← test spec ทุก Task ตาม type

QA + AI Assistant ทำงานร่วมกันอย่างไร: AI Assistant ช่วย draft structure + happy path จาก Scope ใน PLAN.md QA review และเติม edge cases จาก domain knowledge + ประสบการณ์ทดสอบจริง ที่ AI ไม่มีทางรู้ได้

AI Assistant ช่วยได้:
├── สร้าง structure ของ test spec
├── เขียน happy path scenarios จาก Scope ใน PLAN.md
└── เขียน common edge cases ทั่วไป

QA เติมเอง:
├── edge cases จาก business domain
├── scenario จากประสบการณ์ทดสอบจริง
└── acceptance criteria ที่ negotiate กับ PM/PO แล้ว

Task Type และ Test ที่ประกบ:

Task TypeTest
[API]Unit Test ทุก Layer (service, controller, repository)
[FE-BL]Unit Test Frontend BL
[FE]Manual Test — render + layout ใน browser
[FE-IT]E2E flow ครบ end-to-end
[Config]pnpm check + ตรวจ env vars
[CHORE]ตรวจ path ถูกต้อง + build ผ่าน

Output: tests/ folder ครบทุกไฟล์

Roleหน้าที่
QA ✍️ 🤝 AI Assistantprompt AI Assistant draft story test + feature test → review + เติม domain edge cases
Dev ✍️ 🤝 AI Assistantprompt AI Assistant gen task test spec
Tech Lead 👀review task test spec — technical correctness
Dev 👀review task test spec — เพิ่ม edge cases
QA 👀review task test spec — ให้ตรง acceptance scenario

Phase 4: Checklist

ใครทำ: Dev + AI Assistant (Chat) gen / ทุก Role review

สิ่งที่ต้องทำ:

  • Dev prompt AI Assistant (Chat) gen CHECKLIST.md จาก PLAN.md ที่สมบูรณ์แล้ว
  • AI Assistant แปลง implementation detail (bullets) → checkboxes พร้อม test links

ทำไม Checklist ต้องมาหลัง Test Spec: ชื่อ test file ทุกตัว derive ได้จาก PLAN.md โดยตรง — CHECKLIST.md แค่ link ไปหา test ที่มีอยู่แล้ว ถ้าสร้าง CHECKLIST ก่อน test files จะมี broken links

Output: CHECKLIST.md พร้อม Tasks + Subtasks + test links + Scope Coverage Check

Roleหน้าที่
Dev ✍️ 🤝 AI Assistantprompt AI Assistant gen CHECKLIST.md
Dev 👀review Subtasks — realistic + actionable ไหม
Tech Lead 👀review overall structure
QA 👀ตรวจว่า Story test link ครบทุก Story

Phase 5: Register

ใครทำ: Dev + AI Assistant (Chat) gen HANDOFF / PM/PO อัป Kanban

สิ่งที่ต้องทำ:

  • Dev prompt AI Assistant (Chat) gen HANDOFF.md empty state
  • PM/PO ย้าย feature folder และอัป KANBAN.md

HANDOFF.md empty state:

# [feature-name] — Handoff
> Last updated: YYYY-MM-DD

## Current Task
<!-- AI เติมตอน session เต็มกลางคัน -->

## Completed Subtasks
<!-- AI เติม -->

## Next Step
<!-- AI เติม -->

## Context & Decisions
<!-- AI เติม -->

Output: Feature ปรากฏบน Kanban + ทุกไฟล์พร้อม execute

plan/
├── KANBAN.md                     ← updated
└── doing/[feature-name]/
    ├── PLAN.md                   ✅
    ├── CHECKLIST.md              ✅
    ├── HANDOFF.md                ✅ (empty state)
    └── tests/                    ✅ (ครบทุกไฟล์)
Roleหน้าที่
Dev ✍️ 🤝 AI Assistantprompt AI Assistant gen HANDOFF.md empty state
PM / PO ✍️ย้าย feature → doing/ หรือ pending/ + อัป KANBAN.md

Phase 6: Execute

ใครทำ: Dev + AI Coding Agent implement / QA test / Tech Lead review

สิ่งที่ต้องทำ:

  • Dev เปิด PLAN.md + CHECKLIST.md ใน AI Coding Agent (Cursor / Copilot Workspace)
  • AI Coding Agent implement subtask ทีละ step และ tick checkbox
  • AI Coding Agent เขียน HANDOFF.md เมื่อ session เต็มกลางคัน Task
  • Dev review code + run task test ตาม Task Type
  • QA run story test ก่อน commit + feature test ก่อน merge

Execution flow:

Task เสร็จ → Task test ผ่าน → commit
                    ↓
ทุก Task ใน Story เสร็จ → Story test ผ่าน → commit
                    ↓
ทุก Story เสร็จ → Feature test ผ่าน → commit → merge

ทำไมต้อง commit ทุก Task: ถ้ามีปัญหาระหว่างทำ Task ถัดไป → rollback กลับมาได้ทันที โดยไม่เสียงาน Task ที่ผ่านแล้ว

Roleหน้าที่
Dev 🤝 AI Coding Agentimplement subtask ทีละ step
Dev 👀review code + run task test
QA 🧪run story test ก่อน commit + feature test ก่อน merge
Tech Lead 👀review ก่อน merge

สรุป Role × Phase

Phase 1  Define       PM/PO ✍️   + Tech Lead 👀  + QA 👀
Phase 2  Expand       Dev ✍️🤝   + Tech Lead 👀  + PM/PO 👀 + QA 👀
Phase 3  Test Spec    QA ✍️🤝   + Dev ✍️🤝      + Tech Lead 👀
Phase 4  Checklist    Dev ✍️🤝   + Tech Lead 👀  + QA 👀
Phase 5  Register     Dev ✍️🤝   + PM/PO ✍️
Phase 6  Execute      Dev 🤝🤖   + QA 🧪         + Tech Lead 👀

สัญลักษณ์:

  • ✍️ = เป็นคนลงมือทำ
  • 🤝 = ทำร่วมกับ AI Assistant (Chat)
  • 🤖 = ทำร่วมกับ AI Coding Agent
  • 👀 = review
  • 🧪 = run test

สรุป AI ช่วยอะไรในแต่ละ Phase

PhaseAI Assistant (Chat)AI Coding Agent
2 ExpandExpand Stories + Tasks + implementation detail—
3 Test SpecDraft story + feature test spec (กับ QA) + Gen task test spec (กับ Dev)—
4 ChecklistGen CHECKLIST.md—
5 RegisterGen HANDOFF.md empty state—
6 Execute—Implement subtasks + tick checkbox + เขียน HANDOFF.md

AI Assistant (Chat) = ใช้ Phase 2–5 (spec & planning) AI Coding Agent = ใช้ Phase 6 (implementation)

หลักการสำคัญ

1. AI-Spec ต้องสมบูรณ์ก่อน register เสมอ Feature ที่ขึ้น Kanban = Feature ที่ AI พร้อม execute ได้ทันที ไม่มีงานค้างให้ Human เตรียมกลางทาง

2. Dev ที่ implement คือคนเตรียม AI-Spec Dev รู้ implementation detail ดีที่สุด — ให้ Dev เขียนแล้ว Tech Lead review ดีกว่า Tech Lead เขียนแล้ว Dev แก้

3. QA เข้ามาตั้งแต่ Phase 1 และใช้ AI Assistant ช่วยเขียน Test Spec QA รู้ requirement ตั้งแต่แรก = เขียน Story test ได้ตรง business intent AI Assistant ช่วย draft structure + happy path — QA เติม domain edge cases ที่ AI ไม่รู้

4. Human ลงแรงแค่ business decision + review Boilerplate ทั้งหมด — format, subtasks, test file structure — AI handle ให้หมด

FAQ

Q: AI-Spec กับ Technical Spec แบบเดิมต่างกันอย่างไร?

Technical Spec แบบเดิมเขียนเพื่อให้ Human Dev อ่านและ interpret เอง — AI-Spec เขียนเพื่อให้ AI Coding Agent อ่านแล้วทำงานได้ทันทีโดยไม่ต้องตีความ ความแตกต่างหลักคือ AI-Spec ต้องมี implementation detail ที่ละเอียดพอ, Task Type label ชัดเจน, และ test spec พร้อมก่อนเริ่ม execute เสมอ

Q: ถ้าทีมไม่มี QA ควรให้ใครเขียน Story Test และ Feature Test?

ให้ PM/PO เขียน Feature Test (business flow) และให้ Dev เขียน Story Test (technical acceptance) โดยใช้ AI Assistant ช่วย draft ก่อนเสมอ — สิ่งสำคัญคือ test spec ต้องเขียนก่อน implement ไม่ใช่หลัง เพราะถ้าเขียนทีหลังจะกลายเป็นแค่ confirm สิ่งที่ทำไปแล้ว ไม่ใช่ validate requirement จริงๆ

Q: AI Coding Agent อ่าน PLAN.md แล้วทำงานได้เลยโดยไม่ต้องมี CHECKLIST.md ไหม?

ทำได้ แต่ไม่แนะนำ — CHECKLIST.md ช่วยให้ AI Coding Agent track progress ทีละ subtask และเขียน HANDOFF.md ได้ถูกต้องเมื่อ session เต็มกลางคัน ถ้าไม่มี CHECKLIST.md โอกาสที่งานจะหายหรือ AI ทำซ้ำในรอบถัดไปสูงมาก

Q: ควรสร้าง AI-Spec ให้ครบก่อน register ขึ้น Kanban หรือ register ก่อนแล้วค่อยเติม?

ต้องครบก่อน register เสมอ — Feature ที่ขึ้น Kanban หมายความว่าพร้อม execute ได้ทันที ถ้า AI-Spec ยังไม่ครบ Dev ต้องมาเตรียมกลางทาง ซึ่งทำให้ estimate เวลาไม่ได้และ block AI Coding Agent โดยไม่จำเป็น

Q: HANDOFF.md สำคัญแค่ไหน ถ้าไม่มีจะเกิดอะไรขึ้น?

HANDOFF.md คือ checkpoint ที่ AI Coding Agent เขียนทิ้งไว้เมื่อ session เต็มกลางคัน Task — ถ้าไม่มี Dev ต้องอธิบาย context ทั้งหมดให้ AI ใหม่ทุกครั้งที่ session ใหม่ ซึ่งเสียเวลามากและมีโอกาสสูงที่ AI จะ re-do งานที่ทำไปแล้ว

Q: ถ้า Delivery Team มี Developer คนเดียว ใช้ Workflow นี้ได้ไหม?

ได้ครับ — และอาจได้ประโยชน์มากกว่าทีมใหญ่ด้วยซ้ำ เพราะ AI Assistant ทำหน้าที่แทน Role ที่ขาดได้เกือบทั้งหมด Dev คนเดียวแค่สวม hat ให้ถูกในแต่ละ Phase:

  • Phase 1 — คิดแบบ PM/PO: เขียน Goal + Scope จากมุม User
  • Phase 2 — คิดแบบ Dev + Tech Lead: ให้ AI Assistant expand Stories + Tasks + implementation detail แล้ว review เอง
  • Phase 3 — คิดแบบ QA: ตั้งคำถามว่า “อะไรพังได้บ้าง” แล้วให้ AI Assistantช่วย draft test spec
  • Phase 4 — ให้ AI Assistant gen CHECKLIST.md แล้ว review ความสมเหตุสมผลของ Subtasks
  • Phase 5 — ให้ AI Assistant gen HANDOFF.md แล้วขึ้น Kanban ด้วยตัวเอง
  • Phase 6 — ปล่อยให้ AI Coding Agent implement แล้ว review เฉพาะจุดที่ risk สูง

สิ่งที่ Dev คนเดียวต้องระวังคือ อย่าข้าม Phase 3 (Test Spec) เพราะถ้าไม่มี QA คอย check งาน Phase นี้คือ safety net เดียวที่มี

Q: Dev คนเดียวรับผิดชอบหลาย Feature พร้อมกัน ควรสร้าง AI-Spec ทีละ Feature หรือทำพร้อมกันได้?

ทำพร้อมกันได้ในส่วน Phase 1 (Define) เพราะเป็นแค่ shell — แต่ Phase 2 ขึ้นไปควรทำทีละ Feature เพื่อให้ implementation detail มีคุณภาพ Dev ที่คิดหลาย Feature พร้อมกันมักเขียน detail ได้ไม่ละเอียดพอ ทำให้ AI Coding Agent ต้องถามเพิ่มระหว่าง execute