eXtreme Programming

eXtreme Programming — มักเรียกสั้น ๆ ว่า XP — คือสมาชิกที่เรียกร้องมากที่สุดในกลุ่ม agile East Agile Tracker สร้างขึ้นเพื่อ XP เป็นอันดับแรก ทุกอย่างที่เหลือเป็นผลพวงมาจากมัน

หน้านี้ครอบคลุมว่า XP คืออะไร ทำไมมันถึงได้ผล และจะปฏิบัติมันอย่างไรโดยมี tracker เป็นพื้นที่วางแผนของคุณ

XP คืออะไร

XP ถูกสร้างขึ้นโดย Kent Beck ในช่วงปลายทศวรรษ 1990 หนังสือเล่มแรก — Extreme Programming Explained: Embrace Change — ตีพิมพ์ในปี 1999 มันเริ่มต้น เหมือนหลาย ๆ สิ่ง ด้วยทีมที่หงุดหงิดที่พยายามส่งมอบระบบเงินเดือนที่ Chrysler

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

“XP เป็นวิธีการแบบเบาสำหรับทีมขนาดเล็กถึงกลางที่พัฒนาซอฟต์แวร์ท่ามกลางข้อกำหนดที่คลุมเครือหรือเปลี่ยนแปลงอย่างรวดเร็ว” — Kent Beck

ห้าคุณค่า

XP ระบุห้าคุณค่าที่ทุกอย่างที่เหลือยึดโยงอยู่:

1. การสื่อสาร (Communication) — ทีมพูดคุยกัน ทุกวัน เกี่ยวกับงาน การออกแบบ อุปสรรค เห็นหน้ากันเมื่อเป็นไปได้ ไซโลคือศัตรู
2. ความเรียบง่าย (Simplicity) — ทำสิ่งที่ง่ายที่สุดที่อาจใช้ได้ผล คุณสามารถเพิ่มความซับซ้อนทีหลังได้หากคุณต้องการจริง ๆ คุณคงไม่ต้องหรอก
3. ฟีดแบ็ก (Feedback) — จากโค้ด (การทดสอบ) จากทีม (การเขียนโปรแกรมเป็นคู่ การรีวิว) จากผู้ใช้ (release บ่อย ๆ) รับมันให้เร็ว
4. ความกล้าหาญ (Courage) — บอกความจริงเกี่ยวกับความก้าวหน้า การประเมิน และการออกแบบ ทิ้งโค้ดที่ใช้ไม่ได้ Refactor สิ่งที่กำลังฉุดรั้งคุณ
5. ความเคารพ (Respect) — ทุกคนในทีม — และตอนนี้ ทุกเอเจนต์ในทีม — มอบคุณค่า ปฏิบัติต่อกันให้สมกัน

การปฏิบัติ

XP มีชื่อเสียงจากการปฏิบัติดั้งเดิมสิบสองข้อ จัดเป็นสี่ด้าน:

การวางแผน

• Planning Game — ทีมและลูกค้าวางแผนร่วมกัน: อะไรจะมาเป็นลำดับถัดไป ในลำดับใด แต่ละชิ้นใหญ่แค่ไหน
• Small Releases — ส่งมอบบ่อย ๆ เป็นวัน ไม่ใช่เป็นเดือน รับฟีดแบ็กบนสิ่งที่เป็นรูปธรรม
• User Stories — ข้อกำหนดคือการสนทนา จับเป็น story สั้น ๆ จากมุมมองของผู้ใช้ “ในฐานะผู้ใช้ ฉันต้องการ X เพื่อที่ Y”

การออกแบบ

• Simple Design — การออกแบบที่ง่ายที่สุดที่ผ่านการทดสอบและแสดงทุกแนวคิดที่จำเป็น ไม่มากกว่านั้น
• Refactoring — ปรับปรุงการออกแบบของโค้ดที่ใช้งานได้แล้ว อย่างต่อเนื่อง
• System Metaphor — เรื่องเล่าร่วมกันว่าระบบทำงานอย่างไร ใช้เพื่อให้การตัดสินใจด้านการออกแบบสอดคล้องกัน

การเขียนโค้ด

