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

Question

لنفترض أن لديك مشروعًا سيشمل تطبيقين على الويب (سيشارك مجموعات DAL/DAO/BO وبعض مكتبات OSS):

• تطبيق إدارة شبه معقد يستخدم معرف Windows Live للمصادقة وهو قادر أيضًا على التواصل مع خدمات الإشعارات المختلفة (البريد الإلكتروني ، الرسائل القصيرة ، Twitter ، إلخ) ، تبلغ الملاحظات المستهدفة حوالي 10 ٪ من الوظائف
• تطبيق مستخدم منخفض إلى شبه معقد مع وظائف أقل ولكن المزيد من المتانة التي تستخدم معرف Windows Live أيضًا للمصادقة

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

أسئلة

1. كم من الوقت سيستغرق/عادة لتقديم تقدير موثوق/قيم؟
2. ما الذي تقترح أن يسرع التقدير دون التضحية بالدقة؟
3. مقدار الركود (من حيث التكلفة/الوقت) التي ستضيفها اعتمادًا على سرعة التقدير (عندما تقول: يمكنني تقدير ذلك أكثر قليلاً ، لأنني أعتقد أنه لا يزال بعيدًا تمامًا)

Answer 1

سؤال مهم. أخشى أن الجواب هو "الأمر يعتمد حقًا!" أعلم أن هذا ليس مفيدًا بشكل رهيب (على الرغم من أنه صحيح) ، فإليك بعض العوامل:

1) جودة واكتمال المتطلبات ومواصفاتها. هذا ، بالنسبة لي ، غالبًا ما يكون القاتل المتميز للمشروع. إذا لم يكن لديك متطلبات الجودة ، فليس لديك أي أساس معقول لتقدير. نحن نستخدم أسلوب "Rup-Lite" لتطوير المنتج هنا ، لذا بصفتنا مدير الهندسة ، لن أعطي أي شيء سوى تقدير الخشب الخشن حتى نتم إكمال مرحلة "التفصيل" الخاص بنا وحصلت على تسجيل الخروج من إدارة المنتج يتم تغطية 80 ٪ الأساسية من ميزات المنتج بدقة.

2) نطاق وطبيعة المنتج. أكبر/أكثر تكلفة/أكثر تعقيدًا = أطول بكثير لتقديرها. لقد أمضيت سنوات في العمل في أراضي Telco-Carrier التي تقدم حلولًا لها متطلبات الناقل القوية العادية ("5 9" من وقت التشغيل المطلوب من قبل SLA يعني أنه يجب عليك حقًا القيام بعمل جيد في تصميم الحلول واستعادة الفشل!). في هذا النوع من البيئة مع جميع الأجزاء المتحركة عبر المجالات الوظيفية في العمل ، فإن تقدير العمل سوف يتوقف على الحصول على الصورة كاملة ... على وجه التحديد ، يمكن أن يكون التبعيات متعددة الوظائف والتبعيات الخارجية قاتلًا حقيقيًا هنا. ومع ذلك ، فقد قمت أيضًا ببناء الكثير من برامج الانكماش والمؤسسة أيضًا. في تلك البيئات ، يكون الأمر أسهل بكثير لأن النطاق عادة ما يكون أصغر بشكل كبير ، وبالتالي أسهل في تقديره.

3) كيف "جديد" هذا المشروع؟ ما مدى "جديد" الفريق لهذا المنتج أو مجموعة التكنولوجيا؟ كلما كان المنتج أو الفريق الأحدث ، كلما طال أمد عازلة يجب تخصيصها.

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

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

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

شيء آخر: FWIW ، لقد كنت أفعل ذلك منذ عام 81 وأعتبر بدقة تقدير مدة/تكلفة المشروع باعتبارها الجزء الأكثر صعوبة/محفوفة بالمخاطر من الإدارة الهندسية.

Answer 2

نظرًا لأننا نستخدم أساليب Agile (Scrum ، على وجه التحديد) ، يستغرق الأمر حوالي ساعة أطول مما يتطلب المستخدمين تحديد الأولويات.

المزيد من الوقت لا يؤدي إلى مزيد من الدقة.

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

بشكل عام ، نحاول إنشاء سباق 4 أسابيع. القلة الأولى معقدة لأن هناك دائمًا شيء جديد. بعد الأولين (أو الثلاثة) يبدو أننا وضعنا وتيرة ثابتة.

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

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

بعد أول سباقين ،

1. هناك وظائف جديدة ومختلفة ،

2. لقد تغيرت جميع الأولويات ،

3. تم تنقيح تفاصيل كل حالة استخدام بشكل كبير.

ماذا تعني "الدقة" عندما تحاول تقدير التغييرات في نهاية كل سباق؟

---

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

يلاحظ العملاء ذلك ، وقال أحدهم إننا "نقضي الكثير من الوقت في تقديم ما يقوله العقد ، لكن هذا ليس ما نحتاجه".

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

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

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

Answer 3

لتقديم تقدير موثوق ، ستحتاج حقًا إلى إنشاء قائمة من المهام التي يتعين القيام بها. قم بتقسيمها إلى القصص/المهام (حتى لو لم تستخدم Agile) وتقييمها. قد يستغرق هذا الكثير من الوقت بالفعل - خاصةً كمية البحث (للبحث عن المكتبات للقيام بذلك لأشياء إعلامية لتقليل التكلفة). سأأخذ ما لا يقل عن 3 أيام - ومع ذلك ، يبدو لي أكثر من 1-2 أسابيع أكثر منطقية بالنسبة لي. لا يبدو أن هذا مشروع صغير.

لن أجرؤ على تسريع عملية التقدير إذا لم يكن لديك نتائج معقولة إلى حد ما. التقديرات ليست دقيقة أبدًا وستزيد الأمور سوءًا.

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

Answer 4

حسنًا ، الاقتباس الشائع هو "السعر سيكون بين 50 ٪ و 400 ٪ من تقديراتنا الأولية". السبب في أن هذا الاقتباس قد نما بشكل كبير هو أنه صحيح. تعتمد دقة التقدير إلى حد كبير على معرفة المجال. إذا كانت هذه هي المرة المائة التي قمت ببيعها نوعًا معينًا من محرك المدونة أكثر مما كنت متأكدًا تمامًا من التقديرات. ومع ذلك ، في أكثر الأحيان ، ليس لديك المعرفة المهنية بالمجال (إذا كان التطبيق موجودًا بالفعل ، فلماذا إنشاء واحد جديد؟).

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

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

النظر في مشروع التكرارات 5:

• ابدأ بوضع معالم. هذه تخضع للتغيير ، ولكنها ستوفر تقديرات Vargue الخاصة بك للمنتج النهائي.
• خطة التكرار #1.
• تقدير التكرار رقم 1 ، اضبط إجمالي التقديرات وفقًا لذلك.
• افعل التكرار رقم 1
• شطف / كرر حتى التكرار رقم 5
• انت انتهيت :)
• فكر في مشروعك. كيف تطورت تقديراتك؟ أسباب؟ التعلم بالممارسة :)

يفضل معظم العملاء الحصول على تقديرية جزئية وجزئية من الأهداف غير الواقعية التي باعتها بعض الدعوى :)

Answer 5

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

قدرنا 5 أيام لإنتاج هذه الصفحات ، استغرق الأمر بالفعل 10 أيام ، وما إلى ذلك.

في المعلومات طويلة الأجل مثل هذه (نأمل!) تمكنك من تقديم تقديرات أكثر دقة.