AI-assisted Sprint Planning: จะเร่งการเตรียมการได้อย่างไรโดยไม่สูญเสียความรับผิดชอบ

นี่คือบทความที่สองในชุดเกี่ยวกับว่า AI เปลี่ยนแปลงการประชุมแบบคลาสสิกของทีมพัฒนาข้ามสายงานอย่างไร ในบทความแรกผมได้วิเคราะห์ Backlog Refinement และได้ข้อสรุปสำคัญ: AI เร่งความเร็วไม่ใช่ตัวข้อตกลงของทีมเอง แต่เป็นการเตรียมวัสดุสำหรับข้อตกลงนั้น ตอนนี้สมเหตุสมผลที่จะก้าวไปยังขั้นถัดไป — Sprint Planning — และดูว่าจะเร่งการเตรียมการสำหรับมันได้อย่างไรโดยไม่สูญเสียความรับผิดชอบของทีมต่อเป้าหมาย ขอบเขต และความเป็นจริงของสปรินต์

เมื่อมองแวบแรกดูเหมือนว่าหลังจาก refinement ที่ดีแล้ว planning ควรกลายเป็นเกือบจะเป็นพิธีการทางเทคนิค องค์ประกอบของ backlog ได้รับการชี้แจงแล้ว เกณฑ์การยอมรับถูกวาดร่างขึ้น ความเสี่ยงถูกเขียนออกมา คำถามเปิดถูกปิดบางส่วน ทางเลือกของแนวทางทางเทคนิคถูกเตรียมไว้ เหลือเพียงแค่เลือกงานเข้าสปรินต์และกระจายให้คน

แต่นั่นแหละคือกับดัก

Sprint Planning ใน Scrum ไม่ใช่การประชุมเพื่อกระจายงาน เป็นเหตุการณ์ที่ทีมตอบคำถามสำคัญสามข้อ: เหตุใดสปรินต์นี้จึงมีคุณค่า อะไรที่ทำได้จริงภายในสปรินต์ และงานที่เลือกจะถูกดำเนินการอย่างไร และหากมอง AI ผ่านกรอบนี้ จะเห็นสิ่งสำคัญ: AI สามารถช่วยทีมรวบรวมทางเลือกของแผนได้เร็วขึ้น ชี้ให้เห็นการพึ่งพากัน เสนอการแบ่งย่อย และเตรียมคำถามได้จริง แต่ไม่สามารถรับผิดชอบ Sprint Goal แทนได้ และไม่สามารถทำให้แผนเป็นจริงได้ด้วยตัวเอง

“AI ช่วยรวบรวมแผนที่ดูเหมือนเป็นจริง แต่ทีมเท่านั้นที่ทำให้มันเป็นจริงได้”

ในความคิดของผม นี่คือการเปลี่ยนแปลงสำคัญ AI เร่งการเตรียมการสำหรับ Sprint Planning แต่ไม่แทนที่ Sprint Planning เองในฐานะข้อตกลงของทีมเกี่ยวกับเป้าหมาย ขอบเขต และวิธีการส่งมอบ

เหตุใด Sprint Planning จึงไม่ใช่แค่ 'หยิบงานใส่สปรินต์'

ใน Scrum Guide 2020 Sprint Planning ถูกอธิบายว่าเป็นเหตุการณ์ที่เริ่มต้นสปรินต์ ผลลัพธ์ของมันถูกสร้างขึ้นจากความร่วมมือของทีมพัฒนาทั้งหมด

Sprint Planning สร้างขึ้นรอบหัวข้อสามประการ

• เหตุใดสปรินต์นี้จึงมีคุณค่า?
• อะไรที่สามารถทำได้ในสปรินต์นี้?
• งานที่เลือกจะถูกดำเนินการอย่างไร?

นี่คือลำดับที่สำคัญ ไม่ใช่รายการงานก่อน แต่เป็นคุณค่าก่อน ไม่ใช่ 'อะไรที่เราจะปิดได้ทัน' แต่เป็น 'การเปลี่ยนแปลงใดที่เราต้องการได้รับเมื่อสิ้นสุดสปรินต์' ด้วยเหตุนี้ Sprint Goal จึงไม่ใช่บรรทัดตกแต่งใน Jira และไม่ใช่บทสรุปสวยงามของงานที่เลือก มันคือเป้าหมายเดียวของสปรินต์ กล่าวคือเป้าหมายเดียวที่ให้โฟกัสแก่ทีมและช่วยให้ตัดสินใจได้เมื่อมีข้อเท็จจริงใหม่เกิดขึ้นภายในสปรินต์

Sprint Backlog ประกอบด้วยสามส่วน: Sprint Goal ในฐานะ 'ทำไม' องค์ประกอบ backlog ที่เลือกในฐานะ 'อะไร' และ actionable plan ในฐานะ 'อย่างไร' และที่สำคัญเป็นพิเศษคือ Sprint Backlog เป็นแผนที่สร้างโดยนักพัฒนาและเพื่อนักพัฒนา Product Owner ช่วยเตรียมการอภิปรายและเชื่อมโยงงานที่เลือกกับ Product Goal Scrum Master ช่วยให้เหตุการณ์มีประโยชน์และมีประสิทธิผล แต่แผนการดำเนินการและความรับผิดชอบต่อความเป็นจริงของส่วนวิศวกรรมยังคงอยู่ภายในทีมพัฒนา

จากนี้ตามมาด้วยข้อสรุปที่เรียบง่ายแต่สำคัญมากสำหรับการพูดคุยเกี่ยวกับ AI: เครื่องมือสามารถเสนอถ้อยคำของ Sprint Goal รายการองค์ประกอบ backlog เบื้องต้น การพึ่งพากัน ความเสี่ยง และการแบ่งย่อยได้ แต่ไม่สามารถเป็นผู้ถือพันธะสัญญาของทีมได้ ไม่สามารถพูดแทนทีมได้ว่า 'เราพร้อมที่จะรับสิ่งนี้จริงๆ'

AI เปลี่ยนแปลงอะไรจริงๆ ในการ planning

ผมจะระบุขอบเขตของหลักฐานไว้ก่อนเลย วันนี้มีฐานการวิจัยที่แข็งแกร่งเกี่ยวกับ AI-assisted Sprint Planning ในทีม Scrum จริงน้อยมาก มีงานจำนวนมากกว่าอย่างมีนัยสำคัญในหัวข้อที่เกี่ยวข้อง: requirements engineering คุณภาพของ user story การประเมินความพยายาม การสร้างテスト การตัดสินใจของมนุษย์ร่วมกับ AI และการจัดการความเสี่ยงของ AI ดังนั้นจึงถูกต้องกว่าที่จะพูดว่าไม่ใช่ 'AI วางแผนสปรินต์' แต่เป็น 'AI เร่งการรวบรวมแผนร่างที่จะนำมาอภิปรายและช่วยให้ทีมเห็นช่องว่างบางส่วนได้เร็วขึ้น' นี่คือความแตกต่างที่สำคัญ

