ما الأساليب التي يستخدمها المطورون لتقييم المهام؟

أهلاً بكم! النظرية المطلوبة لبدء التطوير واسعة جدًا. يمتلك بعض المتخصصين (مطوري الواجهة الخلفية في Java واللغات الأخرى) الكثير منها، بينما يمتلك البعض الآخر (على سبيل المثال، مطورو الواجهة الأمامية في JavaScript - React Native) أقل قليلاً. ومع ذلك، يجب أن يكون لدى كلاهما مخزون كبير ليس فقط من المعرفة التقنية، ولكن أيضًا من المعرفة "التنظيمية". تعد هذه المعرفة "التنظيمية" إحدى نقاط التقاطع بين مطوري الواجهة الأمامية والخلفية. أريد اليوم أن أتحدث عن جانب واحد من هذه المعرفة التنظيمية غير التقنية - حول تقييم المهام (التقدير). وبما أنني عملت فقط في منهجية Agile (والتي تعتبر في الواقع الأكثر شعبية)، في الجزء الفرعي منها، Scrum ، سأفكر في تقييم المهام في سياق Scrum . سأقول على الفور أن التقييم، الذي يسمى أيضًا التقدير، أمر صعب. بالنسبة لي شخصيًا كمطور، يعد هذا أحد أصعب جوانب الوظيفة/غير المرغوب فيها. هناك العديد من العوامل المختلفة التي يجب مراعاتها والتي يمكن أن تؤثر على تقييم المهمة. وفي الوقت نفسه، ستعتمد خطط التطوير الإضافي على توقعاتك.

ماذا لو لم تحصل على التقييم الصحيح؟

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

كيف يتم تقييم الوقت؟

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

ما هي نقاط القصة

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

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

كيف لا تستخدم نقاط القصة

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

ما هو سكروم بوكر

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

عدد غير معروف من نقاط النهاية

مهمة طويلة بلا حدود

بحاجة إلى استراحة

المزيد من طرق التقدير النادرة:

• بمقاسات القمصان - S، M، L، XL
• أو في الكلاب - الشيواوا، الصلصال، الدشهند، البلدغ، وما إلى ذلك (في رأيي، هذه هي أغرب وحدة لتقييم المشكلات =D)

يقوم الفريق بعد ذلك بمقارنة التقديرات المقدمة لنفس المشكلة من قبل مطورين مختلفين، وإذا اتفقوا، فهذا رائع! إذا لم يكن الأمر كذلك، فمن الضروري مناقشة أسباب الاختلافات في التقييم (الحجج). بعد ذلك، يمكننا أن نتوصل معًا إلى تقدير واحد، يوافق عليه الجميع، زائدًا أو ناقصًا. حسنًا، لماذا يتم استخدام البوكر للتخطيط لمشروع برمجي جاد؟ بعد كل شيء، هذا غريب إلى حد ما. في الواقع، يشجع هذا النوع من اللعب أعضاء الفريق على التفكير بشكل مستقل، ويطلب منهم عرض نتائجهم في نفس الوقت مع زملائهم في الفريق. وهذا بدوره يتجنب الاعتماد على آراء أعضاء الفريق الآخرين. وبخلاف ذلك، فإن المطورين الأقل خبرة سيبحثون ويعتمدون على تقييمات أعضاء الفريق الأكثر خبرة، مما ينفي فائدة تقييمهم. ولكن مع فتح النتائج في وقت واحد، فإن هذا أمر مستحيل في الأساس. مثال على تطبيق جدولة Scrum Poker هو من Atlassian .

مثال لتقييم المهمة

لنتخيل أن فريقك قد حدد مقياسًا معينًا للتقييم في نقاط القصة: يبدأ Scrum Poker بمهمة ما، وتقوم بتقييمها على النحو التالي:

