ส่งผลงานดีๆ ของคุณในฐานความรู้ได้ง่ายๆ ใช้แบบฟอร์มด้านล่าง

นักศึกษา นักศึกษาระดับบัณฑิตศึกษา นักวิทยาศาสตร์รุ่นเยาว์ ที่ใช้ฐานความรู้ในการศึกษาและการทำงาน จะรู้สึกขอบคุณเป็นอย่างยิ่ง

โพสต์บน http://www.allbest.ru/

เนื้อหา

• การแนะนำ
• 1. XP คืออะไร?
• 3.1 เทคนิคพื้นฐานประสบการณ์
• 4. ข้อดีและข้อเสีย
• 5. ประวัติการใช้งาน
• บทสรุป

การแนะนำ

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

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

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

1. XP คืออะไร?

เอ็กซ์ตรีมมผ้าลินินโปรแกรมมการท่องเที่ยว(ภาษาอังกฤษ) สุดขีด การเขียนโปรแกรม, ประสบการณ์) เป็นหนึ่งในวิธีการพัฒนาซอฟต์แวร์ที่ยืดหยุ่น ผู้เขียนวิธีการนี้คือ Kent Beck, Ward Cunningham, Martin Fowler และคนอื่นๆ

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

ด้วยการใช้รอบการพัฒนาที่สั้นมาก XP จึงให้ข้อเสนอแนะที่รวดเร็ว จริง และต่อเนื่อง

XP ใช้การวางแผนส่วนเพิ่ม ซึ่งส่งผลให้แผนโครงการโดยรวมเกิดขึ้นอย่างรวดเร็ว แต่ก็เป็นที่เข้าใจกันว่าแผนนี้มีการพัฒนาไปตลอดอายุของโครงการ

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

XP ขึ้นอยู่กับการทดสอบอัตโนมัติที่พัฒนาโดยทั้งโปรแกรมเมอร์และลูกค้า ด้วยการทดสอบเหล่านี้ ทำให้สามารถตรวจสอบกระบวนการพัฒนา รับรองวิวัฒนาการของระบบที่ถูกต้อง และตรวจจับข้อบกพร่องที่มีอยู่ในระบบได้ทันที

XP ขึ้นอยู่กับการสื่อสารด้วยวาจา การทดสอบ และซอร์สโค้ด เครื่องมือทั้งสามนี้ใช้เพื่อแลกเปลี่ยนข้อมูลเกี่ยวกับโครงสร้างและพฤติกรรมของระบบ

XP ขึ้นอยู่กับกระบวนการออกแบบที่พัฒนาอย่างต่อเนื่องซึ่งจะดำเนินต่อไปตราบเท่าที่ยังมีระบบอยู่

XP ขึ้นอยู่กับปฏิสัมพันธ์อย่างใกล้ชิดระหว่างโปรแกรมเมอร์ที่มีทักษะและความสามารถทั่วไปมากที่สุด

XP ขึ้นอยู่กับเทคนิคที่ตอบสนองทั้งสัญชาตญาณระยะสั้นของโปรแกรมเมอร์แต่ละคนและผลประโยชน์ระยะยาวของโครงการทั้งหมด

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

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

2. การเขียนโปรแกรมแบบเอ็กซ์ตรีมเริ่มต้นที่ไหน?

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

Extreme Programming ไม่ได้ขึ้นอยู่กับเทคนิคเฉพาะอย่างที่เชื่อกันทั่วไป แต่ใช้หลักการพื้นฐานสี่ประการเท่านั้น: การสื่อสาร ความเรียบง่าย การตอบรับ และความกล้าหาญ นี่คือที่ที่คุณต้องเริ่มต้น

Extreme Programming นำเสนอโซลูชันสำเร็จรูป: ทำให้ทุกอย่างเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ รักษาลูกค้าไว้กับตัวเองหรืออยู่กับลูกค้า ปล่อยให้เขาติดตามกระบวนการพัฒนาอย่างแข็งขัน ยินดีกับการเปลี่ยนแปลง - และเกือบจะรับประกันความสำเร็จแล้ว

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

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

Extreme Programming ถามเราว่า: ทำไมไม่พัฒนาความกล้าหาญล่ะ? ท้ายที่สุดแล้วเธอมีความสำคัญมากในงานของเธอ หากไม่มีความกล้าหาญ เป็นไปได้ไหมที่จะรับผิดชอบในการทำงานให้เสร็จสิ้นและภายในกรอบเวลาที่กำหนด? หากปราศจากความกล้า เป็นไปได้ไหมที่จะตระหนักได้ว่าคุณมาถึงทางตันแล้ว ถอยกลับไปและมองหาวิธีแก้ปัญหา? และในที่สุด อะไรจะทำให้นักพัฒนายอมรับความผิดพลาดของเขาในการประเมินงานและเตือนผู้อื่นเกี่ยวกับงานได้ทันเวลา แทนที่จะนำเสนอพวกเขาแบบสำเร็จตามกำหนดเวลาเมื่อหมดกำหนดเวลาทั้งหมดแล้วเท่านั้น ประโยชน์ของความกล้าหาญนั้นชัดเจน และทุกความสำเร็จแม้จะเป็นงานที่เล็กที่สุดก็สามารถพัฒนาความกล้าหาญนี้ได้

3. เทคนิค XP

Extreme Programming (XP) กลายเป็นวิธีวิวัฒนาการของการพัฒนาซอฟต์แวร์จากล่างขึ้นบน แนวทางนี้เป็นตัวอย่างของสิ่งที่เรียกว่าวิธีการพัฒนาแบบ Agile กลุ่มของวิธีการ "สด" รวมถึงนอกเหนือจากการเขียนโปรแกรมขั้นสูงแล้ว วิธีการ SCRUM, DSDM (วิธีการพัฒนาระบบไดนามิก, วิธีการพัฒนาระบบไดนามิก), การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะ (การพัฒนาที่ขับเคลื่อนโดยฟังก์ชันระบบ) เป็นต้น

หลักการพื้นฐานของการพัฒนาซอฟต์แวร์แบบสดนั้นประดิษฐานอยู่ในแถลงการณ์การพัฒนาแบบสดซึ่งปรากฏในปี 2543

· ผู้คนที่เกี่ยวข้องในโครงการและการสื่อสารของพวกเขามีความสำคัญมากกว่ากระบวนการและเครื่องมือ

· โปรแกรมการทำงานมีความสำคัญมากกว่าเอกสารประกอบที่ครอบคลุม

· ความร่วมมือกับลูกค้ามีความสำคัญมากกว่าการหารือรายละเอียดของสัญญา

· การทำงานผ่านการเปลี่ยนแปลงมีความสำคัญมากกว่าการยึดติดกับแผน

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

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

อย่างไรก็ตาม XP มีแผนภาพกระบวนการพัฒนาของตัวเอง (แม้ว่าโดยทั่วไปแล้วความเข้าใจที่ใช้กันอย่างแพร่หลายเกี่ยวกับ "กระบวนการพัฒนา" ซึ่งเป็นรูปแบบการกระทำที่ค่อนข้างเข้มงวดนั้นขัดแย้งกับแนวคิดของการพัฒนาที่ "มีชีวิตชีวา") ดังแสดงในรูปที่ 1 .

