เอ็กซ์ตรีมโปรแกรมมิง

Overview

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

แผนการปฏิบัติและการตอบกลับ (feedback) ในหลายระดับตามรูปแบบของ Extreme Programming (XP)

เอ็กซ์ตรีมโปรแกรมมิง หรือ การเขียนโปรแกรมแบบเอ็กซ์ตรีม (อังกฤษ: Extreme programming; ย่อว่า XP) เป็นระเบียบวิธีการพัฒนาซอฟต์แวร์ที่เป็นหนึ่งในระเบียบวิธีที่เป็นที่รู้จักมากที่สุดในกลุ่มวิธีการพัฒนาซอฟต์แวร์แบบเอจายล์[1][2] XP เป็นระเบียบวิธีที่มีจุดเด่นในแนวทางปฏิบัติที่นำไปสู่ความสำเร็จทางด้านคุณภาพของซอฟต์แวร์ในโครงการพัฒนาซอฟต์แวร์ขนาดเล็ก[3][4][5] โดยความสำเร็จนี้มาจากรูปแบบของ XP เองซึ่งมุ่งเน้นการมีส่วนร่วมอย่างเข้มข้นของลูกค้าที่ประจำอยู่ในโครงการ (On-site customers) มากกว่าการวิเคราะห์ความต้องการเพื่อทำเอกสารกำหนดความต้องการไว้ล่วงหน้า[4][2] อีกทั้งการพุ่งเป้าไปที่การทดสอบโปรแกรม และการลดขั้นตอนการออกแบบให้น้อยลง[4]

XP เป็นระเบียบวิธีการชนิดเบา (lightweight methodology) ในการพัฒนาซอฟต์แวร์ของกลุ่มระเบียบวิธีเอจายล์[5] เน้นความกระชับและคล่องแคล่ว มุ่งเน้นการปฏิบัติการไปที่การเขียนโปรแกรม การสื่อสาร การตอบกลับ ความเรียบง่าย และการแก้ปัญหา นอกจากนี้ XP ยังสนับสนุนการปฏิบัติการที่ดีที่สุดทางวิศวกรรม และยังรองรับการเปลี่ยนแปลงความต้องการของลูกค้าอย่างรวดเร็วและกระชั้นชิดจากการโต้ตอบกับลูกค้าที่ประจำในโครงการได้อย่างรวดเร็ว[5] เมื่อเทียบกับระเบียบวิธีการแบบสกรัม ซึ่งเป็นที่นิยมที่สุดของกลุ่มระเบียบวิธีการแบบเอจายล์แล้วนั้น[6] XP จะมุ่งเป้าไปที่การปฏิบัติการ ในขณะที่สกรัมจะเน้นที่การบริหารโครงการมากกว่า[6]

ประวัติ

เคนต์ เบ็ก วิศวกรซอฟต์แวร์และผู้สร้างเอ็กตรีมโปรแกรมมิง

เคนต์ เบ็ก (Kent Beck) พัฒนาแนวคิดการเขียนโปรแกรมแบบเอ็กซ์ตรีม (Extreme Programming: XP) ระหว่างการทำงานในโครงการ Chrysler Comprehensive Compensation System (C3) ซึ่งเป็นโครงการพัฒนาระบบเงินเดือนของบริษัทไครสเลอร์[7] เบ็กได้รับแต่งตั้งให้เป็นผู้จัดการโครงการในเดือนมีนาคม ค.ศ. 1996 และเริ่มปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ที่ใช้ในโครงการ ก่อนจะเรียบเรียงแนวคิดดังกล่าวเป็นหนังสือ Extreme Programming Explained ซึ่งตีพิมพ์ในเดือนตุลาคม ค.ศ. 1999[7]

โครงการ C3 ถูกยุติลงในเดือนกุมภาพันธ์ ค.ศ. 2000 หลังจากดำเนินงานมาเป็นเวลาราวเจ็ดปี ภายหลังบริษัทไดม์เลอร์-เบนซ์เข้าซื้อกิจการของไครสเลอร์[8] นอกจากเบ็กแล้ว วอร์ด คันนิงแฮม (Ward Cunningham) ยังเป็นบุคคลสำคัญอีกคนหนึ่งที่มีอิทธิพลต่อการพัฒนา XP

