เหตุใดการเขียนโปรแกรมขั้นสูง (XP) จึงล้าสมัยเพื่อ Agile, Kanban และอื่น ๆ


15

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

ในช่วง 10 ปีที่ผ่านมารูปแบบการทำงานของ XP ดูเหมือนจะล้าสมัยไปแล้วเนื่องจากวิธีการทำงาน: Agile และ / หรือ Kanban ทำไม? ตั้งแต่ XP ดูเหมือนว่าฉันจะเป็นวิธีที่ดีมากในการทำงานและเป็นจำนวนมากเกี่ยวกับการเขียนโปรแกรมในขณะที่ Agile และ Kanban เป็นมากกว่าเกี่ยวกับกระบวนการ


28
XP เป็นวิธีที่คล่องตัว ดังนั้น "Agile" จึงไม่สามารถแทนที่ XP ได้
Joachim Sauer

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

3
มีรายการวิพากษ์วิจารณ์ที่น่าสนใจเกี่ยวกับ XP บนวิกิพีเดียแต่ถ้าคุณสแกนมันส่วนใหญ่จะใช้กับ Agile โดยทั่วไป
yannis

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

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

คำตอบ:


21

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

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

โดยเฉพาะ Kanban ไม่ได้มาจากการพัฒนาซอฟต์แวร์ แต่กำเนิดมาจากการสร้างรถยนต์ (ฉันเตือนว่า Toyota แนะนำให้ใช้สำหรับการสร้างรถยนต์และผู้พัฒนาซอฟต์แวร์บางรายได้นำไปใช้และขยายตัว)

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

XP แนะนำสิ่งเหล่านี้มากขึ้นหรือน้อยลง (หรืออย่างน้อยก็ให้ชื่อที่เป็นประกาย) และสิ่งต่าง ๆ ต่อไปนี้นำมาใช้เพราะมันใช้งานได้ดี


3
ตามที่ @refro ได้กล่าวไว้เช่นกัน Scrum และ Kanban ไม่ได้รวมการเขียนโปรแกรมคู่หรือการตรวจสอบโค้ด (แต่พวกเขาไม่ได้ยกเว้นสิ่งเหล่านี้) ทั้งสองเป็นวิธีการจัดการโครงการมากกว่ากระบวนการพัฒนาซอฟต์แวร์ และเช่นนี้พวกมันสามารถใช้งานได้กับหลากหลายสาขานอกการพัฒนาซอฟต์แวร์ ในขณะที่ XP เป็นวิธีการพัฒนาซอฟต์แวร์โดยเฉพาะ สิ่งเหล่านี้สามารถอยู่ร่วมกันได้ - คุณสามารถจัดการทีม XP ของคุณได้ในแบบ Scrum
PéterTörök

16

ในมุมมองของฉัน XP เป็นวิธีปฏิบัติในการเขียนโปรแกรม Scrum และ Kanban เป็นแนวทางปฏิบัติสำหรับการจัดการโครงการ พวกเขามีความสัมพันธ์ แต่ไม่ได้แทนที่กัน

ในโครงการ kanban ของเราเราใช้การเขียนโปรแกรมคู่ (ส่วนใหญ่สำหรับส่วนที่ซับซ้อนและการดีบัก), TDD, CI ดังนั้นจึงยังคงใช้อยู่ แต่ฝ่ายบริหารผลักดันฝ่ายบริหารโครงการให้หนักขึ้น


1
การเขียนโปรแกรมคู่เป็นเหมือนการติดขัดในการฝึกฝนนักดนตรี มันใช้งานได้บางครั้งและบางครั้งก็ไม่ทำงานเลย ในบางกรณีก็อาจจะนำมาใช้เป็นวิธีการทั่วไปในการเล่นและในกรณีที่หายากมากเป็นวิธีการเขียน
Alex Yu

0

Extreme Programming เป็นเรื่องเกี่ยวกับกลไกของการพัฒนาในขณะที่ Agile เป็นเรื่องเกี่ยวกับ SDLC (วงจรการพัฒนาซอฟต์แวร์)

เหตุผลหลักที่คุณไม่ได้ยินเกี่ยวกับ "Extreme Programming" ตามชื่ออีกต่อไปคือการใช้คำว่า "Extreme" ในฐานะคำคุณศัพท์เชิงบวกซึ่งเป็นสิ่งที่ล้าสมัยไปแล้ว 90's-to-early-00's ที่ถูกมองว่าซ้ำซากตอนนี้ ส่วนใหญ่เป็นเพียงเหยื่อการตลาด นั่นเป็นเหตุผลที่คุณเกือบจะได้ยินมันเรียกว่า "XP" โดยเฉพาะทางวาจา


0

ฉันมีความคิดเกี่ยวกับการเขียนโปรแกรมคู่

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

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

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

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


0

Agile นั้นสามารถทำการตลาดได้มากขึ้นเนื่องจากเกี่ยวข้องกับผู้มีส่วนได้ส่วนเสียที่แตกต่างกันซึ่งมีบทบาทและความรับผิดชอบต่าง ๆ ที่เกี่ยวข้องกับกระบวนการสร้างซอฟต์แวร์

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


0

ฉันคิดเสมอว่า Scrum เป็นรุ่นของ Agile ที่ง่ายที่สุดในการขายให้กับผู้บริหาร: การประมาณที่กำหนดขึ้นมาคือหลักคำสอนที่ค่อนข้างชัดเจนธรรมชาติที่ชัดเจน ("คุณไม่ได้ทำ Scrum จริงๆ - รู้สึกผิด!") ...

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

ในด้าน XP การเขียนโปรแกรมคู่ไม่ได้ดึงดูดการจัดการโดยเฉพาะอย่างยิ่งการจัดการที่ไม่ใช่ด้านเทคนิค

หากต้องการวางไว้ในรูปแบบการเปรียบเทียบ SAT, Scrum: XP :: The Monkees: The Beatles

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.