ตามที่ผู้เขียน XP กล่าวว่าเทคนิคนี้ไม่ได้เป็นไปตามรูปแบบการกระทำทั่วไปบางอย่างมากนักเท่ากับการใช้เทคนิคต่อไปนี้รวมกัน อย่างไรก็ตาม แต่ละเทคนิคมีความสำคัญ และหากไม่มีการใช้งาน การพัฒนาจะไม่ถือเป็น XP ตามที่ Kent Beck หนึ่งในผู้เขียนแนวทางนี้ร่วมกับ Ward Cunningham และ Ron Jeffries กล่าว

· สดการวางแผน (การวางแผนเกม)

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

ข้าว.1 แผนภาพเวิร์กโฟลว์ XP

· บ่อยเปลี่ยนวีรุ่นต่างๆ (เล็กเผยแพร่)

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

· อุปมา (อุปมา) ระบบ

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

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

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

· เรียบง่ายออกแบบโซลูชั่น (เรียบง่ายออกแบบ)

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

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

· การพัฒนาบนพื้นฐานการทดสอบ (ทดสอบ- ขับเคลื่อนการพัฒนา)

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

XP ให้ความสำคัญกับการทดสอบสองประเภทเป็นพิเศษ:

ь การทดสอบหน่วย;

การทดสอบการยอมรับ b

ซอฟต์แวร์การเขียนโปรแกรมขั้นสูง

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

การทดสอบการยอมรับทำให้มั่นใจได้ว่าระบบมีความสามารถตามที่ระบุไว้จริง นอกจากนี้ การทดสอบการยอมรับยังช่วยให้คุณตรวจสอบการทำงานที่ถูกต้องของผลิตภัณฑ์ที่กำลังพัฒนาได้

สำหรับ XP แนวทางที่เรียกว่า TDD (Test Driven Development) มีลำดับความสำคัญสูงกว่า โดยขั้นแรกให้เขียนการทดสอบที่ไม่ผ่าน จากนั้นจึงเขียนโค้ดเพื่อให้การทดสอบผ่าน จากนั้นจึงปรับโครงสร้างโค้ดใหม่เท่านั้น

· คงที่การรีไซเคิล (การปรับโครงสร้างใหม่)

เป็นที่ทราบกันดีอยู่แล้วว่าการเพิ่มฟังก์ชันการทำงานใหม่และการเติบโตของโค้ดจะทำให้การพัฒนายุ่งยากขึ้น ระบุข้อผิดพลาด และทำการเปลี่ยนแปลงในภายหลัง เคล็ดลับอย่างหนึ่งของ Extreme Programming คือการชดเชยการเพิ่มฟังก์ชันการทำงานด้วยการปรับปรุงโค้ด นี่คือการประมวลผลโค้ดหรือการรีแฟคเตอร์

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

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

· การเขียนโปรแกรมเป็นคู่ (คู่การเขียนโปรแกรม)

นักพัฒนาที่มีประสบการณ์สังเกตเห็นว่าการตรวจสอบโค้ดของผู้อื่นเป็นระยะๆ จะส่งผลดีต่อคุณภาพของโค้ด ผู้เชี่ยวชาญด้าน Extreme Programming ได้พัฒนาแนวทางนี้โดยการตรวจสอบโค้ดอย่างต่อเนื่องในระหว่างการพัฒนาผ่านเทคนิคที่เรียกว่าการเขียนโปรแกรมคู่

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

· รวมการครอบครองรหัส (โดยรวมความเป็นเจ้าของ)

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

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

· คงที่บูรณาการ (อย่างต่อเนื่องบูรณาการ)

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

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

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

· 40 ชมการทำงานสัปดาห์

การทำงานล่วงเวลาถือเป็นสัญญาณของปัญหาที่ใหญ่กว่าในโครงการ ไม่อนุญาตให้ทำงานล่วงเวลาเป็นเวลา 2 สัปดาห์ติดต่อกัน - สิ่งนี้ทำให้โปรแกรมเมอร์หมดแรงและทำให้งานของพวกเขามีประสิทธิผลน้อยลงอย่างมาก

บุคคลโดยเฉพาะอย่างยิ่งหากเขาเป็นโปรแกรมเมอร์ก็สามารถทำอะไรได้มากมายเพื่อประโยชน์ของธุรกิจ เช่น การอยู่ดึกไปทำงาน ไปทำงานวันหยุดสุดสัปดาห์ เลิกลาพักร้อน ตื่นอยู่หลายวันขณะนั่งอยู่ที่คีย์บอร์ด... โดยทั่วไป คุณสามารถทำอะไรเพื่อกิจกรรมที่คุณชื่นชอบได้ แต่การเขียนโปรแกรมสุดโต่งนั้นขัดต่อการเสียสละตนเองและการละเมิดมาตรฐานกฎหมายแรงงานที่เป็นที่ยอมรับอย่างเด็ดขาด

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

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

· การรวมลูกค้าวีทีม (บน- เว็บไซต์ลูกค้า)

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

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

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

· การใช้งานรหัสยังไงสิ่งอำนวยความสะดวกการสื่อสาร

รหัสถูกมองว่าเป็นวิธีการสื่อสารที่สำคัญที่สุดภายในทีม ความชัดเจนของรหัสถือเป็นหนึ่งในความสำคัญหลัก การปฏิบัติตามมาตรฐานการเข้ารหัสที่ให้ความชัดเจนนี้มีความจำเป็น มาตรฐานดังกล่าว นอกเหนือจากความชัดเจนของโค้ดแล้ว ควรรับประกันภาษาขั้นต่ำ (ไม่มีโค้ดและข้อมูลซ้ำซ้อน) และควรได้รับการยอมรับจากสมาชิกในทีมทุกคน

· เปิดการทำงานช่องว่าง (เปิดพื้นที่ทำงาน)

ทีมงานตั้งอยู่ในห้องที่ค่อนข้างกว้างขวางเพียงห้องเดียวเพื่ออำนวยความสะดวกในการสื่อสารและเปิดใช้งานการอภิปรายกลุ่มเมื่อวางแผนและทำการตัดสินใจทางเทคนิคที่สำคัญ

· เปลี่ยนกฎโดยความจำเป็น (แค่กฎ)

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

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

3.1 เทคนิค XP พื้นฐาน

เทคนิคพื้นฐานสิบสองประการของการเขียนโปรแกรมขั้นสูง (อ้างอิงจากหนังสือฉบับพิมพ์ครั้งแรก สุดขีด การเขียนโปรแกรม อธิบาย) สามารถรวมกันได้เป็น 4 กลุ่ม:

· รอบป้อนกลับสั้น (ป้อนกลับขนาดละเอียด)

o การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ

o เกมการวางแผน

o ลูกค้าอยู่ใกล้ๆ เสมอ (ทั้งทีม ลูกค้านอกสถานที่)

o การเขียนโปรแกรมคู่

ต่อเนื่องมากกว่ากระบวนการเป็นชุด

o การบูรณาการอย่างต่อเนื่อง

o การรีแฟคเตอร์ (การปรับปรุงการออกแบบ รีแฟคเตอร์)

