ฉันใช้วิธีการแบบว่องไว (SCRUM) เป็นเวลาประมาณสามปีแล้วและฉันเห็นข้อดีบางประการโดยเฉพาะอย่างยิ่งในความคิดเห็นระยะสั้นในหลาย ๆ ระดับ (จากลูกค้าที่มีการเข้าถึงคุณลักษณะการใช้งานก่อนหน้านี้จากผู้ทดสอบที่สามารถทดสอบคุณลักษณะต่างๆ ในไม่ช้าพวกเขาจะถูกนำไปใช้งานจากนักพัฒนาซอฟต์แวร์รายอื่นที่สามารถให้ข้อเสนอแนะเกี่ยวกับโค้ดใหม่ผ่านการตรวจสอบและอื่น ๆ )
ในทางกลับกันฉันมีสองปัญหาที่เปิดอยู่สิ่งแรกที่ฉันจะพยายามอธิบายในคำถามนี้
ปัญหา: ความยากในการรับการออกแบบที่ดี
ฉันพยายามทำการปรับโครงสร้างใหม่ทันทีที่รหัสเกิดความยุ่งเหยิงฉันเขียนการทดสอบหน่วยให้มากที่สุดเท่าที่จะทำได้ (ซึ่งจะช่วยป้องกันข้อผิดพลาดโดยทั่วไปและเมื่อทำการปรับโครงสร้างใหม่โดยเฉพาะ) ในอีกทางหนึ่งการพัฒนาฟีเจอร์ที่ซับซ้อนเพิ่มขึ้นทีละน้อยด้วยความมุ่งมั่นในชีวิตประจำวันและการคิดทบทวนโค้ดอย่างต่อเนื่องเมื่อมันไม่มีโครงสร้างไม่อนุญาตให้ฉันสร้างงานออกแบบที่ดีจริงๆ
โมดูลที่ออกแบบมาอย่างดีเท่านั้นที่ฉันสามารถผลิตได้เมื่อไม่นานมานี้โดยใช้แนวทางที่แตกต่าง: ฉันวิเคราะห์ปัญหาสองสามวัน (ที่จริงแล้วฉันมีปัญหาที่เกิดขึ้นในใจของฉันเป็นเวลาสองสามเดือนก่อนที่ฉันจะ ) ร่างการออกแบบที่มีรายละเอียดค่อนข้างมากของชั้นเรียนที่เกี่ยวข้องทั้งหมดและความสัมพันธ์ของพวกเขาอีกสองสามวันและจากนั้นล็อคตัวเองในสำนักงานของฉันและเขียนรหัสทั้งหมดโดยการทำงานโดยไม่หยุดชะงักเป็นเวลาประมาณสามสัปดาห์ ผลที่ได้คือสิ่งที่ดีที่สุดที่ฉันผลิตในขณะที่มีข้อบกพร่องน้อยมากที่ค่อนข้างง่ายต่อการค้นหาและแก้ไขและด้วยการออกแบบที่ชัดเจนมากซึ่งไม่จำเป็นต้องมีการเปลี่ยนแปลงที่เกี่ยวข้องตั้งแต่นั้นมา
ดังนั้นถึงตอนนี้ฉันพบว่ามีประสิทธิภาพมากขึ้นเพื่อให้ได้ภาพรวมของสิ่งที่ฉันต้องการทำล่วงหน้ากว่าการเริ่มเขียนโค้ดทีละน้อยด้วยความหวังว่าภาพใหญ่จะปรากฏขึ้นอย่างน่าอัศจรรย์ในกระบวนการ ด้วยความพยายามอย่างที่สุดของฉันการพัฒนาที่เพิ่มขึ้นเพียงเล็กน้อยทำให้ฉันออกแบบแย่ลงเสมอ
คำถาม : มีใครมีประสบการณ์คล้ายกันบ้างไหม? ฉันกำลังใช้ SCRUM ในทางที่ผิดหรือฉันควรให้ความสนใจกับสิ่งใดหากฉันต้องการพัฒนาทีละน้อยและยังคงจบลงด้วยซอฟต์แวร์ที่ออกแบบมาอย่างดี? หรือฉันควรกำหนดเวลาเรื่องราวของผู้ใช้ออกแบบก่อนเริ่มการเข้ารหัสจริง นี่ถือว่าเป็นแนวปฏิบัติที่ดีอย่างน้อยที่สุดสำหรับคุณลักษณะที่ซับซ้อนกว่าค่าเฉลี่ยหรือไม่
แก้ไข - หมายเหตุ
ฉันตระหนักถึงความจริงที่ว่าการออกแบบที่ดีไม่ใช่สิ่งที่สมบูรณ์และไม่มีคุณค่าในตัวมันเอง แต่ขึ้นอยู่กับบริบทและสิ่งนั้นควรมุ่งที่การออกแบบที่ดีพอสำหรับปัญหาที่เกิดขึ้น
ตัวอย่างเช่นฉันไม่สนใจ (มากเกินไป) เกี่ยวกับการออกแบบที่ดีถ้าฉันต้องใช้องค์ประกอบแบบง่ายที่ (1) จะต้องพร้อมให้เร็วที่สุด (2) จะใช้เพียงครั้งเดียว (3) ไม่ใช่ ใช้โดยส่วนอื่นของระบบ (YAGNI)
ฉันสนใจเกี่ยวกับการออกแบบที่ดีเมื่อมีการใช้ส่วนประกอบ (1) หลายครั้งและในรุ่นต่างๆที่ต่างกันของผลิตภัณฑ์ (2) ต้องได้รับการบำรุงรักษาและขยายเวลาเมื่อผ่านไป (3) มีส่วนประกอบอื่น ๆ มากมายขึ้นอยู่กับมัน .
The only well-designed module I could produce recently I obtained by taking a different approach- คุณตอบคำถามของคุณเอง คุณยังต้องมีการออกแบบล่วงหน้า คุณไม่สามารถคาดหวังการออกแบบที่ดีเพียงแค่เติบโตจากการปรับโครงสร้างซ้ำ มันไม่ทำงานอย่างนั้น