ก่อนการมาของ AI การเตรียมการสำหรับ Sprint Planning มักเป็นงานที่ทำด้วยมือค่อนข้างมาก Product Owner ดูลำดับความสำคัญล่วงหน้าและพยายามรวบรวมขอบเขตงานเบื้องต้น นักวิเคราะห์ตรวจสอบว่าองค์ประกอบ backlog พร้อมสำหรับการอภิปรายเพียงใด นักพัฒนาระลึกถึงข้อจำกัดทางเทคนิคและงานที่คล้ายกัน QA ยกความเสี่ยงด้านการทดสอบขึ้นมา Scrum Master ดูแลให้การประชุมไม่กลายเป็นการโต้เถียงที่วุ่นวายเกี่ยวกับรายละเอียดที่ควรจะชี้แจงไว้ก่อนหน้านี้

ด้วย AI ชั้นเตรียมการนี้อาจเร็วขึ้นอย่างเห็นได้ชัด โดยมีเงื่อนไขว่าทีมมีบริบทนำเข้าที่มีคุณภาพและกระบวนการตรวจสอบผลลัพธ์ที่ชัดเจน โมเดลสามารถช่วยรวบรวมตัวเลือก Sprint Goal หลายแบบ จัดกลุ่มรายการใน backlog รอบเป้าหมาย เน้นจุดอ่อนของเกณฑ์การยอมรับ เสนอรายการ dependency ค้นหางานที่คล้ายกันในประวัติ ร่างความเสี่ยง และเตรียมคำถามสำหรับ QA, backend, frontend และ design แต่สิ่งนี้ไม่ใช่หลักฐานว่า planning สุดท้ายจะเร็วขึ้นหรือแม่นยำขึ้นเสมอ: ส่วนหนึ่งของกำไรอาจหมดไปกับการตรวจสอบโดยมนุษย์ การตรวจสอบแหล่งที่มา และการแก้ไขข้อผิดพลาดในฉบับร่าง

สิ่งนี้มีประโยชน์เป็นพิเศษเมื่อทีมมาถึง planning หลังจาก AI-assisted refinement ในบทความก่อนหน้านี้ ผมแสดงให้เห็นว่า AI ช่วยเปลี่ยนคำขอที่ยังดิบให้เป็นรายการ backlog ที่สมบูรณ์ขึ้นได้เร็วขึ้น แต่ตอนนี้เกิดคำถามถัดไป: ถ้ารายการ backlog ดูดีขึ้น นั่นหมายความว่าแผนก็ดีขึ้นด้วยหรือไม่

ไม่จำเป็น

AI สามารถทำให้อาร์ติแฟกต์ของการวางแผนเรียบร้อยขึ้นได้ มันสามารถสร้างความรู้สึกว่าทุกอย่างเชื่อมโยงกันแล้ว: นี่คือ Sprint Goal นี่คือขอบเขตงาน นี่คือความเสี่ยง นี่คือ dependency นี่คือบันทึกเกี่ยวกับการทดสอบ แต่นี่ไม่ใช่แผน นี่คือฉบับร่างของแผน และคุณค่าของ Sprint Planning ก็อยู่ที่การที่ทีมตรวจสอบฉบับร่างนี้กับความเป็นจริง

AI ช่วยรวบรวมตัวเลือก Sprint Goal ขอบเขตงาน dependency และความเสี่ยงได้เร็วขึ้น แต่ไม่ทดแทนการตรวจสอบความเป็นจริงของแผนโดยทีม

มาต่อเคสเดิม: B2B LMS และอีเมลแจ้งเตือน

เพื่อไม่ให้พูดแบบนามธรรม ผมจะต่อเคสจากบทความแรก

มีแพลตฟอร์ม B2B LMS สำหรับการฝึกอบรมองค์กร ลูกค้ารายใหญ่กำหนดให้พนักงานเรียนหลักสูตรภาคบังคับด้าน compliance ความปลอดภัย และระเบียบภายใน ธุรกิจต้องการเพิ่มอีเมลแจ้งเตือนอัตโนมัติถึงพนักงานที่ยังเรียนหลักสูตรภาคบังคับไม่จบก่อนกำหนดเวลา

ใน refinement ทีมได้ค้นพบแล้วว่างานนี้ดูเหมือนง่ายเพียงผิวเผิน จริง ๆ แล้วต้องตกลงกันว่า:

• ใครถือว่าเข้าเงื่อนไขสำหรับการแจ้งเตือน;
• จะเอาเฉพาะหลักสูตรภาคบังคับหรือไม่;
• จะนับสถานะใดบ้าง: not_started, in_progress, expired;
• จะยกเว้น archived และผู้ใช้ที่ถูกปิดใช้งานอย่างไร;
• เขตเวลาถูกเก็บไว้ที่ไหน;
• การตั้งค่าภาษาและ fallback ภาษาทำงานอย่างไร;
• จะป้องกันข้อมูลซ้ำเมื่อ task ของ scheduler ทำงานซ้ำอย่างไร;
• ต้องมีบันทึกประวัติ / บันทึกการตรวจสอบหรือไม่;
• ทีมสนับสนุนลูกค้าควรเห็นอะไร;
• ขอบเขตงานขั้นต่ำของเวอร์ชันแรกสิ้นสุดที่ไหน

หลังจาก refinement ที่ดี ทีมอาจมาถึง Sprint Planning พร้อมโครงร่างที่แข็งแรงแล้ว ตัวอย่างเช่น AI ช่วยรวบรวมฉบับร่างของ user story เกณฑ์การยอมรับ รายการกรณีขอบ ตัวเลือกแนวทางเทคนิค และคำถามที่ยังเปิดอยู่ แต่ใน planning ต้องตัดสินใจอีกประเภทหนึ่ง: ทีมจะเอาอะไรเข้าสปรินต์ถัดไปและด้วยเป้าหมายอะไร

Sprint Goal ที่แย่สำหรับเคสนี้ mungkinมีหน้าตาแบบนี้:

“ทำ scheduler, อีเมลแจ้งเตือน และบันทึกประวัติ”

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

ถ้อยคำที่แข็งแรงกว่า:

“ระบบส่งการแจ้งเตือนที่ถูกต้องหนึ่งครั้งถึงพนักงานที่ยังใช้งานอยู่ซึ่งมีหลักสูตรภาคบังคับที่ยังไม่จบก่อนกำหนดเวลา และเก็บประวัติการส่งที่ตรวจสอบได้”

ถ้อยคำนี้ดีกว่าเพราะมีทั้งคุณค่าและขอบเขตอยู่แล้ว เราไม่สัญญาว่าจะมีแผงควบคุมลูกค้าที่สมบูรณ์ ไม่สัญญาตรรกะการแจ้งเตือนที่ซับซ้อน ไม่แก้ข้อโต้แย้งทั้งหมดรอบ expiredในทันที ไม่สร้างการวิเคราะห์ขั้นสูง แต่เราสัญญาผลลัพธ์ที่มีคุณค่าขั้นต่ำ: พนักงานที่ต้องการได้รับการแจ้งเตือนที่ถูกต้อง และทีมสามารถตรวจสอบได้ว่าใคร ได้รับเมื่อไร และทำไมอีเมลจึงถูกส่ง

planning จะเป็นอย่างไรหากไม่มี AI

หากไม่มี AI การประชุมแบบนี้มักเริ่มต้นด้วยการฟื้นบริบท เจ้าของผลิตภัณฑ์เตือนความจำถึงคำขอทางธุรกิจ นักวิเคราะห์เล่าว่าสิ่งใดถูกค้นพบใน refinement backend ชี้แจงว่าบริการแจ้งเตือนทำงานอย่างไร frontend ถามว่าต้องมีหน้าจอตั้งค่าหรือเพียงพอด้วยตรรกะฝั่ง backend QA เริ่มดึงคำถามเกี่ยวกับกำหนดเวลา เขตเวลา ข้อมูลซ้ำ และสถานะ designer พยายามทำความเข้าใจว่ามี UI ในขอบเขตงานแรกหรือไม่

ครึ่งหนึ่งของการประชุมหมดไปกับการยกเนื้อหาขึ้นมาใส่หัวของทีมใหม่ ไม่ใช่การเลือกแผนที่เป็นจริง ในช่วงหนึ่งมีความรู้สึกอยาก “เอาทุกอย่างที่สำคัญ” ไปให้หมด: การเข้าเงื่อนไข, scheduler, เทมเพลตอีเมล, การขจัดข้อมูลซ้ำ / การกำจัดข้อมูลซ้ำ, บันทึกประวัติ, การตั้งค่าภาษา fallback, เขตเวลา, การมองเห็นข้อมูลสำหรับทีมสนับสนุนลูกค้า, การจัดการ expired, การตั้งค่าของลูกค้า และกรณีขอบอีกสองสามอย่าง

ปริมาณงานเช่นนี้อาจดูสมเหตุสมผลในระดับสามัญสำนึก เพราะทุกอย่างล้วนเชื่อมโยงกัน แต่ именно здесь planning начинает распухать ทีมดูเหมือนพูดถึงผลลัพธ์ที่เป็นองค์รวม แต่ในความเป็นจริงกลับรวบรวมทิศทางของความไม่แน่นอนหลายสายที่เป็นอิสระต่อกัน บางจุดความหมายเชิงผลิตภัณฑ์ไม่ชัดเจน บางจุดการดำเนินการทางเทคนิค บางจุดการทดสอบ บางจุด UI บางจุดการสนับสนุน

ผลก็คือเมื่อสิ้นสุดการประชุมอาจมี Sprint Backlog ปรากฏขึ้นซึ่งดูสมบูรณ์แต่ยังเปราะบาง มันถูกสร้างบนความหวังว่าทุกจุดที่เป็นข้อโต้แย้งจะคลี่คลายไปตามระหว่างสปรินต์ บางครั้งก็เป็นเช่นนั้น แต่บ่อยครั้งนี่แหละคือวิธีที่ทีมได้รับงานที่ยังไม่เสร็จสิ้น การขยายขอบเขตงานที่ซ่อนอยู่ และความรู้สึกไม่สบายใจว่า “เราก็คุยกันหมดแล้วนี่”

planning เปลี่ยนไปอย่างไรกับ AI

ด้วย AI การประชุมเดียวกันนี้อาจเริ่มต้นในอีกระดับหนึ่ง

ก่อน planning AI ช่วยให้เจ้าของผลิตภัณฑ์เตรียม Sprint Goal หลายแบบ: เวอร์ชันแรกที่แคบ ปริมาณงานฝั่งลูกค้าที่กว้างขึ้น ปริมาณงานที่ปลอดภัยทางเทคนิค ปริมาณงานที่ทะเยอทะยานแบบขยาย นักวิเคราะห์ขอให้ AI เชื่อมโยงรายการใน backlog กับแต่ละทางเลือกของเป้าหมาย และแสดงว่าอันใดไม่สนับสนุนเป้าหมายโดยตรง ฝั่งแบ็กเอนด์รันคำอธิบายสถาปัตยกรรมการแจ้งเตือนผ่าน AI และขอให้ไฮไลต์ความเสี่ยงของงานตัวจัดตาราง การขจัดข้อมูลซ้ำ และ idempotency ฝั่งฟรอนต์เอนด์และนักออกแบบตรวจสอบว่าต้องมี UI ในสปรินต์แรกหรือไม่ หรือจำกัดเพียงการแสดงประวัติขั้นต่ำ QA ขอให้ AI เตรียมรายการสถานการณ์เชิงลบ สถานการณ์ขอบเขต และสถานการณ์ที่ผูกกับเวลา

ทีมมาถึง planning ไม่ใช่ด้วยกระดาษเปล่า แต่ด้วยชุดทางเลือก:

• ปริมาณงานขั้นต่ำ: คอร์สบังคับ, not_started / in_progress, การยกเว้นผู้ใช้ที่ archived และถูกปิดใช้งาน, การเตือนหนึ่งครั้ง, การขจัดรายการซ้ำ, บันทึกประวัติ;
• ปริมาณงานขยาย: บวกการตั้งค่าภาษาสำรอง (fallback) และนโยบายเขตเวลาที่รอบคอบขึ้น;
• ปริมาณงานทะเยอทะยานแบบขยาย: บวกการมองเห็นสำหรับทีมสนับสนุนลูกค้า;
• นอกขอบเขตงาน: expired, กฎความถี่ที่ซับซ้อน, การวิเคราะห์ขั้นสูง, ตารางเวลารายบุคคลตามลูกค้า

สิ่งนี้ประหยัดงานทางปัญญาได้มาก ตอนนี้ทีมไม่ต้องใช้เวลาส่วนใหญ่ของการประชุมไปกับการกำหนดทางเลือกเป็นครั้งแรกอีกต่อไป ทีมกำลังอภิปรายว่าทางเลือกใดสมจริง ทางเลือกใดสนับสนุน Sprint Goal ได้ดีกว่า และความเสี่ยงใดที่ปล่อยให้ไม่ชัดเจนไม่ได้

แต่ именно здесь появляется новая ловушка แผนที่ AI รวบรวมมาอาจดูเรียบร้อยจนทีมเริ่มไม่ตรวจสอบมัน แต่แก้ไขมัน แทนที่จะถามว่า “เราทำได้จริงหรือ” กลับเพียงปรับถ้อยคำให้ดีขึ้น แทนที่จะโต้แย้งเกี่ยวกับความจุของทีมที่มีอยู่ กลับเชื่อการแบ่งย่อยที่สวยงาม แทนที่จะตรวจสอบการพึ่งพากัน กลับคิดว่าถ้ามันอยู่ในตารางแล้วก็ถือว่าคำนึงถึงแล้ว

