ربما سأخرج اليوم عن المألوف والمعتاد في مدونتي المعنونة بـ (البرمجة مع عبد المنعم) وسأخبركم اليوم عن أمر شخصي قد لا يهم الكثيرين منكم ولكنه يهمني أنا من الدرجة الأولى .. ببساطة وبدون فلسفات كثيرة .. الحمد لله لقد أصبحت أباً.

في يوم الخميس 11/11/2010 أنجبت زوجتي ولله الحمد رزان .. جعلها الله قرة عين لي ولها .. وبارك الله فيها وحفظها .. وجعلها كأم المؤمنين عائشة رضي الله عنها وأرضاها.

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

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

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

يوميات رزان : http://razandiary.wordpress.com

تضرعوا لله بالدعاء أن يجعلها كأم المؤمنين عائشة رضي الله عنها وأرضاها .. حليلة خير خلق الله محمد صلى الله عليه وسلم. اللهم آمين

Advertisements

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

  1. ما علاقة هذه الأسئلة بتقدير البرمجيات .. إنها مجرد أسئلة عامة؟!
  2. لا أمتلك الإجابات الصحيحة للأسئلة فأنا لا أعرف متى ولد الاسكندر الأكبر!
  3. كيف يمكنني وضع إجابات وأنا لا أعرف حتى إجابات هذه الأسئلة؟!

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

1.     لكل سؤال عليك أن تقوم بوضع الحد الأدنى والحد الأعلى بحيث أن تكون هذه الأرقام في رأيك تمثل 90% من الإجابة الصحيحة.

2.     احذر أن تجعل المدى بين الحدين كبير جداً .. أو صغير جداً. عليك أن تجعل المدى مناسب حتى يستوعب النتيجة الصحيحة في رأيك بنسبة 90%.

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

4.     يجب عليك الإجابة على كل سؤال ومليء كل البيانات لأن السؤال المتروك يعتبر إجابة خاطئة.

5.     مدة الاختبار 10 دقائق فقط.

في هذه الرسالة سنقوم بتوضيح ما الغرض من الاختبار؟! وما وجه الاستفادة منه؟! بالإضافة إلى أننا سنقوم بحل الاختبار بالطبع.

الغرض من الاختبار؟

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

ما هو مدى الثقة في الـ “90%”؟

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

وهذا معناه بما أننا لدينا 10 أسئلة أنك بعد الانتهاء من الاختبار عليك أن تكون واثقاً من إجابتك على 9 أسئلة من 10 إجابة صحيحة.

إذا كانت شخصيتك ذات طبيعة حذرة فإنك سوف تقوم بوضع نطاق كبير لكل سؤال بحيث يمكنك ذلك من الحصول على 10/10 في الاختبار. وإذا كانت طبيعة شخصيتك متسرعة قليلاً فسوف تضيق نطاقات إجاباتك أكثر مما ينبغي فعندها سوف تحصل على 7 أو 8/10 في الاختبار.

تعالوا نرى نتيجة هذا الاختبار لمئات الممتحنين:
تعالوا نحلل نتيجة الاختبار:

  • متوسط الإجابات الصحيحة هي 2.8.
  • فقط 2% استطاعوا تحقيق 8/10 أو أكثر في نتيجة الاختبار!
  • لم يحصل أي ممتحن على 10/10 مطلقاً!

من خلال هذه المعطيات تم استنتاج أن كلمة “كن واثقاً بنسبة 90%” تعني في الحقيقة “كن واثقاً بنسبة 30%” وقد أثبتت بعض الدراسات الأخرى هذه النظرية بالفعل لدى معظم البشر!

بالتشابه، وُجد الكثير من المشاريع التي يقدم مديرها جدولاً زمنياً يندرج تحت “واثقاً بنسبة 90%” إلا أنه في الحقيقة الجدول الزمني لهذا المشروع يتعدى ذلك بكثير في الأغلب! فإذا كانت هذه الجداول الزمنية بالفعل تمثل “ واثقاً بنسبة 90%” هذا يعني أن الفريق سوف يتأخر عن تسليم المشروع بنسبة 1 إلى 10 من الجدول الزمني المقترح وهو الذي لا يحدث في أغلب الأحيان.

