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

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

มีงานวิจัยใดบ้างที่จัดกลุ่มข้อบกพร่องโดยพิจารณาจากประโยชน์ด้านต้นทุนหรือตัวชี้วัดที่คล้ายคลึงกัน

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

1. โปรแกรมเมอร์ทุกคนในทีมมีความสามารถเท่าเทียมกันในการแก้ไขข้อบกพร่องใด ๆ
2. ไม่มีกำหนด

ระบบติดตามบั๊กทั่วไปมีสองฟิลด์บางทีอาจเป็นสามฟิลด์ที่ระบุอัตราส่วนผลประโยชน์ต้นทุนบั๊ก:

1. ลำดับความสำคัญ (มอบหมายโดยเจ้าของธุรกิจ)
2. ความรุนแรง (การจำแนกข้อผิดพลาด - ร้ายแรงถึงต่ำ)
3. ชั่วโมงโดยประมาณ (คาดเดาว่าจะใช้เวลานานเท่าใด)

ดังที่คุณทราบนี่จะระบุว่าบั๊กใดเป็นสิ่งสำคัญในการทำงาน

ระบบนำเสนอในPEF / REV: การติดตามบั๊กแบบหลายมิติเพิ่มข้อมูลเพิ่มเติมเกี่ยวกับองค์ประกอบทางธุรกิจและนักพัฒนาเพื่อให้ได้รับประโยชน์ด้านต้นทุนบั๊ก

ค่าทั้งหมดอยู่ในระดับ 1 .. N (ค่าสูงสุดเท่ากันสำหรับแต่ละรายการ)

PEF ถูกระบุโดยธุรกิจ:

• P ain - ความเจ็บปวดเป็นอย่างไร
• E ffort - ต้องใช้ความพยายามมากแค่ไหนในการแก้ไขข้อบกพร่อง
• F requency - บั๊กเกิดขึ้นบ่อยแค่ไหน

REV มาจากผู้พัฒนา:

• R isk - การแก้ไขความเสี่ยงของระบบเป็นอย่างไร
• E - ความพยายามเท่าไหร่ที่จะมีการแก้ไขข้อผิดพลาด
• การลบได้ V - การตรวจสอบการแก้ไขข้อผิดพลาดเป็นเรื่องง่ายเพียงใด

ตัวอย่างเช่นหากคุณมีความผิดพลาดที่เกิดขึ้นบ่อยครั้งซึ่งง่ายต่อการแก้ไข (เปิดการบันทึกอัตโนมัติ) ซึ่งอาจเป็น PEF ที่ 7,1,1 (คะแนน 9) ในขณะที่แก้ไขมันอาจเกี่ยวข้องกับการเปลี่ยนแปลงโมดูลหลักและมี REV ที่ 9,3,2 (คะแนน 14)

ในทางกลับกันคุณอาจมีความรำคาญที่มีอยู่เสมอ (3,3,9 - คะแนน 15) ที่มีการแก้ไขเล็กน้อย (1,1,3 - คะแนน 5)

ในตัวอย่างนี้ความรำคาญดูเหมือนจะเป็นสิ่งที่คุ้มค่า / ได้ประโยชน์มากกว่าในการทำงาน

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

ฉันมักจะแบ่งข้อบกพร่องออกเป็นสามประเภท: Crashing, Annoying, Cosmetic (พวกเขาอาจเรียกว่า 1, 2, 3 - นั่นไม่สำคัญจริงๆ) จากนั้นจึงวางการประเมินโดยรวมลงในเวลาที่จำเป็นในการแก้ไขข้อผิดพลาดทุกตัว มีการประมาณการที่อัปเดตคร่าวๆตลอดเวลา)

เมื่อแก้ไขข้อบกพร่อง Crashing> น่ารำคาญ> เครื่องสำอางจากนั้นฉันก็แค่ทำ "งานที่สั้นที่สุดก่อน" เพื่อให้ได้ปริมาณงานที่มากที่สุดเท่าที่จะทำได้

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

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

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

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

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

นอกจากสิ่งที่คนอื่นพูดเกี่ยวกับการจำแนกประเภทของข้อบกพร่อง ฯลฯ แล้วให้ลองพิจารณาที่ Afferent Coupling (Ca) เพื่อพิจารณาระดับของความสำคัญที่อาจเป็นตัวแทนของข้อผิดพลาด หากคุณมีข้อผิดพลาดในโมดูลที่มีจำนวน Ca สูงฉันอาจจะมองหาการแก้ไขที่หนึ่งก่อนเพราะมันอาจเป็นประโยชน์ต่อส่วนประกอบอื่น ๆ ในระบบ Ca ช่วยให้คุณกำหนดระดับความรับผิดชอบและโมดูลที่รับผิดชอบซึ่งมีข้อบกพร่องเกิดขึ้นกับแอปพลิเคชันทั้งหมด (อ่านเพิ่มเติมเกี่ยวกับ Ca ที่นี่: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html )

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

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

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

ดังนั้นคุณไม่เพียง แต่ต้องพิจารณาค่าใช้จ่ายของบั๊กเฉพาะเจาะจงในแง่ของค่าใช้จ่ายในการแก้ไขและมันส่งผลกระทบโดยตรงต่อผู้ใช้ ในตลาดและการรับรู้นั้นมีผลต่อยอดขายในอนาคตอย่างไร

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