และแล้ว AI ก็ไม่ได้ช่วย planning มันเพียงทำให้แผนที่มองโลกในแง่ดีเกินจริงน่าเชื่อถือมากขึ้นเท่านั้น

กับดักหลัก: ความสมจริงลวงของแผน

ใน refinement ความเสี่ยงหลักคือความชัดเจนลวง: งานดูเข้าใจได้เพราะ AI จัดรูปแบบได้สวยงาม ใน Sprint Planning ความเสี่ยงต่างออกไป — ความสมจริงลวง

ความสมจริงลวงเกิดขึ้นเมื่อแผนดูสอดคล้อง สมบูรณ์ และสมเหตุสมผล แต่ไม่ได้ถูกตรวจสอบกับข้อจำกัดจริงของทีม มันมี Sprint Goal รายการงาน การประเมิน การพึ่งพากัน และความเสี่ยง แต่ไม่มีใครตรวจสอบอย่างแท้จริงว่าความจุของทีมที่มีอยู่เพียงพอหรือไม่ มีงานที่ยังไม่เสร็จสิ้นจากสปรินต์ที่แล้วหรือไม่ QA รับภาระเกินไปหรือไม่ ผู้เชี่ยวชาญที่จำเป็นพร้อมหรือไม่ สามารถไปถึง Definition of Done ได้จริงหรือไม่ และส่วนที่ยากที่สุดถูกซ่อนอยู่ใต้คำว่า “integrate”, “เพิ่มการสนับสนุน” หรือ “คำนึงถึงกรณีขอบเขต” หรือไม่

ความเสี่ยงนี้สอดคล้องกับปัญหาที่รู้จักกันดีหลายประการ

ประการแรก — อคติในการวางแผน ทีมมีแนวโน้มอยู่แล้วที่จะประเมินความซับซ้อนของงานในอนาคตต่ำเกินไป โดยเฉพาะเมื่อมองแผน “จากภายใน” และมุ่งเน้นไปที่สถานการณ์ที่ต้องการ AI อาจช่วยได้หากดึงข้อมูลเชิงประวัติ งานที่คล้ายกัน ความล่าช้าในอดีต และสาเหตุทั่วไปของการทำงานที่ยังไม่เสร็จสิ้น แต่ก็อาจเสริมอคติในการวางแผนให้รุนแรงขึ้นได้หากสร้างเรื่องราวที่ราบรื่นน่าเชื่อถือ: “ทุกอย่างดูสอดคล้อง แสดงว่าทุกอย่างสมจริง”

ประการที่สอง — อคติต่อระบบอัตโนมัติ เมื่อระบบเสนอแผนที่เรียบร้อย คนเราจะเปลี่ยนจากโหมดตรวจสอบเชิงรุกไปสู่โหมดเห็นชอบแบบเฉื่อยได้ง่ายขึ้น ทีมไม่ค้นหาความขัดแย้งอย่างกระตือรือร้นอีกต่อไป เพราะ “AI รวบรวมมาหมดแล้ว” สิ่งนี้เป็นอันตรายอย่างยิ่งใน planning ซึ่งคุณภาพของการตัดสินใจไม่ได้ขึ้นอยู่กับความสมบูรณ์ของข้อความ แต่ขึ้นอยู่กับความซื่อสัตย์ในการอภิปรายข้อจำกัด

ประการที่สาม — การหลอนของโมเดลหรือการแต่งเติมข้อมูลเท็จ / การกุเรื่องอย่างมั่นใจ AI อาจสร้างการพึ่งพากันที่ไม่มีอยู่จริงขึ้นมาอย่างมั่นใจ หรืออ้างถึง “งานที่คล้ายกัน” ซึ่งจริง ๆ แล้วคล้ายกันเพียงผิวเผิน หรือสรุปผิดเกี่ยวกับสถานะ เขตเวลา การตั้งค่าภาษาสำรอง (fallback) หรือข้อจำกัดทางสถาปัตยกรรม ปัญหาไม่ใช่ว่าข้อผิดพลาดเช่นนี้หยาบเสมอไป ตรงกันข้าม ข้อผิดพลาดที่อันตรายที่สุดกลับดูน่าเชื่อถือ

ประการที่สี่ — ความแม่นยำเทียม หาก AI ให้การประเมินที่ดูดี ช่วงที่เรียบร้อย หรือลำดับขั้นตอนที่มั่นใจ ทีมอาจรู้สึกถึงความแม่นยำ แต่ความแม่นยำของการวางแผนไม่ได้เกิดจากตารางที่ดี งานวิจัยเกี่ยวกับการประเมินความพยายามแบบ Agile แสดงให้เห็นว่าคุณภาพของการประเมินขึ้นอยู่กับหลายปัจจัย: ประสบการณ์ของทีม ประสบการณ์ที่ผ่านมา ขนาดของงาน คุณภาพของข้อมูล แนวปฏิบัติในการประเมิน การจัดการโครงการ และอิทธิพลทางธุรกิจ ดังนั้นจึงเป็นเรื่องอันตรายที่จะเขียนหรือคิดว่า AI "ปรับปรุงการประเมิน" ด้วยตัวมันเอง การกล่าวที่ซื่อสัตย์กว่าคือ: AI สามารถช่วยระบุข้อมูลที่ขาดหาย กรณีที่คล้ายกัน และสมมติฐานที่ไม่มั่นคง แต่ทีมยังคงต้องตรวจสอบการประเมิน

ดังนั้นการใช้ AI อย่างมีวุฒิภาวะใน Sprint Planning จึงเริ่มต้นไม่ใช่จากคำถามว่า "AI ประกอบแผนอะไรให้เรา?" แต่จากคำถามว่า "อะไรในแผนนี้อาจไม่จริง ไม่สมบูรณ์ หรือเรียบเกินไป?" ทีมที่ดีไม่เพียงปรับปรุงร่างของ AI แต่พยายามหักล้างมันโดยเฉพาะ: ตรวจสอบแหล่งที่มา สมมติฐาน การพึ่งพา ความจุของทีมที่มีอยู่ Definition of Done และจุดที่โมเดลอาจสรุปอย่างมั่นใจเกินกว่าข้อเท็จจริงจะอนุญาต

อะไรเปลี่ยนไปตามบทบาท

เจ้าของผลิตภัณฑ์

เจ้าของผลิตภัณฑ์ได้รับตัวเลือก Sprint Goal และขอบเขตงานเร็วขึ้นด้วย AI เขาสามารถขอให้โมเดลแสดงหลายสถานการณ์: ขั้นต่ำ ปลอดภัย ทะเยอทะยาน และ stretch เขาสามารถเห็นได้เร็วขึ้นว่าองค์ประกอบใดของ backlog สนับสนุนเป้าหมายจริง ๆ และองค์ประกอบใดเป็นเพียง "มีประโยชน์เช่นกัน"