ولهذا فإن نسبة 90% ليست لها معنى تماماً في عالم تقدير البرمجيات إلا إذا تم تدعيمها ببعض الدراسات الإحصائية والأرقام المدعمة لها. وسيتم الحديث عن هذا الموضوع فيما بعد.

ولكن كقاعدة:

لا تعطي تقديراً لأحد بصيغة “واثقاً بنسبة كذا” خاصة الـ “90%” إلا إذا استطعت بالفعل أن تدعم هذا التقدير.

إذا لم تكن اختبرت نفسك بعد يمكنك الرجوع للاختبار الآن وحاول مرة أخرى. وقد تفاجأ إذا وجدت نفسك لم تجاوب إلا القليل من الإجابات للمرة الثانية!

ما هي سعة النطاق وكيفية تحديده؟!

عندما تسأل القلة القليلة التي استطاعت أن تحرز 7 أو 8/10 في الاختبار .. كيف استطعت تحقيق هذه النتيجة؟! الإجابة تكون واحدة وبكل بساطة: لأنني قمت بتوسيع النطاق الخاص بإجاباتي جداً!

ولكن الرد على هذه الإجابة في الحقيقة هو: لا .. لم تقم بتوسيع نطاق إجاباتك بطريقة كافية لقد أهدرت 3 أسئلة ولم تجبهم. إذا كانت نطاقاتك واسعة جداً كما تقول لكنت أحرزت 10/10 في الاختبار.

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

ولكن في الحقيقة عليك أن تأخذها قاعدة عامة:

لا تحاول أن تتصنع أنك تقدر البرمجيات جيداً عن طريق تقليل وتضييق الجدول الزمني. ولكن كن متأكداً أنك تقوم بوضع نطاق مناسب (كبير كان أو صغير) يساعدك على تحقيق نسبة الثقة التي قمت بتقديرها “واثقاً بنسبة كذا”.

من أين يأتي الضغط الذي يجعلك تختار نطاق ضيق؟!

عندما كنت تقوم بالاختبار .. هل استشعرت أنك مضغوط لكي تجعل نطاقاتك كبيرة؟! أم لتجعل نطاقاتك أضيق؟!

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

بعد مناقشة الكثير من المدراء والمبرمجين اتضح أن الضغط يأتي من عاملين:

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

2.     عامل خبرة .. يأتي بسبب التعاملات الدائمة مع رؤساء العمل أو العملاء حيث يصرون بأي شكل من الأشكال على تضييق نطاقات التقدير.

لذا .. كقاعدة عامة:

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

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

ما علاقة هذا الاختبار (هذه المعلومات العامة!) بعالم البرمجيات من الأساس؟!

في عالم البرمجيات لن يقوم أحد بسؤالك أبداً عن تقديرك لحجم البحيرات الكبرى! ولن يسألك أحد عن تداول العملة في الولايات المتحدة الأمريكية خاصة إن لم تكن من قاطنيها (لا يمكن أن يكون هذا معقولاً)؟!

فما العلاقة بين الاختبار وبين عالم البرمجيات؟

عادة ما يسأل المبرمج أو المسئول عن التقدير عن تقدير مشروع خارج نطاق عملك أصلاً، أو مشاريع سوف يتم تطبيقها بتقنيات جديدة لا تعرفها جيداً بعد، أو تقدير التأثير على الإنتاجية عندما نقوم باستخدام أدوات جديدة مثل VS2010 مثلاً … وغير ذلك من الأمور.

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

في النهاية، ما هي إجابات الاختبار؟!
الإجابة السؤال
10000 درجة فهرنهايت .. 6000 درجة سليزيوس درجة حرارة سطح الشمس
31 درجة شمالاً خط العرض لمدينة شنغهاي
44,390,000 كم مربع – 17,139,000 ميل مربع مساحة قارة آسيا
356 قبل الميلاد العام الذي ولد فيه الاسكندر الأكبر
719.9 بليون دولار أمريكي (البليون الأمريكي = 1000000000 ، البليون الإنجليزي = 1000000000000) إجمالي قيمة العملة المتداولة في الولايات المتحدة 2004
5,500  ميل مكعب

