JIRA Handbook

เข้าใจ JIRA 0 → Hero — ตั้งแต่ issue แรก ถึงกลไกหลังบ้าน (JIRA Handbook · 15 บท · 5 ระดับ · เน้น Scrum) · คู่มือที่พาคุณจากคนไม่เคยแตะ JIRA ไปจนวางกระบวนการ Scrum ได้ทั้งทีม และเข้าใจว่า JIRA ประกอบร่างขึ้นจากอะไรในระดับลึกที่สุด — เน้นแบบจำลองความคิดและเหตุผลเบื้องหลัง ไม่ใช่การท่องเมนู

• อิงกับ: Jira Cloud · แนวทาง Scrum เป็นหลัก
• เวลาอ่าน: ~100 นาที
• ภาษา: ไทย พร้อมไดอะแกรม

LEVEL 0 · ปูพื้นจากศูนย์

01JIRA คืออะไร & โมเดลความคิดหลัก#

ลองนึกถึงทีมที่ติดตามงานด้วยกระดาษโน้ต, แชต, และไฟล์ Excel ชื่อ tasks_final_v3.xlsx — ไม่มีใครรู้แน่ว่างานไหนใครทำ ค้างตรงไหน หรือใครแก้อะไรล่าสุด พอทีมโตขึ้นวิธีนี้พังทันที JIRA คือระบบที่ทำสิ่งนี้ให้อย่างเป็นระเบียบ: เก็บทุกชิ้นงานเป็นรายการที่ติดตามได้ มีเจ้าของ มีสถานะ มีประวัติว่าใครเปลี่ยนอะไรเมื่อไหร่ และเชื่อมโยงกันเป็นภาพใหญ่ของโปรเจกต์

สิ่งที่ทำให้ JIRA ทรงพลังกว่า to-do list ทั่วไปคือมันถูกออกแบบมาเพื่อ กระบวนการทำงานของทั้งทีม — ไม่ใช่แค่ "มีงานอะไรบ้าง" แต่ตอบได้ว่า "งานเดินทางผ่านขั้นตอนไหนบ้างกว่าจะเสร็จ", "รอบนี้ทีมรับงานไหวแค่ไหน", และ "เราส่งของได้เร็วขึ้นหรือช้าลง" ทั้งหมดวัดเป็นตัวเลขได้

1.1 ทุกอย่างใน JIRA คือ "issue"

นี่คือกุญแจที่ทำให้ทั้งเล่มนี้เข้าใจง่าย: หน่วยพื้นฐานเดียวของ JIRA คือ issue ไม่ว่าจะเรียกมันว่า task, bug, story, หรืองานใหญ่ระดับ epic — ลึกลงไปมันคือ "issue" ที่มีหน้าตาเหมือนกันหมด คือการ์ดใบหนึ่งที่บรรจุ ฟิลด์ (เช่น ชื่อ, ผู้รับผิดชอบ, สถานะ) เอาไว้ ความต่างระหว่าง bug กับ story เป็นเพียง "ป้ายประเภท" และชุดฟิลด์ที่ต่างกันเล็กน้อยเท่านั้น

เมื่อคุณมองทุกอย่างเป็น issue ที่มีฟิลด์ คำสั่งและฟีเจอร์ที่เหลือทั้งหมด (board, sprint, JQL, report) จะกลายเป็นเรื่อง "เดาได้" เพราะมันทำงานกับ issue และฟิลด์ของมันเสมอ

1.2 JIRA อยู่ตรงไหนในจักรวาล Atlassian

JIRA เป็นผลิตภัณฑ์ของ Atlassian และมักทำงานคู่กับเครื่องมือพี่น้อง — รู้จักไว้คร่าว ๆ จะเห็นว่าทำไมหลายอย่างถึงเชื่อมกันได้:

1.3 Cloud กับ Data Center ต่างกันตรงไหน

JIRA มีสองแบบการติดตั้งหลัก เล่มนี้อิงกับ Jira Cloud เป็นหลัก:

• Jira Cloud — Atlassian โฮสต์ให้ อัปเดตอัตโนมัติ มี Automation ในตัว แบ่งเป็น team-managed (ทีมตั้งค่าเองได้อิสระ) กับ company-managed (admin คุมมาตรฐานกลาง) — รายละเอียดในบท 13
• Data Center / Server — องค์กรติดตั้งบนเซิร์ฟเวอร์ตัวเอง คุมได้ลึกและทำ plugin เองได้ แต่ดูแลเองทั้งหมด แนวคิดหลัก (issue, workflow, JQL) เหมือนกัน ต่างที่เมนูบางจุดและรอบการอัปเดต

🧭 เริ่มยังไงดี — ถ้าเพิ่งเริ่ม: ขอให้ admin สร้าง project ให้ (หรือสร้างเองถ้ามีสิทธิ์) แล้วเลือกเทมเพลต Scrum — JIRA จะเซ็ต board, backlog, และ workflow พื้นฐานมาให้ครบ พร้อมใช้ทันที ที่เหลือคือค่อย ๆ ปรับให้เข้ากับทีม

✅ สรุปบทที่ 1 — JIRA = ระบบติดตามงานของทั้งทีม ที่บอกได้ว่างานอยู่ขั้นไหน ใครทำ และทีมเร็วแค่ไหน · หน่วยพื้นฐานเดียวคือ issue ทุกอย่างคือ issue ที่มีฟิลด์ · ทำงานคู่กับ Confluence/Bitbucket · เล่มนี้อิง Jira Cloud แต่แนวคิดใช้ได้กับ DC

02กายวิภาคของ Issue & ศัพท์ Scrum#

บทนี้สำคัญที่สุดในระดับปูพื้น ถ้าเข้าใจว่า issue ประกอบด้วยอะไรและซ้อนชั้นกันยังไง บทที่เหลือทั้งเล่มจะต่อยอดได้ทันที

2.1 Issue = การ์ดที่บรรจุฟิลด์

ทุก issue มี คีย์ ที่ไม่ซ้ำกัน เช่น SHOP-142 (ตัวหน้าคือรหัสโปรเจกต์ ตัวเลขคือลำดับ) คีย์นี้คือชื่อถาวรที่ใช้อ้างถึงงานชิ้นนั้นได้ทุกที่ — ในแชต, commit, หรือ JQL ภายในการ์ดคือชุด ฟิลด์ ที่อธิบายงาน:

2.2 ประเภทของ issue และลำดับชั้น

ป้ายประเภท (issue type) บอกว่า issue นี้เป็นงานแบบไหน และที่สำคัญคือมันกำหนด ลำดับชั้น ของการซ้อนงาน ในบริบท Scrum ลำดับชั้นมาตรฐานคือ:

• Epic — ก้อนงานใหญ่ที่ทำไม่จบใน sprint เดียว ใช้รวบ Story/Task หลายใบเข้าด้วยกัน (บท 10)
• Story — งานที่ส่งมอบ คุณค่าให้ผู้ใช้ เขียนในมุม user มักประเมินเป็น story point
• Task — งานที่ต้องทำแต่ไม่ผูกกับคุณค่า user ตรง ๆ เช่น "ตั้งค่า CI"
• Bug — ของที่เสียและต้องซ่อม อยู่ระดับเดียวกับ Story (ลากเข้า sprint ได้)
• Sub-task — การแตก Story/Task/Bug หนึ่งใบออกเป็นชิ้นเล็กเพื่อแบ่งกันทำ จะมีชีวิตอยู่ใต้ parent เสมอ