• Pair Programming — นักพัฒนาสองคน คีย์บอร์ดเดียว คนหนึ่งขับ คนหนึ่งนำทาง สลับกันบ่อย ๆ
• Collective Code Ownership — ใครก็ตามสามารถปรับปรุงโค้ดใดก็ได้ ไม่มีอาณาเขตส่วนตัว
• Continuous Integration — บูรณาการและทดสอบโค้ดหลายครั้งต่อวัน จับการพังทันที
• Coding Standards — สไตล์ที่ตกลงกันเพื่อให้โค้ดอ่านเหมือนคนคนเดียวเขียน

การทดสอบ

• Test-Driven Development (TDD) — เขียนการทดสอบที่ล้มเหลวก่อน แล้วจึงเขียนโค้ดที่ทำให้มันผ่าน
• Acceptance Tests — ลูกค้านิยามในรูปโค้ดหรือรูปแบบที่ทำงานได้ว่า “เสร็จ” หมายถึงอะไรสำหรับแต่ละ story

ทำไม XP ถึงได้ผล

XP ไม่สบาย การเขียนโปรแกรมเป็นคู่บังคับให้คุณคิดออกมาดัง ๆ TDD บังคับให้คุณรู้ว่าความสำเร็จหน้าตาเป็นอย่างไรก่อนที่คุณจะเขียนโค้ด การบูรณาการอย่างต่อเนื่องฆ่า branch ที่อยู่ยาวนานสุดโปรดของคุณ release เล็ก ๆ หมายความว่าคุณไม่สามารถซ่อนตัวอยู่หลัง roadmap หกเดือนได้

มันได้ผลเพราะสิ่งเหล่านี้ทั้งหมดทำให้วงจรฟีดแบ็กสั้นลง ยิ่งคุณรู้เร็วว่าคุณผิด การแก้ไขยิ่งถูก โดยพื้นฐานแล้ว XP คือการทำให้วงจรฟีดแบ็กแน่นที่สุดเท่าที่จะเป็นไปได้

มันยังเกี่ยวกับ ความกล้าหาญและความเคารพ ด้วย คุณทำ XP ได้เฉพาะในทีมที่ไว้วางใจกันมากพอที่จะผิดออกมาดัง ๆ

โมเดล story ที่มีวินัย

East Agile Tracker เข้ารหัสทฤษฎีการวางแผนเฉพาะหนึ่ง ถือว่าส่วนนี้เป็นคู่มือการทำงานสำหรับ ทำไม โมเดลข้อมูลถึงหน้าตาเป็นแบบนี้ — และเป็นคู่มือภาคสนามว่าจะทำอะไร (และไม่ทำอะไร) ในทางปฏิบัติ

ทำไมสี่ประเภท story ถึงสำคัญ

ทุกอย่างคือ story แต่มีอยู่สี่ชนิด และความแตกต่างคือประเด็นทั้งหมด:

• Feature มีแต้มและเป็นสิ่งเดียวที่ “นับ” เข้าความเร็ว สิ่งนี้บังคับให้คุณซอยงานออกเป็นคุณค่าที่ผู้ใช้สังเกตเห็นได้
• Bug ไม่มีแต้ม (ศูนย์) ข้อบกพร่องไม่ได้รับเครดิต ซึ่งทำให้ต้นทุนของการทำงานซ้ำมองเห็นได้แทนที่จะได้รับรางวัล
• Chore ก็ไม่มีแต้มเช่นกัน — งานจำเป็นที่ไม่มีคุณค่าโดยตรงต่อผู้ใช้ (infra, refactor, การตั้งค่า) การคงมันไว้ที่ศูนย์กดดันให้ทีมรวมมันเข้ากับ feature ทุกที่ที่ทำได้ เพื่อให้กรอบคิดเรื่องคุณค่ายังคงซื่อตรง
• Release คือเครื่องหมายศูนย์แต้มที่ใช้ยึดหมุดหมายและให้เครื่องมือคาดการณ์วันที่ได้

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

Backlog เดียวที่เรียงลำดับ

สามโซน หนึ่งกฎ

