Extreme programming (XP) มีความสำคัญกับการทำงานเป็นทีมอย่างไร? ลิ้งนี้มีคำตอบ



Extreme Programming(XP) คือกฏระเบียบการทำงานพัฒนาซอฟแวร์ ที่จะเน้นความสนใจไปที่ คนในทีมทั้งหมด(Manager, Customer, XP Programmer และ XP Coach) เพื่อมุ่งไปสู่เป้าหมายร่วมกัน โดยผ่านหลักการคุณค่าของ XP

แนวคิดหลักของ XP

  • —เน้นที่ทำงานร่วมกัน  (Collabaration)
  • —การสื่อสาร (Communication)
  • —การปฏิบัติตามระเบียบ (Discipline)

ปรัชญาในการทำงานของ XP ประกอบไปด้วย 4 ข้อใหญ่ คือ

  1. Communication      ผู้พัฒนาซอฟต์แวร์ที่ใช้ XP จะต้องสื่อสารกับลูกค้าและผู้พัฒนาซอฟแวร์ด้วยกัน
  2. Simple     ผู้พัฒนาซอฟต์แวร์ที่ใช้ XP จะต้องออกแบบโปรแกรมให้ง่าย
  3. Feedback     ผู้พัฒนาซอฟต์แวร์ที่ใช้ XPจะต้องค้นหาการตอบสนองกลับจากลูกค้า (Feedback) โดยทำการทดสอบโปรแกรมตั้งแต่แรกเริ่มพัฒนาซอฟต์แวร์
  4. Courage     ผู้พัฒนาซอฟต์แวร์ที่ใช้ XP จะนำเสนอซอฟต์แวร์ให้กับผู้ใช้ตั้งแต่เนิ่นๆ เท่าที่เป็นไปได้ เพื่อจะได้แก้ไขซอฟต์แวร์ตามความต้องการของลูกค้า ทำให้ผู้พัฒนาซอฟต์แวร์สามารถมีกำลังใจในการตอบสนองต่อการเปลี่ยนแปลงของความต้องการและเทคโนโลยี

 เมื่อใดควรใช้ XP

  1. เมื่อความต้องการไม่คงที่ เปลี่ยนแปลงไปตามเวลา
  2. ผู้ใช้ไม่สามารถระบุความต้องการที่ชัดเจน
  3. โครงการที่มีความเสี่ยงสูง เช่น  โครงการถูกระบุวันเวลาที่จะต้องเสร็จ หรือ เป็นโครงการใหม่สำหรับทั้งอุตสาหกรรมซอฟต์แวร์ นั่นคือ เป็นเทคโนโลยีใหม่



ขั้นตอนและรายละเอียดการนำ XP มาใช้

1.ภาพรวมโครงการ

Picture1

รูปที่ 1 ภาพรวมโครงการที่ใช้เทคนิคของ XP

2.ขั้นตอน Iteration

Picture2

รูปที่ 2 ขั้นตอนการทำ Iteration

3.ขั้นตอน Development

Picture3

รูปที่ 3 ขั้นตอนการทำ Development

4.ขั้นตอน Collective Code Ownership

Picture4

 

Extreme Programming หัวใจหลักของ XP มีอยู่ 4 องค์ประกอบได้แก่

Planning

  • —เขียน User Stories
  • —ทำ Release Planning เพื่อให้ได้ Schedule
  • —มี Small Release บ่อยๆ
  • —แบ่ง project ออกเป็น iterations
  • —ทำ Iteration Planning ตอนเริ่มทุก iteration
  • —Move people around
  • —stand-up meeting ทุกๆวัน
  • —Fix XP กล้าเปลี่ยน process หากมีปัญหาหรือไม่เข้ากับงาน