o การเผยแพร่เล็กๆ น้อยๆ บ่อยครั้ง

· ความเข้าใจร่วมกันโดยทุกคน

o ความเรียบง่าย (การออกแบบที่เรียบง่าย)

o คำอุปมาของระบบ

o ความเป็นเจ้าของรหัสรวมหรือรูปแบบการออกแบบที่เลือก (ความเป็นเจ้าของรูปแบบรวม)

o มาตรฐานการเข้ารหัสหรือแบบแผนการเข้ารหัส

· สวัสดิการโปรแกรมเมอร์:

o สัปดาห์การทำงาน 40 ชั่วโมง (อัตราการก้าวอย่างยั่งยืน สัปดาห์สี่สิบชั่วโมง)

เกมวีการวางแผน

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

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

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

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

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

4. ข้อดีและข้อเสีย

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

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

5. ประวัติการใช้งาน

XP เป็นชุดของเทคนิคที่อธิบายไว้ถูกใช้ครั้งแรกในระหว่างการทำงานในโครงการ C3 (ระบบค่าตอบแทนที่ครอบคลุมของไครสเลอร์ การพัฒนาระบบการบัญชีสำหรับผลประโยชน์ของพนักงานที่เดมเลอร์ไครสเลอร์) จากผู้เข้าร่วม 20 คนในโครงการนี้ 5 คน (รวมถึงผู้เขียนหลัก 3 คนที่กล่าวถึงข้างต้นของ XP) ได้ตีพิมพ์หนังสือ 3 เล่มและบทความจำนวนมากที่อุทิศให้กับ XP ในระหว่างโครงการและต่อมา ข้อมูลต่อไปนี้แสดงให้เห็นถึงปัญหาเกี่ยวกับเทคนิค XP บางอย่างเมื่อนำไปใช้กับโปรเจ็กต์ที่ค่อนข้างซับซ้อน

โครงการนี้เริ่มต้นในเดือนมกราคม พ.ศ. 2538 ตั้งแต่เดือนมีนาคม พ.ศ. 2539 หลังจากการรวม Kent Beck ได้มีการเรียกใช้โดยใช้ XP มาถึงตอนนี้มันเกินงบประมาณและแผนสำหรับการปรับใช้ฟังก์ชั่นแบบเป็นขั้นตอนไปแล้ว ทีมพัฒนาถูกตัดออก และประมาณหกเดือนหลังจากนั้นโครงการก็พัฒนาได้ค่อนข้างประสบความสำเร็จ ในเดือนสิงหาคม พ.ศ. 2541 มีต้นแบบปรากฏขึ้นซึ่งสามารถรองรับพนักงานได้ประมาณ 10,000 คน เดิมโครงการนี้คาดว่าจะแล้วเสร็จในกลางปี ​​2542 และซอฟต์แวร์ที่ได้จะถูกนำมาใช้เพื่อจัดการผลประโยชน์สำหรับพนักงาน 87,000 คนของบริษัท หยุดลงในเดือนกุมภาพันธ์ พ.ศ. 2543 หลังจากใช้งาน XP เป็นเวลา 4 ปี เนื่องจากไม่สามารถปฏิบัติตามกรอบเวลาและงบประมาณโดยสิ้นเชิง ซอฟต์แวร์ที่สร้างขึ้นไม่เคยถูกนำมาใช้เพื่อทำงานกับข้อมูลของพนักงานมากกว่า 10,000 คน แม้ว่าจะมีการแสดงให้เห็นว่าสามารถจัดการข้อมูลของพนักงานบริษัทได้ 30,000 คนก็ตาม บุคคลที่แสดงบทบาทเป็นลูกค้าที่อยู่ในทีมงานโครงการลาออกหลังจากทำงานดังกล่าวได้ไม่กี่เดือน ไม่สามารถทนต่อภาระงานได้ และไม่เคยได้รับการทดแทนที่เพียงพอจนกระทั่งสิ้นสุดโครงการ

บทสรุป

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

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

โพสต์บน Allbest.ru

เอกสารที่คล้ายกัน

การวิเคราะห์ขั้นตอนและคุณลักษณะของการพัฒนาโมเดล ARIS ที่เหมาะสมและใช้งานได้จริง - ผลิตภัณฑ์ซอฟต์แวร์จาก IDS Scheer สำหรับการสร้างแบบจำลองกระบวนการทางธุรกิจของบริษัท ศึกษาแนวคิดพื้นฐาน วิธีการ และแนวทางการเขียนโปรแกรมขั้นสูง

ทดสอบเพิ่มเมื่อ 06/04/2554


ขั้นตอนหลักของการพัฒนาซอฟต์แวร์ (ชุดซอฟต์แวร์) การวิเคราะห์ความต้องการของระบบ วิธีการลงรายละเอียดทีละขั้นตอน ภาษาการเขียนโปรแกรมระดับต่ำและระดับสูง (จำเป็น, เชิงวัตถุ, ฟังก์ชัน, ตรรกะ)

การนำเสนอเพิ่มเมื่อ 10/13/2013


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

บทช่วยสอนเพิ่มเมื่อ 26/10/2013


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

การนำเสนอเพิ่มเมื่อ 30/04/2014


รหัสเครื่องและแอสเซมเบลอร์ ภาษาโปรแกรมระดับสูงยุคแรก ภาษาโปรแกรม FORTRAN ข้อดีและข้อเสียของ ALGOL โปรแกรมวิทยาศาสตร์และการบัญชี หลักการพื้นฐานที่ปฏิบัติตามเมื่อสร้างภาษาโปรแกรมพื้นฐาน

งานหลักสูตรเพิ่มเมื่อ 21/06/2014


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

งานหลักสูตร เพิ่มเมื่อ 12/14/2012


แนวคิดเรื่องวงจรชีวิตของซอฟต์แวร์ กิจกรรมสองประเภทที่มีความโดดเด่นในโครงการด้านเทคนิค: การออกแบบและการผลิต หลักการสำคัญของการประกาศของผู้ติดตามวิธีการที่ยืดหยุ่น หลักการพื้นฐานของการเขียนโปรแกรมแบบเอ็กซ์ตรีม

การนำเสนอเพิ่มเมื่อ 14/08/2013


มาตรฐานสากลสำหรับภาษาโปรแกรมปาสคาล เทคนิคการเขียนโปรแกรมเชิงวัตถุใน Turbo Pascal สัญลักษณ์ของภาษา ตัวอักษรของมัน ขั้นตอนของการพัฒนาโปรแกรม แนวคิดของอัลกอริธึมและอัลกอริธึม โครงสร้างของโปรแกรมในภาษาปาสคาล

งานหลักสูตรเพิ่มเมื่อ 28/02/2010


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

วิทยานิพนธ์เพิ่มเมื่อ 13/07/2554


เทคนิคพื้นฐานสำหรับการทำงานในสภาพแวดล้อมการเขียนโปรแกรม Delphi คุณสมบัติของเทคโนโลยีสำหรับการสร้างแอพพลิเคชั่นที่เรียบง่าย การทำงานกับส่วนประกอบสภาพแวดล้อมการพัฒนาแอปพลิเคชัน การป้อนข้อมูล การแก้ไข การเลือก และการส่งออกข้อมูล แง่มุมของการใช้โครงสร้างการแตกแขนง

