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

لنفترض أنك تقيم مشروعًا في أسبوع واحد. افترض أن هناك ثلاث نتائج محتملة على قدم المساواة: إما سيستغرق الأمر أسبوعين أو أسبوع واحد أو أسبوعين. النتيجة المتوسطة هي في الواقع نفس التقدير: أسبوع واحد ، ولكن متوسط ​​القيمة (ويعرف أيضًا باسم متوسط ​​، ويعرف أيضًا باسم القيمة المتوقعة) هو 7/6 = 1.17 أسبوعًا. يتم معايرة النتيجة بالفعل (غير متحيزة) للمتوسط ​​(وهو 1) ، ولكن ليس للمتوسط.

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



إذا أخذنا لوغاريتم معامل التضخم ، فسوف نحصل على توزيع طبيعي بسيط بمركز يساوي حوالي 0. ​​وهذا يفترض أن متوسط ​​معامل التضخم هو 1x ، وكما تأمل ، تذكر ، log (1) = 0. ومع ذلك ، قد تكون هناك حالات عدم يقين مختلفة حول 0 في العديد من المشكلات. يمكننا نمذجتها عن طريق تغيير المعلمة σ ، والتي تتوافق مع الانحراف المعياري للتوزيع الطبيعي:



فقط لإظهار الأرقام الحقيقية: عندما سجل (الفعلي / المقدرة) = 1 ، ثم معامل التضخم exp (1) = e = 2.72. من المحتمل أيضًا أن يمتد المشروع إلى exp (2) = 7.4 مرة ، وأنه سينتهي عند exp (-2) = 0.14 ، أي 14٪ من الوقت المقدر. بشكل حدسي ، السبب في أن المتوسط ​​كبير جدًا لأن المهام التي تعمل بشكل أسرع من المتوقع لا يمكن أن تعوض عن المهام التي تستغرق وقتًا أطول من المتوقع. نحن مقيدون بـ 0 ، لكن غير محدود في الاتجاه الآخر.

هل هذا مجرد نموذج؟ أتمنى أن تتمكن! ولكن سرعان ما سأحصل على البيانات الحقيقية وعلى بعض البيانات التجريبية سأظهر أنه في الواقع يتماشى تمامًا مع الواقع.

تقدير مواعيد تطوير البرمجيات

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

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


لاحظ أن المتوسطات تضيف ما يصل و 4.95 = 1.65 * 3 ، لكن الأعمدة الأخرى لا تفعل ذلك.

الآن دعونا نضيف ثلاثة مشاريع مع سيغما مختلفة:


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


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

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

يُظهر الرسم البياني المتوسط ​​والنسبة المئوية 99 كدالة من عدم اليقين (σ):



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

أين هو الدليل التجريبي؟

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

فلنضع مخططًا مبعثرًا سريعًا للوقت المقدر والفعلي:



معدل التضخم المتوسط ​​لمجموعة البيانات هذه هو 1X ، في حين أن متوسط ​​المعامل هو 1.81x. مرة أخرى ، يؤكد هذا الحدس بأن المطورين يصنفون بمتوسط ​​جيد ، ولكن المتوسط ​​أعلى من ذلك بكثير.

لنلقِ نظرة على توزيع معامل التضخم (اللوغاريتم):



كما ترون ، يتمركز بشكل جيد حول 0 ، حيث يكون معامل التضخم exp (0) = 1.

خذ الأدوات الإحصائية

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

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

نطبق توزيع الطلاب على التوزيع السابق:



يتقارب لائق ، في رأيي! تحدد معلمات توزيع الطلاب أيضًا توزيع غاما العكسي لقيم::



لاحظ أن قيم σ> 4 غير محتملة للغاية ، ولكن عندما تحدث ، فإنها تتسبب في انفجار متوسط ​​يبلغ عدة آلاف من المرات.

لماذا تستغرق مهام البرنامج دائمًا وقتًا أكثر مما تعتقد

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

في حين أن معدل التضخم المتوسط ​​من هذا القياس هو 1x (كما كان من قبل) ، فإن معدل التضخم بنسبة 99٪ هو 32x ، لكن إذا ذهبت إلى النسبة المئوية 99.99 ، فهذا يمثل 55 مليونًا ! تفسير واحد (مجاني) هو أن بعض المهام مستحيلة في النهاية. في الواقع ، يكون لهذه الحالات القصوى تأثير هائل على المتوسط بحيث يصبح متوسط ​​معدل التضخم لأي مهمة بلا حدود . هذه أخبار سيئة للغاية لأي شخص يحاول الوفاء بالمواعيد النهائية!

ملخص

إذا كان النموذج الخاص بي صحيحًا (كبير إذا) ، فإليك ما يمكن معرفته:

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

الملاحظات

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