2.3 ศัพท์ Scrum map เข้ากับ JIRA ยังไง

เล่มนี้เน้น Scrum ดังนั้นปรับจูนศัพท์ให้ตรงกันก่อน เพื่อไม่ให้สับสนในบทถัด ๆ ไป:

✅ สรุปบทที่ 2 — Issue = การ์ดที่มีคีย์ถาวร (เช่น SHOP-142) บรรจุฟิลด์ · ประเภท issue กำหนดลำดับชั้น: Epic › Story/Task/Bug › Sub-task · Epic เท่านั้นที่อยู่เหนือ sprint · ศัพท์ Scrum (backlog, sprint, story, point) ล้วน map ลงเป็น issue + ฟิลด์ + การจัดกลุ่มทั้งหมด

LEVEL 1 · พื้นฐาน

03Workflow & Status — issue เดินทางยังไง#

ถ้า issue คือการ์ด workflow คือกฎว่าการ์ดใบนั้นเดินทางจากเกิดไปจนเสร็จได้ทางไหนบ้าง นี่คือหัวใจที่ทำให้ JIRA ต่างจาก to-do list — มันไม่ใช่แค่ติ๊กถูกว่าเสร็จ แต่บังคับให้งานไหลตามกระบวนการที่ทีมตกลงกัน

3.1 Status ≠ Transition

สองคำนี้คนสับสนบ่อยที่สุด แยกให้ชัดแล้วทุกอย่างง่ายขึ้น:

• Status = สภาวะ ที่ issue กำลังอยู่ เช่น To Do, In Progress, Done — เป็น "จุด"
• Transition = เส้นทางที่อนุญาต ให้ย้ายจาก status หนึ่งไปอีก status เช่น "Start work" (To Do → In Progress) — เป็น "ลูกศร"

มองภาพรวม workflow คือ state machine: วงกลม (status) เชื่อมด้วยลูกศร (transition) คุณย้าย status ได้เฉพาะตามลูกศรที่มีเท่านั้น — ถ้าไม่มีลูกศรจาก Done กลับไป To Do ก็แปลว่าทีมไม่อนุญาตให้ทำแบบนั้น

3.2 หมวดของ status (status category)

เบื้องหลัง ทุก status ถูกจัดเข้า หนึ่งในสามหมวด ซึ่งเป็นตัวกำหนดสีและการนับงาน "เสร็จ/ไม่เสร็จ" ในรายงานและ board:

✅ สรุปบทที่ 3 — Workflow = state machine: status (จุด) เชื่อมด้วย transition (ลูกศร) · ย้ายได้เฉพาะตามลูกศรที่มี · ทุก status สังกัด 1 ใน 3 หมวด (To Do / In Progress / Done) และ หมวด Done เท่านั้นที่ทำให้รายงานนับงานว่าเสร็จ

04Board — กระดานที่ทีมมองงานร่วมกัน#

Board คือมุมมองที่ทำให้ workflow ที่เป็นนามธรรมในบท 3 กลายเป็นภาพจับต้องได้ — การ์ดเรียงเป็นคอลัมน์ที่ทุกคนในทีมเห็นพร้อมกัน หัวใจที่ต้องเข้าใจคือ:

4.1 คอลัมน์บน board = status (ที่ถูก map ไว้)

แต่ละ คอลัมน์ บน board ไม่ใช่สิ่งใหม่ มันคือ "ตู้" ที่รับ status หนึ่งหรือหลายตัวมาแสดง การลากการ์ดข้ามคอลัมน์ = การสั่ง transition ให้ issue เปลี่ยน status นั่นเอง

4.2 Scrum board กับ Kanban board

JIRA มี board สองชนิด เลือกตามวิธีทำงานของทีม เล่มนี้เน้น Scrum board:

🧭 เลือกยังไง — ถ้าทีมตอบได้ว่า "รอบนี้เราจะส่งอะไร ภายในกี่วัน" → Scrum · ถ้างานเข้ามาแบบคาดเดาไม่ได้และต้องหยิบทำทันที (เช่น ทีม support) → Kanban · ทั้งสองแบบใช้ issue และ workflow ชุดเดียวกัน เปลี่ยน board ได้โดยงานไม่หาย

4.3 Kanban ล้วน — ทำงานแบบไม่มี sprint

ทีมจำนวนไม่น้อย (support, ops, ทีมที่งานเข้าแบบสุ่มตลอดเวลา) ไม่มี "รอบ" ให้วางแผนล่วงหน้าแบบ Scrum — งานเข้าเมื่อไหร่ก็หยิบทำเมื่อนั้น กลไกที่ทำให้ Kanban ยังคุมงานได้โดยไม่มี sprint คือสองอย่างนี้:

• WIP Limit — แต่ละคอลัมน์ตั้งเพดานจำนวนการ์ดได้ (ใน JIRA เรียกว่า column constraint) เช่นคอลัมน์ "In Progress" จำกัดไว้ที่ 3 ใบ ถ้าเต็มแล้ว ห้ามดึงงานใหม่เข้ามาจนกว่าจะมีใบไหลออกก่อน — บังคับให้ทีมเคลียร์งานค้างก่อนรับงานใหม่ แทนที่จะแตะทุกอย่างพร้อมกันแล้วไม่มีอะไรเสร็จสักอย่าง เมื่อเกินเพดาน หัวคอลัมน์จะเปลี่ยนเป็นสีแดงให้เห็นชัด
• Cycle Time — เพราะไม่มี sprint ให้นับ point ต่อรอบ Kanban จึงวัดผลด้วยเวลาที่การ์ดหนึ่งใบใช้ นับจากเริ่มลงมือ (เข้า "In Progress") จนถึง Done แทน ยิ่งสั้นและสม่ำเสมอยิ่งดี — ต่างจาก velocity ที่วัดเป็น point/sprint, cycle time วัดเป็นเวลา/การ์ดหนึ่งใบ จึงเทียบงานแต่ละชิ้นได้ทันทีโดยไม่ต้องรอครบรอบ

เพราะไม่มีจุดจบของรอบให้ปิดแบบ sprint สัญญาณที่ต้องมองบน Kanban board จึงต่างจาก Scrum: คอลัมน์ที่ขึ้นสีแดงค้างนาน (เกิน WIP limit = งานกองเกินกำลังที่จะดันไปต่อ) หรือ การ์ดที่แก่ผิดปกติ (ค้างคอลัมน์เดิมนานกว่าใบอื่นมาก ๆ มักมี blocker ซ่อนอยู่) คือสัญญาณคอขวด ไม่ต้องรอถึง retro เหมือน Scrum — อ่านคอขวดย้อนหลังได้จาก Cumulative Flow Diagram แบบเดียวกับบท 12 เช่นกัน

🧭 สลับไปมาได้ — Scrum กับ Kanban board ใช้ issue และ workflow ชุดเดียวกันเสมอ เปลี่ยน board type ของ project ไม่ทำให้งานหาย แต่การวัดผล (velocity ↔ cycle time) เปลี่ยนความหมายไปตามชนิด board — อย่าเทียบ velocity ข้าม board คนละชนิดกัน