• Icebox คือแหล่งรวมไอเดียที่ยังไม่จัดลำดับความสำคัญ
• Backlog คือรายการที่เรียงลำดับอย่างเข้มงวด มีลำดับความสำคัญเดียว — ไม่มีการเสมอกัน ไม่มี “P1/P1/P1”
• โซน Current ถือรอบงานที่กำลังดำเนินอยู่

เจ้าของผลิตภัณฑ์เป็นเจ้าของลำดับจากบนลงล่าง และค่าคงที่คือ ส่วนบนสุดของ backlog ต้องสำคัญที่สุดและระบุได้ดีที่สุดเสมอ โดยความชัดเจนค่อย ๆ ลดลงตามความเหมาะสมเมื่อคุณเลื่อนลง Story ใกล้ส่วนบนที่มีเกณฑ์การตรวจรับคลุมเครือคือบั๊กในการวางแผน Icebox ได้รับอนุญาตให้เป็นสุสานได้ Backlog ไม่ได้

การวางแผนอัตโนมัติที่ขับเคลื่อนด้วยความเร็ว

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

• คุณประเมิน เฉพาะ feature โดยใช้แต้มเชิงเปรียบเทียบ (Fibonacci 1/2/3/5/8 หรือมาตรวัดที่กระชับกว่าของเรา 0/1/2/3) ไม่ใช่ชั่วโมง การประเมินคือการสนทนาเรื่องขนาด ไม่ใช่คำสัญญา
• คุณ ไม่เล่นกลกับความเร็ว การพองแต้มเพื่อ “ดูเร็ว” หรือการให้แต้มกับ chore ทำลายการคาดการณ์ที่ทำให้ทั้งระบบซื่อตรง ความเร็วคือเครื่องมือวัด และคุณไม่ปลอมแปลงเครื่องมือของคุณเอง

ผลตอบแทนคือการคาดการณ์วันที่ release กลายเป็นการคำนวณมากกว่าการเจรจาต่อรอง และการสนทนากับผู้มีส่วนได้ส่วนเสียเปลี่ยนจาก “คุณรับปากได้ไหมว่าจะเสร็จ X ภายในวันศุกร์” เป็น “ที่ความเร็วปัจจุบัน release นี้จะมาถึงราววันที่ Y — นี่คือการแลกเปลี่ยนระหว่างขอบเขตกับวันที่”

วงจรชีวิตของ story และวงจรการตรวจรับ

เครื่องสถานะคือ Start → Finish → Deliver → Accept / Reject สถานะที่สำคัญคือ Deliver: วิศวกรทำเครื่องหมาย story ว่าส่งมอบแล้ว แต่มันยังไม่เสร็จจนกว่าเจ้าของผลิตภัณฑ์จะตรวจรับอย่างชัดเจนเทียบกับเกณฑ์การตรวจรับ หรือปฏิเสธมัน ซึ่งจะเตะกลับ สิ่งนี้ฝังวงจรการรับฟีดแบ็กจากลูกค้าเข้าไปในทุก story แทนที่จะเลื่อนการตรวจรับไปไว้ตอนสาธิตท้าย sprint

เกณฑ์การตรวจรับควรอยู่บน story ก่อน เริ่มทำ ทางที่ดีในรูปแบบ Given/When/Then เพื่อให้แมปเข้ากับการทดสอบการตรวจรับได้โดยตรง INVEST เป็นเครื่องตรวจสอบความสมเหตุสมผลว่า story มีรูปแบบที่ดีหรือไม่:

• Independent — ปล่อยได้โดยไม่ต้องพึ่ง story อื่น
• Negotiable — จับเจตนา ไม่ใช่ข้อกำหนดที่ตายตัว
• Valuable — มีคุณค่าต่อผู้ใช้หรือผู้มีส่วนได้ส่วนเสีย
• Estimable — ทีมประเมินขนาดได้
• Small — พอดีในรอบงานได้สบาย ๆ
• Testable — มีเกณฑ์การตรวจรับที่ทดสอบได้

จังหวะ (Cadence)

พิธีการวางแผนเบาและสม่ำเสมอ:

