كيف أصمم مقاييس رشيقة لمؤسستي؟

تستمر كل المؤسسات تقريبًا في البحث عن المزيد والمزيد من المقاييس للتحكم في شيء ما أو خاصة المؤسسات التي أزورها للعمل كمدرب/مستشار رشيق. تنشأ الحاجة إلى المقاييس أثناء المناقشة مع الإدارة ولكن في كثير من الأحيان تفشل الإدارة في شرح الهدف من وراء طلب الكثير من المقاييس.
أشعر أن هذه المقاييس تؤدي في بعض الأحيان إلى سوء التواصل، وتحدد هدفًا خاطئًا وتخلق غياب الثقة داخل الفريق. يجب أن تركز المنظمة بشكل أكبر على بناء الممارسات والعمليات المبتكرة الأفضل لتحقيق الهدف المعلن. المقاييس ضرورية بالتأكيد لأنها تساعد المنظمة في تحديد مسار العمل المستقبلي وتساعد الفريق على الحفاظ على تركيزه ولكن المقاييس دون ممارسة؟ لا لأن ذلك قد يحبط الفريق والفريق المحبط سينتج منتجًا رديء الجودة.
فيما يلي مثال على المقاييس دون ممارسة أفضل:-
تغطية الكود بنسبة 80% – ما سبب هذه المقاييس؟ هل هذا للحكم على الأداء الفردي أم للتأكد من أن الكود قابل للصيانة؟ إذا لم يتم توصيل الهدف بشكل جيد إلى الفريق ولم يتم تأسيس ممارسات التعليمات البرمجية النظيفة فما الذي سيفعله أعضاء الفريق؟
قد ينتهي الأمر بالفريق إلى تحقيق 80% من التغطية البرمجية ولكن كيف؟ بإضافة المزيد من الاختبارات هنا وهناك لإرضاء المقاييس ولكن ما هو الهدف؟
وبالمثل، هناك العديد من المقاييس الأخرى مثل “نسبة العيوب” و”العيب لكل ميزة” و”تعقيد الكود” و”سرعة الفريق” و”دقة التقدير” وما إلى ذلك. يمكن التلاعب بها بسهولة إذا لم يعرف الفريق الهدف من وراء هذه المقاييس. يجب أن تكون هناك عملية لتحديد المقاييس ويجب أن يكون لكل مقياس هدف واضح.
قبل القياس يجب التأكد من وجود ممارسة محددة. يجب أن تتماشى كل من الممارسة والمقياس مع الهدف.
من الأفضل دائمًا قياس النتائج وليس المخرجات.
المقاييس
تقدم المنظمة مقاييس تطوير البرمجيات لضمان جودة أفضل للمنتج وإنتاجية أفضل لفريق التطوير. فيما يلي بعض المقاييس الشائعة المدرجة أدناه:-
تغطية الكود
كفاءة إزالة العيوب
العيوب لكل ميزة
سرعة الفريق
الرسم البياني التنازلي
وقت الرصاص
زمن الدورة
نسبة إعادة فتح العيوب
تغطية الاختبار
انظر إلى هذه المقاييس عن كثب لفهم الغرض منها وانظر إلى ما نفعله بهذه المقاييس في مؤسستنا.
تغطية الكود – هذه مقاييس لضمان تغطية الكود بشكل جيد بالاختبار، وسهولة إعادة هيكلة الكود، وسهولة قراءة الكود وصيانته.
كفاءة إزالة العيوب (DRE) – الغرض من DRE هو الحكم على الإنتاجية من حيث التسليم بجودة أفضل/متفق عليها. تسليم ميزة جديدة وكذلك إزالة العيوب من الميزة المطورة.
وبالمثل ترتبط المقاييس الأخرى أيضًا إما بالإنتاجية أو الجودة ولكن السؤال الأكبر “ما هي المقاييس التي تعني وأيها يجب اعتمادها جميعًا؟
اعتماد المقاييس
يجب أن تُظهر المقاييس فعالية ممارسات المؤسسة.
يجب أن تتماشى المقاييس مع قيم العمل
يجب أن تكون المقاييس مرتبطة بهدف المشروع لإثبات الإنجاز
يجب أن تتكامل المقاييس مع سير العمل. يجب أن يتم توليد البيانات تلقائيًا بدلاً من جمعها يدويًا.
يجب أن تكون المقاييس مفيدة لمبادرة التحسين وإعداد خطط العمل.
يجب تحديد الهدف للمقاييس ويجب أن يكون الفريق على دراية بالنطاقات الدنيا والعليا المتوقعة.
لماذا الممارسات؟
تساعد الممارسات في تحسين الجودة ونضج الفريق وزيادة الإنتاجية والسماح للأعمال بالتنبؤ بالإصدارات. الممارسة تعني العادة والروتين ولا تحتاج إلى التذكر. من المفترض أن تكون طريقة طبيعية لتطوير البرمجيات داخل المؤسسة. يجب أن تنتج هذه الممارسات بشكل منهجي بيانات يمكن قياسها لفهم الفعالية والكفاءة. إذا لم تكن الممارسات في مكانها الصحيح ولكن المقاييس فقط تبدأ المنظمة في مطاردة البيانات ويمكن أن يتم طهي/التلاعب بالبيانات التي لن تعكس الواقع.
ما هي الممارسات الرشيقة؟
هناك العديد من الممارسات ولكن يجب على المنظمة اختيارها بناءً على المنتج والجودة المتوقعة وتعقيد المنتج. فيما يلي بعض الممارسات التي يمكن أخذها بعين الاعتبار.
Scrum – تستند إلى فلسفة أجايل المبنية على الفحص والتكيف والشفافية. يحتوي Scrum على بعض الأدوار والأحداث والمصنوعات اليدوية المحددة ويساعد في إنتاج مقاييس تتماشى مباشرة مع قدرة الفريق وتساعد المنظمة على التنبؤ بالنتائج.
هناك 3 مقاييس جميلة ينتجها سكروم.
السرعة – تساعد المؤسسة على معرفة مقدار ما يمكن أن يقدمه الفريق في كل تكرار لمعرفة دورة الإصدار.
المخطط الهبوطي – يساعد الفريق على الاستمرار في التركيز على الالتزام والتوافق مع الهدف.
مخطط الإصدار المُنجز – يساعد المؤسسة على تتبع التسليمات وضبط الأولوية.
Kanban – مفيد بشكل أساسي لتتبع التغييرات المستمرة في الإنتاج وأيضًا في التحسين المستمر. مرة أخرى هناك 3 مقاييس رئيسية.
المهلة الزمنية – هي الوقت من وقت تقديم التغيير من قبل العميل (ووضعه على اللوحة) حتى وقت تنفيذ كل التغييرات.
وقت الدورة الزمنية – هو فقط مقدار الوقت الذي يقضيه الفريق في العمل على التغيير (دون الوقت الذي يقضيه في الانتظار على اللوحة). لذلك، يجب أن يبدأ قياس وقت الدورة الزمنية عندما يدخل التغيير في عمود “العمل”، وليس قبل ذلك.
الإنتاجية – هي كمية عناصر العمل التي يتم تسليمها في فترة زمنية معينة (على سبيل المثال أسبوع، شهر، ربع سنة).
TDD – التطوير المدفوع بالاختبار هو ممارسة مفيدة لتقليل مشكلات الجودة حيث تتم كتابة الاختبارات قبل التعليمات البرمجية. وهذا يساعد تلقائيًا في كتابة كود الجودة من البداية. يمكن قياس فعالية TDD باستخدام أي أدوات تغطية التعليمات البرمجية. يساعد TDD أيضًا في إنتاج كود أقل، فقط الكود المطلوب لاجتياز الاختبار. كود أقل يعني عيوبًا أقل. هذه في الأساس ممارسة تعزز الجودة المدمجة بدلاً من التفكير اللاحق.
وبالمثل، هناك العديد من الممارسات الأخرى التي تسمح بإنتاج مجموعة متنوعة من المقاييس مثل DevOps، والتكامل المستمر، وإدارة تكوين البرامج، والتسليم المستمر، إلخ.
الخلاصة
يجب أن تكون المقاييس مستمدة من الممارسات، وإذا لم تكن كذلك، فعلى الأرجح أنها لن تعكس الصورة الحقيقية حول الإنتاجية والجودة ورضا العملاء.
يجب أن تتماشى جميع المقاييس إما مع الخط العلوي (الإيرادات) أو الخط السفلي (كفاءة التشغيل) أو CSAT (رضا العملاء) أو ESAT (رضا الموظفين).
ابحث عن تدريبنا القادم
اشترك في النشرة الإخبارية لسبوتو
ابق على اطلاع على أحدث اتجاهات Agile & Scrum.