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

ما هذا؟
Zero Bug Policy (ZBP) هي سياسة لمعالجة الأخطاء تستند إلى القواعد:
"عندما يظهر خطأ جديد ، يجب أن تقرر على الفور إصلاحه في المستقبل القريب ، أو إغلاقه كـ" لن إصلاح "."
في هذه الحالة ، لا تذهب إلى التطرف: لا تخطئ على الإطلاق أو تعدل كل شيء على التوالي. من المهم أن تضع لنفسك معايير الجودة للميزات التي تكون مستعدًا لإعطاءها للمستخدمين والنظر في المهمة المكتملة بعد تصحيح جميع الأخطاء المهمة.
فوائد السياسة
- يعلم الجميع عدد الأخطاء المفتوحة وهذا العدد محدود للغاية.
- مطلوب وقت أقل للعثور على المهمة في نظام تتبع الأخطاء.
- لا توجد اجتماعات طويلة لفرز وإعادة ترتيب أولوية تراكم الخطأ.
- قد يصبح الأمر أسهل نفسيًا لك عندما لا تتعرض لضغوط بسبب تراكم الأعمال المتضخمة.
- عند التصحيح ، ليس من الضروري أن نتذكر ما كان هناك "منذ مائة عام" ، ومرة أخرى لتغرق في السياق.
تبدو رائعة ، لكن الآثار الجانبية ممكنة.
- انخفاض جودة المنتج.
- تدهور مستوى فريق الاختبار. (لماذا نضيع الوقت في البحث عن أخطاء معقدة ومعقدة إذا كانت لا تزال غير ثابتة؟).
- يتم فقد مصدر مفيد للمعلومات (في شكل تراكم مفتوح) لأعضاء الفريق الجدد.
وهناك دائما عامل الخوف.
"إذن ، سنغلق الخطأ ، وماذا لو كان مستقبل مشرق يأتي عندما يكون هناك وقت لإصلاحه؟"
من غير المرجح أن يكون لديك وقت إضافي. يشبه تخزين خردة قديمة على الشرفة: لا تفقد الأمل في استخدام أحد هذه الأشياء ، ولكن على الأرجح لن يحدث ذلك أبدًا.
نحن هنا نغلق الخطأ ، ويرى المستخدم في همز.
سيقوم مستخدم منزعج الكتابة إلى الدعم ، والتي بدورها سوف أبلغكم. سيكون من الضروري مراجعة أولوية هذا الخطأ وإعادة تحديد ما إذا كان يجب تصحيحه أم لا.
تطبيق
الجزء الأصعب هو أن تبدأ. للقيام بذلك ، تحتاج إلى العثور على الوقت والموارد والرغبة (تسطير ضروري) لتجريف كامل الأخطاء المتراكمة من الأخطاء القديمة واتخاذ قرار جذري لتصحيح أو إغلاق.
ثم ، جمع القوة وتصحيح "الناجين" بعد تنظيف الأخطاء.
وابدأ العيش وفق القواعد الجديدة.
ابدأ في تقسيم الأخطاء إلى فئتين:
- تم العثور على خطأ أثناء اختبار ميزة جديدة ؛
- علة وجدت على همز / مع الانحدار.
إذا وجدت خطأً عند اختبار ميزة جديدة ، فيجب عليك اتخاذ قرار على الفور:
- إصلاح الخلل قبل اكتمال تطوير / اختبار الميزة ؛
- إعادة تصنيف الخلل (ربما هذا في الواقع تحسين) ؛
- ربما لا يتعين عليك الحصول على خطأ على الإطلاق إذا كنت لن تقوم بتحريره.
في مرحلة الاستراحة من العملية ، من الأفضل البدء في إغلاق هذه الأخطاء وإغلاقها باستخدام دقة "لن إصلاح" التي تصف سبب الإغلاق. بناءً على هذه البيانات ، ستتمكن من تحليل العيوب وتطوير معايير الجودة في فريقك بشكل صحيح.
وإذا كان هناك خطأ في همز / مع الانحدار ، فأنت بحاجة إلى تحديد ما يجب القيام به.
- إصلاح الخلل وتلبية الموعد النهائي اعتمادا على أولوية الخلل. وقت الإصلاح هو من "الآن" إلى عمودين. إذا لم يتم إصلاح الخلل في عمودين ، فيجب إغلاقه.
- تغيير نوع المهمة من "علة" إلى "تحسين".
- أغلق الخطأ مع الدقة "لن إصلاح" مع وصف سبب الإغلاق.
لتحديد أولوية الخطأ ، نستخدم مصفوفة تجمع بين أهمية الخطأ في أمر محدد وتكرار حدوثه.

تفاصيل أخرى
من المحتمل أن يكون الربح من استخدام هذا النهج غير مهم إذا لم تقم بتغيير العمليات والمناهج في التطوير والاختبار بشكل إضافي.
ما الذي سيقلل عدد الأخطاء عند تطوير ميزة جديدة؟
- استخدم مجموعة واسعة من الممارسات التقنية والتنظيمية (على سبيل المثال ، تنفيذ بوابات الجودة ، تحليل التأثيرات ، اختبار رشيق).
- تخلص من مواقع توليد الأخطاء عن طريق إعادة بناء الكود القديم.
- تصحيح الأخطاء بسرعة ، مما يقلل من تأثيرها في المستقبل.
- اكتب autotests للكشف عن مناطق المشكلة بشكل أسرع و
منع تكرار الأخطاء.
المقاييس
من أجل عدم استخلاص استنتاجات حول مشاعرنا ، فإننا نراقب مقاييس ZBP (أنا أحب Tableau حقًا ونستخدمها لإنشاء تقارير). يتيح لك ذلك تتبع التقدم المحرز في الديناميات وتسليط الضوء على المشاكل الناشئة.

النتائج
ما هي نتائج العمل على ZBP معنا؟
نحن نعيش في العالم الحقيقي ، وفي أنقى صوره ، لم يكن من الممكن استخدام السياسة.
واجه شخص ما مشكلة Legacy وعدم القدرة على إصلاح بعض الأخطاء لفترة محدودة. لقد تراكمت لدى شخص ما تراكم على مر السنين ، كان مخيفًا فقط الاقتراب منه ولم يكونوا في عجلة من أمرهم لبدء هذه العملية.
ولكن بشكل عام ، تمكنت العديد من الفرق من تحليل تراكمها ووضع شريط معين على عدد الأخطاء المفتوحة. بدأت الفرق في تقييم الأخطاء بشكل أفضل واتخاذ قرارات أسرع حول الحاجة إلى التصحيح.
النتائج
- يتطلب الأمر الكثير من الجهد لتغيير نهجك في التعامل مع الأخطاء.
- لكي تنجح العملية ، يجب أن تصبح جزءًا من الثقافة الهندسية للشركة.
- يجب على الفريق تحقيق التوازن بين تصحيح الخطأ وتطوير العدو.
كل الخير وأقل البق!