จัดประเภทงาน / ข้อบกพร่องตามความเสี่ยงของการเปลี่ยนแปลง

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

เราใช้ JIRA ดังนั้นฉันจึงเริ่มติดฉลากปัญหาเพื่อติดตามการประมาณนี้ ฉันสังเกตเห็นว่าฉันลงเอยด้วยการใช้หลายเมตริกเพื่อจัดหมวดหมู่ข้อบกพร่อง / งาน:

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

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

มีใครเคยจัดการกับเรื่องแบบนี้มาก่อนหรือไม่?

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

โพสต์บล็อกที่อธิบายการติดตามบั๊กแบบหลายมิติจะพิจารณาที่อยู่นี้รวมถึงมุมมองของนักพัฒนา: PEF และ REV

ค่า PEF เป็นมุมมองของผู้ใช้:

• P Ain - ว่าเจ็บปวดเป็นข้อผิดพลาดเมื่อมีการพบ?
• ส่งออก - ใช้ความพยายามมากแค่ไหนในการแก้ไข?
• F ‍ ความถี่ - ข้อผิดพลาดเกิดขึ้นบ่อยแค่ไหน?

ด้าน REV มาจากมุมมองของนักพัฒนา:

• R ISK - วิธีการที่มีความเสี่ยงคือการแก้ไข?
• ส่งออก - ใช้ความพยายามเท่าไหร่ในการแก้ไข?
• V ‍erifiability - มันง่ายแค่ไหนที่จะตรวจสอบว่าข้อผิดพลาดได้รับการแก้ไข?

แต่ละสิ่งเหล่านี้วัดในระดับ 1..9 โดยที่ 1 ต่ำ / ง่ายและ 9 สูง / ยาก ตัวเลขจะถูกรวมเข้าด้วยกันเพื่อให้คะแนนสำหรับ PEF และ REV

ส่วนที่กล่าวถึงบิตที่อธิบาย:

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

ปัจจัยเหล่านี้เป็นความพยายามและความเสี่ยงที่อธิบายไว้ใน REV

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

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

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

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

อย่างไรก็ตามการตัดสินจากสิ่งที่คุณเขียนคุณดูเหมือนจะมีสองประเด็น:

1. คุณกำลังติดต่อกับโปรแกรมเมอร์ใหม่หรือมือใหม่
2. ดูเหมือนว่าคุณภาพของ (มาก / บาง) ของรหัสของคุณจะเป็นปัญหา

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

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

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

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

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

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