ระเบียบวิธีว่องไวคืออะไร? [ปิด]

27

มีใครสามารถอธิบายเกี่ยวกับวิธีการแบบเปรียวในประโยคง่ายๆ

development-process agile

— Chankey Pathak
แหล่งที่มา

3

ตามที่ครู CompSci ของฉันในวิทยาลัย, "วิธีน้ำตก, เร็วขึ้น"

— Malfist

11

@ มัลลิสต์หวังว่าเขา / เธอจะอยู่ในแวดวงวิชาการซึ่งความเสียหายนั้น จำกัด อยู่ที่สมอง ;-)

— Steven A. Lowe

@Steven A. Lowe สิ่งที่น่าเศร้าคือตอนที่สามของหนังสือเรียนของเราคือ "การพัฒนาซอฟต์แวร์ Agile" และเขาก็ยังไม่รู้ว่ามันคืออะไร

— Malfist

2

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

— Steven A. Lowe

1

วิธีการเปรียวเป็นเหมือนภาษาจีน - คุณไม่ได้รับจนกว่าคุณจะได้เรียนรู้มัน)

— งาน

22

Agile เป็นสิ่งและแนวทางปฏิบัติมากมาย แต่ฉันคิดว่าแก่นแท้ของมันคือการพัฒนาซ้ำ ๆ

การทำซ้ำ: คิดน้ำตกที่เล็กมาก นั่นคือวิธีน้ำตก (ข้อกำหนด -> spec-> รหัส -> การทดสอบ) แต่แทนที่จะทำในช่วงเวลาหนึ่งปีหรือมากกว่านั้นคุณต้องทำในช่วงสองสามสัปดาห์เพื่อจัดการชิ้นงานโดยรวม โครงการ. ในตอนท้ายของ 'การทำซ้ำ / การวิ่ง / การเพิ่มขึ้น' คุณจะมีชุดฟังก์ชันการทำงานเพิ่มเติมเพิ่มเติมที่มีขนาดเล็ก แต่สมบูรณ์และผ่านการทดสอบแล้ว

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

— Fishtoaster
แหล่งที่มา

นี่ไม่ใช่คำตอบที่ถูกต้องจริงๆ Agile ไม่ใช่วิธีการ แต่เป็นปรัชญา

— RibaldEddie

32

ฉันคิดว่าไม่มีอะไรทำให้ดีไปกว่า Manileest Agile:

เรากำลังเปิดเผยวิธีที่ดีกว่าในการพัฒนา
ซอฟต์แวร์ด้วยการทำและช่วยเหลือผู้อื่นให้ทำ
ผ่านงานนี้เราได้เห็นคุณค่า:

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

นั่นคือในขณะที่มีค่าในรายการ
ทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

จากhttp://agilemanifesto.org/

— Andy Lowry
แหล่งที่มา

1

gotcha เพียงอย่างเดียวคือถ้าคุณไม่ได้เห็นกระบวนการที่ไม่ดีผู้ประกาศก็ไม่ยุติธรรม มันต้องใช้การเปรียบเทียบกับสิ่งที่ไม่ดีเพื่อให้ได้รับการประกาศอย่างชัดเจน ถึงกระนั้น +1 เพราะมีคนจำนวนมากสับสนและคล่องแคล่วในการต่อสู้ในวันนี้ และถึงตอนนั้นพวกเขายังสับสน SCRUM กับ Scrum + XP

— MIA

2

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

— user8865

2

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

— NoChance

13

สำหรับฉันความคิดที่สำคัญที่สุดคือ:

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

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

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

— JohnFx
แหล่งที่มา

6

ในประโยคเดียวดูเหมือนว่านี้:

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

นี่มาจากคำนิยามของวิกิพีเดียและฉันชอบมันมาก ฉันเน้นหลักการสำคัญ

3

ฉันต้องการเพิ่มสิ่งที่ไม่ใช่ Agile มีร้านค้ามากมายที่เรียกร้องให้มีความคล่องตัว แต่ในทางที่หมายความว่าพวกเขาไม่สนใจที่จะวางแผนโครงการและคาดหวังว่าสิ่งต่าง ๆ จะเกิดขึ้นในระยะเวลาอันสั้นอย่างไร้เหตุผล

Agile! = ไม่มีแผนโครงการ มันยากที่จะจัดการกับคนที่คิดว่าคำพูดนั้นเป็นเท็จเพราะพวกเขามักจะเป็นประเภทการจัดการและไม่ใช่เรื่องง่ายที่จะโต้แย้ง

— q303
แหล่งที่มา

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

— Chankey Pathak

ตกลง หลายคนคล่องแคล่วเป็นเพียงวิธีการทำสิ่งที่ถูก

— SmallChess

2

Andy ได้เชื่อมโยงกับ Agile Manifesto แล้วซึ่งฉันคิดว่าครอบคลุมไปแล้ว

ฉันคิดว่ามันมีประโยชน์ที่จะดูว่า Agile Manifesto มาจากไหน มีวิธีการมากมายที่มีองค์ประกอบทั่วไปและแรงจูงใจที่คล้ายกันมาก: Extreme Programming (XP), Scrum, DSDM, การพัฒนาซอฟต์แวร์แบบปรับได้, Crystal, การพัฒนาที่ขับเคลื่อนด้วยคุณสมบัติ, การเขียนโปรแกรมเชิงปฏิบัติ (รายการจากAlistair Cockburn ) ผู้คนที่เสนอวิธีการเหล่านั้นตัดสินใจใช้คำศัพท์ทางการตลาดเพื่อปกปิดสิ่งที่พวกเขามีร่วมกันเพื่อให้พลังของสิ่งที่พวกเขาพูดจะเพิ่มขึ้น

ที่น่าสนใจ (ตามสิ่งที่ใครบางคนบอกฉัน) มีชื่อจำนวนมากในตัวเลือกที่สามารถเลือกได้แทน "เปรียว" - หนึ่งในนั้นคือ "ปรับตัว" โดยส่วนตัวแล้วฉันคิดว่าเป็นคำเดียวที่สรุปได้ดีกว่าความคล่องแคล่วนั้นดีกว่า "เปรียว" จริงๆ!

— FinnNk
แหล่งที่มา

2

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

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

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

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

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

— deaks
แหล่งที่มา