บอร์ด: Scrum, Kanban และ Delivery pipeline

บอร์ดแต่ละแบบต่างกันอย่างไร?

คอลัมน์ Backlog บน Kanban ทำงานอย่างไร?

project Kanban มีสถานะ Backlog เป็นคอลัมน์แรกก่อน To Do issue ใหม่เริ่มที่ Backlog และลากไป To Do เมื่อพร้อมทำ คอลัมน์ Backlog พับเก็บได้ project Kanban ที่สร้างก่อนมีฟีเจอร์นี้ ผู้ดูแล project กดเพิ่มคอลัมน์ Backlog ได้ครั้งเดียว

WIP limit ต่อ status กำหนดใน project.md คอลัมน์ที่เกิน limit จะถูกเน้นให้เห็น

Delivery pipeline ทำงานอย่างไร?

ตอนสร้าง project ระบุ environment ตามลำดับการส่งมอบ 1–10 อัน ระบบสร้างคอลัมน์ Backlog · To Do · Test Rejected · Developing · Dev Done แล้วตามด้วย Testing และ Passed ของแต่ละ environment และปิดท้ายด้วย Done บนบอร์ด คอลัมน์ของแต่ละ environment อยู่ใต้แถบหัวข้อเดียวกัน

environment คือที่ที่ส่งมอบงาน (เช่น Dev, UAT, Production) ไม่ใช่สถานะงาน อย่าใส่ชื่อคอลัมน์หลักอย่าง To Do หรือ Done หรือคำ Testing / Passed — ระบบสร้าง Testing (ชื่อ) และ Passed (ชื่อ) ให้เอง ถ้าชื่อดูเหมือนสถานะงาน หน้าจอจะเตือนและถามอีกครั้งก่อนสร้างหรือบันทึก ใต้ตัวอย่างคอลัมน์มีลำดับการส่งมอบ เช่น Dev Done → Testing (Dev) → Passed (Dev) → Testing (UAT) → Passed (UAT) → Done — Testing คือกำลังทดสอบบน environment นั้น Passed คือทดสอบผ่านแล้ว รอส่งต่อ environment ถัดไป

• issue ที่ทดสอบไม่ผ่านใน environment ใดก็ตาม ย้ายไป Test Rejected แล้วกลับเข้าสู่การพัฒนา
• ผู้ดูแล project เพิ่ม เปลี่ยนชื่อ หรือจัดลำดับ environment ได้ภายหลังในหน้าตั้งค่า project
• ลบ environment ได้เมื่อไม่มี issue อยู่ในคอลัมน์ของ environment นั้น — ระบบแสดงรายการ issue ที่ยังค้างอยู่
• Delivery pipeline ไม่มี sprint

---
key: REL
name: Releases
board_type: pipeline
environments:               # 1–10, in delivery order
  - { id: develop, name: develop }
  - { id: uat, name: UAT }
  - { id: prod, name: production }
statuses:                   # generated from the environments
  - { id: backlog, name: "Backlog", category: todo }
  - { id: todo, name: "To Do", category: todo }
  - { id: test_rejected, name: "Test Rejected", category: in_progress }
  - { id: developing, name: "Developing", category: in_progress }
  - { id: dev_done, name: "Dev Done", category: in_progress }
  - { id: testing_develop, name: "Testing (develop)", category: in_progress }
  - { id: passed_develop, name: "Passed (develop)", category: in_progress }
  - { id: testing_uat, name: "Testing (UAT)", category: in_progress }
  - { id: passed_uat, name: "Passed (UAT)", category: in_progress }
  - { id: testing_prod, name: "Testing (production)", category: in_progress }
  - { id: passed_prod, name: "Passed (production)", category: in_progress }
  - { id: done, name: "Done", category: done }
---

