#priwreadbooks Extreme Programming Explained สรุป บทที่ 1–4

Second Edition, Kent Beck with Cynthia Andres

Disclaimer: บทความนี้เป็นการสรุป บทที่ 1–4 ของหนังสือที่ชื่อ Extreme Programming Explained เจ้าของหนังสือคือพี่บอย ส่งมอบมาให้อ่านโดยพี่หนุ่ม ถ้าเขียนงงๆ ไปบ้าง ก็บอกเลยว่า ตอนที่อ่านก็งงเหมือนกัน 55

Extreme Programming Explained เล่มนี้ เขียนโดย Kent Beck เขาเป็นวิศวกรซอฟต์แวร์ชาวอเมริกัน เป็นผู้สร้าง Methodology ที่ชื่อ Extreme Programming และเป็นหนึ่งใน 17 ผู้ลงนามของ Agile Manifesto

Chapter 1 — What is XP?

Extreme Programming (XP) คือ Social Change การเปลี่ยนนิสัย รูปแบบในอดีต เพื่อให้การทำงานออกมาดีที่สุด การเปิดใจสิ่งที่เราสามารถทำได้และทำมัน การหา สถานที่ ตัวตนของเราในโลกที่กว้างขึ้น กระบวนการที่ดีในการพัฒนา การเขียนโค้ดที่ยอดเยี่ยม ซึ่งส่งผลดีต่อธุรกิจ

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

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

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

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

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

การแสวงหาความเป็นเลิศทางด้านเทคนิค เป็นสิ่งสำคัญในรูปแบบการพัฒนาทางสังคม หากคุณสามารถประเมินงานของคุณได้อย่างแม่นยำ ส่งมอบงานที่มีคุณภาพได้ในครั้งแรก และสร้าง feedback loop ที่รวดเร็ว คุณก็สามารถเป็นหุ้นส่วนที่น่าเชื่อถือได้

ปฏิสัมพันธ์ทางสังคมที่ดีและปลอดภัย จำเป็นต่อการพัฒนา XP ให้ประสบความสำเร็จพอๆ กับทักษะทางเทคนิคที่ดี

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

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

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

ไม่ใช่หน้าที่ของฉันที่จะ “จัดการ” ความคาดหวังของคนอื่น
เป็นหน้าที่ของพวกเขาในการจัดการความคาดหวังของตนเอง
หน้าที่ของฉันคือ ทำให้ดีที่สุด และสื่อสารอย่างชัดเจน

• การดีเลย์ — XP ทำให้มีรอบการเผยแพร่ (release) สั้นๆ มากที่สุดไม่กี่เดือน ดังนั้นขอบเขตของ Schedule ที่ถูกเลื่อนออกจะถูกจำกัด วางแผนงานเป็นรอบสั้นๆ เพื่อให้ทีมสามารถแก้ปัญหาระหว่างรอบการทำงานได้ และนำคุณลักษณะ (feature/function) ที่มีลำดับความสำคัญสูงสุดมาพัฒนาก่อน
• โปรเจ็กต์ถูกยกเลิก — XP เลือก release ที่เล็กที่สุด เหมาะสมที่สุดสำหรับธุรกิจ และมูลค่าของซอฟต์แวร์จะมากที่สุด
• ระบบมีปัญหา — XP สร้างและดูแลชุดการทดสอบอัตโนมัติที่ครอบคลุม ซึ่งรันและรันซ้ำหลังจากการเปลี่ยนแปลงทุกครั้ง (หลายครั้งต่อวัน) เพื่อให้แน่ใจว่าระบบอยู่ในสภาพที่ใช้ได้เสมอ
• อัตราข้อบกพร่อง — การทดสอบ XP เกิดจากมุมมองของโปรแกรมเมอร์ที่เขียนการทดสอบฟังก์ชันต่อฟังก์ชัน และการทดสอบที่ถูกเขียนจากมุมมองของลูกค้า จะช่วยลดอัตราการเกิด Defect
• ความเข้าใจผิดทางธุรกิจ — XP ให้บุคลากรฝั่งธุรกิจเข้ามาเป็นสมาชิกของทีม ข้อกำหนดของโครงการได้รับการปรับปรุงอย่างต่อเนื่องในระหว่างการพัฒนา ดังนั้นการเรียนรู้โดยลูกค้าและทีม สามารถสะท้อนให้เห็นได้ในซอฟต์แวร์
• การเปลี่ยนแปลงทางธุรกิจ — XP ทำให้รอบการเผยแพร่สั้นลง ในระหว่างรอการเปิดตัว ลูกค้าสามารถเพิ่มฟังก์ชันการทำงานใหม่ แทนฟังก์ชันที่ยังไม่เสร็จสมบูรณ์ เพื่อให้ตอบรับการเปลี่ยนแปลง
• อุดมด้วยคุณสมบัติที่ผิดพลาด — XP ยืนยันว่า เฉพาะงานที่มีความสำคัญสูงสุดเท่านั้นที่ได้รับการแก้ไข
• พนักงานลาออก — XP ขอให้โปรแกรมเมอร์รับผิดชอบประเมินและทำงานของตัวเองให้เสร็จ ให้ข้อเสนอแนะเกี่ยวกับเวลาจริงเพื่อให้การประมาณการสามารถปรับปรุงได้ และเคารพการประมาณการเหล่านั้น กฎสำหรับผู้ที่สามารถสร้างและเปลี่ยนแปลงการประมาณมีความชัดเจน ดังนั้นจึงมีโอกาสน้อยที่โปรแกรมเมอร์จะหงุดหงิดจากการถูกขอให้ทำสิ่งที่เป็นไปไม่ได้อย่างเห็นได้ชัด XP ยังส่งเสริมการติดต่อระหว่างคนในทีม ลดความเหงาที่มักเป็นหัวใจสำคัญของความไม่พึงพอใจในงาน สมาชิกในทีมใหม่ได้รับการสนับสนุนให้มีความรับผิดชอบมากขึ้นเรื่อยๆ และได้รับความช่วยเหลือจากกันและกันและจากโปรแกรมเมอร์ที่มีอยู่

XP ถือว่า

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

Chapter 2 —Learning to Drive

การขับรถไม่ได้เกี่ยวกับการทำให้รถไปในทิศทางที่ถูกต้อง การขับรถคือการให้ความสนใจอย่างต่อเนื่อง แก้ไขเล็กน้อยด้วยวิธีนี้ แก้ไขเล็กน้อยด้วยวิธีนั้น

นี่คือกระบวนทัศน์สำหรับ XP — รับทราบ ปรับ เปลี่ยน

ทุกอย่างในซอฟต์แวร์มีการเปลี่ยนแปลง

• ข้อกำหนด
• การออกแบบ
• ธุรกิจ
• เทคโนโลยี
• ทีม สมาชิกในทีม

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

ลูกค้าขับเคลื่อนเนื้อหาของระบบ ทีมงานทั้งหมดขับเคลื่อนกระบวนการพัฒนา

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

คุณไม่ต้องรอนานเพื่อดูว่าคุณกำลังไปผิดทางหรือไม่

ลูกค้ามักไม่ทราบแน่ชัดว่า ซอฟต์แวร์ควรทำอะไร

นั่นเป็นเหตุผลว่าทำไมการพัฒนาซอฟต์แวร์จึงเหมือนกับการขับรถ

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

Chapter 3 —Values, Principles, and Practices

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

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

Values เป็นเกณฑ์ขนาดใหญ่ที่เราใช้ในการตัดสินสิ่งที่เราเห็น คิด และทำ

การทำให้ชัดเจนเป็นสิ่งสำคัญ เพราะหากปราศจาก Values การปฏิบัติจะกลายเป็นสิ่งเดิมๆ อย่างรวดเร็ว

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

Practices มีความชัดเจน ทุกคนรู้ว่า ฉันได้เข้าร่วมการประชุมสแตนด์อัพตอนเช้าหรือไม่ ไม่ว่าฉันจะให้ความสำคัญกับการสื่อสารหรือไม่ก็ตาม ไม่ว่าฉันจะรักษาแนวปฏิบัติที่ปรับปรุงการสื่อสารไว้หรือไม่ก็ตาม

• Values นำจุดประสงค์มาสู่ Practices
• Practices ก็นำความรับผิดชอบมาสู่ Values เช่นกัน

Values และ Practices เป็นมหาสมุทรที่แยกจากกัน

• Values เป็นสากล ตามหลักการแล้ว Values ของฉันในขณะที่ทำงานนั้นเหมือนกับ Values ในชีวิตที่เหลือของฉันทุกประการ
• อย่างไรก็ตาม Practices ตั้งอยู่อย่างเข้มข้น ถ้าฉันต้องการคำติชมว่าฉันเขียนโปรแกรมได้ดีหรือไม่ การสร้างและทดสอบซอฟต์แวร์ของฉันอย่างต่อเนื่องก็สมเหตุสมผล
• ถ้าฉันต้องการความคิดเห็นเมื่อฉันเปลี่ยนผ้าอ้อมให้เด็ก การ “สร้างและทดสอบอย่างต่อเนื่อง” นั้นไร้สาระ

Principles เป็นหลักการ อุดมการณ์ เป็นตัวชี้นำ เป็นสะพาน

การเรียนรู้ที่จะเขียนการทดสอบก่อนเขียนโค้ดนั้นมีประโยชน์ ไม่ว่า Values หรือ Practices ของคุณจะเป็นอย่างไร

ลองยกตัวอย่างเพื่อให้เห็นภาพมากขึ้นด้วยสถานการณ์ของตัวเอง (ใช่ไหมนะ?)

• Values การพิชิตเขาสูง
• Principles ร่างกายแข็งแรง ทนต่อการเดินติดต่อกันสิบวันได้ เฉลี่ยวันละ 8 ชั่วโมง ต้องมีอุปกรณ์อะไรบ้าง (itinerary, equipment list)
• Practices เช่น ออกกำลังทุกวัน ทั้งแบบหนักและยืดหยุ่น

Chapter 4 —Values

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

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

ถ้าทุกคนในทีมเลือกที่จะให้ความสำคัญกับสิ่งที่สำคัญสำหรับทีม พวกเขาควรโฟกัสไปที่อะไร?

XP รวบรวมคุณค่าห้าประการ เพื่อเป็นแนวทางในการพัฒนา: การสื่อสาร ความเรียบง่าย คำติชม ความกล้าหาญ และความเคารพ

การสื่อสาร (Communication)

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

เมื่อคุณประสบปัญหา ให้ถามตัวเองว่า ปัญหาเกิดจากการขาดการสื่อสารหรือไม่

• คุณต้องการการสื่อสารอะไรในตอนนี้เพื่อแก้ไขปัญหา
• การสื่อสารใดที่คุณต้องการ เพื่อป้องกันตัวเองจากปัญหานี้ในอนาคต

การสื่อสารมีความสำคัญต่อการสร้างความรู้สึกเป็นทีมและความร่วมมืออย่างมีประสิทธิภาพ

ซึ่งการสื่อสารไม่ใช่ทั้งหมดที่คุณต้องการ สำหรับการพัฒนาซอฟต์แวร์ที่มีประสิทธิภาพ

ความเรียบง่าย (Simplicity)

การทำให้ระบบง่ายพอที่จะแก้ปัญหาของวันนี้ได้ มันยาก

เมื่อคุณต้องการเปลี่ยนแปลงเพื่อให้ได้มาซึ่งความเรียบง่าย คุณต้องหาทางจากจุดที่คุณอยู่ไปสู่จุดที่คุณต้องการ

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

ความเรียบง่าย ทำให้คุณสื่อสารน้อยลงด้วยเช่นกัน

คำติชม (Feedback)

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

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

พอใจกับการปรับปรุงมากกว่าคาดหวังความสมบูรณ์ เราใช้ feedback เพื่อให้เข้าใกล้เป้าหมายของเรามากขึ้น

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

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

ยิ่งรู้เร็ว ยิ่งปรับตัวได้เร็ว

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

ในขณะเดียวกัน ยิ่งระบบเรียบง่ายเท่าใด ก็ยิ่งได้รับคำติชม (feedback) เกี่ยวกับระบบได้ง่ายขึ้นเท่านั้น

ความกล้าหาญ (Courage)

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

การทำอะไรโดยไม่คำนึงถึงผลที่ตามมา ไม่ใช่การทำงานเป็นทีมที่มีประสิทธิภาพ

หากความกล้าหาญเพียงอย่างเดียวเป็นอันตราย การใช้ร่วมกับอย่างอื่น ก็ถือว่ามีพลัง

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

ความเคารพ (Respect)

หากสมาชิกในทีมไม่สนใจซึ่งกันและกันในสิ่งที่พวกเขากำลังทำอยู่ XP จะไม่สามารถเห็นผลได้

• ทุกคนที่พัฒนาซอฟต์แวร์มีค่าเท่าเทียมกันในฐานะมนุษย์ ไม่มีใครมีค่ามากกว่าใคร
• การมีส่วนร่วมของแต่ละคนในทีม จำเป็นต้องได้รับการเคารพ
• ฉันเป็นคนสำคัญ และคุณก็สำคัญเช่นกัน

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

ทีมของคุณ และตัวคุณเองอาจเลือกคุณค่าอื่นๆ ร่วมด้วยได้ เช่น ความปลอดภัย ความมั่นคง การคาดการณ์ได้ และคุณภาพชีวิต

สิ่งที่สำคัญที่สุดคือ การปรับพฤติกรรมของทีมให้สอดคล้องกับค่านิยมของทีม

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

— — — — — โปรดติดตามตอนต่อไป — — — — —