แต่ความรับผิดชอบของเจ้าของผลิตภัณฑ์ไม่หายไป ตรงกันข้ามกลับชัดเจนขึ้น หาก AI เสนอให้ดึงทุกอย่างที่ดูเกี่ยวข้องเข้าสปรินต์ เจ้าของผลิตภัณฑ์ต้องยึดคำถามเรื่องคุณค่า: ผลลัพธ์ขั้นต่ำอะไรที่ผู้ใช้หรือผู้มีส่วนได้ส่วนเสียต้องการจริง ๆ? อะไรที่ยังไม่ต้องทำตอนนี้? อะไรจะทำลาย Sprint Goal และอะไรเป็นเพียงสิ่งที่ดีถ้ามี?

นักวิเคราะห์ธุรกิจ

สำหรับนักวิเคราะห์ AI มีประโยชน์เป็นเครื่องมือตรวจสอบความเชื่อมโยง ช่วยค้นหาช่องว่างในเกณฑ์การยอมรับ ความขัดแย้งระหว่างองค์ประกอบของ backlog สมมติฐานที่แฝงอยู่ และคำถามที่ควรยกขึ้นมาใน planning ได้อย่างรวดเร็ว

แต่นักวิเคราะห์ยังคงเป็นคนที่แยกแยะระหว่างข้อกำหนดที่ดูดีในเชิงรูปแบบกับข้อกำหนดที่ตรวจสอบได้จริง ในกรณี LMS นักวิเคราะห์ต้องสังเกตว่า "หลักสูตรที่ยังไม่เสร็จ" ไม่ใช่คำศัพท์ที่ชัดเจน มันคือสถานะเฉพาะ ข้อยกเว้น กำหนดเวลา กฎของลูกค้า และข้อมูลในระบบ

นักพัฒนาส่วนหลัง

ส่วนหลังได้รับการตรวจสอบความเสี่ยงทางเทคนิคครั้งแรกอย่างรวดเร็วจาก AI: งานของตัวจัดตาราง ความสามารถในการทำซ้ำได้ คีย์การขจัดข้อมูลซ้ำ บันทึกการตรวจสอบ ตรรกะการลองใหม่ การเชื่อมต่อกับบริการแจ้งเตือน สิ่งนี้เร่งการเตรียมการ

แต่ AI ไม่รู้สถาปัตยกรรมจริงทั้งหมดเหมือนที่ทีมรู้ มันอาจเสนอโครงร่างที่สมเหตุสมผลซึ่งไม่คำนึงถึงข้อจำกัดของ legacy คิวที่ไม่เสถียร ลักษณะเฉพาะของข้อมูล หรือข้อตกลงระหว่างบริการ ดังนั้นส่วนหลังไม่ควร "ยอมรับ" การแบ่งส่วนทางเทคนิคของ AI แต่ควรวิจารณ์มัน

นักพัฒนาส่วนหน้า

ส่วนหน้าสามารถตรวจสอบได้เร็วขึ้นว่า UI จำเป็นในขอบเขตงานแรกหรือไม่ สถานะใดต้องแสดง ผู้ใช้จะเห็นประวัติการส่งอย่างไร จำเป็นต้องมีการจัดการการตั้งค่าหรือเพียงการมองเห็นแบบอ่านอย่างเดียวก็เพียงพอ

แต่ planning ต้องตอบอย่างซื่อสัตย์: UI จำเป็นสำหรับ Sprint Goal จริงหรือนี่คือการขยายขอบเขตแล้ว? หากเป้าหมายคือการส่งการแจ้งเตือนอย่างถูกต้องและเก็บประวัติที่ตรวจสอบได้ อาจไม่จำเป็นต้องมีอินเทอร์เฟซลูกค้าที่สมบูรณ์ในสปรินต์แรก AI สามารถช่วยกำหนดตัวเลือก แต่ทีมต้องยอมรับการประนีประนอม

วิศวกรคุณภาพ / วิศวกร QA

QA อาจได้ประโยชน์จาก AI มากกว่าที่คิด โมเดลสร้างสถานการณ์เชิงลบ สถานการณ์ขอบ สถานการณ์ที่ผูกกับเวลา การตรวจสอบเขตเวลา การ fallback ทางภาษา ผู้ใช้ที่ถูกเก็บถาวรและปิดใช้งาน การรันงานของตัวจัดตารางซ้ำ และการขจัดข้อมูลซ้ำได้อย่างรวดเร็ว

แต่ QA ต้องปกป้องทีมจากความครอบคลุมเทียม รายการไอเดียการทดสอบที่ยาวไม่ได้หมายความว่าแผนทดสอบได้ แผนทดสอบได้ก็ต่อเมื่อเกณฑ์การยอมรับชัดเจน ข้อมูลเข้าถึงได้ การสังเกตเข้าใจได้ และทีมเข้าใจวิธีพิสูจน์การบรรลุ Definition of Done

นักออกแบบ UX/UI

นักออกแบบรวบรวมตัวเลือกแนวทาง UI ได้เร็วขึ้นด้วย AI: การตั้งค่าการแจ้งเตือน ประวัติการส่ง สถานะข้อผิดพลาด คำแนะนำสำหรับทีมสนับสนุนลูกค้า แต่ใน planning หน้าที่ของเขาไม่ใช่การขยายขอบเขตด้วยความสามารถด้านอินเทอร์เฟซที่สวยงาม แต่คือการช่วยแยกสิ่งที่จำเป็นออกจากสิ่งที่พึงปรารถนา

ในกรณีของเรา dashboard ที่สมบูรณ์อาจมีประโยชน์แต่ไม่จำเป็นสำหรับ Sprint Goal แรก หากนักออกแบบช่วยจำกัดเส้นทางผู้ใช้ให้แคบลงโดยไม่สูญเสียคุณค่า เขาจะเพิ่มความเป็นจริงของแผน

Scrum Master

Scrum Master ในการวางแผนที่ช่วยด้วย AI ไม่ได้กลายเป็น "ผู้จัดประชุม" แต่เป็นผู้ปกป้องคุณภาพของพันธสัญญาของทีม หน้าที่ของเขาคือดูแลไม่ให้ร่างของ AI กลายเป็นผู้มีอำนาจในตัวเอง

คำถามที่ดีของ Scrum Master ในที่นี้คือ:

• เราเข้าใจจริง ๆ ไหมว่าทำไมสปรินต์นี้มีคุณค่า?
• นักพัฒนาถือว่า Sprint Backlog นี้เป็นแผนของพวกเขาหรือไม่?
• อะไรในร่างของ AI ที่เราตรวจสอบด้วยข้อเท็จจริงแล้ว?
• แผนดูเรียบเกินไปตรงไหน?
• ถ้ามีข้อมูลใหม่ เราจะเอาอะไรออกก่อน?
• Sprint Goal กลายเป็นรายการงานไปหรือยัง?

เปรียบเทียบ: Sprint Planning แบบไม่มี AI และแบบมี AI