23,000  كم مكعب

2.4 x 10^22  قدم مكعب

6.8 x 10^20  م مكعب

1.8 x 10^23  جالون أمريكي

6.8 x 10^23  لتر

إجمالي حجم المياة في البحيرات الكبرى
1.835 بليون دولار أمريكي مبيعات تذاكر فيلم تيتانك
84,300  ميل

135,663  كم

إجمالي طول الخط الساحلي للمحيط الهادئ
22 مليون عدد عناوين الكتب التي نشرت في الولايات المتحدة منذ 1776
380,000 باوند

190  طن إنجليزي

170,000  كجم

170 طن متري

أكبر حوت أزرق تم تسجيله من قبل
الملكية الفكرية محفوظة لكتاب Software Estimation لـ Steve McConnell

أرجو أن أكون أزلت كل الالتباسات السابقة .. وفي المرة القادمة سنبدأ التحدث عن فائدة دقة التقديرات .. وكيفية الوصول بالتقديرات إلى الدقة المطلوبة.


في المرة السابقة انتهينا من بعض التعريفات الخاصة بعلم تقدير البرمجيات وما هو التقدير الجيد وكيفية الوصول إليه. أما اليوم فتعالوا نختبر أنفسنا بالفعل الآن .. هل نحن نمتلك المهارات والإمكانيات التي تؤهلنا لتقدير البرمجيات جيداً.الاختبار التالي سوف يقيس مستواك وإمكانياتك في التقدير بصفة عامة فاتبع التعليمات الآتية بدقة: 

1.     لكل سؤال عليك أن تقوم بوضع الحد الأدنى والحد الأعلى بحيث أن تكون هذه الأرقام في رأيك تمثل 90% من الإجابة الصحيحة.

2.     احذر أن تجعل المدى بين الحدين كبير جداً .. أو صغير جداً. عليك أن تجعل المدى مناسب حتى يستوعب النتيجة الصحيحة في رأيك بنسبة 90%.

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

4.     يجب عليك الإجابة على كل سؤال ومليء كل البيانات لأن السؤال المتروك يعتبر إجابة خاطئة.

5.     مدة الاختبار 10 دقائق فقط.

[الحد الأدنى – الحد الأعلى] السؤال
[ _______________ – _______________ ] درجة حرارة سطح الشمس
[ _______________ – _______________ ] خط العرض لمدينة شنغهاي
[ _______________ – _______________ ] مساحة قارة آسيا
[ _______________ – _______________ ] العام الذي ولد فيه الاسكندر الأكبر
[ _______________ – _______________ ] إجمالي قيمة العملة المتداولة في الولايات المتحدة 2004
[ _______________ – _______________ ] إجمالي حجم المياة في البحيرات الكبرى
[ _______________ – _______________ ] عدد مبيعات تذاكر فيلم تيتانك
[ _______________ – _______________ ] إجمالي طول الخط الساحلي للمحيط الهادئ
[ _______________ – _______________ ] عدد عناوين الكتب التي نشرت في الولايات المتحدة منذ 1776
[ _______________ – _______________ ] أكبر حوت أزرق تم تسجيله من قبل
الملكية الفكرية محفوظة لكتاب Software Estimation لـ Steve McConnell

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


في المرة السابقة تحدثنا عن علاقة تقدير البرمجيات بعلم الاحتمالات. وعرفنا الكثير عن هذا الجانب. في هذه المرة سنتحدث عن علاقة تقدير البرمجيات بالتحكم في المشروع ومجرياته. 

تقدير البرمجيات والتحكم في المشروع

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

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

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

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

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

ولهذا عملياً فعندما يتم تسليم مشروع ما بـالرقم التقريبي لعدد أعضاء الفريق وبالرقم التقريبي للمدة الزمنية والبرقم التقريبي للميزانية فإننا نقول أن المشروع قد وافق التقدير على الرغم من الشوائب والأحداث المتلاحقة التي حدثت داخل المشروع كما أسلفنا.

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