4.4 Swimlane — จัดแถวการ์ด

Swimlane คือการแบ่ง board เป็นแถวแนวนอน เพื่อจัดกลุ่มการ์ดที่อยู่ในสถานะเดียวกันให้อ่านง่าย เช่นแบ่งตาม assignee, ตาม epic, หรือตาม priority — ช่วยให้เห็นภาพว่า "ใครถืองานอะไรอยู่" หรือ "epic ไหนคืบไปถึงไหน" ได้ในแวบเดียว

✅ สรุปบทที่ 4 — Board ทำให้ workflow มองเห็นได้ · คอลัมน์ = status (map ได้หลายตัว), ลากการ์ด = transition · Scrum board = ทำเป็นรอบ sprint มี backlog แยก (โฟกัสของเล่มนี้), Kanban = ไหลต่อเนื่อง คุมด้วย WIP limit วัดผลด้วย cycle time แทน sprint/velocity · swimlane จัดแถวให้อ่าน board ง่ายขึ้น

05ทำงานประจำวันบน Issue#

ระดับนี้คือสิ่งที่คุณจะทำซ้ำทุกวัน — ถ้าทำให้ลื่นและเป็นนิสัยที่ดี ข้อมูลใน JIRA จะสะอาดพอที่รายงานในบทหลัง ๆ จะเชื่อถือได้

5.1 สร้าง issue ที่ดี

กดปุ่ม Create ได้จากทุกหน้า สิ่งที่ทำให้ issue ใช้งานได้จริงไม่ใช่จำนวนฟิลด์ แต่คือคุณภาพของ 3 อย่าง:

• Summary ที่อ่านแล้วเข้าใจทันที — "ปุ่มชำระเงินกดไม่ได้บน Safari" ดีกว่า "บั๊กหน้า checkout"
• Description มี acceptance criteria — บอกว่า "เสร็จ" หมายถึงอะไร เพื่อไม่ต้องเดา
• Issue type ถูกต้อง — story/task/bug เลือกให้ตรง เพราะมีผลต่อรายงานและ workflow

5.2 มอบหมาย, คอมเมนต์, @mention

การสื่อสารทั้งหมดควรอยู่ "บนการ์ด" ไม่ใช่ในแชตที่หาย:

• Assignee — กำหนดคนเดียวที่รับผิดชอบ "ตอนนี้" (ไม่ใช่ทุกคนที่เกี่ยว)
• Comment + @mention — พิมพ์ @ชื่อ เพื่อแจ้งเตือนคนนั้นโดยตรง ทำให้บทสนทนาผูกกับงานถาวร
• Watchers — คนที่อยากตามความเคลื่อนไหวแม้ไม่ได้รับผิดชอบ

5.3 เชื่อม issue เข้าหากัน & Sub-task

งานจริงไม่ได้อยู่โดด ๆ JIRA ให้เชื่อมความสัมพันธ์ได้:

✅ สรุปบทที่ 5 — งานประจำวัน = สร้าง issue ที่ summary ชัด + มี acceptance criteria + type ถูก · สื่อสารบนการ์ดด้วย comment/@mention ไม่ใช่แชตนอก · เชื่องานด้วย link (blocks/relates), sub-task, epic link — ข้อมูลที่สะอาดวันนี้ = รายงานที่เชื่อได้ในบทหลัง

LEVEL 2 · หัวใจ SCRUM

06Backlog & Estimation#

Backlog คือ รายการงานทั้งหมดที่ยังไม่ได้ทำ เรียงตามลำดับความสำคัญจากบนลงล่าง มันคือแหล่งความจริงเดียวว่า "ทีมจะทำอะไรต่อ" และเป็นจุดตั้งต้นของทุก sprint งานบนสุดคือสิ่งที่จะถูกหยิบเข้า sprint ก่อนเสมอ

6.1 Refinement — ลับ backlog ให้คม

Backlog ที่ดีไม่ได้เกิดเอง ทีมต้องทำ refinement (grooming) สม่ำเสมอ: ทบทวนงานบนสุด เติมรายละเอียด แตกงานใหญ่ให้เล็กลง และจัดลำดับใหม่ เป้าหมายคือ งานที่อยู่ใกล้ ๆ ด้านบนต้องพร้อมหยิบทำได้ทันที ส่วนงานล่าง ๆ หยาบไว้ก่อนได้

🧭 Definition of Ready (DoR) — ก่อน story จะ "พร้อมเข้า sprint" ควรผ่านเช็กลิสต์: มี acceptance criteria ชัด · ประเมิน point แล้ว · ไม่มี dependency ค้าง · ทีมเข้าใจตรงกัน — ถ้ายังไม่ครบ อย่าเพิ่งดึงเข้า sprint

6.2 Story Points — ประเมิน "ขนาด" ไม่ใช่ "ชั่วโมง"

นี่คือจุดที่หลายทีมเข้าใจผิด: story point วัดขนาด/ความซับซ้อนสัมพัทธ์ของงาน ไม่ใช่จำนวนชั่วโมง เหตุผลคือคนเราประเมิน "เทียบกัน" ได้แม่นกว่าประเมินเวลาสัมบูรณ์ — เราตอบได้ว่า "งาน B ใหญ่กว่างาน A ราวสองเท่า" ง่ายกว่าตอบว่า "งาน A ใช้ 6.5 ชั่วโมง"

ทีมส่วนใหญ่ใช้เลข Fibonacci (1, 2, 3, 5, 8, 13, 21) เพราะยิ่งงานใหญ่ ความไม่แน่นอนยิ่งสูง ช่องห่างจึงควรถ่างขึ้น ตัวเลขที่กระโดด (เช่น 13, 21) เป็นสัญญาณว่า "งานนี้ใหญ่เกินไป ควรแตกก่อน"

6.3 Planning Poker — ประเมินพร้อมกันทั้งทีม

วิธีประเมินที่ลดอคติ: ทุกคน "เปิดไพ่" point พร้อมกัน ถ้าตัวเลขต่างกันมาก (เช่น คนหนึ่งให้ 2 อีกคนให้ 8) นั่นไม่ใช่ปัญหา แต่เป็น โอกาสคุย — แปลว่าสองคนเข้าใจงานไม่ตรงกัน การถกตรงนี้คือคุณค่าที่แท้จริง ไม่ใช่ตัวเลขสุดท้าย

✅ สรุปบทที่ 6 — Backlog = งานทั้งหมดเรียงตามความสำคัญ บนสุด = ทำก่อน · refine สม่ำเสมอให้งานบนสุดพร้อมหยิบ (DoR) · story point วัดขนาดสัมพัทธ์ ไม่ใช่ชั่วโมง ใช้ Fibonacci · planning poker มีค่าที่ "บทสนทนาเมื่อเลขไม่ตรงกัน" ไม่ใช่ตัวเลข

07Sprint Planning & Sprint Goal#

Sprint คือ รอบเวลาคงที่ (ส่วนใหญ่ 1–2 สัปดาห์) ที่ทีมสัญญาว่าจะส่งมอบงานชุดหนึ่ง ความคงที่ของเวลาคือหัวใจ — เพราะมันทำให้ทีม "วัดจังหวะตัวเอง" ได้ และทำให้ velocity (บท 9) มีความหมาย ก่อนเข้าเรื่องวางแผน ดูภาพรวมวงจร Scrum ทั้งวงก่อน:

