คุณจะจัดการกับปัญหาที่เพิ่มขึ้นเรื่อย ๆ เพื่อที่จะได้รับการ“ แก้ปัญหา” ได้อย่างไร?

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

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

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

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

หากไม่คุณสามารถทำเครื่องหมายว่า "ไม่แก้ไข" หากไม่ร้ายแรงพอที่จะพิสูจน์เวลาที่ใช้ในการแก้ไข

คุณควรแก้ไขข้อผิดพลาดเฉพาะเมื่อแอปพลิเคชันมีค่ามากกว่าโดยไม่มีข้อบกพร่อง

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

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

บริษัท บางแห่งไม่เขียนบรรทัดรหัสใหม่หากยังมีข้อบกพร่องที่ค้างอยู่ คนอื่นไม่ต้องกังวลจนกว่าขั้นตอนการทดสอบก่อนส่งมอบ

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

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

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

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

• หากหัวหน้าของคุณใส่ใจเกี่ยวกับตั๋วที่เปิดมากเกินไปอย่าเพิ่งสร้างเรื่องเล็กน้อยในตอนแรก คุณควรจะ prgamatic และไม่เพิ่มคุณสมบัติ / การแก้ไขใด ๆ ที่ไม่มีประโยชน์ ถ้ามันจะทำให้ชีวิตของคุณง่ายขึ้นในการขัดรหัสหรือปรับแต่ง UI จากนั้นให้เพิ่ม อย่าเพิ่งทำงานให้ตัวเองโดยพยายามแก้ไขข้อบกพร่องเล็ก ๆ น้อย ๆ ในผลิตภัณฑ์ไม่มีอะไรสมบูรณ์แบบ
• ใส่บั๊ก / ฟีเจอร์ที่ไม่สำคัญลงในเหตุการณ์สำคัญปัจจุบัน แต่อยู่ภายใต้ลำดับความสำคัญต่ำ หากมีการกล่าวถึงการร้องเรียน / คำขอเพิ่มเติมเกี่ยวกับปัญหาคุณสามารถชนลำดับความสำคัญได้
• ปิด / แก้ไขสิ่งที่คุณสามารถทำได้เช่นจะไม่แก้ไขไม่สามารถทำซ้ำทำซ้ำ ฯลฯ ข้อบกพร่องบางอย่างอาจไม่สำคัญที่จะแก้ไขหรือเป็นคำขอคุณลักษณะที่ใช้เวลานานเกินไป บางครั้งคุณต้องบอกให้บุคคลที่ขอการแก้ไข / คุณสมบัติเหล่านี้ "ไม่เสียใจเราไม่มีเวลา"
• จัดลำดับความสำคัญข้อบกพร่องตามความจำเป็นและมีรายการตั๋วของคุณเรียงลำดับความสำคัญและเหตุการณ์สำคัญ
• หากพวกเขาจะไม่สร้างเหตุการณ์สำคัญให้ย้ายพวกเขาไปสู่เหตุการณ์สำคัญในอนาคต
• หากตั๋วขึ้นอยู่กับตั๋วอื่นที่เสร็จสมบูรณ์ให้ทำเครื่องหมายว่าถูกบล็อกหรือจัดระเบียบตั๋วเป็นลำดับชั้นดังนั้นจึงเห็นได้ชัดว่า ticket-x และ ticket-y เกี่ยวข้องกัน
• หากตั๋วต้องการความคิดเห็นจากใครบางคนมอบหมายให้กับบุคคลนั้น

ในที่สุดคุณจะมีตั๋วที่มีลำดับความสำคัญต่ำนั่งอยู่เสมอ แต่คะแนนด้านบนจะช่วยให้คุณลดขนาดตั๋วลงได้

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

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

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