แนวปฏิบัติหลายประการของ XP ไม่ใช่แนวคิดใหม่ หากแต่เป็นการนำวิธีการปฏิบัติที่เป็นเลิศ [en] (best practices) ที่มีอยู่แล้วมาประยุกต์ใช้อย่างเข้มข้น ตัวอย่างเช่น แนวคิดการพัฒนาโดยเขียนการทดสอบก่อน (test-first development) ซึ่งกำหนดให้วางแผนและเขียนกรณีทดสอบก่อนเริ่มเขียนโค้ดในแต่ละส่วนย่อย ได้ถูกนำมาใช้ตั้งแต่โครงการเมอร์คิวรีขององค์การนาซาในช่วงต้นคริสต์ทศวรรษ 1960[9]

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

จุดกำเนิด

มีปัจจัยสำคัญสองประการที่ส่งอิทธิพลต่อการพัฒนาซอฟต์แวร์ในคริสต์ทศวรรษ 1990 ได้แก่

  • ภายในวงการซอฟต์แวร์ กระบวนทัศน์การเขียนโปรแกรมเชิงวัตถุ (object-oriented programming) เริ่มเข้ามาแทนที่กระบวนทัศน์การเขียนโปรแกรมเชิงกระบวนการ [en] (procedural programming) ในฐานะแนวทางการเขียนโปรแกรมที่ได้รับความนิยมในหมู่นักพัฒนา
  • ภายนอกวงการ การเติบโตของอินเทอร์เน็ตและยุคภาวะเศรษฐกิจฟองสบู่ดอตคอม ทำให้ความรวดเร็วในการนำผลิตภัณฑ์ออกสู่ตลาด (time-to-market) และการเติบโตของธุรกิจกลายเป็นปัจจัยสำคัญในการแข่งขันในวงการธุรกิจ

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

โครงการ Chrysler Comprehensive Compensation System (C3) จึงถูกริเริ่มขึ้นเพื่อศึกษาวิธีการนำเทคโนโลยีเชิงวัตถุมาใช้กับระบบเงินเดือนของไครสเลอร์ โดยใช้ภาษาสมอลล์ทอล์ก (Smalltalk) และระบบฐานข้อมูลเจมสโตน [en] เป็นชั้นสำหรับเข้าถึงข้อมูล (data access layer) บริษัทไครสเลอร์ได้เชิญเคนต์ เบ็ก ผู้เชี่ยวชาญด้าน Smalltalk เข้ามาช่วยปรับปรุงประสิทธิภาพของระบบ[7] แต่เมื่อเขาพบปัญหาในกระบวนการพัฒนาซอฟต์แวร์หลายประการ บทบาทของเขาจึงขยายจากการปรับแต่งประสิทธิภาพไปสู่การเสนอและนำแนวปฏิบัติใหม่ ๆ มาใช้ โดยอาศัยประสบการณ์จากการทำงานร่วมกับวอร์ด คันนิงแฮมมาเป็นเวลานาน

เบ็กกล่าวถึงจุดเริ่มต้นของ XP ไว้ว่า

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

— เคนต์ เบ็ก

ต่อมา เบ็กได้เชิญรอน เจฟฟรีส์ (Ron Jeffries) เข้าร่วมโครงการเพื่อช่วยพัฒนาและปรับปรุงแนวปฏิบัติเหล่านี้ โดยเจฟฟรีส์ทำหน้าที่เป็นโค้ช ช่วยให้ทีม C3 นำแนวปฏิบัติของ XP ไปใช้จนกลายเป็นกิจวัตรในการทำงาน

หลักการและแนวปฏิบัติของ XP เริ่มเผยแพร่สู่สาธารณชนผ่านการอภิปรายบนวิกิต้นฉบับของคันนิงแฮมคือ WikiWikiWeb ซึ่งมีผู้ร่วมอภิปรายจำนวนมากช่วยกันขยายแนวคิดและพัฒนาต่อยอด จนเกิดแนวปฏิบัติแบบแอไจล์อื่น ๆ ตามมา (ดู การพัฒนาซอฟต์แวร์แบบเอจายล์) นอกจากนี้ แนวคิดของ XP ยังได้รับการเผยแพร่ผ่านเว็บไซต์ ExtremeProgramming.org ตั้งแต่ราวปี ค.ศ. 1999