7.1 Sprint Planning ทำอะไรบ้าง

ในมีตติ้ง planning ทีมจะ ดึง issue จากบนสุดของ backlog เข้ามาใน sprint จนเต็มกำลังที่รับไหว ใน JIRA คือการสร้าง sprint แล้วลากการ์ดจาก backlog เข้าไป หรือกด "Add to sprint" สองคำถามที่ต้องตอบให้ได้คือ "รอบนี้เราจะทำอะไร" และ "เท่านี้ไหวไหม"

7.2 Capacity — รับงานเท่าไรถึงพอดี

อย่ารับงานตามความหวัง ให้รับตาม velocity เฉลี่ยของรอบก่อน ๆ (เช่น ถ้า 3 sprint ที่ผ่านมาทำได้เฉลี่ย 28 point ก็รับราว ๆ 28) เผื่อวันลา/วันหยุด/งานแทรกไว้ด้วย การรับเกินกำลังซ้ำ ๆ คือสาเหตุอันดับหนึ่งของ sprint ที่ทำไม่จบและทีมหมดไฟ

7.3 Sprint Goal — เข็มทิศของรอบ

นอกจากรายการงาน sprint ที่ดีต้องมี เป้าหมายหนึ่งประโยค เช่น "ผู้ใช้ซื้อของจนจบ flow ได้" เป้าหมายนี้สำคัญกว่าการทำครบทุกการ์ด — เมื่อมีงานแทรกหรือต้องตัดสินใจระหว่างทาง sprint goal คือสิ่งที่บอกว่าอะไรสำคัญ อะไรตัดได้

✅ สรุปบทที่ 7 — Sprint = รอบเวลา คงที่ ที่ทำให้วัดจังหวะทีมได้ · planning = ดึงงานบนสุดของ backlog เข้า sprint ตาม capacity จาก velocity จริง ไม่ใช่ความหวัง · ทุก sprint ต้องมี sprint goal หนึ่งประโยค เป็นเข็มทิศเวลาต้องตัดสินใจ · ห้ามยืดความยาว sprint

08Active Sprint & Daily#

เมื่อกด Start sprint board จะเปลี่ยนเป็น "active sprint" แสดงเฉพาะงานในรอบนี้ ตอนนี้หน้าที่ของทีมคือทำให้การ์ดไหลจากซ้ายไปขวาจนถึง Done ให้ได้ภายในเวลา

8.1 Daily standup รอบ board

ทุกวันทีมยืนคุยสั้น ๆ (~15 นาที) โดยใช้ board เป็นศูนย์กลาง ไล่ดูการ์ดจากขวา (ใกล้เสร็จ) ไปซ้าย โฟกัสสามคำถาม: เมื่อวานคืบอะไร, วันนี้จะทำอะไร, มีอะไรติดขัด (blocker) ไหม — ข้อสุดท้ายสำคัญสุด เพราะ daily มีไว้เพื่อปลด blocker ไม่ใช่รายงานความคืบหน้าให้หัวหน้าฟัง

🧭 อ่าน board ให้เป็น — ดูการ์ดที่ กองอยู่คอลัมน์ In Review/ขวาสุดแต่ไม่ขยับ — นั่นคือคอขวด · ดูคนที่ถือหลายการ์ด In Progress พร้อมกัน — นั่นคือ context switching · board เล่าความจริงของทีมได้ดีกว่าคำพูด

8.2 จัดการ Scope Creep

ระหว่าง sprint จะมีงานใหม่โผล่มาเสมอ กฎคือ: sprint backlog ถูก "แช่แข็ง" ไว้ตาม sprint goal งานแทรกที่ไม่เร่งด่วนให้ลงไปที่ product backlog เพื่อพิจารณารอบหน้า ไม่ใช่ยัดเข้า sprint ที่กำลังวิ่งอยู่ — ผลของการแทรก/ตัดงานกลางรอบจะโผล่เป็นรอยหยักบน burndown เสมอ (สังเกตยังไงดูบท 9) ตัดสินใจงานแทรกตามสามกรณีนี้:

8.3 แตก Sub-task ระหว่างทำ

เมื่อลงมือจริงแล้วพบว่า story หนึ่งต้องแบ่งหลายคนทำ ค่อยแตกเป็น sub-task ตอนนั้นได้ — ข้อสำคัญคือ point ยังอยู่ที่ story ตัวแม่ เสมอ sub-task ไม่นับ point ซ้ำ มิฉะนั้น velocity จะพอง

✅ สรุปบทที่ 8 — Active sprint = ดันการ์ดให้ถึง Done ในเวลา · daily ใช้ board เป็นศูนย์กลาง เพื่อปลด blocker ไม่ใช่รายงานเจ้านาย · sprint backlog แช่แข็งตาม goal — งานแทรกไม่ด่วนลง product backlog, ด่วนจริงต้องแลกงานออก · sub-task แบ่งงานได้แต่ point อยู่ที่ story

09ปิด Sprint · Review · Retro · Velocity#

ปลายทางของทุก sprint ไม่ใช่แค่ "หมดเวลา" แต่คือพิธีกรรมสามอย่างที่ทำให้ทีมเก่งขึ้นทุกรอบ: โชว์ของ, ปิดรอบ, และเรียนรู้

9.1 Sprint Review & การปิด sprint

Review คือโชว์งานที่ "เสร็จจริง" (status อยู่หมวด Done) ให้ผู้เกี่ยวข้องดู เพื่อรับ feedback จากนั้นกด Complete sprint ใน JIRA — ระบบจะถามว่างานที่ ยังไม่เสร็จ จะให้ไปไหน:

• ย้ายไป sprint ถัดไป (carry-over) — ทำต่อรอบหน้า
• ย้ายกลับ backlog — ยังไม่จัดรอบให้

การปิด sprint ตรงเวลาเสมอ (แม้งานไม่ครบ) คือสิ่งที่ทำให้ตัวเลข velocity ซื่อสัตย์

9.2 อ่าน Burndown vs Burnup

• Burndown — งานที่ เหลือ ไหลลงสู่ 0 · ตอบว่า "เราจะทันไหม" · เด้งขึ้น = scope เพิ่ม
• Burnup — งานที่ เสร็จแล้ว ไต่ขึ้น พร้อมเส้น "ขอบเขตรวม" แยกต่างหาก · ข้อดีคือ แยกได้ว่าช้าเพราะทำน้อย หรือเพราะงานถูกเพิ่ม (เส้นขอบเขตขยับขึ้น)

เห็นรอยหยัก/เด้งขึ้นแบบนี้แล้วอย่าตกใจ — มันคืออาการที่บอกว่ามีงานแทรก ส่วนจะตัดสินใจรับหรือดันออกยังไง ดูหลักการที่บท 8

9.3 Velocity — จังหวะที่แท้จริงของทีม

9.4 Retrospective — เก่งขึ้นทุกรอบ