พื้นที่การวางแผน	ไม่มี AI	อะไรเปลี่ยนไปเมื่อมี AI
Sprint Goal	กำหนดขึ้นจากการหารือสด บางครั้งหลังเลือกงานแล้ว	AI เสนอทางเลือกเป้าหมายได้หลายแบบอย่างรวดเร็ว
การเลือกขอบเขตงาน	ทีมพูดคุยรายการใน backlog ตามลำดับและมักถกเถียงเรื่องขอบเขต	AI รวบรวมรายการสั้น ๆ ทางเลือกขอบเขตงาน และข้อเสนอที่อยู่นอกขอบเขตงาน
ความจุของทีมที่มีอยู่	คำนวณด้วยมือจากจำนวนคน วันลา งานซัพพอร์ต และงานที่ค้างจากรอบก่อน	AI สามารถรวบรวมสัญญาณเชิงประวัติและข้อจำกัดจากปฏิทิน
การพึ่งพากัน	ปรากฏผ่านความทรงจำและประสบการณ์ของทีม	AI ดึงการพึ่งพากันเบื้องต้นจากข้อความและประวัติได้เร็วขึ้น
การแบ่งงานย่อย	นักพัฒนาร่วมกันแบ่งงานเอง	AI เสนอการแบ่งงานย่อยได้เร็วและละเอียดกว่า
การทดสอบ	QA ยกสถานการณ์วิกฤตขึ้นมาด้วยมือ	AI สร้างทางเลือกเบื้องต้นของสถานการณ์เชิงลบและกรณีขอบ
การบริหารความเสี่ยง	ความเสี่ยงมักถูกพูดถึงเป็นส่วน ๆ	AI สร้างรายการความเสี่ยงและทะเบียนสมมติฐานได้อย่างรวดเร็ว
พันธะสัญญาของทีม	เกิดจากความเห็นพ้องของทีมหลังการหารือ	AI สร้างแผนที่ขัดเกลามาแล้วซึ่งรับได้ง่ายกว่า
เอกสาร	มักเขียนเพิ่มด้วยมือหลังการประชุม	AI บันทึกการตัดสินใจ สมมติฐาน และการดำเนินการต่อไปได้อย่างรวดเร็ว

ความเสี่ยงใหม่และสิ่งที่ต้องตรวจสอบด้วยมือ

พื้นที่การวางแผน	ความเสี่ยงใหม่	สิ่งที่ต้องตรวจสอบด้วยมือ
Sprint Goal	Sprint Goal กลายเป็นบทสรุปขอบเขตงานที่สวยงาม	เป้าหมายมีคำว่า “ทำไปเพื่ออะไร” ไม่ใช่แค่ “ทำอะไร” หรือไม่
การเลือกขอบเขตงาน	ความสมบูรณ์ลวงตาและการอัดขอบเขตงานแน่นเกินไป	ทุกองค์ประกอบจำเป็นต่อ Sprint Goal จริงหรือไม่? อะไรเอาออกได้ก่อน?
ความจุของทีมที่มีอยู่	มองข้ามสิ่งรบกวนจริง บั๊ก งานซัพพอร์ต และการประชุม	ได้คำนึงถึงวันลา ภาระงานซัพพอร์ต งานค้าง การประชุมที่จำเป็น และการรอการพึ่งพาภายนอกหรือไม่
การพึ่งพากัน	โมเดลอาจสร้างการพึ่งพาที่ไม่มีอยู่จริงหรือมองข้ามการพึ่งพาเชิงองค์กร	การพึ่งพาภายนอกทั้งหมดได้รับการยืนยันจากคนและมีผู้รับผิดชอบ
การแบ่งงานย่อย	ทีมรับตรรกะการแบ่งงานของผู้อื่นอย่างเฉื่อยชา	การแบ่งงานสะท้อนสถาปัตยกรรม ความเสี่ยง และ Definition of Done ของทีม
การทดสอบ	ความครอบคลุมเทียม: เทสต์เยอะแต่ไม่ครอบโหมดความล้มเหลว	มีเกณฑ์การยอมรับที่ตรวจสอบได้ การสังเกตการณ์ และข้อมูลสำหรับการทดสอบหรือไม่
การบริหารความเสี่ยง	รายการดูสมบูรณ์และปิดประเด็น	ความเสี่ยงใดยังไม่ได้รับการยืนยันด้วยข้อเท็จจริง? ความเสี่ยงใดลดได้แล้วตอนนี้?
พันธะสัญญาของทีม	ความเป็นเจ้าของ/ความรับผิดชอบเจือจาง: “แผนถูกประกอบเสร็จแล้ว”	นักพัฒนาได้ยืนยันอย่างชัดเจนว่า Sprint Backlog เป็นแผนของตน
เอกสาร	บันทึกการประชุมมีถ้อยคำที่โน้มน้าวของโมเดล ไม่ใช่ข้อตกลง	การตัดสินใจหลัก ข้อเท็จจริง และคำถามเปิดทั้งหมดได้รับการยืนยันจากผู้เข้าร่วม

สาระสำคัญในตารางนี้ไม่ใช่ว่า AI “ทำ planning ได้ดีกว่า” ความคิดที่แม่นยำกว่าคือ AI เร่งการประกอบร่างฉบับร่าง รายการ ทางเลือก และบันทึกการประชุมได้แทบทุกจุด แต่แทบไม่เคยทดแทนรอบการตรวจสอบสุดท้ายของมนุษย์ในเรื่องความเป็นจริง ความสมจริง และความเป็นเจ้าของ/ความรับผิดชอบ

การกำกับดูแลและสุขอนามัยของข้อมูล: สิ่งที่ไม่ควรให้โมเดลแบบไม่คิด

ในการ planning มักมีสิ่งล่อใจให้ป้อนทุกอย่างลงใน AI: งานใน Jira เธรดสนทนาใน Slack คำร้องของลูกค้า บันทึกงานซัพพอร์ต ชิ้นส่วนเอกสาร ปฏิทินของทีม ประวัติเหตุการณ์ และการติดต่อกับผู้มีส่วนได้ส่วนเสีย ในแง่คุณภาพของ planning ก็เข้าใจได้ ยิ่งมีบริบทมาก ฉบับร่างก็ยิ่งดี

แต่ในแง่ governance นั่นอันตราย

หากทีมใช้ AI เตรียม Sprint Planning ทีมต้องตกลงล่วงหน้าว่าข้อมูลใดส่งให้โมเดลได้และข้อมูลใดไม่ได้ ใครตรวจสอบผลลัพธ์ และจะบันทึกจุดที่เป็นข้อถกเถียงอย่างไร แนวทาง governance ง่าย ๆ ที่ได้ผลคือ กำหนดผู้รับผิดชอบการตรวจสอบอย่างชัดเจน แยกข้อเท็จจริงออกจากสมมติฐาน บันทึกสิ่งที่ไม่รู้จัก เก็บการกำหนดทับด้วยมือที่สำคัญของทีมไว้เหนือคำแนะนำของ AI และตรวจสอบแหล่งที่มาของข้อกล่าวอ้างสำคัญ ไม่ควรใส่สิ่งต่อไปนี้ลงในพรอมป์ต์ / คำขอถึงโมเดลแบบไม่คิด:

