การเขียนโปรแกรมแบบสุดขั้ว ( XP ) เป็น วิธี การพัฒนาซอฟต์แวร์แบบ Agileที่ใช้ในการสร้าง ระบบ ซอฟต์แวร์บทความนี้จะอธิบายรายละเอียดเกี่ยวกับแนวปฏิบัติที่ใช้ในวิธีการนี้ การเขียนโปรแกรมแบบสุดขั้วมีแนวปฏิบัติ 12 ข้อ ซึ่งจัดกลุ่มเป็น 4 ด้าน โดยได้มาจากแนวปฏิบัติที่ดีที่สุดของวิศวกรรมซอฟต์แวร์^{[ 1 ]}

การเขียนโปรแกรมแบบคู่ (Pair programming)เป็นวิธีการเขียนโปรแกรมที่คนสองคนร่วมกันเขียนโค้ดในงานเดียว โปรแกรมเมอร์คนหนึ่งควบคุมเวิร์กสเตชันและคิดเกี่ยวกับรายละเอียดของการเขียนโค้ดเป็นหลัก ส่วนโปรแกรมเมอร์อีกคนจะเน้นที่ภาพรวมและคอยตรวจสอบโค้ดที่โปรแกรมเมอร์คนแรกเขียนอยู่ตลอดเวลา โปรแกรมเมอร์ทั้งสองจะสลับบทบาทกันเป็นช่วงๆ ตั้งแต่ไม่กี่นาทีถึงหลายชั่วโมง

คู่ทำงานไม่ได้ตายตัว โปรแกรมเมอร์จะสลับคู่กันบ่อยๆ เพื่อให้ทุกคนรู้ว่าแต่ละคนกำลังทำอะไร และทุกคนคุ้นเคยกับระบบโดยรวม แม้แต่ส่วนที่อยู่นอกเหนือความเชี่ยวชาญของตนเอง ด้วยวิธีนี้ การเขียนโปรแกรมแบบคู่ยังช่วยเสริมสร้างการสื่อสารในทีมได้อีกด้วย (ซึ่งสอดคล้องกับแนวคิดเรื่องการเป็นเจ้าของร่วมกัน)

กระบวนการวางแผนหลักใน Extreme Programming เรียกว่า Planning Game เกมนี้เป็นการประชุมที่เกิดขึ้นหนึ่งครั้งต่อรอบการพัฒนา โดยทั่วไปคือสัปดาห์ละครั้ง กระบวนการวางแผนแบ่งออกเป็นสองส่วน:

• การวางแผนการปล่อยเวอร์ชัน : ขั้นตอนนี้มุ่งเน้นไปที่การกำหนดว่าข้อกำหนดใดบ้างที่จะรวมอยู่ในเวอร์ชันที่จะออกในระยะใกล้ และควรส่งมอบเมื่อใด ทั้งลูกค้าและนักพัฒนาต่างมีส่วนร่วมในขั้นตอนนี้ การวางแผนการปล่อยเวอร์ชันประกอบด้วยสามขั้นตอน:
  • ขั้นตอนการสำรวจ: ในขั้นตอนนี้ ลูกค้าจะคัดเลือกข้อกำหนดที่มีคุณค่าสูงสำหรับระบบ โดยจะเขียนข้อกำหนดเหล่านี้ลงบนการ์ดเรื่องราวของผู้ใช้
  • ขั้นตอนการให้คำมั่นสัญญา: ในขั้นตอนการให้คำมั่นสัญญานี้ ฝ่ายธุรกิจและนักพัฒนาจะให้คำมั่นสัญญาเกี่ยวกับฟังก์ชันการทำงานที่จะรวมไว้ และวันที่วางจำหน่ายเวอร์ชันถัดไป
  • ขั้นตอนการปรับแผน: ในขั้นตอนการปรับแผนนี้ สามารถปรับแผน เพิ่มข้อกำหนดใหม่ และ/หรือ เปลี่ยนแปลงหรือลบข้อกำหนดที่มีอยู่ได้