หัวใจที่ทำให้ Scrum ดีขึ้นเรื่อย ๆ คือ retro: ทีมคุยว่า อะไรดี / อะไรควรปรับ / จะลองอะไรรอบหน้า สิ่งสำคัญคือต้องจบด้วย action ที่ทำได้จริง 1–2 ข้อ และติดตามมันรอบหน้า ไม่ใช่บ่นแล้วจบ — แปลง action เป็น issue ใน backlog ได้เลยเพื่อไม่ให้หาย

✅ สรุปบทที่ 9 — ปิด sprint ตรงเวลาเสมอ งานค้างไป carry-over/backlog · burndown ดูงานเหลือ, burnup แยกได้ว่าช้าเพราะทำน้อยหรือถูกเพิ่มงาน · velocity = point เสร็จจริง ใช้พยากรณ์ ห้ามทำเป็น KPI/เทียบข้ามทีม · retro ต้องจบด้วย action ที่ติดตามได้

LEVEL 3 · วางแผนใหญ่

10Epic · Version · Roadmap#

sprint ตอบคำถาม "สองสัปดาห์นี้ทำอะไร" แต่ไม่ตอบ "ทั้งไตรมาสเรากำลังมุ่งไปไหน" เครื่องมือสามอย่างในบทนี้คือสะพานจากงานราย sprint ไปสู่ภาพใหญ่ระดับเดือน/ไตรมาส

10.1 Epic — รวบงานใหญ่ที่กินหลาย sprint

Epic คือ container ของ story/task หลายใบที่ประกอบกันเป็นความสามารถใหญ่หนึ่งอย่าง เช่น epic "ระบบชำระเงิน" อาจมี story ย่อยกระจายทำใน 3–4 sprint ประโยชน์คือ ติดตามความคืบของก้อนใหญ่ได้ โดยไม่ต้องไล่ดูทีละการ์ด — JIRA แสดงแถบความคืบของ epic จากสัดส่วน story ที่ Done

10.2 Version (Fix Version) — ผูกงานเข้ากับการ release

ฟิลด์ Fix Version ตอบว่า "งานนี้จะออกใน release ไหน" (เช่น v2.1) แท็ก issue ด้วย version เดียวกันแล้ว JIRA จะรวมเป็น release page ให้อัตโนมัติ — เห็นเสร็จกี่ % และ generate release notes ให้เอง อย่าสับสนกับ Component (ส่วนของระบบ เช่น "Backend" จัดกลุ่มแบบถาวร) เพราะ Version คือมิติเรื่องเวลา/การออกของ คนละมิติกัน

10.3 มุมมองบนแกนเวลา — เห็นภาพทั้งไตรมาส

เมื่อต้องสื่อสารกับผู้บริหารหรือทีมอื่นว่า "ไตรมาสนี้เราส่งอะไรบ้าง" การไล่ดูทีละ story ไม่ตอบโจทย์ — สิ่งที่ต้องการคือมุมมองที่ วาง epic เป็นแถบยาวบนแกนเวลา เห็นทันทีว่าอะไรทำช่วงไหน อะไรซ้อนทับกัน และ epic ไหนพึ่งพาอีก epic ก่อนจะเริ่มได้ — ตอบคำถามระดับไตรมาสได้โดยไม่ต้องลงรายละเอียดราย story

ชื่อฟีเจอร์นี้ในหน้า UI เปลี่ยนไปแล้วอย่างน้อยหนึ่งครั้ง (จาก "Roadmap" เป็น "Timeline" ในปี 2023) — เป็นตัวอย่างที่ดีว่าทำไมควรจำแนวคิด ("มุมมอง epic บนแกนเวลา") มากกว่าจำชื่อเมนูเป๊ะ ๆ เพราะ Atlassian ปรับ UI/ชื่อฟีเจอร์อยู่เรื่อย ๆ

✅ สรุปบทที่ 10 — Epic รวบ story หลายใบข้าม sprint เห็นความคืบก้อนใหญ่ · Fix Version ผูกงานเข้า release → ได้ release page + notes อัตโนมัติ · Component = ส่วนของระบบ (ถาวร), Version = การออก (เวลา) · มุมมองบนแกนเวลา (ปัจจุบันเรียก Timeline) วาง epic ให้สื่อสารภาพใหญ่ระดับไตรมาสได้

11JQL เจาะลึก — ภาษาที่ปลดล็อก JIRA#

ถ้าจะจำอะไรจากเล่มนี้แค่บทเดียว ให้เป็นบทนี้ JQL (Jira Query Language) คือภาษาค้นหาที่เปลี่ยน JIRA จาก "ที่เก็บการ์ด" เป็น "ฐานข้อมูลที่ถามอะไรก็ได้" ทุก filter, dashboard, board, และ automation ล้วนวางอยู่บน JQL — เข้าใจมันแล้วคุณจะควบคุม JIRA ได้จริง

11.1 กายวิภาคของหนึ่ง query

JQL ไม่เหมือน Google search ตรงที่มันมีโครงสร้างชัดเจน: field — operator — value ต่อกันด้วย AND/OR แล้วปิดท้ายด้วยการเรียงลำดับ

11.2 Operator ที่ใช้บ่อย

11.3 Functions — ค่าที่ขยับเองตามบริบท

พลังจริงของ JQL อยู่ที่ฟังก์ชันที่ให้ค่าแบบ ไดนามิก — query ชุดเดียวใช้ได้ตลอดโดยไม่ต้องแก้:

# งานของฉันที่ยังไม่เสร็จ ใน sprint ที่กำลังวิ่ง
assignee = currentUser() AND sprint IN openSprints() AND status != Done

# bug ที่เพิ่งสร้างใน 14 วัน ยังไม่มีคนรับ
type = Bug AND created >= -14d AND assignee IS EMPTY ORDER BY priority DESC

# งานที่ฉัน mention หรือ watch อยู่ ใน project นี้
project = SHOP AND watcher = currentUser()

ฟังก์ชันยอดฮิต: currentUser(), openSprints(), now(), startOfWeek(), membersOf("team") — สังเกตว่ามันทำให้ query "เคลื่อนที่ตามเวลา/ตามคนที่เปิดดู" เอง

11.4 Saved Filter — query ที่กลายเป็นของใช้ซ้ำ

เมื่อได้ query ที่ดีแล้ว save เป็น filter ตั้งชื่อมัน แล้วมันจะกลายเป็นวัตถุที่นำไปใช้ต่อได้ทั่ว JIRA:

• เป็น แหล่งข้อมูลของ board (board จริง ๆ คือ filter + การจัดคอลัมน์)
• เป็น gadget บน dashboard (บท 12)
• Subscribe ให้ส่งผลเข้าอีเมลตามเวลา เช่นทุกเช้าวันจันทร์
• แชร์ filter ให้ทีมใช้ร่วมกันได้

🧭 ทางลัดเรียนรู้ JQL — ใน issue search กดสลับระหว่างโหมด Basic (กดเลือกจาก dropdown) กับ JQL — ค่อย ๆ คลิกใน Basic แล้วดูว่ามันแปลงเป็น JQL หน้าตายังไง เป็นวิธีเรียนที่เร็วที่สุด

11.5 Query ระดับสูง — subquery ซ้อนกัน & อ้างอิง custom field ตรง ๆ