• ชื่อลูกค้าจริง;
• ที่อยู่อีเมลของผู้ใช้และพนักงาน;
• ข้อมูล在生产;
• รายละเอียดเหตุการณ์ด้านความปลอดภัย;
• ข้อมูลรับรอง โทเคน คีย์ API;
• บันทึกการตรวจสอบฉบับเต็ม;
• เอกสารทางกฎหมายและเงื่อนไขสัญญา;
• ข้อมูล HR;
• รายละเอียดที่อ่อนไหวเชิงพาณิชย์ซึ่งไม่จำเป็นต่อ planning

ปลอดภัยกว่าที่จะทำงานกับบริบทที่ลดทอนและไม่ระบุตัวตน: แทนที่ตัวระบุจริงด้วยตัวแทนที่ไม่ระบุตัวตน ใช้การแก้ไขโดยลบข้อมูลที่อ่อนไหว / การทำให้ไม่ระบุตัวตน ส่งรูปแบบเชิงประวัติแบบรวมแทนการส่งออกดิบ แยกข้อเท็จจริงออกจากข้อสันนิษฐาน และบันทึกว่าพรอมป์ต์ / คำขอถึงโมเดลและคำตอบของโมเดลใดถูกใช้จริงในการเตรียม planning

นี่ไม่ใช่ระบบราชการ แต่เป็นวิธีไม่ให้ AI-assisted planning กลายเป็นช่องทางรั่วไหลของข้อมูล และไม่ให้โมเดลได้บริบทมากเกินกว่าที่จำเป็นสำหรับการตัดสินใจเฉพาะเรื่อง

เช็กลิสต์: Sprint Plan ที่ AI ประกอบขึ้นสามารถนำมาหารือได้หาก…

รายการตรวจสอบนี้ไม่ใช่สิ่งประดิษฐ์ Scrum อย่างเป็นทางการ แต่เป็นตัวกรองเชิงปฏิบัติที่ช่วยให้ทีมไม่สับสนระหว่างร่างที่สร้างโดย AI กับแผนจริง

Sprint Plan ที่ AI รวบรวมสามารถนำมาหารือได้ หาก:

• Sprint Goal ถูกกำหนดเป็นคุณค่าหรือสภาวะที่เปลี่ยนแปลงสำหรับผู้ใช้/ผู้มีส่วนได้ส่วนเสีย ไม่ใช่เป็นรายการงาน
• สำหรับแต่ละรายการ backlog ที่เลือก ทีมสามารถอธิบายได้ว่ารายการนั้นสนับสนุน Sprint Goal อย่างไร
• ความจุที่มีอยู่ของทีมถูกนำมาพิจารณาอย่างเป็นรูปธรรม โดยคำนึงถึงวันลา การสนับสนุน การแก้บั๊ก งานที่ค้างจากรอบก่อน การ onboard และการประชุมที่จำเป็น
• งานที่ยังไม่เสร็จจากสปรินต์ก่อนหน้าถูกวิเคราะห์อย่างชัดเจน: อะไรที่ยกไป อะไรที่ยกเลิก อะไรที่ต้องประเมินใหม่
• การพึ่งพาภายนอกถูกระบุอย่างชัดเจน แต่ละรายการมีผู้รับผิดชอบและสถานะที่เข้าใจได้
• สำหรับขอบเขตงานที่เลือก ทีมมองเห็นเส้นทางสู่ Definition of Done ไม่ใช่แค่สถานะ "โค้ดเกือบเสร็จ"
• แผนสามารถทดสอบได้: มีเกณฑ์การยอมรับ สถานการณ์เชิงลบ สถานการณ์ขอบเขต การสังเกตได้ และข้อมูลที่ชัดเจนสำหรับการตรวจสอบ
• ทีมสามารถระบุขอบเขตงานที่มีคุณค่าขั้นต่ำของสปรินต์ได้ในประโยคเดียว
• ทีมเข้าใจล่วงหน้าว่าอะไรจะถูกตัดออกจากขอบเขตงานก่อน หากมีข้อมูลใหม่เกิดขึ้น
• ข้อเท็จจริงที่มีนัยสำคัญจากร่างของ AI ถูกตรวจสอบด้วยมือ: สถานะ การพึ่งพา ข้อมูลเชิงประวัติ ข้อจำกัดทางสถาปัตยกรรม กฎเกี่ยวกับกำหนดส่ง การแปลภาษา การขจัดข้อมูลซ้ำ
• มีสมาชิกคนหนึ่งในทีมพยายามหักล้างร่างของ AI โดยเฉพาะ ไม่ใช่เพียงแค่ปรับปรุงให้ดีขึ้น
• ทีมได้ตรวจสอบแยกต่างหากว่าส่วนใดของแผนที่ดูราบรื่นเกินไป แม่นยำเกินไป หรือดูเหมือน "เข้าใจได้เอง" อย่างน่าสงสัย
• นักพัฒนาได้ยืนยันอย่างชัดเจนว่า Sprint Backlog คือแผนของพวกเขา และ Sprint Goal คือพันธสัญญาของทีมสำหรับสปรินต์
• ผลลัพธ์ของการวางแผนถูกบันทึกไว้อย่างชัดเจน: อะไรที่ตัดสินใจแล้ว อะไรที่เป็นสมมติฐาน อะไรที่ยังไม่ทราบ และอะไรที่ถูกนำออกนอกขอบเขตงาน

ในทางปฏิบัติ รายการตรวจสอบนี้สามารถใช้เป็นวินัยการคิดสั้นๆ ในตอนท้ายของการวางแผน ไม่ใช่เป็นด่านควบคุมอย่างเป็นทางการ คำถามสองข้อที่มีประโยชน์เป็นพิเศษคือ: "อะไรในร่างของ AI นี้อาจไม่เป็นความจริง?" และ "อะไรที่เราจะตัดออกก่อนหากความเป็นจริงซับซ้อนกว่าที่คิด?"

สิ่งที่ฉันจะแนะนำทีม

ประการแรก ใช้ AI ก่อน Sprint Planning ไม่ใช่เพื่อให้ "มันวางแผนสปรินต์" แต่เพื่อให้มันเตรียมวัสดุสำหรับการหารือของมนุษย์ที่ดี ปล่อยให้มันรวบรวมทางเลือก การพึ่งพา สมมติฐาน ความเสี่ยง กรณีขอบเขต ทางเลือกของขอบเขตงาน และคำถาม แต่การตัดสินใจต้องยังคงอยู่กับทีม

ประการที่สอง แยกฉบับร่างของแผนออกจากพันธสัญญาของทีมเสมอ ร่างของ AI อาจเป็นวัตถุดิบที่ดีเยี่ยม แต่ Sprint Backlog จะกลายเป็นของจริงก็ต่อเมื่อนักพัฒนาเข้าใจว่ามันเป็นแผนของพวกเขา

