تقييم المطور على أساس البيانات الموضوعية

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

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


حول المتحدثين: ألكسندر كيسيليف وسيرجي سيمينوف ، نحن في مجال تكنولوجيا المعلومات لأكثر من 8 سنوات. ذهب كلاهما من المطور إلى قائد الفريق وكذلك إلى مدير المنتج. الآن يعملون على الخدمة التحليلية GitLean ، التي تجمع تلقائيًا التحليلات من فرق التطوير لقيادات الفريق و CTO. الهدف من هذه الخدمة هو أن المديرين الفنيين يمكنهم اتخاذ قراراتهم بناءً على البيانات الموضوعية.

بيان المشكلة

عملنا كقادة فريق وكثيرا ما واجهنا مشكلة عدم اليقين والغموض في عملنا.


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

سنتحدث اليوم عما يمكنك إخباره بالبيانات التي جمعتها بالفعل ، ولكن على الأرجح لا تستخدمها.


هذا ضروري في حالتين رئيسيتين.

مراجعة الأداء هي عملية معقدة وغير موضوعية إلى حد ما. سيكون من الرائع جمع الحقائق حول عمل المطور تلقائيًا.

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

الجانب الثاني هو مراقبة الوضع الحالي في الفريق. أريد أن أفهم بسرعة المشاكل التي تظهر ، وأن أستجيب لها بسرعة.

خيارات القرار

قد يكون هناك العديد من الحلول.


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


هذا هو الشيء التالي الذي يجب فعله. نظرًا لأن التقييم الذاتي لا يكفي غالبًا ، يمكنك الخلط وجمع الحقائق يدويًا .

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

عندما اكتشفت CTO ، اتضح أن المشكلة كانت قديمة جدًا لدرجة أنه كان من المستحيل فعل أي شيء ، وفي النهاية كان يجب فصل أحد المبرمجين.


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

مثال بسيط - قام المطور في السباق السابق بـ 5 مهام ، هذه المهمة - 10. هل من الممكن القول أنه بدأ في العمل بشكل أفضل؟ هذا مستحيل ، لأن المهام مختلفة تمامًا.


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

الحل المختار

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

مصادر البيانات

مصادر البيانات الرئيسية التي يتم فيها تجميع المعلومات حول عمل المطور هي:

1. Git - الكيانات الرئيسية: الارتباطات والفروع والرموز داخلها.
2. أدوات مراجعة الكود - خدمات الاستضافة git التي تستضيف مراجعات كود تحمل معلومات حول طلب السحب التي يمكن استخدامها.
3. تعقب المهام - معلومات حول المهام ودورة حياتها.

مصادر البيانات المساعدة:

1. رسل - يمكنك ، على سبيل المثال ، إجراء تحليل المشاعر ، وحساب متوسط ​​وقت استجابة المطور لطلب المعلومات.
2. خدمات CI التي تخزن معلومات حول الإصدارات والإصدارات.
3. استطلاعات الفريق.

نظرًا لأن جميع المصادر التي تحدثت عنها أعلاه قياسية بشكل أو بآخر ، والأخيرة ليست قياسية جدًا ، سأتحدث عنها أكثر قليلاً.


شارك CTO آخر هذه الطريقة معنا. في نهاية كل تكرار ، أرسل الفريق استطلاعًا تلقائيًا ، حيث كان هناك سؤالان فقط:

1. برأيك ، ما مدى أهمية ما فعلناه في هذا التكرار؟
2. هل تعتقد أن ما نقوم به مثير للاهتمام؟

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

ما وكيفية قياسه

بادئ ذي بدء ، سنناقش منهجية القياس. يجب أن يجيب المقياس الجيد على 3 أسئلة:

1. هل هو مهم؟ من الضروري فقط قياس الإشارات المتعلقة بشيء مهم للشركة.
2. هل أصبحت أسوأ / أفضل / نفس الشيء؟ بالمقياس ، يجب أن يكون واضحًا تمامًا ما إذا كان قد أصبح أفضل أو أسوأ.
3. ماذا تفعل من المقياس ، يجب أن يكون واضحًا ما يجب فعله من أجل تصحيح الوضع.

بشكل عام ، يجدر اتباع المبدأ:

قياس ما تريد ويمكن تغييره.

من الجدير بالذكر على الفور أنه لا يوجد مقياس عالمي ، ولن نتحدث عن مقياس عالمي اليوم للأسباب التالية:

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

نهج جديد

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


ما هو اختيارنا للمشاكل على أساس؟ الأمر بسيط: لقد أجرينا مقابلة مع 37 من مديري التكنولوجيا وقادة الفرق الذين تحدثوا عن المشاكل التي يواجهونها في فرقهم ، وكيف يحلون هذه المشاكل.

القائمة الضخمة الناتجة ، أعطينا الأولوية وجمعنا الاختراقات والمقاييس للحياة لهذه المشاكل. قسمنا جميع المشاكل إلى مجموعتين:

1. مشاكل المطور الفردية (المطور هو المسؤول عن هذه المشاكل).
   
   
2. مشاكل الفريق. الفريق مسؤول عن هذه المشاكل ؛ وبالتالي ، من أجل حلها ، تحتاج إلى العمل مع الفريق ككل وتغيير حلول العملية.
   
   

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

قضايا المطور

أداء قليل المطور

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

كيف يمكن قياس ذلك؟

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

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

لذلك ، فإن القيد التالي الذي نفرضه هو أن المطور يجب أن يكون لديه أيضًا كود صغير . كيفية تحديد عتبة "الرمز الصغير"؟ نوصي بأن تضعها صغيرة بما يكفي بحيث يمكن لأي شخص ، مثل مطور الأداء ، التغلب عليها بسهولة. على سبيل المثال ، في خدمتنا لـ JS ، يوجد حوالي 150 سطرًا من التعليمات البرمجية ، وبالنسبة لـ Clojure - 100 سطر من التعليمات البرمجية.

لماذا هذه العتبة الصغيرة؟ الفكرة هي أننا لا نفصل بين المطورين العاملين البارعين عن المطورين العاملين العاديين ، ولكن أولئك الذين لا يفعلون شيئًا تقريبًا ، عن أولئك الذين يقومون على الأقل بقدر معقول من العمل.

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

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

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

ماذا تفعل حيال ذلك؟

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

كانت هذه أبسط مشكلة وأكثرها استفزازًا. دعنا ننتقل إلى الأثقل.

إعادة تدوير المطور

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

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

كيف يمكن قياس ذلك؟

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

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

المشغل الصريح الأخير هو عدد كبير من المهام المتوازية . هناك بعض القيود المعقولة على 3-4 مهام للمطور. يمكنك تتبعهم عن طريق بوابة أو جيرا - كما يحلو لك. يعمل بشكل جيد.

ماذا تفعل حيال ذلك؟

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

إذا لم يفلح ذلك ، فمن الضروري إعادة توزيع الحمل . هذا في الواقع سؤال معقد إلى حد ما - كيف نفعل ذلك. هناك العديد من الطرق المختلفة. لن نتعمق ، ولكن لاحظ التقرير الرائع عن HighLoad 2017 من Anton Potapov ، حيث تم النظر في هذا الموضوع عن كثب.

المطور لا يركز على إطلاق المهمة

أريد أن أفهم عدد هؤلاء المطورين في فريقك وكم يكلف في الوقت المناسب.


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

كيف يمكن قياس ذلك؟

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

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

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

ماذا تفعل حيال ذلك؟

إذا وجدت مثل هذا المطور ، فمن الواضح أنه من المفيد الذهاب إليه والقول : "انظر ، إنه 30-40٪ من وقتك الذي تقضيه في وقت التوقف!" إنه يعمل بشكل رائع جدًا. في حالتي ، على سبيل المثال ، كان له مثل هذا التأثير ، أن المشكلة قد اختفت تمامًا تقريبًا ، إذا لم تكن كذلك ، فأنت بحاجة إلى متابعة المراقبة ، بشكل دوري ، ولكن الشيء الرئيسي هنا هو عدم الوقوع في الإدارة الجزئية ، لأنها ستكون أسوأ.

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

المطور لا يفكر في المهام الكافية

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


كيف يمكن قياس ذلك؟

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

كيف يمكن قياس ذلك؟

للقيام بذلك ، نحتاج إلى إدخال مقياسين ، أولهما هو رمز Churn.


Churn هو مقياس لمقدار الشفرة التي يكتبها المطور بشروط دون جدوى.