• การวางแผนรอบการทำงาน (Iteration Planning ): ขั้นตอนนี้จะวางแผนกิจกรรมและภารกิจของนักพัฒนา โดยที่ลูกค้าจะไม่เข้ามาเกี่ยวข้องในกระบวนการนี้ การวางแผนรอบการทำงานประกอบด้วยสามขั้นตอนหลัก:
  • ขั้นตอนการสำรวจ: ในขั้นตอนนี้ ข้อกำหนดจะถูกแปลงเป็นงานต่างๆ งานเหล่านั้นจะถูกบันทึกไว้ในบัตรงาน
  • ขั้นตอนการกำหนดความรับผิดชอบ: จะมีการมอบหมายงานให้กับโปรแกรมเมอร์และประเมินระยะเวลาที่ใช้ในการดำเนินการให้แล้วเสร็จ
  • ขั้นตอนการกำกับดูแล: ดำเนินงานต่างๆ และผลลัพธ์สุดท้ายต้องตรงกับเรื่องราวของผู้ใช้ที่วางแผนไว้ตั้งแต่แรก

จุดประสงค์ของเกมวางแผนคือการชี้นำผลิตภัณฑ์ไปสู่การส่งมอบ แทนที่จะคาดการณ์วันที่แน่นอนว่าจะต้องส่งมอบเมื่อใดและผลิตเมื่อใด ซึ่งทำได้ยาก เกมวางแผนมีเป้าหมายที่จะ "ชี้นำโครงการ" ไปสู่การส่งมอบโดยใช้วิธีการที่ตรงไปตรงมา^{[ 2 ]}แนวทางเกมวางแผนถูกนำไปใช้ในกรอบการพัฒนาที่นอกเหนือจากระบบซอฟต์แวร์ ตัวอย่างเช่น ทีมงานใช้ในบริบทของ ความ คล่องตัวทางธุรกิจ^{[ 3 ]}

นี่เป็นกระบวนการแบบวนซ้ำในการรวบรวมข้อกำหนดและประเมินผลกระทบของข้อกำหนดแต่ละข้อต่อปริมาณงาน

• เขียนเรื่องราว: ฝ่ายธุรกิจมีปัญหาเข้ามา ในระหว่างการประชุม ฝ่ายพัฒนาจะพยายามกำหนดปัญหาและรวบรวมข้อกำหนดต่างๆ โดยอิงจากปัญหาทางธุรกิจ จะต้องเขียนเรื่องราว ( เรื่องราวของผู้ใช้ ) ขึ้นมา ฝ่ายธุรกิจจะเป็นผู้ระบุว่าต้องการให้ส่วนใดส่วนหนึ่งของระบบทำอะไร สิ่งสำคัญคือฝ่ายพัฒนาต้องไม่มีอิทธิพลต่อเรื่องราวนี้ เรื่องราวจะถูกเขียนลงบนการ์ดเรื่องราวของผู้ใช้
• ประเมินงาน: ทีมพัฒนาจะประเมินว่าต้องใช้เวลานานแค่ไหนในการดำเนินงานตามที่ระบุไว้ในสตอรี่การ์ด ทีมพัฒนาอาจสร้างโซลูชันแบบเร่งด่วนเพื่อวิเคราะห์หรือแก้ไขปัญหา โซลูชันเหล่านี้จะใช้สำหรับการประเมินและจะถูกยกเลิกเมื่อทุกคนเข้าใจปัญหาอย่างชัดเจนแล้ว ทั้งนี้ อาจไม่มีผลต่อข้อกำหนดทางธุรกิจ
• แบ่งเรื่องราวออกเป็นส่วนๆ: ความซับซ้อนที่สำคัญในการออกแบบทุกอย่างจะต้องได้รับการแก้ไขก่อนเริ่มวางแผนการทำงานในแต่ละรอบ หากทีมพัฒนาไม่สามารถประเมินเรื่องราวได้ ก็จำเป็นต้องแบ่งเรื่องราวออกเป็นส่วนๆ และเขียนใหม่ทั้งหมด

เมื่อภาคธุรกิจไม่สามารถหาความต้องการเพิ่มเติมได้อีกแล้ว ขั้นตอนต่อไปคือการให้คำมั่นสัญญา

ขั้นตอนนี้เกี่ยวข้องกับการพิจารณาต้นทุน ผลประโยชน์ และผลกระทบต่อกำหนดการ โดยประกอบด้วยสี่ส่วนดังนี้:

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

ฝ่ายธุรกิจจะจัดเรียงเรื่องราวของผู้ใช้ตามมูลค่าทางธุรกิจ โดยจะแบ่งออกเป็นสามกอง:

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

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

