การใช้ซอฟต์แวร์การติดตามบั๊ก / การติดตามปัญหาเพื่อหารือเกี่ยวกับคำถามการออกแบบเครื่องมือใหม่ ๆ

ใครบ้างมีประสบการณ์กับการใช้ซอฟต์แวร์การติดตามบั๊ก / การติดตามปัญหาเช่น bugzilla, ตั๊กแตนตำข้าวหรือ JIRA ไม่เพียง แต่สำหรับข้อบกพร่องหรืองาน แต่ยังเพื่อเริ่มต้นและรักษาการสนทนาที่ในที่สุดนำไปสู่การตัดสินใจ?

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

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

ข้อดีที่ฉันเห็นในนี้:

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

ข้อเสีย:

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

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

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

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

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

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

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

อย่างที่ฉันพูดไปมันเป็นความคิดที่ดีถ้ามันช่วยคนได้ ไม่มีอะไรผิดปกติกับมัน แต่สำหรับการตัดสินใจได้อย่างมีประสิทธิภาพ / การตัดสินใจต้องการสิ่งที่เป็นรูปธรรม

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

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

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

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

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

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

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

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

FogBugz เป็นวิธีที่จะไป มันไม่ฟรี คุณสมบัติใหม่ล่าสุดทำให้การใช้วิธีการแบบเปรียวง่ายยิ่งขึ้น

วิธีที่ง่ายและฟรีไปคืออาสนะ

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