Extreme Programming หรือ XP, eXtreme Programming เป็นวิธีการพัฒนาซอฟต์แวร์ที่ยืดหยุ่น เช่นเดียวกับวิธีการแบบ Agile อื่นๆ ก็มีเครื่องมือ กระบวนการ และบทบาทเฉพาะ แม้ว่าผู้เขียน XP จะไม่ได้คิดอะไรใหม่ ๆ แต่ก็ใช้แนวทางปฏิบัติที่ดีที่สุดในการพัฒนาแบบ Agile และเสริมความแข็งแกร่งให้สูงสุด นั่นเป็นเหตุผลว่าทำไมการเขียนโปรแกรมถึงเรียกว่าสุดขั้ว

ผู้เขียนวิธีนี้คือ Kent Beck นักพัฒนาชาวอเมริกัน ในช่วงปลายทศวรรษที่ 90 เขาเป็นผู้นำโครงการ Chrysler Comprehensive Compensation System และที่นั่นเขาเป็นผู้บุกเบิกการฝึกเขียนโปรแกรมขั้นสูง เขาบรรยายถึงประสบการณ์และแนวคิดที่เขาสร้างขึ้นในหนังสือ Extreme Programming Explained ซึ่งตีพิมพ์ในปี 1999 ตามมาด้วยหนังสือเล่มอื่นๆ ที่ให้รายละเอียดเกี่ยวกับแนวทางปฏิบัติ XP Ward Cunningham, Martin Fowler และคนอื่นๆ มีส่วนร่วมในการพัฒนาวิธีการนี้เช่นกัน

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

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

วิธีการของ XP สร้างขึ้นจากสี่กระบวนการ ได้แก่ การเขียนโค้ด การทดสอบ การออกแบบ และการฟัง นอกจากนี้ Extreme Programming ยังมีคุณค่าของความเรียบง่าย การสื่อสาร การตอบรับ ความกล้าหาญ และความเคารพ

1.ทีมงานทั้งหมด

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

2. เกมการวางแผน

การวางแผนใน XP ดำเนินการในสองขั้นตอน ได้แก่ การวางแผนการเผยแพร่และการวางแผนการวนซ้ำ

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

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

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

มีการวางแผนการวนซ้ำ ทุกสองสัปดาห์บางครั้งไม่มากก็น้อยบ่อยครั้ง ลูกค้าจะปรากฏตัวอยู่เสมอ: เขากำหนดฟังก์ชันการทำงานสำหรับการทำซ้ำครั้งถัดไป และทำการเปลี่ยนแปลงข้อกำหนดของผลิตภัณฑ์

3. การเผยแพร่เวอร์ชันบ่อยครั้ง

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

4. การทดสอบผู้ใช้

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

5. ความเป็นเจ้าของรหัสโดยรวม

ใน XP นักพัฒนาทุกคนสามารถแก้ไขโค้ดส่วนใดก็ได้ เพราะ... รหัสไม่ได้ถูกกำหนดให้กับผู้เขียน ทีมงานทั้งหมดเป็นเจ้าของรหัส

6. การรวมโค้ดอย่างต่อเนื่อง

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

7. มาตรฐานการเข้ารหัส

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

8. คำอุปมาของระบบ

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

9. ก้าวที่มั่นคง

ทีม XP ทำงานอย่างมีประสิทธิภาพสูงสุดโดยยังคงรักษาอัตราการก้าวที่มั่นคง ในเวลาเดียวกัน การเขียนโปรแกรมแบบสุดโต่งมีทัศนคติเชิงลบต่อการทำงานล่วงเวลาและส่งเสริมการทำงานสัปดาห์ละ 40 ชั่วโมง

10. การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ

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

11. การเขียนโปรแกรมคู่

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

12. การออกแบบที่เรียบง่าย

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

13. การปรับโครงสร้างใหม่

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

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

วิธีการ XP ทำให้เกิดความขัดแย้งและการวิพากษ์วิจารณ์อย่างมากจากผู้ที่ไม่เคยสามารถนำวิธีนี้ไปใช้ในทีมของตนได้

ประโยชน์ของ Extreme Programming นั้นสมเหตุสมผลเมื่อทีมใช้แนวทางปฏิบัติ XP อย่างน้อยหนึ่งข้ออย่างเต็มที่ ดังนั้นสิ่งที่ควรค่าแก่การลอง:

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

แม้จะมีข้อดีทั้งหมด แต่ XP ก็อาจไม่ได้ผลเสมอไปและมีจุดอ่อนหลายประการ ดังนั้นการเขียนโปรแกรมขั้นสูง - ข้อเสีย:

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

หลักการของ XP

ในหนังสือเล่มแรกของเขา Kent Beck ได้กล่าวถึงหลักการของ Extreme Programming: ความเรียบง่าย การสื่อสาร การตอบรับ และความกล้าหาญ ในหนังสือฉบับพิมพ์ใหม่ เขาได้เพิ่มหลักการที่ห้า - ความเคารพ

1. ความเรียบง่าย

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

2. การสื่อสาร

ใน XP การสื่อสารระหว่างนักพัฒนาไม่ได้ดำเนินการผ่านเอกสาร แต่เป็นการสื่อสารสด ทีมงานสื่อสารระหว่างกันและกับลูกค้าอย่างแข็งขัน

3. ข้อเสนอแนะ

ความคิดเห็นใน XP ถูกนำมาใช้ในสามทิศทางพร้อมกัน:

1. เสียงตอบรับจากระบบระหว่างการทดสอบโมดูลอย่างต่อเนื่อง
2. เสียงตอบรับจากลูกค้าเพราะว่า เขาเป็นส่วนหนึ่งของทีมและมีส่วนร่วมในการเขียนแบบทดสอบการยอมรับ
3. ข้อเสนอแนะจากทีมงานระหว่างการวางแผนเกี่ยวกับระยะเวลาในการพัฒนา

4. ความกล้าหาญ

เทคนิคการเขียนโปรแกรมขั้นสูงบางอย่างนั้นผิดปกติมากจนต้องใช้ความกล้าหาญและการควบคุมตนเองอย่างต่อเนื่อง

5. ความเคารพ

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

อัลกอริทึมสำหรับการนำวิธีการ XP ไปใช้และกระบวนการทำงาน

Beck Kent แนะนำให้ใช้ XP เพื่อแก้ไขปัญหาในโครงการ ทีมงานเลือกปัญหาเร่งด่วนที่สุดและแก้ไขโดยใช้แนวทางปฏิบัติการเขียนโปรแกรมแบบ Extreme แล้วค่อยไปสู่ปัญหาต่อไปด้วยการฝึกฝนให้มากขึ้น ด้วยแนวทางนี้ ปัญหาจะทำหน้าที่เป็นแรงจูงใจในการใช้ XP และทีมงานจะค่อยๆ เชี่ยวชาญเครื่องมือทั้งหมดของวิธีการดังกล่าว

หากต้องการนำ XP ไปใช้ในโครงการที่มีอยู่ คุณจะต้องค่อยๆ เชี่ยวชาญเทคนิคต่างๆ ในด้านต่อไปนี้:

