يعتبر تطوير البرمجيات عملية قابلة للقياس بشكل سيئ ، ويبدو أنه من أجل إدارتها بشكل فعال ، تحتاج إلى ذوق خاص. وإذا لم يكن الحدس مع الذكاء العاطفي متطورًا للغاية ، فمن المؤكد أن الشروط ستتغير ، وستنخفض جودة المنتج وستنخفض سرعة التسليم.
يعتقد
سيرجي سيمينوف أن هذا يحدث بشكل رئيسي لسببين.
- لا توجد أدوات ومعايير لتقييم عمل المبرمجين. يجب على المديرين اللجوء إلى التقييم الذاتي ، الذي يؤدي بدوره إلى الأخطاء.
- لا يتم استخدام وسائل التحكم الآلي في العمليات في الفريق. بدون التحكم المناسب ، تتوقف العمليات في فرق التطوير عن أداء مهامها ، حيث يبدأ تنفيذها جزئيًا أو يتم تجاهلها ببساطة.
ويقدم نهجًا لتقييم ومراقبة العمليات استنادًا إلى البيانات الموضوعية.
فيما يلي نسخة فيديو ونسخة من تقرير سيرجي ، والذي ، وفقًا لنتائج تصويت الجمهور ، احتل المركز الثاني في
Saint TeamLead Conf .
نبذة عن المتحدث: يعمل سيرجي سيمينوف ( sss0791 ) في مجال تكنولوجيا المعلومات منذ 9 سنوات ، وكان مطورًا وقائد فريق ومدير منتجات وهو الآن الرئيس التنفيذي لشركة GitLean. GitLean هو منتج تحليلي للمديرين والمديرين الفنيين وقادة الفرق ، تم تصميمه لاتخاذ قرارات إدارية موضوعية. لا تستند معظم الأمثلة في هذه القصة على الخبرة الشخصية فحسب ، بل أيضًا على تجربة الشركات العميلة مع موظفي التطوير من 6 إلى 200 شخص.لقد تحدثنا بالفعل مع زميلي ألكسندر كيسيليف عن
تقييم المطورين في فبراير في TeamLead Conf السابق. لن أطيل في الحديث عن هذا بالتفصيل ، لكنني سأشير إلى مقال حول بعض المقاييس. سنتحدث اليوم عن العمليات وكيفية التحكم فيها وقياسها.
مصادر البيانات
إذا كنا نتحدث عن القياسات ، سيكون من الجيد أن نفهم من أين نحصل على البيانات. بادئ ذي بدء ، لدينا:
- Git بمعلومات الرمز ؛
- Jira أو أي أداة تتبع مهام أخرى تحتوي على معلومات حول المهام ؛
- GitHub ، Bitbucket ، Gitlab مع معلومات مراجعة التعليمات البرمجية.
بالإضافة إلى ذلك ، هناك آلية رائعة مثل جمع التقييمات الذاتية المختلفة. سأبدي تحفظًا بأنه يجب استخدامه بشكل منهجي إذا أردنا الاعتماد على هذه البيانات.
بالطبع ، الأوساخ والألم في انتظارك في البيانات - لا يوجد شيء يمكنك القيام به حيال ذلك ، ولكن هذا ليس مخيفًا جدًا. الشيء الأكثر إزعاجًا هو أنه قد لا تكون هناك ببساطة بيانات عن عمل العمليات الخاصة بك في هذه المصادر. قد يكون هذا بسبب بناء العمليات بحيث لا تترك أي آثار في البيانات.
القاعدة الأولى التي نوصي باتباعها عند تصميم وبناء العمليات هي جعلها بحيث تترك القطع الأثرية في البيانات. تحتاج إلى بناء ليس فقط رشيقة ، ولكن جعلها
رشيقة قابلة للقياس.
سوف أخبرك قصة الرعب التي التقينا بها مع أحد العملاء الذين قدموا إلينا لطلب تحسين جودة المنتج. لجعلك تفهم المقياس ، طار حوالي 30-40 خطأ من الإنتاج إلى فريق من 15 مطورًا في الأسبوع. بدأوا في فهم الأسباب ، ووجدوا أن 30٪ من المهام لم تندرج في حالة "الاختبار". في البداية ، اعتقدنا أنه كان مجرد خطأ في البيانات ، أو لم يقم المختبرون بتحديث حالة المهمة. ولكن اتضح أن 30٪ من المهام لم يتم اختبارها ببساطة. مرة واحدة كان هناك مشكلة في البنية التحتية ، بسبب أن 1-2 مهام في التكرار لم تقع في الاختبار. ثم نسي الجميع هذه المشكلة ، وتوقف المختبرون عن التحدث عنها ، ومع مرور الوقت نمت إلى 30 ٪. ونتيجة لذلك ، أدى هذا إلى المزيد من المشاكل العالمية.
لذلك ، فإن أول مقياس مهم لأي عملية هو أنه يترك البيانات. تأكد من اتباع هذا.
في بعض الأحيان ، من أجل قابلية القياس ، يجب عليك التضحية بجزء من مبادئ Agile ، وعلى سبيل المثال ، تفضل في مكان ما التواصل الكتابي على الفم.
أثبتت ممارسة تاريخ الاستحقاق ، التي نفذناها في عدة فرق من أجل تحسين القدرة على التنبؤ ، أنها جيدة للغاية. جوهرها هو كما يلي: عندما يأخذ المطور المهمة ويسحبها إلى "قيد التقدم" ، يجب عليه تحديد تاريخ الاستحقاق الذي سيتم فيه إطلاق المهمة أو جاهزة للإصدار. تعلم هذه الممارسة المطور أن يكون مدير مشروع صغير مشروط لمهامه الخاصة ، أي مراعاة التبعيات الخارجية وفهم أن المهمة جاهزة فقط عندما يمكن للعميل استخدام نتائجها.
لإجراء التدريب ، بعد تاريخ الاستحقاق ، يحتاج المطور إلى الذهاب إلى Jira وتعيين تاريخ استحقاق جديد وترك التعليقات في نموذج معين ، لماذا حدث ذلك. يبدو أن هناك حاجة إلى مثل هذه البيروقراطية. ولكن في الواقع ، بعد أسبوعين من هذه الممارسة ، نقوم بإفراغ كل هذه التعليقات من Jira بنص بسيط ونجري عرضًا استعاديًا بهذا النسيج. اتضح الكثير من الأفكار حول سبب كسر المواعيد النهائية. إنه يعمل بشكل رائع للغاية ، أوصي باستخدامه.
نهج المشكلة
في قياس العمليات ، نعترف بالنهج التالي: نحن بحاجة إلى المضي قدمًا من المشاكل. نتخيل بعض الممارسات والعمليات المثالية ، وبعد ذلك نكون مبدعين في الطرق التي قد لا تعمل بها.
من الضروري مراقبة انتهاك العمليات ، وليس كيف نتبع بعض الممارسات. لا تعمل العمليات في كثير من الأحيان ، ليس لأن الأشخاص ينتهكونها بشكل ضار ، ولكن لأن المطور والمدير ليس لديهم ما يكفي من التحكم والذاكرة لمتابعة كل منهم. بتتبع انتهاكات اللوائح ، يمكننا تذكير الناس تلقائيًا بما يجب القيام به ، ونحصل على عناصر تحكم تلقائية.
لفهم العمليات والممارسات التي تحتاج إلى تنفيذها ، تحتاج إلى فهم سبب القيام بذلك في فريق التطوير ، وما تحتاجه الشركة من التطوير. الجميع يفهم أنه ليس هناك حاجة ماسة:
- تسليم المنتج لفترة توقع كافية ؛
- أن المنتج كان بجودة مناسبة وليس بالضرورة مثاليًا ؛
- بحيث يكون كل هذا سريعًا بما يكفي.
أي أن
القدرة على التنبؤ والجودة والسرعة مهمة. لذلك ، سنلقي نظرة على جميع المشاكل والمقاييس بدقة مع مراعاة كيفية تأثيرها على القدرة على التنبؤ والجودة. بالكاد نناقش السرعة ، بسبب ما يقرب من 50 فريق عملنا بطريقة أو بأخرى ، لا يمكن إلا لفريقين العمل بسرعة. من أجل زيادة السرعة ، يجب أن تكون قادرًا على قياسها ، بحيث تكون على الأقل قابلة للتنبؤ بها قليلاً ، وهذا هو القدرة على التنبؤ والجودة.
بالإضافة إلى القدرة على التنبؤ والجودة ، نقدم هذا الاتجاه مثل
الانضباط . سوف نسمي الانضباط كل شيء يضمن الأداء الأساسي للعمليات وجمع البيانات ، بناءً على ذلك يتم تحليل المشكلات المتعلقة بالقدرة على التنبؤ والجودة.
من الناحية المثالية ، نريد بناء مخطط العمل التالي: بحيث يكون لدينا جمع تلقائي للبيانات ؛ من هذه البيانات يمكننا بناء مقاييس ؛ استخدام المقاييس للعثور على المشاكل أبلغ عن المشاكل مباشرة للمطور أو قائد الفريق أو الفريق. ثم سيتمكن الجميع من الرد عليهم في الوقت المناسب والتعامل مع المشاكل التي تم العثور عليها. يجب أن أقول على الفور أنه ليس من الممكن دائمًا الوصول إلى إشارات مفهومة. في بعض الأحيان ، ستبقى المقاييس مجرد مقاييس يجب تحليلها وإلقاء نظرة على القيم والاتجاهات وما إلى ذلك. حتى مع البيانات ، في بعض الأحيان ستكون هناك مشكلة ، وأحيانًا لا يمكن جمعها تلقائيًا ويجب عليك القيام بذلك يدويًا (سأوضح مثل هذه الحالات بشكل منفصل).
بعد ذلك ، نعتبر 4 مراحل من حياة الميزات:
وسوف نحلل مشاكل الانضباط والقدرة على التنبؤ والجودة التي يمكن أن تكون في كل من هذه المراحل.
مشاكل الانضباط في مرحلة التخطيط
هناك الكثير من المعلومات ، لكني أهتم بأهم النقاط الأساسية. قد يبدو الأمر بسيطًا جدًا ، لكنهم يواجهون عددًا كبيرًا جدًا من الفرق.
المشكلة الأولى التي غالباً ما تنشأ أثناء التخطيط هي
مشكلة تنظيمية مبتذلة - ليس كل من يجب أن يكون حاضراً في اجتماع التخطيط.
مثال: يشكو فريق من أن أحد المختبرين يختبر شيئًا خاطئًا. اتضح أن المختبرين في هذا الفريق لا يذهبون إلى التخطيط على الإطلاق. أو بدلاً من الجلوس والتخطيط لشيء ما ، يبحث الفريق بشكل محموم عن مكان للجلوس لأنهم نسوا حجز غرفة اجتماعات.
لا يلزم تكوين المقاييس والإشارات ، فقط يرجى التأكد من عدم وجود هذه المشاكل. تم وضع علامة على الاجتماع في التقويم ، تمت دعوة الجميع إليه ، وتم أخذ المكان. مهما كان الأمر يبدو مضحكًا ، فقد تمت مصادفته في فرق مختلفة.
سنناقش الآن المواقف التي تتطلب إشارات وقياسات. في مرحلة التخطيط ، يجب إرسال معظم الإشارات التي سأتحدث عنها إلى الفريق بعد حوالي ساعة من نهاية اجتماع التخطيط ، حتى لا يصرف الفريق في العملية ، ولكن لا يزال يحتفظ بالتركيز.
المشكلة التأديبية الأولى هي
أن المهام ليس لها وصف ، أو أنها موصوفة بشكل سيئ. يتم التحكم في هذا بشكل أساسي. هناك تنسيق يجب أن تتوافق معه المهام - نتحقق مما إذا كان الأمر كذلك. على سبيل المثال ، نتبع أن معايير القبول قد تم تعيينها ، أو يوجد رابط للتخطيط لمهام الواجهة الأمامية. تحتاج أيضًا إلى تتبع المكونات الموضوعة ، لأن تنسيق الوصف مرتبط غالبًا بالمكون. بالنسبة لمهمة الواجهة الخلفية ، يكون وصف واحد ذا صلة ؛ لمهمة الواجهة الأمامية ، آخر.
المشكلة الشائعة التالية هي أن
الأولويات يتم التحدث بها شفهيًا أو لا يتم التحدث بها على الإطلاق ولا تنعكس في البيانات . ونتيجة لذلك ، بحلول نهاية التكرار ، اتضح أن أهم المهام لم يتم القيام بها. من الضروري التأكد من أن الفريق يستخدم الأولويات ويستخدمها بشكل مناسب. إذا كان لدى الفريق 90٪ من المهام في التكرار ذات أولوية عالية ، فهي لا تساوي أي أولويات على الإطلاق.
نحن نحاول الوصول إلى مثل هذا التوزيع: 20٪ من المهام ذات الأولوية العالية (لا يمكنك المساعدة إلا التفريغ) ؛ 60٪ - أولوية متوسطة ؛ 20٪ - أولوية منخفضة (لن تكون مخيفة إذا لم نطلقها). نعلق الإشارات على كل هذا.
المشكلة الأخيرة في الانضباط ، والتي تحدث في مرحلة التخطيط -
لا توجد بيانات كافية ، بما في ذلك المقاييس اللاحقة. الأساسيات: المهام ليس لها تقييمات (يجب عمل إشارة) أو أنواع المهام غير كافية. أي أن الأخطاء تبدأ كمهام ، ولا يمكن تتبع مهام الديون الفنية على الإطلاق. لسوء الحظ ، لا يمكن التحكم تلقائيًا في النوع الثاني من المشاكل. ننصح مرة واحدة فقط كل شهرين ، خاصة إذا كنت مديرًا فنيًا ولديك العديد من الفرق ، فراجع خلال المتأخرات وتأكد من أن الأشخاص يبدأون الأخطاء مثل الأخطاء والقصص مثل القصص ومهام الديون الفنية مثل الديون الفنية.
مشاكل التنبؤ في مرحلة التخطيط
ننتقل إلى مشاكل مع إمكانية التنبؤ.
المشكلة الأساسية هي
أننا لا نلتزم بالمواعيد النهائية والتقديرات ، بل نقوم
بتقييمها بشكل غير صحيح. لسوء الحظ ، من المستحيل العثور على نوع من الإشارة السحرية أو المقياس الذي سيحل هذه المشكلة. الطريقة الوحيدة هي تشجيع الفريق على التعلم بشكل أفضل ، لتحليل أسباب الأخطاء باستخدام تقييم واحد أو آخر باستخدام الأمثلة. ويمكن تسهيل عملية التعلم هذه بوسائل تلقائية.
أول شيء يمكن القيام به هو التعامل مع المهام الصعبة بشكل واضح مع تقدير عالٍ لوقت التنفيذ. نعلق اتفاقية مستوى الخدمة والتحكم في أن جميع المهام متحللة بشكل جيد بما فيه الكفاية. نوصي بحد أقصى يومين ليبدأ التنفيذ ، وبعد ذلك يمكنك الانتقال إلى يوم واحد.
يمكن للفقرة التالية تسهيل جمع القطع الأثرية ، والتي سيكون من الممكن إجراء التدريب والتحليل فيها مع الفريق لسبب حدوث خطأ في التقييم. نوصي باستخدام ممارسة تاريخ الاستحقاق لهذا. لقد أثبتت نفسها باردة جدا هنا.
طريقة أخرى هي مقياس يسمى رمز Churn كجزء من المهمة. جوهرها هو أننا ننظر إلى النسبة المئوية من التعليمات البرمجية في إطار المهمة التي تمت كتابتها ، ولكن لم ترق إلى مستوى الإصدار (المزيد في
التقرير الأخير). يوضح هذا المقياس مدى دقة المهام المدروسة. وبناءً على ذلك ، سيكون من الجيد الانتباه إلى مشاكل قفزات Churn وفهمها ، ما لم نأخذه في الاعتبار ولماذا ارتكبنا خطأ في التقييم.
القصة التالية قياسية: لقد خطط الفريق لشيء ما ، شغل العدو ، ولكن في النهاية
لم يفعل على الإطلاق ما خطط له . يمكنك تكوين إشارات للحشو وتغيير الأولويات ، ولكن بالنسبة لمعظم الفرق التي قمنا بها ، كانت غير ذات صلة. غالبًا ما تكون هذه عمليات قانونية من قبل مدير المنتج لإلقاء شيء ما في السباق ، وتغيير الأولوية ، لذلك سيكون هناك العديد من الإيجابيات الزائفة.
ما الذي يمكن فعله هنا؟ احسب المقاييس الأساسية القياسية إلى حد ما: إغلاق كشافة العدو الأولية ، وعدد الرميات في العدو ، وإغلاق الرميات نفسها ، وتغييرات الأولوية ، انظر هيكل الرميات. بعد ذلك ، قم بتقييم عدد المهام والأخطاء التي عادة ما تلقيها في التكرار. علاوة على ذلك ، باستخدام إشارة للتحكم في أنك
تضع هذه الحصة في مرحلة التخطيط .
مشاكل الجودة في مرحلة التخطيط
المشكلة الأولى:
لا يفكر الفريق في وظائف الميزات التي تم إصدارها . سأتحدث عن الجودة بشكل عام - مشكلة الجودة هي إذا قال العميل أنها موجودة. يمكن أن يكون نوعًا من عيوب البقالة ، أو يمكن أن يكون أشياء فنية.
فيما يتعلق بعيوب الطعام ، فإن مقياسًا مثل تشغيل لمدة
3 أسابيع يعمل بشكل جيد ، وكشف أن 3 أسابيع بعد إطلاق مهمة التمرير أعلى من المعتاد. الجوهر بسيط: لم يتم إطلاق المهمة ، ثم في غضون ثلاثة أسابيع تم حذف نسبة عالية بما فيه الكفاية من رمزها. على ما يبدو ، لم يتم تنفيذ المهمة بشكل جيد للغاية. نلتقط ونحلل مثل هذه الحالات مع الفريق.
المقياس الثاني مطلوب للفرق التي لديها مشاكل في الأخطاء والأعطال والجودة. نقترح إنشاء
رسم بياني لتوازن الأخطاء والأعطال: كم عدد الأخطاء الموجودة حاليًا ، وكم وصل بالأمس ، وكم عدد أمس. يمكنك تعليق شاشة
المراقبة في
الوقت الحقيقي أمام الفريق مباشرة بحيث تراها كل يوم. يركز هذا عظيم الفريق على قضايا الجودة. فعلت ذلك مع الفريقين ، وبدأوا بالفعل في التفكير في المهام بشكل أفضل.
المشكلة القياسية التالية هي
أن الفريق ليس لديه الوقت للديون الفنية . تتم مراقبة هذه القصة بسهولة إذا اتبعت العمل بأنواع ، أي ، يتم تقييم مهام الديون الفنية وبدءها في Jira كمهام فنية للديون. يمكننا حساب الوقت المخصص لحصة التخصيص لفريق الدين الفني خلال الربع. إذا اتفقنا مع الشركة على أنها كانت 20٪ ، وأنفقت 10٪ فقط ، فيمكن أخذ ذلك في الاعتبار وفي الربع التالي لتخصيص مزيد من الوقت للديون الفنية.
مشاكل الانضباط قيد التطوير
الآن دعنا ننتقل إلى مرحلة التطوير. ما هي مشاكل الانضباط؟
لسوء الحظ ، يحدث أن
المطورين لا يفعلون شيئًا ، أو لا يمكننا أن نفهم ما إذا كانوا يفعلون أي شيء. من السهل تتبع ذلك بعلامتين عاديتين:
- تكرار ارتكاب - على الأقل مرة واحدة في اليوم ؛
- مهمة نشطة واحدة على الأقل في جيرا.
إذا لم يكن الأمر كذلك ، فليس من الحقيقة أنك بحاجة إلى التغلب على أيدي المطور ، ولكنك بحاجة إلى معرفة ذلك.
المشكلة الثانية التي يمكن أن تهدم حتى أقوى الأشخاص وعقل حتى مطور رائع للغاية هي
المعالجة المستمرة . سيكون من اللطيف أن تعرف ، كقائد فريق ، أن الشخص يعالج: يكتب رمزًا أو يراجع الكود بعد ساعات.
قد يتم أيضًا
انتهاك قواعد Git المختلفة . أول شيء نحث جميع الأوامر على اتباعه هو تحديد بادئات المهام من المتتبع في رسائل التنفيذ ، لأنه في هذه الحالة فقط يمكننا ربط المهمة والرمز بها. من الأفضل هنا عدم إنشاء إشارات ، ولكن تكوين ربط git مباشرةً. بالنسبة لأي قواعد git إضافية لديك ، على سبيل المثال ، لا يمكنك الالتزام بها بشكل رئيسي ، نقوم أيضًا بتكوين خطافات git.
الأمر نفسه ينطبق على الممارسات المتفق عليها. في مرحلة التطوير ، هناك العديد من الممارسات التي يجب على المطور اتباعها. على سبيل المثال ، في حالة تاريخ الاستحقاق ، ستكون هناك ثلاث إشارات:
- المهام التي لم يتم تعيين تاريخ الاستحقاق لها ؛
- المهام التي انتهت صلاحيتها ؛
- المهام التي تم تغيير تاريخ الاستحقاق لها ولكن لا يوجد تعليق.
يتم ضبط الإشارات لكل هذا. يمكن أيضًا إعداد أشياء مماثلة لأي ممارسة أخرى.
مشاكل التنبؤ في مرحلة التطوير
يمكن أن تسوء الكثير من الأمور في التوقعات في مرحلة التطوير.
يمكن لمهمة تعليق فقط في التنمية لفترة طويلة. لقد حاولنا بالفعل حل هذه المشكلة في مرحلة التخطيط - قم بتحليل المهام بدقة تامة. لسوء الحظ ، هذا لا يساعد دائمًا ،
وهناك مهام تتجمد . بالنسبة للمبتدئين ، نوصي ببساطة بتعيين اتفاقية مستوى الخدمة على "قيد التقدم" بحيث تكون هناك إشارة على انتهاك اتفاقية مستوى الخدمة. لن يسمح لك ذلك بالبدء في تحرير المهام بشكل أسرع الآن ، ولكنه سيسمح لك مرة أخرى بجمع الفواتير والرد على ذلك ومناقشة ما حدث مع الفريق ، ولماذا تعليق المهمة لفترة طويلة.
يمكن أن تعاني قابلية التنبؤ إذا كان
هناك الكثير من المهام على مطور واحد . من المستحسن التحقق من عدد المهام الموازية التي يقوم بها المطور عن طريق التعليمات البرمجية ، وليس عن طريق Jira ، لأن Jira لا تعكس دائمًا المعلومات ذات الصلة. نحن جميعًا بشرًا ، وإذا قمنا بالعديد من المهام المتوازية ، فإن خطر حدوث خطأ ما في مكان ما يزداد.
قد يواجه المطور بعض المشاكل التي لا يتحدث عنها ، ولكن من السهل التعرف عليها بناءً على البيانات. على سبيل المثال ، بالأمس كان لدى المطور نشاط رمز قليل. هذا لا يعني بالضرورة أن هناك مشكلة ، ولكن يمكنك ، كقائد فريق ، أن تأتي وتكتشف. قد يكون عالقًا ويحتاج إلى مساعدة ، لكنه يشعر بالحرج من سؤالها.
مثال آخر ، المطور ، على العكس ، لديه نوع من المهمة الكبيرة التي تستمر في النمو والنمو في التعليمات البرمجية. يمكن أيضًا اكتشاف هذا الأمر وربما تحلله بحيث لا توجد مشاكل في النهاية في مرحلة مراجعة الكود أو مرحلة الاختبار.
, . , , . .
. , , .
.
«» : , ; «»; «»; , bug fix. , , , , , — « ».
, , , , . , - , .
, , ,
, «» . , . ,
Legacy Refactoring , , , .
, —
SLA high-priority- . , . , , : high-priority critical .
, —
. -, . -, , . , .
-
Code review. ? , , — pull requests. -, pull request, . , , «in review», , Jira. , . , 2-3 , .
, , , pull request, . — , pull request ticket Jira .
, , , . pull requests, . , , : «, , - ». , . pull requests , , Jira.
pull request, , — , , - , - , , . .
, , — , , , , . : , « , ». , .
, , linter. , , - linter, - - , .
-
, SLA , , . , , .
SLA , "
- " — . , -. pull request .
,
- , . , CTO , , , . -. - , 6 50% - . , , 50%, CTO . , CTO - , 100%.
, — , - . :
, -.
-
, -. , .
100 . - 10 , - 1-2 . , .
— , , . , , , .
, , , , .
—
, - , . — churn -, .. pull request , .
,
- , , , . , commit, , -.
, - ( pull request ), - . , commit, . , .
. , — Jira. Jira. , «testing». task-tracker. , , - .
SLA . SLA , .
-, , , — . . , , ,
.
pipeline test- — , , , . build' , , — , . , 1-2 , , . , .
— . , . , , «» , , , , , .
, , ,
. . , , , , . , , , . : , , , .
, «» , , . , , , .
قصة أخرى تؤثر على جودة مرحلة الاختبار هي لعبة كرة الطاولة المستمرة بين الاختبار والتطوير . يقوم المختبر ببساطة بإعادة المهمة إلى المطور ، وهو بدوره ، دون تغيير أي شيء ، يعيدها إلى المختبر. يمكنك النظر إليه إما كمقياس ، أو تكوين الإشارة لمثل هذه المهام والنظر عن كثب في ما يحدث هناك وما إذا كانت هناك أي مشاكل.منهجية المقاييس
تحدثنا عن المقاييس ، والسؤال الآن - كيف نعمل مع كل هذا؟ قلت فقط الأشياء الأساسية ، ولكن حتى الكثير منها. ماذا تفعل بكل هذا وكيف تستخدمه؟
نوصيك بأتمتة هذه العملية إلى أقصى حد وإرسال جميع الإشارات إلى الفريق من خلال روبوت في المراسلة الفورية. لقد جربنا قنوات اتصال مختلفة: كل من البريد الإلكتروني ولوحة المعلومات - لا تعمل بشكل جيد. أثبت البوت أنه الأفضل. يمكنك كتابة روبوت بنفسك ، يمكنك أن تأخذ OpenSource من شخص ما ، يمكنك الشراء منا.
النقطة هنا بسيطة للغاية: يتفاعل الفريق بهدوء أكبر تجاه الإشارات الواردة من الروبوت من المدير الذي يشير إلى المشاكل. إذا أمكن ، قم بتوصيل معظم الإشارات مباشرةً إلى المطور أولاً ، ثم إلى الفريق ، إذا لم يستجب المطور ، على سبيل المثال ، في غضون يوم إلى يومين.
لا حاجة لمحاولة بناء جميع الإشارات في وقت واحد. معظمها لن يعمل ببساطة ، لأنه لن يكون لديك بيانات ، بسبب مشاكل تافهة مع الانضباط. لذلك ، أولاً ، نحدد الانضباط ونضع إشارات للممارسات التأديبية. وفقًا لتجربة الفرق التي تحدثنا معها ، استغرق الأمر عامًا ونصف لبناء الانضباط في فريق التطوير بدون أتمتة. مع الأتمتة ، بمساعدة الإشارات المستمرة ، يبدأ الفريق في العمل بشكل طبيعي بطريقة منضبطة في مكان ما بعد شهرين ، أي أسرع بكثير.
أي إشارات تجعلها عامة ، أو مباشرة إلى المطور ، لا يمكنك بأي حال من الأحوال التقاطها وتشغيلها. تحتاج أولاً إلى تنسيق ذلك مع المطور ، والتحدث معه ومع الفريق. يُنصح بإدخال جميع قيم العتبة في اتفاقية الفريق كتابيًا ، وأسباب قيامك بذلك ، وما هي الخطوات التالية ، وما إلى ذلك.
يجب أن يوضع في الاعتبار أن جميع العمليات لها استثناءات ، وتأخذ ذلك في الاعتبار في مرحلة التصميم.
نحن لا نبني معسكر اعتقال للمطورين حيث من المستحيل اتخاذ خطوة إلى اليمين ، خطوة إلى اليسار. جميع العمليات لها استثناء ، نريد فقط أن نعرف عنها. إذا أقسم البوت باستمرار ببعض المهام التي لا يمكن أن تتحلل حقًا ، والتي تستغرق 5 أيام للعمل عليها ، فأنت بحاجة إلى وضع علامة "عدم التتبع" بحيث يأخذ البوت ذلك في الاعتبار. يمكنك ، كمدير ، مراقبة عدد مهام "عدم التتبع" بشكل منفصل ، وبالتالي فهم مدى جودة تلك العمليات والإشارات التي تبنيها. إذا كان عدد المهام المسمى "عدم التتبع" في ازدياد مطرد ، فهذا يعني للأسف أن الإشارات والعمليات التي اخترعتها صعبة على الفريق ، فلا يمكنها متابعتها ، ويسهل الالتفاف عليها.
التحكم اليدوي لا يزال قائما . لن يعمل على تشغيل الروبوت والمغادرة في مكان ما في بالي - لا يزال عليك التعامل مع كل موقف. لديك نوع من الإشارة ، لم يستجب الشخص لها - سيكون عليك معرفة السبب في يوم أو يومين ، والتحدث عن المشكلة والعمل على حل.
لتحسين هذه العملية ، نوصي بإدخال ممارسة مثل
مضيفة العملية . هذا هو الموقف الانتقالي للشخص (مرة واحدة في الأسبوع) الذي يفهم المشاكل التي يشير إليها البوت. وأنت ، كقائد فريق ، تساعد المصاحبة على التعامل مع هذه المشاكل ، أي أن تشرف عليه. وبالتالي ، يزيد المطور من الدافع للعمل مع هذا المنتج. يتفهم فوائدها لأنه يرى كيف يمكن حل هذه المشاكل وكيفية التعامل معها. وبالتالي ، فإنك تقلل من تفردك في الفريق
وتقرب اللحظة التي يصبح فيها الفريق مستقلاً ، ولا يزال بإمكانك الذهاب إلى بالي.
الاستنتاجاتجمع البيانات. بناء العمليات بحيث تكون قد جمعت البيانات. حتى إذا كنت لا ترغب في إنشاء مقاييس وإشارات الآن ، يمكنك إجراء تحليل رائع بأثر رجعي في المستقبل إذا بدأت في جمعها الآن.
التحكم في العمليات تلقائيًا. عند تصميم العمليات ، فكر دائمًا في كيفية اختراقها ، وكيف يمكنك التعرف على مثل هذه الاختراقات من البيانات.
عندما تكون الإشارات قليلة لعدة أسابيع - أحسنت! واجهنا حقيقة أنه عندما يرى الفريق أن هناك إشارات أقل ، ويبدو أن الوضع يتحسن ، فإنه يبدأ في التوصل إلى بعض الممارسات الأخرى بشكل محموم ، ويبدأ في تنفيذ شيء ما من أجل رؤية حزم الإشارات هذه مرة أخرى. هذا ليس ضروريًا دائمًا ، ربما إذا كان هناك عدد أقل من الإشارات - كل شيء على ما يرام معك ، بدأ الفريق في العمل بالطريقة التي تريدها منذ البداية ، وقد انتهيت :)
تعال وشارك نتائج Timlid الخاصة بك على TeamLead Conf . سيعقد مؤتمر فبراير في موسكو ودعوة مفتوحة للأوراق .
هل تريد تجربة تجربة الآخرين؟ قم بالتسجيل في النشرة الإخبارية للإدارة لتلقي الأخبار حول البرنامج ولا تفوت وقت المساومة على تذاكر المؤتمرات.