- แม้ ความเร็วในการพัฒนา จะเพิ่มขึ้นอย่างก้าวกระโดดจากการสร้างโค้ดด้วย AI และนวัตกรรมด้านแพลตฟอร์ม แต่ผลลัพธ์ของโปรเจ็กต์ยังคงย่ำแย่และมีอัตราความล้มเหลวสูง
- ปัญหาไม่ใช่เรื่องความเร็ว แต่คือ การขาดการตรวจสอบและการจัดแนวร่วมกัน และ XP ใช้ ข้อจำกัดที่ตั้งใจออกแบบไว้ เพื่อผลักดัน การเรียนรู้ การจัดแนว และการยกระดับคุณภาพ
- โดยเฉพาะเมื่อ AI agent เร่งการสร้าง แก้ไข และดีพลอยโค้ด มากขึ้นเท่าไร ความซับซ้อนและช่องโหว่ที่เพิ่มขึ้นโดยไม่มีการตรวจสอบก็ยิ่งรุนแรงขึ้นเท่านั้น
- XP เน้นคุณค่าที่มีมนุษย์เป็นศูนย์กลาง เช่น ความเรียบง่าย การสื่อสาร ฟีดแบ็ก ความเคารพ และความกล้าหาญ รวมถึงการส่งมอบทีละน้อย การทำ CI อย่างต่อเนื่อง และการทดสอบอัตโนมัติ
- ในยุคที่ผลลัพธ์รวดเร็วกลายเป็นเรื่องปกติ XP คือแนวทางที่ช่วยย้ำเตือนอีกครั้งว่า ซอฟต์แวร์นั้นท้ายที่สุดแล้วสร้างขึ้นเพื่อมนุษย์
การเร่งความเร็วของการผลิตซอฟต์แวร์และข้อจำกัด
- ช่วงหลังมานี้ เครื่องมือ AI และนวัตกรรมจากแพลตฟอร์มพัฒนาหลากหลายแบบทำให้ อุปสรรคในการสร้างโค้ดต่ำลงมาก และความเร็วดีขึ้นอย่างชัดเจน
- เพียงไม่กี่พรอมป์ต์หรือการเรียก API ก็สามารถ สร้างทั้งผลิตภัณฑ์ ฟีเจอร์ และโครงสร้างพื้นฐานได้อย่างรวดเร็ว
- แต่ถึงแม้ ผลิตภาพจะสูงขึ้น ก็ยังมีปัญหาที่อัตราความสำเร็จของทั้งโปรเจ็กต์ไม่ได้ดีขึ้นอย่างมีนัยสำคัญ
- รายงาน Standish Chaos และรายงานของ McKinsey ชี้ว่า กรณีที่โปรเจ็กต์ IT ส่วนใหญ่ล้มเหลวหรือใช้งบเกิน ยังคงเกิดขึ้นบ่อยครั้ง
- จึงเห็นได้ชัดว่า แม้ความเร็วในการสร้างโค้ดจะดีขึ้น ก็ไม่ได้หมายความว่า ผลลัพธ์ในการส่งมอบซอฟต์แวร์จะดีขึ้นโดยอัตโนมัติ
เหตุใด output จึงไม่ใช่ปัญหาที่แท้จริง
- มีการพิสูจน์ซ้ำแล้วซ้ำเล่าว่า คอขวดของการพัฒนาซอฟต์แวร์ไม่ใช่ ความเร็วในการป้อนหรือสร้างโค้ด
- มีคลื่นแห่งการเร่งความเร็วตามมาอย่างต่อเนื่อง ไม่ว่าจะเป็น การมาของภาษาเขียนโปรแกรมระดับสูง การแพร่หลายของเฟรมเวิร์กและ package manager การขยายตัวของ DevOps และ serverless การพัฒนาของแพลตฟอร์มพัฒนา และการสร้างโค้ดด้วย AI
- ตามรายงาน Chaos แม้ output จะเร็วขึ้น แต่ปัญหาที่ผลลัพธ์สุดท้ายยังไม่สม่ำเสมอและต่ำกว่าความคาดหวังก็ยังคงอยู่
- สิ่งสำคัญจึงไม่ใช่การเร่งความเร็วอย่างเดียว แต่เป็น ‘ข้อจำกัด’ ที่ชาญฉลาดกว่า
- XP คือแนวปฏิบัติที่ช่วยพาไปในทิศทางที่ถูกต้องผ่าน การเรียนรู้ การจัดแนว และการพัฒนาที่มีเจตนา โดยไม่เร่งรีบเกินไป
บทบาทของ XP: ตัวถ่วงสมดุลต่อความเร็ว
- การเร่งความเร็วแบบไร้ขีดจำกัดก่อให้เกิดปัญหา เพราะมัน พรากโอกาสในการเรียนรู้ การค้นพบข้อผิดพลาด และการปรับทิศทาง
- Extreme Programming (XP) ถูกออกแบบมาเพื่อให้ทีมเคลื่อนไปในทิศทางที่ถูกต้อง ด้วยการใส่ แรงเสียดทานและข้อจำกัดโดยตั้งใจ
- แนวปฏิบัติที่เป็นตัวอย่างชัดเจน: pair programming จงใจลดปริมาณผลผลิตลงครึ่งหนึ่ง
- แม้ pair programming อาจทำให้ผลผลิตลดลงครึ่งหนึ่ง แต่กลับให้ผลเชิงบวกเป็นสองเท่าในด้าน ความเข้าใจร่วมกัน ความไว้วางใจ คุณภาพ และการยกระดับความสามารถของทีม
- XP เปลี่ยนวิธีการทำงานร่วมกันโดยตรง และลงทุนกับ การเสริมพลังให้ทีมและการมอบทิศทาง
การมองปัญหาของ XP ที่ยิ่งทวีความสำคัญเมื่อมี AI
- เมื่อ AI ทำให้ การสร้างโค้ดแทบไม่ต้องออกแรง ความเสี่ยงของการผลิตซอฟต์แวร์จำนวนมากที่ยังไม่ได้รับการตรวจสอบอย่างเหมาะสมก็เพิ่มสูงขึ้น
- โดยเฉพาะในระบบ agentic AI ที่มีเอเจนต์หลายตัวสร้าง ปรับปรุง และดีพลอยโค้ดโดยอัตโนมัติ ความเสี่ยงจะยิ่งเพิ่มขึ้นอย่างรวดเร็ว
- ระบบอัตโนมัติที่ไร้ข้อจำกัดจะพอกตรรกะที่ไม่ผ่านการตรวจสอบไว้เป็นชั้น ๆ ทำให้ความซับซ้อนและช่องโหว่แย่ลง
- งานวิจัยล่าสุดพิสูจน์ว่า ยิ่ง context window ของ LLM ยาวขึ้น ความแม่นยำกลับยิ่งแย่ลง
- มันจัดการช่วงต้นและช่วงท้ายได้ดี แต่ตรงกลางกลับเปราะบางต่อการเหมารวมและข้อผิดพลาดมากกว่า
- ผลลัพธ์คือ โค้ดที่ดูแลรักษาแพงและพังได้ง่าย และ XP ก็ถือกำเนิดขึ้นมาเพื่อป้องกัน entropy ที่ไร้ระเบียบ แบบนี้
ซอฟต์แวร์ยังคงเป็นพื้นที่ของมนุษย์
- ต่อให้ AI พัฒนาไปไกลเพียงใด ธรรมชาติของซอฟต์แวร์ในฐานะ สิ่งที่มนุษย์สร้างขึ้นเพื่อมนุษย์ ภายใต้การสื่อสารและวัฒนธรรมขององค์กร ก็ไม่เปลี่ยนแปลง
- อุปสรรคสำคัญต่อการส่งมอบไม่ใช่ระดับของระบบอัตโนมัติ แต่คือ การจัดแนวร่วมกัน บริบทร่วม ความชัดเจนของผลลัพธ์ และการตรวจสอบกับผู้ใช้ ซึ่งล้วนเป็นองค์ประกอบที่มีมนุษย์เป็นฐาน
- คุณค่าหลักของ XP:
- Simplicity: ลดความซับซ้อน
- Communication: รักษาความเหนียวแน่นของทีม
- Feedback: ขับเคลื่อนการเรียนรู้และการปรับตัว
- Respect: สร้างความไว้วางใจและความปลอดภัย
- Courage: สนับสนุนความโปร่งใสและความสามารถในการเปลี่ยนแปลง
จาก feature factory สู่การส่งมอบคุณค่าที่แท้จริง
- ทีมที่ประสบความสำเร็จให้ความสำคัญกับ flow และฟีดแบ็ก มากกว่าความเร็วเพียงอย่างเดียว
- แนวปฏิบัติของ XP เช่น การส่งมอบเป็นชุดเล็ก ๆ การทำ CI อย่างต่อเนื่อง การทดสอบอัตโนมัติ และ การเป็นเจ้าของร่วมกัน ช่วยเสริม ความสามารถในการปรับตัวและความเป็นศูนย์กลางของผู้ใช้
- ยิ่งในอนาคตที่การผลิตโค้ดเร็วขึ้น วิธีการเหล่านี้ยิ่งจะ จำเป็นต่อการควบคุมคุณภาพ ความเสี่ยง และเจตนาของงาน
บทเรียนจากอดีต
- สถิติจากรายงาน CHAOS:
- ปี 1994: โปรเจ็กต์ที่สำเร็จตรงเวลาและไม่เกินงบ 16%
- ปี 2012: ดีขึ้นเป็น 37%
- ปี 2020: ลดลงอีกครั้งเหลือ 31%
- แม้ผ่านนวัตกรรมและการเปลี่ยนแปลงมากกว่า 20 ปี (agile, DevOps, cloud-native, AI ฯลฯ) ความน่าเชื่อถือโดยรวมก็เพิ่มขึ้นเพียง 14 จุดเปอร์เซ็นต์เท่านั้น
- ปัญหาไม่สามารถแก้ได้ด้วย toolchain เพียงอย่างเดียว
- นี่จึงเป็นการยืนยันอีกครั้งถึง ความสำคัญของวิธีวิทยาที่ถูกต้อง
ต่อจากนี้ต้องการอะไร
- 1. output ไม่ใช่ข้อจำกัดอีกต่อไป: ความสามารถในการผลิตโค้ดแซงหน้าความเร็วในการตรวจสอบและการจัดแนวไปแล้ว
- 2. เสริมความสามารถที่มุ่งผลลัพธ์: ฟีดแบ็ก ทิศทางผลิตภัณฑ์ที่ชัดเจน การทำงานร่วมกันที่แข็งแรง และการออกแบบที่ดี เป็นสิ่งจำเป็น
- 3. ต้องมีกระบวนการที่เป็นมนุษย์มากขึ้น: แม้ AI จะก้าวหน้าเพียงใด การส่งมอบอย่างต่อเนื่องก็ยังพึ่งพาการทำงานร่วมกัน
- ย้ำว่า Product Operating Model ที่มีประสิทธิภาพจริงนั้นมาจาก การดำเนินงานที่ยึดมนุษย์เป็นศูนย์กลาง—ความร่วมมือ ความชัดเจน และ flow
- เมื่อสามารถจัดแนว กลยุทธ์ทีม จังหวะการดำเนินงาน และแนวปฏิบัติทางวิศวกรรม ได้อย่างไร้รอยต่อ มากกว่าพึ่งเพียงนวัตกรรมทางเทคนิค (แพลตฟอร์ม) ก็จะสร้างสภาพแวดล้อมการส่งมอบซอฟต์แวร์ที่ยั่งยืนได้ในยุค AI
สรุป: ในยุค AI, XP จำเป็นหรือไม่?
- จำเป็น
- ท่ามกลางเครื่องมือที่ทรงพลังขึ้นเรื่อย ๆ เราจำเป็นต้องมี กรอบการทำงานที่ยึดโยงแนวปฏิบัติแบบมนุษย์เป็นศูนย์กลางไว้ให้มั่นคง
- XP มอบทั้งการทำงานแบบยึดทีมเป็นศูนย์กลาง ความเห็นอกเห็นใจ ความเข้าใจร่วมกัน และการมุ่งสู่เป้าหมายที่ถูกต้อง
- มันไม่ได้โฟกัสที่ความเร็วของ output เพียงอย่างเดียว แต่เน้น ทิศทางที่มีความหมายและการจัดแนวภายในทีม
- ในยุคแห่งการเร่งด้วย AI และการผลิตแบบไร้ข้อจำกัด XP คือ วิธีวิทยาที่หาได้ยาก ซึ่งช่วยเตือนเราว่า ซอฟต์แวร์เป็นงานของมนุษย์
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
Kent Beck (ผู้สร้าง Extreme Programming) กำลังทำการทดลองหลากหลายเกี่ยวกับ AI coding
ในบทความอย่าง Augmented Coding Beyond the Vibes เขากำลังครุ่นคิดว่า AI สามารถถูกนำมาใช้กับการเขียนโปรแกรมได้อย่างไร
จำได้ว่าเมื่อ ChatGPT เริ่มถูกใช้ให้เป็นประโยชน์กับการเขียนโค้ด เขาเคยบอกว่าทักษะ 90% ของตัวเองตอนนี้ไร้ค่าไปแล้ว และอีก 10% ที่เหลือกลับมีคุณค่ามากขึ้นเท่านั้น
90% of my skills are now worth 0
ฉันคิดว่าวิธีพัฒนาแบบ XP ที่ให้ความสำคัญกับการทดสอบก่อนนั้นยิ่งมีคุณค่ามากขึ้นในยุคที่ AI สร้างโค้ดและตรวจสอบมันได้
รู้สึกว่าวิธีนี้ทำให้การสร้างโค้ดด้วยเครื่องมือ AI ง่ายขึ้นมาก โดยเฉพาะอย่างยิ่ง
หนึ่งในจุดที่ทำให้กังวลเกี่ยวกับ AI coding ทุกวันนี้คือ รายงานหรือไกด์เก่า ๆ ยังคงค้างอยู่ใน repository
ตัวอย่างเช่น รายงานนี้ก็เป็นรายงานที่ AI สร้างขึ้นจากโค้ด ณ เวลาที่มันถูกสร้าง
ไม่แน่ใจว่าการทิ้งผลลัพธ์ขั้นกลางแบบนี้ไว้ใน history มีความหมายอะไร
โดยเฉพาะไฟล์ที่เพิ่มพอกพูนขึ้นมาอย่าง _updated_v2_from_2025
ตัวอย่าง1, ตัวอย่าง2
ฉันคิดว่า XP เท่านั้นที่เป็น agile methodology ที่แท้จริง
Agile ถูกบิดความหมายจนแทบไม่เหลือสาระเมื่อเวลาผ่านไป
AI programming ช่วยปิด feedback loop ให้เร็วขึ้น แต่ก็ไม่ได้คิดว่าทุกโค้ดจำเป็นต้องมี unit test จำนวนมหาศาล
ถ้าผู้คนกลับมาเข้าใจแก่นของ XP อีกครั้ง (สำหรับฉันคือ feedback loop) และสามารถสร้าง feedback loop ที่แน่นยิ่งขึ้นผ่านระบบ agent ที่อิงกับ LLM ได้ ก็น่าจะเป็นความก้าวหน้าครั้งใหญ่ของ software engineering
ฉันเริ่มต้นกับ XP และเคยยึดมั่นปฏิบัติมันอย่างจริงจัง เลยทำให้ตอนนี้ทำงานในองค์กรสไตล์ SCRUM ได้ยาก
SCRUM ส่วนใหญ่มีที่มาจาก XP แต่ตอนนี้ให้ความรู้สึกว่าเหลือแต่พิธีกรรมที่ไร้ความหมาย
ฉันคิดว่าสถานการณ์ในอุดมคติคือ นักพัฒนาสองคนทำ pair programming บน branch เดียวกันร่วมกับ AI agents
เป็น feedback loop ในอุดมคติที่มีทั้ง pair planning, review, development และ testing วนซ้ำอย่างเป็นธรรมชาติ
unit test ในยุค XP กับการทดสอบในตอนนี้ต่างกัน
ตอนนั้นเป็นการทดสอบในระดับฟังก์ชัน ไม่ใช่การทดสอบแยกตามแต่ละเมธอด
รู้สึกว่ามันขึ้นอยู่กับว่า AI จะช่วยปิด feedback loop ได้แม่นยำแค่ไหน
ฉันไม่คิดว่าการส่งมอบโค้ดเพียงครึ่งเดียวให้ผู้ใช้ (= ส่งขึ้น production) จะเป็น agile
ทีมของเราประกอบด้วยคนที่เป็น ex-Pivots และมาจาก Thoughtworks ทั้งหมด
pair programming, TDD และการมีลูกค้าอยู่ร่วมทีมเป็นเรื่องพื้นฐาน
และเราใช้ AI ใน IDE อย่างจริงจังมานานกว่า 2 ปีแล้ว
แต่ที่น่าประหลาดใจคือปีนี้ เราไม่ได้ทำงานแบบ 'แยกกันคนละส่วนกับ AI' กลับเริ่มทำ 'mobbing' ที่ทุกคน (4 คน) ซิงก์กันในโปรเจกต์เดียวและจดจ่อกับงานเดียวกัน
Claude Code ช่วยพิมพ์ให้ ขณะที่ทั้งสี่คนร่วมมือกันแบบเรียลไทม์
มันเป็นประสบการณ์ที่สนุกที่สุด มีสมาธิสูงที่สุด และมีประสิทธิภาพที่สุดจากการผสาน XP กับ AI ได้อย่างลงตัว
ฉันลืม XP ไปหมดแล้วจริง ๆ
บางส่วนกลายเป็นเรื่องปกติในทุกวันนี้ ส่วนที่เหลือหากมองด้วยมาตรฐานปัจจุบันก็น่าจะรู้สึกแปลกมาก
โดยเฉพาะอยากเน้นว่าควรหยุดคิดสักครั้งก่อนใช้ LLM พ่นโค้ดออกมาเกิน 1000 บรรทัดแบบไม่ทันคิด
ส่วนตัวอยากรู้ว่าคุณคิดว่าส่วนไหนของ XP ที่ดูแปลกที่สุด
อย่าตีความว่านี่หมายความว่าทุกคนต้องทำ pair programming กับ AI
การทำ pair programming กับเพื่อนร่วมทีมทำให้เราแบ่งปันวิธีคิดและบริบทของโค้ดต่อกันได้
แต่ถ้าทำ pair programming กับ AI พอปิด prompt ไป AI ก็ลืมทุกอย่างทันที
เพราะฉะนั้น XP ที่กำลังคุยกันอยู่นี้ก็ยังเป็น XP แบบ 'คนกับคน' เหมือนในยุค 1990
AI อาจเข้ามามีส่วนบ้าง แต่หัวใจยังคงเป็นคน
ถ้าไม่ทิ้งผลลัพธ์ไว้แบบชัดเจนก็จะเป็นแบบนั้น
เวลาสำรวจโค้ดใหม่ที่ยังมีเอกสารไม่พอ ถ้าเก็บสิ่งที่เรียนรู้ร่วมกับ LLM ไว้ใน repository ในรูปเอกสารหรือไฟล์ agent ก็อาจมีความหมายได้
ฉันกลับคิดว่าถ้าไม่ทำ pair programming กับ AI ต่างหากที่กำลังทำผิดทาง
เอาจริง ๆ ต่อให้เป็น pair programming ระหว่างคนกันเอง ตัวฉันในอนาคตก็มักลืมความทรงจำทั้งหมดในตอนนี้อยู่ดี
เราควรมุ่งไปสู่ pair ที่เน้นการทำเอกสาร
สรุปคือควรทำ XP pair programming ร่วมกับ LLM อย่างจริงจัง
น่าจะมีคนขายคอร์ส Extreme Vibing (XV) แน่ ๆ
Extreme Programming เป็นกระบวนทัศน์ที่รวบรวมแนวคิดหลายอย่างที่ใช้แยกเดี่ยวก็มีประโยชน์ได้เองอยู่แล้ว (เช่น TDD, pair programming, CI, feedback)
แต่ละอย่างมีประโยชน์ตามบริบท ทว่าไม่จำเป็นต้องใช้ทุกอย่างพร้อมกันตลอดเวลา
ในบริบทนี้จึงมองว่า XP สูญเสียพลังในฐานะแนวคิดที่สมบูรณ์หนึ่งเดียว
ทุกวันนี้ทีมส่วนใหญ่ปฏิบัติตามเพียงบางส่วนของ XP และแทบทุกองค์กรก็ไม่ได้ใช้ XP แบบครบชุดจริง ๆ
สำหรับ agile บริษัทใหญ่ส่วนมากมักนำแนวปฏิบัติกว่า 90% ไปใช้ได้จริงราว 70%
ในทางปฏิบัติไม่เคยมีสักบริษัทเดียวที่ทำตามสิ่งที่อธิบายไว้ใน Agile Manifesto ได้ครบ 100% และที่ทำได้ดีที่สุดก็อยู่ราว 90%
แต่เพราะแนวปฏิบัติหลักทั้งหมดถูกมัดรวมอยู่ในกระบวนทัศน์เดียว องค์กรต่าง ๆ จึงเรียกตัวเองว่า 'agile' ได้ง่าย
เลยทำให้การประกาศว่า “เราจะเปลี่ยนไปเป็น agile” เป็นเรื่องที่ง่ายกว่ามาก
นี่คือเหตุผลที่หนังสือ XP แบ่งเป็นระดับปรัชญา หลักการ และภาคปฏิบัติ
ประโยคที่น่าประทับใจที่สุดในหนังสือเล่มนั้นคือ คุณค่าที่ไม่มีการปฏิบัตินั้นตายแล้ว และการปฏิบัติที่ไม่มีคุณค่าก็ว่างเปล่าเช่นกัน
ท้ายที่สุด เป้าหมายสูงสุดไม่ใช่ best practice แต่คือการมอบอำนาจให้ทีม กำหนด process ด้วยตัวเอง และสร้างซอฟต์แวร์ที่น่าเชื่อถือและออกแบบมาอย่างดี
ที่ XP ดูเหมือน 'ชุดเครื่องมือสารพัดอย่าง' ก็เพราะแท้จริงแล้วมันคือสิ่งที่ทีมที่มีความเป็นเจ้าของสูงเลือกหยิบมาใช้
ในทางปฏิบัติฉันทำสิ่งที่กล่าวถึงข้างต้นทั้งหมด (TDD, pair programming, CI, feedback) กับ production code อยู่เสมอถ้าสภาพแวดล้อมเอื้ออำนวย
เลยสงสัยว่าในสถานการณ์แบบไหนเราถึงจะมองว่าแนวปฏิบัติเหล่านี้ 'ผิด'
คิดว่าเราพัฒนามาไกลมากจากยุค agile แบบเคร่งครัดสุดโต่งในยุค 90
ตอนนี้มี workflow ที่ใช้ AI มากขึ้น จึงควรโฟกัสให้มากขึ้นกับการทบทวน software process ในทิศทางที่เพิ่มโอกาสของผลลัพธ์ที่ดีต่อผู้ใช้จริง ไม่ใช่แค่เพิ่มปริมาณผลลัพธ์
ฉันคิดว่า XP เป็นจุดเริ่มต้นที่ดีสำหรับเรื่องนั้น (แต่ไม่จำเป็นต้องเป็นจุดจบ)
Extreme Programming (XP) เป็น agile methodology ที่เน้นรอบการทำงานสั้น ๆ, feedback ที่รวดเร็ว และการออกแบบที่เรียบง่าย โดยอาศัยแนวปฏิบัติอย่าง pair programming, TDD และ CI เพื่อปรับตัวต่อการเปลี่ยนแปลงได้อย่างรวดเร็ว
มันให้ความสำคัญกับการสร้างสิ่งที่เล็กและเร็วที่สุดเท่าที่จะทำได้ แล้วเรียนรู้และปรับคุณภาพซ้ำร่วมกับลูกค้า
~ GPT5 in perplexity
ช่วงนี้รู้สึกว่า waterfall กำลังกลับมาอีกครั้งพร้อมกับ AI
ที่จริง waterfall ไม่เคยหายไปไหนเลย
เป็นเรื่องน่าเสียดายที่ waterfall กลับมา
waterfall เป็นแนวทางที่ไม่ถูกต้องในกรณีส่วนใหญ่
ในฐานะอดีตคนจาก Pivot และคนที่คลั่งไคล้ XP ฉันเห็นด้วย
ดูคอมเมนต์ของฉันด้านล่างด้วย
ฉันยังคงทำ XP อยู่จนถึงตอนนี้