ความสำคัญของปัญหา

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

 

การนำเสนอที่เน้นไปในทางการเพิ่มการพัฒนาทางด้านเทคนิค 17 ผู้เชี่ยวชาญทางด้าน software แนะนำให้ใช้ agile development ในปี 2001 ทฤษฎีที่ยึดหยุ่นรวดเร็วการรวมศูนย์กลางความร่วมมือการพัฒนา software กลายข้อสรุปสั้นๆที่เรียกว่า agile manifesto

 

software engineering ken back แนะนำ Xp-programmingในปี 1990 จุดมุ่งหมายเพื่อเพิ่มคุณภาพของการพัฒนา software ได้อย่างรวดเร็ว รองรับการเปลี่ยนแปลงของลูกค้าในปี 1999 ได้มีการกำหนด xp ในหนังสือ extreme programming explained embrace change

 

คุณค่าและทฤษฤีของ Extreme Programming มีกฎพื้นฐานที่ง่ายห้าอย่างดังนี้

 

การติดต่อสื่อสาร(communication) ทุกคนของทีมทำงานร่วมกันต้องมีการติดต่อสื่อสารกันทุกขั้นตอนของโปรเจค

ความเรียบง่าย (simplicity) นักพัฒนามุ่งมั่นที่จะเขียน code ง่ายๆแต่สามารถให้คุณค่าแก่ผลิตภัณฑ์ และประสิทธิภาพของเวลาที่ใช้น้อยลง

ข้อเสนอแนะ (feedback) นักพัฒนาต้องปล่อย software บ่อยๆ เพื่อดูการตอบรับและเพื่อปรับปรุงผลิตภัณฑ์ตามความต้องการใหม่

ความเคารพ (respect) ทุกคนกำหนดให้เป็นผู้แนะนำเกี่่ยวกับโปรเจค เพื่อจุดมุ่งหมายความสำเร็จเดียวกัน

ความกล้าหาญ (courage) Programmer มีจุดประสงค์เพื่อประเมินผลในตัวเองโดยปราศจากข้อแก้ตัวและพร้อมจะเปลี่ยนแปลง

 

ค่านิยมดังกล่าวนี้จะช่วยให้ทีมมีแรงจูงใจไปถึงเป้าหมายได้และสะท้อนให้เห็นอย่างเป็นรูปธรรมมากขึ้น

 

นักพัฒนาวิจัยเห็นคุณค่าของ 5 ค่าของ XP ดังนี้

rapid feedback (การตอบสนองรวดเร็ว )สมาชิกของทีมต้องเข้าใจว่าให้ทำอะไร และต้องตอบสนองให้ถูกต้อง

Assumed simplicity (กำหนดให้ง่าย) นักพัฒนาต้องมุ่งเน้นงานที่สำคัญในขณะนั้น ตามรูปแบบ YAGNI (You aren’t Gonna Need It) จะไม่เพิ่ม function ใน source code เมื่อมันไม่มีความจำเป็นต้องทำ don't repeat yourself (DRY) จะไม่ประมวลข้อมูลที่เหมือนกันและการทำกระทำแบบเดียวกันช้ำๆหลายครั้ง ควรใช้ข้อมูลชุดเดียวหรือ functionชุดเดียวในการประมวลผลของโปรแกรมในจุดมุ่งหมายเดียวกัน

Incremental changes (การเพิ่มการเปลี่ยนแปลง) ค่อยเปลี่ยนแปลงที่ละเล็กๆน้อยๆ เพือให้ผลิตภัณฑ์ดีขึ้น ดีกว่าทำทีเดียวให้ดีทั้งหมด

Embracing change (เกาะติดการเปลี่ยนแปลง) ถ้าลูกค้าต้องการจะเปลี่ยนรูปแบบผลิตภัณฑ์ programmer ควรให้การสนับสนุนการติดสินใจนี้ว่าควรวางแผนและนำไปใช้อย่างไร