บาง query ที่ต้องการซับซ้อนกว่า "field เทียบกับ value ตรง ๆ" — เช่น "หา sub-task ทั้งหมดที่พ่อแม่ผูกกับ epic นี้" หรือ "หา issue ที่ไป block งานที่ยังไม่เสร็จ" — JQL ดั้งเดิมเพียงลำพังไม่มีทางเขียนความสัมพันธ์ข้าม issue แบบนี้ได้ เพราะมันเทียบได้แค่ field ของ issue ใบเดียวกับ value เฉย ๆ ไม่มีแนวคิด "subquery" ในตัว นี่คือช่องว่างที่แอปเสริมอย่าง ScriptRunner (Adaptavist) เข้ามาเติม ด้วยฟังก์ชัน issueFunction ที่คืนค่าเป็น "รายการ issue" แทนที่จะเป็นค่าเดียว

# sub-task ทั้งหมดที่พ่อแม่ผูกกับ epic นี้ (ต้องมี ScriptRunner)
issueFunction in subtasksOf("'Epic Link' = SHOP-100")

# issue ที่ไป block งานที่ยังไม่ Done — ซ้อน filter เข้าไปอีกชั้นในวงเล็บ
issueFunction in linkedIssuesOf("status != Done", "blocks")

สังเกตรูปแบบ: พารามิเตอร์ในวงเล็บคือ JQL อีกชุดหนึ่งในเครื่องหมายคำพูด — จึงซ้อนกันได้หลายชั้น (subquery ของ subquery) ชื่อฟังก์ชันและ syntax ละเอียดต่างกันไปตามเวอร์ชันแอปที่ติดตั้ง ควรเช็ก doc ของแอปนั้นก่อนใช้จริงเสมอ

อีกเรื่องที่ native JQL ทำได้เองโดยไม่ต้องพึ่งแอปเสริม คือการอ้างอิง custom field ด้วยเลข ID ตรง ๆ ผ่าน cf[ID] แทนชื่อฟิลด์ ปัญหาที่มันแก้คือ: เมื่อหลาย project ต่างสร้าง custom field ชื่อซ้ำกันเอง (เช่นทีม Marketing กับทีม Dev ต่างมีฟิลด์ชื่อ "Priority Level" คนละตัว) การพิมพ์ชื่อฟิลด์ใน JQL จะกำกวมว่าหมายถึงตัวไหน — JIRA จะเลือกตัวใดตัวหนึ่งให้แบบที่คุณเดาไม่ได้ ทางแก้คืออ้างด้วย ID ที่ไม่ซ้ำกันแทนชื่อ:

# กำกวม — ถ้ามีฟิลด์ชื่อนี้ซ้ำกันหลายตัวในระบบ ไม่รู้ว่าเจาะจงตัวไหน
"Priority Level" = "Critical"

# ชัดเจน — เจาะจงฟิลด์ ID 10010 ตัวเดียวเท่านั้น ไม่กำกวม
cf[10010] = "Critical"

🧭 หา ID ยังไง — เปิด issue search แล้วพิมพ์ชื่อฟิลด์ในช่อง JQL ตัว autocomplete จะโชว์ cf[xxxxx] ต่อท้ายชื่อฟิลด์ให้เห็นเลย หรือดึงจาก REST API ของ issue ด้วย ?expand=names ก็ได้ถ้าต้องการความแน่นอนระดับสคริปต์/automation

11.6 กับดักที่พบบ่อย

อีกกับดักที่ทำให้ query error แบบงง ๆ คือลืมใส่เครื่องหมายคำพูดครอบค่าที่มีช่องว่าง:

# ผิด — JQL อ่าน "Progress" เป็น token แยกต่างหาก จะ error ทันที
status = In Progress

# ถูก — ครอบด้วยเครื่องหมายคำพูดเมื่อค่ามีช่องว่าง
status = "In Progress"

✅ สรุปบทที่ 11 — JQL = field operator value เชื่อม AND/OR + ORDER BY · operator สำคัญ: = IN ~ >= IS WAS/CHANGED · functions ทำให้ query ไดนามิก (currentUser(), openSprints()) · saved filter คือหัวใจที่ board/dashboard/subscription ทั้งหมดวางอยู่บนนั้น · query ซับซ้อนใช้ issueFunction (ต้องมี ScriptRunner) หรืออ้าง custom field ตรง ๆ ด้วย cf[ID] (native) · ระวัง timezone กับเครื่องหมายคำพูด — เก่ง JQL = ควบคุม JIRA ได้

12Dashboard & Agile Report#

เมื่อข้อมูลใน JIRA สะอาด (บท 5) และคุณดึงมันออกมาด้วย JQL ได้ (บท 11) ขั้นต่อไปคือเปลี่ยนข้อมูลเป็น ภาพที่ตัดสินใจได้ — นั่นคือหน้าที่ของ report และ dashboard

12.1 Agile Report ที่ควรอ่านเป็น

Cumulative Flow Diagram (CFD) อ่านยากแต่ทรงพลัง: มันคือพื้นที่สีซ้อนกันของจำนวนงานในแต่ละ status ตามเวลา — ถ้าแถบสี "In Progress" ถ่างกว้างขึ้นเรื่อย ๆ แปลว่ามีงานไหลเข้าเร็วกว่าไหลออก = คอขวดชัด ๆ

12.2 Dashboard — รวมหลายมุมไว้หน้าเดียว

Dashboard คือหน้ารวม gadget หลายชิ้น แต่ละ gadget ดึงข้อมูลจาก filter (= JQL ที่ save ไว้) นี่คือเหตุผลที่บท 11 สำคัญ — dashboard ดีแค่ไหนขึ้นอยู่กับ filter ที่อยู่ข้างหลัง gadget ยอดนิยม: Filter Results (ตารางงาน), Pie Chart (สัดส่วนตามฟิลด์), Two Dimensional (เช่น assignee × status), Sprint Burndown

🧭 ออกแบบ dashboard ให้คนอ่าน ไม่ใช่ให้สวย — เริ่มจากคำถาม: "คนเปิดหน้านี้ต้องตัดสินใจอะไร" · dashboard ทีม dev อาจมี "blocker ตอนนี้ + งานของฉัน + burndown" · dashboard ผู้บริหารอาจมี "ความคืบ epic + release ใกล้ถึง" — คนละชุด gadget กัน

✅ สรุปบทที่ 12 — อ่านรายงานเป็น: burndown (ทันไหม), velocity (เร็วแค่ไหน), CFD (คอขวดอยู่ไหน), control chart (cycle time) · dashboard = gadget หลายชิ้นที่ดึงจาก filter ดังนั้นคุณภาพ dashboard = คุณภาพ JQL · ออกแบบรอบ "คนอ่านต้องตัดสินใจอะไร"

LEVEL 4 · ระดับเทพ

13กลไกภายใน: Schemes & Permissions#

นี่คือบท "Git internals" ของ JIRA — เปิดฝาดูว่า project ที่คุณใช้ทุกวันถูกประกอบขึ้นจากอะไร เข้าใจบทนี้แล้วคุณจะเลิกงงว่า "ทำไมแก้ workflow ของ project นี้แล้วอีก project เปลี่ยนตาม" และตอบได้ว่าควรแก้ตรงไหน

13.1 ความลับ: project ไม่ได้ "เป็นเจ้าของ" การตั้งค่า มันแค่ "ชี้ไปหา" scheme