ในปี ค.ศ. 1999 เบ็กได้ตีพิมพ์หนังสือ Extreme Programming Explained (ISBN 0-201-61641-6) ซึ่งเป็นผลงานสำคัญที่ทำให้ XP เป็นที่รู้จักในวงกว้าง ต่อมาเขายังทำหน้าที่บรรณาธิการหนังสือชุดเกี่ยวกับ XP อีกหลายเล่ม ครอบคลุมทั้งหลักการ แนวปฏิบัติ และประสบการณ์การนำไปใช้ รวมถึงมีหนังสือบางเล่มที่นำเสนอข้อวิจารณ์และข้อจำกัดของแนวทาง XP ด้วย

6 ค่านิยมหลัก (6 core values)

การเขียนโปรแกรมแบบเอ็กซ์ตรีม (XP) ตั้งอยู่บนค่านิยมหลัก (core values) ซึ่งเป็นแนวคิดพื้นฐานที่ใช้กำหนดแนวทางการตัดสินใจและการทำงานร่วมกันของทีมพัฒนาซอฟต์แวร์ ค่านิยมเหล่านี้เป็นรากฐานของหลักการ (principles) และแนวปฏิบัติ (practices) ทั้งหมดของ XP[10] ประกอบด้วย:

  1. การสื่อสาร (Communication): การสื่อสารที่มีประสิทธิภาพช่วยลดความเข้าใจคลาดเคลื่อนระหว่างสมาชิกในทีม ลูกค้า และผู้มีส่วนเกี่ยวข้อง XP สนับสนุนการสื่อสารแบบเผชิญหน้า การทำงานร่วมกันอย่างใกล้ชิด และการแบ่งปันความรู้ภายในทีม เพื่อให้ทุกฝ่ายมีความเข้าใจตรงกันเกี่ยวกับความต้องการและทิศทางของโครงการ
  2. ความเรียบง่าย (Simplicity): XP สนับสนุนการออกแบบและพัฒนาซอฟต์แวร์ให้เรียบง่ายที่สุดเท่าที่จำเป็นสำหรับความต้องการในปัจจุบัน โดยหลีกเลี่ยงการเพิ่มฟังก์ชันหรือโครงสร้างที่ยังไม่มีความจำเป็น ซึ่งช่วยลดความซับซ้อนของระบบและทำให้สามารถปรับเปลี่ยนได้ง่ายในอนาคต (ดูเพิ่มเติมที่ คุณไม่ต้องการมันหรอก! [en])
  3. ข้อมูลป้อนกลับ (Feedback): ทีมพัฒนาควรได้รับข้อมูลป้อนกลับอย่างรวดเร็วและต่อเนื่องจากหลายแหล่ง เช่น การทดสอบอัตโนมัติ การตรวจสอบโค้ด การรวมโค้ดอย่างต่อเนื่อง และความคิดเห็นของลูกค้า เพื่อให้สามารถค้นพบข้อผิดพลาดและปรับปรุงซอฟต์แวร์ได้ตั้งแต่ระยะเริ่มต้น
  4. ความกล้าหาญ (Courage): XP ส่งเสริมให้ทีมมีความกล้าตัดสินใจทำสิ่งที่ถูกต้องทางวิศวกรรมซอฟต์แวร์ แม้ว่าจะต้องปรับเปลี่ยนโค้ด ลบส่วนที่ไม่จำเป็น ปรับโครงสร้างระบบ (refactoring) หรือยอมรับข้อผิดพลาดเมื่อพบว่าการตัดสินใจเดิมไม่เหมาะสม
  5. ความเคารพ (Respect): สมาชิกทุกคนในทีมควรให้เกียรติและเคารพซึ่งกันและกัน ยอมรับความคิดเห็น ความเชี่ยวชาญ และผลงานของผู้อื่น รวมทั้งรับผิดชอบต่อคุณภาพของซอฟต์แวร์ร่วมกัน ความเคารพซึ่งกันและกันเป็นปัจจัยสำคัญที่ช่วยให้การเขียนโปรแกรมแบบจับคู่ (pair programming) และการทำงานร่วมกันใน XP ประสบความสำเร็จ

12 หลักการ (12 principles)

