ตั๋วถูกเขียนไว้เรียบร้อยแล้ว มีทั้งหัวข้อ คำอธิบาย เกณฑ์การยอมรับ และตำแหน่งใน sprint สิ่งเดียวที่ขวางกั้นระหว่างตั๋วใบนั้นกับ diff คือคนคนหนึ่งที่ต้องเปิดเทอร์มินัล วางตั๋วลงใน coding agent คอยดูมันรัน แล้วคัดลอกผลลัพธ์กลับเข้า Jira ด้วยมือ ตัวงานกับบันทึกของงานอยู่ในคนละหน้าต่าง และการทำให้ทั้งสองตรงกันก็กินเวลาทั้งบ่ายของใครสักคน
การมอบหมายตั๋ว Jira ให้ AI agent คือการปิดช่องว่างนั้น ตั๋วจะกลายเป็นหน่วยของงานที่ agent หยิบไปทำได้ รันกับ repository ของคุณ และส่งกลับมาเป็น change ที่ตรวจสอบได้ โดยไม่ต้องออกจากระบบ tracker ที่ทีมคุณใช้อยู่แล้ว คุณไม่ต้องย้ายทีมออกจาก Jira แต่เพิ่มชั้นที่ทำให้ตั๋วถูกนำไปทำงานได้จริง
ชั้นนั้นคือ Sharkly แพลตฟอร์มสั่งการและบริหารจัดการ Agent แบบครบวงจรในตัวเดียว เชื่อมต่อกับ Jira เปลี่ยน issue ให้กลายเป็น Task ที่มอบหมายได้ ส่งต่อไปยัง coding agent ของคุณ (Claude Code, Codex, Gemini และเครื่องมือ command-line อื่น ๆ) รันแต่ละงานแยกจากกัน และส่งผลลัพธ์กลับไปที่ Task คู่มือนี้จะพาดูวงจรทั้งหมด ตั้งแต่ตั๋วเข้ามา มอบหมาย Agent งานรันใน worktree ที่แยกออกมา ไปจนถึง pull request และการสนทนาที่กลับเข้าไปอยู่ในบันทึก
วงจรทั้งหมดในหนึ่งประโยค
Task ใน Sharkly คือบันทึกกลางของงานหนึ่งชิ้น และเมื่อคุณเชื่อมต่อ Jira แล้ว issue แต่ละใบใน Jira จะกลายเป็น Task หนึ่งอัน จากตรงนั้นข้อตกลงก็ง่ายมาก: Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนเป็นผู้กำหนดทิศทาง ให้อำนาจ และตัดสินใจรับผลลัพธ์ ที่เหลือของบทความนี้เป็นเพียงกลไกเบื้องหลังประโยคนั้น
เก็บ Jira ไว้ แล้วเพิ่มเลเยอร์สำหรับรันงาน
Sharkly ไม่ได้มาแทน Jira แต่เพิ่มชั้นของ Task กลาง Computer ที่เชื่อมต่อ การรันงาน และการรีวิว เข้าไปรอบ ๆ tracker ที่ทีมคุณใช้อยู่แล้ว ไม่มีใครต้องเรียนรู้บอร์ดใหม่หรือย้าย backlog เพื่อเริ่มต้น
คุณเชื่อมทั้งสองเข้าด้วยกันผ่าน sync link เปิดการเชื่อมต่อ Jira แล้วเชื่อมบัญชี (Jira Cloud ใช้ host *.atlassian.net ของคุณ อีเมลบัญชี และ Atlassian API token ส่วน Server และ Data Center ใช้ base URL ชื่อผู้ใช้ และ personal access token) จากนั้นจับคู่ Jira project หนึ่งอันกับ Sharkly Space หนึ่งอัน การแมปหลัก ๆ ก็เป็นอย่างที่คุณคาดไว้:
- Jira issue กลายเป็น Sharkly Task
- Jira epic กลายเป็น Sharkly Project
- ผู้รับผิดชอบ สถานะ ความคิดเห็น และไฟล์แนบถูกส่งข้ามมาด้วย
นี่คือทางเลือกสองทางที่ต้องตัดสินใจให้ชัด ใช้ sync เมื่อคุณต้องการให้โปรเจกต์ที่ยังใช้งานอยู่เชื่อมกันแบบสด ๆ การเปลี่ยนแปลงจะไหลไปมาระหว่าง Jira กับ Sharkly ตั้งแต่นั้นเป็นต้นไป ใช้ import เมื่อคุณต้องการคัดลอก issue ในอดีตเข้ามาเพื่อการย้ายข้อมูลแบบควบคุมไว้ เพราะ sync เพียงอย่างเดียวไม่ได้ดึงข้อมูลย้อนหลังของโปรเจกต์กลับมา ทีมส่วนใหญ่ที่เพิ่งเริ่มจะต้องการแค่ sync link แบบสองทางบนโปรเจกต์ที่ใช้งานอยู่หนึ่งอันเท่านั้น การตั้งค่าฉบับเต็ม รวมถึงขั้นตอน webhook ที่ผู้ดูแล Jira ต้องทำครั้งเดียว มีอยู่ในเอกสารของ Sharkly
มอบหมายตั๋วให้ Agent
เมื่อโปรเจกต์เชื่อมกันแล้ว issue จะปรากฏเป็น Task ใน Space การมอบหมายให้ Agent ก็ทำเหมือนกับการมอบหมายให้เพื่อนร่วมงาน เพียงแต่คุณเลือก Agent แทนที่จะเลือกคน
Agent ไม่ใช่แค่การเลือกโมเดล คำสั่ง Runtime repository และการตั้งค่าการรันของมันเป็นตัวกำหนดว่ามันจะจัดการงานอย่างไร เช่นเดียวกับที่คำบรรยายลักษณะงานกำหนดว่าพนักงานใหม่จะทำอะไรบ้าง Runtime คือเครื่องยนต์ที่อยู่เบื้องหลัง ไม่ว่าจะเป็น Claude Code, Codex หรือ CLI agent ตัวไหนก็ตามที่ทีมคุณใช้อยู่ การใช้งานโมเดลยังคงเดินผ่าน subscription หรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้น แปลว่าการเข้าถึง agent และโค้ดของคุณยังอยู่บนฮาร์ดแวร์ของคุณเอง Sharkly แค่ประสานการมอบหมาย ไม่ได้เข้าไปถือครอง credential ของคุณ
ถ้านี่เป็นการรันครั้งแรก ให้จำกัดขอบเขตให้เล็กและกำหนดเส้นแบ่งให้ชัดเจน การเขียนงานที่ agent รันได้จริงเป็นทักษะเฉพาะอย่าง และควรทำให้ถูกตั้งแต่ก่อนจะให้ Agent ไปแตะงานที่สำคัญต่อระบบ ตั๋วที่กระชับพร้อม definition of done ที่ชัดเจนย่อมได้ diff ที่กระชับ ส่วนตั๋วที่คลุมเครือก็ได้ diff ที่คลุมเครือเช่นกัน
รันงานใน worktree ที่แยกออกจากกัน
เมื่อ Agent เริ่มทำงาน การรันจะเกิดขึ้นบน Computer ที่เชื่อมต่อไว้ ภายใน worktree ที่แยกออกมาเป็นของตัวเอง การแยกส่วนนี้เองที่ทำให้ทำซ้ำได้อย่างปลอดภัย แต่ละครั้งของการรันจะได้ working directory ใหม่เอี่ยม ดังนั้น Agent สองตัวที่ทำสองตั๋วบน repository เดียวกันจึงไม่มีทางเขียนทับไฟล์ของกันและกันหรือแย่ง branch กัน นี่เป็นวินัยแบบเดียวกับที่คุณใช้กับ git worktrees สำหรับ AI coding agents ด้วยมือ เพียงแต่คราวนี้ระบบจัดการให้ทั้งหมด และทำซ้ำได้กับทุก Task
นี่ก็เป็นสิ่งที่ทำให้ workflow ขยายเกินหนึ่งตั๋วได้เช่นกัน พอการแยกส่วนกลายเป็นเรื่องอัตโนมัติ การรัน agent หลายตัวพร้อมกัน ก็ไม่ใช่การเล่นกลอีกต่อไป เพราะสิ่งที่มักทำให้พัง (state ที่ใช้ร่วมกันบนดิสก์) ถูกออกแบบให้ไม่เกิดขึ้นตั้งแต่แรก ถ้าคุณเพิ่งเริ่มรู้จักโมเดลนี้ การมอบหมายงานแรกให้ AI agent เป็นทางลาดที่นุ่มนวลกว่า ก่อนที่คุณจะไปเชื่อมกับ Jira
ดึง PR กลับเข้าสู่บันทึกงาน
งานของ Agent กลับมาอยู่ใน Task ทั้งการสนทนา log การรัน อุปสรรคที่เจอ และ change ที่ได้ ล้วนไปรวมอยู่ที่เดียว แทนที่จะกระจัดกระจายอยู่ระหว่างเทอร์มินัลกับเธรดแชต เมื่อ Agent เปิด pull request คุณเชื่อมมันเข้ากับ Task ได้โดยเขียน Task ID ลงในชื่อ branch ชื่อ PR หรือเนื้อความของ PR GitHub integration ของ Sharkly จะเห็น ID นั้น เชื่อม pull request เข้ากับ Task และสามารถฝากคอมเมนต์ลิงก์กลับได้ เพื่อให้ใครก็ตามที่ดูตั๋วอยู่กระโดดไปดูโค้ดได้ทันที
เพราะ sync link ของ Jira เป็นแบบสองทาง กิจกรรมเหล่านั้นจึงไหลกลับไปยัง issue ต้นทางด้วย คนที่เปิดตั๋วเห็นงานเดินหน้าได้โดยไม่ต้องเปิดเทอร์มินัลเลยสักครั้ง นี่คือผลตอบแทนของการส่งงานผ่าน Task กลางแทนที่จะเป็น prompt ส่วนตัว เพราะ context ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิว ยังมองเห็นได้ตลอดทางตั้งแต่ตอนส่งคำขอจนถึงตอนปล่อยของ
เส้นแบ่งที่ตรงไปตรงมา: คนเป็นผู้ตัดสินใจรับงาน
ไม่มีอะไร merge ตัวเองได้ นี่เป็นความตั้งใจ และควรพูดให้ชัดเพราะผู้อ่านอาจเข้าใจไปทางอื่น: การ merge pull request ไม่ได้เปลี่ยนสถานะของ Task และไม่เคยเกิดขึ้นโดยอัตโนมัติ ระบบอัตโนมัติจะหยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม
การแบ่งหน้าที่นี้คงอยู่ไปจนถึงขั้นตอนสุดท้าย Agent ลงมือทำงาน เปิด PR และรายงานว่ามันทำอะไร ตรวจสอบอะไรไปแล้ว และตรงไหนที่ยังไม่มั่นใจ คนเป็นผู้อ่าน diff เทียบกับเกณฑ์การยอมรับเดิม ขอให้แก้หรือรับงาน และตัดสินใจเรื่อง merge กับ release agent ยินดีเติมความเงียบด้วยการริเริ่มทำอะไรเองเสมอ ขั้นตอนรีวิวจึงไม่ใช่พิธีกรรม แต่เป็นกลไกควบคุมที่ทำให้ส่วนอัตโนมัตินั้นน่าเชื่อถือ การรับงานขั้นสุดท้ายและการตัดสินใจปล่อยของยังคงเป็นของคน
นั่นคือวงจรทั้งหมด ตั๋ว Jira เข้ามา Agent หยิบไปทำ งานรันแบบแยกส่วนแล้วกลับเข้าสู่บันทึกเป็น pull request ที่คุณอ่านได้ และคุณตัดสินใจว่าจะปล่อยหรือไม่ ถ้าอยากมองภาพกว้างขึ้นว่านี่เข้ากับทีมของ agent หลายตัว ไม่ใช่แค่การรันครั้งเดียวได้อย่างไร อ่าน AI agent orchestration หมายความว่าอะไรสำหรับทีมพัฒนา หรือดูภาพรวม Sharkly สำหรับทั้งแพลตฟอร์ม
ถ้าอยากลองกับตั๋วจริงสักใบ: ดาวน์โหลด Sharkly ลงชื่อเข้าใช้ที่ app.sharkly.ai เชื่อมต่อ Computer และเชื่อม Jira project ที่ความเสี่ยงต่ำสักหนึ่งอัน
คำถามที่พบบ่อย
Sharkly มาแทน Jira หรือเปล่า? ไม่ครับ Sharkly เพิ่มชั้นการรันงานและการรีวิวเข้าไปรอบ ๆ Jira ส่วน issue, epic, สถานะ และ workflow ของคุณยังอยู่ที่เดิม โดยมี sync link คอยเชื่อมให้ทั้งสองฝั่งต่อกันในขณะที่ Agent ขับเคลื่อนงานให้เดินหน้า
ใช้ได้กับ Jira เวอร์ชันไหนบ้าง? ได้ทั้งคู่ Jira Cloud เชื่อมต่อด้วย host อีเมลบัญชี และ Atlassian API token ส่วน Jira Server และ Data Center เชื่อมต่อด้วย base URL ชื่อผู้ใช้ และ personal access token
ต้องย้าย backlog ก่อนไหม? ไม่ต้อง sync link เชื่อมต่อโปรเจกต์ที่ใช้งานอยู่และทำให้การเปลี่ยนแปลงในอนาคตไหลเวียนได้โดยไม่ต้อง import ประวัติ ให้ใช้ import แยกต่างหากเฉพาะเมื่อคุณต้องการคัดลอก issue ในอดีตเข้ามาจริง ๆ
merge pull request แล้วตั๋วจะปิดไหม? ไม่ครับ การ merge PR ไม่เปลี่ยนสถานะของ Task เพราะออกแบบไว้แบบนั้น คนเป็นผู้รับผลลัพธ์และตัดสินใจขั้นตอน merge กับ release ดูการมอบหมายงานแรกให้ AI agent เพื่อทำความเข้าใจว่าวงจรรีวิวทำงานอย่างไร
โค้ดและการเข้าถึงโมเดลของฉันอยู่ที่ไหน? อยู่บนฮาร์ดแวร์ของคุณเอง Agent รันบน Computer ที่คุณเชื่อมต่อ โดยใช้ subscription หรือ API key ที่ตั้งค่าไว้แล้วในเครื่องมือเขียนโค้ดของคุณ Sharkly ประสานการมอบหมาย context และการรีวิว แต่ไม่ได้โฮสต์ repository หรือโควตาโมเดลของคุณ
