การวางแผน Sprint สำหรับทีมที่ประกอบด้วยมนุษย์และเอเจนต์จะได้ผลก็ต่อเมื่อคุณวางแผนโดยยึด "กำลังการตรวจทาน" เป็นตัวตั้ง ไม่ใช่ความเร็วในการลงมือทำ เอเจนต์รับและปิด Task ได้มากกว่าที่ผู้ตรวจทานจะ accept ไหว ดังนั้นข้อจำกัดจริงของแต่ละรอบคือจำนวนงานที่เสร็จแล้วซึ่งคนหนึ่งคนตรวจสอบและ merge ได้ ไม่ใช่ว่าเขียนโค้ดได้มากแค่ไหน คู่มือนี้จะพาไปทีละขั้นของวิธีการวางแผน ระบุโหมดความล้มเหลวในแต่ละขั้น และปิดท้ายด้วยเช็กลิสต์ที่คุณใช้ตรวจก่อนเริ่ม Sprint ถัดไป
การวางแผน Sprint แบบดั้งเดิมตั้งอยู่บนสมมติฐานว่าทรัพยากรที่หายากคือชั่วโมงของวิศวกรที่ใช้เขียนโค้ด พอเพิ่มเอเจนต์เขียนโค้ดเข้ามา สมมติฐานนั้นก็พังทันที Claude Code, Codex และ Gemini CLI ต่างรับ Task แล้วส่ง diff ที่ใช้งานได้กลับมา ระหว่างที่คุณยังอ่านอันก่อนหน้าไม่ทันจบด้วยซ้ำ การลงมือทำจึงไม่ใช่คอขวดอีกต่อไป — การ accept ต่างหากที่เป็น
การเปลี่ยนแปลงนี้ทำลายแผนปกติแบบเงียบ ๆ คุณประเมินรอบสองสัปดาห์จาก developer-days แต่เอเจนต์รื้อ backlog หมดภายในสามวัน และคิวงานที่เสร็จแล้วแต่ยังไม่ได้ตรวจทานก็พอกพูนขึ้นข้างหลังมนุษย์หนึ่งหรือสองคนที่ accept merge ได้ Sprint จึงดูเร็วตอนเริ่ม แต่จบช้า
Sharkly คือ workspace ที่คู่มือนี้ใช้วางแผนอยู่ข้างใน คุณมีเอเจนต์เขียนโค้ดอยู่แล้ว Sharkly เปลี่ยนพวกมันให้กลายเป็นทีม ด้วยการเก็บทุก Task ความคืบหน้า อุปสรรค ผลลัพธ์ และการตรวจทานโดยมนุษย์ไว้ในที่เดียวที่ใช้ร่วมกัน แทนที่จะกระจายอยู่ตาม terminal ต่างๆ กัน Sprint ใน Sharkly คือชุดของ Task ที่จำกัดเวลาและเป็นของ Space หนึ่ง วิธีด้านล่างนี้ใช้เหมือนกันไม่ว่าคุณจะทำบนไวท์บอร์ดหรือในตัวผลิตภัณฑ์ แต่โหมดความล้มเหลวจะจับได้ง่ายขึ้นเมื่องานกลับมาอยู่บนบอร์ดที่ใช้ร่วมกัน
อะไรเปลี่ยนไปเมื่อเอเจนต์เป็นตัวลงมือทำ
การวางแผน Sprint สำหรับทีมมนุษย์-เอเจนต์ คือการกำหนดขอบเขตของรอบการทำงานจากปริมาณงานที่เอเจนต์ทำเสร็จซึ่งมนุษย์ตรวจทานและ accept ได้ ไม่ใช่จากปริมาณโค้ดที่ทีมผลิตได้
เอเจนต์ค้นคว้า ลงมือทำ ทดสอบ และรายงานผล ส่วนคนกำหนดทิศทาง มอบอำนาจ และ accept ผลลัพธ์ การแบ่งงานแบบนี้คือโจทย์การวางแผนทั้งหมด ปริมาณงานของเอเจนต์ยืดหยุ่นได้ คุณจะรันสามตัวหรือสิบตัวก็ได้ แต่ปริมาณการตรวจทานของคุณถูกจำกัดตายตัวด้วยจำนวนคนที่อ่าน diff ได้ รันการเปลี่ยนแปลง และตัดสินใจว่า ship ได้ ดู คณิตศาสตร์ของกำลังการตรวจทาน ว่าทำไมผลผลิตของเอเจนต์ที่พุ่งขึ้น 5 เท่าจึง rarely หมายความว่างานที่ ship ออกไปจะเพิ่ม 5 เท่าตาม
ตัวเลขตัวแรกที่คุณใช้วางแผนจึงไม่ใช่ story point แต่คือ "ช่องการตรวจทาน" (review slots) ว่า Task ที่เสร็จแล้วแต่ละผู้ตรวจทาน accept ได้กี่ชิ้นต่อวัน คูณจำนวนผู้ตรวจทาน คูณจำนวนวันในรอบการทำงาน ทุกอย่างที่เหลือต้องอยู่ใต้เพดานนี้
วางแผน Sprint ทีละขั้น
1. กำหนดเพดานการตรวจทานก่อนเป็นอันดับแรก ประเมินจำนวน Task ที่เสร็จแล้วซึ่งผู้ตรวจทาน accept ได้จริงต่อวัน การตรวจทานงานที่ไม่ใช่เรื่องเล็ก ๆ อย่างจริงจังใช้เวลา 30 ถึง 60 นาที จากนั้นคูณด้วยจำนวนผู้ตรวจทานและจำนวนวันของ Sprint โหมดความล้มเหลว: ข้ามขั้นนี้ วางแผนจากกำลังของเอเจนต์ commit เกินกำลัง แล้วจบรอบด้วยคิวตรวจทานที่ยาวกว่า Sprint เสียอีก
2. กำหนดขนาด Task ให้เหมาะกับการตรวจทาน ไม่ใช่การลงมือทำ แบ่งงานให้แต่ละ Task ได้ diff ที่คนหนึ่งคนถือไว้ในหัวได้ โหมดความล้มเหลว: เอเจนต์ส่งการเปลี่ยนแปลง 2,000 บรรทัดในเก้าไฟล์กลับมาอย่างสบายใจ ไม่มีใคร accept ได้ในช่องเดียว และมันก็เน่าอยู่ก้นบอร์ด
3. เขียนเกณฑ์การยอมรับก่อนมอบหมายงาน ทุก Task ต้องมีนิยามของ "เสร็จ" ที่ทดสอบได้: สร้างอะไร หน้าตาของ "ถูกต้อง" เป็นอย่างไร และห้ามแตะอะไร โหมดความล้มเหลว: ขอบเขตคลุมเครือ เอเจนต์เดา ผู้ตรวจทานส่งกลับ และ Task เดียวก็เผาช่องตรวจทานไปสองช่อง
4. มอบหมายให้ Agent ตัวเดียวหรือ Crew อย่างจงใจ ใช้ Agent ตัวเดียวกับงานเล็กที่นิยามชัดเจน ใช้ Crew เมื่อ Agent หัวหน้าต้องตีความเป้าหมาย ดึงสมาชิกตัวอื่นเข้ามา และรวมผลลัพธ์กลับมาเป็น Task เดียว โหมดความล้มเหลว: เรียกใช้ Crew กับงานจิ๊บจ๊อย เพิ่มชิ้นส่วนที่ต้องเคลื่อนไหว ซึ่งสุดท้ายคุณก็ต้องตรวจทานอยู่ดี
5. จำกัดงานที่ทำค้างอยู่ ใส่ลิมิตว่ามี Task อยู่ในคอลัมน์ "in review" ได้กี่ชิ้น อย่างที่ WIP limit ทำงานในคันบัง โหมดความล้มเหลว: ไม่มีเพดาน เอเจนต์ก็ทะลักเข้าคอลัมน์ตรวจทานเร็วกว่าที่คนจะระบายออก คอขวดยังมองไม่เห็นจนถึงวันสุดท้าย
6. เผื่อช่องว่างสำรองไว้ จองช่องตรวจทานไว้สำหรับงานแก้และคำขอเปลี่ยนแปลงที่คุณจะส่งกลับ โหมดความล้มเหลว: วางแผนเต็ม 100% แล้วรอบแรกของ "ช่วยแก้หน่อย" ก็ไม่มีที่ลง
จุดที่สเปรดชีตหรือระบบที่มีแค่ ticket เริ่มขยายไม่ไหว
คุณรัน Sprint แรกในสเปรดชีตได้ แท็บหนึ่งมีรายการ Task คอลัมน์เจ้าของงาน คอลัมน์สถานะ มันยังไปรอดตราบที่คนหนึ่งคนดูแลเอเจนต์สองตัวบน repo เดียว
มันเลิกใช้ได้ทันทีที่การลงมือทำกับการติดตามแยกออกจากกัน การรันของเอเจนต์, diff, ผลทดสอบ และการพูดคุยอยู่ใน terminal ส่วนสเปรดชีตถือสถานะ "in progress" ที่เก่าแล้ว มีคนอัปเดตแถวนั้นด้วยมือ หรือไม่มีเลย พอเพิ่มเอเจนต์ตัวที่สามและ repo แห่งที่สอง บอร์ดก็เพี้ยนไปจากความจริงภายในหนึ่งวัน จากตรงนั้นคุณจะตอบคำถามเดียวที่การวางแผนต้องพึ่งพาไม่ได้: อะไรเสร็จแล้ว และอะไรกำลังรอฉันอยู่?
task board ที่สร้างมาเพื่อสิ่งนี้จะเก็บการลงมือทำและบันทึกไว้ด้วยกัน งาน ความคืบหน้า อุปสรรค และผลลัพธ์จะย้อนกลับเข้าไปใน Task แทนที่จะหายไปในเซสชันส่วนตัว ใน Sharkly เอเจนต์จะ claim Task ที่พร้อมแล้ว รันใน worktree ที่แยกออกมาเพื่อให้การเปลี่ยนแปลงที่ทำขนานกันไม่ชนกัน และสรุปการเปลี่ยนแปลง ผลการตรวจสอบ และข้อจำกัดที่ทราบ จะกลับเข้าไปในไทม์ไลน์ของ Task ให้คน accept หรือส่งกลับ นี่คือความต่างระหว่างสถานะที่คุณต้องคอยอัปเดต กับสถานะที่ดูแลตัวเองได้ มันยังมอบข้อมูลจริงให้เซสชันวางแผนครั้งถัดไปของคุณด้วย: เอเจนต์ทำงานอะไรเสร็จบ้างในรอบที่แล้ว และเวลาในการตรวจทานหมดไปกับอะไร
พูดตรง ๆ ตามขอบเขตจริง: ถ้าคุณรันเอเจนต์ตัวเดียวบน repo เดียวและตรวจทานไปพร้อมกัน คุณไม่จำเป็นต้องมี task board หรือ Sharkly เลย terminal เดียวกับเช็กลิสต์ก็เพียงพอ สมการจะเปลี่ยนเมื่อคุณวางแผนข้ามเอเจนต์หลายตัว Task หลายรายการ repo หลายแห่ง หรือหลายคน ซึ่งเป็นจุดเดียวกับที่สเปรดชีตกลายเป็นงานที่สอง Sharkly ถูกสร้างมาเพื่อกรณีหลังนี้ ดาวน์โหลดได้เลยเมื่อสเปรดชีตเริ่มโกหกคุณ
เช็กลิสต์ที่ควรตรวจก่อนเริ่ม Sprint ถัดไป
ตรวจสิ่งนี้ก่อนที่คุณจะล็อกแผน:
- [ ] คำนวณเพดานการตรวจทานแล้ว (ผู้ตรวจทาน x จำนวนที่ accept ได้ต่อวัน x จำนวนวัน) และถือเป็นกำลังจริงของ Sprint
- [ ] ทุก Task เล็กพอที่จะตรวจทานจบในหนึ่งช่อง
- [ ] ทุก Task มีเกณฑ์การยอมรับที่ทดสอบได้ และมีขอบเขต "ห้ามแตะ" ที่ชัดเจน
- [ ] แต่ละ Task มอบหมายให้ Agent ตัวเดียวหรือ Crew อย่างจงใจ ไม่ใช่ตามค่าเริ่มต้น
- [ ] มีเพดาน WIP ในคอลัมน์ "in review"
- [ ] เผื่อช่องว่างไว้สำหรับงานแก้และคำขอเปลี่ยนแปลง
- [ ] มีคนรับผิดชอบตัดสินใจ merge และ release ของทุก Task
- [ ] ความคืบหน้า อุปสรรค และผลลัพธ์กลับเข้าบอร์ดที่ใช้ร่วมกัน ไม่ใช่ terminal ส่วนตัว
ทำครบทั้งแปดข้อ การลงมือทำของเอเจนต์ก็จะอยู่ในแผนที่ทีมทำจบได้ พลาดข้อแรก ข้อที่เหลือช่วยคุณไม่ได้
คำถามที่พบบ่อย
การวางแผน Sprint ยังมีประโยชน์อยู่ไหมเมื่อเอเจนต์เขียนโค้ดเกือบทั้งหมด? มี แต่ข้อจำกัดเปลี่ยนที่อยู่ Sprint เลิกเป็นภาชนะสำหรับชั่วโมงงานวิศวกรรม แล้วกลายเป็นภาชนะสำหรับการตรวจทานและการ accept จงวางแผนรอบการทำงานจากปริมาณงานที่เสร็จแล้วซึ่งคนตรวจสอบได้ แล้วเอเจนต์จะเติมเต็มส่วนที่เหลือ Scrum Guide ยังนิยามพิธีกรรมไว้เหมือนเดิม มีแค่คณิตศาสตร์ของกำลังการผลิตที่เปลี่ยนไป
จะประเมินกำลังการผลิตของทีมมนุษย์-เอเจนต์ได้อย่างไร? เริ่มจากผู้ตรวจทาน ไม่ใช่เอเจนต์ นับจำนวน Task ที่เสร็จแล้วซึ่งคนหนึ่งคน accept ได้จริงต่อวัน แล้วคูณด้วยจำนวนผู้ตรวจทานและจำนวนวันของ Sprint จำนวนเอเจนต์สำคัญแค่จนถึงจุดที่ทะลุเพดานนั้น พ้นจากนั้นการเพิ่มเอเจนต์มีแต่ทำให้คิวยาวขึ้น
เอเจนต์ควรเลือก Task เองระหว่าง Sprint ไหม? ปล่อยให้พวกมัน claim Task ที่พร้อมและมีเกณฑ์การยอมรับอยู่แล้ว เพื่อให้งานที่ทำขนานกันเดินหน้าได้โดยไม่ต้องมีคนคอยแจกงาน ให้มนุษย์ดูแลทิศทาง อำนาจ และการ merge แบบนี้ก็จะเหลือ มนุษย์อยู่ในลูปตรงจุดที่ต้องใช้วิจารณญาณ และเป็นอัตโนมัติในที่อื่นทั้งหมด
วิธีนี้ต่างจากการบริหารโครงการทั่วไปอย่างไร? พิธีกรรมดูเหมือนกัน แต่คอขวดไม่เหมือนกัน การบริหารโครงการด้วย AI agent วางแผนจากปริมาณการตรวจทานและการแยกการเปลี่ยนแปลง ไม่ใช่ความพร้อมของนักพัฒนา เพราะการลงมือทำไม่ใช่ทรัพยากรที่หายากอีกต่อไป
ต้องใช้เครื่องมือใหม่ไหม หรือต่อยอดจาก Jira ได้? คุณใช้ระบบที่ทีมเข้าใจอยู่แล้วต่อไปได้ ช่องว่างคือเครื่องมือ ticket ติดตามสถานะที่มนุษย์พิมพ์ ไม่ใช่การลงมือทำที่เครื่องจักรรัน ดู ทางเลือกแทน Jira สำหรับทีมมนุษย์-เอเจนต์ได้ว่าช่องว่างนั้นเริ่มเจ็บตรงไหน