การเขียนเอ็กตรีมโปรแกรมมิง (XP) ตั้งอยู่บนค่านิยมหลัก (values) และนำไปสู่หลักการ (principles) ซึ่งใช้เป็นแนวทางในการตัดสินใจและเลือกแนวปฏิบัติระหว่างการพัฒนาซอฟต์แวร์ หลักการทั้ง 12 ประการ ได้แก่[11]

  1. ความเป็นมนุษย์ (Humanity) — การพัฒนาซอฟต์แวร์ควรคำนึงถึงความต้องการ ข้อจำกัด และแรงจูงใจของผู้คน ทั้งนักพัฒนา ลูกค้า และผู้มีส่วนเกี่ยวข้อง เพื่อให้เกิดสภาพแวดล้อมการทำงานที่ยั่งยืน
  2. ความคุ้มค่าทางเศรษฐกิจ (Economics) — การตัดสินใจควรพิจารณาต้นทุน เวลา และผลตอบแทนทางธุรกิจ ไม่ใช่เพียงความสมบูรณ์ทางเทคนิค
  3. การปรับปรุงร่วมกัน (Mutual benefit) — แนวทางและการตัดสินใจควรก่อให้เกิดประโยชน์แก่ทุกฝ่าย ทั้งทีมพัฒนา ลูกค้า และองค์กร แทนที่จะเป็นผลดีต่อฝ่ายใดฝ่ายหนึ่งเพียงอย่างเดียว
  4. ความคล้ายคลึงกัน (Self-similarity) — วิธีแก้ปัญหาที่ประสบผลสำเร็จในระดับหนึ่งของระบบมักสามารถประยุกต์ใช้กับระดับอื่นได้ ทำให้เกิดรูปแบบการออกแบบและการพัฒนาที่สอดคล้องกัน
  5. การปรับปรุงอย่างต่อเนื่อง (Improvement) — ทีมควรมองหาวิธีปรับปรุงกระบวนการ เครื่องมือ และคุณภาพของซอฟต์แวร์อยู่เสมอ แม้จะเป็นการเปลี่ยนแปลงเพียงเล็กน้อยก็ตาม
  6. ความหลากหลาย (Diversity) — ทีมที่มีสมาชิกซึ่งมีความรู้ ประสบการณ์ และมุมมองที่แตกต่างกัน จะช่วยให้สามารถแก้ปัญหาและสร้างนวัตกรรมได้ดียิ่งขึ้น
  7. การสะท้อนและทบทวน (Reflection) — ทีมควรทบทวนผลการทำงานและประสบการณ์ที่ผ่านมาเป็นระยะ เพื่อนำบทเรียนที่ได้รับมาปรับปรุงการทำงานในรอบถัดไป
  8. การไหลของงาน (Flow) — มุ่งเน้นให้การส่งมอบคุณค่าเป็นไปอย่างต่อเนื่อง โดยลดการหยุดชะงัก งานค้าง และการรอคอยระหว่างขั้นตอนต่าง ๆ
  9. โอกาส (Opportunity) — ปัญหา ความผิดพลาด หรือการเปลี่ยนแปลงควรถูกมองว่าเป็นโอกาสในการเรียนรู้และพัฒนาระบบให้ดีขึ้น มากกว่าจะเป็นอุปสรรคเพียงอย่างเดียว
  10. ความซ้ำซ้อน (Redundancy) — ปัญหาสำคัญควรมีวิธีป้องกันหรือวิธีตรวจสอบหลายรูปแบบ เช่น การทดสอบอัตโนมัติ การทบทวนโค้ด และการเขียนโปรแกรมแบบจับคู่ เพื่อเพิ่มความน่าเชื่อถือของระบบ
  11. ความล้มเหลว (Failure) — การทดลองและความล้มเหลวในขอบเขตที่ควบคุมได้เป็นส่วนหนึ่งของการเรียนรู้ ช่วยให้ค้นพบแนวทางที่เหมาะสมได้รวดเร็วยิ่งขึ้น
  12. คุณภาพ (Quality) — XP ถือว่าคุณภาพไม่ใช่สิ่งที่สามารถลดทอนเพื่อแลกกับความเร็วได้ แต่เป็นปัจจัยที่ช่วยให้สามารถพัฒนาและเปลี่ยนแปลงซอฟต์แวร์ได้รวดเร็วในระยะยาว

