#priwreadbooks Extreme Programming Explained สรุป บทที่ 5–8
Second Edition, Kent Beck with Cynthia Andres
Disclaimer: บทความนี้เป็นการสรุป บทที่ 5–8 ของหนังสือที่ชื่อ Extreme Programming Explained เจ้าของหนังสือคือพี่บอย ส่งมอบมาให้อ่านโดยพี่หนุ่ม ถ้าเขียนงงๆ ไปบ้าง ก็บอกเลยว่า ตอนที่อ่านก็งงเหมือนกัน 55
- อ่านบทความก่อนหน้าได้ที่ Chapter 1–4
Chapter 5 — Principles
Values เป็นนามธรรมเกินกว่าจะชี้นำพฤติกรรมได้โดยตรง จึงต้องมีการใช้หลักการเข้ามาช่วย นี่เป็นตัวอย่างหลักการที่ XP แนะนำ
มนุษยชาติ (Humanity)
คนคือผู้พัฒนาซอฟต์แวร์ ข้อเท็จจริงที่เรียบง่ายและหลีกเลี่ยงไม่ได้ บางครั้งความเป็นมนุษย์ของพวกเขาถูกบดบังด้วยกระบวนการที่ไร้มนุษยธรรม ซึ่งไม่ยอมรับความต้องการของพวกเขา ซึ่งสิ่งนี้ไม่เป็นผลดีต่อธุรกิจเช่นกัน
การเป็นนักพัฒนาที่ดีต้องมีอะไรบ้าง?
- ความปลอดภัยขั้นพื้นฐาน — อิสระจากความหิวโหย การทำร้ายร่างกาย การคุกคามต่อบุคคลอันเป็นที่รัก ความกลัวการสูญเสียงานคุกคามความต้องการนี้
- ความสำเร็จ — โอกาสและความสามารถในการช่วยเหลือสังคม
- ต้องการเข้าหมู่เข้าพวก — ความสามารถในการระบุตัวตนกับกลุ่มที่พวกเขาได้รับการตรวจสอบ ความรับผิดชอบ และนำไปสู่เป้าหมายร่วมกัน
- การเติบโต — โอกาสในการขยายทักษะและมุมมองของพวกเขา
- ความใกล้ชิด — ความสามารถในการเข้าใจ และเข้าใจอย่างลึกซึ้งโดย
คนอื่น
แนวทางปฏิบัติสำหรับ XP มีเพื่อตอบสนองความต้องการทั้งทางธุรกิจและส่วนบุคคล เช่น การพักผ่อน ออกกำลังกาย และการเข้าสังคม ที่ไม่จำเป็นต้องพบเจอในสภาพแวดล้อมการทำงาน
การห่างหายจากทีม ทำให้แต่ละคนมีพลังและมุมมองมากขึ้น และนำพลังนั้นกลับมาสู่ทีม การจำกัดชั่วโมงการทำงาน ช่วยให้มีเวลาสำหรับความต้องการอื่นๆ ของมนุษย์ และเพิ่มการมีส่วนร่วมของแต่ละคนในขณะที่เขาอยู่กับทีม
ส่วนหนึ่งของความท้าทายในการพัฒนาซอฟต์แวร์ของทีมคือ การสร้างสมดุลระหว่างความต้องการของแต่ละบุคคลกับความต้องการของทีม
ความต้องการของทีม อาจช่วยบรรลุเป้าหมายส่วนบุคคลระยะยาวของตัวเราเอง ดังนั้นการเสียสละบางอย่างจึงคุ้มค่า
หากฉันต้องการความเป็นส่วนตัว ฉันมีหน้าที่รับผิดชอบในการหาวิธีตอบสนองความต้องการของฉัน ด้วยวิธีที่ไม่กระทบกระเทือนต่อทีม
ความมหัศจรรย์ของทีมที่ยอดเยี่ยมคือ หลังจากที่สมาชิกในทีม พัฒนาความไว้วางใจแล้ว พวกเขาพบว่า พวกเขามีอิสระที่จะเป็นตัวของตัวเองมากขึ้น อันเป็นผลมาจากการทำงานร่วมกัน
แม้ว่าความใกล้ชิดจะรู้สึกดี แต่ งานก็คืองาน การบอกเล่ารายละเอียดส่วนตัวมากไปทำให้การสื่อสารในทีมสับสน
แนะนำให้แยกการสื่อสารในชีวิตออกเป็น
- เรื่องส่วนตัว ที่ฉันคุยกับคู่ครองเท่านั้น
- เรื่องส่วนตัว ที่ฉันคุยกับคนที่ได้รับความไว้วางใจ
- เรื่องสาธารณะ ที่ฉันไม่รังเกียจที่จะพูดถึงเรื่องนี้กับใคร
การค้นหาว่าเรื่องใดอยู่หมวดใดไม่ใช่เรื่องง่าย และไม่ใช่เรื่องง่ายที่จะคิดออกว่าใครควรได้รับความไว้วางใจ
เศรษฐศาสตร์ (Economics)
ตรวจสอบให้แน่ใจว่าสิ่งที่คุณทำมีมูลค่าทางธุรกิจ บรรลุเป้าหมายทางธุรกิจ ตอบสนองความต้องการทางธุรกิจ ตัวอย่างเช่น การแก้ปัญหาความต้องการทางธุรกิจที่มีลำดับความสำคัญสูงสุดก่อน จะเพิ่มมูลค่าสูงสุดให้กับโครงการ
การพัฒนาซอฟต์แวร์จะมีค่ามากกว่าเมื่อได้เงินเร็วและใช้เงินทีหลัง การจ่ายต่อการใช้งาน เป็นวิธีสร้างรายได้จากคุณสมบัติต่างๆ ทันทีที่มีการปรับใช้
แหล่งที่มาของมูลค่าทางเศรษฐกิจอีกประการหนึ่งในการพัฒนาซอฟต์แวร์คือ มูลค่าที่เป็นทางเลือกสำหรับอนาคต ถ้าฉันสามารถปรับใช้โปรแกรมการจัดตารางเวลาสื่อของฉันใหม่สำหรับงานต่างๆ ที่เกี่ยวข้องกับการจัดตารางเวลาได้ มันจะมีค่ามากกว่าที่จะใช้ได้เฉพาะตามวัตถุประสงค์ที่ตั้งใจไว้แต่แรกเท่านั้น
ผลประโยชน์ร่วม (Mutual Benefit)
ทุกกิจกรรมควรมีประโยชน์ต่อทุกฝ่ายที่เกี่ยวข้อง ทั้งปัจจุบันและอนาคต
ผลประโยชน์ร่วมกัน เป็นหลัก XP ที่สำคัญที่สุดและยากที่สุดที่จะปฏิบัติตาม
XP แก้ปัญหาการสื่อสารกับอนาคตด้วยวิธีที่เป็นประโยชน์ดังนี้
- ฉันเขียนการทดสอบอัตโนมัติ ที่ช่วยให้ฉันออกแบบและใช้งานได้ดีขึ้นในวันนี้
- ฉันให้การทดสอบเหล่านี้กับโปรแกรมเมอร์ในอนาคตที่จะใช้เช่นกัน แนวทางปฏิบัตินี้เป็นประโยชน์ต่อฉันในตอนนี้ และผู้ดูแลต่อในอนาคต
- ฉันทำการ Refactor อย่างรอบคอบ เพื่อขจัดความซับซ้อน ทำให้ฉันพึงพอใจ มีข้อบกพร่องน้อยลง และทำให้โค้ดเข้าใจได้ง่ายขึ้นสำหรับผู้ที่มาอ่านในภายหลัง
- ฉันเลือกชื่อจาก coherent and explicit set of metaphors (หมายเหตุ: แปลไม่ถูกจริงๆ ตรงนี้) ซึ่งช่วยเร่งการพัฒนาของฉันและทำให้โค้ดชัดเจนขึ้นสำหรับโปรแกรมเมอร์คนใหม่
หากคุณต้องการให้คนอื่นรับฟังคำแนะนำของคุณ
คุณต้องแก้ปัญหา มากกว่าที่คุณสร้างปัญหา
ผลประโยชน์ร่วมกันใน XP คือ การค้นหาวิธีปฏิบัติที่ให้ประโยชน์แก่ฉันในตอนนี้ ต่อฉันในภายหลัง และลูกค้าของฉันด้วย
แนวทางปฏิบัติแบบ win-win-win นั้นขายง่ายกว่า เพราะช่วยบรรเทาความเจ็บปวดที่เกิดขึ้นทันที ตัวอย่างเช่น คนที่ต่อสู้กับ Defect ที่ยาก ก็พร้อมที่จะเรียนรู้การเขียนการทดสอบก่อน
เมื่อมันมีประโยชน์กับฉันในตอนนี้ มันง่ายกว่าที่จะยอมรับการทำบางสิ่ง เพื่อช่วยผู้อื่นทั้งในปัจจุบันและอนาคต
ความคล้ายคลึงกันในตนเอง (Self-Similarity)
จังหวะพื้นฐานของการพัฒนา คือการที่คุณเขียนแบบทดสอบที่ล้มเหลว (fail) แล้วคุณก็เขียนโค้ดทำให้มันสำเร็จ (success)
- ในไตรมาสหนึ่ง คุณเขียนหัวข้อที่คุณต้องการกล่าวถึง
- กล่าวถึงประเด็นเหล่านั้นด้วยเรื่องราว
- ในหนึ่งสัปดาห์ คุณเขียนรายการเรื่องราวที่คุณต้องการจัดการ
- เขียนการทดสอบ ที่แสดงเรื่องราว แล้วทำให้มันได้ผล
- ในอีกไม่กี่ชั่วโมง คุณจะทำรายการการทดสอบที่คุณรู้ว่าต้องเขียน จากนั้นเขียนการทดสอบ ทำให้มันใช้งานได้
- เขียนการทดสอบอีกชุดหนึ่ง และทำให้ทั้งสองการทดสอบทำงาน จนกว่ารายการจะเสร็จ
Self-Similarity ไม่ใช่หลักการเดียวที่ใช้ได้ผลในการพัฒนาซอฟต์แวร์
เพียงเพราะคุณคัดลอกโครงสร้างที่ทำงานได้ในบริบทหนึ่ง ไม่ได้หมายความว่าโครงสร้างนั้นจะทำงานในบริบทอื่นได้
ตามความเข้าใจของตัวเองคือ เราสามารถเอา Process/Theme การทำงานจากที่แรก ไปใช้กับที่ๆ สองได้ แต่ไม่สามารถเอา Code ชุดนั้นไปใช้กับที่อื่นได้ เพราะมันคนละบริบทกัน — Coding Dojo เพราะการทำซ้ำ ทำให้เราเชี่ยวชาญขึ้น
การปรับปรุง (Improvement)
ในการพัฒนาซอฟต์แวร์ ไม่มีกระบวนการใดที่สมบูรณ์แบบ ไม่มีการออกแบบที่สมบูรณ์แบบ ไม่มีเรื่องราวใดที่สมบูรณ์แบบ อย่างไรก็ตาม คุณสามารถทำให้กระบวนการ การออกแบบ และเรื่องราวของคุณสมบูรณ์แบบได้
การทำวันนี้ให้ดีที่สุด มุ่งมั่นเพื่อการรับรู้และความเข้าใจที่จำเป็นในการทำสิ่งที่ดีกว่าในวันพรุ่งนี้ ไม่ได้หมายถึงการรอคอยความสมบูรณ์แบบเพื่อเริ่มต้น
หลักการของการปรับปรุง แสดงให้เห็นในแนวทางปฏิบัติที่ทำให้กิจกรรมเริ่มต้นทันที แต่ปรับแต่งผลลัพธ์เมื่อเวลาผ่านไป
การออกแบบที่แท้จริง ไม่ใช่ภาพสะท้อนที่สมบูรณ์แบบตามอุดมคติ แต่คุณสามารถพยายามทุกวันเพื่อให้ทั้งสองเข้าใกล้กันได้
ปรับปรุงการทำงานโดยไม่รอความสมบูรณ์แบบ ค้นหาจุดเริ่มต้น เริ่มต้นและปรับปรุงจากจุดนั้น
ความหลากหลาย (Diversity)
ทีมต้องการความหลากหลาย ความขัดแย้งเป็นสิ่งที่หลีกเลี่ยงไม่ได้ของความหลากหลาย แต่ไม่ใช่ความขัดแย้งกันจริงๆ ในความหมาย
นำเสนอโอกาส ไม่ใช่ปัญหา
หลักการของความหลากหลาย แนะนำว่า โปรแกรมเมอร์ควรทำงานร่วมกันในปัญหาที่เกิด และควรให้คุณค่ากับความคิดเห็นทั้งสองฝ่าย เพื่อให้เกิดไอเดีย เห็นวิธีแก้ปัญหา
การเคารพผู้อื่น เคารพตัวเอง ทำให้การสื่อสารเป็นไปอย่างราบรื่นในช่วงเวลาที่ตึงเครียด
ความหลากหลาย แสดงออกมาในแนวปฏิบัติของทั้งทีม ซึ่งคุณรวบรวมคนที่มีทักษะและมุมมองที่หลากหลายมารวมกันในทีม รอบการวางแผนต่างๆ กระตุ้นให้ผู้คนที่มีมุมมองต่างกันโต้ตอบกับเป้าหมายในการสร้างซอฟต์แวร์ที่มีค่ามากที่สุดเท่าที่จะเป็นไปได้ในเวลาที่มีอยู่
การหยุดเพื่อไตร่ตรอง ส่องกระจกดูตัวเอง (Reflection)
ทีมที่ดีไม่เพียงแค่ทำงานของพวกเขา พวกเขาคิดว่า พวกเขาทำงานอย่างไร และทำไม
วิเคราะห์ว่า ทำไมพวกเขาถึงประสบความสำเร็จหรือล้มเหลว พวกเขาไม่พยายามซ่อนความผิดพลาด แต่เปิดเผยและเรียนรู้
การรับประทานอาหารร่วมกันและช่วงพักดื่มกาแฟ เป็นบรรยากาศที่ไม่เป็นทางการสำหรับการหยุดเพื่อไตร่ตรอง ทบทวนร่วมกัน
คุณสามารถได้รับข้อมูลเชิงลึกโดยการวิเคราะห์ข้อมูล และคุณสามารถเรียนรู้จากอารมณ์ “เชิงลบ” เช่น ความกลัว ความโกรธ และความวิตกกังวล สิ่งเหล่านี้ เป็นตัวบ่งบอกมานานแล้วว่า สิ่งเลวร้ายกำลังจะเกิดขึ้น
ต้องใช้ความพยายามในการฟังว่าอารมณ์ของคุณบอกอะไรเกี่ยวกับงานของคุณ
Reflection เกิดขึ้นหลังการกระทำ
การเรียนรู้คือ Reflection
ผสมผสานกับการลงมือทำเพื่อเพิ่มข้อมูล Reflection
ถ้า Reflection คือ XP ใน Scrum ก็น่าจะเป็น Retrospective ล่ะนะ
ความลื่นไหล (Flow)
ความลื่นไหลในการพัฒนาซอฟต์แวร์คือการส่งมอบซอฟต์แวร์ที่มีคุณค่าอย่างต่อเนื่อง โดยการมีส่วนร่วมในกิจกรรมทั้งหมดของการพัฒนาพร้อมๆ กัน
ยิ่งมีการเลื่อนเวลาการส่งมอบออกไปมากเท่าไร ก้อนใหญ่ขึ้น ความเสี่ยงก็จะยิ่งสูงขึ้นเท่านั้น
หลักการของความลื่นไหลแนะนำว่า สำหรับการปรับปรุง ให้ปรับใช้การเพิ่มมูลค่าทีละน้อยให้บ่อยขึ้น
เมื่อใดก็ตามที่คุณถอยห่างจากความลื่นไหล ให้ตัดสินใจแก้ไขปัญหาที่ทำให้ความลื่นไหลของคุณหยุดชะงัก และกลับไปปรับใช้การทำงานระดับรายสัปดาห์โดยเร็วที่สุด
โอกาส (Opportunity)
เรียนรู้ที่จะมองปัญหาเป็นโอกาสในการเปลี่ยนแปลง ตามทัศนคติของ “การอยู่รอด” นำไปสู่การแก้ปัญหาที่เพียงพอ เพื่อไปสู่ความเป็นเลิศ
การเปลี่ยนปัญหาให้เป็นโอกาสเกิดขึ้นตลอดกระบวนการพัฒนา ช่วยเพิ่มจุดแข็งและลดจุดอ่อนให้เหลือน้อยที่สุด ซึ่งสอดคล้องกับแผนในระยะยาวว่าให้ Value อะไรกับผู้ใช้งาน
เมื่อคุณเริ่มฝึก XP คุณจะพบกับปัญหาอย่างแน่นอน ค่อยๆ เลือกที่จะเปลี่ยนแต่ละปัญหาให้เป็นโอกาสอย่างมีสติ
โอกาสสำหรับการเติบโตส่วนบุคคล ความสัมพันธ์ที่ลึกซึ้งยิ่งขึ้น และซอฟต์แวร์ที่ได้รับการปรับปรุง
ความซ้ำซ้อน (Redundancy)
ความซ้ำซ้อน เป็นปัญหาที่สำคัญและยากในการพัฒนาซอฟต์แวร์ ควรได้รับการแก้ไข
ใน XP มีวิธีปฏิบัติหลายอย่าง เช่น pair programming, continuous integration, sitting together, real customer involvement, and daily deployment จะช่วยลดเรื่องความซ้ำซ้อนลงได้
คุณไม่สามารถแก้ปัญหาข้อบกพร่องได้ด้วยการปฏิบัติเพียงครั้งเดียว
แม้ว่าความซ้ำซ้อนอาจสิ้นเปลือง แต่ระวัง อย่ากำจัดความซ้ำซ้อนที่ตอบสนองวัตถุประสงค์ที่ถูกต้อง
การทดสอบหลังจากการพัฒนาเสร็จสิ้นควรซ้ำซ้อน อย่างไรก็ตาม ทำการกำจัดมันออกเฉพาะเมื่อได้รับการพิสูจน์แล้วว่าซ้ำซ้อนในทางปฏิบัติ และไม่พบข้อบกพร่องใดๆ ในการใช้งาน
ความล้มเหลว (Failure)
หากคุณประสบปัญหาในการประสบความสำเร็จ จงล้มเหลว
แม้ว่าคุณจะล้มเหลว แต่คุณก็จะได้เรียนรู้สิ่งที่มีค่าอย่างแน่นอน
มันคือส่วนหนึ่งของการเรียนรู้และเติบโต
เอาเวลาไปเขียนโค้ด แล้วให้พบกับความล้มเหลว ดีกว่านั่งคุยกันไปเรื่อยๆ
เมื่อคุณไม่รู้ว่าต้องทำอะไร การเสี่ยงกับความล้มเหลวอาจเป็นหนทางสู่ความสำเร็จที่สั้นที่สุดและแน่นอนที่สุด
ถ้าให้เรารู้สึก คือประโยคของ Startup ที่ฮิตๆ กันว่า ‘fail fast learn fast’
คุณภาพ (Quality)
โครงการไม่ได้ส่งมอบเร็วขึ้นด้วยการยอมรับคุณภาพที่ต่ำลง พวกเขาไม่ได้ทำงานช้าลงด้วยความต้องการคุณภาพที่สูงขึ้น
- การผลักดันคุณภาพให้สูงขึ้น มักส่งผลให้จัดส่งเร็วขึ้น
- ในขณะที่มาตรฐานคุณภาพที่ต่ำลง มักส่งผลให้มีการส่งมอบได้ช้าลง และคาดการณ์ได้น้อยลง
คุณภาพไม่ใช่ปัจจัยเพียงอย่างเดียว ผู้คนจำเป็นต้องทำงานที่พวกเขาภาคภูมิใจ
XP ใช้การกำหนดขอบเขต ในการวางแผน ติดตาม และขับเคลื่อนโครงการ เนื่องจากไม่เคยรู้ขอบเขตล่วงหน้าอย่างแม่นยำ ก็เลยทำเป็นรอบรายสัปดาห์และรายไตรมาสให้ชัดเจน
ความกังวลเกี่ยวกับคุณภาพ ไม่ใช่ข้อแก้ตัวสำหรับการเพิกเฉย
- หากคุณไม่รู้วิธีการทำโค้ดให้สะอาดในงานที่ต้องทำให้เสร็จ ให้ทำอย่างดีที่สุดเท่าที่จะทำได้
- หากคุณรู้วิธี แต่ใช้เวลานานเกินไป ให้ทำงานนี้และแก้ไขโค้ดให้สะอาดในภายหลัง
สิ่งนี้มักเกิดขึ้นในช่วงวิวัฒนาการทางสถาปัตยกรรม ซึ่งคุณต้องใช้ชีวิตร่วมกับสถาปัตยกรรมสองแห่งเพื่อแก้ปัญหาเดียวกัน ในขณะที่คุณเปลี่ยนจากสถาปัตยกรรมหนึ่งไปอีกสถาปัตยกรรมหนึ่ง จากนั้นการเปลี่ยนแปลงจะกลายเป็น การแสดงให้เห็นถึงคุณภาพ
ก้าวทีละนิดแบบเด็กน้อย (Baby Steps)
การเปลี่ยนแปลงครั้งใหญ่ในขั้นตอนใหญ่ๆ มักจะดึงดูดใจอยู่เสมอ ท้ายที่สุดแล้ว ยังมีหนทางอีกยาวไกลและเวลาอันสั้นที่จะไปถึงที่นั่น
การเปลี่ยนแปลงครั้งสำคัญ ที่เกิดขึ้นพร้อมกัน เป็นสิ่งที่อันตราย
ทีมสามารถก้าวเล็กๆ หลายๆ ก้าว อย่างรวดเร็ว จนดูเหมือนกำลังก้าวกระโดดได้
Baby steps ทำให้ค่าใช้จ่ายในการดำเนินการของขั้นตอนเล็กๆ นั้นถูกกว่า เมื่อเทียบกับการถอยกลับอย่างเปล่าประโยชน์จากการยกเลิกการเปลี่ยนแปลงครั้งใหญ่
ขั้นตอนเล็กๆ นี้ แสดงออกมาในแนวทางปฏิบัติ เช่น การเขียนการทดสอบก่อนเขียนโปรแกรม ทำการทดสอบครั้งละหนึ่งรายการ บูรณาการอย่างต่อเนื่อง และเสร็จในเวลาไม่กี่ชั่วโมง
มีความรับผิดชอบในสิ่งที่ได้รับ (Accepted Responsibility)
ถ้ามีคนพยายามให้คุณรับผิดชอบ มีเพียงคุณเท่านั้นที่ตัดสินใจได้ว่า คุณจะรับผิดชอบหรือไม่
บุคคลที่รับผิดชอบในการนำเรื่องราวไปทำ จะต้องรับผิดชอบในการออกแบบ การนำไปใช้ และการทดสอบ
ความรับผิดชอบมาพร้อมกับอำนาจ การไม่ได้เดินไปในแนวทางเดียวกันทำให้การสื่อสารของทีมผิดเพี้ยนไป รวมถึงยังมีเรื่องของอารมณ์เข้ามาเกี่ยวข้องด้วย
เมื่อผู้เชี่ยวชาญด้านกระบวนการบอกฉันถึงวิธีการทำงาน แต่ไม่ได้มีส่วนร่วมในงานนั้นหรือผลที่ตามมา อำนาจหน้าที่และความรับผิดชอบจะไม่สอดคล้องกัน
บทสรุป
คุณสามารถใช้หลักการเพื่อทำความเข้าใจแนวปฏิบัติให้ดีขึ้นและเพื่อปรับแนวปฏิบัติเสริมเมื่อคุณไม่พบแนวทางที่เหมาะกับวัตถุประสงค์ของคุณ
หลักการต่างๆ ช่วยให้คุณเข้าใจได้ดีขึ้นว่า การปฏิบัตินั้นมีวัตถุประสงค์เพื่อบรรลุผลสำเร็จอย่างไร
คุณจะสร้างแนวปฏิบัติใหม่เป็นครั้งคราว เพื่อตอบสนองความต้องการเฉพาะของคุณ การเข้าใจหลักการ เปิดโอกาสให้คุณสร้างแนวปฏิบัติที่สอดคล้องกับแนวปฏิบัติที่มีอยู่และเป้าหมายโดยรวมของคุณ
Chapter 6 — Practices
หลังจากนี้จะเป็นแนวทางปฏิบัติของ XP ซึ่งเป็นสิ่งที่คุณเห็นทีม XP ทำในแต่ละวัน
การปฏิบัติขึ้นอยู่กับสถานการณ์ หากสถานการณ์เปลี่ยนไป คุณเลือกวิธีปฏิบัติที่แตกต่างกัน เพื่อให้ตรงตามเงื่อนไขเหล่านั้น เมื่อเปลี่ยนโดเมน Principles บางอย่างอาจถูกเรียกมาใช้ ซึ่ง Values ของคุณอาจจะเปลี่ยน หรือไม่จำเป็นต้องเปลี่ยน เพื่อปรับตัวให้เข้ากับสถานการณ์ใหม่
ใน XP คุณจะก้าวไปสู่สถานะการพัฒนาที่มีประสิทธิภาพ ถ้าคุณ Deploy ปีละครั้ง การทำ Daily-Deployment อาจไม่สมเหตุสมผล การ Deploy บ่อยขึ้นก่อให้เกิดการปรับปรุง สร้างความมั่นใจในขั้นต่อไป
ทำ Primary ให้ดีก่อน แล้วค่อยไปต่อที่ Corollary
แนวปฏิบัติของ XP ทั้งหมด มักจะทำงานร่วมกันได้ดี เริ่มปรับใช้ ดำเนินการทีละครั้งคุณจะเห็นการปรับปรุง เมื่อพวกเขาเริ่มเอาหลาย Practices มารวมกัน คุณอาจเห็นการปรับปรุงเป็นอย่างมาก
Chapter 7 — Primary Practices
ในบทนี้จะเป็นแนวทางปฏิบัติที่คุณสามารถเริ่มต้นทำได้ สิ่งใดที่คุณควรใช้ก่อนนั้นขึ้นอยู่กับสภาพแวดล้อมของคุณ และสิ่งที่คุณมองว่าเป็นโอกาสที่ใหญ่ที่สุดในการปรับปรุง
Sit Together นั่งด้วยกัน
หาพื้นที่เปิดโล่งที่ใหญ่พอสำหรับทั้งทีม มีพื้นที่ของทีม และพื้นที่ที่เป็นส่วนตัวขนาดเล็กในบริเวณใกล้เคียง โดยการจำกัดชั่วโมงการทำงานในพื้นที่นั้น
ไม่ว่าลูกค้าจะบอกว่าปัญหาคืออะไร มันก็คือปัญหาของผู้คนเสมอ การแก้ไขทางเทคนิคเพียงอย่างเดียวไม่เพียงพอ การนั่งด้วยกันเพื่อสื่อสารด้วยประสาทสัมผัสทั้งหมดของเรานั้นจึงมีความสำคัญ
หากทีมรู้สึกปลอดภัยในที่ของตัวเอง การรื้อผนังกั้น การกำจัดความรู้สึกปลอดภัยนั้นออก มีแนวโน้มที่จะก่อให้เกิดความไม่พอใจและการต่อต้าน
ทีมที่รู้ว่าความใกล้ชิดช่วยเพิ่มการสื่อสารและได้เรียนรู้คุณค่าของการสื่อสาร จะเปิดพื้นที่ของตนเองออก
มีการคาดการณ์ว่ายิ่งคุณมีเวลาเผชิญหน้ากันมากขึ้น โปรเจกต์ก็ยิ่งมีความเป็นมนุษย์มากขึ้น ประสิทธิผลมากขึ้น
หากคุณมีโปรเจ็กต์หลายไซต์และทุกอย่างเป็นไปได้ด้วยดี ให้ทำในสิ่งที่คุณกำลังทำอยู่ หากคุณมีปัญหา ให้คิดหาวิธีที่จะนั่งด้วยกันให้มากขึ้น แม้ว่าจะหมายถึงการเดินทางก็ตาม
Whole Team ทั้งทีม
รวมคนในทีมที่มีทักษะและมุมมองทั้งหมดที่จำเป็น เพื่อให้โครงการประสบความสำเร็จ นี่เป็นอะไรมากไปกว่าแนวคิดแบบเก่าของทีมข้ามสายงาน
ความรู้สึกของความเป็นหนึ่งเดียว ความพร้อมของทรัพยากรทั้งหมดที่จำเป็นต่อความสำเร็จ
ความรู้สึกของการเป็น “ทีม”
- เราเป็นของเรา
- เราอยู่ในนี้ด้วยกัน
- เราสนับสนุนการทำงาน การเติบโต และการเรียนรู้ของกันและกัน
สิ่งที่ประกอบกันเป็น “ทั้งทีม” มีความปราดเปรียว หากทักษะหรือทัศนคติชุดหนึ่งมีความสำคัญ ให้นำบุคคลที่มีทักษะเหล่านี้มาร่วมทีม ถ้าใครหมดความจำเป็น ก็ไปที่อื่นก็ได้
The Tipping Point โดย Malcolm Gladwell — ขนาดทีมในอุดมคติ คือ 12 คน ที่สามารถมีปฏิสัมพันธ์กันได้อย่างสบายในหนึ่งวัน (ไม่ใช่ 150 คน เพราะจำหน้ากันยังไม่ได้ด้วยซ้ำ) ก่อให้เกิดความไว้วางใจ ซึ่งเป็นสิ่งจำเป็นสำหรับการทำงานร่วมกัน
สำหรับโครงการขนาดใหญ่ ค้นหาวิธีแยกปัญหา เพื่อให้สามารถแก้ไขได้โดยทีมหลายทีม ช่วยให้ XP ขยายขนาดได้
บางองค์กรพยายามที่จะแบ่งงานของทีมออกเป็นส่วนๆ เช่น คุณจะใช้เวลา 40% ในการทำงานให้กับลูกค้า A และ 60% ทำงานให้กับลูกค้า B การสลับงานไปมาคือการเสียเวลา (ตั้งสติ) ทำลายความรู้สึกของการเป็น “ทีม” และสร้างการต่อต้าน
Informative Workspace พื้นที่ทำงานที่มีข้อมูล
สร้างพื้นที่ทำงานที่ผู้สังเกตการณ์ที่สนใจควรเดินเข้าไปในพื้นที่ของทีมและรับทราบแนวคิดทั่วไปว่า โครงการดำเนินไปอย่างไรภายในสิบห้าวินาที และสามารถรับข้อมูลเพิ่มเติมเกี่ยวกับปัญหาที่เกิดขึ้นแล้ว หรือที่อาจเกิดขึ้นได้โดยการมองอย่างใกล้ชิดมากขึ้น
พื้นที่ทำงาน ยังจำเป็นต้องจัดเตรียมไว้สำหรับความต้องการอื่นๆ ของมนุษย์อีกด้วย เช่น น้ำ ของว่าง ความสะอาดและความเป็นระเบียบ
ในขณะที่การเขียนโปรแกรมเกิดขึ้นในพื้นที่สาธารณะ คนก็ต้องการความเป็นส่วนตัวเช่นกัน ซึ่งสามารถจัดเตรียม คิวบ์แยก (ฉากกั้น) ต่างหาก หรือโดยการจำกัดชั่วโมงการทำงาน
การใช้งานพื้นที่ทำงานที่ให้ข้อมูลอีกอย่างหนึ่งคือ แผนภูมิขนาดใหญ่ที่มองเห็นได้ หากคุณมีปัญหาที่ต้องการความคืบหน้าอย่างต่อเนื่อง ให้เริ่มสร้างแผนภูมิ เมื่อปัญหาได้รับการแก้ไขแล้ว หรือหากแผนภูมิหยุดอัปเดต ให้ลบออก
ใช้พื้นที่ของคุณ สำหรับข้อมูลสำคัญที่ใช้งานอยู่เท่านั้น
จากเรื่องนี้ทำให้นึกถึงคลิปของ IDEA Shopping Cart
Energized Work การทำงานที่มีพลัง
ทำงานให้มากที่สุด เท่าที่คุณจะทำได้อย่างต่อเนื่อง การเผา (งาน) ตัวเองอย่างไม่เกิดผลในวันนี้ ทำให้งานในอีกสองวันข้างหน้าเสีย ไม่ดีต่อคุณหรือทีม
เมื่อคุณป่วย ให้เคารพตัวเองและคนในทีมด้วยการพักผ่อนและหายป่วย การดูแลตัวเองเป็นวิธีที่เร็วที่สุดในการกลับไปทำงานอย่างกระปรี้กระเปร่า การป่วยไม่ได้แสดงถึงความมุ่งมั่นในการทำงาน เพราะเมื่อคุณป่วย คุณไม่ได้ช่วยทีม
คุณสามารถปรับปรุงชั่วโมงการทำงานได้ทีละน้อย อยู่ที่ทำงานเท่าเดิมแต่บริหารเวลาได้ดีขึ้น เช่น Block Time 2 ชั่วโมง เพื่อเขียนโค้ด ปิดการแจ้งเตือนทางโทรศัพท์และอีเมล
Pair Programming เขียนโปรแกรมคู่กัน
เขียนโปรแกรมโดยมีคนสองคนนั่งอยู่ที่เครื่องเดียวกัน เลื่อนแป้นพิมพ์และเมาส์ไปมาเพื่อให้คุณรู้สึกสบายขณะพิมพ์
Pair Programming เป็นการโต้ตอบระหว่างคนสองคนพร้อมกันในการเขียนโปรแกรม (และวิเคราะห์ และออกแบบ และทดสอบ) และพยายามเขียนโปรแกรมให้ดียิ่งขึ้น
ทั้งสองคนจะช่วยกันทำงาน ระดมสมอง ขัดเกลาระบบ ชี้แจงความคิด คอยริเริ่มเมื่อคู่ของพวกเขาติดขัด ซึ่งจะช่วยลดความคับข้องใจ เพิ่มความรับผิดชอบต่อการปฏิบัติของทีมซึ่งกันและกัน
ผู้คนต้องการทั้งความเป็นเพื่อนและความเป็นส่วนตัว หากคุณต้องการทำงานคนเดียว ลงมือทำเลย จากนั้นกลับมาตรวจสอบกับทีมของคุณ เมื่อคุณสำรวจหาวิธีการทำงานเสร็จแล้ว ให้นำแนวคิดที่สร้างผลลัพธ์กลับมาที่ทีม (ไม่ใช่โค้ด) ผลลัพธ์จะเป็นที่เข้าใจกันอย่างกว้างขวางมากขึ้นและเป็นประโยชน์ต่อโครงการโดยรวม
- โปรแกรมเมอร์ส่วนใหญ่ไม่สามารถจับคู่ได้นานกว่าห้าหรือหกชั่วโมงในหนึ่งวัน
- สลับคู่บ่อยๆ บางทีมรายงานผลลัพธ์ที่ดีโดยปฏิบัติตามตัวจับเวลาที่บอกให้เปลี่ยนคู่ทุกๆ หกสิบนาที (หรือ ทุกๆ สามสิบนาที เมื่อแก้ปัญหายากๆ)
ข้อควรระวัง
- บุคคลและวัฒนธรรมที่แตกต่างกัน การจับคู่กับชาวอิตาลีที่สื่อสารได้ดีที่สุดเมื่ออยู่ใกล้กันนั้น แตกต่างอย่างสิ้นเชิงกับการจับคู่กับชาวเดนมาร์กที่ชอบพื้นที่ส่วนตัว
- สุขอนามัยส่วนบุคคลและสุขภาพเป็นเรื่องสำคัญ ปิดปากของคุณเมื่อคุณไอ อย่ามาทำงานเมื่อคุณป่วย หลีกเลี่ยงโคโลญจน์กลิ่นแรง
- การทำงานกับบุคคลเพศตรงข้ามอาจทำให้เกิดความรู้สึกทางเพศที่ไม่เป็นประโยชน์สูงสุดต่อทีม หากความรู้สึกเหล่านี้เกิดขึ้นเมื่อจับคู่ ให้หยุดจับคู่กับบุคคลนั้นจนกว่าคุณจะรับผิดชอบและจัดการกับความรู้สึกของคุณ หากคุณต้องการมีความสัมพันธ์ใกล้ชิด คุณคนใดคนหนึ่งควรออกจากทีม เพื่อที่คุณจะได้สร้างความสัมพันธ์ส่วนตัวในสภาพแวดล้อมส่วนตัว โดยไม่ทำให้การสื่อสารของทีมสับสน
- เคารพความแตกต่างระหว่างบุคคล
- หากคุณไม่สบายใจที่จะจับคู่กับใครบางคนในทีม ให้พูดคุยกับคนที่คุณรู้สึกปลอดภัย สมาชิกในทีมที่น่านับถือ ผู้จัดการ หรือบุคคลในฝ่ายทรัพยากรบุคคล หากคุณไม่สบายใจ แสดงว่าทีมยังทำได้ไม่ดีเท่าที่ควร และมีโอกาสที่คนอื่นจะไม่สบายใจเช่นกัน
Stories เรื่องราว (ที่จะถูกนำไปพัฒนา)
วางแผนการพัฒนาเรื่องราวโดยใช้สิ่งที่ลูกค้าสามารถมองเห็นและทำความเข้าใจได้ เช่น
- รับ traffic ได้ 5 เท่า ด้วยเวลาตอบสนองเท่าเดิม
- ให้มีการคลิกแค่สองครั้งสำหรับผู้ใช้ ในการโทรไปยังหมายเลขที่ใช้บ่อย
“ความต้องการ” (Requirements) มักโดนนิยามว่า “เป็นสิ่งที่จำเป็นหรือบังคับ” มีความหมายแฝงของความคงทนถาวร ไม่สามารถเปลี่ยนแปลงได้ ถ้าคุณได้รับเอกสารมา 1,000 หน้า แล้วบอกว่าสิ่งนี้คือ Requirements เอาจริงๆ แก่นที่ดึงมาปรับใช้กับระบบ อาจจะมีแค่ 20% หรือ 10% หรือ 5% คุณก็จะรับรู้ถึงผลประโยชน์ทางธุรกิจทั้งหมดที่คาดการณ์ไว้สำหรับระบบทั้งหมดแล้ว
แล้วอีก 80% ที่เหลือล่ะ?
มันไม่ใช่ “Requirements” เพราะมันไม่ได้จำเป็น
ทันทีที่เขียนเรื่องราว ให้พยายามประมาณการ (estimate) ความพยายามในการพัฒนา (effort) ติดไปด้วย
การประมาณการ เปิดโอกาสให้คนจากฝั่งธุรกิจและคนจากทางฝั่งเทคนิคโต้ตอบกัน ทั้งฝั่ง business value ที่จะได้ และ effort ที่ต้องทำ ซึ่งเป็นการสร้างมูลค่าตั้งแต่เนิ่นๆ เมื่อทีมทราบต้นทุน ก็สามารถแยก รวม หรือขยายขอบเขต ตามสิ่งที่ทราบเกี่ยวกับ value ของ feature ได้
นอกเหนือจากประโยคอธิบายสั้นๆ หรือภาพกราฟิก ให้เขียนเรื่องราวลงในการ์ดและติดไว้บนกำแพงที่มีคนผ่านบ่อย
หากคุณต้องการรายงานความคืบหน้าไปยังส่วนอื่นๆ ขององค์กรในรูปแบบที่คุ้นเคย ก็แค่เปลี่ยนการ์ดให้อยู่ในรูปแบบนั้นเรื่อยๆ
คุณลักษณะหนึ่งของการวางแผนแบบ XP คือ เรื่องราวต่างๆ จะถูกประเมินตั้งแต่แรกๆ สิ่งนี้ทำให้ทุกคนนึกถึงวิธีการได้รับผลตอบแทนสูงสุดจากการลงทุนที่น้อยที่สุด
ถ้ามีคนถามว่าต้องการเฟอร์รารี่หรือมินิแวน คนปกติก็เลือกเฟอร์รารี่ อย่างไรก็ตาม ทันทีที่มีคนพูดว่า “คุณต้องการ Ferrari ราคา $150,000 หรือรถมินิแวนราคา $25,000” ฉันจะตัดสินใจอย่างไตร่ตรองมากขึ้น
การเพิ่มข้อจำกัด เช่น “ฉันต้องบรรทุกเด็กห้าคน” หรือ “ต้องวิ่ง 150 ไมล์ต่อชั่วโมง” ทำให้ภาพชัดเจนยิ่งขึ้น ในการเลือกรถยนต์อย่างชาญฉลาด คุณจำเป็นต้องรู้ข้อจำกัดของคุณ ทั้งค่าใช้จ่ายและจุดประสงค์ในการใช้งาน
Weekly Cycle แพลนระดับสัปดาห์
วางแผนการทำงานสัปดาห์ละครั้ง มีการประชุมทุกต้นสัปดาห์
ระหว่างการประชุมนี้:
- ทบทวนความคืบหน้าจนถึงปัจจุบัน รวมถึงความคืบหน้าจริงของสัปดาห์ก่อนหน้า ว่าตรงกับความคืบหน้าที่คาดไว้อย่างไร
- ให้ลูกค้าเลือก Stories (ที่มีมูลค่า) เพื่อนำไปพัฒนาในสัปดาห์นี้
- แบ่งเรื่องราวออกเป็น Tasks สมาชิกในทีม เลือก Tasks และประเมินงาน
เริ่มต้นสัปดาห์ด้วยการเขียนการทดสอบอัตโนมัติ ที่จะทำงานเมื่อเรื่องราวเสร็จสิ้น จากนั้นใช้เวลาที่เหลือของสัปดาห์เพื่อจบเรื่องราวและทำแบบทดสอบให้ผ่าน
เป้าหมายคือ การมีซอฟต์แวร์ที่ใช้งานได้ในปลายสัปดาห์ ซึ่งทุกคนสามารถฉลองความคืบหน้าได้
สิ่งที่ดีเกี่ยวกับหนึ่งสัปดาห์แทนที่จะเป็นสองหรือสามสัปดาห์ คือทุกคนจดจ่ออยู่กับวันศุกร์ หากคุณไปถึงวันพุธและเป็นที่ชัดเจนว่า การทดสอบทั้งหมดจะไม่ผ่าน เรื่องราวจะไม่เสร็จสมบูรณ์ ไม่พร้อมที่จะใช้งาน คุณยังมีเวลาเหลือที่จะเลือกเรื่องราวที่มี Value ที่สุดและดำเนินการให้เสร็จสิ้น
บางคนชอบที่จะเริ่มต้นสัปดาห์ในวันอังคารหรือวันพุธ การเปลี่ยนวันเริ่มต้นจะสมเหตุสมผลก็ต่อเมื่อ มันไม่สร้างแรงกดดันให้ผู้คนต้องทำงานในช่วงสุดสัปดาห์
หากปัญหาที่แท้จริงคือการประมาณการนั้นมองโลกในแง่ดีมากเกินไป ให้พยายามปรับปรุงการประมาณการของคุณ
การวางแผนเป็นรูปแบบหนึ่งของความสูญเปล่า มันไม่ได้สร้างมูลค่าด้วยตัวมันเอง
พยายามค่อยๆ ลดเปอร์เซ็นต์เวลาที่คุณใช้ในการวางแผน บางทีมเริ่มต้นด้วยการวางแผนทั้งวัน ค่อยๆ ปรับปรุงทักษะการวางแผนของตน จนกระทั่งพวกเขาใช้เวลาหนึ่งชั่วโมงในการวางแผนสำหรับการทำงานในหนึ่งสัปดาห์
เมื่อโปรแกรมเมอร์พร้อมที่จะเริ่มงานใหม่ เขาจะดึงงานหนึ่งอัน จากบนสุดของลิสต์ สิ่งนี้จะลดโอกาสที่เขาจะเลือกงานที่เขาสนใจหรือถนัดเป็นพิเศษ และรับประกันว่าโปรแกรมเมอร์แต่ละคนจะได้งานที่หลากหลาย
Quarterly Cycle แพลนระดับไตรมาส
วางแผนการทำงานทีละไตรมาส ไตรมาสละครั้ง จะสะท้อนถึงทีม โครงการ ความคืบหน้า และความสอดคล้องกับเป้าหมายที่ใหญ่กว่า
ระหว่างการวางแผนรายไตรมาส:
- ระบุคอขวด ที่ทำให้เราทำตามแผนภาพใหญ่ไม่ได้ เน้นไปที่สิ่งที่เราควบคุมไม่ได้ภายในทีม
- เริ่มการซ่อมแซมส่วนที่พัง ที่ส่งผลให้เราไม่สามารถทำงานได้ตามแผน
- วางแผนธีมหรือรูปแบบสำหรับไตรมาส
- เลือกเรื่องราวที่มีมูลค่า เพื่อจัดมันเข้ากับธีมในแต่ละไตรมาส
- มุ่งเน้นไปที่ภาพใหญ่ของโครงการที่เหมาะสมกับองค์กร
การใช้ไตรมาสเป็นขอบเขตการวางแผน สามารถประสานได้อย่างดีกับกิจกรรมทางธุรกิจอื่นๆ และยังเป็นช่วงเวลาที่สะดวกสบายสำหรับการโต้ตอบกับซัพพลายเออร์ภายนอกและลูกค้า
การแยก “ธีม” ออกจาก “เรื่องราว” มีวัตถุประสงค์เพื่อจัดการกับแนวโน้มของทีมที่จะจดจ่อและตื่นเต้นกับรายละเอียดของสิ่งที่พวกเขากำลังทำอยู่ โดยไม่ได้ไตร่ตรองว่าเรื่องราวของสัปดาห์นี้นั้นผนวกเข้ากับภาพรวมได้อย่างไร
ธีมยังเข้ากันได้ดีกับการวางแผนในระดับที่ใหญ่ขึ้น เช่น การวาดแผนกลยุทธ์ทางการตลาด
Slack คลายออก หย่อนลงบ้าง อู้บ้าง
ในแผนใดๆ ให้รวมงานเล็กๆ น้อยๆ ที่สามารถทิ้งได้หากคุณทำไม่ทัน เพราะปกติการทำงานมันจะมีงานที่เสร็จและไม่เสร็จอยู่เสมอ
คุณสามารถเพิ่มเรื่องราวเพิ่มเติมได้ในภายหลังและส่งมอบมากกว่าที่คุณสัญญาไว้ มันอาจทำให้ความสัมพันธ์ตอนต้นแย่ แต่ด้วยความมุ่งมั่นเพียงไม่กี่ครั้งจะนำไปสู่การสร้างความสัมพันธ์ใหม่ได้อีก
ผู้เขียน (ในที่นี้แทนตัวเองว่า “ฉัน”) จำการสนทนาได้ 2 ครั้ง
- ครั้งแรกกับผู้จัดการระดับกลาง ที่มีพนักงานหนึ่งร้อยคนรายงานต่อเขา
- และอีกบทสนทนาหนึ่งกับผู้จัดการระดับบริหาร ซึ่งมีพนักงานสามร้อยคนในองค์กรของเขา
- ฉันแนะนำผู้จัดการระดับกลางว่า สนับสนุนให้ทีมของเขารับปากทำสิ่งที่พวกเขามั่นใจว่าสามารถทำได้จริง พวกเขามีประวัติการทำงานเกินกำลังและการส่งมอบน้อยเกินไปมาอย่างยาวนาน
- “โอ้ ฉันทำอย่างนั้นไม่ได้ ตารางงานที่ไม่สมจริง (ไม่แน่น) ฉันจะถูกไล่ออก”
- วันต่อมาได้คุยกับผู้บริหาร “พวกเขาไม่เคยมาตรงเวลาเลย ก็โอเค พวกเขายังคงส่งมอบสิ่งที่เราต้องการอย่างเพียงพอ”
ความมุ่งมั่นมากเกินไปจนเป็นนิสัยของพวกเขา ก่อให้เกิดปริมาณของ Defects ที่ไม่สามารถจัดการได้ ขวัญกำลังใจลดลง หดหู่ใจ และความสัมพันธ์ที่ร้าวฉาน
การสื่อสารที่ชัดเจนและตรงไปตรงมาช่วยลดความตึงเครียดและเพิ่มความน่าเชื่อถือ
คุณสามารถจัดโครงสร้างให้มีความหย่อนๆ ได้บ้าง ในหลายวิธี เช่น
- 1/8 สัปดาห์อาจเป็น “Geek Week”
- 20% ของงบประมาณรายสัปดาห์สามารถปันส่วนลงไปในงานที่โปรแกรมเมอร์เลือกได้ (มีเวลาให้ลองเล่น ลองทำในสิ่งที่สนใจ)
คุณอาจต้องเริ่มผ่อนคลายกับตัวเอง บอกตัวเองว่า คุณคิดว่างานจะต้องใช้เวลานานแค่ไหนและให้เวลาตัวเองทำ แม้ว่าคนอื่นๆ ในองค์กรจะไม่พร้อมสำหรับการสื่อสารที่ตรงไปตรงมาและชัดเจนก็ตาม
Ten-Minute Build สร้างได้ภายในสิบนาที
สร้างระบบทั้งหมดและเรียกใช้การทดสอบทั้งหมดโดยอัตโนมัติ เห็นผลภายในสิบนาที งานสร้างที่ใช้เวลานานกว่าสิบนาทีจะถูกใช้น้อยลง ขาดโอกาสในการได้รับ Feedback
การสร้างได้ภายในสิบนาทีเป็นภาพในอุดมคติ คุณทำอะไรระหว่างการเดินทางไปสู่ภาพในอุดมคตินั้น?
- หากกระบวนการของคุณไม่เป็นอัตโนมัติ นั่นคือจุดเริ่มต้นแรก
- จากนั้นคุณอาจสร้างเฉพาะส่วนของระบบที่คุณเปลี่ยนแปลงได้
- สุดท้ายคุณอาจสามารถรันเฉพาะการทดสอบที่ครอบคลุมส่วนของระบบที่มีความเสี่ยง เนื่องจากการเปลี่ยนแปลงที่คุณทำ
การเดาว่าส่วนใดของระบบจำเป็นต้องสร้างและส่วนใดที่ต้องทดสอบจะนำมาซึ่งความเสี่ยงที่จะเกิดข้อผิดพลาด
Automated builds มีค่ามากกว่าการ Build ที่ต้องดำเนินการด้วยตนเอง เมื่อระดับความเครียดเพิ่มสูงขึ้น การ Build แบบแมนนวลมักจะทำได้น้อยลงและทำได้ไม่ดี ส่งผลให้มีข้อผิดพลาดมากขึ้นและเกิดความเครียดมากขึ้น
“เราทำผิดพลาดหรือไม่? มา Build และดูผลกันเถอะ”
Continuous Integration การผสานรวมกันอย่างต่อเนื่อง
การเขียนโปรแกรมของทีมคือ a divide, conquer, and integrate problem ขั้นตอนการรวมโค้ดกันไม่สามารถคาดเดาได้ อาจใช้เวลามากกว่าการเขียนโปรแกรมดั้งเดิม ยิ่งคุณรอการผสานรวมกันนานเท่าใด ก็ยิ่งมีค่าใช้จ่ายมากขึ้นเท่านั้น และค่าใช้จ่ายที่คาดเดาไม่ได้ก็จะยิ่งมากขึ้นเท่านั้น รูปแบบทั่วไปของการรวมแบบต่อเนื่องมีอยู่สองแบบหลัก
แบบอะซิงโครนัส
- ฉันตรวจสอบการเปลี่ยนแปลงของฉัน
- หลังจากนั้นไม่นาน ระบบจะสังเกตเห็นการเปลี่ยนแปลง เริ่ม Build และทดสอบ
- หากมีปัญหา ฉันได้รับแจ้งทางอีเมล ข้อความ หรือ โคมไฟสีแดงเรืองแสง
- แล้วค่อยไปแก้
แบบซิงโครนัส
- พอเราเอาโค้ดไปรวมกันหลังจากที่ pair programming เสร็จ ไม่เกินสองสามชั่วโมง
- เรารอให้การสร้างเสร็จสมบูรณ์และชุดการทดสอบทั้งหมดทำงาน รอดูว่าผ่านหรือไม่ผ่าน
- สร้างแรงกดดันเชิงบวกสำหรับรอบการทำงานที่สั้นและชัดเจน
เมื่อฉันได้รับแจ้งปัญหาหลังจากเริ่มงานใหม่ครึ่งชั่วโมง ฉันเสียเวลาไปมากในการจดจำสิ่งที่ฉันเคยทำ แก้ไขปัญหา และจากนั้นกลับมาหาตำแหน่งของฉันในงานใหม่ที่ถูกขัดจังหวะ
ผสานรวมและสร้างผลิตภัณฑ์ที่สมบูรณ์
หากเป้าหมายคือการเขียนซีดี ให้เขียนซีดี หากเป้าหมายคือการปรับใช้เว็บไซต์ ให้ปรับใช้เว็บไซต์ แม้ว่าจะเป็นการทดสอบสภาพแวดล้อมก็ตาม
การผสานรวมอย่างต่อเนื่อง ควรสมบูรณ์เพียงพอที่การติดตั้งระบบครั้งแรกจะไม่ใช่เรื่องใหญ่
Test-First Programming เขียนการทดสอบก่อนเขียนโค้ด
เขียนการทดสอบอัตโนมัติที่ผลลัพธ์ออกมาผิด (fail) ก่อน แล้วค่อยไปเขียนโค้ดที่จะทำให้ผลมันผ่าน ช่วยแก้ปัญหาเรื่อง
- Scope creep ระบุสิ่งที่โปรแกรมควรทำอย่างชัดเจนและเป็นกลาง ทำให้คุณโฟกัสที่การเขียนโค้ดของคุณได้ แบบไม่ต้องเขียนเผื่อๆ
- Coupling and cohesion (การเชื่อมโยง และ การประสานกัน) หากการเขียนการทดสอบทำได้ยาก แสดงว่าคุณมีปัญหาในการออกแบบ ไม่ใช่ปัญหาในการทดสอบ โค้ดที่เชื่อมติดกันอย่างหลวมๆ นั้นง่ายต่อการทดสอบ (ถ้ามันยุ่งเหยิง มันก็ทดสอบยาก กระทบกันเยอะ)
- Trust การเขียนโค้ดที่สะอาด ใช้งานได้จริง ผ่านการทดสอบอัตโนมัติ ทำให้เพื่อนร่วมทีมของคุณมีเหตุผลที่จะไว้วางใจคุณ
- Rhythm การหลงทางเป็นเวลาหลายชั่วโมงเป็นเรื่องง่ายเมื่อคุณเขียนโค้ด เมื่อเขียนการทดสอบก่อน สิ่งที่ต้องทำต่อไปจะชัดเจนขึ้น — ทดสอบ, โค้ด, รีแฟกเตอร์, ทดสอบ, โค้ด, รีแฟคเตอร์
คุณเริ่มต้นด้วย “การทดสอบ” ที่ระบุว่า ไม่มีการหยุดชะงักในระบบ หลังจากการเปลี่ยนแปลงทุกครั้ง คุณจะตรวจสอบอีกครั้งว่าไม่มีการหยุดชะงักเกิดขึ้น
การปรับปรุงอีกประการหนึ่งของการเขียนการทดสอบก่อนคือ การทดสอบอย่างต่อเนื่องตลอดการพัฒนา การทดสอบจะดำเนินการในทุกการเปลี่ยนแปลงของโปรแกรม ความล้มเหลวในการทดสอบจะถูกรายงานในรูปแบบเดียวกับข้อผิดพลาดของคอมไพเลอร์
การทดสอบอย่างต่อเนื่อง ช่วยลดเวลาในการแก้ไขข้อผิดพลาด โดยลดเวลาในการค้นพบ อย่างไรก็ตาม การทดสอบต้องดำเนินการอย่างรวดเร็ว
เนื่องจากขอบเขตที่จำกัด การทดสอบเหล่านี้มักจะทำงานเร็วมาก คุณสามารถเรียกใช้ได้หลายพันรายการโดยเป็นส่วนหนึ่งของการสร้างได้ภายในสิบนาที
Incremental Design การออกแบบที่เพิ่มขึ้นเรื่อยๆ
ลงทุนออกแบบระบบทุกวัน พยายามออกแบบระบบให้เหมาะกับความต้องการของระบบในปัจจุบัน ทำงานอย่างค่อยเป็นค่อยไปแต่ต่อเนื่อง เพื่อให้การออกแบบสอดคล้องกับความเข้าใจของคุณ
ทีม XP ทำงานอย่างหนักเพื่อสร้างเงื่อนไขที่ค่าใช้จ่ายในการเปลี่ยนซอฟต์แวร์จะไม่เพิ่มขึ้นอย่างหายนะ การทดสอบอัตโนมัติ แนวทางปฏิบัติอย่างต่อเนื่องในการปรับปรุงการออกแบบ และกระบวนการทางสังคมที่ชัดเจน ทั้งหมดนี้มีส่วนช่วยให้ค่าใช้จ่ายในการเปลี่ยนแปลงต่ำ
หากปราศจากความใส่ใจในการออกแบบทุกวัน ต้นทุนของการเปลี่ยนแปลงจะพุ่งสูงขึ้นอย่างรวดเร็ว ผลลัพธ์ที่ได้คือ ระบบที่ออกแบบมาไม่ดี เปราะบาง เปลี่ยนแปลงยาก
ไม่ใช่ให้ลดการลงทุนด้านการออกแบบให้น้อยที่สุดในระยะสั้น แต่ให้ลงทุนด้านการออกแบบตามสัดส่วนความต้องการของระบบจนถึงปัจจุบัน
คำถามไม่ได้อยู่ที่ว่าจะออกแบบหรือไม่ แต่คำถามคือควรออกแบบเมื่อใด
Incremental Design แสดงให้เห็นว่า เวลาที่มีประสิทธิภาพมากที่สุดในการออกแบบนั้นขึ้นอยู่กับประสบการณ์ หากขั้นตอนเล็กๆ ที่ปลอดภัยคือวิธีการออกแบบ
คำถามต่อไปคือ จุดไหนในระบบที่จะปรับปรุงการออกแบบ
เริ่มต้นจาก การกำจัดความซ้ำซ้อน
Incremental Design ไม่ได้บอกว่า การออกแบบล่วงหน้า เป็นสิ่งที่น่ากลัว มันบอกว่า การออกแบบที่ทำใกล้เวลาใช้งานนั้น มีประสิทธิภาพมากกว่า
เมื่อความเชี่ยวชาญของคุณเติบโตขึ้น การเปลี่ยนแปลงระบบที่กำลังทำงานอยู่ ด้วยขั้นตอนเล็กๆ ที่ปลอดภัย ระบบจะง่ายขึ้น ความคืบหน้าจะเริ่มเร็วขึ้น การทดสอบจะเขียนได้ง่ายขึ้น และเนื่องจากระบบมีขนาดเล็กลง การสื่อสารกับทีมจึงน้อยลง
การปรับโครงสร้างใหม่เหล่านี้สามารถเกิดขึ้นได้ในทุกระดับ ทำให้เราได้ระบบที่สามารถเริ่มต้นเล็กๆ และเติบโตได้ตามต้องการ โดยไม่มีค่าใช้จ่ายสูงเกินไป
ถ้าย้อนระลึกถึงสิ่งที่เคยเรียน เราจะถูกสอนให้ออกแบบให้ครบ เพราะเราเห็นภาพปลายทาง
แนวทางปฏิบัติในบทนี้ไม่ใช่เรื่องราวทั้งหมดของ XP พวกเขาให้พื้นฐานของความเคารพ การสื่อสาร และคำติชม ที่ส่งเสริมความเรียบง่ายและความกล้าหาญ
สมาชิกในทีมสามารถใช้ความมั่นใจและความสามารถที่เพิ่มขึ้นเพื่อสร้างความสัมพันธ์ภายในและภายนอกทีม
ผลตอบแทนก้อนใหญ่ของ XP เกิดขึ้น เมื่อแนวทางปฏิบัติเหล่านี้เข้าที่เข้าทางแล้ว
Chapter 8 — Getting Started
ในการทำ XP คุณต้องเริ่มจากจุดที่คุณอยู่และปรับเปลี่ยนโดยเพิ่มแนวทางปฏิบัติที่ทำให้คุณบรรลุเป้าหมายและแสดงคุณค่า เมื่อคุณเพิ่มแนวทางปฏิบัติ การผสานพลังระหว่างกันทำให้สิ่งต่างๆ เป็นไปได้อย่างที่คุณคาดไม่ถึง
XP อาจแสดงถึงทิศทางใหม่ หรือการเร่งความเร็ว ในความพยายามของคุณในการปรับปรุง ถ้าเป็นเช่นนั้น คุณจะเริ่มต้นอย่างไรและที่ไหน
- ประการแรก ไม่มีสถานที่ที่เหมาะสมสำหรับทุกคนในการเริ่มต้น
- วิธีปฏิบัติหลักใดๆ นั้นปลอดภัย เสนอการปรับปรุงทันทีหากพบปัญหา
- เริ่มต้นวงจรระดับสัปดาห์ด้วยตัวคุณเอง ใช้เวลาในช่วงต้นสัปดาห์เพื่อจดทุกสิ่งที่คุณคิดว่าจะทำได้ในสัปดาห์นั้น หากมีงานที่ต้องทำมากเกินไป ให้จัดลำดับความสำคัญของคุณให้สอดคล้องกับความต้องการของทีม
- เริ่มต้นง่ายๆ ด้วยการเปลี่ยนทีละอย่าง
- ทักษะทางเทคนิคในการทำงานแบบ XP และการปรับเปลี่ยนทัศนคติ ต้องใช้เวลาเรียนรู้ นิสัยใหม่ต้องใช้เวลาในการสร้างความเข้มแข็ง
- หากคุณเปลี่ยนแปลงเร็วเกินไป คุณก็เสี่ยงที่จะกลับไปสู่แนวทางปฏิบัติและค่านิยมแบบเก่า
- กำหนดงบประมาณของคุณ สำหรับการปรับปรุงกระบวนการ เลือกเรื่องที่จะทำก่อน ปรับตัวเมื่อคุณค้นพบว่าอะไรง่าย หรือมีค่า และ อะไรยาก
- การใช้การวางแผนแบบ XP กับกระบวนการเปลี่ยนแปลง ทำให้เราสื่อสารและจัดลำดับความสำคัญของเราได้ เปิดโอกาสให้ผู้สนับสนุนของเราเห็นว่าเรากำลังทำอะไร อะไรมีอิทธิพลต่อสิ่งที่เกิดขึ้น
- การเปลี่ยนแปลงเริ่มต้นด้วยการตระหนักรู้ การตระหนักถึงความจำเป็นในการเปลี่ยนแปลงมาจากความรู้สึก สัญชาตญาณ ข้อเท็จจริง หรือคำติชมจากบุคคลภายนอก แม้ว่าความรู้สึกจะมีคุณค่า แต่จำเป็นต้องตรวจสอบข้อเท็จจริงหรือความคิดเห็นที่เชื่อถือได้
- เมื่อคุณตระหนักถึงความจำเป็นในการเปลี่ยนแปลง คุณสามารถเริ่มเปลี่ยนแปลงได้ แนวทางปฏิบัติหลักคือจุดเริ่มต้น เลือกแนวปฏิบัติที่มีจุดประสงค์ตรงกับลำดับความสำคัญของการเปลี่ยนแปลงของคุณ และดูว่าประสิทธิภาพของทีมดีขึ้นหรือไม่
- การเปลี่ยนแปลงเริ่มต้นที่บ้านเสมอ คนเดียวที่คุณสามารถเปลี่ยนแปลงได้คือตัวคุณเอง ไม่ว่าองค์กรของคุณจะทำงานได้ไม่ดีเพียงใด คุณสามารถเริ่มใช้ XP สำหรับตัวคุณเองได้
- ทุกคนในทีมสามารถเริ่มเปลี่ยนพฤติกรรมของตัวเองได้ โปรแกรมเมอร์สามารถเริ่มเขียนการทดสอบก่อนได้ ผู้ทดสอบสามารถทำการทดสอบได้โดยอัตโนมัติ ลูกค้าสามารถเขียนเรื่องราวและกำหนดลำดับความสำคัญที่ชัดเจน ผู้บริหารสามารถคาดหวังความโปร่งใส
- เมื่อใช้ XP ทีมสามารถสร้างการปรับปรุงอย่างมากในด้านการแก้ไขข้อบกพร่อง การประมาณค่า และประสิทธิภาพการทำงาน ราคาของการปรับปรุงคือความร่วมมืออย่างใกล้ชิดและการมีส่วนร่วมกับทั้งทีม เพิ่มความคาดหวังของคุณสำหรับความรับผิดชอบและการทำงานเป็นทีม จากนั้นช่วยทีมข้ามผ่านความวิตกกังวลที่มาพร้อมกับการเปลี่ยนแปลง
Mapping the Practices
ไม่มีคำตอบที่ “ถูกต้อง” ในแบบฝึกหัดการใช้ XP สมาชิกในทีมแต่ละคน แต่ละทีมตีความ ความหมายของการปฏิบัติที่แตกต่างกัน การอภิปรายเกี่ยวกับเนื้อหาและการฝึกใช้เป็นผลลัพธ์ที่มีค่า
เมื่อคุณเห็นแนวคิดในการปรับปรุงที่เหมาะสมกับคุณแล้ว ลงมือทำเลย
ถ้าทำได้เป็นทีมยิ่งดี ถ้าไม่ ให้ทำคนเดียวจนกว่าคุณจะสามารถแบ่งปันสิ่งที่คุณได้เรียนรู้กับคนที่คุณไว้ใจได้
- การพัฒนาซอฟต์แวร์สามารถทำได้มากกว่าที่กำลังทำอยู่ เรามีโอกาสที่จะก้าวกระโดดอย่างมีประสิทธิผล
- ข้อบกพร่องเกิดขึ้นได้ยาก ถ้าเกิดแล้วก็หาเจอได้ง่าย
- การปรับขอบเขตครั้งใหญ่เนื่องจากขาดความคืบหน้าควรเกิดขึ้นในช่วงครึ่งแรกของกำหนดการเท่านั้น
- การปรับใช้ซอฟต์แวร์ครั้งแรก ควรเกิดขึ้นหลังจากใช้งบประมาณโครงการเพียงเล็กน้อย
- ทีมควรจะสามารถเติบโตและหดตัวได้โดยไม่มีผลกระทบร้ายแรง
— — — — — โปรดติดตามตอนต่อไป — — — — —