• การทดสอบ
• ออกแบบ
• การวางแผน
• การจัดการ
• การพัฒนา

การทดสอบ

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

ออกแบบ.

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

การวางแผน.

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

การจัดการ.

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

การพัฒนา.

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

ในโครงการที่ทำงานตามวิธีการ XP กระบวนการมีโครงสร้างดังนี้:

ใครใช้ XP

จากการศึกษาของ Versionone ในปี 2559 มีเพียง 1% ของบริษัทที่มีความคล่องตัวเท่านั้นที่ใช้การเขียนโปรแกรมขั้นสูงในรูปแบบที่บริสุทธิ์ อีก 10% ทำงานโดยใช้วิธี Scrum แบบไฮบริดและ XP

สิ่งที่น่าสนใจคือ แม้ว่า XP จะยังห่างไกลจากวิธีการทั่วไปในรูปแบบที่บริสุทธิ์ แต่บริษัทส่วนใหญ่ที่ทำงานเกี่ยวกับระเบียบวิธีแบบ Agile ก็ใช้แนวทางปฏิบัติดังกล่าว นี่คือหลักฐานจากข้อมูลจากการศึกษาเดียวกัน:

การค้นหาข้อมูลเกี่ยวกับทีมที่ใช้ XP ไม่ใช่เรื่องง่าย แต่มีผู้ที่โฆษณาว่าวิธีการนี้เป็นสาเหตุของความสำเร็จ ตัวอย่างของ Extreme Programming คือ Pivotal Software, Inc.

พิโวทอล ซอฟต์แวร์ อิงค์

บริษัทซอฟต์แวร์สัญชาติอเมริกันที่พัฒนาซอฟต์แวร์สำหรับการวิเคราะห์ธุรกิจโดยใช้ข้อมูลขนาดใหญ่และให้บริการคำปรึกษา ผลิตภัณฑ์ที่สำคัญมีการใช้งานโดย Ford, Mercedes, BMW, GAP, Humana, ธนาคารขนาดใหญ่, หน่วยงานราชการ, บริษัทประกันภัย ฯลฯ

Pivotal เป็นผู้สนับสนุนวิธีการแบบ Agile ซึ่งเป็นวิธีเดียวที่เป็นไปได้ในการพัฒนาสมัยใหม่ ในบรรดาตัวเลือกทั้งหมดสำหรับวิธีการที่ยืดหยุ่น บริษัทเลือก XP เป็นแนวทางที่ได้ประโยชน์ทั้งสองฝ่ายสำหรับลูกค้าและทีมเขียนโปรแกรม ทุกวันทำการเริ่มต้นด้วยการประชุมระหว่างเดินทาง และสิ้นสุดเวลา 18:00 น. พอดี - ไม่มีการทำงานล่วงเวลา Pivotal ใช้การวางแผนเกม การเขียนโปรแกรมคู่ การทดสอบอย่างต่อเนื่อง การบูรณาการอย่างต่อเนื่อง และแนวทางปฏิบัติ XP อื่นๆ สำหรับแนวทางปฏิบัติหลายๆ อย่าง พวกเขามีซอฟต์แวร์ของตัวเอง

การเขียนโปรแกรมสุดขีด,
การเขียนโปรแกรมขั้นสูง: การวางแผน
การเขียนโปรแกรมขั้นสูง: การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ / เคนท์ เบ็ค

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

การปรับโครงสร้างใหม่: การปรับปรุงโค้ดที่มีอยู่ / Martin Fowler

การเขียนโปรแกรมขั้นสูง: การกำหนดกระบวนการ จากก้าวแรกสู่จุดจบอันขมขื่น / เคน ออเออร์, รอย มิลเลอร์

เนื่องจาก Extreme Programming มุ่งมั่นที่จะสร้างโค้ดที่สะอาดและบำรุงรักษาง่าย รายชื่อหนังสือจึงรวมสิ่งพิมพ์ทั้งหมดที่สอนวิธีเขียนโปรแกรมให้ดีขึ้นให้กับคุณ

แอปพลิเคชันสำหรับการนำ XP ไปใช้งานในทีม

ทีมที่ทำงานในโครงการโดยใช้วิธี XP ใช้ตัวจัดการงานและบริการสำหรับโครงการที่คล่องตัว มีผลิตภัณฑ์ดังกล่าวมากมายในตลาด เราจะดูตัวอย่างบางส่วน

ตัวจัดการงานโอเพ่นซอร์สฟรี หน้าที่หลัก: ทำงานหลายโครงการพร้อมกัน, ระบบจัดการงานที่ยืดหยุ่น, แผนภูมิแกนต์, การควบคุมเวลา, ทำงานกับเอกสารประกอบ, สร้างงานผ่านอีเมล ฯลฯ

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

จิรา

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

เพื่อทำงานในโครงการ ช่วยให้คุณสามารถตั้งค่างานและควบคุมกระบวนการดำเนินการ โต้ตอบกันในงาน ตั้งค่าตัวกรอง คำนึงถึงการใช้เวลาและการเงิน และทำงานกับไฟล์

คำตัดสิน

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

วิธีการนี้มีไว้สำหรับสาขานี้โดยเฉพาะ การพัฒนาซอฟต์แวร์และไม่สามารถนำไปปรับใช้กับธุรกิจอื่นได้

นี่เป็นหนึ่งในวิธีการที่ยากที่สุดในการดำเนินการเนื่องจากมีแนวทางปฏิบัติมากถึงสิบสามวิธี!

มีบริษัทเพียงไม่กี่แห่งที่เสี่ยงในการทำงานกับ XP ล้วนๆ แต่แนวทางการพัฒนาของบริษัทนั้นได้รับความนิยมมากที่สุดในโครงการที่มีความคล่องตัว และนี่คือข้อโต้แย้งที่ชัดเจนในความมีประสิทธิผล

ไม่มีใครบังคับให้คุณติดตั้ง XP แบบทั้งหมดหรือไม่ใช้เลย ท้ายที่สุดแล้ว วิธีการแบบ Agile จะต้องมีความยืดหยุ่นในการใช้งาน ซึ่งปรับให้เหมาะกับความต้องการของทีมและโครงการที่เฉพาะเจาะจง

การพัฒนา (การพัฒนาที่ขับเคลื่อนด้วยฟังก์ชันของระบบ) ฯลฯ

ตามที่ผู้เขียน XP กล่าวว่าเทคนิคนี้ไม่ได้เป็นไปตามรูปแบบการกระทำทั่วไปบางอย่างมากนักเท่ากับการใช้เทคนิคต่อไปนี้รวมกัน อย่างไรก็ตาม แต่ละเทคนิคมีความสำคัญ และหากไม่มีการใช้งาน การพัฒนาจะไม่ถือเป็น XP ตามที่ Kent Beck หนึ่งในผู้เขียนแนวทางนี้ร่วมกับ Ward Cunningham และ Ron Jeffries กล่าว

• เกมวางแผนสด

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

• การเปลี่ยนแปลงเวอร์ชันบ่อยครั้ง (รุ่นเล็ก)

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