ส่วนสรุปของบอร์ดอัปเดตทันทีที่ย้ายหรือแก้ issue ส่วน Throughput นับ issue ที่อยู่ในคอลัมน์ Done ตามสัปดาห์ที่แก้ล่าสุด (ช่วงละ 7 วัน เวลากรุงเทพ) แท่งขวาสุดคือสัปดาห์นี้

คอลัมน์ On Hold คืออะไร?

บอร์ด Kanban และ Delivery pipeline เปิดคอลัมน์ On Hold ได้ในหน้าตั้งค่า project (ส่วนคอลัมน์) สำหรับงานที่พักไว้ เช่น รอลูกค้า รอการตัดสินใจ หรือรอทีมอื่น คอลัมน์อยู่ต่อจาก Backlog อยู่ในหมวด todo จึงไม่นับรวมใน WIP และไม่นับว่าเสร็จ

• ค่าเริ่มต้นปิด เพราะบางทีมไม่ได้ใช้
• ปิดได้เมื่อไม่มี issue อยู่ในคอลัมน์ ถ้ายังมี ระบบแสดงรายการ issue ให้ย้ายออกก่อน
• เปลี่ยน environment ของ Delivery pipeline แล้วคอลัมน์ On Hold ยังอยู่
• บอร์ด Scrum ไม่มี On Hold — งานที่พักใน sprint ให้ย้ายออกไป backlog

Status และ workflow มาจากไหน?

จากไฟล์ project.md ของแต่ละ project ทุก status มี category (todo, in_progress, done) และกำหนดได้ว่าย้ายไป status ใดก็ได้ (any) หรือเฉพาะเส้นทางที่ระบุ project ใหม่ได้ To Do, In Progress, In Review, Test Rejected และ Done บนแพ็กเกจ Premium ผู้ดูแลแก้คอลัมน์ได้เองในหน้าตั้งค่าโปรเจกต์ → คอลัมน์บอร์ด (ด้านล่าง)

---
key: APP
name: Mobile App
board_type: scrum
statuses:
  - { id: todo, name: "To Do", category: todo }
  - { id: in_progress, name: "In Progress", category: in_progress }
  - { id: in_review, name: "In Review", category: in_progress }
  - { id: test_rejected, name: "Test Rejected", category: in_progress }
  - { id: done, name: "Done", category: done }
transitions: any            # any | explicit list
parallel_sprints: false     # Scrum only; off by default
---

ปรับคอลัมน์บอร์ดเองได้ไหม? (Premium)

ได้ บนแพ็กเกจ Premium ผู้ดูแลบริษัทหรือผู้ดูแล project เปิดตั้งค่าโปรเจกต์ → คอลัมน์บอร์ด ได้ทุกเมื่อ ทั้งบอร์ด Scrum, Kanban และ Delivery pipeline และตอนสร้าง project ก็ปรับได้ด้วย editor เดียวกัน แก้เป็นร่างพร้อมตัวอย่างบอร์ด แล้วกดบันทึกหรือยกเลิก ถ้ามีคนอื่นบันทึกก่อน ระบบให้โหลดใหม่ก่อน ปรับได้เฉพาะคอลัมน์ — การ์ดยังลากไปคอลัมน์ไหนก็ได้ (workflow ประเภท issue และ field อื่นจะตามมาทีหลัง)