تخيل الوضع. يوم الاثنين ، بدأ المطور في تنفيذ مهمة جديدة ، وكتب 100 سطر من التعليمات البرمجية. ثم جاء يوم الثلاثاء ، كتب 100 سطر جديد من التعليمات البرمجية في هذه المهمة. ولكن ، لسوء الحظ ، حدث ذلك أن 50 سطرًا من التعليمات البرمجية التي تم كتابتها يوم الاثنين ، قام بحذف المهمة وإطلاقها. ونتيجة لذلك ، يبدو أنه تم إنشاء 200 سطر من التعليمات البرمجية في المهمة ، لكن 150 فقط بقيت حتى الإصدار ، و 50 تم كتابتها عبثا. هؤلاء 50 نسميهم Churn. وهكذا في هذا المثال ، كان المطور Churn 25٪.

في رأينا ، فإن المستوى العالي من Churn هو مشغل رائع لم يفكر المطور في المهمة.

هناك دراسة أجرتها شركة أمريكية قاسوا فيها مستوى Churn لـ 20،000 مطور وتوصلوا إلى استنتاج مفاده أن رمز Churn الجيد يجب أن يكون في حدود 10-20 ٪.

ولكن هناك شرطان مهمان:

1. High Churn على ما يرام إذا كنت ، على سبيل المثال ، تقوم بعمل نموذج أولي أو مشروع جديد. ثم يمكن أن يساوي 50-60٪ لعدة أشهر. لا يوجد شيء يدعو للقلق. , Churn — , .
2. Churn — . . - . delivery .

, , , , Fixed Tasks, . , .

, bug fixes , bug fixes . bug fixes 3 , , . , , , .

— . , , , - .

?

, , , . , , , estimation ..

CTO, , workflow, , . , , , - , .

Churn Fixed Tasks

, , :

• commit message, . commit message, , git .
• git-squash commit' , Churn .
• git. merge master, merge , . — , , Churn Fixed Tasks.

, — , . , , , . , - .

, , - 3-4 . , .

?

— - , , .


, 3 , , ( ), .

, , . — , .

— , — — , , .

?

. , , . - , .

— , , . . , , . .

30-50 50-60 %. , .

, , . , , , . .


, — . product- , . , , .

?

product- , ?

, product- , :

• Churn, ;
• , , estimation;
• in progress product-.

?

product- : «, Churn - — ».

« » , 1-2 . , product-, .


. , , .

, , , . , , - , , . , . .

?

, , :

• ;
• ;
• ;
• -, - , ;
• .

?

-, , , , .

-, , , , , , .

— - , . best practise, , , , . 3 , 3 .


, — . , . - , , -. , , CTO, , 100%. , - .

?

, legacy refactoring . , . . , , , .


, legacy refactoring , , complexity , , .

?

, , . , CTO. , .

CTO , , Jira «» . , - estimation . , — , ..

CTO . , , , «Hack». - -, : « Hack — », . grep' «Hack» , .

. .

:

1. . , , Churn legacy refactoring. , .
   
2. . , , , — git , git-. — , .
3. , . , , .
4. تعمل معظم المقاييس التي ذكرناها هنا فقط لمطوري الوقت ، لأن أنشطة مطوري الوقت فقط تنعكس بشكل جيد في مصادر البيانات المتاحة: git و Jira و GitHub والمراسلات الفورية وما إلى ذلك.

الاستنتاجات

نود أن ننقل إليكم ما يلي:

• يمكن ويجب تقييم المطورين والفريق . يمكن أن يكون صعبًا ، ولكن يمكن القيام به.
  
• لا توجد مجموعة صغيرة عالمية من مؤشرات الأداء الرئيسية . لكل مشكلة ، تحتاج إلى تحديد مجموعة المقاييس عالية التخصص. يجب أن نتذكر أنه يجب ألا تهمل حتى أبسط المقاييس. يمكنهما العمل جيدًا معًا.
  
• يمكن لـ Git أن يخبر الكثير من الأشياء المثيرة للاهتمام حول التطوير والمطورين ، ولكن عليك اتباع ممارسات معينة حتى يمكن الوصول إلى البيانات منها بسهولة ، بما في ذلك:
  
  • عدد المهام في ارتكاب ؛
  • لا اسكواش
  • يمكنك تحديد وقت الإصدار: الدمج في العلامات الرئيسية.

روابط واتصالات مفيدة:

• هناك العديد من مشاكل ومقاييس المكافأة لهم في العرض التقديمي .
  
• مدونة المؤلفين مع مقالات مفيدة لمديري التنمية
  
• جهات الاتصال برقية:avkiselev (ألكسندر كيسيليف) و sss0791 (سيرجي سيمينوف).

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

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