تقدير تكاليف البرمجيات في إدارة المشاريع الرشيقة

مقدمة

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

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

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

كتابة البرامج عالية الجودة هي الخبز والزبدة لكبار المهندسين ؛ يمكن أن يكون إنشاء منتجات برمجية رائعة مسعىً أصعب بكثير لجميع المعنيين.

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

إذن ، كيف يمكنك أن تبدأ بتقدير حجم ومدة وتكلفة المشروع؟ دعنا نستكشف تكاليف تطوير البرامج وتقدير مشروع Agile ، وكيف نقوم بذلك في Toptal.

تسعير وتقدير العقود التقليدية

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

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

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

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

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

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

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

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

أيهما أفضل ويزيد من ثقة أصحاب المصلحة أم التكلفة الثابتة أم التكلفة المتغيرة؟

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

لذلك تركز العقود الرشيقة على ما يلي:

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

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

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

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

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

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

نهجنا لتكاليف البرامج والتسعير

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

يتم اتخاذ الخطوات التالية في وضع مشروع تقديري وسعر ثابت:

1. نطاق المستوى العالي الأولي

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

لذلك ، نبدأ بميثاق المشروع ومجموعة عالية المستوى من الميزات "الملحمية" التي توجه اتجاه المشروع ، بناءً على رؤية وأهداف سليمة

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

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

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

2. الاقتراح

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

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

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

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

3. الافراج عن التخطيط

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

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

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

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

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

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

د. تخطيط الإصدار حتى الآن ، حددنا ما نعتقد أن المنتج سيكون وحجمه.

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

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

وأخيرًا ، تضمن هذه الخطة حصول فريق المشروع على ضوء إرشادي يقود الطريق ويحدد نقطة نهاية منطقية للتطوير.

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

لاتخاذ سيناريو أساسي ، نأخذ العدد الإجمالي لنقاط القصة التي حصلنا عليها من تحديد حجم الأعمال المتراكمة لدينا ونقسمها على السرعة المتوقعة لفرقنا. (يتم التعبير عن السرعة NB عادةً في صورة نطاق ، ولكن من أجل التبسيط ، سنستخدم رقمًا واحدًا هنا.) نعمل في تكرارات لمدة أسبوعين ، لذا ستنعكس سرعتنا بمقدار ما يمكننا إكماله في دورة مدتها أسبوعين مع المتاح قدرة الفريق. إذا كان مجموع نقاط قصتنا 120 ونتوقع إكمال 20 نقطة لكل تكرار ، فإن إجمالي مدة التطوير ستكون 12 أسبوعًا أو 6 تكرارات. نضيف إلى ذلك العدو السريع 0 لمدة 2 أسابيع وخطوة الإعداد للتحرير لمدة أسبوعين. في المجموع ، يبلغ طول مشروعنا 16 أسبوعًا. هناك تقنيات يمكننا استخدامها من شأنها أن تساعد في بناء مخزن مؤقت مناسب للمخاطر في تخطيطنا ، والذي سنناقشه لاحقًا. لكن باختصار ، نستخدم المخزن المؤقت لإدارة مخاطر عدم اليقين والتوصل إلى الحد الأدنى من الاتفاق بشأن نقاط القصة المتوقعة التي سيتم تسليمها. قد تكون النتيجة مجموعة من 90 إلى 150 نقطة قصة يتم تسليمها ، 90 هو الحد الأدنى المقبول لإنشاء منتج قابل للتطبيق.

بدلاً من ذلك ، إذا كان يجب إكمال المشروع في تاريخ معين ، في غضون 10 أسابيع على سبيل المثال ، فسيحدد الفريق مقدار العمل المتراكم الذي يمكن إكماله في ذلك الوقت. إذا توقعنا 20 نقطة قصة في كل سباق ، بالإضافة إلى Sprint 0 ونسخة الإصدار ، فسنستهدف 60 نقطة مكتملة بنهاية المشروع. مرة أخرى ، نتطلع إلى إدارة المخاطر من خلال إضافة مخزن مؤقت مناسب ، والذي قد ينتج عنه هدف من 45 إلى 75 نقطة قصة مكتملة وجاهزة للإفراج عنها. تتماشى نقاط القصة الـ 45 مع الحد الأدنى المقبول لتقديم منتج قابل للتطبيق وقيِّم. هذا هو أحد السيناريوهات التي قد تتوقع فيها إضافة عضو في الفريق لزيادة السرعة ، إذا كان ذلك مناسبًا.

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

4. عقد السعر الثابت

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

يتم تسليم عرض أسعار عقد السعر الثابت مع بيان العمل وجدول الدفع المتفق عليه.

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

تقنيات التقدير

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

تقدير الحجم

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

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

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

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

نقاط القصة

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

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

إذا كانت القصص التالية في تراكم منتجاتنا تحتوي على الأحجام المرتبطة:

الحجم الإجمالي للمشروع 12 نقطة قصة.

الأيام المثالية

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

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

عند التقدير على مستوى أكثر تفصيلاً ، قل قصة في تراكم منتج راسخ ، يمكن استخدام أي من النهجين وسيقرره الفريق الهندسي. هناك فوائد لكلا النهجين وسيكون لكل فريق ما يفضله.

تقنيات التقدير

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

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

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

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

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

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

السرعة الاتجاهية

السرعة هي مقياس لقدرة الفريق على إنجاز العمل في تكرار معين (أو العدو السريع).

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

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

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

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

• 4 أعضاء فريق * أسبوعان * 40 ساعة في الأسبوع = 320 ساعة
• مضروبًا في سعة 70 بالمائة لدينا = 224 ساعة
• أضف جميع المهام المميزة وتوقف عن العد عند 224
• خذ جميع الميزات المكتملة ، واجمع نقاط قصتهم وستحصل على سرعتك ، على سبيل المثال 36
• قم بتطبيق 20 بالمائة على كلا الجانبين للحصول على نطاق من الأدنى والأعلى ، للوصول إلى سرعة تقديرية من 29 إلى 43 نقطة قصة.

تختلف السرعة عادةً في أول مرتين إلى أربع تكرارات ثم تستقر في نطاق صغير من النقاط. لذلك ، حيث كان النطاق الأولي قبل العدو الأول من 29 إلى 43 ، من خلال العدو الرابع ، قد يستقر من 34 إلى 38. هذا يعطينا ثقة أكبر في التنبؤ بتاريخ الانتهاء النهائي.

خطط وقائية للمخاطر وعدم اليقين

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

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

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

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

ميزة المخازن المؤقتة

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

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

بعض الأفكار الختامية

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

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

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

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

ملخص

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

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