💌 🎅🏾 💙 JIRA: قواعد إعداد البرامج اللذيذة في الوقت المناسب. TLDR 2: إدارة المتطلبات 🤩 👩🏻‍🚒 👙

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

مصدر

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

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

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

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

قواعد لتقطيع المتطلبات

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

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

في الحالة الثانية ، ينقسم عمل إدارة المتطلبات إلى عدة مراحل.

ابدأ المصدر . تسجيل المستند المصدر لتطوير / تعديل البرمجيات في JIRA. يتم تحميل المواد المستلمة إلى المستودع مع رقم المهمة المقابلة المشار إليها في تعليق الالتزام.

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

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

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

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

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

3. بالنظر إلى خارطة الطريق التي تم تطويرها لكل من المتطلبات في المرحلة الأولى من تنفيذها ، ينبغي أن يحل المحلل المسؤول القضايا التالية:

توضيح المحتوى الدلالي للمتطلب ؛
توضيح حدود التنفيذ.

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

4. في إطار تنفيذ مجال وظيفي واحد ( حالة استخدام رئيسية واحدة - حالة استخدام) يجب على المحلل المسؤول صياغة مهام "التحليل" المتعلقة بالمتطلبات ذات الصلة.

5. إذا لزم الأمر ، يقوم المحلل المسؤول بإجراء مسح معلومات لكائن التشغيل الآلي.

6. بعد جمع البيانات الأولية اللازمة للتصميم ، يشكل المحلل المسؤول قرار التصميم.

7. بناء على نتائج قرار التصميم ، يجب على المحلل تشكيل / توضيح قائمة المكونات التي تخضع للتطوير / التعديل.

8. يعتبر حل التصميم المطور شرطًا ضروريًا وكافًا لإنشاء مهام التطوير والاختبار والتوثيق والتنبؤ بتعقيد تنفيذها.

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

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

في حالتنا ، تقرر أنه إذا تجاوز تعقيد المهمة 8 ساعات ، يجب على مؤلف المهمة تقسيمها إلى مراحل منفصلة (وهذا لا يعني دائمًا المهام الفرعية). بالإضافة إلى ذلك ، تم تحديد القوائم الرسمية لنتائج معينة لكل من هذه المراحل. بالإضافة إلى ذلك ، تم إنشاء الآلات الحاسبة عبر الإنترنت لزيادة موضوعية التوقعات استنادًا إلى هذه القوائم باستخدام طريقة PERT .تحديد التعقيد الكلي للمهام من أنواع مختلفة (من المفترض تقديم وصف أكثر تفصيلاً للعمل باستخدام هذه الأدوات أثناء نشر المقالات التالية). ولكن في الوقت نفسه ، تم تحديد وجود حد أقصى للتعقيد المتوقع لمهمة JIRA واحدة يجب ألا يتجاوز 32 ساعة. في حالة عدم موافقة المقاول على التعقيد المتوقع لمهمته ، كحجة ، يجب عليه تقديم حسابه للتعقيد الذي يتم باستخدام نفس الأدوات. الحكم في حل هذه الخلافات بين المحلل المسؤول عن تنفيذ المتطلبات والمنفذين هو مدير المشروع (teamlead).

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

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

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

12. بالتوازي مع عملية التطوير ، يتم تكوين نسخة من وثائق المستخدم على أساس قرار التصميم.

13. بعد الانتهاء من مهام التطوير ، يجب على المبرمج توضيح قائمة المكونات التي تم تطويرها / تعديلها.

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

15. تم تضمين المراجعة في إصدار البرنامج وفقًا لقرار التسليم الذي اتخذه مدير المشروع.

16. قبل إجراء الاختبارات ، يتم إجراء اختبار تكامل متكرر للمتطلبات التي تم تنفيذها في الإصدار.