• เพิ่ม เปลี่ยนชื่อ เรียงใหม่ และลบคอลัมน์ ชื่อห้ามซ้ำ
• หมวดของคอลัมน์ (todo, in_progress หรือ done) — ต้องมีหมวด done อย่างน้อย 1 คอลัมน์ burndown และ velocity นับงานในคอลัมน์หมวด done เปลี่ยนหมวดมีผลตั้งแต่ตอนนั้น (sprint ที่ปิดแล้วใช้ค่าเดิม)
• สี WIP limit (ไม่บังคับ ทุกแบบบอร์ด — เกินแล้วคอลัมน์เป็นสีเตือน แต่ไม่ห้ามย้าย) และความหมายของคอลัมน์ ที่คนเห็นบนบอร์ดและ AI agent ได้ใน get_project และ get_docs_context
• เปลี่ยนชื่อคอลัมน์แล้ว issue ลิงก์ filter และประวัติยังเหมือนเดิม เพราะ status id ไม่เปลี่ยน
• Lane ของคอลัมน์ (ไม่บังคับ): บทบาทที่ทำงานใน status นั้น เช่น Developer หรือ QA ใส่หลายบทบาทได้ ใช้เตือน AI agent ที่ย้ายงานออกนอกบทบาท ไม่ได้ห้าม
• ลบคอลัมน์ที่มีงาน: เลือกคอลัมน์ปลายทางก่อน แล้วระบบย้ายงานเป็นเบื้องหลัง แสดงจำนวนที่ย้ายแล้ว เวลา และเวลาที่เหลือ
• Delivery pipeline: คอลัมน์ Testing / Passed ของแต่ละ environment เปลี่ยนชื่อและสีได้ แต่ลบได้ด้วยการลบ environment เท่านั้น คอลัมน์ที่เพิ่มเองยังอยู่เมื่อแก้ environment
• Backlog ของ Kanban และ Delivery pipeline เป็นคอลัมน์แรกเสมอ เปลี่ยนชื่อ สี และความหมายได้ แต่ลบหรือย้ายไม่ได้ (งานใหม่และงานที่ยังไม่เริ่มรออยู่ที่นี่) ส่วน On Hold เป็นคอลัมน์ธรรมดา
• ตอนนำเข้าจาก Jira ก็ปรับคอลัมน์ได้แบบเดียวกัน หรือใช้คอลัมน์ตามบอร์ด Jira
• แก้คอลัมน์ได้ในเว็บแอปเท่านั้น AI agent อ่านได้แต่แก้ไม่ได้
• ไม่ใช่ Premium: หน้าคอลัมน์บอร์ดยังเปิดดูได้แต่ล็อก ผู้ดูแลบริษัทเห็นปุ่มอัปเกรด สมาชิกคนอื่นกดขอให้ผู้ดูแลอัปเกรดได้ ถ้าลดจาก Premium เป็น Pro คอลัมน์ที่ปรับไว้ใช้งานต่อได้ครบแต่แก้ไม่ได้
• คอลัมน์ที่ตั้งความหมายไว้มีปุ่ม ⓘ ข้างชื่อคอลัมน์ ชี้ เลื่อนโฟกัส หรือแตะเพื่ออ่านความหมาย (และ lane) ทั้งมุมมองคอลัมน์และรายการ

แต่ละ status หมายความว่าอะไร?

นี่คือความหมายตั้งต้นของ BoardMark (กฎหลวม ๆ สำหรับเริ่มต้น) บริษัทและแต่ละ project เขียนกฎของตัวเองแทนได้ — ดูหัวข้อ “ตั้งกฎของทีมเองอย่างไร?” ด้านล่าง

แต่ละ status ยังมี lane ตั้งต้น คือบทบาทที่ทำงานใน status นั้น (เช่น In Review → QA) ดูหัวข้อ “คนและ AI agent แต่ละบทบาทหยิบงานและย้ายการ์ดอย่างไร?” ด้านล่าง

คนและ AI agent แต่ละบทบาทหยิบงานและย้ายการ์ดอย่างไร?