• กำหนดดัชนีความเสี่ยง: ให้คะแนนดัชนีความเสี่ยงแก่เรื่องราวของผู้ใช้แต่ละเรื่องตั้งแต่ 0 ถึง 2 ในแต่ละปัจจัยต่อไปนี้:
  • ความครบถ้วน (เรารู้รายละเอียดเรื่องราวทั้งหมดหรือไม่?)
    • เสร็จสมบูรณ์ (0)
    • ไม่สมบูรณ์ (1)
    • ไม่ทราบ (2)
  • ความผันผวน (มีโอกาสเปลี่ยนแปลงหรือไม่?)
    • ต่ำ (0)
    • ปานกลาง (1)
    • สูง (2)
  • ความซับซ้อน (การสร้างนั้นยากแค่ไหน?)
    • ง่าย (0)
    • มาตรฐาน (1)
    • ซับซ้อน (2)

ดัชนีทั้งหมดสำหรับเรื่องราวของผู้ใช้จะถูกบวกเข้าด้วยกัน โดยกำหนดดัชนีความเสี่ยงให้กับเรื่องราวของผู้ใช้เป็นต่ำ (0–1), ปานกลาง (2–4) หรือสูง (5–6)

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

โดยคำนึงถึงความเร็วในการทำงานของทีมและกำหนด Storypoints ที่จะวางแผน ระยะเวลาของแต่ละรอบการทำงานอาจอยู่ที่ 1 ถึง 3 สัปดาห์

ขั้นตอนการสำรวจในการวางแผนการทำงานแบบวนซ้ำนั้นเกี่ยวข้องกับการสร้างภารกิจและประเมินเวลาในการดำเนินการ

• แปลงข้อกำหนดให้เป็นงาน: จัดทำเป็นบัตรงาน
• การรวม/แบ่งงาน: หากโปรแกรมเมอร์ไม่สามารถประเมินงานได้เนื่องจากงานนั้นเล็กเกินไปหรือใหญ่เกินไป โปรแกรมเมอร์จะต้องรวมหรือแบ่งงานนั้นออก
• ประเมินงาน: ประเมินเวลาที่จะใช้ในการดำเนินงานให้แล้วเสร็จ

ในขั้นตอนการกำหนดข้อผูกพันในการวางแผนการทำงานแบบวนซ้ำ โปรแกรมเมอร์จะได้รับมอบหมายงานที่เกี่ยวข้องกับเรื่องราวของผู้ใช้ต่างๆ

• โปรแกรมเมอร์รับงาน: โปรแกรมเมอร์แต่ละคนจะเลือกงานที่ตนเองรับผิดชอบ
• โปรแกรมเมอร์ประเมินงาน: เนื่องจากตอนนี้โปรแกรมเมอร์เป็นผู้รับผิดชอบงานแล้ว เขาหรือเธอจึงควรประเมินระยะเวลาของงานในท้ายที่สุด
• กำหนดค่าตัวประกอบภาระงาน: ตัวประกอบภาระงานแสดงถึงปริมาณเวลาในการพัฒนาจริงที่เหมาะสมต่อโปรแกรมเมอร์หนึ่งคนภายในหนึ่งรอบการทำงาน ตัวอย่างเช่น ในสัปดาห์ทำงาน 40 ชั่วโมง โดยมีเวลา 5 ชั่วโมงสำหรับการประชุม เวลาในการพัฒนาจริงจะไม่เกิน 35 ชั่วโมง
• การปรับสมดุลงาน: เมื่อโปรแกรมเมอร์ทุกคนในทีมได้รับมอบหมายงานแล้ว จะมีการเปรียบเทียบเวลาที่คาดการณ์ไว้ของงานกับปัจจัยภาระงาน จากนั้นจึงปรับสมดุลงานให้กับโปรแกรมเมอร์แต่ละคน หากโปรแกรมเมอร์คนใดรับภาระงานมากเกินไป โปรแกรมเมอร์คนอื่นจะต้องรับภาระงานบางส่วนแทน และในทางกลับกัน

การดำเนินงานต่างๆ จะเกิดขึ้นในระหว่างขั้นตอนการกำหนดทิศทางของการทำซ้ำ