• لم يسبق لك العمل مع تنفيذ وظيفة مماثلة من قبل - +3
• وظيفة مهمة متوسطة الحجم - +2
• تنفيذ المهمة معقد للغاية - +3
• درجة عالية من التعقيد في اختبارات الكتابة لهذه الوظيفة - +3

ونتيجة لذلك، تحصل على 11 نقطة قصة، ولكن نظرًا لعدم وجود مثل هذه البطاقة، فإنك تقدم 13 نقطة. يقوم زميل آخر لك بتقييم المهمة:

• عملت مع مشكلة مماثلة من قبل - +1
• وظيفة مهمة متوسطة الحجم - +2
• تنفيذ المهمة متوسط ​​التعقيد - +2
• متوسط ​​تعقيد اختبارات الكتابة لهذه الوظيفة - +2

ونتيجة لذلك، يحصل على 7 نقاط قصة، ولكن لا يوجد شيء من هذا القبيل في أرقام فيبوناتشي، ويضع بطاقة بأقرب رقم ممكن - 8. وبناءً على ذلك، يقدم أعضاء الفريق الآخرون تقديرات بناءً على آرائهم الشخصية. بعد ذلك، تعرض نتائجك وتكتشف أن جميع زملائك تقريبًا أعطوا التقدير 13، باستثناء مطور واحد أعطى التقدير 8. في هذه الحالة، تم إعطاؤه الكلمة وإبداء الأسباب. وهم مثلا هكذا: عمل سابقا مع نفس المشكلة، وهي ليست صعبة كما قد يبدو، وفي النهاية يقنع بقية أعضاء الفريق بتغيير حلهم من 13 إلى 8 قصة يشير إلى أنه سيساعد من يتولى هذه المهمة على اكتشافها. أو في النهاية سيفعل ذلك بنفسه. وبشكل عام، لا يهم ما إذا كان الآخرون يستمعون إلى حججه أم لا، لأنه بطريقة أو بأخرى، سيتم تعيين تصنيف لهذه المهمة، وسينتقل الفريق إلى التعرف على المهمة التالية. في المرات الأولى، ستكون التقديرات غير دقيقة، وكذلك تقديرات حجم العمل الذي تخطط للقيام به خلال الفترة الزمنية التالية (سباق السرعة). بعد كل شيء، يتم إجراء هذه التقديرات بدقة بناءً على التقديرات. بعد مرور بعض الوقت، حوالي ثلاثة أشهر، سيبدأ الفريق في تقدير المهام بشكل أكثر دقة، وسيصبح متوسط ​​حجم العمل الذي يمكن للفريق إكماله في كل سباق مرئيًا. ولكن هذا تخطيط عام لنطاق العمل، فهو يتعلق بالوقت أكثر، وفي هذه الحالة قد يكون هناك العديد من العوامل المختلفة التي لها تأثير. على سبيل المثال، ذهب أحد المطورين في إجازة لمدة أسبوعين. أي أنك تحتاج إلى شطب قدر معين من العمل المخطط (الوظيفة المخططة). أو قد يأتي مطور جديد إلى الفريق، لكن لا تحتاج إلى الاعتماد عليه بشكل كامل، لأن... عليك أن تأخذ في الاعتبار الوقت اللازم للتكيف مع المشروع، والذي يسمى onboarding . يمكن أن يكون هذا أسبوعين، زائد أو ناقص أسبوع، اعتمادًا على مدى تعقيد المشروع. هذا كل شيء لهذا اليوم، وآمل أن أكون قد حسنت معرفتك قليلاً في هذا الجزء غير الفني من المعرفة مثل تقدير المشكلة. إذا كنت تريد التعمق في هذا الموضوع، وكذلك في تفاصيل Scrum، أنصحك بشدة بقراءة كتاب "SCRUM" للكاتب Jeff Sutherland. لا أستطيع أن أضمن العواقب، لأنه ربما بعد ذلك سيكون لديك رغبة مزعجة في أن تصبح Scrum Master =D