سؤال

نحن نقوم للتو بتحديد بطاقات القصة الخاصة بنا للمشروع التالي.

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

عملياتنا في تحديد القصص هي كما يلي

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

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

يستغرق هذا بعض الوقت ويمكن أن يكون مرهقًا للغاية

ما هي الطرق الأخرى التي يمكن استخدامها لتحديد بطاقات القصة؟ما هي الطرق الأخرى التي يمكنك من خلالها جمع المتطلبات في بطاقات القصة؟

يحرر:

  1. هذه ليست المرة الأولى التي نقوم فيها بذلك، إنها عملية عادية
  2. العميل هو عميل داخلي
  3. أنا مهتم بكيفية كتابة البطاقات التي ينتهي بك الأمر بالتشفير عليها
هل كانت مفيدة؟

المحلول

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

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

نصائح أخرى

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

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

أنت:متى تحتاج هذه الميزات؟

(عميل:متى يمكنك تسليمهم؟

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

ج:بالطبع.

أنت:إذا قمت بتسليم كل هذه الميزات غدًا، فهل سيكون ذلك قريبًا بما فيه الكفاية؟

ج:بالطبع.

أنت:ماذا عن سنة واحدة من الآن؟

ج:وهذا لا يزال بعد فوات الأوان.

أنت:3 اشهر؟

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

كنت أعتقد):اه ها!

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

ج:سنحتاج حقًا إلى الميزة X لشهر يناير.

أنت:حسنًا، إذا أضفنا الميزة X فسنحتاج إلى إزالة الميزة.والتي لا تحتاج إليها؟

ج:يمكننا أن نفعل مع جزء فقط من الميزة Y.

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

ج (فكر):ها!حصلت على ما أردت!

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

  1. يجبر العميل على المساعدة في إجراء المقايضات

  2. يكشف السبب الحقيقي للتقديرات

  3. يقلل من عدد الأشياء لتقديرها.

  4. يساعد في تحديد الميزات المهمة لأي سباق.

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

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

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

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

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

آمل أن يساعد هذا.

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

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

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

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

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

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

القصص! = المهام.يتم تقسيم القصص إلى مهام، ثم تقوم بعد ذلك بتقدير أقل من 3 أيام لها.يعد تقدير القصص أكثر انفتاحًا ويجب أن تكون قادرًا على تحديد حدود تقديرات القصص التي تناسبك أنت وفريقك بشكل أفضل بعد القيام بذلك لفترة من الوقت.(أي < أسبوع واحد، أسبوعين، > أسبوعين، وما إلى ذلك)

الجزء الأكثر أهمية في التقدير هو متابعة الوقت الفعلي المستغرق وإجراء التعديلات على عملية التقدير الخاصة بك.XP يدور حول التعليقات.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top