ประการที่สาม อย่ายอมรับการประเมินที่สร้างโดย AI ว่าเป็นกลางกว่าเพียงเพราะมันดูมีโครงสร้าง การจำลองและการทบทวนเกี่ยวกับการประเมินอัตโนมัติ/การประเมินภาระงานที่ AI ช่วยเหลือให้เหตุผลเพียงพอที่จะระมัดระวัง: แบบจำลองที่ซับซ้อนไม่ได้ดีกว่าแบบจำลองพื้นฐานง่ายๆ เพียงเพราะความซับซ้อนของมัน ในการประเมิน สิ่งที่อันตรายไม่ใช่แค่ข้อผิดพลาด แต่ยังรวมถึงความมั่นใจที่เกินควร ควรใช้ AI เพื่อระบุความไม่แน่นอนมากกว่าสร้างภาพลวงของความแม่นยำ

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

ประการที่ห้า กำหนดผู้รับผิดชอบการตรวจสอบ เจ้าของผลิตภัณฑ์ตรวจสอบความหมายทางธุรกิจ นักวิเคราะห์ตรวจสอบความสอดคล้องของข้อกำหนด นักพัฒนาตรวจสอบความเป็นไปได้ทางสถาปัตยกรรม QA ตรวจสอบความสามารถในการทดสอบ นักออกแบบตรวจสอบขอบเขตประสบการณ์ผู้ใช้ Scrum Master ตรวจสอบคุณภาพของข้อตกลงของทีม AI สามารถเตรียมร่างทั่วไปได้ แต่ไม่สามารถเป็นเจ้าของการตรวจสอบได้

บทสรุป

หากใน Backlog Refinement AI ช่วยรวบรวมและจัดเตรียมวัสดุสำหรับการหารือได้เร็วขึ้น ใน Sprint Planning มันก็ช่วยรวบรวมทางเลือกของแผนได้เร็วขึ้น มันสามารถเสนอ Sprint Goal จัดกลุ่มรายการ backlog เน้นการพึ่งพา ร่างการแบ่งย่อย เตรียมสถานการณ์ทดสอบ เขียนสมมติฐาน และแม้แต่บันทึกผลลัพธ์การประชุมได้อย่างสวยงาม

แต่สิ่งนี้ไม่ได้ทำให้แผนเป็นจริง

Sprint Plan ที่เป็นจริงจะเกิดขึ้นก็ต่อเมื่อทีมตรวจสอบอย่างซื่อสัตย์ถึงคุณค่า ขอบเขตงาน ความจุที่มีอยู่ของทีม การพึ่งพา Definition of Done ความสามารถในการทดสอบ และความพร้อมของตนเองที่จะรับงานนี้ไปทำ AI สามารถเร่งการตรวจสอบนี้ได้ แต่ไม่สามารถแทนที่ได้ มันสามารถช่วยให้เห็นทางเลือกมากขึ้น แต่ไม่สามารถเลือกพันธสัญญาของทีมแทนคนได้

ดังนั้นผลกระทบหลักของ AI ใน Sprint Planning ที่ฉันจะสรุปคือ: มันลดต้นทุนในการเตรียมทางเลือกของแผน แต่เพิ่มราคาของการตรวจสอบโดยมนุษย์ ยิ่งการสร้างแผนที่สวยงามกลายเป็นเรื่องง่ายขึ้นเท่าไร การเข้าใจว่าแผนนั้นเป็นแผนที่แท้จริงของทีมหรือไม่ก็ยิ่งสำคัญขึ้นเท่านั้น

ในทีมที่เติบโตเต็มที่ AI ไม่ได้เปลี่ยน Sprint Planning ให้กลายเป็นการสร้าง Sprint Backlog โดยอัตโนมัติ แต่เปลี่ยนให้เป็นการสนทนาที่เจาะจงมากขึ้นเกี่ยวกับเป้าหมาย ข้อจำกัด และการประนีประนอม และนี่อาจเป็นรูปแบบการทำงานอัตโนมัติที่มีประโยชน์ที่สุด: ไม่ใช่การนำคนออกจาก planning แต่เป็นการปลดปล่อยความสนใจของพวกเขาให้กับ decisions ที่เครื่องมือไม่สามารถตัดสินใจแทนได้

แหล่งที่มาและแนวทางอ้างอิง

• Scrum Guide 2020 — Sprint Planning, Sprint Goal, Sprint Backlog, ขอบเขตความรับผิดชอบ
• กรอบการบริหารความเสี่ยง AI ของ NIST 1.0 — การกำกับดูแล/การกำหนดกฎเกณฑ์, ความรับผิดชอบ/ความรับผิด, การกำหนดค่าปฏิสัมพันธ์ระหว่างมนุษย์และ AI
• โปรไฟล์ NIST สำหรับ Generative AI — การสร้างข้อมูลเท็จอย่างมั่นใจ (confabulation), การพึ่งพามากเกินไป, ความเป็นส่วนตัว และการบริหารความเสี่ยง
• ChatGPT as a tool for User Story Quality Evaluation — ตัวอย่างฐานหลักฐานระดับปานกลางสำหรับงานด้านคุณภาพของ user story
• Large Language Models for Software Engineering: Survey and Open Problems — ภาพรวมของ LLM ในการพัฒนาซอฟต์แวร์/วิศวกรรมซอฟต์แวร์
• การประเมินความพยายามใน Agile Software Development: การทบทวนวรรณกรรมอย่างเป็นระบบ — ปัจจัยด้านคุณภาพของการประเมินแบบ Agile
• Reasons and Approaches for Accurate Effort Estimations in Agile Iterative Development — คุณภาพของข้อมูล, ทีม, แนวปฏิบัติในการประเมิน, การบริหารโครงการ, ผลกระทบทางธุรกิจ
• GPT2SP replication report — ข้อจำกัดของการประเมินด้วย AI ใน story points และการเปรียบเทียบกับโมเดลพื้นฐาน/แนวทางอ้างอิงอย่างง่าย
• สู่การวางแผน Agile แบบวนซ้ำที่เชื่อถือได้ผ่านการพยากรณ์การเปลี่ยนแปลงเอกสารของ work item — ความเชื่อมโยงระหว่างการเปลี่ยนแปลงเอกสารและความเปราะบางของ planning
• The Planning Fallacy — งานคลาสสิกเกี่ยวกับการประเมินเวลาต่ำเกินจริง
• Automation Bias in Intelligent Time Critical Decision Support Systems — อคติจากระบบอัตโนมัติ, ข้อผิดพลาดจากการละเลย และข้อผิดพลาดจากการกระทำ
• Generalization bias in large language model summarization — ความเสี่ยงของการสรุปเกินจริงในบทสรุปที่สร้างโดยโมเดลภาษาขนาดใหญ่
• OWASP Top 10 สำหรับแอปพลิเคชัน LLM — ข้อมูลที่ละเอียดอ่อน, การพึ่งพามากเกินไป, ความเสี่ยงจาก prompt และความปลอดภัย