• ทำเฉพาะส่วนของบทบาทตัวเอง — ผู้ใช้บอก AI ว่าทำหน้าที่อะไร (developer, QA, BA …) ถ้าไม่ชัด AI จะถามครั้งเดียว BoardMark เชื่อม AI ได้ทุกตำแหน่ง
• Developer: หยิบงานที่ assign ให้ตัวเองก่อน แล้วค่อยหยิบงานใน To Do ที่ยังไม่มีคนรับ ไม่หยิบงานที่ assign ให้คนอื่นเว้นแต่ผู้ใช้สั่ง เรียก list_inbox เมื่อเริ่ม session และหลังทำแต่ละการ์ด อ่านการ์ดด้วย get_issue_context ก่อน แล้วหยิบด้วย update_issue ครั้งเดียว: In Progress (Developing บน Delivery pipeline) + working (ทำอะไร อย่างไร เพราะอะไร) + touches + if_unassigned: true (409 already_assigned = มีคนถืออยู่แล้ว) ทำเสร็จย้ายไป In Review (Dev Done) พร้อม comment สรุป งานที่ Test Rejected ย้ายกลับไป In Progress / Developing เมื่อเริ่มแก้
• QA: ทดสอบงานใน In Review (Scrum, Kanban) หรือ Testing (env) (Delivery pipeline) ผ่าน → Done หรือ Passed (env) ไม่ผ่าน → Test Rejected พร้อม comment ขั้นตอน ผลที่ควรได้ และผลที่ได้จริง
• BA: เขียนและเกลา issue — รายละเอียด acceptance criteria ประเภท point ลิงก์ และ parent — ใน Backlog / To Do ไม่ย้ายงานเลย To Do
• Deploy: ย้าย Dev Done → Testing (env) หรือ Passed (env) → Testing (env ถัดไป) หมายความว่างานขึ้น environment นั้นแล้ว
• บอร์ด Scrum (สำหรับ AI agent): เปลี่ยน status ได้เฉพาะงานใน sprint ที่คนกดเริ่มแล้ว และเริ่ม sprint เองไม่ได้ ส่วนคนเปลี่ยน status ของ issue ได้ตลอดในหน้ารายละเอียด issue

Lane คือบทบาทที่ทำงานใน status นั้นและย้ายงานต่อ ทุกคอลัมน์ตั้ง lane ได้ เช่น Developer · QA · BA · DevOps · Sales · Admin หรือ Manager (ใส่หลายบทบาทได้ คั่นด้วยเครื่องหมายจุลภาค) บอร์ดซอฟต์แวร์มีค่าตั้งต้นให้โดยไม่ต้องตั้งค่า ผู้ดูแล project เปลี่ยนได้ใน editor คอลัมน์ (Premium เหมือนสีและความหมาย) หรือเลือก “ไม่มี lane” เพื่อปิด

• ค่าตั้งต้นของบอร์ดซอฟต์แวร์: Backlog → BA ; To Do · In Progress / Developing · Test Rejected → Developer ; In Review · Testing (env) → QA ; Dev Done · Passed (env) → DevOps
• Sales & Billing: Draft · Sent · Signed → Sales ; In delivery → Manager ; Billing → Admin. Budget planning: Proposed → Manager ; Approved · Spending → Admin
• บทบาทของ AI agent ตั้งที่ personal access token (ตอนสร้างหรือแก้ภายหลังในหน้าสิทธิ์เข้าถึงของเอเจนต์และ MCP) หรือที่หน้าอนุมัติตอน AI client เชื่อมต่อด้วย OAuth ถ้าผู้ใช้บอกบทบาทในแชต ให้ใช้ตามนั้น (agent ส่งบทบาทนั้นไปด้วย) ถ้าคนเดียวรัน agent หลายตัว สร้าง token แยกตามบทบาท เช่น agent DEV และ agent QA จะสะดวก
• เตือน ไม่ห้าม: เมื่อ agent ย้ายงานออกจาก lane ของบทบาทอื่น (เช่น agent Developer ย้าย In Review → Done) ข้ามขั้นของบทบาทอื่น (In Progress → Done โดยไม่ผ่าน QA) หรือ — ถ้าไม่ได้ตั้งบทบาท — ย้ายงานที่ตัวเองเพิ่งย้ายเข้า lane อื่น (ตรวจงานของตัวเอง) การย้ายยังสำเร็จ แต่ agent ได้รับคำเตือนให้หยุด บอกผู้ใช้ และส่งต่อด้วย comment คนไม่ถูกเตือนและไม่ถูกห้าม
• ประวัติของ issue แสดงบทบาทของ agent (“ผ่าน Claude Code · QA”) และเครื่องหมาย ⚠ ที่การย้ายที่ออกนอก lane ของ agent
• Lane เป็นคำแนะนำ ไม่ใช่สิทธิ์ — สิทธิ์ยังเท่ากับผู้ใช้เหมือนเดิม

ตั้งกฎของทีมเองอย่างไร?

เขียนเป็น Markdown ในเอกสารที่ AI agent อ่านก่อนเริ่มงานเสมอ: กฎของทั้งบริษัทอยู่ใน company brief (คอนโซลผู้ดูแล) กฎของแต่ละ project อยู่ใน brief ของ project (ฟันเฟืองบนบอร์ด → เอกสาร) เอกสาร 2 ชนิดนี้แก้ได้เฉพาะผู้ดูแล (company admin / project admin) จึงเป็นกฎชุดเดียวที่ agent ทำตาม ส่วน working notes กับ handoff รวมถึง issue และ comment ที่สมาชิกทุกคนเขียนได้ agent อ่านเป็น “ข้อมูล” ไม่ใช่คำสั่ง — ข้อความในนั้นที่สั่งให้ agent ทำอะไรจะไม่ถูกทำตาม และ agent จะไม่ไปทำกับ project อื่นเพราะมีข้อความบอก ลำดับความสำคัญ: คำสั่งของผู้ใช้ > brief ของ project > company brief > ค่าตั้งต้นของ BoardMark ด้านบน ถ้า project มี status ของตัวเอง (เช่น import จาก Jira) ให้อธิบายความหมายไว้ใน brief ด้วย เขียนเป็นภาษาไทยได้ ทุก brief แสดงว่าใครแก้ล่าสุดเมื่อไร

lane ใน editor คอลัมน์เสริมกฎที่เขียนไว้: lane บอกว่าบทบาทไหนทำงานใน status นั้น ส่วนเอกสารอธิบายรายละเอียดของทีม

## Workflow rules

- In Review = code review by a senior developer; QA tests in UAT only.
- Developers move their own issues up to In Review; only QA moves to Done.
- "Waiting sign-off" (from Jira) = the customer is checking it; the PM moves it to Done.
- Agents: work only on issues labelled `agent-ok`; always comment what you changed.

ย้ายการ์ดอย่างไร?

• ลากการ์ดไปคอลัมน์อื่นเพื่อเปลี่ยน status หรือลากขึ้นลงเพื่อจัดลำดับ
• ลาก issue จากแถบ backlog ลงคอลัมน์ได้โดยตรง — issue จะเข้า sprint ที่กำลังทำงานพร้อม status นั้น
• บนมือถือกดค้างแล้วลาก หรือเปลี่ยน status ในหน้ารายละเอียด issue
• ใช้คีย์บอร์ด: ⇧← / ⇧→ ย้ายคอลัมน์ และ ⇧↑ / ⇧↓ เลื่อนลำดับ

