Scrum

scrum هو إطار عمل للمشاريع قيد التشغيل استناداً إلى مبادئ و قيم agile. تعرف مجموعة من الأنشطة التي يمكن مساعة فريقك فى تسليم قيمة أكثر إلى عملائك بشكل أسرع. تمد هذه الأنشطة عملاءك بفرصة مراجعة و إرشاد و التأثير على عمل الفريق الخاص بك أثناء تقدمه. لم يحاول هذا الأسلوب تعريف كل شيء في بداية المشروع. بدلاً من ذلك، يعمل فريقك بتكرارات موجزة (تسمى أيضاً سباقات) و يعالج الخطة أثناء تقدم الفريق. للحصول على معلومات عن مبادئ و قيم agile التى يعتمد عليها Scrum, راجع مبادئ و قيم التطوير السريع، بقلم Jeff Sutherland.

MSF للتطوير السريع البرامج v5.0 يستند على Scrum. لذلك، يستطيع فريقك تطبيق Scrum باستخدام أدوات تتكامل مع أنشطة التطوير الأساسية.

في هذا الموضوع التحضير للمشروع تخطيط المشروع قم بالتخطط لسباق تشغيل السباق تعقب المشروع

التحضير للمشروع

قبل البدء فى مشروعك، قم بتنفيذ المهام التالية:

• تأسيس حالة العمل

• تجميع فريق

• قم بإعداد البنية الأساسية لفريقك

لتأسيس حالة عمل، قم بتحديد حاجة و مبرر العمل و قم بتعريف الرؤية و احصل على تمويل. يوفر كتاب ل Geoffrey مور "متقاطع الفجوة" دليل جيد لتأسيس الرؤية الخاصة بك. للمزيد من المعلومات, راجع الموارد التالية على الويب: تعبر الفجوة.

بعد تأسيس حالة العمل، يجب عليك تجميع الفريق و التعرف على ScrumMaster و مالك المنتج. لمزيد من المعلومات، راجع الأدوار (مرجع MSF للتطوير السريع للبرامج v5.0 ).

وأخيراً، يجب يقوم فريقك بإعداد البنية الأساسية. على سبيل المثال، قم بتثبيت Visual Studio Team Foundation Server و Visual Studio Application Lifecycle Management‏ (ALM) و قم بإنشاء و ربما مشروع الفريق الخاص بك و إعداد الممارسات الهندسية. لمزيد من المعلومات، راجع الشروع في العمل بـ Visual Studio Application Lifecycle Management ، تخصيص مشروع الفريق الخاص بك ، و ممارسات هندسية.

تخطيط المشروع

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

إنشاء تراكمات المنتج

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

	إنشاء قصص مستخدم: في كتابه "قصص المستخدم المطبقة"، يحدد Mike Cohn قصص المستخدم بهذه الطريقة: “توصف قصة المستخدم الوظيفة التي ستكون قيّمة لكلاً من المستخدم أو المشتري النظام أو البرنامج. ” تتم كتابة قصص المستخدم من وجهة نظر المستخدم. فعلى سبيل المثال: “ كعميل سابق، أريد الوجبة التى طلبها من قبل. ” لمزيد من المعلومات، راجع قم بإنشاء تراكمات منتجات عالية.
	تحديد أولوية قصص المستخدم: يقوم مالك المشروع الخاص بك بتحديد أولويات قصص المستخدم في تراكمات المنتج عن طريق العمل مع العملاء لفهم القيمة و العمل مع فريقك لفهم المخاطر و التبعيات. يحدد مالك المشروع الخاص بك الأولويات عن طريق تعيين مرتبة لكل قصة مستخدم للإشارة إلى الترتيب الذي يجب أن يطبق الفريق به. يمكن لمالك المنتج الخاص بك استخدام العديد من التقنيات لتحليل و مقارنة قيمة قصص المستخدم. إذا كان فريقك يملك أسلوب يعمل بشكل جيد لتحديد الأولوية, استخدام هذه الطريقة. بعض تقنيات الأولويات مقترنة بشكل كبير مع مجتمع agile مثل طراز Kano لرضا العملاء و الوزن النسبى لـ Karl Wiegers. (للحصول على مزيد من المعلومات حول الوزن النسبي، راجع الصفحة التالية على الويب: الأشياء الأهم أولًا: متطلبات تحديد الأولويات.) تقنيات الأخرى لتحديد الأولويات "مثل أولويات التكلفة" و "القيمة الحالية الصافية" و "فترة الاسترداد" و "المعدل الداخلي للعائدا المؤسس خارج مجتمع agile. تجيز هذه التقنيات أيضاً و تناسب ترتيب أولوية تراكمات المنتج الخاص بك على مشروع Scrum. لمزيد من المعلومات، راجع "الجزع الثانى: يتم الآن تقدير الحجم"من الكتاب الذي يعرف مورد ويب التالية: القيام بتقدير لها agile و تخطيط.
	تقدير قصص المستخدم: يقدر فريقك بطريقة تعاونية كل قصة مستخدم في نقاط القصة. في كتابه "تقدير و تخطيط Agile"، يحدد Mike Cohn نقاط القصة بهذه الطريقة: “تعتبر نقاط القصة وحدة قياس للتعبير عن إجمالية حجم قصة المستخدم أو الميزة أو قطعة العمل الأخرى. ” تعتبر نقاط القصة قيم نسبية لا تقوم بترجمة مباشرةً إلى عدد معين من الساعات. بدلاً من ذلك، تساعد نقاط القصة الفريق فى حصر الحجم العام من قصة المستخدم. تكون هذه التقديرات النسبية أقل دقة بحيث تتطلب جهد أقل لتحديدها و تصمد بشكل أفضل عبر الوقت. بواسطة تقدير نقاط القصة، سوف يوفر فريقك الحجم العام لقصص المستخدم الآن و سيطور تقدير أكثر تفصيلاً عن ساعات العمل فيما بعد، عندما يكون أعضاء الفريق على وشك تنفيذ قصص المستخدم.