Designing

  • —Simplicity พยายามออกแบบระบบที่ง่ายที่สุดที่ทำงานได้
  • —ใช้ชื่อที่สื่อและง่ายต่อการเข้าใจ System Metaphor
  • —ใช้ CRC cards สำหรับการ design
  • —สร้าง spike solution เพื่อลด risk – ทดลองทำ POC เพื่อดูว่าทำได้จริง
  • —ไม่ใส่ function ที่ยังไม่ต้องการ (added early) – มีเพียง 10% ของสิ่งที่ทำเพิ่มเท่านั้นที่จะถูกใช้จริง ดังนั้นอย่าเสียเวลาไปกับ 90% ที่ไม่ได้ใช้ ให้ concentrate ที่ feature function ปัจจุบันเท่านั้น
  • —Refactor ทุกๆครั้งเมื่อมีโอกาส

Coding

  • —ต้องมี user อยู่ตลอดเพื่อถามปัญหาได้ทันที always available
  • —มี standard ที่ตกลงกันในการเขียน code
  • —เขียน unit test ก่อน
  • —ใช้ pair programmed ในการเขียน code
  • —ให้ integrate code ทีละคู่ อย่ารวมทีเดียวหมด และให้ทำบ่อยๆ ให้มากกว่าสัปดาห์ละครั้ง
  • —Integrate บ่อยๆ – ให้ release code ขึ้น repository ให้บ่อยที่สุด ทุกๆ 2-3 ชม.
  • —ใช้ Collective Code Ownership ทุกคนใช้ code ร่วมกัน สามารถแก้ code คนอื่นเพื่อแก้ bug และ refactor ได้
  • —ปล่อย optimization ไว้สุดท้าย – Make it work, Make it right, then make it fast
  • —ไม่ทำ overtime – ให้ใช้ release planning meeting แก้ project scope หรือ timing แทน การเพิ่มคนก็ไม่ช่วยให้ดีขึ้นหากเมื่อ project เริ่ม late แล้ว



Testing

  • —ทุกๆ code ต้องมี unit test
  • —ทุกๆ code ต้องผ่าน unit test ก่อนจะ release
  • —เมื่อเจอ bug ให้สร้าง test case สำหรับ case นี้ทันที
  • —ทำ Acceptance Test บ่อยๆ และมีการ publish ผลที่ได้

XP สามารถแบ่งออกได้เป็น 12 แนวทางปฏิบัติ และ แบ่งออกเป็น 4  กลุ่มใหญ่ ดังนี้

กลุ่มที่ 1

  1. Pair programming  Pair programming คือ code ทั้งหมดถูกสร้างจากprogrammer 2 คนโดยทำงานบนเครื่องคอมพิวเตอร์เครื่องเดียวกัน คนที่หนึ่งจะเป็นคนที่เข้าใจรายละเอียดการ coding ส่วนอีกคนนั้น จะเป็นคนค่อยติดตามดูการทำงานของคนแรก และจะสลับกันทำหน้าที่กัน เป็นประจำ
  2. Planning game   วิธีการวางแผนใน XP เรียกว่า planning game โดยแบ่งออกเป็น 2 ส่วน         ส่วนที่หนึ่ง Release Planning จะสนใจว่าสิ่งที่เป็นความต้องการถูกนำมาใส่ไว้ก่อนที่จะนำส่ง ในส่วนนี้ทั้ง programmer และผู้ใช้จะมีส่วนร่วมกันส่วนที่สอง Iteration Planning ในส่วนนี้เป็นส่วนของ Developer ไม่เกี่ยวข้องกับ ลูกค้า
  3. Test driven development    เป็นขั้นตอนการทดสอบงานที่ทำเสร็จในแต่ละส่วน
  4. Whole team    การมีส่วนร่วมในทีมทั้งผู้ใช้และผู้ออกแบบ

กลุ่มที่ Continuous processes

5. Continuous integration  การพัฒนาอย่างต่อเนื่อง แต่ให้ระวังการเพิ่มเติม เพราะอาจจะเป็นการเพิ่มปัญหาเข้าไปด้วย