• รับบัตรงาน: โปรแกรมเมอร์จะได้รับบัตรงานสำหรับหนึ่งในงานที่ตนเองรับปากไว้
• หาคู่หู: โปรแกรมเมอร์คนนี้จะทำงานนี้ร่วมกับโปรแกรมเมอร์อีกคนหนึ่ง ซึ่งจะกล่าวถึงรายละเอียดเพิ่มเติมในหัวข้อการเขียนโปรแกรมแบบคู่ (pair programming )
• ออกแบบงาน: หากจำเป็น โปรแกรมเมอร์จะออกแบบฟังก์ชันการทำงานของงานนั้น
• ดำเนินการตามภารกิจโดยใช้การพัฒนาแบบทดสอบนำ (Test-Driven Development : TDD) (ดูรายละเอียดด้านล่าง)
• ดำเนินการทดสอบการทำงาน: ทำการทดสอบการทำงาน (ตามข้อกำหนดในเรื่องราวของผู้ใช้และบัตรงานที่เกี่ยวข้อง)

การทดสอบหน่วย (Unit test)คือการทดสอบอัตโนมัติที่ทดสอบการทำงานของส่วนต่างๆ ของโค้ด (เช่น คลาส เมธอด) ใน XP นั้น การทดสอบหน่วยจะถูกเขียนขึ้นก่อนที่จะเขียนโค้ดจริง วิธีการนี้มีจุดประสงค์เพื่อกระตุ้นให้โปรแกรมเมอร์คิดถึงเงื่อนไขที่โค้ดของตนอาจล้มเหลว XP กล่าวว่าโปรแกรมเมอร์จะเสร็จสิ้นการเขียนโค้ดส่วนใดส่วนหนึ่งเมื่อเขาหรือเธอไม่สามารถคิดหาเงื่อนไขเพิ่มเติมที่โค้ดอาจล้มเหลวได้อีก

การพัฒนาแบบทดสอบนำ (Test Driven Development) ดำเนินไปโดยการวนรอบขั้นตอนต่อไปนี้อย่างรวดเร็ว โดยแต่ละขั้นตอนใช้เวลาเพียงไม่กี่นาที หรืออาจจะน้อยกว่านั้นมาก เนื่องจากเรื่องราวของผู้ใช้แต่ละเรื่องมักต้องใช้เวลาทำงานหนึ่งถึงสองวัน ดังนั้นจึงจำเป็นต้องมีการวนรอบแบบนี้เป็นจำนวนมากต่อเรื่องราวหนึ่งเรื่อง

• เขียนUnit Test : โปรแกรมเมอร์เขียน Test ขั้นต่ำที่ควรจะล้มเหลวเนื่องจากฟังก์ชันการทำงานยังไม่ได้ถูกนำไปใช้ในโค้ดที่ใช้งานจริงอย่างสมบูรณ์
• เฝ้าดูการทดสอบใหม่ที่ล้มเหลว: โปรแกรมเมอร์ตรวจสอบว่าการทดสอบล้มเหลวจริงหรือไม่ แม้ว่าอาจดูเหมือนเสียเวลา แต่ขั้นตอนนี้มีความสำคัญอย่างยิ่ง เพราะเป็นการตรวจสอบว่าความเชื่อของคุณเกี่ยวกับสถานะของโค้ดที่ใช้งานจริงนั้นถูกต้อง หากการทดสอบไม่ล้มเหลว โปรแกรมเมอร์ควรพิจารณาว่ามีข้อบกพร่องในโค้ดทดสอบหรือไม่ หรือว่าโค้ดที่ใช้งานจริงรองรับฟังก์ชันการทำงานที่อธิบายไว้ในการทดสอบใหม่หรือไม่
• เขียนโค้ด: โปรแกรมเมอร์เขียนโค้ดสำหรับใช้งานจริงเพียงพอที่จะทำให้การทดสอบใหม่ผ่านเท่านั้น
• เรียกใช้การทดสอบ: การทดสอบหน่วยจะถูกเรียกใช้เพื่อตรวจสอบว่าโค้ดการผลิตใหม่ผ่านการทดสอบใหม่ และไม่มีการทดสอบอื่นใดล้มเหลว
• ปรับปรุงโครงสร้างโค้ด (Refactor ): กำจัดโค้ดที่ไม่พึงประสงค์ทั้งจากโค้ดที่ใช้งานจริงและโค้ดทดสอบ

สำหรับเวอร์ชันที่เข้มข้นกว่าของกระบวนการข้างต้น โปรดดูที่กฎสามข้อของ TDD ของลุงบ็อบ^{[ 4 ]}