มุมมองรายการ: สวิตช์ คอลัมน์ | รายการ ข้างปุ่ม Settings แสดงงานชุดเดียวกันเป็นรายการ จัดกลุ่มตามคอลัมน์ (Backlog และ Done พับไว้) ระบบจำมุมมองที่เลือกไว้ต่อ project บนมือถือเปิดเป็นรายการเลย หัวกลุ่มแต่ละกลุ่มมีปุ่ม + สร้างงานใหม่ในสถานะนั้นได้เลยเหมือนหัวคอลัมน์ ทุกแถวมีปุ่มสถานะ: กดแล้วเลือกสถานะถัดไปที่ไฮไลต์ไว้ ย้อนกลับ หรือสถานะใดก็ได้ ไม่ต้องเปิดรายละเอียด issue · คีย์บอร์ด ] = สถานะถัดไป [ = ย้อนกลับ · หลังย้ายกด “เลิกทำ” ได้ · ใน Delivery pipeline จาก Testing มีให้เลือกทั้ง Passed และ Test Rejected

ทุกคนที่เปิดบอร์ดอยู่เห็นการเปลี่ยนแปลงแบบ realtime

ย้าย issue ไป Test Rejected แล้วระบบขอให้เขียน comment บอกเหตุผล (ขั้นตอน ผลที่ควรได้ ผลที่เกิดจริง) พร้อมปุ่มเปิด issue

เลือกหลายใบแล้วย้ายทีเดียว (บอร์ด Columns และ List): กดปุ่ม Select หรือ ⌘/Ctrl+คลิกการ์ด การคลิกจะเลือกการ์ดแทนการเปิด (โหมดนี้ไม่ลาก) แถบด้านล่างแสดงจำนวนที่เลือก พร้อมปุ่ม Move to… และ Select all shown และ Clear และ Done selecting กด Esc เพื่อออก Move to… เปิดหน้าต่างยืนยันที่ข้ามการ์ดซึ่งอยู่ในสถานะนั้นแล้วหรือ workflow ไม่อนุญาต เตือนเมื่อเกิน WIP limit และมีช่องเหตุผลเมื่อสถานะนั้นต้องใส่ comment แต่ละใบย้ายด้วยการเปลี่ยนสถานะตามปกติ มีประวัติของตัวเองเหมือนลาก ใบที่ย้ายไม่ได้แสดงเหตุผลและยังถูกเลือกอยู่ ส่วน AI agent ใช้ transition_issue ทีละ issue

ใส่งานเข้า Release ทีละมาก ๆ ทำอย่างไร?

แท็บ Releases ใช้ได้ทุกแบบบอร์ดบนแพ็กเกจที่จ่ายเงิน เปิดที่ตั้งค่า project (ปิดไว้ก่อน) release หนึ่งรวม feature (epic — issue ลูกตามไปด้วย) กับวันขึ้น production ส่วนนี้บอกวิธีใส่และย้ายงานเข้า release ทีละหลายใบ

บนสุดของแท็บ Releases ส่วน “ล่าสุดบน production” บอกว่าตอนนี้ production อยู่ที่ release ไหน: ชื่อ วันและเวลาที่ขึ้น (ตามเขตเวลาของคุณ) ใครกดขึ้น จำนวนงานและ feature ที่ขึ้นไปด้วย เหตุผลเมื่อขึ้นทั้งที่ gate ข้อที่จำเป็นยังไม่ผ่าน และปุ่มเปิด dashboard ของ release นั้น บรรทัดเล็กด้านล่างบอก release ก่อนหน้า ถัดลงมาคือ “กำลังวางแผน” (release ที่ยังเป็นแผน) และ “ขึ้น production แล้ว (n)” ที่พับไว้ ซึ่งรวมทุก release ที่ขึ้นแล้ว project ที่ยังไม่มี release ขึ้น production จะไม่แสดงส่วนนี้

issue ที่เสร็จใน sprint ที่ปิดไปแล้วก็ใส่เข้า release ได้ เพราะ sprint ที่ปิดแล้วไม่ได้ล็อกการเลือก release อีกต่อไป (ยังเปลี่ยนสถานะและ story points ของ issue ใน sprint ที่ปิดไม่ได้ และ sprint ไม่เปลี่ยน) แต่ละ release มีบันทึกการเปลี่ยนแปลง (Release note) — ข้อความ Markdown สำหรับบอกว่ารอบนี้มีอะไร สมาชิกทุกคนของ project ที่เปิด release ได้เห็น แยกจากคำอธิบายภายในของ release — และส่วน “การ deploy” ที่เรียงใหม่สุดก่อน (ปุ่ม “บันทึกการ deploy”): แต่ละครั้งบอก environment, artifact หรือเวอร์ชัน, commit, เวลา, ผล (deployed · verified · failed · rolled back) และหมายเหตุ ครั้งล่าสุดของแต่ละ environment แสดงเป็นป้ายสั้น ๆ บนการ์ด release (เช่น production · 1.0.1 · 3 พ.ย. 23:27) ผู้ดูแล project และผู้จัดการ release เขียน Release note และบันทึกการ deploy ได้ ทั้งตอนที่ release ยังเป็นแผนและหลังขึ้น production แล้ว ส่วน AI agent บันทึกการ deploy ได้ด้วยสิทธิ์ของผู้ใช้ทุกสถานะ และเขียน Release note ได้ขณะที่ release ยังเป็นแผน เขียนบันทึกใหม่เพื่อแก้ของเดิม (แก้หรือลบรายการเก่าไม่ได้) สมาชิกทั่วไปเห็นบันทึกการ deploy แต่ไม่เห็นหมายเหตุและลิงก์ build ส่วนการติ๊ก gate และการกดขึ้น production ยังเป็นของคนเท่านั้น

• จากหน้า release ที่ยังเป็นแผน (planned): กด + Add issues ในการ์ด Features (สมาชิก PM และผู้ดูแลเห็นปุ่มนี้ ผู้ดูแลแบบดูอย่างเดียวไม่เห็น)
• ทางลัดตามแบบบอร์ด — Scrum: Done in sprint (เลือกสปรินต์ที่กำลังทำและปิดล่าสุด 3 อัน) · Kanban: งานที่เสร็จแล้วแต่ยังไม่มี release · Delivery pipeline: งานที่เสร็จและผ่าน (Passed) ก่อน production แล้วแต่ยังไม่มี release · ทุกบอร์ดมี No release (ทุกสถานะ) และค้นหาด้วย key หรือชื่อ
• ทุกแถวถูกติ๊กไว้ก่อน เอาติ๊กออกข้อที่ไม่ต้องการ แล้วกด Add N issues โหลดหน้าละ 50 รายการ ที่เหลือโหลดเมื่อเลื่อนลง
• สวิตช์ Include issues เพื่อดู issue ที่อยู่ใน release อื่น (ไม่ติ๊กไว้ และจะย้ายออกจาก release นั้น) epic บอกว่ามีการ์ดลูกตามไปกี่ใบ
• จากบอร์ด: โหมด Select (Columns และ List) และแถบเลือกการ์ดใน Backlog ของ Scrum มีปุ่ม Release… เลือก release ที่ยังเป็นแผนหรือ No release แล้วยืนยัน การ์ดที่อยู่ใน release นั้นแล้วถูกข้าม epic แจ้งจำนวนการ์ดลูกที่ตามไป ลากการ์ดไป release ไม่ได้
• ทั้งสองทางย้ายทีละ issue ด้วย move_to_release เดิม (ตรวจสิทธิ์ ต้องเป็น release ที่ยังเป็นแผน ประวัติและบันทึก scope ต่อ issue) มีตัวนับ x / N ใบที่ไม่สำเร็จยังติ๊กอยู่พร้อมเหตุผลและปุ่ม Try again เมื่อ baseline ล็อกแล้ว PM หรือผู้ดูแลพิมพ์เหตุผลหนึ่งข้อ (ไม่บังคับ ไม่เกิน 500 ตัวอักษร) ใช้กับทุก issue และเก็บในประวัติ scope

บอร์ด Kanban และ Delivery pipeline ที่เปิด Releases: เมื่อกด “Released to production” การ์ดที่เสร็จของ release นั้นออกจากบอร์ด (Columns และ List) ทันที ไม่ต้องรอรอบเก็บงานเสร็จวันจันทร์ ใต้แถบเครื่องมือมีบรรทัดบอกจำนวนการ์ดที่ขึ้นระบบแล้วและออกจากบอร์ด พร้อมปุ่ม View in release และ Show (Show โหลดดูทีละหน้าใต้หัวข้อ Shipped ของ release เฉพาะครั้งนั้น) การ์ดยังหาเจอได้ที่หน้า release, ในการค้นหา ⌘K และลิงก์ ?release=R-n การ์ดของ release นั้นที่ยังไม่เสร็จอยู่บนบอร์ดต่อ บอร์ด Scrum ไม่เปลี่ยน

สำหรับ AI agent (D189): หา issue ด้วย search_issues (release=none, status id ที่เสร็จ — บน pipeline รวม status Passed ก่อน production — และ sprint) แล้วเรียก add_to_release ครั้งเดียวด้วย key สูงสุด 50 ตัวและเหตุผลเดียว ระบบย้ายทีละ issue และตอบผลรายตัว agent ยังสร้าง release ที่ยังเป็นแผนได้ (create_release, gate ตั้งต้น) และแก้ชื่อ วัน milestone คำอธิบายได้จนกว่าจะล็อก baseline (update_release) ด้วยสิทธิ์ของผู้ใช้ agent เขียน Release note ด้วย update_release (release_note) ขณะที่ release ยังเป็นแผน และบันทึกการ deploy ด้วย add_release_deployment (environment, artifact, commit, เวลา, ผล, หมายเหตุ) ได้ทั้งตอนที่ยังเป็นแผนและหลังขึ้น production แล้ว ส่วนติ๊ก gate ล็อก baseline กดขึ้น production เปิดใหม่ และลบ เป็นของคนในแอปเท่านั้น ส่วน search_issues ที่ใส่ hide_released=true ซ่อนการ์ดที่เสร็จใน release ที่ขึ้น production แล้ว (บอกจำนวนใน omitted_released) ใช้ตอบว่า “อะไรยังไม่ขึ้น production”

search_issues   { project_key: "APP", release: "none", status: ["done"], sprint: "S-12" }   # candidates, 50 per page
create_release  { project_key: "APP", name: "2026.11", target_date: "2026-11-28", reason: "Next release" }   # → R-4, default gate
add_to_release  { project_key: "APP", release_id: "R-4", issue_keys: ["APP-101", "APP-104", "APP-107"], reason: "Sprint 12 scope" }   # ≤ 50, result per issue
update_release  { project_key: "APP", release_id: "R-4", release_note: "Faster board loading, new Releases tab", reason: "Draft release note" }   # seen by every project member
add_release_deployment  { project_key: "APP", release_id: "R-4", environment: "production", artifact: "app:1.0.1", commit: "3f9c2ab", result: "deployed", notes: "Rolled out 23:27" }   # appended to the deployment log
search_issues   { project_key: "APP", hide_released: true }   # what is not in production yet
# → omitted_released: how many done cards of shipped releases were left out

ถ้าสองคนแก้ issue เดียวกันพร้อมกันจะเป็นอย่างไร?

ทุกการบันทึกส่ง version ที่อ่านมา ถ้ามีคนบันทึกก่อน ระบบจะไม่เขียนทับ ถ้าอีกฝ่ายแก้ฟิลด์อื่น การเปลี่ยนฟิลด์หรือรายละเอียดของคุณจะถูกบันทึกต่อจาก version ใหม่ให้เอง ถ้าอีกฝ่ายแก้ฟิลด์เดียวกันก่อน ระบบแสดงค่าของอีกฝ่ายและแจ้งให้ทราบ

ถ้าทั้งสองฝ่ายแก้รายละเอียดพร้อมกัน ระบบแสดงความแตกต่างให้คุณเลือกเอง: ใช้ของฉัน, ใช้ของอีกฝ่าย หรือรวมการแก้ไข

การตั้งค่า project ก็เช่นกัน: ถ้ามีคนแก้การตั้งค่าอื่นระหว่างนั้น สวิตช์ที่คุณกดยังบันทึกได้ ระบบแจ้งเฉพาะเมื่ออีกฝ่ายเปลี่ยนการตั้งค่าเดียวกัน