6. Design improvement    การออกแบบที่เรียบง่ายเพื่อการพัฒนาหรือปรับแต่งระบบในอนาคต

7.  Small release  สร้างความสัมพันธ์ต่างๆ ระหว่างส่วนต่างๆของโปรแกรมในน้อยที่สุดเพื่อง่ายต่อการพัฒนา

กลุ่มที่Share understanding

8. Coding standard  การเขียนโค้ด ต่างๆในรูปแบบที่เป็นมาตรฐาน

9. Corrective code ownership  การที่อนุญาต ให้ผู้อื่นสามารถแก้ไขในส่วนของตนเองได้



10. Simple design  การใช้วิธีการต่างๆหรือแม้  ฟังชันการทำงานที่เรียบง่ายเพื่อง่ายต่อการเข้าใจ

11. System metaphor  การใส่ชื่อให้คล้าย กับหน้าที่การทำงานของส่วนนั้นๆ

กลุ่มที่ Programmer welfare

12. Sustainable pace  การให้งานไม่ควรเกิน 40 ชมต่อสัปดาห์



ข้อดีและข้อเสียของ XP

ข้อดี (Advantages)

  1. ประหยัดเวลาในการพัฒนา ไม่ต้องเสียเวลาในการเปลี่ยนแปลงหรือปรับแก้โปรแกรมใหม่ตั้งแต่ต้น
  2. ต้นทุนในการพัฒนาต่ำเนื่องจากเป็นวิธีที่ไม่ต้องเสียเวลารื้อแก้ใหม่ทั้งหมด
  3. การทำ on-site customer หรือก็คือการที่ทีมพัฒนาจะปรับปรุงเปลี่ยนแปลงโปรแกรมไปตามความต้องการของ user ตลอดเวลา ซึ่งก็จะเป็นวิธีที่มีความยืดหยุ่นมาก
  4. เน้นในเรื่องการมีส่วนร่วมของ user  โดยจะมีการออกแบบโปรแกรมตาม user story
  5. user และProgrammer มีความสัมพันธ์ที่ดีต่อกัน
  6. เน้นในเรื่องของ Teamwork และการสื่อสาร
  7. ออกแบบง่าย  เน้นความคล่องตัวและเรียบง่ายของกระบวนการพัฒนา
  8. สามารถ redesign ได้บ่อยครั้ง และมีวิธีที่ทำให้ Code อ่านง่าย ให้สามารถเป็น Document ในตัว

