الوفاء بالمواعيد النهائية الخاصة بك: الأساليب التي يستخدمها المطورون لتقدير الجهد

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

ماذا لو قدمت تقديرا سيئا؟

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

كيفية عمل تقدير للوقت

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

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

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

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

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

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

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

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

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

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

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

تستخدم طرق التقدير الأقل شيوعًا:

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

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

مثال على تقدير الجهد

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

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

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

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

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