ثقافة التنمية: كيف يتم تقييم الأداء والكفاءة

( ج )

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

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

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

في هذه المقالة ، سنتحدث عن المقاييس الحالية الأكثر إثارة للاهتمام و "المقاييس" في تكنولوجيا المعلومات.

من الصعب بالفعل العثور على (على الأقل في المصادر المفتوحة) معلومات حول استخدام عدد ساعات العمل أو عدد الخطوط في الكود المصدري (SLOC) أو نقاط الوظيفة أو عدد الأخطاء التي تم إنشاؤها بواسطة كل مطور كمقياس.

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

ولكن ماذا حدث للرغبة في قياس وحساب كل شيء؟ على ما يبدو ، لم تختف.

نيتفليكس

( ج )

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

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

يبدأ تطوير المنتج في Netflix بفرضية تبدو كما يلي:

تعمل الخوارزمية / الوظيفة / التصميم (×) على زيادة تفاعل المشتركين مع الخدمة وفي النهاية الاحتفاظ بها.

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

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

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

حتى فشل الفرضية يعتبر نتيجة محققة. وبالتالي ، فإن احتمال أن تصبح الفرضية التالية أفضل فقط. يتمتع فريق التطوير بحرية كبيرة في تطبيق الأفكار على المنتج على مدار فترة زمنية طويلة.

IBM

( ج )

يعد القياس الأقدم والأكثر "وضوحًا" لتطوير البرمجيات هو حساب عدد الخطوط التي ينتجها مطور أو فريق فردي ، ومقدار الوقت الذي يقضيه في ذلك. تم استخدام هذا المقياس لأول مرة بواسطة IBM. في الفيلم الوثائقي Triumphof the Nerds: The Rise of Accidental Empires ، لاحظ Steve Ballmer أنه في الثمانينيات ، يبدو أن IBM قد جعل الدين في هذا المؤشر.

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

ومع ذلك ، تعطي المنشورات اللاحقة انطباعًا بحدوث نقلة نوعية - فقد تم بالفعل ذكر منهجية بناء الفرضيات في قلب التطور. التنمية المفرطة لا يمكن أن تفعل دون ضياع الوقت والموارد.



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

(سبيس اكس)

( ج )

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

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

بالنظر إلى المشكلات التي تواجهها الفرق المشاركة في إعداد المعدات للبيئة الفضائية القاسية ، فإنه ليس من الصعب فهم المسؤولية التي تقع عليهم.

يحاول SpaceX مزامنة الكود بين المشاريع المختلفة - من خلال نموذج التطوير هذا ، يمتد تصحيح الخطأ لمشروع واحد (بشكل نسبي ، صواريخ) تلقائيًا إلى مشاريع أخرى.

اختارت الشركة لغة C ++ كلغة برمجة رئيسية. أولاً ، يسمح لك بتوظيف العديد من المطورين البارزين ، لأن اللغة لا تزال شائعة نسبيًا. في الوقت نفسه ، غالبًا ما يتم الاختيار لصالح مطوري الألعاب الذين اعتادوا على كتابة التعليمات البرمجية والعمل في بيئات ذات ذاكرة محدودة وقوة حسابية.

ثانياً ، يستفيدون من النظام البيئي الكبير C ++. ليست هناك حاجة لإنشاء برنامج خاص عندما يمكنك استخدام أدوات مألوفة ، مثل gcc و gdb.

وأخيرا ، في التنمية ، يتم إيلاء اهتمام كبير لاختبار المقاييس. يُنصح المطورون والمهندسون بالتحقق من الأمان والتسامح مع أي شيء يمكنك التفكير فيه.

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

يستخدم التكامل المستمر لاختبار تلقائيا كل رمز. لديهم حتى منصات اختبار مع جميع مكونات المحرك لمحاكاة البدء والكشف عن المشاكل المحتملة بشكل كامل.

الأمازون

تمتلك أمازون واحدة من أكثر الاستراتيجيات إثارة للاهتمام الموضحة في هذه المقابلة التي استمرت 40 دقيقة مع مدير أدوات مطور AWS.

