Extreme Programming หรือ XP เป็นกระบวนการพัฒนาซอฟต์แวร์แบบ agile (lightweight)
XP มี practices ที่น่าสนใจเช่น strong customer orientation, planning game , very short release, test-first coding, etc
 
XP มีจุดอ่อนคือ

• ทำการ maintenance ยาก
• เกิด error-prone
• ปัญหาการมีตัวแทนลูกค้าหลายคน
• ปัญหาที่เกิดจากการทำ release อย่างรวดเร็ว
• automated test case XP ไม่ใช้เทคนิคต่อไปนี้
• IEEE 830 and Requirements specification Document
• Requirements as the basis for software plans
• Function Point Analysis (COCOMO)
• Code first
• UML
• Allocated requirements
• Waterfall model

 
XP vs. Capability Maturity Model (CMM)
CMM มี 5 level ใน level 2 เรียกว่า Repeatable มี 6 KPAs หนึ่งในนั้นคือเรื่อง Requirements Management จุดอ่อนสำคัญของวิธี XP คือไม่ทำ documentation of requirements ดังนั้นจึงทำให้เกิดปัญหาดังนี้

• written specification are missing or perfunctory (การเขียน specification ผิดพลาดหรือไม่สนใจที่จะเขียน)
• Maintenance costs are usually well above average (ค่าใช้จ่ายในการ maintenance สูงกว่าที่เฉลี่ยไว้)
• Litigation probability is alarming high (เกิดการฟ้องร้องคดีสูงจนน่าตกใจ)

ซึ่งมีผลกับ maintenance มากที่สุดทั้ง continuous maintenance และ discrete maintenance ดังนั้นวิธีการ XP ไม่ถูกยอมรับใน CMM/CMMI จึงมีการ modify XP โดยการจัดการ Requirement คือการทำ stories, onsite customer และ continuous integration ทำให้ modify XP ถูกยอมรับใน CMM/CMMI ใน level 2
 
XP vs. Sommerville-Sawyer model
Sommerville-Sawyer model มี 3 ระดับ คือ Defined Level – มากกว่า 85 point , Repeatable Level – มากกว่า 55 point แต่น้อยกว่า 85 point , Initial Level – น้อยกว่า 55 point มี 66 practice XP ถูกประเมินได้เพียง 31 point ถูกจัดอยู่ใน Initial Level เป็นระดับที่มีความเสี่ยงมากที่สุด ซึ่งมีเพียง 7 basic practices of Sommerville-Sawyer model เท่านั้นที่สนับสนุน XP เต็ม ๆ ดังนั้นจึงมีการ modify XP เมื่อทำการประเมินใหม่แล้วได้ point สูงขึ้นเป็น 78 point อยู่ใน Repeatable Level ทำให้ modify XP ถูกยอมรับใน Sommerville-Sawyer model ใน level 2
 
 
Reconciling XP with document requirements
บุคคลที่สำคัญที่สุดใน Modify XP คือ XP tester/analyst เป็นบุคคลที่ทำการวิเคราะห์สำหรับ requirement document and requirement management จากเดิม XP ไม่มีการทำ requirement document ดังนั้นจึงไม่ถูกยอมรับใน CMM และ Sommerville-Sawyer model ดังนั้นจึงพัฒนาเป็น Modify XP ซึ่งมีการทำ Requirements โดย XP tester/analyst และ Programmer ยังคงมองว่า Modify XP ยังเป็น Lightweight เหมือน XP เดิม Multiple customer representatives เดิม XP มองว่ามีเพียง customer representative แค่คนเดียว แต่ในความเป็นจริงไม่สามารถมองอย่างนั้นได้ ดังนั้นจึงมีการปรับปรุงตามแนวทาง Sommerville and Sawyer เพื่อให้สามารถพิจารณา many customer representatives ได้ดังนี้

• Identify and consult system stakeholders
• Collect requirements from multiple viewpoints
• Be sensitive to organizational and political considerations
• Plan for conflicts and conflict resolution
• The tester/anayst answers programmer’s questions
• The tester/anayst has every contact with the customer representatives
• The customer representatives participated in a modified Planning Game

Modified Planning Game ในหลายๆ customer representatives จะมี senior customer 1 คน โดยจะมีบทบาทหลักคือลดความขัดแย้งกันระหว่าง customer representatives และเป็นไปได้ที่ senior customer จะไม่มี domain knowledge แต่ customer representatives มี และ มีเวลาในการโต้แย้งรายละเอียดของระบบที่จะสร้าง ในการปรับปรุง Planning Game จะได้ผลคล้ายกับ Planning Game เดิม คือมี 3 ระยะ ดังนี้

• first move เป็นของธุรกิจ ตัวอย่าง customer representatives ทำ story cards
• second move ถูกทำโดย Development ซึ่ง developer ประมาณ effort in Ideal Engineering Time และ ประเมินความเสี่ยงที่เกิดขึ้นในแต่ละ story อาจใช้วิธี Delphi method
• third move ตัดสินใจในเรื่องขอบเขต เช่น งบประมาณและเวลา

Modifying the XP Lifecycle XP เดิมมีมุมมองการวางแผนใช้เวลาสั้นที่สุดคือไม่เกิน 2 เดือน ต่อ 1 release แต่มีปัญหาคือในการที่ใช้เวลาน้อยนั้นทำให้เกิดความเข้าใจที่ผิดได้ ดังนั้นจึงเสนอให้มีการปรับปรุง XP Life cycle และแนะนำให้ใช้ Requirement Engineering Phase ในตอนเริ่มต้น Project โดย phase นี้ใช้เวลาไม่นาน และมีการทำต่างๆ ดังนี้

• Collect the use scenarios
• Assess system feasibility
• Identify system stakeholders
• Roughly describe the system’s operating environment
• Look for main domain constraints
• Prototype poorly understood requirements

Conclusions
ใน paper นี้ เสนอการปรับปรุง 3 วิธีให้กับ XP methodology

• การเขียนเอกสาร Requirement ที่จัดการโดย tester/analyst
• ปรับปรุง planning game ตาม customer representatives หลายคน ( XP เดิมมี customer representative คนเดียว)
• Requirement Engineering Phase ตอนเริ่มต้นของ Project จัดการ wide perspective ของระบบที่จะพัฒนาต่อไป จากประสบการณ์แสดงให้เห็นถึงการแก้ไขอย่างง่ายและผลลัพธ์ methodology เกือบจะ lightweight เท่ากับ XP เดิม

ตัวชี้ที่สำคัญของการพัฒนาคือการเพิ่มขึ้นของจำนวน Sommerville-Sawyer point ถ้าองค์กรใช้ XP เดิมจะได้ 31 point ของ basic practices และจะเป็นประเภท Initial หลังจากพัฒนาโดยการปรับปรุงได้ถึง 78 point ใน basic practices และอยู่ในประเภท Repeatable ซึ่งเป็นตัวชี้ที่ดีในการพิจารณา