ولهذا فعلينا التحدث باستفاضة عن الدور الأساسي والصحيح للتقدير.

الدور الأساسي والصحيح لتقدير البرمجيات

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

لذا تعالوا لنضرب مثالاً:

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

وضعت ثيابك ووجدت أنها سوف تدخل بالكاد في الحقيبة الصغيرة. ماذا ستفعل؟!

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

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

1.     الغرض الأساسي من التقدير ليس التكهن بنتيجة المشروع أو توقعها ولكن هو الإجابة على السؤال التالي: هل الأهداف المرجو تحقيقها مرنة نوعاً ما حتى يمكن التحكم في المشروع بصورة أو بأخرى لتحقيقها أم لا؟

2.     ليس المطلوب أن يكون التقدير دقيق 100% ولكن المطلوب أن يكون التقدير مفيداً. فعندما نمتلك تقديراً جيداً، وإدارة حكيمة للمشروع، وتحديد جيد للأهداف. يمكنك أن تصل بالمشروع لبر الأمان ويمكننا حينها القول أننا حققنا ما تم تقديره من قبل.

في المرة القادمة سأختبرك لتعرف هل أنت تستطيع تقدير البرمجيات بطريقة جيدة أم لا؟! .. ابقوا معنا

 


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

ما علاقة تقدير البرمجيات بنظرية الاحتمالات؟!

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

ولكن في الحقيقة فإن هذا العلم يرتبط ارتباطاً وثيقاً بالاحتمالات. كيف؟!

إذا كانت ثلاثة أرباع المشاريع في العالم تتعدى التقديرات الزمنية أو المالية، فإن احتمالات اكتمال مشروع برمجي معين في مدة زمنية محددة ودون تعدي التقدير المالي له ليست 100% على الإطلاق! ومن هنا ينشأ سؤال هام جداً: إذا كانت الاحتمالات ليست 100% فكم إذن؟!

عادة ما نسمع بعض التقديرات التي تمثل برقم واحد. على سبيل المثال: يمكنني إنهاء هذا البرنامج في 15 يوماً!

هذا النوع من التقدير لا يعتبرعملياً بالمرة ويسمى هذا التقدير: تقدير النقطة الواحدة. في الحقيقة هذا النوع غير مفيد بالمرة فهو ليس مقترناً باحتمالية معينة. إذا نظرنا للرسم البياني التالي:

سيتضح أن تقدير النقطة الواحدة يعني أنك تعني ضمنياً أنني يمكنني إنهاء هذا المشروع في 15 يوماً بنسبة 100% فلا يوجد احتمالية للفشل أبداً! وهذا النوع لا يعطي نوعية من المرونة ويسبب مشاكل وتعقيدات كثيرة. الحقيقة أن هذا النوع من التقديرات هو نوع من أنواع الأهداف المتنكرة في صورة تقدير.

لذا فيجب أن نضع قاعدة عريضة هي أننا عندما نجد تقديراً من هذا النوع فيجب علينا أن نسأل عن احتمالية هذا التقدير.

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

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

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

لذا فإن الرسم البياني التالي هو الرسم الصحيح العملي:

وكما هو ملاحظ من الرسم السابق أنه يوجد احتمالية 50% في أن يمر المشروع بسلام وبنجاح واحتمالية 50% أن يفشل المشروع أو أن يمر بمراحل سيئة. وهذه طريقة أخرى لتصوير هذا الأمر وتقريبه أكثر:

أيضاً يمكن تصوير هذا الأمر بشكل ثالث:

يتضح من الشكل الأخير عدة نقاط هامة جداً:

1.     عندما ترى تقدير النقطة الواحدة فلابد أن يكون لها احتمالية فهو ليس بشرط أن يكون 100% لهذا عليك أن تسأل. كمثال: في الشكل السابق احتمالية إنجاز المشروع في هذه المدة هي 10% وليس شرطاً أن يكون 100%.

2.     إذا قلنا أن تقدير برنامج ما 18 أسبوع فهذا لا يحتوي على الكثير من المعلومات ولا يمكن اعتباره مفيداً. ولكن الأفضل والأحسن أن تقول سيأخذ من 18 أسبوع إلى 24 أسبوع. أو أن تقرنه بنسبة كأن تقول سيأخذ 22 أسبوع بنسبة 75%.

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

في المرة القادمة سننهي هذه المقدمة بإذن الله لندخل بعدها في موضوع أخر بخصوص هذا العلم الشيق. ابقوا معنا.


فكرت كثيراً في الموضوع الذي أفتتح به مدونتي باللغة العربية وبعد تفكير عميق لم أجد أفضل من موضوع (تقدير البرمجيات). هذا العلم قلما أجد مطوراً أو مهندس برمجيات يعرفه معرفة تامة. صدقوني قلة قليلة جداً من يعرف قواعد وأصول هذا العلم النفيس.

في البداية كما تعلمنا من علمائنا أن من بركة العلم أن ننسبه لأهله. ولهذا فأنا لا أقول أنني أكتب كل سطر من رأسي بل إن هذه المقالات مستوحاة من كتاب لــ (ستيف ماكونيل) بعنوان (Software Estimation : Demystifying the Black Art).

فنقول متوكلين على الله ومستعينين به وبحوله وقوته:

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

قد يظن القاريء العزيز أنه يعرف ما هو تقدير البرمجيات أو بالإنجليزية (Software Estimation)، وبالطبع إذا كنت تقرأ هذا المقال فلا شك إما أنك مهتم بهذا العلم أو أنك تريد أن تعرف عن هذا العلم أو تظن أنك تعرف ما هو تقدير البرمجيات. ولكن الحقيقة المرة أن معظم هؤلاء لا يعرف ما هو تقدير البرمجيات بحق.

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

هل عندما يطلب منك مديرك في العمل أن تقدر الوقت اللازم لشيء ما، هل هو يطلب منك تقديراً قابلاً للتغيير ومبدأي؟ في الغالب لا، لأنه يطلب منك في الحقيقة خطة محددة وتعهد ما لكي تنفذ هدفاً محدداً.

تعالوا لنضرب مثالاً:

المدير: أحمد أريد منك تقديراً لهذا البرنامج وكم سيكلفنا من الوقت؟ هذا هو الملف الذي به كل المعلومات. تفضل.

أحمد: حسناً. سأبلغك بردي غداً إن شاء الله.

المدير (غداً): شكراً يا أحمد لقد قرأت ملفك بخصوص تقدير البرنامج وأرى أن شهراً يعتبر وقتاً مناسباً. ابدأ في البرنامج على بركة الله.

المدير (بعد شهر ونصف) وبحدة شديدة: أحمد لماذا كل هذا التأخير؟! لقد قمنا بتخطي المهلة المحددة!

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

المدير بصوت مرتفع للغاية: ماذا؟! لقد قمت بنشر حملاتي التسويقية للبرنامج منذ فترة على أن يتم الإصدار من نصف شهر مضى وأنت تطلب مهلة إضافة تقدر بـ 100% من الوقت الذي مضى!

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

لذا وجب علينا أن نقوم بتعريف ثلاثة مصطلحات: التقدير، التعهد، والهدف.

ما هو التعهد وما هو الهدف؟ وما هي العلاقة بين تقدير البرمجيات وبينهما؟

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

أما الهدف فهو: نتاج أساسي لأهداف العمل وغالباً ما يكون هدف مستقبلي مستقل عن عملية التقدير تماماً.

تعالوا نأخذ بعض الأمثلة للأهداف:

  • علينا بإصدار النسخة الثانية في نهاية الشهر الجاري من أجل اللحاق بمؤتمر جايتكس المقام في الإمارات.
  • هذه الوظائف عليها أن تنتهي قبل مطلع الشهر الجاري لكي نستطيع التوافق مع قرارات الحكومة الجديدة.
  • زادت المصاريف بصورة ملحوظة ولهذا تحددت ميزانية المشروع بمئة ألف جنيه.

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