8 ขั้นตอนหลัก (8 primary activities)

การเขียนโปรแกรมแบบเอ็กซ์ตรีมแบ่งการพัฒนาซอฟต์แวร์ออกเป็นกิจกรรมหลัก (primary activities) 8 ประการ ซึ่งดำเนินไปอย่างต่อเนื่องและสนับสนุนซึ่งกันและกันตลอดวงจรการพัฒนา[12] ดังนี้:

การรับฟัง (Listening)

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

การออกแบบ (Designing)

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

การเขียนโปรแกรม (Coding)

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

การทดสอบ (Testing)

การทดสอบดำเนินควบคู่กับการพัฒนา โดยเฉพาะการทดสอบอัตโนมัติ ซึ่งช่วยตรวจสอบความถูกต้องของระบบและค้นหาข้อผิดพลาดได้ตั้งแต่ระยะเริ่มต้น ทั้งการทดสอบระดับหน่วย (unit testing) และการทดสอบการยอมรับ (acceptance testing)

การปรับปรุง (Caring)

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

การส่งมอบ (Deploying)

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

การสำรวจ (Exploring)

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

การบริหารจัดการ (Managing)

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

ความสัมพันธ์ระหว่างค่านิยม หลักการ และแนวปฏิบัติ

ใน XP ค่านิยมหลักเป็นรากฐานของวิธีคิดในการพัฒนาซอฟต์แวร์ ค่านิยมเหล่านี้ถูกนำไปตีความเป็นหลักการ เพื่อใช้ประกอบการตัดสินใจในสถานการณ์ต่าง ๆ และหลักการจึงถูกนำไปปฏิบัติผ่านแนวทางการพัฒนาซอฟต์แวร์ เช่น การพัฒนาโดยขับเคลื่อนด้วยการทดสอบ (Test-driven Development; TDD) การเขียนโปรแกรมแบบจับคู่ (Pair Programming) และการบูรณาการอย่างต่อเนื่อง (Continuous Integration; CI)

อ้างอิง

  1. ↑ Salo, O. & Abrahamsson, P., 2007. An iterative improvement process for agile software development. Software Process: Improvement and Practice, 12(1), pp. 81-100.
  2. 1 2 Beck, K., 2000. Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley
  3. ↑ Qumer, A. & Henderson-Sellers, B., 2008. An evaluation of the degree of agility in six agile methods. Information and Software Technology, Volume 50, p. 280–295.
  4. 1 2 3 Zuser, . W., Heil, S. & Grechenig, T., 2005. Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study. New York, NY, USA, ACM.
  5. 1 2 3 Rasool, G., Aftab, S., Hussain, S. & Streitferdt, D., 2013. eXRUP: A Hybrid Software Development Model for Small to Medium Scale Projects. Journal of Software Engineering and Applications, Volume 6, pp. 446-457.
  6. 1 2 Moniruzzaman, A. B. M. & Akhter Hossain, S. D., 2013. "Comparative Study on Agile software development methodologies". Global Journal of Computer Science and Technology, 13(7).
  7. 1 2 3 [(http://www.computerworld.com/article/2585634/app-development/extreme-programming.html) Computerworld-appdev-92 "Extreme Programming", Computerworld (online), December 2001].
  8. ↑ Rosenberg, Doug; Stephens, Matt (2003). Extreme Programming Refactored: The Case Against XP (ภาษาอังกฤษ). Apress. ISBN 978-1-59059-096-6.
  9. ↑ Larman & Basili 2003.
  10. ↑ Beck, Kent; Andres, Cynthia (2004). Extreme Programming Explained: Embrace Change (พิมพ์ครั้งที่ 2nd). Addison-Wesley. ISBN 978-0321278654.
  11. ↑ Beck, Kent; Andres, Cynthia (2004). Extreme Programming Explained: Embrace Change (พิมพ์ครั้งที่ 2nd). Addison-Wesley. ISBN 978-0321278654.
  12. ↑ Beck, Kent; Andres, Cynthia (2004). Extreme Programming Explained: Embrace Change (พิมพ์ครั้งที่ 2nd). Addison-Wesley. ISBN 978-0321278654.

ดูเพิ่ม

Related

No related data.

Recommendations