17. يمكن التأكد من صحة المتطلبات التي تم تنفيذها أثناء اختبار البرمجيات (الأولي ، التشغيل التجريبي ، القبول). يتم تسجيل نتائج الاختبار في JIRA كجزء من مهام نوع "التنفيذ".
بعد استلام مستند من العميل بشأن التنفيذ الصحيح للمتطلبات ، يمكن نقله إلى الحالة "المغلقة" . في حالة تلقي التعليقات من العميل فيما يتعلق بالمتطلبات ، يتم إعادتها إلى الحالة "المعينة"(المرحلة رقم 8). في الوقت نفسه ، يمكن إصلاح التعليقات نفسها في JIRA كمتطلبات منفصلة تتعلق بالمتطلب الرئيسي باستخدام نوع الاتصال "Relates" .

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

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

متطلبات جديدة ؛
توضيحات بشأن التنفيذ ؛
عيوب؛
الأخطاء.

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

قواعد تلوين الصراصير

الشخص الذي لا يفعل أي شيء لا يخطئ.
ثيودور روزفلت

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

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

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

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

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

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

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

1. توضيح ظروف الحادث. كجزء من هذا الإجراء ، من الضروري جمع المعلومات الأكثر اكتمالاً حول تعليق البرنامج:

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

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

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

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

4. السيطرة على التكرارات. في حالة إعادة الانضمام إلى التطبيق لإزالة العيوب المكتشفة مسبقًا ، يرتبط هذا الشرط بالمهمة التي تم تقديمها سابقًا عبر الاتصال "تكرار" ( تكرار ).

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

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

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

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

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

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

10. يمثل ظهور المهام ذات الصلة بتطوير المتطلبات واختبارها وتوثيقها إشارة لمدير المشروع لاتخاذ قرار بشأن إصدار البرنامج الذي سيتم إصلاح العيب الذي تم تحديده. في الوقت نفسه ، يخطط مدير المشروع لحدث لتنفيذ البرنامج من خلال ربط المتطلبات المقابلة بمهمة JIRA من نوع "التنفيذ".

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

12. يتم تصحيح الخلل في إطار مهام نوع "التنمية".

13. بعد إزالة العيب ، يجب على المطور ، إذا لزم الأمر ، توضيح نوع العيب المكتشف وتكوين المكونات التي تم تعديلها.

14. إذا لزم الأمر ، يتم تحديد الوثائق.

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

16. بعد إجراء الاختبار دون اتصال بالإنترنت ، يتم تضمين الإصلاح في التحديث وفي الإصدار الحالي.

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

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

المصدر

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

قواعد تجميد المتطلبات

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

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

مصدر

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

في هذه الحالة ، يمكن إجراء توضيح باستخدام رسالة من المحتويات التالية:

. 4.5.6. : « 1, 2 3 «». , , ».

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

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

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

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

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

«»


*	( ).
	: ( , , .. ); ; — ( , , ); ; ( , ); /; (, , , , , ).
	, (, ).
()	. , , ( ).
	– . . . . , . - .
	, : ; ; ; ; ; .
	( - ). , . «» .

	, ( )
	/ ( PSP IBM): ( , ); ; ( , ); ( , , ); ( , -, ); ( , ); ( ); ( , , , , ); ( , ); , .
— , .
	: ; ; ; ; ; ; ; ; ; ; ; — , ; (e-mail).


	/ ( JIRA , [ ].[ ].[() ])

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

* ميزات ملء السمة المشتركة لجميع أنواع المهام.

يوضح الجدول التالي تغيير السمات المحددة لمهمة من النوع "متطلب" عند الانتقال من حالة إلى أخرى ، حيث:

- يمكن تغيير السمة ؛

- إدخال البيانات المطلوبة.

يتبع

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

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

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

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

JIRA: قواعد إعداد البرامج اللذيذة في الوقت المناسب. TLDR 2: إدارة المتطلبات

قواعد لتقطيع المتطلبات

قواعد تلوين الصراصير

قواعد تجميد المتطلبات

يتبع

More articles: