คุณคุ้นเคยกับการเขียนโปรแกรม แต่ Extreme Programming (เรียกสั้นๆ ว่า XP) ยังคงเป็นปริศนาสำหรับคุณ
อย่าปล่อยให้ชื่อทำให้คุณผิดหวัง คุณอาจเสี่ยงที่จะพลาดข้อมูลที่เป็นประโยชน์
ในบทความนี้ เราจะอธิบายทุกอย่างที่คุณจำเป็นต้องรู้เกี่ยวกับ Extreme Programming เพื่อให้คุณสามารถใช้มันให้เป็นประโยชน์ได้
การเขียนโปรแกรมขั้นสูงเป็นวิธีการพัฒนาซอฟต์แวร์ที่เป็นส่วนหนึ่งของสิ่งที่เรียกรวมกันว่าวิธีการแบบอไจล์ XP สร้างขึ้นจากค่านิยม หลักการ และแนวทางปฏิบัติ และเป้าหมายคือเพื่อให้ทีมขนาดเล็กและขนาดกลางสามารถผลิตซอฟต์แวร์คุณภาพสูงและปรับให้เข้ากับความต้องการที่เปลี่ยนแปลงและพัฒนาตลอดเวลา
สิ่งที่ทำให้ XP แตกต่างจากวิธีการแบบ Agile อื่นๆ คือ XP เน้นด้านเทคนิคของการพัฒนาซอฟต์แวร์ การเขียนโปรแกรมขั้นสูงนั้นแม่นยำเกี่ยวกับวิธีการทำงานของวิศวกร เนื่องจากแนวปฏิบัติด้านวิศวกรรมต่อไปนี้ช่วยให้ทีมสามารถส่งมอบโค้ดคุณภาพสูงได้อย่างยั่งยืน
การเขียนโปรแกรมแบบเอ็กซ์ตรีมคือแนวทางปฏิบัติที่ดีโดยสรุป เนื่องจากการเขียนโปรแกรมคู่เป็นสิ่งที่ดีให้ทำตลอดเวลา เนื่องจากการทดสอบล่วงหน้าเป็นสิ่งที่ดี เราจึงทดสอบก่อนที่จะเขียนโค้ดการผลิตเสียด้วยซ้ำ
XP ซึ่งแตกต่างจากวิธีการอื่น ๆ ขึ้นอยู่กับค่านิยมและหลักการที่สำคัญและเกี่ยวข้องในแง่ของการปฏิบัติทางวิศวกรรม
ค่านิยมให้เป้าหมายแก่ทีม พวกเขาทำหน้าที่เป็น "ดาวเหนือ" เพื่อชี้นำการตัดสินใจของคุณในระดับสูง อย่างไรก็ตาม ค่าต่างๆ นั้นเป็นนามธรรมและคลุมเครือเกินไปสำหรับแนวทางที่เฉพาะเจาะจง ตัวอย่างเช่น การบอกว่าคุณให้ความสำคัญกับการสื่อสารอาจนำไปสู่ผลลัพธ์ที่แตกต่างกันมากมาย
การปฏิบัติเป็นสิ่งที่ตรงกันข้ามกับค่านิยม พวกมันเป็นรูปธรรมและติดดิน defiการกำหนดรายละเอียดเฉพาะของสิ่งที่ต้องทำ แนวทางปฏิบัติช่วยให้ทีมมีความรับผิดชอบต่อค่านิยม ตัวอย่างเช่น การปฏิบัติงานในพื้นที่ทำงานด้านข้อมูลส่งเสริมการสื่อสารที่โปร่งใสและเรียบง่าย
หลักการเป็นแนวทางเฉพาะโดเมนที่เชื่อมช่องว่างระหว่างการปฏิบัติและค่านิยม
ค่า XP: การสื่อสาร ความเรียบง่าย คำติชม ความกล้าหาญ และความเคารพ ลองดูที่แต่ละรายละเอียดเพิ่มเติม
การร่าง BlogInnovazione.ของภาพ alexsoft.com
การสื่อสาร: ขาดการสื่อสารป้องกันความรู้ไหลภายในทีม บ่อยครั้งเมื่อเกิดปัญหา มีผู้รู้วิธีแก้ไขอยู่แล้ว แต่การขาดการสื่อสารขัดขวางพวกเขาจากการเรียนรู้เกี่ยวกับปัญหาหรือมีส่วนร่วมในการแก้ปัญหา ดังนั้น ปัญหาจึงจบลงด้วยการแก้ไขสองครั้ง ทำให้เกิดขยะ
ความเรียบง่าย: ความเรียบง่ายบอกว่าคุณมักจะพยายามทำสิ่งที่ง่ายที่สุดที่ได้ผล มักถูกเข้าใจผิดและถือเป็นสิ่งที่ง่ายที่สุด ระยะเวลา โดยไม่สนใจส่วนที่ "ใช้งานได้"
สิ่งสำคัญคือต้องจำไว้ว่าความเรียบง่ายนั้นมีบริบทสูง สิ่งที่ง่ายสำหรับทีมหนึ่งกลับซับซ้อนสำหรับอีกทีมหนึ่ง และขึ้นอยู่กับทักษะ ประสบการณ์ และความรู้ของแต่ละทีม
ข้อเสนอแนะ: ข้อเสนอแนะในแนวทางการพัฒนาซอฟต์แวร์แบบเรียงซ้อนแบบดั้งเดิมมักจะ “น้อยเกินไป สายเกินไป”
อย่างไรก็ตาม XP ยอมรับการเปลี่ยนแปลงและทีม XP พยายามหาข้อเสนอแนะที่ทันท่วงทีและสม่ำเสมอ หากจำเป็นต้องมีการแก้ไขหลักสูตร XPers ต้องการทราบโดยเร็วที่สุด
การร่าง BlogInnovazione.ของภาพ alexsoft.com
ข้อเสนอแนะมีหลายรูปแบบและหลายขนาด เมื่อคุณร่วมโปรแกรม ข้อคิดเห็นจากเพื่อนร่วมงานของคุณคือคำติชมที่สำคัญ เช่นเดียวกับความคิดเห็นของสมาชิกในทีมคนอื่นๆ ที่มีต่อไอเดีย รวมถึงลูกค้าที่เป็นสมาชิกของทีม
การทดสอบเป็นแหล่งข้อมูลข้อเสนอแนะอันมีค่าอีกแหล่งหนึ่งซึ่งนอกเหนือไปจากผลการทดสอบ ไม่ว่าการทดสอบการเขียนจะง่ายหรือยาก ความคิดเห็นก็เช่นกัน หากคุณประสบปัญหาในการเขียนแบบทดสอบ โครงการของคุณอาจซับซ้อนเกินไป รับฟังความคิดเห็นและปรับปรุงการออกแบบของคุณ
สิ่งที่ดูเหมือนเป็นความคิดที่ดีอาจใช้ไม่ได้ผลในทางปฏิบัติ ดังนั้น โค้ดสำเร็จรูปจึงเป็นแหล่งที่มาของคำติชม เช่นเดียวกับผลิตภัณฑ์ที่แจกจ่าย
สุดท้าย โปรดทราบว่ามีข้อเสนอแนะมากเกินไป หากทีมให้ข้อเสนอแนะมากเกินกว่าที่จะสามารถจัดการได้ ข้อเสนอแนะที่สำคัญอาจตกหล่นจากเรดาร์ ดังนั้น สิ่งสำคัญคือต้องชะลอความเร็วและค้นหาว่าอะไรเป็นสาเหตุของฟีดแบ็คที่มากเกินไปและแก้ไข
ความกล้าหาญ: เคนท์ เบ็ค defiความกล้าหาญปรากฏเป็น "การกระทำที่มีประสิทธิภาพเมื่อเผชิญกับความกลัว" ในฐานะวิศวกรซอฟต์แวร์ คุณมีความกลัวมากมายและมีโอกาสมากมายที่จะแสดงความกล้าหาญ
ต้องใช้ความกล้าที่จะบอกความจริง การให้และรับคำติชมต้องใช้ความกล้าหาญเช่นกัน และต้องใช้ความกล้าหาญเพื่อหลีกเลี่ยงการเข้าใจผิดเกี่ยวกับต้นทุนที่จมลง และละทิ้งโซลูชันที่ล้มเหลวซึ่งได้รับการลงทุนจำนวนมาก
เคารพ: หลักฐานพื้นฐานของ XP คือทุกคนใส่ใจกับงานของตน ไม่มีความเป็นเลิศทางเทคนิคใด ๆ สามารถช่วยโครงการได้หากไม่มีความเอาใจใส่และความเคารพ
ทุกคนมีค่าควรแก่การให้เกียรติและความเคารพ ซึ่งรวมถึงผู้ที่เกี่ยวข้องในโครงการพัฒนาซอฟต์แวร์ด้วย เมื่อคุณและสมาชิกในทีมเคารพและดูแลซึ่งกันและกัน ลูกค้า โครงการ และผู้ใช้ในอนาคต ทุกคนจะได้รับประโยชน์
หลักการให้คำแนะนำเฉพาะเจาะจงมากกว่าค่านิยม เป็นแนวทางที่ให้ความกระจ่างแก่ค่านิยมและทำให้มีความชัดเจนมากขึ้นและไม่คลุมเครือ
การร่าง BlogInnovazione.ของภาพ alexsoft.com
ตัวอย่างเช่น พิจารณาจากคุณค่าของความกล้าหาญเพียงอย่างเดียว คุณอาจสรุปได้ว่าควรทำการเปลี่ยนแปลงครั้งใหญ่ในตารางเวลาของคุณทันที อย่างไรก็ตาม หลักการ Baby Steps บอกเราว่าการเปลี่ยนแปลงครั้งใหญ่มีความเสี่ยง เลยเลือกตัวเล็กแทน
อุมานิตา: มนุษย์สร้างซอฟต์แวร์เพื่อมนุษย์ ข้อเท็จจริงที่มักถูกมองข้าม แต่การคำนึงถึงความต้องการขั้นพื้นฐานของมนุษย์ จุดแข็งและจุดอ่อนจะสร้างผลิตภัณฑ์ที่มนุษย์ต้องการใช้ และสภาพแวดล้อมการทำงานที่เปิดโอกาสให้คุณบรรลุความสำเร็จและเติบโต ความรู้สึกเป็นเจ้าของและความปลอดภัยขั้นพื้นฐาน เป็นสถานที่ที่คุณพิจารณาความต้องการของผู้อื่นได้ง่ายขึ้น
เศรษฐกิจ: ใน XP ทีมมักจะให้ความสนใจกับความเป็นจริงทางเศรษฐกิจของการพัฒนาซอฟต์แวร์ ประเมินความเสี่ยงทางเศรษฐกิจและความต้องการของโครงการอย่างต่อเนื่อง
ตัวอย่างเช่น พวกเขาจะใช้เรื่องราวของผู้ใช้ตามมูลค่าทางธุรกิจมากกว่าข้อกังวลทางเทคนิค
ผลประโยชน์ร่วมกัน: หลังจาก XP คุณจะหลีกเลี่ยงโซลูชันที่ให้ประโยชน์แก่ฝ่ายหนึ่งโดยที่อีกฝ่ายต้องเสีย ตัวอย่างเช่น ข้อกำหนดเพิ่มเติมอาจช่วยให้ผู้อื่นเข้าใจได้ แต่จะทำให้เสียสมาธิในการนำไปใช้และทำให้ผู้ใช้ของคุณล่าช้า
วิธีแก้ปัญหาที่ได้ประโยชน์ร่วมกันคือการใช้การทดสอบการยอมรับโดยอัตโนมัติ รับคำติชมทันทีเกี่ยวกับการใช้งานของคุณ เพื่อนร่วมงานของคุณได้รับข้อมูลจำเพาะที่แม่นยำในโค้ด และผู้ใช้จะได้รับฟีเจอร์ก่อนใคร นอกจากนี้ พวกคุณทุกคนจะมีตาข่ายนิรภัยป้องกันการถดถอย
ผลประโยชน์ (ผลประโยชน์ร่วมกัน): หากโซลูชันหนึ่งทำงานได้ในระดับหนึ่ง ก็อาจทำงานในระดับที่สูงกว่าหรือต่ำกว่าได้เช่นกัน ตัวอย่างเช่น การได้รับคำติชมตั้งแต่เนิ่นๆ และสม่ำเสมอเป็นเดิมพันกับระดับที่แตกต่างกันใน XP
การปรับปรุง: ตามหลักการของการปรับปรุง ทีมไม่ได้ตั้งเป้าหมายเพื่อความสมบูรณ์แบบในการนำไปใช้ครั้งแรก แต่สำหรับการนำไปใช้ที่ดีพอ จากนั้นจึงเรียนรู้และปรับปรุงอย่างต่อเนื่องด้วยคำติชมจากผู้ใช้จริง
ความหลากหลาย: คุณและเพื่อนร่วมงานได้รับประโยชน์จากมุมมอง ทักษะ และทัศนคติที่หลากหลาย ความหลากหลายดังกล่าวมักนำไปสู่ความขัดแย้ง แต่ก็ไม่เป็นไร
ความขัดแย้งและความไม่ลงรอยกันเป็นโอกาสสำหรับความคิดที่ดีขึ้นเมื่อทุกคนแสดงตามคุณค่าของความกล้าหาญและความเคารพ กล้าแสดงมุมมองที่เป็นปฏิปักษ์ เคารพในการแสดงออกในทางแพ่งและเห็นอกเห็นใจ และทั้งหมดนี้คือแบบฝึกหัดการสื่อสารที่มีประสิทธิภาพ
การสะท้อน: ทีมที่ยอดเยี่ยมสะท้อนผลงานและวิเคราะห์ว่าจะดีขึ้นได้อย่างไร XP มอบโอกาสมากมายสำหรับสิ่งนี้ ไม่ใช่แค่ในรอบรายสัปดาห์และรายไตรมาสเท่านั้น แต่ในทุก ๆ การปฏิบัติที่ส่งเสริม
ความรู้สึกเป็นสิ่งสำคัญที่ต้องพิจารณานอกเหนือไปจากการวิเคราะห์เชิงตรรกะ ลำไส้ของคุณสามารถบอกคุณได้ก่อนที่คุณจะให้เหตุผลเกี่ยวกับอะไร และเพื่อให้เขาสามารถพูดคุยกับผู้ที่ไม่เชี่ยวชาญด้านเทคนิค พวกเขาสามารถถามคำถามที่เปิดโอกาสใหม่ๆ ได้อย่างเต็มที่
ไหล: วิธีการพัฒนาซอฟต์แวร์แบบดั้งเดิมมีขั้นตอนที่แตกต่างกันซึ่งกินเวลานานและมีโอกาสน้อยสำหรับข้อเสนอแนะและการแก้ไขหลักสูตร การพัฒนาซอฟต์แวร์ใน XP เกิดขึ้นในกิจกรรมที่เกิดขึ้นอย่างต่อเนื่องใน "กระแส" ของคุณค่าที่สอดคล้องกัน
โอกาส: ปัญหาเป็นสิ่งที่หลีกเลี่ยงไม่ได้ในการพัฒนาซอฟต์แวร์ อย่างไรก็ตาม ทุกปัญหาคือโอกาสในการปรับปรุง เรียนรู้ที่จะมองสิ่งเหล่านี้ด้วยวิธีนี้ และคุณมีแนวโน้มที่จะคิดหาทางออกที่สร้างสรรค์และมุ่งเน้นเป้าหมายที่จะป้องกันไม่ให้เกิดขึ้นอีก
ความซ้ำซ้อน: หลักการของความซ้ำซ้อนกล่าวว่าหากปัญหานั้นวิกฤต คุณต้องใช้กลวิธีหลายอย่างเพื่อตอบโต้
ใช้ข้อบกพร่อง ไม่มีกลยุทธ์ใดที่สามารถป้องกันข้อบกพร่องทั้งหมดไม่ให้เล็ดลอดออกจากการผลิตได้
ดังนั้นวิธีแก้ปัญหาของ XP คือการวางชุดการวัดคุณภาพ การตั้งโปรแกรมคู่ การทดสอบ การรวมอย่างต่อเนื่อง แนวป้องกันแต่ละแนวรวมกันเป็นกำแพงที่แทบจะทะลุผ่านไม่ได้
ความล้มเหลว: ความล้มเหลวไม่เสียเปล่าเมื่อแปลเป็นความรู้ การลงมือทำและเรียนรู้อย่างรวดเร็วว่าอะไรที่ไม่ได้ผลนั้นให้ผลดีกว่าการเพิกเฉยที่เกิดจากการไม่แน่ใจเมื่อเลือกตัวเลือกต่างๆ มากมาย
คุณภาพ: ผู้คนมักคิดว่ามีปัญหาระหว่างคุณภาพและความเร็ว
ตรงกันข้าม: การผลักดันเพื่อปรับปรุงคุณภาพคือสิ่งที่ทำให้คุณไปได้เร็วขึ้น
ตัวอย่างเช่น การปรับโครงสร้างใหม่—การเปลี่ยนโครงสร้างของโค้ดโดยไม่เปลี่ยนลักษณะการทำงาน—เป็นวิธีปฏิบัติที่ทำให้โค้ดเข้าใจและเปลี่ยนแปลงได้ง่ายขึ้น ด้วยเหตุนี้ คุณจึงมีโอกาสน้อยที่จะทำให้เกิดข้อบกพร่องของโค้ด ซึ่งทำให้คุณสามารถส่งมอบคุณค่าได้มากขึ้นก่อนโดยไม่ต้องแก้ไขข้อบกพร่อง
ขั้นตอนเล็กน้อย: การเปลี่ยนแปลงครั้งใหญ่มีความเสี่ยง XP ลดความเสี่ยงดังกล่าวโดยทำการเปลี่ยนแปลงในขั้นตอนเล็กๆ ในทุกระดับ
โปรแกรมเมอร์เขียนโค้ดในขั้นตอนเล็ก ๆ โดยใช้การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ พวกเขารวมรหัสของตนเข้ากับการฉีดหลายครั้งต่อวัน แทนที่จะเป็นทุก ๆ สองสามสัปดาห์หรือแม้แต่เป็นเดือน โครงการนี้เกิดขึ้นในวงจรสั้น ๆ มากกว่าระยะที่ยาวนาน
ความรับผิดชอบได้รับการยอมรับ: ใน XP ควรยอมรับความรับผิดชอบ ไม่เคยมอบหมาย
ความรับผิดชอบควรมาพร้อมกับอำนาจในการตัดสินใจเกี่ยวกับสิ่งที่คุณรับผิดชอบ สิ่งที่ตรงกันข้ามก็เป็นจริงเช่นกัน คุณไม่ต้องการให้คนอื่นตัดสินใจหากพวกเขาไม่จำเป็นต้องอยู่กับผลที่ตามมา
การเขียนโปรแกรมขั้นสูงซึ่งเป็นวิธีการที่คล่องตัว สามารถยอมรับและเริ่มนำมาใช้โดยไม่ต้องปฏิบัติตามแผนตายตัว นี่เป็นการออกแบบซ้ำๆ แทนที่จะเป็นโครงการเริ่มต้นขนาดใหญ่
XP แตกต่างอย่างมากจากวิธีการแบบดั้งเดิม เช่น การเรียงซ้อน การหลีกเลี่ยงขั้นตอนที่ยาวนาน
XP แตกต่างจากวิธีการแบบ Agile อื่นๆ อย่างไร
โดยธรรมชาติแล้วการเขียนโปรแกรมแบบ Extreme นั้นมีความเหมือนกันหลายอย่างกับวิธีการแบบ Agile อื่นๆ แต่ก็มีลักษณะเฉพาะเช่นกัน
วิธีการพัฒนาอื่น ๆ ส่วนใหญ่ไม่ได้พูดอะไรมากเกี่ยวกับวิธีทำให้งานสำเร็จลุล่วง ในทางกลับกัน XP มีความคิดเห็นอย่างมากเมื่อพูดถึงเรื่องนี้และให้ความสำคัญกับแนวทางปฏิบัติด้านวิศวกรรมซอฟต์แวร์เป็นอย่างมาก
Scrum เป็นเฟรมเวิร์กที่ช่วยให้ทีมพัฒนาโครงการที่ซับซ้อนด้วยวิธีที่ปรับเปลี่ยนได้ Scrum ไม่ได้กำหนดวิธีการทำงานของนักพัฒนา ดังที่ได้กล่าวไปแล้ว XP ให้ความสำคัญกับแนวทางปฏิบัติในการเขียนโปรแกรมที่ดีเป็นอย่างมาก
การร่าง BlogInnovazione.th รูปภาพ โซลูชันสุทธิ
นอกจากนี้ XP ยังเป็นเรื่องเกี่ยวกับการเขียนโปรแกรมอีกด้วย ในทางกลับกัน Scrum สามารถนำไปใช้กับโครงการใดๆ ก็ได้ที่ได้รับประโยชน์จากวิธีการทำซ้ำๆ
XP ยอมรับการเปลี่ยนแปลงส่วนประกอบ ทีมได้รับการเสริมอำนาจและสนับสนุนให้ปรับเปลี่ยนแนวทางปฏิบัติตามความต้องการเฉพาะของพวกเขา ในทางกลับกัน Scrum Guide ยืนกรานว่า "แม้ว่า Scrum สามารถนำไปใช้ได้เพียงบางส่วน แต่ผลลัพธ์ไม่ใช่ Scrum"
นอกจากนี้ Scrum ยังเป็นเฟรมเวิร์กที่ต้องเสริมด้วยวิธีการและแนวปฏิบัติเพื่อให้งานสำเร็จลุล่วง
ซึ่งหมายความว่าขอแนะนำให้ทำงานในการเขียนโปรแกรมขั้นสูงและ Scrum
ตามคำกล่าวของ Kent Beck ทีม XP ที่เติบโตเต็มที่ไม่ควรกำหนดบทบาทที่ตายตัว แต่ควรตระหนักว่าบทบาทนั้นมีประโยชน์สำหรับทีมที่มีประสบการณ์ จนกว่าพวกเขาจะเริ่มทำงานช้าลงหรือทำให้การทำงานร่วมกันทำได้ยาก
มาดูบทบาทสำคัญบางประการ:
นี่คือหลักปฏิบัติที่ใช้ใน XP พวกเขาแบ่งออกเป็นสามกลุ่มหลัก: วิศวกรรมซอฟต์แวร์ สถานที่ทำงาน และการจัดการโครงการ
การเขียนโปรแกรมจับคู่: ใน XP คุณเขียนโค้ดเป็นคู่โดยนั่งอยู่บนเครื่อง คุณและคู่ของคุณคุยกันขณะที่คุณวิเคราะห์ นำไปใช้ และทดสอบคุณสมบัติที่คุณกำลังทำอยู่ การเขียนโปรแกรมแบบคู่นั้นดีเป็นพิเศษในการสร้างโค้ดที่มีจุดบกพร่องน้อยลง ในขณะที่ยังคงมีส่วนร่วม สนุก และเหนื่อย
จำกัด สิบนาที: จำเป็น ให้เวลา 10 นาทีในการสร้างโครงการทั้งหมด รวมถึงการเรียกใช้การทดสอบอัตโนมัติทั้งหมด สูงสุดไม่เกิน XNUMX นาที ขีดจำกัดนี้มีไว้เพื่อให้การทดสอบคล่องตัวและมีประสิทธิภาพ
ทดสอบก่อนลงโปรแกรม: ใช้คุณสมบัติโดยใช้วิธีทดสอบก่อนหรือที่เรียกว่า การพัฒนาเพื่อทดสอบ (TDD). TDD ประกอบด้วยการพัฒนาโดยใช้ขั้นตอนการทำซ้ำอย่างง่าย:
TDD ให้ประโยชน์หลายประการ
ประการแรกข้อเสนอแนะ หากการเขียนแบบทดสอบทำได้ยาก การออกแบบที่คุณกำลังมองหาหรือสิ่งที่คุณได้รับมานั้นอาจซับซ้อนเกินไป และคุณจำเป็นต้องทำให้ง่ายขึ้น
ประการที่สอง TDD ช่วยให้โปรแกรมเมอร์เชื่อถือโค้ดที่พวกเขาเขียนและสร้างจังหวะการวนซ้ำที่ดีโดยที่ขั้นตอนต่อไปจะชัดเจนเสมอ
สุดท้าย แต่ไม่ท้ายสุด การใช้ TDD ตั้งแต่เริ่มต้นทำให้มั่นใจได้ว่าโค้ดครอบคลุม 100% จากนั้นชุดทดสอบจะกลายเป็นเครือข่ายความปลอดภัยอย่างแท้จริงสำหรับการเปลี่ยนแปลงในอนาคต สนับสนุนการปรับโครงสร้างโค้ดและสร้างวงจรคุณภาพที่ดี
การออกแบบที่เพิ่มขึ้น: หลักปฏิบัติในการออกแบบส่วนเพิ่มหมายความว่าคุณต้องลงทุนกับการออกแบบแอปพลิเคชันของคุณทุกวัน มองหาโอกาสในการลบความซ้ำซ้อนและทำการปรับปรุงเล็กน้อยเพื่อให้ได้การออกแบบที่ดีที่สุดเท่าที่เป็นไปได้สำหรับสิ่งที่ระบบของคุณต้องการในปัจจุบัน
การบูรณาการอย่างต่อเนื่อง: ใน XP คุณจะรวมงานของคุณเข้ากับพื้นที่เก็บข้อมูลหลักที่ใช้ร่วมกันหลายครั้งต่อวัน ทริกเกอร์การสร้างระบบทั้งหมดโดยอัตโนมัติ การผสานรวมให้เร็วที่สุดและบ่อยที่สุดเท่าที่จะเป็นไปได้ช่วยลดค่าใช้จ่ายในการรวมได้อย่างมาก เนื่องจากทำให้การผสานรวมและความขัดแย้งทางตรรกะมีโอกาสเกิดขึ้นน้อยลง นอกจากนี้ยังเปิดโปงปัญหาด้านสิ่งแวดล้อมและการเสพติดอีกด้วย
รหัสที่ใช้ร่วมกัน (กรรมสิทธิ์รวม): XP ส่งเสริมรหัสที่ใช้ร่วมกันหรือการเป็นเจ้าของร่วมกัน: นักพัฒนาแต่ละรายมีหน้าที่รับผิดชอบรหัสทั้งหมด ส่งเสริมการแลกเปลี่ยนข้อมูล ลดปัจจัยบัสของทีม และเพิ่มคุณภาพโดยรวมของแต่ละโมดูล หากเราพิจารณาหลักการของความหลากหลาย
ฐานรหัสเดียว: โค้ดเบสเดียวเรียกอีกอย่างว่า "การพัฒนาตามลำต้น" หมายความว่าความจริงมีแหล่งเดียวเท่านั้น ดังนั้น แทนที่จะพัฒนาแยกกันเป็นระยะเวลานาน ให้รวมการสนับสนุนของคุณไว้ในสตรีมเดียวแต่เนิ่นๆ และบ่อยครั้ง แฟล็กคุณลักษณะช่วยจำกัดการใช้คุณลักษณะของคุณจนกว่าจะเสร็จสิ้น
แจกทุกวัน: การปรับใช้ในการผลิตอย่างน้อยวันละครั้งเป็นผลสืบเนื่องของการผสานรวมอย่างต่อเนื่อง:. ในความเป็นจริง ทุกวันนี้ หลายทีมก้าวไปไกลกว่านั้นและฝึกฝนการใช้งานอย่างต่อเนื่อง นั่นคือเมื่อใดก็ตามที่มีคนเข้าร่วมการฉีด แอปพลิเคชันจะถูกปรับใช้กับการผลิต
รหัสและการทดสอบ: แนวปฏิบัตินี้หมายความว่าซอร์สโค้ดรวมถึงการทดสอบเป็นสิ่งประดิษฐ์ถาวรเพียงชิ้นเดียวของโครงการซอฟต์แวร์ การมีส่วนร่วมในการสร้างสิ่งประดิษฐ์ประเภทอื่นๆ รวมถึงการจัดทำเอกสาร มักจะสิ้นเปลืองเพราะไม่ได้สร้างมูลค่าที่แท้จริงให้กับลูกค้า
หากคุณต้องการสิ่งประดิษฐ์หรือเอกสารอื่นๆ ให้พยายามสร้างจากรหัสการผลิตและการทดสอบ
การวิเคราะห์สาเหตุที่แท้จริง: เมื่อใดก็ตามที่เกิดข้อบกพร่องในการผลิต อย่าเพิ่งแก้ไขข้อบกพร่องนั้น ตรวจสอบให้แน่ใจว่าคุณทราบสาเหตุแล้วว่าทำไมคุณและเพื่อนร่วมทีมจึงไม่สามารถป้องกันการลื่นไถลได้ จากนั้นทำตามขั้นตอนเพื่อให้แน่ใจว่าจะไม่เกิดขึ้นอีก
นั่งด้วยกัน: ใน XP ทีมต้องการทำงานร่วมกันในพื้นที่เปิดโล่ง วิธีปฏิบัตินี้ส่งเสริมการสื่อสารและความรู้สึกเป็นส่วนหนึ่งของทีม
ทั้งทีม: ทุกคนที่จำเป็นสำหรับความสำเร็จของโครงการเป็นส่วนหนึ่งของทีม XP สิ่งนี้มีบริบทสูง - แตกต่างกันสำหรับแต่ละทีม - และไดนามิกสามารถเปลี่ยนแปลงได้ภายในทีม
พื้นที่ทำงานด้านข้อมูล: พื้นที่ทำงานด้านข้อมูลใช้พื้นที่ทางกายภาพของทีมเพื่อแสดงข้อมูลที่ทำให้ทุกคนสามารถทราบความคืบหน้าของโครงการได้อย่างรวดเร็ว วิธีการดำเนินการนี้อาจแตกต่างกันไป ตั้งแต่บันทึกจริงและกราฟไปจนถึงภาพหน้าจอที่แสดงบอร์ด Kanban และแดชบอร์ดจากซอฟต์แวร์การจัดการโครงการ
การทำงานที่มีพลัง: ใน XP คุณจะทำงานตราบเท่าที่คุณสามารถทำงานอย่างกระฉับกระเฉงได้ ชั่วโมงการทำงานต้องจำกัดไว้ที่ 40 ต่อสัปดาห์ สูงสุด
analisi- เขียนความต้องการของผู้ใช้ในรูปแบบที่เรียกว่าการวิเคราะห์ผู้ใช้ การวิเคราะห์ผู้ใช้มีชื่อที่สื่อความหมายสั้นๆ และคำอธิบายสั้นๆ ของสิ่งที่ต้องดำเนินการ
หย่อน: เมื่อวางแผนวงจร ให้เพิ่มงานย่อยที่ทีมสามารถละทิ้งได้หากจำเป็น สามารถเพิ่มเรื่องราวเพิ่มเติมได้เสมอหากทีมนำเสนอมากเกินไป
รอบ (รายเดือนและรายสัปดาห์): การพัฒนาใน XP เกิดขึ้นในสองรอบหลัก: รอบรายสัปดาห์และรอบเดือน
การประชุม รอบ การเปิดตัวตามกำหนดการ: การพัฒนาใน XP ทำงานในสองรอบหลัก: รอบรายสัปดาห์และรอบรายไตรมาส ในขั้นต้น Kent Beck แนะนำรอบสองสัปดาห์ แต่เปลี่ยนในการพิมพ์ครั้งที่สองของหนังสือของเขา
รอบสัปดาห์: รอบรายสัปดาห์คือ "ชีพจร" ของโครงการ XP วงจรเริ่มต้นด้วยการประชุมที่ลูกค้าเลือกเรื่องราวที่เขาต้องการสร้างในระหว่างสัปดาห์ นอกจากนี้ ทีมจะทบทวนงานของพวกเขา รวมถึงความคืบหน้าของสัปดาห์ที่แล้ว และคิดหาวิธีปรับปรุงกระบวนการ
รอบเดือน: ทุกๆ เดือน ทีมงานจะสะท้อนและระบุโอกาสในการปรับปรุงในกระบวนการของตน ลูกค้าเลือกธีมตั้งแต่หนึ่งธีมขึ้นไปสำหรับเดือนนั้น พร้อมด้วยการวิเคราะห์ในธีมเหล่านี้
จะเริ่มทำงานกับการเขียนโปรแกรมขั้นสูงได้อย่างไร
ทักษะทางเทคนิคและนิสัย XP อาจเป็นเรื่องยากที่จะเรียนรู้ แนวทางปฏิบัติบางอย่างอาจดูแปลกสำหรับโปรแกรมเมอร์ที่ไม่คุ้นเคย
Ercole Palmeri
UK CMA ได้ออกคำเตือนเกี่ยวกับพฤติกรรมของ Big Tech ในตลาดปัญญาประดิษฐ์ ที่นั่น…
พระราชกฤษฎีกา "บ้านสีเขียว" ซึ่งกำหนดโดยสหภาพยุโรปเพื่อปรับปรุงประสิทธิภาพการใช้พลังงานของอาคารได้สรุปกระบวนการทางกฎหมายด้วย...
รายงานประจำปีเกี่ยวกับอีคอมเมิร์ซในอิตาลีของ Casaleggio Associati นำเสนอ รายงานเรื่อง “AI-Commerce: พรมแดนอีคอมเมิร์ซกับปัญญาประดิษฐ์”...
ผลลัพธ์ของนวัตกรรมทางเทคโนโลยีอย่างต่อเนื่องและความมุ่งมั่นต่อสิ่งแวดล้อมและความเป็นอยู่ที่ดีของผู้คน Bandalux นำเสนอ Airpure® เต็นท์…