تحديد سرعة الفريق الخاص بك

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

إذا قام فريقك بقياس سرعته النسبية من خلال تجميع البيانات التي تعرض عدد قصص المستخدم التى يقوم فريق العمل بإكمالها في فترة محددة من الوقت, استخدم هذم البيانات. سوف يقدم أفضل نظرة ثاقبة عن سرعة الفريق. إذا لم تكن لديك البيانات الآن و لكنك بدأت فى تشغيل مشروعك باستخدام Visual Studio ALM و MSF للتطوير السريع للبرامج v5. 0، سيتم تجميع تلك البيانات عبر الدورة التدريبية من المشروع. لمزيد من المعلومات، راجع تقرير حالة التكرارات (Agile).

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

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

تأسيس خطة الإصدار

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

• قم بتعريف مجموعات من المستخدمين قصص، معا، بتوفير القيمة العمل كافية لتحرير إلى العملاء.

• تحديد في sprints التي يتوقع الفريق إلى إكمال هذه المجموعات من sإلىries مستخدم.

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

لمزيد من المعلومات، راجع مصنف تخطيط المنتج.

تحضير السباق الأول

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

• فصل قصص مستخدم في أسفل في قصص أصغر.

• توفير تفاصيل حول sفيries مستخدم الذي سيحتاج الفريق في تجزئة في sفيries في المهام.

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

سوف يطلب فريقك أيضا الحصول على تفاصيل حول قصص المستخدم ليكون قادر على كسرها إلى مهام و تقدير تلك المهام. على سبيل المثال، عندما يفحص الفريق sإلىry مستخدم في "cusإلىmer، أريد أن إلى من إلى بحث عن نوع meal،" قد تطلب الفريق أنواع الأسئلة التالية:

• "هل يجب أن يكون ذلك بحث نص محرر، أو هل يمكن أن يكون تحديد للحصول على أنواع القوائم المتوفرة ؟"

• "إذا وفر أكثر من مورد وجبة تطابق البحث، كيف ستفرز النتائج؟"

للحصول على معلومات أكثر, راجع الإعداد للسباق التالي .

قم بالتخطط لسباق

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

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

لمزيد من المعلومات، راجع سباق تخطيط الاجتماع.

اختر قصص المستخدم

يختار فريقك قصص المستخدم المرشحة للتطبيق في السباق. يعرّف فريقك قصص المستخدم التي لها أولوية الأعلى و التى لها نقاط قصة التي لا تتعدى السرعة النسبية المقدرة لها. على سبيل المثال، قصص المستخدم الأربعة التى لها الأولوية الأعلي قد يكون لديها 8 و 3 7 و 6 و 2 نقاط قصة. إذا كان فريق يملك سعة 25 نقطة قصة لكل سباق، سيقوم فريقك بتضمين قصص المستخدم الأربعة الأولى في تراكم السباق.