• อุปมาของระบบ

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

• โซลูชั่นการออกแบบที่เรียบง่าย

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

• การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ

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

• การรีแฟคเตอร์อย่างต่อเนื่อง

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

• การเขียนโปรแกรมคู่

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

• ความเป็นเจ้าของโดยรวมของรหัส

  สมาชิกในทีมสามารถเปลี่ยนส่วนใดส่วนหนึ่งของโค้ดได้ตลอดเวลา ไม่มีใครควรมีพื้นที่รับผิดชอบของตนเอง ทีมทั้งหมดโดยรวมต้องรับผิดชอบโค้ดทั้งหมด

• การบูรณาการอย่างต่อเนื่อง

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

• สัปดาห์การทำงาน 40 ชั่วโมง

  การทำงานล่วงเวลาถือเป็นสัญญาณของปัญหาที่ใหญ่กว่าในโครงการ ไม่อนุญาตให้ทำงานล่วงเวลาเป็นเวลา 2 สัปดาห์ติดต่อกัน - สิ่งนี้ทำให้โปรแกรมเมอร์หมดแรงและทำให้งานของพวกเขามีประสิทธิผลน้อยลงอย่างมาก

• รวมไปถึงลูกค้าในทีมงาน (on-site customer)

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

• การใช้รหัสเป็นวิธีการสื่อสาร

  รหัสถูกมองว่าเป็นวิธีการสื่อสารที่สำคัญที่สุดภายในทีม ความชัดเจนของรหัสถือเป็นหนึ่งในความสำคัญหลัก การปฏิบัติตามมาตรฐานการเข้ารหัสที่ให้ความชัดเจนนี้มีความจำเป็น มาตรฐานดังกล่าว นอกเหนือจากความชัดเจนของโค้ดแล้ว ควรรับประกันภาษาขั้นต่ำ (ไม่มีโค้ดและข้อมูลซ้ำซ้อน) และควรได้รับการยอมรับจากสมาชิกในทีมทุกคน

• เปิดพื้นที่ทำงาน

  ทีมงานตั้งอยู่ในห้องที่ค่อนข้างกว้างขวางเพียงห้องเดียวเพื่ออำนวยความสะดวกในการสื่อสารและเปิดใช้งานการอภิปรายกลุ่มเมื่อวางแผนและทำการตัดสินใจทางเทคนิคที่สำคัญ

• เปลี่ยนกฎเกณฑ์ตามต้องการ (แค่กฎ)

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

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

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

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

XP เป็นชุดของเทคนิคที่อธิบายไว้ถูกใช้ครั้งแรกในระหว่างการทำงานในโครงการ C3 (ระบบค่าตอบแทนที่ครอบคลุมของไครสเลอร์ การพัฒนาระบบการบัญชีสำหรับผลประโยชน์ของพนักงานที่เดมเลอร์ไครสเลอร์) จากผู้เข้าร่วม 20 คนในโครงการนี้ 5 คน (รวมถึงผู้เขียนหลัก 3 คนที่กล่าวถึงข้างต้นของ XP) ได้ตีพิมพ์หนังสือ 3 เล่มและบทความจำนวนมากที่อุทิศให้กับ XP ในระหว่างโครงการและต่อมา โครงการนี้ถูกกล่าวถึงซ้ำแล้วซ้ำอีกในแหล่งต่าง ๆ เพื่อเป็นตัวอย่างของการใช้เทคนิคนี้ ข้อมูลต่อไปนี้รวบรวมจากบทความที่กล่าวถึง ลบหลักฐานโดยสังเขป และแสดงให้เห็นปัญหาเกี่ยวกับเทคนิค XP บางอย่าง เมื่อนำไปใช้กับโครงการที่ค่อนข้างซับซ้อน

โครงการนี้เริ่มต้นในเดือนมกราคม พ.ศ. 2538 ตั้งแต่เดือนมีนาคม พ.ศ. 2539 หลังจากการรวม Kent Beck ได้มีการเรียกใช้โดยใช้ XP มาถึงตอนนี้มันเกินงบประมาณและแผนสำหรับการปรับใช้ฟังก์ชั่นแบบเป็นขั้นตอนไปแล้ว ทีมพัฒนาถูกตัดออก และประมาณหกเดือนหลังจากนั้นโครงการก็พัฒนาได้ค่อนข้างประสบความสำเร็จ ในเดือนสิงหาคม พ.ศ. 2541 มีต้นแบบปรากฏขึ้นซึ่งสามารถรองรับพนักงานได้ประมาณ 10,000 คน เดิมโครงการนี้คาดว่าจะแล้วเสร็จในกลางปี ​​2542 และซอฟต์แวร์ที่ได้จะถูกนำมาใช้เพื่อจัดการผลประโยชน์สำหรับพนักงาน 87,000 คนของบริษัท หยุดลงในเดือนกุมภาพันธ์ พ.ศ. 2543 หลังจากใช้งาน XP เป็นเวลา 4 ปี เนื่องจากไม่สามารถปฏิบัติตามกรอบเวลาและงบประมาณโดยสิ้นเชิง ซอฟต์แวร์ที่สร้างขึ้นไม่เคยถูกนำมาใช้เพื่อทำงานกับข้อมูลของพนักงานมากกว่า 10,000 คน แม้ว่าจะมีการแสดงให้เห็นว่าสามารถจัดการข้อมูลของพนักงานบริษัทได้ 30,000 คนก็ตาม บุคคลที่แสดงบทบาทเป็นลูกค้าที่อยู่ในทีมงานโครงการลาออกหลังจากทำงานดังกล่าวได้ไม่กี่เดือน ไม่สามารถทนต่อภาระงานได้ และไม่เคยได้รับการทดแทนที่เพียงพอจนกระทั่งสิ้นสุดโครงการ

Extreme Programming (XP) เป็นหนึ่งในวิธีการพัฒนาซอฟต์แวร์ที่ยืดหยุ่น ผู้เขียนวิธีการนี้คือ Kent Beck, Ward Cunningham, Martin Fowler และคนอื่นๆ

เกมการวางแผน

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

แผนการวางจำหน่าย

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

การวางแผนการวนซ้ำ

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

ยืนประชุม

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

ความเรียบง่าย

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

ระบบอุปมาอุปไมย

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

ลูกค้าถึงหน้างาน

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

การทดสอบก่อนเริ่มการพัฒนา

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

การเขียนโปรแกรมคู่

รหัสทั้งหมดสำหรับระบบการผลิตเขียนเป็นคู่ นักพัฒนาสองคนกำลังนั่งติดกัน คนหนึ่งกำลังพิมพ์ อีกคนกำลังดูอยู่ พวกเขาเปลี่ยนแปลงเป็นครั้งคราว ไม่อนุญาตให้ทำงานคนเดียว หากคู่ที่สองพลาดอะไรบางอย่าง (ป่วย เกษียณ ฯลฯ) ด้วยเหตุผลบางประการ เขาจะต้องตรวจสอบการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นในคู่แรก
ฟังดูไม่ปกติ แต่หลังจากปรับตัวได้ช่วงสั้นๆ คนส่วนใหญ่ก็ทำงานร่วมกันเป็นคู่ได้ดี พวกเขายังชอบเพราะงานเสร็จเร็วขึ้นอย่างเห็นได้ชัด ใช้หลักการ “หัวเดียวก็ดี แต่สองหัวดีกว่า” คู่รักมักจะพบวิธีแก้ปัญหาที่ดีกว่า นอกจากนี้คุณภาพของโค้ดจะเพิ่มขึ้นอย่างมาก จำนวนข้อผิดพลาดลดลง และการแลกเปลี่ยนความรู้ระหว่างนักพัฒนาก็เร็วขึ้น ในขณะที่คนหนึ่งมุ่งเน้นไปที่วิสัยทัศน์เชิงกลยุทธ์ของวัตถุ คนที่สองนำคุณสมบัติและวิธีการของมันไปใช้

การเปลี่ยนตำแหน่ง

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

ความเป็นเจ้าของรหัสรวม

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

แบบแผนการเข้ารหัส

คุณเป็นส่วนหนึ่งของทีมที่ทำงานในโครงการนี้มาเป็นเวลานาน ผู้คนมาและไป ไม่มีใครรหัสเพียงอย่างเดียวและรหัสเป็นของทุกคน มักจะมีบางครั้งที่คุณต้องเข้าใจและปรับเปลี่ยนโค้ดของผู้อื่น นักพัฒนาจะลบหรือเปลี่ยนโค้ดที่ซ้ำกัน วิเคราะห์และปรับปรุงคลาสของผู้อื่น ฯลฯ เมื่อเวลาผ่านไป เป็นไปไม่ได้ที่จะบอกว่าใครเป็นผู้เขียนชั้นเรียนใดชั้นเรียนหนึ่ง
ดังนั้น ทุกคนจะต้องปฏิบัติตามมาตรฐานการเข้ารหัสทั่วไป - การจัดรูปแบบโค้ด การตั้งชื่อคลาส ตัวแปร ค่าคงที่ รูปแบบความคิดเห็น ด้วยวิธีนี้ เราจะมั่นใจได้ว่าเมื่อเราทำการเปลี่ยนแปลงโค้ดของผู้อื่น (ซึ่งจำเป็นสำหรับความก้าวหน้าในเชิงรุกและก้าวไปข้างหน้า) เราจะไม่เปลี่ยนมันให้กลายเป็น Babel Pandemonium
ข้อความข้างต้นหมายความว่าสมาชิกในทีมทุกคนต้องเห็นด้วยกับมาตรฐานการเข้ารหัสทั่วไป มันไม่สำคัญว่าอันไหน กฎคือทุกคนเชื่อฟังพวกเขา ส่วนใครไม่ประสงค์จะปฏิบัติตามก็ออกจากทีมไป

การบูรณาการบ่อยครั้ง

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

สัปดาห์การทำงานสี่สิบชั่วโมง

บุคคลโดยเฉพาะอย่างยิ่งหากเขาเป็นโปรแกรมเมอร์ก็สามารถทำอะไรได้มากมายเพื่อประโยชน์ของธุรกิจ เช่น ทำงานสาย ไปทำงานวันหยุดสุดสัปดาห์ เลิกลาพักร้อน ตื่นตัวเป็นเวลาหลายวันขณะนั่งอยู่ที่คีย์บอร์ด... โดยทั่วไป คุณสามารถทำอะไรเพื่อกิจกรรมที่คุณชื่นชอบได้ แต่การเขียนโปรแกรมสุดโต่งนั้นขัดต่อการเสียสละตนเองและการละเมิดมาตรฐานกฎหมายแรงงานที่เป็นที่ยอมรับอย่างเด็ดขาด
สิ่งนี้ถูกกำหนดไม่เพียงแต่โดยการพิจารณาถึงความถูกต้องตามกฎหมายและมนุษยธรรมเท่านั้น แต่ประการแรกคือโดยความจำเป็นในการเพิ่มประสิทธิภาพการทำงานและการจัดองค์กรที่เข้มงวด ท้ายที่สุดแล้ว การเขียนโปรแกรมแบบเอ็กซ์ตรีมเป็นเกมแบบรวมกลุ่ม ซึ่งไม่ได้ออกแบบมาสำหรับบุคคล แต่สำหรับทั้งกลุ่ม และสิ่งต่าง ๆ เช่นการเขียนโปรแกรมคู่จะเกิดขึ้นได้ก็ต่อเมื่อมีการซิงโครไนซ์ biorhythms ของผู้เข้าร่วมเท่านั้น และเป็นไปไม่ได้ถ้าคนหนึ่งมาทำงานตอนเก้าโมงและคนที่สองตอนสิบสองหรือคนหนึ่งตัดสินใจว่าจะดีกว่าสำหรับเขาที่จะทำงานในวันเสาร์และวันอาทิตย์ในขณะที่อีกคนไม่สะดวก
แต่สิ่งที่สำคัญที่สุดคือเพื่อรักษาสุขภาพและประสิทธิภาพการทำงาน บุคคลจำเป็นต้องพักผ่อนอย่างเหมาะสม วันทำงานแปดชั่วโมงและสัปดาห์ทำงานห้าวันถูกกำหนดไว้อย่างชัดเจนด้วยเหตุผลของประสิทธิภาพการผลิตสูงสุด ในบริษัทตะวันตกหลายแห่ง การออกจากงานสายถือเป็นความล้มเหลวในการทำงานให้ดีหรือไม่สามารถจัดการเวลาทำงานได้อย่างเหมาะสม ในกรณีส่วนใหญ่สิ่งนี้เป็นจริง และจากมุมมองทางการแพทย์ ความล่าช้าในการทำงานทำให้เกิดความเหนื่อยล้า หงุดหงิด และการทำงานของสมองลดลงอย่างต่อเนื่อง สิ่งนี้มีประสิทธิภาพหรือไม่? เราจะจัดระเบียบการสื่อสารแบบเปิดอย่างต่อเนื่องระหว่างนักพัฒนาในทีมดังกล่าวได้อย่างไร และการเขียนโปรแกรมคู่จะเป็นไปได้หรือไม่ คำตอบคือเชิงลบ มาตรฐานก็คือมาตรฐานและควรปฏิบัติตาม

บทสรุป

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

บรรณานุกรม:

Extreme Programming (XP) กลายเป็นวิธีวิวัฒนาการของการพัฒนาซอฟต์แวร์จากล่างขึ้นบน แนวทางนี้เป็นตัวอย่างของสิ่งที่เรียกว่าวิธีการพัฒนาแบบ Agile กลุ่มของวิธีการ "สด" รวมถึงนอกเหนือจากการเขียนโปรแกรมขั้นสูงแล้ว วิธีการ SCRUM, DSDM (วิธีการพัฒนาระบบไดนามิก, วิธีการพัฒนาระบบไดนามิก), การพัฒนาที่ขับเคลื่อนด้วยคุณลักษณะ (การพัฒนาที่ขับเคลื่อนโดยฟังก์ชันระบบ) เป็นต้น

หลักการพื้นฐานของการพัฒนาซอฟต์แวร์แบบสดนั้นประดิษฐานอยู่ในแถลงการณ์การพัฒนาแบบสดซึ่งปรากฏในปี 2543

