على الرغم من أن المهارات العملية والمعرفة بلغات وأدوات وتقنيات برمجة محددة هي المفتاح للحصول على وظيفة بدوام كامل كمطور برامج، إلا أن هناك مؤشرًا قيمًا آخر يمكن اعتباره من نواحٍ عديدة بمثابة افتراض مسبق للنجاح في هذه المهنة: إنتاجية. يعد قياس الإنتاجية أمرًا يحتاج جميع مطوري البرامج المحترفين إلى فهمه وأخذه بعين الاعتبار نظرًا لأن مقاييس الأداء مهمة بطبيعتها لأي فريق تطوير برمجيات في بيئة الأعمال الحالية.
لماذا تعتبر إنتاجيتك كمطور مهمة؟
في عصر التطوير Agile وDevOps ودورات إصدار البرامج المتقلصة، عندما يحتاج المطورون إلى شحن إصدارات جديدة من المنتجات في أسرع وقت ممكن، تستخدم الشركات مقاييس إنتاجية متعددة ومختلفة لتقييم أداء المبرمجين الفرديين والفريق ككل. بالنظر إلى هذا من وجهة نظر المطور، يمكن أن يخدم قياس الأداء عددًا من الأغراض القيمة، مما يساعدك على تتبع التقدم المحرز في مهارات البرمجة لديك، مما يسمح لك بتحقيق نمو مهني ثابت. المبرمجون ذوو الإنتاجية العالية هم الذين ينتهي بهم الأمر إلى تلقي عروض الرواتب المذهلة والعمل في المشاريع الأكثر إثارة. ولكن حتى لو لم تكن من ذوي الإنجازات العالية وتريد فقط أي وظيفة في مجال تطوير البرمجيات وأن تكون ناجحًا فيها بشكل معقول، فلا تزال بحاجة إلى أن يكون لديك على الأقل فهم أساسي لمؤشرات الأداء وكيفية استخدامها لقياس إنتاجية مدخلاتك في العمل. وهو ما سنتحدث عنه اليوم.
مقاييس قياس إنتاجية تطوير البرمجيات
ما هي مقاييس إنتاجية تطوير البرمجيات؟
مقاييس تطوير البرمجيات هي مجالات عمل البرمجة حيث يمكن تطبيق القياسات الكمية من أجل تتبع أداء المطور وجودة العمل وإنتاجيته. يعتمد كل مقياس إنتاجية على أخذ البيانات من عملية التطوير واستخدامها لقياس الإنتاجية. نظرًا لأن أي شيء متعلق بتطوير البرمجيات ليس أمرًا سهلاً ومباشرًا، يمكنك القول أن قياس إنتاجية البرمجة هو أيضًا غير متسق تمامًا ومجزأ عبر الصناعة. أو ببساطة، يمكن للفرق والشركات المختلفة استخدام مؤشرات أداء مختلفة تمامًا والتعامل مع هذه المشكلة من عدد من الزوايا. لذلك لا داعي للقلق بشأن تعلم كل المقاييس التي قد تستخدمها فرق تطوير البرامج. ولكن من المستحسن بالتأكيد معرفة وفهم المقاييس الأكثر شيوعًا والأكثر شيوعًا المستخدمة في صناعة تطوير البرمجيات بشكل عام.
ما هي أنواع مقاييس إنتاجية تطوير البرمجيات الموجودة؟
وبطبيعة الحال، هناك العديد من مقاييس الإنتاجية المختلفة التي تقترب من قياس الأداء على مستويات وزوايا مختلفة. فيما يلي الأنواع الأكثر شيوعًا لمقاييس الإنتاجية هذه:
- المقاييس الرسمية التي تركز على الحجم.
تركز هذه المقاييس على قياس حجم نتائج عمل المبرمج، مثل سطور التعليمات البرمجية (LOC)، وطول تعليمات التعليمات البرمجية، وتعقيد التعليمات البرمجية، وما إلى ذلك. وتعتبر هذه المقاييس بشكل متزايد قديمة في صناعة تطوير البرمجيات اليوم.
- مقاييس الإنتاجية التي تركز على الوقت والوظيفة.
هناك مجموعة مختارة من مقاييس الإنتاجية التقليدية المستخدمة في تطوير برمجيات الشلال، مثل الأيام النشطة، ونطاق الوظائف التي يتم شحنها في فترة زمنية محددة، ومعدلات تغيير التعليمات البرمجية، وعدد المهام المعينة، وما إلى ذلك.
- مقاييس عملية التطوير الرشيقة.
من المحتمل أن تكون مقاييس عملية التطوير الرشيقة، مثل تقرير توقف الركض والسرعة والمهلة الزمنية ومدة الدورة وغيرها، هي المقاييس الأكثر استخدامًا بين فرق تطوير البرمجيات اليوم. سنتحدث عن مقاييس Agile بمزيد من التفاصيل لاحقًا في المقالة.
- مقاييس التحليلات التشغيلية.
تركز هذه المجموعة من المقاييس على قياس أداء البرنامج في بيئة الإنتاج الحالية. متوسط الوقت بين حالات الفشل (MTBF)، ومتوسط وقت الاسترداد (MTTR)، ومعدل تعطل التطبيق هي المقاييس الأكثر استخدامًا هنا.
اختبار البرمجيات لديه مجموعة من المقاييس الخاصة به لقياس جودة اختبار النظام، مثل النسبة المئوية للاختبارات الآلية، وتغطية التعليمات البرمجية، وما إلى ذلك.
أخيرًا، المقياس النهائي لأي جزء من البرامج هو تجربة العميل النهائي، وهناك مجموعة كاملة من المقاييس لذلك أيضًا، مثل درجة جهد العميل (CES)، درجة رضا العملاء (CSAT)، صافي درجة المروج (NPS) و اخرين.
مقاييس تطوير البرمجيات رشيقة
كما ترون، من السهل جدًا أن تضيع في كل تعقيدات مقاييس إنتاجية البرامج. ومع ذلك، فإن المقاييس الوحيدة التي يجب أن يكون مطور البرامج العادي على دراية بها هي مقاييس Agile، التي تستخدم عادة من قبل فرق تطوير البرمجيات اليوم كمعايير لقياس إنتاجية الفريق عبر أجزاء مختلفة من دورة حياة تطوير البرمجيات. دعونا ندرج مقاييس Agile الرئيسية والأكثر استخدامًا.
1. سبرينت Burndown.
تعد تقارير Sprint Burndown أحد المقاييس الرئيسية لفرق تطوير سكروم Agile. كما هو الحال في Agile، يتم تنظيم عملية التطوير من خلال سباقات السرعة المحددة بفترة زمنية، يتم استخدام Sprint Burndown كوسيلة لتتبع إكمال المهام أثناء سباق السرعة. يتم استخدام الساعات أو نقاط القصة كوحدة قياس. الهدف هو تحقيق تقدم ثابت وتقديم العمل بما يتماشى مع التوقعات الأولية. يساعد Sprint Burndown الفرق على قياس وتيرة العمل وتعديلها عند الحاجة.
2. سرعة الفريق.
السرعة هي مؤشر رئيسي آخر، والذي يعتمد أيضًا على الساعات أو نقاط القصة كوحدة قياس. فهو يقيس متوسط مقدار العمل الذي يكمله الفريق أثناء السباق ويستخدم للتقدير والتخطيط في جميع أنحاء المشروع. يعد تتبع السرعة أمرًا مهمًا للتأكد من أن الفريق يقدم أداءً ثابتًا.
3. نقاط القصة.
على مستوى أعضاء فريق التطوير الفردي، تعد نقاط القصة مقياسًا قيمًا، حيث أن حجم القصص التي يقدمها المبرمج خلال كل إصدار يعد مؤشرًا على إنتاجية هذا المبرمج.
4. مخطط التحكم بالدورة.
يقيس إجمالي الوقت من لحظة بدء العمل على مهمة أو عنصر متراكم آخر حتى اكتماله. يسمح بتتبع أوقات الدورة والتحكم فيها مما يوفر نتائج أكثر قابلية للتنبؤ بها.
5. الإنتاجية والقيمة المقدمة.
يقوم مديرو المشاريع بتحليل المهام المخصصة للمطورين وتعيين قيمة لهم. يتم بعد ذلك استخدام هذا المقياس لقياس إنتاجية الفريق، أو بعبارة أخرى، مقدار العمل ذي القيمة المضافة المنجز.
6. رمز الاضطراب.
يعد تغيير التعليمات البرمجية مقياسًا آخر جدير بالذكر لأنه يستخدم لقياس إنتاجية الفريق ككل وتتبع أداء المبرمجين الفرديين. يقيس تغيير التعليمات البرمجية عدد المرات التي يقوم فيها المطور بإزالة أسطر التعليمات البرمجية المضافة مسبقًا أو إجراء تغييرات عليها، وما هي النسبة المئوية للتعليمات البرمجية المكتوبة مسبقًا التي ينتهي بها الأمر بالتغيير أو التخلص منها.
آراء الخبراء
أخيرًا، لإضافة بعض المنظور، هناك بعض الاقتباسات حول هذا الموضوع من قبل متخصصين ذوي خبرة في صناعة تطوير البرمجيات. "آمل ألا تتطلع إلى "مقارنة" مقاييسك بنوع ما من المعايير أو حتى بأداء فريق آخر في شركة أخرى. كان في كل مكان عملت فيه اختلافات فريدة في تعريفاتهم لنقاط القصة، والسرعة، والتقديرات بالساعة، والمهام، وما إلى ذلك، مما يجعل من المستحيل تقريبًا مقارنة أداء فريق من شركة ما مباشرة بأداء فريق آخر في شركة أخرى. الشركة،"
أشار
كليف جيلي، مدير المنتجات الفنية السابق ومدرب Agile . "أنا حذر قليلاً بشأن المقاييس عندما يتعلق الأمر بتوجيه أداء الفريق. بمجرد الاهتمام بمتغير واحد أو متغيرين فقط، يصبح من السهل جدًا الوقوع في التلاعب بالمقياس (عن قصد أو غير ذلك) وخداع نفسك بأنك تتحسن - عندما يكون كل ما تفعله هو تحسين المقياس. على سبيل المثال، يمكن أن "تتحسن" المقاييس المستندة إلى السرعة من خلال انتقال الفريق إلى قصص أصغر (عمل أقل لكل قصة - وبالتالي إكمال المزيد من القصص - وبالتالي ترتفع السرعة). قد يكون هذا أمرًا جيدًا إذا كانت القصص عبارة عن قصص مستخدمين مفيدة توفر زيادات صغيرة في قيمة الأعمال.
وقال
أدريان هوارد، وهو متخصص آخر في الصناعة، "قد يكون هذا أمرًا سيئًا إذا أصبحت القصص أصغر حجمًا وأكثر "تقنية" ولا تقدم قيمة حقيقية في حد ذاتها" . "عند العمل في نظام قائم على السحب، فإنني أقدر الإنتاجية ووقت الدورة. الأول يعطيني معلومات عامة حول قدرة فريقنا، وبمرور الوقت يمكن أن يصبح مقياسًا تنبؤيًا قويًا للغاية. والثاني مفيد كمقياس عام لكفاءة خطوط الأنابيب لدينا. إذا كان وقت الدورة مرتفعًا، فقد حان الوقت للبدء في النظر إلى خط الأنابيب، نظرًا لوجود قيد يمكننا على الأرجح العمل على تخفيفه/استغلاله. لكن المقاييس هي مجرد أدوات. لا تضيع فيها، وبالتأكيد لا تبدأ بالتخطيط لمقياس محدد. فكر فيما تقوم به كفريق وكيف تعمل بشكل طبيعي، ثم قم ببناء النظام حول الأشخاص. من المفترض أن تساعدك المقاييس في معرفة كيفية دعم نظامك لعمل الجميع.
أو لا،" خلص
ديف سيرا، منتج تطوير ألعاب الفيديو .
GO TO FULL VERSION