هل من الممكن تتبع أو قياس سبب الخلل أم أن هذا مجرد طلب عواقب غير مقصودة?

Question

هل هناك طريقة لتتبع أو قياس سبب الخلل الذي لن يؤدي إلى عواقب غير مقصودة من أعضاء فريق التطوير?أضفنا مؤخرا القدرة على تعيين سبب خطأ في نظام التتبع الخاص بنا.تشمل أمثلة الأسباب ما يلي:رمز سيء ، رمز مفقود ، متطلبات غير كاملة ، متطلبات مفقودة ، اختبار غير مكتمل إلخ.لم أكن من دعاة هذا لأنني رأيت أنه يؤدي إلى سلوكيات غير مقصودة من فريق التطوير.حتى الآن تم إخفاء هذا الحقل عن أعضاء الفريق ولم يتم استخدامه بنشاط.

نحن الآن في منتصف مشروع حيث لدينا عدد أكبر من المعتاد من الأخطاء وسيكون من الجيد الحصول على هذا النوع من المعلومات من أجل فهم أفضل للمكان الذي أخطأنا فيه وأين يمكننا إجراء تحسينات في المستقبل (أو التعديلات الآن).من أجل الحصول على بيانات جيدة عن سبب الأخطاء ، سنحتاج إلى فتح هذا المجال للإدخال من قبل أعضاء فريق التطوير وضمان الجودة وأنا قلق من أن يؤدي ذلك إلى سلوكيات سيئة.على سبيل المثال ، قد لا يرغب الأشخاص في إصلاح عيب لم يخلقوه لأنهم سيشعرون أنه ينعكس بشكل سيئ على أدائهم ، أو قد يضيع الناس الوقت في الجدل حول تصنيف العيب لأسباب مماثلة.

هل وجد أي شخص آلية للقيام بهذا النوع من التتبع دون قيادة السلوكيات السيئة?هل من الممكن أن نتوقع بيانات مفيدة من أعضاء الفريق إذا شرحنا للفريق السبب وراء البيانات (لا لدفع مقاييس الأداء الفردية, ولكن مقاييس نجاح المشروع)?هل هناك آخر, أفضل طريقة للقيام بهذا النوع من الشيء (أكثر مخصصة بعد الوفاة أو مناقشة مفتوحة حول القضايا ربما)?

Answer 1

تحتوي الكثير من حزم التحكم في الإصدار على أشياء مثل svn blame.هذا ليس مقياسا مباشرا لتتبع خطأ ما ، ولكن يمكنه إخبارك بمن قام بتسجيل التغييرات في إصدار يحتوي على خطأ كبير فيه.

هناك أيضا برامج مثل http://www.bugzilla.org/ يساعد ذلك في تتبع الأشياء بمرور الوقت.

ولكن بقدر ما تبحث حقا في سبب وجود الأخطاء ، نعم ، من الجدير بالتأكيد النظر فيها ، على الرغم من أنني لا أستطيع إعطاء مقياس قياسي لجمع تلك المعلومات.وهناك عدد من الأسباب لماذا قد يكون نظام عربات التي تجرها الدواب جدا:

• مواصفات مكتوبة بشكل سيئ
• الجداول الزمنية السريعة
• البرمجة منخفضة المهارة
• معنويات سيئة
• عدم وجود اختبار بيتا أو ضمان الجودة
• عدم إعداد البرامج بحيث يكون من الممكن حتى اختبار بيتا أو ضمان الجودة
• نسبة ضعيفة من الوقت المستغرق في تنظيف الأخطاء مقابل الحصول على وظائف جديدة
• نسبة ضعيفة من الوقت المستغرق في إجراء تحسينات خالية من الأخطاء مقابل الحصول على وظائف
• نظام معقد يتجاوز من السهل كسره
• بيئة متغيرة خارج قاعدة التعليمات البرمجية ، مثل إدارة الجهاز
• اللوم على الأخطاء التي تؤثر على تعويض المبرمج أو الترويج

هذا فقط على سبيل المثال لا الحصر...إذا كان الكثير من الأخطاء يمثل مشكلة كبيرة ، فإن الإدارة والمبرمجين الرئيسيين وأي أصحاب مصلحة آخرين في العملية برمتها يحتاجون إلى الجلوس ومناقشة المشكلة.

Answer 2

يمكن أن تكون معدلات الأخطاء العالية هي أعراض جدول زمني هو هرع للغاية أو غير مرن.التبديل إلى نهج عيب صفر قد يساعد.إصلاح جميع الأخطاء قبل العمل على رمز جديد.

الأسباب المعنية

هي تقنية جيدة لمعرفة ما إذا كان لديك منطقة مشكلة.المقاييس النموذجية التي رأيتها وتصادفها هي مقسمة بين:

أخطاء المواصفات
• (مفقودة، غير صحيح، إلخ.)
• أخطاء التطبيق (الرمز الحاد، رمز مفقود، البيانات السيئة، إلخ.)
• اختبارات غير صحيحة / لا يوجد خطأ (توقعات غير صحيحة عموما، أو مواصفات لم يتم تنفيذها بعد)

يمكن أن تكون

reveiwing والتحقق من أسباب العيب مفيدة.