عند حساب مدة المشروع ، نقيم تقليديًا مدة الخطوات المتوسطة ، ثم نلخصها ونضيف مخزنًا مؤقتًا لجميع أنواع الحوادث. ثم تقطعنا القيادة هذه الفترة إلى النصف. في إطار هذه المذكرة ، سيكون المؤلف مهتمًا بحساباتنا ، لأنه حتى مدير المشروع ذي الخبرة الواسعة غالبًا ما يفهم أن الفترة المحسوبة قصيرة جدًا ، وأحيانًا تختلف في بعض الأحيان عن تقييم خبيره الشخصي. نعم ، سوف يصحح تقديرات شروط المشروع والخطوات الوسيطة لتقييم خبرائه ، مع إتقان حقيقي مع بعض المعالجة ، سوف يفي بالموعد النهائي بدقة 15 ٪ ، ولكن تبقى الرواسب.
تشرح هذه الملاحظة سبب التناقض بين تقديرات الخبراء والتقديرات المحسوبة نظريًا. كما يتم النظر في سبب عدم تقدير تقييم الخبراء "المبالغة" في العادة إذا لم يتم ذلك على أساس إحصاءات عن تنفيذ مشاريع مماثلة. في النهاية ، يتم الكشف عن كيفية حساب مدة المشروع بشكل صحيح وشرح الموقف للأطراف المعنية قبل بدء المشروع أو أثناء المشروع.
جذر الخطأ
عندما نقيم فترة تنفيذ قطعة من العمل ، فإننا نحدد الرقم الأكثر احتمالا. يمكن أن يكون تقييماً للخبراء بشأن نقطة أو ثلاث نقاط ، كما هو الحال في بيرت. في مشروع معقد ، يمكن أن يكون هذا نمذجة حدودي. في جميع الحالات ، نرتكب الخطأ نفسه. والحقيقة هي أنه في جميع أساليب التقدير الكلاسيكية ، يُفترض أن لدينا توزيعًا طبيعيًا للقيمة المقدرة - وفقًا لـ Gauss. المنظرين مغرمون جدا من هذا التوزيع.
التوزيع الطبيعي يعني أن المشروع الذي تقدر مدته بشكل صحيح لمدة 6 أشهر من المرجح أن يكتمل في غضون 9 أشهر أو 3 أشهر. على مسافات متساوية من مركز التوزيع ، يكون احتمال الانتهاء من المشروع متساويًا - وهذه سمة من سمات منحنى Gauss. من ناحية أخرى ، في الممارسة العملية ، لم يشهد سوى عدد قليل من مشروع تكنولوجيا المعلومات الذي أنجز مرتين أسرع (بعد 3 أشهر) ، ولكن المشاريع التي يتم تأخيرها مرة واحدة ونصف من حيث (9 أشهر) التي نراها بانتظام. بالإضافة إلى ذلك ، مع التوزيع الطبيعي ، فإن نصف مشاريعنا ستنتهي قبل الوقت المقدر ، ونصف بعد. ولكن هذا لا يلاحظ في الممارسة أيضا. هذا يشير إلى أن التوزيع الطبيعي لتقدير المواعيد النهائية غير قابل للتطبيق. بمعنى ، ليس لدينا توزيع عادي ، ولكن البعض الآخر ، مع احتمال مختلف للإنجاز قبل التاريخ الأكثر احتمالًا وبعده.
النظر في التوزيع غير الطبيعي كمثال على هذا التوزيع. وسوف تظهر لنا ملامح هذه الفئة من التوزيعات. بالنسبة للتوزيع اللوغاريتمي ، يتجاوز المتوسط والتوقع الرياضي بشكل كبير الذروة:
في الرسم البياني المقدم ، توضح الذروة أكبر احتمال لتاريخ إنجاز المشروع ، وعادة ما يتضمن هذا الرقم هذا الرقم بالإضافة إلى هامش معين. يشير الوسيط إلى نقطة فصل يتم عندها إكمال نصف المشروعات قبل هذا الموعد النهائي ، والنصف الثاني بعده. يشير التوقع الرياضي إلى متوسط قيمة مدة المشروع. بالنسبة لجزء العمل ، سيكون للتوزيع نفس الميزات: هناك فرق كبير بين الفترة الزمنية الأكثر توقعًا لتنفيذ جزء العمل (تستند الخطط تقليديًا إلى ذلك) ومتوسط قيمة المصطلح.
للتنبؤ بمدة المشروع ، نحدد أطول سلسلة زمنية ونضيف مدة شظاياها. إذا قمنا بإضافة القيم الموزعة وفقًا لـ Gauss ، فيجب الحصول على المصطلح النهائي الصحيح في المتوسط. في الواقع ، سيتم الانتهاء من نصف أجزاء العمل قبل الموعد المحدد ، نصف في وقت لاحق ، وهذه الاختلافات سوف تلغي بعضها البعض. لمزيد من الشظايا ، بدقة أكثر يتم تعويض عدم التجانس. بالإضافة إلى ذلك ، يمكننا حساب الخطأ وتغيير الموعد النهائي بشكل طفيف بواسطة سيجما أو اثنين ، وهذا يتوقف على عواقب الموعد النهائي.
لكن ليس لدينا توزيع غوسي. في بلدنا ، يكون إطالة وقت تنفيذ كل قطعة عمل أكثر ترجيحًا من تقصيرها بنفس المقدار. نتيجة لذلك ، إذا أضفنا المواعيد النهائية لإتمام كل قطعة عمل على الأرجح ، فلن يتم تعويض أوجه عدم التجانس فيما يتعلق بالإنجاز ، بل يتم تضخيمها. علاوة على ذلك ، فإنهم يتكثفون في اتجاه إطالة المدى المتوسط الحقيقي للمشروع مقارنة بالتقدير. ما نلاحظه في الحياة الحقيقية: إذا تأخرت فترة الولاية الأولى ، فستكون جميع المصطلحات الأخرى متأخرة ، في حين أن التأخير سينمو فقط. فقط من خلال تطبيق جهود إضافية يمكن إيقاف تأخر المشروع.
إن إحدى ميزات طريقة الحساب هذه هي حقيقة معروفة: فكلما كان تجزؤ العمل أصغر لتقييم مدة المشروع ، كان التقدير أقل دقة. رغم أنه من الناحية النظرية ، يجب أن يكون العكس هو الصحيح. والسبب في ذلك هو أن تقييم الخبراء لدينا للعمل بأكمله ولأجزاء المكونة له مأخوذ من التجربة. تقوم الخبرة بتقييم كل عنصر بشكل مستقل ، وليس بناءً على الحساب ، والتي بموجبها يجب أن تكون مدة العمل هي مجموع فترات أجزائه المكونة. لا يعمل الحساب هنا ، نظرًا لأن مجموع المواعيد النهائية الأكثر احتمالًا لاستكمال الأجزاء لا يعطي الموعد النهائي الأكثر احتمالًا لاستكمال جميع الأعمال - يمكن تلخيص التوقعات الرياضية فقط بشكل صحيح.
إذا حاولنا تغيير المصطلح المقدر للمشروع بأكمله أو أجزائه قليلاً بواسطة سيغما أو اثنين ، مع الأخذ في الاعتبار أن التوزيع طبيعي ، فهذا لا يساعد كثيرًا ، لأن ذيل التوزيع يكون أكثر سمكًا من منحنى غاوسي. نتيجة لذلك ، بسبب هذه الزيادة في تقدير المصطلح ، لا يمكن للمرء حتى بلوغ الوسيط ، ناهيك عن متوسط قيمة مدة المشروع في شكل توقعات رياضية.
ما يجب القيام به
من ناحية ، ينبغي إضافة التوقعات الرياضية. من ناحية أخرى ، نحن لسنا علماء الرياضيات. نحن من واقع الحياة ونحن نفهم مشكلة حساب المعلمات من الرسوم البيانية حتى عندما يكون هناك وقت لهذا وبعض الإحصاءات المتراكمة. ولكن هناك طرق أخرى. في النهاية ، مشكلة تقييم توقيت أكثر من عشر سنوات ، والممارسة قد تعلمت العمل معها.
طريقة Brooks : نعتبر أن فترة تنفيذ البرنامج "وجهاً لوجه" (المستخدم هو المبرمج نفسه) وضربها في 3 لمنتج البرنامج (المستخدم عبارة عن دائرة غير محدودة من الأشخاص) أو مجمع البرمجيات (في الواقع الحالي - مجموعة من الخدمات المصغرة) و 9 لمنتج برنامج النظام ( في الواقع الحالي ، مجموعة من مكونات البنية التحتية ذات الصلة). من حيث أن هذه المعاملات تأتي من الناحية النظرية ، فقد تم تبريرها جيدًا من الناحية النظرية في الفصل الأول من كتاب بروكس "شهر الأسطوري" ، وهذا الوصف لعام 1975 تم تحويله جيدًا إلى حقائق حالية.
طريقة Scrum : نحن نقدم وحدة وسيطة مجردة من تعقيد تنفيذ وظيفي ، ونحن ننظر في إحصاءات تنفيذ الوظيفية المقاسة في وحدات معينة من وظيفية ، نطلب من الفريق لتقييم مدى تعقيد مهام المشروع ، وترجمة الوحدات في Scrum التكرار (سرعات) من طول المعروفة والحصول على تقدير للمصطلحات لهذا الفريق التطوير. نظرًا لأننا نعمل مع الإحصاءات التي تم جمعها حقًا وأن الفريق مسؤول عن تقديراته عن التعقيد ، فإن ربط المدة بوحدة العمل هو توقع رياضي وبالتالي فإن نصف المسافات السريعة ستنتهي قبل ذلك بقليل ، نصف بعد ذلك بقليل. في الممارسة العملية ، في نصف تكرارات Scrum ، سيتعين على الفريق المشاركة في المهام ، وإضافة مهام غير مخططة في النصف ، بحيث يظل طول العدو ثابتًا.
مهمة نقل Scrum Evaluation من فريق إلى فريق آخر هي مهمة فنية. لا يمكن ترحيلها ببساطة عن طريق إدخال عامل تحويل لوحدات العمل في فريق ما في وحدات العمل في الفريق الآخر. الحقيقة هي أن فريقًا واحدًا يتمتع بواجهة أمامية جيدة في تكوينه ، لكن ليس لديه أخصائي أساسي جيد ، والفريق الآخر لديه أخصائي أساسي جيد ، لكن مهام الخط الأمامي له تتزايد تعقيدًا. سوف تؤدي الاختلافات في تخصص المطورين إلى حقيقة أنه فيما يتعلق بالمهام الخلفية ، سيكون لدى أحد الفريقين فائض في التعقيد تجاه المهام في قاعدة البيانات ، والآخر في المقدمة. بالإضافة إلى ذلك ، يحدد الفريق نفسه المستوى الضروري للجودة الداخلية للمنتج ، والفرق المختلفة تحدده بطريقة مختلفة قليلاً عن الفرق المجاورة ، مما يجعل من الصعب أيضًا إعادة حساب وحدات العمل. بمعنى أنه من الممكن ترجمة الوحدات الوسيطة لأحد الفرق إلى الوحدات الوسيطة لفريق آخر من خلال مقارنة تقديرات المهام المماثلة ، ولكن ينبغي أن تؤخذ هذه المهام من أنواع مختلفة من الأنشطة ، مع مراعاة نقاط القوة والضعف في الفرق ومراعاة خصوصيات إعداد Scrum الخاصة بهم.
طريقة العناصر الوظيفية : نحن نقدم وحدة وسيطة من مدخلات العمل ، ونجمع قائمة بالعناصر الوظيفية (الشاشات في المتصفح ، والخدمات المصغرة ، وعناصر البنية التحتية المخصصة ، وما إلى ذلك) ، ونقيم مدى تعقيد العمل على كل عنصر وظيفي في الوحدات الوسيطة. بعد ذلك ، استنادًا إلى خبرتنا الخبيرة في العمل مع فريق تطوير محدد ، نقوم بتقييم عامل التحويل للوحدة الوسيطة بمرور الوقت. أنا شخصياً ما زلت أقيم بشكل مستقل عوامل التحويل لأنواع مختلفة من الأنشطة: التحليلات والتصميم وكتابة بيانات المهام وكتابة التعليمات البرمجية والتخطيط والاختبار والتكامل ، إلخ. بعد ذلك ، يجب مراعاة ترتيب العمليات ، وفترة التأخير المميزة بين إتمام العملية السابقة وبدء عملية جديدة ، وينبغي تحديد مدة المشروع باستخدام طريقة المسار الحرج.
حتى الآن ، لقد عملنا مع العوامل الداخلية للمشروع. ولكن لدينا أيضًا جهات خارجية: المقاولون الخارجيون والإدارات ذات الصلة والموردون والعميل. تتشابه المشكلات معهم تمامًا: فهي تستجيب مرتين أو أسرع أو تقل كثيرًا عن مرة ونصف أكثر من القيمة الأكثر احتمالًا. وهذا هو ، لا يوجد أيضا توزيع توقيت طبيعي. كما يجب وضع ذلك في الاعتبار على أساس إحصاءات العمل مع العملاء والمقاولين والوحدات ذات الصلة ، وإذا أمكن ، يجب حمايتهم بمساعدة العقوبات.
تبرير الوقت
وهكذا ، قدّرنا المدة المتوقعة للمشروع. كيف تبرر المصطلح المستلم؟ استنادا إلى الحسابات التي أجريت. على سبيل المثال ، عادةً ما يقوم مؤلف ملاحظة للمشروعات بخلاف Scrum بإنشاء جدول مرئي كبير متعدد الخطوط في أوراق Google مع حساب تفصيلي حسب طريقة العناصر الوظيفية. يعتمد الحساب على الممارسة ، وجميع المعاملات والمعاملات مرئية ، والممارسة للأطراف المهتمة عادة ما تكون حجة قوية وجيدة ، حتى لو اتضح أنها فترة غير مريحة لبعض الأفراد. خاصة أن الممارسة بصرية والتي تم الحصول عليها في إطار الشركة الحالية.
هل سيتفق أصحاب المصلحة ، مثل الإدارة ، على جدول زمني جيد الإعداد ومستنير؟ ليس دائمًا ، حتى لو كانت الأطراف المعنية تدرك تمام الإدراك أن التقييم صحيح. في بعض الأحيان يكون التقييم غير مقبول لأسباب خارجية ، لكن هذا يمثل بالفعل ألمًا للأطراف المعنية ، مما يؤدي إلى قرار صعب من قبل الإدارة بشأن التوقيت. ومع ذلك ، فإن مشاهدة الحسابات على أساس الخبرة والإدارة وغيرها من الأطراف المعنية لديها فرصة للتأثير بشكل متوقع على المدة النهائية للمشروع من خلال تخصيص موارد وسلطات إضافية. في بعض الأحيان ، ستواصل الإدارة التي تتفهم حالة التوقيت خفض المواعيد النهائية دون تخصيص موارد إضافية وسلطة. كيفية التعايش مع هذا هو موضوع مذكرة منفصلة.