คนส่วนใหญ่คิดว่าการตั้งค่าทุกอย่างฝังอยู่ใน project แต่ความจริงคือ project เป็นเพียงตัวรวมที่ชี้ (point) ไปยังชุดการตั้งค่าที่ใช้ร่วมกันได้ ที่เรียกว่า scheme — scheme หนึ่งตัวถูกหลาย project ใช้ร่วมกันได้ นี่คือเหตุผลที่แก้ที่เดียวกระทบหลาย project

13.2 scheme หลักที่ต้องรู้จัก

• Workflow scheme — แมปว่า issue type ไหนใช้ workflow ตัวไหน (bug อาจมีขั้นตอนต่างจาก story)
• Issue type scheme — project นี้อนุญาต issue type อะไรบ้าง
• Screen scheme — ตอน create/edit/view ผู้ใช้เห็นฟิลด์ชุดไหน
• Field configuration scheme — ฟิลด์ไหนบังคับกรอก/ซ่อน/มีคำอธิบาย
• Permission scheme — ใครทำอะไรได้ในระดับ project (ดูข้อ 13.4)

13.3 สองระดับของการรวมศูนย์ config

Project ทุกใบเลือกได้ว่าจะตั้งค่า (scheme ต่าง ๆ ในข้อ 13.2) แบบรวมศูนย์ที่ใช้ร่วมกับ project อื่น หรือแบบแยกอิสระเฉพาะตัวเอง — นี่คือข้อตัดสินใจเรื่อง "ใครควบคุม config" ไม่ใช่ความต่างเรื่องฟีเจอร์ ปัจจุบัน JIRA เรียกสองโหมดนี้ว่า Company-managed (รวมศูนย์) กับ Team-managed (แยกอิสระ) — ชื่อนี้เคยเปลี่ยนมาแล้วครั้งหนึ่ง (จาก Classic/Next-gen เมื่อปี 2021) จึงควรจำ "หลักการรวมศูนย์ vs แยกอิสระ" เป็นแกนหลัก มากกว่าจำชื่อที่อาจเปลี่ยนอีกในอนาคต:

13.4 ลำดับชั้นของ Permission

สิทธิ์ใน JIRA ซ้อนกันเป็นชั้น เข้าใจลำดับนี้แล้วจะ debug ปัญหา "ทำไมฉันกดไม่ได้" ได้:

• Global permission — สิทธิ์ระดับทั้งระบบ (เช่น เป็น admin ได้ไหม)
• Project role — บทบาทในแต่ละ project (Administrator / Developer / Viewer) — เป็น "ตัวแปร" ที่ permission scheme อ้างถึง
• Permission scheme — แมป action (เช่น "transition issue", "delete") เข้ากับ role
• Issue security level — ซ่อน issue บางใบไม่ให้บางกลุ่มเห็น แม้อยู่ project เดียวกัน

ตัวอย่างจริง: บริษัท 200 คน แบ่ง 5 ทีม แต่ละทีมมี project ตัวเอง ต้องการให้ ทีม A เห็นแค่ project ของตัวเอง แต่ QA ต้องเห็นทุก project — โจทย์นี้แก้ด้วยการเลือกใช้ project role กับ group คนละแบบอย่างตั้งใจ:

• ทั้ง 5 project ใช้ permission scheme เดียวกัน (แชร์ scheme ได้ตามข้อ 13.1) ซึ่งให้สิทธิ์ "Browse Projects" กับ project role ชื่อ "Team Member"
• แต่ละ project เติมสมาชิกลง role "Team Member" เฉพาะคนของทีมตัวเอง — role เป็น container ที่ผูกกับ project ใบเดียว ทีม A จึงเห็นแค่ project ตัวเองโดยอัตโนมัติ โดยไม่ต้องแตะตัว scheme เลยสักครั้ง
• ส่วน QA ให้สิทธิ์ "Browse Projects" กับ group "qa-team" ตรง ๆ ใน scheme เดียวกัน แทนที่จะผ่าน role — เพราะ group เป็นของกลางระดับทั้งระบบ ไม่ผูกกับ project ใบใดใบหนึ่งเหมือน role แค่เพิ่มคนเข้า group เดียว ก็เห็นทุก project ที่ใช้ scheme นี้ทันที ไม่ต้องไล่เติมทีละ project

🧭 เลือก role หรือ group — ใช้ project role เมื่อสิทธิ์ต้องต่างกันไปตาม project (เช่นทีม A เห็นแค่ของตัวเอง) · ใช้ group เมื่อสิทธิ์ต้องเหมือนกันทุก project (เช่น QA เห็นหมด) — ผสมสองแบบในสคีมเดียวกันได้ นี่คือเหตุผลที่ permission scheme ตัวเดียวรองรับทั้งองค์กรได้ โดยไม่ต้องสร้าง scheme แยกทีละทีม

✅ สรุปบทที่ 13 — project ไม่ได้เป็นเจ้าของ config มันชี้ไปหา scheme ที่ใช้ร่วมกันได้ — แก้ scheme = กระทบทุก project ที่ชี้มา · scheme หลัก: workflow / issue type / screen / field config / permission · config รวมศูนย์ (company-managed, admin คุม) vs แยกอิสระ (team-managed, ทีมคุม) — จำหลักการนี้ไว้ ชื่อเปลี่ยนได้เสมอ · permission ซ้อนชั้น: global → role → scheme → issue security

14Automation — ให้ JIRA ทำงานซ้ำ ๆ แทน#

งานน่าเบื่อที่ทีมทำมือซ้ำ ๆ — ย้ายสถานะ, มอบหมายงาน, แจ้งเตือน, ยกงานค้างข้าม sprint — ยกให้ Automation ทำแทนได้หมด และใน Jira Cloud มันมาในตัว ไม่ต้องลง plugin

14.1 โครงของทุก rule: Trigger → Condition → Action

Automation rule ทุกตัวอ่านได้เป็นประโยคเดียว: "เมื่อ (trigger) ถ้า (condition) ให้ (action)"

14.2 Smart values — หยิบข้อมูลจาก issue มาใช้

Smart value คือตัวแปรที่ดึงค่าจาก issue ที่ trigger เข้ามา เขียนในรูป {{...}} ทำให้ action ปรับข้อความ/ค่าได้ตามแต่ละ issue เช่น {{issue.key}}, {{issue.assignee.displayName}}, {{now.plusDays(3)}}

14.3 สูตร Scrum ยอดฮิต

✅ สรุปบทที่ 14 — Automation มากับ Jira Cloud ในตัว · ทุก rule = trigger (เมื่อ) → condition (ถ้า) → action (ให้ทำ) · smart value {{issue.key}} ดึงข้อมูลมาปรับ action ต่อ issue · สูตรฮิต: carry-over, auto-assign, ปิด parent, เตือน bug ค้าง · ระวัง loop + ตรวจ audit log

15Integration & บทสรุป#

JIRA แข็งแกร่งที่สุดเมื่อไม่ได้อยู่โดดเดี่ยว บทสุดท้ายรวมการเชื่อมต่อที่ใช้บ่อย และตกผลึกเป็นหลักคิดที่พาคุณข้ามจาก "ใช้เป็น" ไปสู่ "ใช้ดี"

