ทำไมเราต้องการทั้งลำดับความสำคัญและความรุนแรง

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

ฉันรู้วิธีการตั้งค่าจัดหมวดหมู่ ฯลฯ ฉันรู้ว่า IEEE / ISO จำเป็นต้องทำเช่นนั้น ฉันไม่เห็นว่าทำไม

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

ข้อบกพร่องวันที่และเวลา

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

วันที่: 15 ธันวาคมข้อบกพร่องมีความสำคัญสูงมาก

วันที่: 1 กุมภาพันธ์ข้อบกพร่องมีลำดับความสำคัญต่ำ

การยิงขีปนาวุธบั๊กโดยไม่ตั้งใจ

ข้อผิดพลาด: ซอฟแวร์การควบคุม ICBM pukes เมื่อไปจาก 28 กุมภาพันธ์ถึง 1 มีนาคมในปีหารด้วย 4 ผลที่ได้คือการเปิดตัวที่ไม่ได้รับคำสั่ง

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

คำที่ไม่เหมาะสมโดยไม่ตั้งใจบนหน้าจอ

ข้อผิดพลาด: ข้อความล้นพื้นที่ของพวกเขาบนหน้าจอส่งผลให้มีการอ้างอิงดูหมิ่นบ๊อบปรากฏโดยไม่ได้ตั้งใจ (โลกแห่งความจริง: เรามีคนทำงานอยู่ในแผนก "Final Ass" "Ass" = "Assembly")

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

คุณเขียน:

ฉันหมายถึงมันจำเป็นต้องแก้ไขอย่างรวดเร็วหรือไม่

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

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

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

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

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

IMHO การวางทั้งความสำคัญและความรุนแรงเป็นเพียงระบบราชการ

ในทางปฏิบัติคุณเพียงแค่ต้องใช้หนึ่งใน "ความสำคัญ" บ่อยครั้งที่มีการใช้ลำดับความสำคัญเป็นลำดับแรกและจากนั้นความรุนแรงจะถูกใช้เป็นคำศัพท์ทางเทคนิคเช่น "high = ล่มระบบหรือทำให้ใช้ไม่ได้", "Medium = buggy พฤติกรรมอาจเป็นอันตราย", "ต่ำ = ความรำคาญรำคาญ แต่ไม่เป็นอันตราย"

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

... แต่ในที่สุดในฐานะนักพัฒนา (หรือผู้จัดการ ฯลฯ ) คุณเพียงแค่ต้องรู้ในลำดับที่คุณควรแก้ไข / ปรับปรุงสิ่งต่าง ๆ นั่นคือทั้งหมดที่ ดังนั้นหนึ่งวัดก็เพียงพอแล้ว

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

ฉันคิดว่ามันเป็นอันตรายเพราะทำให้มันชัดเจนน้อยลงว่าข้อผิดพลาดที่สำคัญกว่า:

• บางคนอาจคิดว่าบั๊ก "วิกฤติ" มีลำดับความสำคัญสูงกว่าบั๊ก "ลำดับความสำคัญสูง"
• ผู้ใช้บางคนรายงานข้อผิดพลาดอาจสร้างความสับสนและความสำคัญ
• ... โดยรวมมันค่อนข้างจะเพิ่มความสับสนว่าสิ่งที่ควรจะจัดการกับข้อบกพร่อง

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

แน่นอน 'รุนแรง' และ 'ลำดับความสำคัญ' อาจถูกตีความในรูปแบบที่แตกต่างกัน

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

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

ฉันได้ออกแบบและดำเนินการตามกระบวนการใน บริษัท ซอฟต์แวร์ที่ได้รับการรับรอง ISO9001: 2007 มีการอัปเดตมาตรฐานตั้งแต่ปี 2550 ดังนั้นอาจมีข้อกำหนดเพิ่มเติมที่ฉันไม่ทราบ ... อย่างไรก็ตาม:

มาตรฐาน ISO9001 คือการรับรองว่า บริษัท ของคุณออกแบบและดำเนินกระบวนการที่มีลูปข้อเสนอแนะสำหรับการปรับปรุงกระบวนการเมื่อมีการระบุข้อบกพร่องของผลิตภัณฑ์และกระบวนการ

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

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

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

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

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

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

สำหรับเหตุผลที่ให้ความสำคัญและความรุนแรงต่างกันมาก:

ตัวอย่างง่ายๆ ลองนึกภาพกรณีที่คุณมีสถานที่แคบ ๆ ที่ป้องกันการขยายระบบของคุณ - อัลกอริทึมบางอย่างมีความซับซ้อน O (N ^ 3) โดยที่ N นับจำนวนร้านค้าของลูกค้า ลูกค้าบอกว่าจะเปิดสาขาใหม่ 200 แห่งในปีหน้าและการคำนวณที่จำเป็น (การกระจายสินค้าการวางแผนการขนส่งและอื่น ๆ ) จะไม่เสร็จในเวลาที่กำหนด แต่ปัจจุบันลูกค้ารายนี้มีร้านค้าเพียง 30 แห่งและมีทรัพยากรเพียงพอ งานในการปรับแต่งอัลกอริทึมนี้ (เป็น O (N ^ 2) หรือดีกว่า) เป็นสิ่งสำคัญอย่างแน่นอน (คุณจะสูญเสียลูกค้าหากไม่ได้ใช้งาน) แต่มีแนวโน้มที่จะไม่เร่งด่วน: คุณมีเวลาสองสามเดือนในการใช้อัลกอริธึมใหม่

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

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