والفكرة الرئيسية لتشكيل فرق التطوير هي التحجيم الانقسامي. يتم تقسيم الفرق إلى مجموعات أصغر ، مع الحفاظ بشكل كامل على استمرارية ووظائف فرق "الأم".

يعتقد جيف بيزوس ، الرئيس التنفيذي لشركة AWS Developer Tools ، أن الفريق المثالي يجب ألا يضم أكثر من شخص يمكن أن يشغلهما البيتزا.

في الفرق الصغيرة ، يكون التواصل أكثر فاعلية ، حيث يظلون لا مركزيين ومستقلين ويتطورون بشكل أسرع ويقدمون الابتكارات.

كان لدى Amazon في الأصل بنية متجانسة وبرامج (Perl / Mason / C ++). ثم تم تقسيم البنية إلى خدمات ، والهيكل التنظيمي في فرق البيتزا. لذلك تم تشكيل الخدمة السحابية في Amazon Amazon Compute Cloud (Amazon EC2) من قبل مجموعة تتكون من "فريق بيتزا" فقط.

تلتزم أمازون بالأتمتة الكاملة لجميع العمليات (بناء ونشر ونشر التزام ، وما إلى ذلك). في كل عملية نشر ، يتم استخدام عدة أنواع مختلفة من الاختبارات: التكامل ، المتصفح ، الويب والتحميل. وبالتالي ، يتم التحكم في كل شيء وقياسه.

تتم مراقبة الأمان خلال عملية إطلاق المنتج ، ولهذا السبب من الطبيعي تمامًا لـ Amazon أن "تفكر كمهندس أمان" في أي ثقافة في Amazon. عند إطلاق مشروع جديد ، يعمل المطورون بشكل أساسي على نموذج العمارة والتهديد.

يتم تضمين عمليات التحقق من الصحة في جميع خطوط الأنابيب من خلال مجموعة من سياسات الثقة المحلية والعالمية. يمكن للزعيم تعيين سياسة التدقيق بشكل مستقل لفريقه (على سبيل المثال ، قبل النشر ، يجب تغطية كل التزام جديد عن طريق اختبار الوحدة بنسبة 70 ٪).

في الوقت نفسه ، هناك قواعد عامة لشركة Amazon تغطي كل عملية نشر (على سبيل المثال ، فرض حظر على النشر لمرة واحدة في كل منطقة).

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

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

ماذا الشركات الناشئة هناك

بفضل الدراسات الاستقصائية التي أجرتها Stackify (منصة سحابية لمراقبة واستكشاف تطبيقات الويب واستكشافها) ، كان من الممكن معرفة الموقف من المقاييس في بعض الشركات الناشئة والشركات المعروفة باسم "اليد الوسطى".

CircleCI هي خدمة شائعة ، بما في ذلك في روسيا ، خدمة التكامل المستمر مع إعدادات مرنة لتطبيقات الويب والجوال. يعتقد روب زوبر ، CTO CircleCI ، أن أفضل مقياس لقياس إنتاجية وفعالية تطوير البرمجيات هو مقياس للوقت الذي يستغرقه الكود للانتقال من الالتزام بالنشر - وقت الالتزام بالنشر (CDT).

الهدف من قياس CDT هو "تعقب" الحواجز أمام النشر. من الناحية المثالية ، إذا كنت تستخدم الأتمتة و / أو اختبارات ذات نوعية جيدة ، يمكنك الانتقال إلى النشر في دقائق (أو حتى ثوانٍ) للحصول على خدمة microservice. إذا كنت تستخدم بشكل أساسي عملية التحكم في الجودة اليدوية ، فربما يعني ذلك أن النشر سيستغرق وقتًا أطول.

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

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

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

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

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

يعتبر المشروع ناجحًا إذا كان العميل راضيًا وتوافق الفريق مع الموعد النهائي.

استنتاج

في بعض الأحيان ، مع تقييم المقاييس ، لا يزال بإمكانك الوصول إلى قاسم مشترك - وهذا هو التركيز على راحة المستخدم. بدلاً من محاولة قياس إنتاجية المبرمج مباشرةً ، ينصب التركيز على قياس كل ما يعوق التقدم في تقديم القيمة للعميل.

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