Quality work (คุณภาพของงาน) ทีมควรทำงานร่วมกันได้ดี สร้างคุณค่าผลิตภัณฑ์และมีความรู้สึกภาคภูมิใจในผลงาน

 

Extreme Programming ในทางปฎิบัติ

XP นำเสนอแนวทางปฎิบัติ 12 แบบ นักพัฒนาปฎิบัติตามทฎษฎีและค่่านิยม มีแนวทางปฎิบัติจริงจะแบ่งออกได้เป็นสี่กลุ่ม

 

feedback (การตอบกลับ)

Test driven development :เป็นได้ไหมว่าที่จะเขียน code ให้ดูรวดเร็วเข้าใจง่าย ตอบได้เลยว่าได้ ตามหลักของ XP software ต้องมีคุณภาพและควรพัฒนาเป็นช่วงสั้นๆ และปล่อย software บ่อยๆ เพื่อดูการตอบรับ การมีการตอบรับเข้ามาเป็นสิ่งดีที่สำหรับการทดสอบ ทีม XP ควรฝึกการเขียน TDD (test driven development) เป็นการเขียน unit-test แบบอัตโนมัติก่อนเขียน code จริง เพื่อแน่ใจว่าทุกส่วนของ code ผ่านการทดสอบก่อน ปล่อย software ออกมา ดังนั้น นักพัฒนาควรรออกแบบ function ที่ต้องการให้สามารถทดสอบได้ TDD จึงเป็นหนทางที่สามารถทดสอบการตอบกลับของ function software ได้ทันทีและสร้างผลิตภัณท์softwareที่เชื่อถือได้

 

The Planing game (เกมวางแผน): นี่เป็นการประชุมเกี่ยวการเริ่มการพัฒนาของทีม และลูกค้าเข้ามาช่วยอภิปรายและปรับปรุงคุณสมบัติของผลิตภัณฑ์ ในตอนท้ายของเกมวางแผนทีมต้องกำหนดงานแผนการพัฒนาในคุณสมบัติต่างและช่วงเวลาการปล่อย software กำหนดงานที่จะทำในแต่ละอย่าง

 

onsite-customer(อยู่กับลูกค้า) ตามหลัก XP ลูกค้าควรมีปฏิสัมพันธ์เต็มรูปแบบตลอดการพัฒนา และให้คำตอบของสถานะปัจจุบันตลอดเวลา ระบุความสำคัญ แก้ไขข้อขัดแย้งตามความจำเป็น

 

pair programming (จับคู่่เขียนโปรแกรม)ในทางปฎิบัติ เป็นการทำงานร่วมเขียน code เดียวกัน คนแรกเน้นการขียน code คนที่สองเน้นให้แนะนำ และปรับปรุงและแก้ไข ข้อผิดพลาดระหว่างทาง ผลของทีมคือได้งานที่มีคุณภาพ มีการแชร์ความรู้ที่รวดเร็ว ใช้เวลา 15 ถึง 60 % หรือมากกว่า ตามการพิจารณาระยะยาว วิธีการนี้น่าจะเหมาะโปรเจคที่มีเวลาพัฒนายาวนาน

 

continual process (การดำเนินการที่ต่อเนื่อง)

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

 

continuous Integration (การดำเนินการต่อเนื่องและรวมกันทั้งหมด) นักพัฒนาต้องรักษาระบบรวมแบบเต็ม XP ทีมอาจจะมีการวนการพัฒนาไปในหลายระดับการ commit code หลายครั้งต่อวัน จะต้องปล่อย software ได้อย่างต่อเนื่อง ผู้ปฎิบัติXP ต้องเข้าใจความสำคัญของการสื่อสาร โปรแกรมเมอร์อภิปรายส่วน code ที่สามารถนำกลับมาใช้ใหม่และแชร์ แนวทางนี้ต้องรู้ว่า function อะไรเป็นฟังก์ชันที่ต้องการจริงๆในการพัฒนา นโยบายการแชร์ code จะช่วยลดปัญหาที่เกิดซ้ำ อีกทางเพิ่มการทดสอบอัตโนมัติใน code จะช่วยให้นักพัฒนาสามารถค้นหาและแก้ไขข้อผิดพลาดได้ทัน ก่อนที่จะนำไปใช้งาน

 