ในแนวคิด XP นั้น "ลูกค้า" ไม่ใช่ผู้ที่จ่ายเงิน แต่เป็นผู้ที่ใช้งานระบบจริง ๆ XP กล่าวว่าลูกค้าควรอยู่พร้อมให้ความช่วยเหลือและตอบคำถามได้ตลอดเวลา ตัวอย่างเช่น ทีมที่พัฒนาระบบบริหารจัดการทางการเงินควรมีผู้ดูแลระบบการเงินรวมอยู่ด้วย ทักษะทั้งหมดที่จำเป็นในการส่งมอบผลิตภัณฑ์ซอฟต์แวร์ควรมีอยู่ในทีม

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

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

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

มาตรฐานการเขียนโค้ดคือชุดกฎที่ตกลงกันไว้ซึ่งทีมพัฒนาทั้งหมดเห็นพ้องต้องกันที่จะปฏิบัติตามตลอดทั้งโครงการ มาตรฐานนี้ระบุรูปแบบและสไตล์ที่สอดคล้องกันสำหรับซอร์สโค้ดภายในภาษาโปรแกรม ที่เลือก ตลอดจนโครงสร้างและรูปแบบการเขียนโปรแกรมต่างๆ ที่ควรหลีกเลี่ยงเพื่อลดโอกาสที่จะเกิดข้อผิดพลาด^{[ 5 ]} มาตรฐานการเขียนโค้ดอาจเป็นข้อกำหนดมาตรฐานที่กำหนดโดยผู้จำหน่ายภาษา (เช่น ข้อกำหนดการเขียนโค้ดสำหรับภาษาโปรแกรม Java ที่แนะนำโดย Sun) หรือกำหนดเองโดยทีมพัฒนา

ผู้สนับสนุน Extreme Programming สนับสนุนการเขียนโค้ดที่สามารถอธิบายตัวเองได้มากที่สุดเท่าที่จะเป็นไปได้ ซึ่งจะช่วยลดความจำเป็นในการใช้คำอธิบายโค้ดซึ่งอาจไม่สอดคล้องกับตัวโค้ดเอง^{[ 6 ]}

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

อุปมาอุปไมยของระบบคือเรื่องราวที่ทุกคน ไม่ว่าจะเป็นลูกค้า โปรแกรมเมอร์ หรือผู้จัดการ สามารถเล่าได้เกี่ยวกับวิธีการทำงานของระบบ มันเป็นแนวคิดในการตั้งชื่อคลาสและเมธอดที่ควรทำให้สมาชิกในทีมสามารถเดาหน้าที่การทำงานของคลาส/เมธอดนั้นๆ ได้ง่ายจากชื่อเพียงอย่างเดียว ตัวอย่างเช่น ระบบห้องสมุดอาจสร้างออบเจ็กต์loan_records(class)สำหรับborrowers(class)รายการหนึ่งๆ และหากรายการนั้นเลยกำหนดส่ง ระบบอาจดำเนินการ make_overdue กับออบเจ็กต์อีกตัวหนึ่งcatalogue(class)สำหรับแต่ละคลาสหรือการดำเนินการ หน้าที่การทำงานนั้นชัดเจนสำหรับทั้งทีม

แนวคิดคือ โปรแกรมเมอร์หรือนักพัฒนาซอฟต์แวร์ไม่ควรทำงานเกิน 40 ชั่วโมงต่อสัปดาห์ และหากมีการทำงานล่วงเวลาในสัปดาห์หนึ่ง สัปดาห์ถัดไปก็ไม่ควรมีการทำงานล่วงเวลาเพิ่มเติมอีก เนื่องจากวงจรการพัฒนาเป็นวงจรที่สั้นและมีการบูรณาการอย่างต่อเนื่อง และวงจรการพัฒนาเต็มรูปแบบ (การปล่อยเวอร์ชัน) เกิดขึ้นบ่อยกว่า โครงการใน XP จึงไม่จำเป็นต้องมีช่วงเวลาเร่งด่วน (crunch time) เหมือนโครงการอื่นๆ (ซึ่งต้องมีการทำงานล่วงเวลา)

นอกจากนี้ แนวคิดนี้ยังรวมถึงว่าคนเราจะทำงานได้ดีที่สุดและมีความคิดสร้างสรรค์มากที่สุดเมื่อได้พักผ่อนอย่างเพียงพอ

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

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

• การบูรณาการอย่างต่อเนื่อง
• การบูรณาการอย่างต่อเนื่องหลายขั้นตอน
• บัตรแสดงความรับผิดชอบและความร่วมมือของชั้นเรียน

• แนวทางปฏิบัติของ XP
• แนวทางการปฏิบัติ XP ของ Kent Beck
• รอน เจฟฟรีส์ เอ็กซ์พี แพรกเตอร์