Extreme Programming (XP) คืออะไร

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 ซึ่งเป็นตัวชี้ที่ดีในการพิจารณา