15.1 เชื่อมกับโค้ดและเอกสาร

• Bitbucket / GitHub / GitLab — เมื่อ commit, branch, หรือ PR อ้างถึง คีย์ issue (เช่น SHOP-142 ในข้อความ commit) มันจะโผล่ใน development panel ของการ์ดนั้นเอง — เห็นได้ทันทีว่า story นี้มีโค้ดอะไรผูกอยู่ และ merge แล้วหรือยัง
• Confluence — ลิงก์สเปก/หน้าออกแบบเข้ากับ epic หรือ story โดยตรง, ฝังรายการ issue สด ๆ ในหน้าเอกสารได้ (หน้าเอกสารจะอัปเดตสถานะ issue ให้เองแบบเรียลไทม์ ไม่ต้องกลับมาก็อปสถานะซ้ำ)
• Slack / Teams — ส่งแจ้งเตือนเข้าแชนเนล หรือสร้าง issue จากข้อความได้

🧭 มินิเคส: จาก story กลับไปปิด issue — Dev เปิด story SHOP-142 เห็นลิงก์ Confluence แนบอยู่ → คลิกเข้าไปอ่านสเปก "หน้าชำระเงิน v2" เต็ม ๆ ที่ Confluence (รายละเอียดที่ไม่มีที่พอในฟิลด์ description สั้น ๆ) → ทำงานตาม acceptance criteria ที่ระบุไว้ในหน้านั้น → กลับมาที่ JIRA transition SHOP-142 เป็น Done — สเปกอยู่ที่เดียว (Confluence) งานอยู่ที่เดียว (JIRA) เชื่อมกันด้วยลิงก์ ไม่ต้องคัดลอกสเปกมาแปะซ้ำในการ์ดจนหลุดจาก source of truth ทันทีที่สเปกอัปเดต — นี่คือเหตุผลที่เล่มต่อไปทั้งเล่มพูดถึงเรื่องนี้โดยเฉพาะ

15.2 ย้ายข้อมูลเข้า JIRA (Migrate & Import)

แทบทุกทีมไม่ได้เริ่มต้นบน JIRA ตั้งแต่วันแรก — มาจาก Trello, Excel, หรือ JIRA instance เก่าที่ต้องย้ายข้อมูลมาโดยไม่อยากเริ่มนับหนึ่งใหม่ JIRA มีเครื่องมือรองรับต่างกันไปตามต้นทาง:

• จาก Trello — Jira Cloud มี Trello importer ในตัว ดึงข้อมูลจากบัญชี Trello ตรง ๆ (ต้องมีสิทธิ์ระดับ admin ของ site/องค์กร) เลือก workspace/board ที่จะย้าย จับคู่ผู้ใช้ด้วยอีเมล แล้วตั้งชื่อ project ใหม่ใน JIRA ให้เลย
• จาก Excel/CSV หรือระบบอื่น — export ข้อมูลต้นทางเป็นไฟล์ CSV แล้วใช้ตัว CSV importer ของ JIRA แมปแต่ละคอลัมน์เข้ากับฟิลด์ปลายทางเอง (summary, assignee, status ฯลฯ) ยืดหยุ่นที่สุดเพราะใช้ได้กับข้อมูลจากที่ไหนก็ได้ที่ export เป็นตารางได้
• จาก JIRA instance เดิม (Server/Data Center → Cloud) — ใช้ Jira Cloud Migration Assistant เครื่องมือทางการของ Atlassian ที่ติดตั้งเป็นแอปฝั่ง Server/Data Center แล้วรัน pre-migration check ก่อนย้ายจริง เลือกได้ว่าจะย้ายทีละส่วนหรือย้ายทั้งหมดทีเดียว

15.3 Marketplace

สิ่งที่ JIRA ไม่มีในตัว มักมีใน Atlassian Marketplace เช่น time tracking ละเอียด, แผนภาพ dependency, หรือ template — แต่ก่อนลง app ทุกตัว ถามก่อนว่า "ปัญหานี้แก้ด้วย automation/JQL ที่มีอยู่แล้วได้ไหม" บ่อยครั้งได้ และ app ทุกตัวมีต้นทุนดูแล

15.4 Anti-patterns — กับดักที่เจอบ่อย

15.5 เส้นทางสู่ Hero — ตกผลึก

ถ้าจะสรุปทั้งเล่มเป็นไม่กี่ประโยค:

• ทุกอย่างคือ issue + ฟิลด์ — เข้าใจข้อนี้แล้ว board/sprint/JQL/report ล้วนเดาออก
• workflow คือกฎการไหล — board แค่ทำให้มันมองเห็น
• Scrum วัดจังหวะด้วย sprint คงที่ + velocity จริง — ไม่ใช่เครื่องมือกดงาน
• JQL คือกุญแจ — board, dashboard, automation ทั้งหมดวางอยู่บนมัน
• หลังบ้านคือ scheme ที่ project ชี้ไปหา — รู้ตรงนี้คือควบคุม JIRA ได้จริง

✅ สรุปบทที่ 15 — เชื่อม Bitbucket/GitHub ด้วยคีย์ issue → เห็นโค้ดในการ์ด · Confluence ผูกสเปกกลับเข้า issue ได้โดยตรง · ย้ายข้อมูลเข้า JIRA มีทางรองรับทั้งจาก Trello, CSV, และ JIRA instance เดิม (Migration Assistant) · ลง app ต่อเมื่อ JQL/automation ทำไม่ได้ · หลีกเลี่ยง anti-pattern: ฟิลด์/สถานะล้น, velocity เป็น KPI, ยัดงานกลาง sprint · แก่นของ JIRA = issue+ฟิลด์ · workflow · sprint+velocity · JQL · scheme

เล่มต่อไป: Confluence & งานเอกสารทีม#

คุณติดตามงานใน JIRA ได้คล่องแล้ว แต่ "ทำไมเราถึงทำงานชิ้นนี้", "สเปกคืออะไร", "ตัดสินใจอะไรไปแล้วบ้าง" — ความรู้พวกนี้ควรอยู่ใน Confluence ที่ผูกกลับเข้ากับ issue เล่มต่อไปจะพาเข้าใจว่าเอกสาร, สเปก, และ knowledge base ควรอยู่ร่วมกับ JIRA ยังไงให้ทีมไม่ต้องถามซ้ำ — เล่ม Confluence — เร็ว ๆ นี้

🧭 ก่อนไปต่อ — ลองตั้ง automation สัก 1 rule ที่ทีมคุณทำมือซ้ำบ่อยสุด (เช่น carry-over) แล้วสร้าง dashboard 1 หน้าจาก saved filter ของคุณเอง — สองอย่างนี้คือก้าวแรกจาก "ผู้ใช้" สู่ "เจ้าของกระบวนการ"

อ่านต่อ: Git Handbook#

JIRA 0 → Hero — คู่มือฉบับเข้าใจถึงแก่น · เน้น Scrum · อิง Jira Cloud

เขียนในสไตล์เดียวกับชุด คู่มือฉบับเข้าใจถึงแก่น — เน้นแบบจำลองความคิดมากกว่าการท่องเมนู · ส่วนหนึ่งของ Handbooks — เขียนเพื่อเข้าใจ ไม่ใช่เพื่อท่องจำ · โดย @tayakorn221 · 2026