كيفية تقدير وقت البرمجة

فن تقدير الوقت المستغرق لإنشاء البرامج

أريد حقًا أن أخبر الجميع كيف أقدر الوقت اللازم لبناء مشاريع البرامج.

في السنوات العشر الماضية سُئلت مئات المرات عن هذا السؤال.

  • "نحن بحاجة إلى تنفيذ هذه الميزة. كم من الوقت سيستغرق ذلك؟
  • "أعطني نظرة عامة مفصلة عن مقدار الوقت الذي سيستغرقه هذا المشروع من حيث الوقت. شهر واحد؟ 2 أشهر؟"
  • "أريدك أن تشحن هذا. هل يكفي 50 ساعة من وقت الدفع؟

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

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

في النهاية انتهى بي الأمر بالقول "لا أستطيع أن أقدر".

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

لكن يمكنني تقدير ذلكلا أحد قادر حقًا على التقديرعندما يتعلق الأمر ببناء البرمجيات ، بسبب التعقيدات الداخلية التي يمكن أن يضعها هذا المجال ضدك.

سيجد "المهندسون الحقيقيون" هذا أمرًا صعبًا للاعتراف به ، لكنني لم أكن أبدًا نوع مهندس حقيقي نموذجي.

ربما يكون التقدير هو أصعب شيء عند العمل كمطور.

إليك جدول مرجعي رائع يمكنك استخدامه عندما تحتاج إلى تقدير مهمة

مهمة أنت تقدر أنت نسيت الوقت الفعلي المطلوب
خطأ صغير 2 دقيقة نحتاج إلى العثور على الوظيفة التي بها الخطأ في الكود المصدري ، git pull ، والتحقق من أننا لم نكسر أي وظيفة أخرى ، نحتاج إلى إضافة بعض الاختبارات ، وإجراء الاختبارات ، وإصلاح الاختبارات التي كسرناها ، ونشرها ، وتحديثها تعقب علة ساعاتين
ميزة ثانوية ساعاتين تحتاج إلى إصلاح أن TODO المتبقي في الكود في الوظيفة التي ستقوم بتحريرها ، ومعرفة سبب وجود ملف//don't touch thisتعليق. تحتاج إلى إجراء اختبار يدوي بعناية ، بالإضافة إلى اختبار المتصفح ، والتحقق من سبب عدم عمل Edge كما هو متوقع. أوه ، نحن بحاجة إلى تحديث جميع لقطات الشاشة في المستندات 10 ساعات
تحسين أداء نقطة النهاية 10 ساعات أنت بحاجة إلى معايير معيارية دقيقة يمكنك استخدامها لإثبات أن تطبيقك الجديد يعمل بشكل صحيح ، وإضافة 10 اختبارات أخرى لم تكن موجودة من قبل ، وإلا فإنك تخاطر بكسر كود الإنتاج المستخدم من قبل 10000 عميل 5 ايام
أعد كتابة كود الواجهة بالكامل 3 أسابيع أنت فقط تبدأ مع الجديدأكثر قابلية للتوسعإطار العمل الذي كنت تجربه ، دون لمس واجهة المستخدم ، لكنك واجهت مجموعة جديدة كاملة من المشكلات ولكن هذه المرة لا يوجد StackOverflow أو Google للمساعدة ، لأن إطار العمل جديد جدًا. أنت تواجه مشاكل فريدة ، وتحتاج إلى توظيف مشرف المكتبة للعمل معك ، لكنه انتقل بالفعل إلى الشيء الرائع التالي. أثناء تواجدك فيه ، قرر فريق واجهة المستخدم العمل على إعادة كتابة كاملة للواجهة ، مرتين. يريد مديرو المنتج في منتصف الوقت التحول إلى منتج مختلف قليلاً 12 شهر

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

قد يبالغ البعض في التقدير ، ويتوقعون أنهم قد يواجهون صعوبات ، مضيفًا 30٪ أكثر مما يعتقدون.

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

ماذا تفعل بعد ذلك؟

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

لأنه بعد كل هذه العملية لن تنتهي أبدا.


المزيد من الدروس المعملية: