جدول المحتويات:
تقدير مشروع البرمجيات
بيكساباي
المقدمة
التقدير صعب. لسوء الحظ ، إنه ضروري أيضًا. تستخدم الشركات التقديرات لتوقع جداول الإصدار ، وتلتزم بعملائها ، وتقرر ما إذا كانت الميزة المقترحة تستحق التنفيذ ، وتتبع سرعة الفرق ، وترتيب أولويات العمل بشكل فعال. غالبًا ما يرغب المسؤولون التنفيذيون في معرفة متى ستكون الميزة أو التسليم جاهزًا للإنتاج. بعد كل شيء ، تطوير البرمجيات ليس استثمارًا تافهًا. بدون تقديرات ، كيف يقوم مدير المشروع بإجراء تقييم؟ إذا استطاع البشر التنبؤ بالمستقبل بدقة ، فلن يفوز الناس في سباقات الخيول بنسبة 2٪ من الوقت. التقدير هو اللغز الكبير. من الضروري والضروري أن تطلب الشركات من موظفيها فعل المستحيل: توقع المستقبل.
أولاً ، دعنا نراجع بعض طرق التقدير الشائعة (في حال فاتتك بعض الإثارة). ثم يمكننا أن ننظر إلى ما يعنيه هذا لنا ولمشاريعنا.
نموذج العراف
لا يتطلب هذا النموذج أي جهد تقريبًا لإنتاج تقدير. يفكر المقدرون قليلاً فيما يجب القيام به لتنفيذ واختبار ميزة ما ، ثم يقومون بطرح رقم. يبدو كثيرًا مثل "… (وقفة طويلة)… أممممم… 6 أسابيع." ثم يهز الجميع رأسه ونمضي قدمًا. يمكن أن يقضوا بعض الوقت في الواجهة الأمامية يتحدثون من خلال ما يعرفونه عن المتطلبات (والتي ربما ليست الصورة الكاملة). هذا التحليل الدقيق يجعل تقديرهم أكثر موثوقية. في نهاية المشروع ، هناك دائمًا سبب مقبول لكون التقدير بعيدًا عن الواقع. هناك دائمًا ظروف غير متوقعة يمكن أن تكون كبش فداء. غالبًا لا يخطر ببال أي شخص أن النموذج معيب بشدة.
فكيف يمكننا تحسين هذه العملية؟ أنا أعلم! يمكننا استخدام أسلوب التحليل (أي فرق تسد). يفترض هذا الأسلوب أنك تعرف النطاق الكامل للميزة أو المشروع على الواجهة الأمامية. يتم تقسيم كل ميزة إلى أجزاء صغيرة الحجم. يتم تقدير كل جزء (أسلوب العراف) ، ثم نجمعها للحصول على تقدير إجمالي للميزة / المشروع. هذا بالتأكيد نهج أكثر تعقيدًا ، لكنه يبدو أفضل لسببين:
- تميل الأجزاء الصغيرة من العمل إلى أن تكون أسهل في التقدير بشكل موثوق.
- بينما لا تزال هناك فرصة للخطأ (+/- بعض المبلغ) ، هناك افتراض بأن الأخطاء ستلغي بعضها البعض عندما تضيفها كلها وستحصل على تقدير عام أكثر موثوقية.
العيب الأساسي في هذا النهج هو أن المساهمين الفرديين (الأشخاص الذين يقومون بالعمل بالفعل) يقللون من شأنهم على مستوى العالم. إنهم لا يزالون أفضل بكثير من أولئك الذين فوقهم ومن حولهم ، لكن هذا ليس مستوى مرتفعًا. لا يبدو هذا هو الحال لأننا رأينا جميعًا حالات فاجأ فيها المطورون أنفسهم بإنجاز شيء ما قبل الموعد المحدد. لكن هذه نقطة بيانات واحدة وليست اتجاهًا. يربح الناس أحيانًا في الكازينو ؛ أنفق المال في كازينو كل يوم لمدة عام وستحصل على أموال أقل مما بدأت به. إذا قمت بتتبع التقديرات مقابل القيم الفعلية لمدة عام أو عامين ، فستكتشف أن التقديرات لا ترقى إلى الواقع. في حين أن العديد من رجال الأعمال على يقين تام من أن المطورين يملأون تقديراتهم بتكاسل ويستخدمون الوقت الإضافي لـ "لوحة الذهب" أو التحقق من مخزونهم ،تظهر البيانات خلاف ذلك. استراتيجية "الإلغاء" لا تعمل.
إذن ، ماذا الآن؟ دعنا نتخلى عن نموذج العراف ونتحول إلى نهج قائم على الحجم. اتضح أنه في حين أن البشر مروعون جدًا في تقدير وقت الإنجاز ، فإننا في الواقع جيدون في تحديد حجم شيء ما. نحن جيدون بشكل خاص في القياس المقارن ("إنه أكبر من ذلك ، ولكنه أصغر من ذلك الموجود هناك"). إذا كنا نفكر من حيث الحجم أو التعقيد بدلاً من الوقت ، فإن أدمغتنا تعالج الأمر بشكل أكثر موثوقية. ثم يمكننا أخذ قيم الحجم وحساب العدد الفعلي لساعات المشروع بناءً على صيغة سحرية رائعة! وذلك عندما يدخل نموذج نقاط الوظيفة الشائعة إلى المشهد (المرحلة اليسرى).
تحليل نقاط الوظيفة (FPA)
لتحليل نقطة الوظيفة ، نحتاج إلى تحديد خمسة أنواع من الأشياء في تطبيقنا: المدخلات الخارجية ، والمخرجات الخارجية ، والاستعلامات الخارجية ، وملفات الواجهة الخارجية ، والملفات المنطقية الداخلية (لا تقلق كثيرًا بشأن التعريفات ؛ يمكنك البحث عنها لاحقًا). كل مثال من هؤلاء (دالة) له تعقيد مرتبط به (منخفض ، متوسط ، أو مرتفع). نستخدم الجدول أدناه لمعرفة عدد النقاط التي يتم تعيينها لكل وظيفة.
الآن إذا جمعنا النقاط لجميع وظائفنا ، فقد نحصل على رقم مثل 457 نقطة دالة لمشروعنا. ثم نحتاج فقط إلى صيغة لمعرفة عدد الساعات… بناءً على مشروعنا الأخير ، كان "معدل التسليم" لدينا 15 نقطة دالة لكل شخص شهريًا. هذا ما يقرب من 30 شهرًا من العمل ، والتي يجب أن تستغرق أكثر من شهرين ونصف بقليل لفريقي المكون من 12. Ta-da!
هذا بالتأكيد أكثر تعقيدًا من نموذجنا السابق. في الواقع ، هناك أربعة مجالات رئيسية من التعقيد يجب التعرف عليها.
- أنواع المكونات الخمسة ليست بالضرورة بديهية ، ومن السهل أن تنسى وضع شيء ما في القائمة أو تخصيصه للحاوية الخطأ.
- يحتوي الجدول المستخدم لإنشاء نقاط الدالة فعليًا على أرقام سحرية تتطلب الكثير من الجهد للتحقق من صحتها. هل تمت معايرة هذه الأرقام بشكل صحيح لتوليد تقديرات موثوقة لفريقي؟
- يتم احتساب معدل التسليم (جزء مهم من اللغز) بناءً على إنتاجية فريقك. كم مرة نحتاج لحساب رقم جديد؟ في الواقع هناك القليل من الإرشادات حول هذا الأمر.
- ما الذي يشكل تعقيدًا منخفضًا أو متوسطًا أو مرتفعًا؟ كيف نحدد ذلك حتى يفهمه الجميع؟ أليس الحصول على هذا الحق أمرًا مهمًا لدقة حساباتنا؟
هناك العديد من الأجزاء المتحركة في هذا المثال البسيط للغاية ، ولم نناقش حتى نماذج التعقيد الأكثر تعقيدًا والبيانات الأخرى التي يمكن أن تلعب دورًا (مثل معدل التكلفة ، ومعدل الدعم ، وكثافة الخلل ، وما إلى ذلك). المزيد من الأجزاء المتحركة يعني المزيد من الفرص لحدوث الأخطاء. هل نجعل التقدير معقدًا للغاية الآن؟ نحن لا ندفع للمطورين مقابل تكريس الكثير من الوقت للتقدير. لا يمكنني بيع تقدير لعملائي. أحتاج إلى برنامج عمل. هل هناك أي شيء آخر هناك؟
الذهاب رشيق
الآن دعنا ننظر بإيجاز إلى agile scrum (يكفي فقط لإجراء مقارنة). كما ذكرنا سابقًا ، البشر سيئون في تقدير الوقت ، وهم جيدون جدًا في القياس المقارن. فيما يلي بعض المصطلحات لفهمها:
- العدو السريع - فترة زمنية محاصرة من الوقت (عادة أسبوعين).
- قصة المستخدم - قطعة عمل منفصلة ، ويفضل أن تكون صغيرة بما يكفي ليقوم بها شخص واحد في سباق سريع. هذا هو الشيء الذي نقدره.
الإستراتيجية الأكثر شيوعًا هي استخدام تسلسل فيبوناتشي (0 ، 1 ، 2 ، 3 ، 5 ، 8 ، 13) للتقديرات. إنه ليس خطيًا - كلما تصعد المقياس ، يزداد حجم الفجوات. المفتاح هو أن الفجوات يجب أن تكون واسعة بما فيه الكفاية بحيث لا يوجد سبب للجدل حول الاختلافات غير المهمة. بمجرد أن تتجاوز 3 ، يكون الفرق بين 4 و 5 أو 7 و 8 ضئيلًا للغاية لدرجة أنه من غير المجدي قضاء بعض الوقت في البحث عن أيهما. سيعمل أيضًا تسلسل Base-2 (0 ، 1 ، 2 ، 4 ، 8 ، 16 ، إلخ).
"لكن انتظر ، هذا مجرد رقم. ماذا يعنى ذلك؟ كم ساعة هي نقطة؟ " لا يُقصد من النقاط أن ترتبط ارتباطًا مباشرًا بالساعات ، لأنه إذا فعلوا ذلك ، فإن الفرق ستميل إلى العودة إلى التقدير في ساعات ثم تحويل ذلك إلى نقاط بطريقة ما. كما تمت مناقشته سابقًا ، تأتي دقة تقديراتنا من الحجم المقارن وليس تقدير عدد الساعات التي سيستغرقها شيء ما. إذا أعطيت الفريق القدرة على التفكير بالساعات ، فأنت بذلك تقلل من قدرتك على التقدير بدقة.
لنفترض أنك بدأت بممارسة المعايرة. اسحب فريقك إلى غرفة واطلعهم على قائمة من 10 إلى 12 قصة مستخدم. اختر واحدة صغيرة ولكن ليست الأصغر وافعل ذلك أولاً. راجعها وأعلن أن هذه القصة هي "3". أنت لا تسأل. أنت تقول. ثم ننتقل إلى القصة التالية. "إذا كان هذا الرقم 3 ، فما هذا؟" الآن يقوم الفريق بتحديد حجم القصص بالنسبة للقصص الأخرى. في النهاية ، سيكون لديهم فكرة جيدة عما يشكل "1" ، "2" ، إلخ. إنهم لا يقدرون. الوقت لا يهم. إنهم يحجمون القصص ، مقارنة بالقصص الأخرى التي لديها بالفعل رقم. يمكنك بعد ذلك وضع نماذج قصصية لكل رقم في التسلسل في مستند يسمى المسطرة. يمكنهم استخدام ذلك كمرجع إذا لم يكونوا متأكدين من ماهية "5".
الآن هذا هو المفتاح. الصلصة السحرية التي تجعل هذا العمل هي "السرعة" (عدد النقاط التي يمكن أن يكملها الفريق في سباق يبلغ متوسطه 3-4 سباقات سريعة). لنفترض أن العدو السريع الخاص بك هو أسبوعين وأن فريقك المكون من 8 أشخاص بمتوسط سرعة 35 نقطة. أنت تنجز 35 نقطة في 640 ساعة عمل (8 × 80 ساعة). إذا اكتشفنا أن إحدى الميزات ستستغرق حوالي 100 نقطة من العمل لبدء الانتهاء ، فأنا أعلم أن هذا يستغرق حوالي 6 أسابيع من العمل و 1900 ساعة تقريبًا. يصبح الفريق جيدًا جدًا في تحديد حجم القصص باستمرار ، ويمكنك الاستفادة من ذلك للقيام بالتخطيط لمشروعك. يعمل هذا الحساب لأن المدة متسقة من العدو إلى العدو السريع.
للقيام بالتخطيط عالي المستوى على المدى الطويل ، يمكنك أن تطلب من العملاء المحتملين تقسيم الميزات عالية المستوى إلى قصص مؤقتة من سطر واحد ووضع قيم النقطة عليها. ستكون هناك درجة من الدقة مفقودة ، لكنك تستفيد من النموذج الذي يفهمونه بالفعل. سيكون المسار الأكثر دقة هو الحجم النسبي على مستوى الميزة. "هذه الميزة أكبر من ميزة 40 نقطة ، وأصغر من ميزة 120 نقطة هناك ، وأكبر قليلاً من ميزة 65 نقطة التي فعلناها للتو." يتم تجميع القصص في "ملاحم". إذا كانت كل ميزة ملحمية ، فستعرف في النهاية عدد النقاط التي استغرقتها لإكمال هذه الميزة. احتفظ بسجل لذلك ويمكنك استخدامه لتخطيط الإصدار الخاص بك.
خاتمة
هناك الكثير من المنهجيات المستخدمة اليوم. لكل منها إيجابيات وسلبيات. بطريقة ما نحتاج إلى معرفة كيفية تعظيم دقة تقديراتنا حتى نتمكن من اتخاذ قرارات جيدة. هذا لا يعني أن تقديراتنا يجب أن تكون دقيقة. يجب أن تكون دقيقة بما يكفي لتكون مفيدة. إذا لم تفهم التقدير ، فقد تفترض أن التقديرات لم تكن دقيقة لأن الفريق لم يقم بعمل جيد. لم يقدروا بشكل صحيح ، أو لم ينفذوا المشروع بشكل صحيح. سيستمر الضرب حتى تتحسن التقديرات. لكن لا ينبغي استخدام التقديرات كالتزام. إنه أفضل تخمين بناءً على المعلومات المحدودة المتوفرة لدينا اليوم. عندما تظهر معلومات جديدة ، يجب أن نسمح بإعادة النظر في التقديرات. أي شيء آخر يتوقع المستحيل ، وهي مشكلة في القيادة (وليس مع الفريق).
نهج سكرم أبسط بكثير مما نراه في تحليل نقاط الوظيفة. وأود أن أقول إنها جديرة بالثقة أكثر من الطاولات السحرية ذات الأرقام السحرية. إنها تحصل على أكبر قدر من الضجة (الحد الأدنى من الجهد مع درجة عالية من الدقة). من منظور الجهد ، فإنه لا يخلق عملية ثقيلة للفرق لفهمها واستخدامها. يمكن أن يحدث جزء تقدير أجايل في الواقع بسرعة كبيرة بمجرد أن يفهم الجميع تفاصيل العمل المقدر. إنه بالتأكيد أفضل من سحب الأرقام من فراغ. تؤدي زيادة السرعة إلى شيء مهم للغاية: فهي تجلب البيانات التاريخية إلى الحساب. في كل عدو ، تقوم بإعادة حساب سرعتك. هذا أمر بالغ الأهمية ، لأنه بمرور الوقت يتغير الإنتاجية. قد تستمد الفرق التي تستخدم FPA معدل التسليم من مشروعها السابق ،والذي كان في بعض الحالات قبل عدة أشهر. ربما تغير الكثير منذ ذلك الحين. اقتراحي هو أن تستكشف Agile وأن تبذل جهدًا في فهم نقاط القصة وسرعتها. لا تتراجع عن التقدير بالساعات فقط لأن هذا ما تفهمه. أعتقد أنك ستشكر نفسك لاحقًا.