small releases (ปล่อยทีละน้อยๆ) ในทางปฎิบัติแนะนำว่าควรปล่อย version แรกให้เร็วที่สุด และเพิ่มเติมการพัฒนาของผลิตภัณฑ์ทีละน้อยๆ และปล่อย software ออกมาบ่อย จะได้มีการตอบรับจากในกลุ่มนักพัฒนาบ่อยๆ สามารถตรวจสอบบัคได้ในตอนแรกๆ และสามารถดูการทำงานได้ของผลิตภัณฑ์ หนึ่งในวิธีการทำคือ วิธีการก่อนหน้านี้ที่กล่าวมา CI (continuous integration practice)

 

 

code understanding (ความเข้าใจ code)

Simple Design (ออกแบบง่ายๆ) การออกแบบที่ดีที่สุดของ software คือง่ายที่สุดและทำงานได้ ถ้ามีความซับซ้อน มันควรจะลบออกไป การออกแบบที่ถูกต้องควรผ่านการทดสอบทั้งหมด ไม่มีการทำ code ซ้ำ มีส่วน class และ method น้อย และแสดงเจตนาการทำงานของโปรแกรมชัดเจน

 

ผู้ร่วมงาน xp เน้นการออกแบบง่ายๆ หลังจากที่ได้ผลิตผลิตภัณฑ์มาระยะหนึ่งแล้ว Don well แนะนำการเขียน code ตามคุณสมบัติที่ได้วางแผนไว้มากกว่าสร้างคุณสมบัติต่างๆไว้รอในอนาคต วิธีการที่ดีที่สุดคือสร้าง code เฉพาะที่คุณใช้เท่านั้น ขณะนั้นคุณต้องค้นหาความรู้เพียงพอที่จะออกแบบให้ง่ายที่สุด จากนั้นค่อย refactor เรื่อยๆ จนนำไปใช้ทำเป็นความเข้าใจใหม่และออกแบบ

 

Coding standards ทีมต้องมีจิตสำนักทั่วไปในการตั้งค่า code ที่นำไปใช้ ใช้รูปแบบเดียวกับของการเขียน application เป็นมาตราฐานให้ทีมสามารถอ่าน แชร์และ refactor code ได้อย่างง่ายดาย เพื่อให้คนที่ติดตาม code ปัจจุบัน สามารถเรียนรู้ได้รวดเร็วที่สุด สำหรับ โปรแกรมมือคนใหม่ code ที่เขียนของมีกฎการเขียนถือครองเหมือนกัน

 

Collective Code Ownership (การถือครอง code ร่วมกัน)

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

 

System metaphor(อุปลักษณ์ของระบบ)

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

 

Programmer’s work conditions

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

 

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

สิ่งที่สำคัญคือต้องแน่ใจเกี่ยวกับขนาดของบริษัท เจ้าที่เชี่ยวชาญที่จะนำ XP ไปใช้ควรคำนึงถึงปัจจัยสำคัญต่างๆดังต่อไปนี้

มีการเปลี่ยนการพัฒนาค่อยข้างสูง Xp จะให้ทีมสามารถจัดการเปลี่ยนที่รวดเร็วของความต้องการลูกค้าได้

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

ทีมเล็กๆ เพื่อความมีประสิทธิภาพทีมไม่ควรเกิน 12 คน

มีการทดสอบแบบอัตโนมัติ ปัจจัยอื่นที่ทำให้ นักพัฒนาสามารถสร้างและรัน unitest ได้

ลูกค้าสามารถมีปฎิสัมพันธ์ได้ ต้องแน่ใจว่าลูกค้ามีเวลาเขามาจัดการและสังเกตการณ์ จนจบโปรเจคได้