ข้อเสีย (Disadvantages)

  1. การพัฒนาวิธีนี้มุ่งเน้นที่การเขียนโค้ดเป็นหลักไม่เน้นที่การออกแบบ ซึ่งวิธีนี้ไม่มีผลกับโปรแกรมขนาดเล็ก แต่สำหรับโปรแกรมขนาดใหญ่หรือการทำงานของโปรแกรมเกี่ยวข้องกับคนจำนวนมาก การออกแบบไม่สมบูรณ์เพียงนิดเดียวก็ถือเป็นหายนะ
  2. การเขียนโค้ดในแบบที่อ่านได้ง่าย ซึ่งถือเป็นการทำเอกสารของวิธีนี้นั้น การเขียนโค้ดให้อ่านเข้าใจง่ายเพื่อทำให้เป็นเอกสารสำหรับระบบขนาดใหญ่นั้นไม่สามารถเป็นไปได้ในทางปฏิบัติเนื่องจากว่าโค้ดมีจำนวนมากกว่าหลาย 1000 หน้า การไม่จัดทำเอกสาร  จึงเป็นข้อจำกัดที่ทำให้ใช้ได้กับโปรแกรมเล็กๆเท่านั้น
  3. กระบวนการพัฒนาที่ขึ้นอยู่กับการ test  เป็นส่วนใหญ่แบบนี้ไม่สามารถผลิตโปรแกรมที่มีคุณภาพได้ การออกแบบที่ไม่มีขั้นตอนและไม่มีโครงสร้างในการตรวจทานทำให้เสียค่าใช้จ่ายและเวลาในการ test โดยไม่จำเป็น
  4. XP ขาดการวางแผนที่มีประสิทธิภาพหรือการจัดการคุณภาพของโปรแกรม
  5. ขาดการสนับสนุนที่ดี เนื่องจาก XP เป็นวิธีการจัดการแบบใหม่ ซึ่งยังไม่มีการฝึกอบรมและแนะนำที่ดี  จึงจำเป็นต้องให้การสนับสนุนระยะยาว อีกทั้งยังต้องมีเทคโนโลยีและทรัพยากรที่พอเพียงสำหรับการเปลี่ยนแปลง
  6. การเปลี่ยนแปลงความต้องการบ่อยๆอาจทำให้เกิดความขัดแย้งในเรื่องของการให้เงินทุนได้ เนื่องจากเมื่อความต้องการเปลี่ยนแล้ว โปรแกรมก็จะต้องถูกพัฒนาขึ้นใหม่ตามความต้องการนั้น ทำให้เงินทุนสำหรับ Project เดิมที่ได้ตั้งไว้ผิดพลาด  ทำให้เกินขอบเขตของ project ที่คิดและตกลงกันไว้ตั้งแต่แรก จึงต้องมาทบทวน แก้ไขกันใหม่อีกรอบหนึ่ง
  7. วิธีนี้ผู้พัฒนา software จะต้องทำงานเป็นคู่ ซึ่งอาจจะทำให้เกิด     ความขัดแย้ง  เนื่องจากมีการจับคู่โดยไม่เหมาะสม หรือโปรแกรมเมอร์บางคนก็อาจมีความต้องการความเป็นส่วนตัว อยากทำงานคนเดียวมากกว่า

 



ตัวอย่าง  ระบบที่ใช้  Extreme Programming (XP)

ระบบของ Google ใช้ XP เป็น process การทำงาน

  1. มีแค่ 1 code base ทุก ๆ คนมีสิทธิที่จะเข้ามาแก้ไข code เพียงแค่ register เข้าระบบ ใครสร้าง library อะไรก็เอาขึ้นไป อยากได้ library อะไรก็ search หาดูใน code base บนนั้นจะมีทั้ง source code และ document พร้อม
  2. เปลี่ยนทีมได้ง่าย ตามความสนใจของตน หากเบื่องานนี้ก็สามารถไป lookup หา project ที่สนใจ แล้วขอร่วม join ได้ แต่ต้องผ่านการสัมภาษณ์และ HR ก่อน ใช้วิธีการประกาศหางานใน Internal ก่อน
  3. ทีมจะแชร์ totally share ข้อมูลของ project ของตนที่ดูอยู่ภายในบริษัท ทั้ง tech talks, design docs, lunch table conversation เพื่อแชร์ความรู้และข้อมูลให้แก่กัน หากมี project 2 projects ใกล้เคียงกันเกิดขึ้นจะไม่มีการ push ให้รวมทีม แต่จะให้แข่งกัน เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด There isn’t only one solution for each problem
  4. 20% ของเวลางานจะใช้เพื่อวิจัย project ส่วนตัว
  5. ไม่มีการปิดกั้น idea หากมี idea ใหม่ๆ ทุก ๆ คนจะตื่นเต้นกับมันและช่วยกัน brainstorm ไม่มีการหวงว่าเป็น area ของใคร แต่ยินดีรับ idea ใหม่ ๆ จากคนอื่น ๆ เสมอ

 

 

Reference

 



  •  
  •  
  •  
  •  
  •  
  •  
phongrid.yoos on sabfacebook
phongrid.yoos
at GlurGeek.Com
สวัสดีครับ!! เติ้ล วิศวกรรมศาตร์ ปี4 ม.กรุงเทพ
ฝากเนื้อฝากตัวด้วยครับ จุ้บๆ

Leave a Reply