لمزيد من المعلومات، راجع مصنف تراكم التكرار.

تحديد المهام

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

قد تتمكن الفرق ذو الخبرة الغالية في Scrum من جعل هذا الالتزام بدون تقسيم قصص المستخدم إلى مهام.

تقدير المهام

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

الالتزام بقصص المستخدم

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

يلتزم فريقك بإكمال قصص المستخدم التي حددت على أنها يمكن أن تُستكمل. يجعل هذا الالتزام على أساس أن مالك المنتج الخاص بك لن يحاول إدخال عمل إضافي أو تغيير أولويات قصص المستخدم التي يتم تنفيذها في الآن فى السباق.

تشغيل السباق

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

إكمال قصص المستخدم

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

للحصول على مزيد من المعلومات حول تعيين المهام و تحديث الحالة الخاصة بهم، راجع المهمة (سريع).

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

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

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

لمزيد من المعلومات، راجع خطأ (agile).

تتبع تقدم السباق

يمكن فريقك تتبع تقدم السباق للتأكد من أنه يتم إكمال العمل بالشكل المتوقع و أنه يحقق معايير القبول. تستخدم فرق scrum بشكل متكرر تقرير الحرق لتتبع التقدم الخاصة بهم خلال السباق. يوفر MSF للتطوير السريع للبرامج v5.0 مجموعة من التقارير لتى يمكن للفرق استخدامها لتعقب تقدم السباق.

حرق و تقرير معدل النسخ (سريع)

إنشاء تقرير مؤشرات جودة

تقرير تقدم خطة الاختبار

قصص تقرير التقدم (Agile)

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

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

• قم بتقليل خصائص القبول للحصول على تفاصيل مستخدم لكي تصبح مهمة غير ضرورية.

• قم بإزالة القصة مستخدم من تراكم sprint.

• قم بإلغاء sprint.

إنهاء السباق

كما اقتراب نهاية السباق، تأكد من أن فريقك استكمل جميع قصص أو متطلبات المستخدم. على سبيل المثال، تأكد من نجاح اختبارات القبول و أن كل قصة مستخدم تحقق المعايير التى عرفها فريقك. لمزيد من المعلومات حول ما يعني إلى أن هذه العملية، راجع صفحة ويب التالية: Lacey Mitch & شركاء, Inc.

تقرير حالة الخطأ

تقرير اتجاهات الأخطاء

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

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

تعقب المشروع

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

التحضير للسباق التالى

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

مالك منتج الخاص بك بتحضير تراكم منتج ل sprint التالي بواسطة القيام بالمهام التالية:

• تحديث قصص مستخدم والأولويات الخاصة بهم كـ العملاء يجب تغيير.

• تجزئة sإلىries مستخدم التي من المحتمل إلى تطبيقه في sprint القادمة.

عند انتهاء فريقك من سباق، تقترب قصص المستخدم الأخرى من الجزء العلوي من تراكمات المنتج. يجب على مالك المنتج الخاص بل تحليل و تقسيم تلك القصص الموجودة في الجزء العلوي بحيث يمكن لفريق تطبيقها في السباق القادم. (ل المزيد من المعلومات، راجع التحضير ل Sprint أول في هذا الموضوع.) Mike Cohn غالباً talks حول هذه العملية كـ iceberg تراكم منتج. كـ يعمل الفريق تشغيل التعيين من الوظائف، iceberg melts، أسطح العمل الجديدة، ويتقلص iceberg. في هذه العملية، تظهر تفاصيل إضافية، كافية و في الوقت المحدد.

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

تعقب تقدم الإصدار

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

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

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

يوفر Visual Studio ALM العديد من التقارير للمساعدة فريقك فى تعقب تقدمه عبر العديد من السباقات.

تقرير حالة التكرارات (Agile)

تقرير الروايات العام (Agile)

قصص تقرير التقدم (Agile)

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

إنهاء الإصدار

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

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

راجع أيضًا:

المبادئ

اختيار قالب العملية

تخطيط المشاريع وتعقبها

موارد أخرى

ممارسات هندسية

MSF للتطوير السريع للبرامج الإصدار 5.0