คุณจัดการกับการติดตามบั๊กในลักษณะที่เป็นมิตรกับโปรแกรมเมอร์และเจ้าหน้าที่ที่ไม่ใช่ด้านเทคนิคอย่างไร [ปิด]

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

แน่นอนในฐานะโปรแกรมเมอร์ฉันสามารถใช้ตั๊กแตนตำข้าวได้โดยไม่มีปัญหา แต่การติดตามบั๊กมีประโยชน์อย่างไรเมื่อทุกคนที่เกี่ยวข้อง ** ในโครงการพบว่าพวกเขาออกแบบมาไม่ดีและยากที่จะใช้ว่าพวกเขาต้องการสร้างเอกสาร Google ด้วยรายการหัวข้อย่อย จากข้อบกพร่องที่พบหรือข้อเสนอแนะที่พวกเขาอาจมี

ฉันกำลังจะติดตั้งฟอรัมดูเหมือนว่าฉันจะชอบวิธี "ตรงกลาง" ระหว่างตัวติดตามบั๊กและรายการหัวข้อย่อยแบบธรรมดา อย่างน้อยฟอรัมอนุญาตให้ตรวจสอบและรวมศูนย์การสนทนาเกี่ยวกับข้อเสนอแนะ

ในกรณีที่ความกังวลของฉันไม่ชัดเจนคำถามของฉันสามารถสรุปได้ดังนี้:

คุณจัดการข้อผิดพลาดและรายงานข้อเสนอแนะต่อผู้ใช้ที่ไม่ใช่ด้านเทคนิคได้อย่างไร?

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

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

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

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

เราใช้Redmineสำหรับสิ่งนี้ เคล็ดลับสำคัญคือกลุ่มผู้ใช้ที่ไม่เคยเห็น redmine - พวกเขาเพียงแค่ส่งอีเมลไปที่ support@example.com การใช้เทคนิคขั้นสูงเพิ่มเติมเล็กน้อย - ส่วนใหญ่เป็น BCCing บัญชี redmine ของเราและรวมถึงปัญหา # - เราสามารถให้การอัปเดตต่อไปเป็น redmine สำหรับคนที่มีความก้าวหน้ามากขึ้นเราเพียงแค่ปล่อยให้พวกเขาใช้ redmine โดยตรงเพราะมันค่อนข้างทันสมัยและใช้งานง่ายกว่า MANTIS ที่เคยเป็นมา

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

ฉัน Redmine ที่สองและส่วนตัวใช้Bug Genie (ใช่ชื่อวิเศษ แต่ออกแบบมาอย่างดีถ้าคุณอยู่ในสภาพแวดล้อม PHP และ / หรือไม่สามารถรัน Ruby ด้วยเหตุผลใด ๆ ก็ตาม) สำหรับการติดตามปัญหาที่เป็นมิตรกับผู้ที่ไม่ใช่ ผู้ใช้เทคโนโลยี

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

เราใช้ "คุณสมบัติ Application Lifecycle Management ของ Visual Studio" ซึ่งก่อนหน้านี้รู้จักกันในนาม Team Systems ข้อได้เปรียบที่สำคัญอย่างหนึ่งสำหรับเราคือคุณสามารถส่งออกผลการสืบค้น (เช่น "ข้อกำหนดทั้งหมด" หรือ "ข้อผิดพลาดทั้งหมดที่มีค่า pri 2 หรือต่ำกว่าซึ่งจะไม่อยู่ในรุ่นถัดไป") ไปยังสเปรดชีตหรือเอกสารโครงการ ผู้จัดการโครงการผู้ใช้ขั้นปลายผู้มีส่วนได้เสีย ฯลฯ สามารถแก้ไขไฟล์เหล่านี้ - เปลี่ยนลำดับความสำคัญอัปเดตคำอธิบายกำหนดให้กับบุคคลอื่นไม่ว่าอะไรก็ตาม - และเมื่อไฟล์ทำให้กลับไปยังเครื่องที่เชื่อมต่อกับ TFS คุณสามารถกดเผยแพร่และ การเปลี่ยนแปลงกลับไปสู่ที่เก็บ โปรแกรมเมอร์ทำงานกับรายการงานโดยตรงจาก Visual Studio แต่โปรแกรมเมอร์ที่ไม่ใช่โปรแกรมเมอร์จะไม่เข้าใกล้ VS นอกจากนี้ยังมีไซต์ SharePoint สำหรับแต่ละโครงการ TFS เพื่อให้คุณไม่ต้อง '

อาจไม่ใช่ตัวเลือกหากคุณไม่ใช่ร้าน VS แต่ควรลองนึกถึงถ้าคุณเป็น

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

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

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