• · ผู้คนที่เกี่ยวข้องในโครงการและการสื่อสารของพวกเขามีความสำคัญมากกว่ากระบวนการและเครื่องมือ
• · โปรแกรมการทำงานมีความสำคัญมากกว่าเอกสารประกอบที่ครอบคลุม
• · ความร่วมมือกับลูกค้ามีความสำคัญมากกว่าการหารือรายละเอียดของสัญญา
• · การทำงานผ่านการเปลี่ยนแปลงมีความสำคัญมากกว่าการยึดติดกับแผน

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

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

อย่างไรก็ตาม XP มีแผนภาพกระบวนการพัฒนาของตัวเอง (แม้ว่าโดยทั่วไปแล้วความเข้าใจที่ใช้กันอย่างแพร่หลายเกี่ยวกับ "กระบวนการพัฒนา" ซึ่งเป็นรูปแบบการกระทำที่ค่อนข้างเข้มงวดนั้นขัดแย้งกับแนวคิดของการพัฒนาที่ "มีชีวิตชีวา") ดังแสดงในรูปที่ 1 .

ตามที่ผู้เขียน XP กล่าวว่าเทคนิคนี้ไม่ได้เป็นไปตามรูปแบบการกระทำทั่วไปบางอย่างมากนักเท่ากับการใช้เทคนิคต่อไปนี้รวมกัน อย่างไรก็ตาม แต่ละเทคนิคมีความสำคัญ และหากไม่มีการใช้งาน การพัฒนาจะไม่ถือเป็น XP ตามที่ Kent Beck หนึ่งในผู้เขียนแนวทางนี้ร่วมกับ Ward Cunningham และ Ron Jeffries กล่าว

· สด การวางแผน เกม)

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

รูปที่ 1

· บ่อย เปลี่ยน รุ่น (เล็ก เผยแพร่)

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

· อุปมาของระบบ

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

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

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

· เรียบง่าย ออกแบบ โซลูชั่น (ง่าย ออกแบบ)

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

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

· การพัฒนา บน พื้นฐาน การทดสอบ (การทดสอบขับเคลื่อน การพัฒนา)

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

XP ให้ความสำคัญกับการทดสอบสองประเภทเป็นพิเศษ:

ь การทดสอบหน่วย;

การทดสอบการยอมรับ b

ซอฟต์แวร์การเขียนโปรแกรมขั้นสูง

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

การทดสอบการยอมรับทำให้มั่นใจได้ว่าระบบมีความสามารถตามที่ระบุไว้จริง นอกจากนี้ การทดสอบการยอมรับยังช่วยให้คุณตรวจสอบการทำงานที่ถูกต้องของผลิตภัณฑ์ที่กำลังพัฒนาได้

สำหรับ XP แนวทางที่เรียกว่า TDD (Test Driven Development) มีลำดับความสำคัญสูงกว่า โดยขั้นแรกให้เขียนการทดสอบที่ไม่ผ่าน จากนั้นจึงเขียนโค้ดเพื่อให้การทดสอบผ่าน จากนั้นจึงปรับโครงสร้างโค้ดใหม่เท่านั้น

· คงที่ การปรับโครงสร้างใหม่

เป็นที่ทราบกันดีอยู่แล้วว่าการเพิ่มฟังก์ชันการทำงานใหม่และการเติบโตของโค้ดจะทำให้การพัฒนายุ่งยากขึ้น ระบุข้อผิดพลาด และทำการเปลี่ยนแปลงในภายหลัง เคล็ดลับอย่างหนึ่งของ Extreme Programming คือการชดเชยการเพิ่มฟังก์ชันการทำงานด้วยการปรับปรุงโค้ด นี่คือการประมวลผลโค้ดหรือการรีแฟคเตอร์

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

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

· การเขียนโปรแกรม คู่ การเขียนโปรแกรม)

นักพัฒนาที่มีประสบการณ์สังเกตเห็นว่าการตรวจสอบโค้ดของผู้อื่นเป็นระยะๆ จะส่งผลดีต่อคุณภาพของโค้ด ผู้เชี่ยวชาญด้าน Extreme Programming ได้พัฒนาแนวทางนี้โดยการตรวจสอบโค้ดอย่างต่อเนื่องในระหว่างการพัฒนาผ่านเทคนิคที่เรียกว่าการเขียนโปรแกรมคู่

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

· รวม การครอบครอง รหัส (รวม ความเป็นเจ้าของ)

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

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

· คงที่ บูรณาการ (ต่อ บูรณาการ)

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

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

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

· 40 ชม การทำงาน สัปดาห์

การทำงานล่วงเวลาถือเป็นสัญญาณของปัญหาที่ใหญ่กว่าในโครงการ ไม่อนุญาตให้ทำงานล่วงเวลาเป็นเวลา 2 สัปดาห์ติดต่อกัน - สิ่งนี้ทำให้โปรแกรมเมอร์หมดแรงและทำให้งานของพวกเขามีประสิทธิผลน้อยลงอย่างมาก

บุคคลโดยเฉพาะอย่างยิ่งหากเขาเป็นโปรแกรมเมอร์ก็สามารถทำอะไรได้มากมายเพื่อประโยชน์ของธุรกิจ เช่น การอยู่ดึกไปทำงาน ไปทำงานวันหยุดสุดสัปดาห์ เลิกลาพักร้อน ตื่นอยู่หลายวันขณะนั่งอยู่ที่คีย์บอร์ด... โดยทั่วไป คุณสามารถทำอะไรเพื่อกิจกรรมที่คุณชื่นชอบได้ แต่การเขียนโปรแกรมสุดโต่งนั้นขัดต่อการเสียสละตนเองและการละเมิดมาตรฐานกฎหมายแรงงานที่เป็นที่ยอมรับอย่างเด็ดขาด

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

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

· การรวม ลูกค้า วี ทีมงาน (ในสถานที่ ลูกค้า)

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

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

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

· การใช้งาน รหัส ยังไง สิ่งอำนวยความสะดวก การสื่อสาร

รหัสถูกมองว่าเป็นวิธีการสื่อสารที่สำคัญที่สุดภายในทีม ความชัดเจนของรหัสถือเป็นหนึ่งในความสำคัญหลัก การปฏิบัติตามมาตรฐานการเข้ารหัสที่ให้ความชัดเจนนี้มีความจำเป็น มาตรฐานดังกล่าว นอกเหนือจากความชัดเจนของโค้ดแล้ว ควรรับประกันภาษาขั้นต่ำ (ไม่มีโค้ดและข้อมูลซ้ำซ้อน) และควรได้รับการยอมรับจากสมาชิกในทีมทุกคน

· เปิด การทำงาน พื้นที่ (เปิด พื้นที่ทำงาน)

ทีมงานตั้งอยู่ในห้องที่ค่อนข้างกว้างขวางเพียงห้องเดียวเพื่ออำนวยความสะดวกในการสื่อสารและเปิดใช้งานการอภิปรายกลุ่มเมื่อวางแผนและทำการตัดสินใจทางเทคนิคที่สำคัญ

· เปลี่ยน กฎ โดย จำเป็น (เพียง กฎ)

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

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