มีประโยชน์เล็กน้อยในการแก้ไขข้อบกพร่อง [ปิด]

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

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

มีข้อได้เปรียบเล็กน้อยในการแก้ไขข้อบกพร่องหรือไม่? มีคำอื่นที่อธิบายแนวคิดนี้หรือไม่

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

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

ปัจจัยทั้งหมดเหล่านี้ควรนำมาพิจารณาด้วยเมื่อจัดลำดับความสำคัญ

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

นี่คือการอ้างอิงที่ดี

http://www.joelonsoftware.com/articles/fog0000000043.html

คุณแก้ไขข้อบกพร่องก่อนที่จะเขียนรหัสใหม่หรือไม่? Microsoft Word สำหรับ Windows เวอร์ชั่นแรกถือเป็นโครงการ“ เด ธ มาร์ช” [... ] เพราะช่วงการแก้ไขข้อผิดพลาดไม่ได้เป็นส่วนหนึ่งของกำหนดการที่เป็นทางการ [... ]

Microsoft ได้นำบางสิ่งบางอย่างมาใช้ในระดับสากล [... ] ลำดับความสำคัญสูงสุดคือการกำจัดข้อบกพร่องก่อนที่จะเขียนรหัสใหม่ใด ๆ [... ] โดยทั่วไปยิ่งคุณรออีกนานก่อนที่จะแก้ไขข้อผิดพลาดค่าใช้จ่าย (ในเวลาและเงิน) .

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

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

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

สมมติว่าคุณกำลังทำงานให้กับองค์กรการค้าที่มีก็จะเป็นคนที่มีที่ตระหนักถึงต้นทุนและผลประโยชน์การวิเคราะห์

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

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

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

ดูทั้งสองโพสต์ที่นี่ในวิศวกรรมซอฟต์แวร์:

การแก้ไขข้อบกพร่องซึ่งจะให้ผลประโยชน์ด้านต้นทุนที่มากที่สุด

เกือบทุกข้อบกพร่องที่รายงานเป็นข้อบกพร่องที่มีลำดับความสำคัญสูง

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

ในสถานการณ์ดังกล่าวข้างต้นจะมีสองวิธีการที่สมเหตุสมผล:

1. แก้ไขปัญหาหากทำเช่นนั้นได้จริง

2. ระบุช่วงที่เอาต์พุตของโปรแกรมน่าเชื่อถือและระบุว่าโปรแกรมนั้นเหมาะสำหรับใช้กับข้อมูลที่ทราบว่าสร้างค่าภายในช่วงที่ถูกต้องเท่านั้น

วิธีการ # 1 จะกำจัดข้อผิดพลาด วิธีที่ # 2 อาจทำให้ความคืบหน้าน้อยกว่าที่เหมาะสมสำหรับวัตถุประสงค์บางอย่างมากกว่าที่เป็นเช่นนั้น แต่ถ้าไม่จำเป็นต้องให้โปรแกรมจัดการค่าที่มีปัญหาที่อาจไม่เป็นปัญหา

แม้ว่าการไม่สามารถจัดการค่า 99.95 ถึง 100.0 ได้อย่างถูกต้องเป็นผลมาจากความผิดพลาดในการเขียนโปรแกรม [เช่นการตัดสินใจที่จะเอาท์พุทสองหลักทางด้านซ้ายของจุดทศนิยมก่อนที่จะปัดเศษไปที่หนึ่งหลังจากนั้นจึงให้ 00.00] ข้อผิดพลาดหากโปรแกรมจะถูกระบุเป็นอย่างอื่นเป็นการผลิตผลลัพธ์ที่มีความหมายในกรณีดังกล่าว [บังเอิญปัญหาดังกล่าวเกิดขึ้นใน Turbo C 2.00 printf code ในบริบทนั้นมันเป็นข้อผิดพลาดอย่างชัดเจน แต่รหัสที่เรียกว่า printf ที่ผิดพลาดนั้นจะมีข้อผิดพลาดหากว่ามันอาจสร้างผลลัพธ์ในช่วงที่มีปัญหา]

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

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

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

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

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

หวังว่าจะอธิบายแนวคิดได้ดีขึ้นเล็กน้อย! แน่นอนฉันจะหลีกเลี่ยงการคิดเกี่ยวกับเรื่องนี้ในแง่ทั่วไป - ข้อผิดพลาดทุกข้อมีเอกลักษณ์และควรได้รับการปฏิบัติเช่นนี้

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

ดังนั้น "การโต้แย้ง" ของพวกเขาจึงเป็นจริง

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

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