أما التعهد أو الالتزام: فهو بكل بساطة وعد من أجل تحقيق هدف معين في تقدير زمني معين. والتعهد عادة ما يكون أشد إلزاماً من التقدير الزمني المطلق فإياك أن تخلط بينهما.

وبعد أن عرفنا هذه الفروق. هل ما زلت تعتقد أنك تعرف ما هو تقدير البرمجيات؟! انتظر .. سندخل في نقطة أخرى.

هل هناك علاقة بين تقدير البرنامج والتخطيط؟

ربما يكون التقدير والتخطيط موضوعان مترابطان ولكنهما مختلفان تماماً. فالتقدير ليس بتخطيط. والتخطيط ليس بتقدير.

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

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

النقطة الثانية هي أن التقدير يمثل الأساس لعملية التخطيط. ولكن التخطيط ليس شرطاً أبداً أن يوافق التقدير المكتوب.

فعلى سبيل المثال إذا كانت التقديرات بعيدة تماماً عن الأهداف (لاحظ الفرق بين التقدير والهدف كما أسلفنا) فعلى عملية التخطيط أن تضع هذا في الحسبان وتفرض نسبة عالية من المخاطرة. وأما إذا كانت التقديرات قريبة من الأهداف فهذا يعني أن عملية التخطيط سوف تحمل القليل من المخاطرة.

ولهذا فكلما زادت دقة التقدير كلما كانت عملية التخطيط أفضل. انظر العلاقة الهامة لتعرف أهمية علم تقدير البرمجيات.

كيف تتحدث مع مديرك عندما يطلب منك تقدير مشروع ما زمنياً اومالياً؟

ضربنا مثالاً سابقاً عن هذه النقطة ولكن نعود لنقوم بتفصيله ووضع مثال أخر. لنفرض الحوار التالي:

المدير: كيف تقدر هذا المشروع؟ إننا نريده في خلال ثلاثة أشهر من الآن لكي نلحق بالمؤتمر قبل البدء.

مدير الفريق: دعني أرى ثم أرجع لك …

وبعد فترة …

مدير الفريق: سيكلفنا سبعة أشهر لكي نقوم بإنهاء كل المتطلبات المطلوبة في المشروع

المدير: ألا تفهم ما قلته لك .. إننا نريده أن ينتهي في ثلاثة أشهر وليس سبعة!!

وربما يترك المدير النقاش وهو يقول لنفسه ما هذا الرجل! ألا يفهم ما تطلبه متطلبات العمل!

وربما يترك مدير الفريق النقاش وهو يقول لنفسه ما هذا الجهل المطبق ياله من مدير غير طبيعي! كيف نقوم بتطبيق شيء يحتاج لسبعة أشهر في ثلاثة أشهر!

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

فهذا هو النقاش المثالي الفعال:

المدير: كيف تقدر هذا المشروع؟ إننا نريده في خلال ثلاثة أشهر من الآن لكي نلحق بالمؤتمر قبل البدء.

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

المدير: أن يكون معي منتج للتسويق. ونتمنى وجود الخصائص كاملة 100% إن أمكن.

مدير الفريق: سنحاول أن نسلمك 100% في وقت التسويق ولكن ماذا لو لم يكن ذلك ممكناً، هل نقوم بتسليمك ما انتهى من الخصائص من أجل التسويق أم نقوم بتعديل موعد الإصدار لما بعد موعد التسويق؟

المدير: علينا أن نلحق الموعد المحدد للتسويق لذا سأختار أن يكون معي أي شيء حتى وإن لم تكن كل الخصائص مكتملة بعد.

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

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

لذا فعليك أن تأخذها قاعدة عريضة يا من ستكون مسئولاً عن التقدير … إذا سُئلت عن تقدير شيء ما فعليك أن تسأل هل المطلوب هو تقدير أم المطلوب خطة لتحقيق الهدف؟ فالبون بينهما شاسع شاسع.

سنتكلم في المرة القادمة عن أمور أكثر تعمقاً في هذا العلم وفي تعريفه قبل الدخول في تفاصيل أكبر وأعمق .. ابقوا معنا.