• การประชุมวางแผนรอบงาน รายสัปดาห์เพื่อให้แต้ม story ใหม่และตรึงเกณฑ์การตรวจรับที่ส่วนบนของ backlog
• standup รายวัน สั้น ๆ ที่เน้นการไหลและตัวขัดขวาง
• retrospective ต่อรอบงานเพื่อปรับกระบวนการ

รอบงานมักเป็นหนึ่งหรือสองสัปดาห์ — สั้นพอที่การประเมินที่ผิดจะถูกค้นพบได้อย่างไม่แพง

การปฏิบัติทางวิศวกรรมที่ทำให้การวางแผนได้ผล

การวางแผนแบบ tracker คือครึ่งที่มองเห็นได้ของ XP มันพังทลายหากไม่มีครึ่งทางวิศวกรรม

• Test-first / TDD และชุดทดสอบการตรวจรับที่แท้จริงคือสิ่งที่ทำให้ “ส่งมอบแล้ว” มีความหมาย
• การบูรณาการอย่างต่อเนื่อง และ release เล็ก ๆ บ่อย ๆ ทำให้ cycle time สั้นเพื่อให้ความเร็วคงที่แทนที่จะกระท่อนกระแท่น
• การเขียนโปรแกรมเป็นคู่ (หรือการรีวิวที่แข็งแกร่ง) ทำให้งานที่กำลังทำอยู่ต่ำ — ทำเสร็จก่อนเริ่ม — ซึ่งเป็นคันโยกที่ใหญ่ที่สุดต่อ cycle time
• เจ้าของผลิตภัณฑ์ที่พร้อมใช้งาน คือสิ่งที่ป้องกันไม่ให้วงจรตรวจรับ/ปฏิเสธหยุดชะงัก

Anti-pattern ที่ต้องระวัง

ความล้มเหลวที่เกิดซ้ำ:

• ปฏิบัติต่อ Backlog เหมือนที่จอดรถ แทนที่จะเป็นลำดับความสำคัญที่แท้จริง
• ประเมิน bug และ chore เพื่อทำให้ความเร็วดูดีขึ้น
• แบก story ขนาดยักษ์ ที่ไม่สามารถทำเสร็จในรอบงานได้ แยกจนกว่าแต่ละอันจะส่งมอบได้อย่างอิสระ
• ปล่อยให้ story กองพะเนินในสถานะ Delivered เพราะไม่มีใครตรวจรับ

อันใดอันหนึ่งในนี้แอบเปลี่ยนระบบเชิงประจักษ์ให้กลับไปเป็นการวางแผนแบบเพ้อฝัน Tracker หยุดคุณจากการทำมันไม่ได้ มันทำได้แค่ทำให้มันมองเห็นได้ ดูคอลัมน์ Delivered ของคุณที่ปลายทุกรอบงาน — หากมันเพิ่มขึ้น นั่นคือสัญญาณของคุณ

XP กับ East Agile Tracker

Tracker คือพื้นที่วางแผนที่ทีม XP อยากได้มาตั้งแต่สมัย Pivotal Tracker ทุกแนวคิดแมปได้โดยตรง:

User Stories → Stories

User story ของ XP คือ story ของ East Agile Tracker เขียนมันในประเภท Feature ใช้คำอธิบายสำหรับการสนทนา ใช้ความคิดเห็นสำหรับการอภิปรายต่อเนื่อง เกณฑ์การตรวจรับอยู่ในคำอธิบาย

Planning Game → บอร์ด

Planning Game ใน XP คือการสนทนาระหว่างฝ่ายธุรกิจและทีมเกี่ยวกับลำดับความสำคัญและขนาด ใน East Agile Tracker:

1. คนฝ่ายผลิตภัณฑ์เขียน story ใน Backlog และจัดลำดับตามลำดับความสำคัญ
2. ทีมประเมิน feature เป็นแต้ม (มาตรวัด Fibonacci หรือ East Agile)
3. ระบบวางแผนรอบงานอัตโนมัติจากความเร็ว
4. ทีมเริ่ม story จากส่วนบนของคอลัมน์ Current

แค่นั้น “เกม” อยู่ในการสนทนา tracker แค่บันทึกคะแนนไว้

Small Releases → Releases (ประเภท story)

XP บอกว่า release บ่อย ๆ Release เป็นหนึ่งในสี่ประเภท story ใน East Agile Tracker สร้าง release สำหรับทุกหมุดหมายการส่งมอบ ลากมันเข้าไปในรอบงานที่มันส่งมอบ Release ข้าม Started/Finished/Delivered และไปยัง Accepted โดยตรงเมื่อคุณส่งมอบ

Continuous Integration → เครื่องสถานะของ story

เครื่องสถานะไม่ใช่ CI โดยตรง — นั่นคือระบบ build ของคุณ — แต่เส้นทาง Finished → Delivered → Accepted สะท้อนวงจรการตรวจรับของลูกค้าที่ XP อธิบาย ทำงานเสร็จ ส่งมอบให้ลูกค้า ตรวจรับเมื่อยืนยันว่าใช้งานได้

Velocity → “อากาศเมื่อวาน”

XP เรียกมันว่า อากาศเมื่อวาน (yesterday’s weather): ปริมาณที่คุณทำเสร็จในรอบงานที่แล้วคือการพยากรณ์ที่ดีที่สุดว่าคุณจะทำเสร็จเท่าไรในรอบนี้ East Agile Tracker คำนวณความเร็วโดยอัตโนมัติ — ค่าเฉลี่ยของรอบงานล่าสุด กลยุทธ์ที่ตั้งค่าได้ — และใช้มันเพื่อวางแผนความจุของรอบงานถัดไปอัตโนมัติ

Acceptance Tests → Reviews

การรีวิว story ใน tracker แมปเข้ากับการตรวจรับ มอบหมายผู้รีวิว (ลูกค้า เจ้าของผลิตภัณฑ์ หรือแม้แต่เอเจนต์ที่ทำหน้าที่เป็นหนึ่งในนั้น) พวกเขาอนุมัติหรือปฏิเสธ การปฏิเสธจะส่ง story กลับไปยัง Started

Pair Programming → ความเป็นเจ้าของร่วม

ทีม XP จับคู่กันที่โค้ด ใน tracker สิ่งนี้ปรากฏเป็น เจ้าของหลายคนบน story มอบหมายทั้งคู่ให้กับ story ทั้งสองชื่อปรากฏบนการ์ด

XP กับเอเจนต์ — การปฏิบัติใหม่

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

ในการปฏิบัติของเรา — และสิ่งที่ tracker สร้างขึ้นมาเพื่อ — เอเจนต์ คือสมาชิกทีม XP ที่มีชื่อ มันมีบทบาทของตัวเอง มีคู่ของตัวเอง (มนุษย์หรือเอเจนต์) และมีร่องรอยการตรวจสอบของตัวเอง มันสามารถทำทุกอย่างที่สมาชิกทีมที่เป็นมนุษย์ทำได้ ในพื้นที่วางแผน: ประเมิน เป็นเจ้าของ story แสดงความคิดเห็น เปลี่ยนสถานะ ตรวจรับการรีวิว

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

เราไม่ได้ใส่เอเจนต์ไว้ในตัว tracker ให้ทำการเขียนโค้ด เรามอบพื้นที่วางแผนให้มนุษย์ และ เอเจนต์ทำงานร่วมกัน คุณนำเอเจนต์เขียนโค้ดมา — Claude Code, Codex หรือของคุณเอง — และเชื่อมต่อมันกับ tracker ผ่าน API เอเจนต์รับ story ทำงาน แสดงความคิดเห็น เปลี่ยนสถานะ คุณรีวิวร่องรอยและตรวจรับ

นี่คือ การวางแผนแบบ Agile ที่ทุกคนมีส่วนร่วม (Inclusive Agile Planning) มันคือ XP กับทีมที่มันมีอยู่จริง

อ่านเพิ่มเติม

• Extreme Programming Explained — หนังสือรากฐานของ Kent Beck ปี 1999
• ปฏิญญา Agile — ที่ที่กลุ่มนี้เริ่มต้น
• การพัฒนาแบบ Agile — ภาพที่กว้างกว่า
• คู่มือการใช้งาน — คู่มือปฏิบัติสำหรับ tracker
• คู่มือ API — เสียบเอเจนต์เขียนโค้ดของคุณเข้าไป