ควรเปิดกรณีใหม่สำหรับข้อบกพร่องหรือควรเปิดข้อบกพร่องเป็นกรณีใหม่หรือไม่

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

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

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

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

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

ผู้จัดการของฉันไม่เห็นด้วยกับฉันที่ระบุว่าเป็นการง่ายกว่าที่จะใช้เวลาทั้งหมดในฟีเจอร์นี้ถ้ามันทั้งหมดในกรณีเดียว

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

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

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

สำหรับกรณีเช่นของคุณฉันใช้วิธีย่อย / ภารกิจระดับสูง (แนวคิดที่ฉันเลือกจากJIRAไม่สามารถบอกได้ว่า FogBugz สนับสนุนอย่างชัดเจนหรือ^ไม่ ) ด้วยวิธีนี้รายการสัญลักษณ์แสดงหัวข้อย่อย "ไคลเอนต์ไคลเอนต์" ไปที่งานระดับสูงในขณะที่ "ซ้ำนักพัฒนา" ที่สำคัญสำหรับฉันจะปรากฏในงานย่อย

เมื่องานระดับสูงคือ "เปิด" ผมสร้างย่อยงานใหม่ที่จะติดตามความพยายามเพิ่มด้วยตนเอง

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

นอกจากนี้ยังช่วยให้มีเหตุผลที่ชัดเจนในกรณีที่การใช้งานคุณสมบัติต้องใช้เวลามากกว่าที่คาดไว้เดิม

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

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

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

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

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

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

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

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

พบข้อบกพร่องก่อนหรือหลังผลิตภัณฑ์ 'ส่ง / ปล่อย' ให้กับลูกค้าหรือไม่

หากเป็นก่อนการเผยแพร่ข้อบกพร่องควรติดตามกับตั๋วต้นฉบับ

หากเป็นหลังจากปล่อยแล้วบั๊กแต่ละตัวควรเป็นตั๋วของตัวเอง

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

เมื่อกรณีได้ผ่านขั้นตอนเหล่านี้ทั้งหมดและ QA ปิดกรณีปัญหาใหม่ที่พวกเขาพบจะถูกบันทึกเป็นข้อบกพร่อง

ระบบนี้ทำงานได้ดีสำหรับเรา

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