في وقت سابق من المقال "
JIRA كعلاج للأرق والانهيارات العصبية " ، تم اقتراح خيار لاستخدام JIRA لإدارة مشروع تطوير البرمجيات لصالح عميل كبير من الدولة. ومع ذلك ، لا يمكن للمعالجة المتهورة لمعدات التشغيل الآلي للتحكم في "المطبخ الرقمي" أن تفسد المنتج فحسب ، بل تؤدي أيضًا إلى إصابات عديدة. في سلسلة من المقالات "قواعد لإعداد البرامج اللذيذة في الوقت المناسب" ، يُقترح دراسة قواعد تنظيم العمل في مشروع برمجيات بالتفصيل باستخدام محفز يسمى JIRA. أي نقد هو موضع ترحيب.
مصدرأسرار عامة
الذكاء هو القدرة على تجنب القيام بالعمل ، ولكن ذلك يتم.
لينوس توردفالدس
بعد نشر مقال "
JIRA كعلاج للأرق والانهيارات العصبية " ، أصبح العديد من المديرين التنفيذيين مهتمين بتجربتنا في استخدام JIRA وقرروا تقديم خطة مماثلة لأتمتة الإدارة في مشاريعهم. لذلك ، كنتيجة لكتابة هذا المقال ، كان من المفترض أن "تصاب ببعض الأرانب" في وقت واحد:
- النظر بالتسلسل في كل نوع من مهام JIRA كعملية فرعية للمشروع ، أثناء العرض التقديمي:
- توحيد مواصفات هذه العمليات الفرعية ؛
- توحيد قواعد العمل للعمل المنظم ؛
- تجميع خرائط "المزالق" النموذجية والأماكن التي تتطلب "فراش من القش" مقدمًا ؛
- تحديد مؤشرات أداء قابلة للقياس وقابلة للتحقيق لكل نوع من المهام.
- صياغة بيان بالمشكلة لمدير JIRA من أجل نشر مشاريع جديدة وفقًا للنهج المقترح ؛
- الحصول على لوائح غير رسمية ، ومع ذلك ، مفهومة وشفافة بشأن توزيع مسؤوليات جميع موظفي فرق المشروع ؛
- إضفاء الطابع الرسمي على أفضل الوصفات التي تم العثور عليها أثناء حل حالات المشكلات ("اختراقات الحياة" لمدير المشروع) ؛
- تحديد مواطن الضعف التي لم يلاحظها أحد من قبل في النهج المقترح أثناء مناقشة تفاصيل تنفيذه مع قراء هبر.
أود الإشارة إلى ذلك على الفور: لقد أثبتت بعض التقنيات الموضحة في أحد
مطابخ LANIT
الرقمية لإدارة المشاريع لتطوير وصيانة البرامج المخصصة بما يخدم مصلحة الدولة الكبيرة. ومع ذلك ، ليست هذه التوصيات مفيدة على الإطلاق في مشروعك. من ناحية أخرى ، نحن ندخل تيرا التخفي. بعض الاعتبارات التي تم التعبير عنها مخططة للتنفيذ فقط. لذلك ، إذا رأيت نقاط ضعف في النهج المقترح أو كانت هناك اقتراحات بناءة للتحسين ، مرحباً بك في المناقشة في التعليقات.
من المفترض أنه بعد تنفيذ التوحيد في مصلحة مختلف القادة ، سيتم تطبيق تقنية الإدارة الموصوفة بنجاح على مشاريع البرامج ذات التوجهات المختلفة والمقاييس المختلفة. بدوره ، فإن استخدام مساحة مفاهيمية واحدة عند تسجيل مهام JIRA يخلق المتطلبات الأساسية
للتقييم الآلي
للحالة الراهنة في إطار
محفظة المشروع . بالإضافة إلى ذلك ، من المفترض أن اتباع نهج موحد لتسجيل نتائج العمل في JIRA سوف يبسط تنقل الموظفين بين العديد من مجموعات المشاريع ، الأمر الذي سيسهم بدوره في زيادة نجاح المشروعات.
حدود المشروع
أي مهمة صعبة لها حل بسيط وسهل الفهم وغير صحيح.
آرثر بلوخ
منذ أن بدأت
خوارزمية تطبيق JIRA
المقترحة في "الانتشار" إلى مشاريع أخرى ، كان من الضروري إعادة التفكير في السؤال: "ما الذي يحدد بالضبط حدود مشروع البرنامج في JIRA؟"
وفقًا لأتباع PMBoK غير
المدونين ، فإن الإجابة على هذا السؤال هي أولية: "بالطبع ، يتم تحديد حدود المشروع من
خلال ميثاق (جواز سفر) المشروع ". من وجهة النظر هذه ، لكل عقد مع العميل ، يجب تشكيل مشروع منفصل في JIRA. علاوة على ذلك ، في كثير من الأحيان ، قد يتضمن تطوير حزمة برامج واحدة العديد من مجالات النشاط ، وكقاعدة عامة ، يتم إبرام عدة عقود:
- التطوير - المتطلبات بموجب عقود إنشاء أنظمة جديدة (النظم الفرعية) ؛
- التطوير - المتطلبات في إطار العقود التي تهدف إلى مراجعة كبيرة للأنظمة الفرعية الحالية ؛
- الدعم الموسع - متطلبات العقود الخاصة بالإكمال التشغيلي لوحدات النظام الفردية للتغيرات الحالية في العمليات التجارية للعميل ؛
- دعم الضمان - القضاء على أخطاء البرامج المحددة خلال فترة الضمان ؛
- الدعم الأساسي - القضاء على أخطاء البرامج المحددة بعد نهاية فترة الضمان.
بالإضافة إلى ذلك ، كجزء من إنشاء البرنامج ، يجب على فريق المشروع حل المتطلبات التي لم يتم تحديدها بواسطة أي من العقود. هذه هي متطلبات مدير المشروع المتعلقة بأنشطة ما قبل المشروع ، وإعادة البناء ، والبيع المسبق ، والقضاء على الأخطاء التي تم تحديدها بشكل مستقل ، وتدريب الموظفين ، إلخ.
ومع ذلك ، كما أوضحت الممارسة ، في التطوير الفعلي لمنتج برنامج طويل الأجل ، من الصعب الفصل بين أعمال التطوير والصيانة. لم تنته العملية التجريبية بعد (لم يتم إغلاق عقد التطوير) ، والعميل في وضع كامل بالفعل لصياغة متطلبات الدعم الممتد لمكونات النظام التي لم يتم وضعها بعد في التشغيل التجاري. يمكن فهم العميل ، لأن العالم يتغير بشكل أسرع من المخطط له في العقود المعتمدة. في الوقت نفسه ، يستمر التعرف على عيوب البرامج الجديدة. والمستخدم الذي اكتشف العيب لا يهتم على الإطلاق بأي عقد يجب تصحيح هذا الخطأ. من وجهة نظره - ببساطة لا ينبغي أن يكون. من أجل إسناد الخطأ المحدد إلى عقد أو آخر ، يستغرق تحليله وقتًا ، وإذا كانت مشروعات JIRA مقسمة على أساس العقود ،
فثمة معضلة : "وفي أي مشروع JIRA يجب تسجيل هذا العيب؟". بالإضافة إلى ذلك ، من الضروري تنظيم نقل المهام من مشروع إلى آخر ، إذا حدث خطأ في التصنيف. إذا قمت بتعيين جميع عيوب البرامج المكتشفة إلى مشروع منفصل لمجموعة الدعم ، فإن مخاطر المشاكل تنشأ عند حل مشكلات الدفع مقابل العمل في مرحلة عقد التطوير أو مراجعة
الشكاوى المتعلقة بعدم الامتثال لاتفاقية مستوى الخدمة (
SLA ).
من ناحية أخرى ، يقترح رؤساء الإدارات الغيرة أنه في إطار المشروع ، سيتم إنشاء مشاريع منفصلة لفريق الدعم ، والقسم التحليلي ، وقسم التطوير والاختبار. الكل يريد أن يكون سيدًا كاملًا في أبرشيته وأن لا يكون مسؤولًا عن "المياه الضحلة" من الجيران. علاوة على ذلك ، تتيح لك مرونة JIRA المذهلة إنشاء روابط بين مهام المشروعات المختلفة.
مصدرفي رأيي ، فإن الطرق المذكورة أعلاه لتسجيل المشاريع في JIRA تشبه محاولة طهي حساء واحد في العديد من الأواني المختلفة الموجودة في مطابخ مختلفة. الهدف الرئيسي للمشروع هو إنشاء منتج برمجي بجودة معينة في الوقت المناسب. من وجهة نظر العميل ، يتم تحديد جودة المنتج من خلال مجموعة من الإمكانيات الوظيفية لهذا المنتج ، والتي يمكن للعميل استخدامها (أي موثوق) لحل مشكلاته. ولا يهم العميل الوظيفي النهائي الذي بموجبه تم إنشاء الوظائف المطلوبة بموجب العلاقات التعاقدية. كما أنه ليس من المهم للطيار معرفة قائمة المقاولين من الباطن المشاركين في إنشاء طائرته.
مع وضع ذلك في الاعتبار ، يجب أن يضمن تحديد حدود مشروع JIRA الانسجام بين الاعتبارين التاليين.
- من الضروري أن يعكس المشروع جميع الأعمال التي يتم تنفيذها أثناء إنشاء / تعديل منتج البرنامج (أو النظام الفرعي الخاص به). يجب اعتبار المشروع عملية واحدة لإنشاء منتج برمجي واحد ("طائرة" واحدة). لذلك ، المبدأ الرئيسي: منتج برنامج واحد - مشروع JIRA واحد. من المهم ألا تنسى ما تنتجه شركتك - "طائرة" أو "محرك للطائرات". في أي حال ، لا ينبغي أن ينفر منشئو البرامج من عواقب قراراتهم.
بغض النظر عن نوع العلاقة التعاقدية مع العميل ، فإن نقطة الدخول إلى عملية إنشاء منتج البرنامج هي أي شرط لتعديله. الحدث الأخير هو استلام تأكيد العميل بأن هذا المتطلب قد تم تنفيذه (أو أعلن معسراً). هذه القاعدة هي القاعدة الرئيسية لتقييم اكتمال التخطيط واكتمال المهام في مشروع JIRA.
من المستحسن أن يجد مشروع JIRA أيضًا مكانًا للعمل الإضافي الذي بدأ من أجل تلبية متطلبات العميل. أثناء تطوير البرنامج ، تحدث العديد من الأحداث التي ، كقاعدة عامة ، تظل "وراء الكواليس": اجتماعات منتظمة لتوضيح المواعيد النهائية ، ونشر خوادم الاختبار ، وإعداد بيانات الاختبار ، وإنشاء تعليمات إضافية ، إلخ. يمكن أن تساعد JIRA في اكتشاف الثقوب التي يتدفق خلالها موظفو فريق المشروع بسخاء وبلا رجعة. لكن بشرط أن يتم تسجيل هذه الأعمال في مشروع JIRA. - في حالة تطوير أنظمة برمجية كبيرة حقًا ، يجب ألا تدفع كل شيء إلى مشروع JIRA واحد ، مما يزيد بشكل كبير من خطر التعطل. في مثل هذه الحالات ، في إطار مشروع JIRA منفصل ، يُنصح بالتجميع حسب وظائف البرنامج التي توفر الدعم لأحد العمليات التجارية للعميل (كقاعدة عامة ، يتم تخصيص هذه الوظائف لأنظمة فرعية منفصلة بالفعل في مرحلة التصميم المفاهيمي).
يجدر التفكير في تشكيل مشاريع فردية JIRA لتسجيل نتائج العمل التي يتم تنفيذها بانتظام في إطار العديد من منتجات البرمجيات (على سبيل المثال ، حساب الوقت الذي يقضيه الموظفون في دراسة التكنولوجيات الجديدة أو الأعمال المتعلقة بالنسخ الاحتياطية).
قد يكون الحد الأقصى لعدد موظفي فريق المشروع أحد القيود المفروضة على مشروع JIRA. تشير التجربة الشخصية إلى الاستنتاج التالي: الحد الأقصى لتكوين فريق التطوير في مشروع JIRA واحد يتبع
قاعدة ميلر (في أفضل تقاليد Agile). تشير مجموعة التطوير هنا إلى المبرمجين والمحللين الذين يقومون بصياغة المهام لهم. وبطبيعة الحال ، مدير المشروع. (كما قد تعتقد! هذا مقدس!) علاوة على ذلك ، إذا سمحت ميزانية المشروع ، فيمكن إدراج الـ
80٪ الباقية
من موظفي فريق المشروع ، الذين يتألفون من فتيات فريق دعم ودود ، واختبارين فظيعات ، وكاتبات تقنيات مملات ومسؤول عن نظام مرح ، بأمان وبانسجام في المشروع جيرة.
كيفية وضع المهام على الرفوف
في علمي هناك فقط الأدوات التي أحتاج إليها. هناك الكثير منهم ، لكنهم في حالة ممتازة ودائما في متناول اليد.
شرلوك هولمز
في أي مشروع ، يعد تنقل الموظفين في مجموعة المهام التي يتعين حلها أحد مكونات النجاح المهمة. ومع ذلك ، مع نمو حجم المشروع ، يصبح فهم هذا التدفق أكثر فأكثر ، والذي قد يصبح في حد ذاته أحد مشكلات إدارة مشروع كبير. لذلك ، يعد تعريف نظام إحداثي واحد يمكن لجميع المشاركين الرئيسيين التنقل فيه بسهولة جزءًا لا يتجزأ من أتمتة إدارة المشروع.
كان أساس هذا النظام الإحداثي في مشروعنا الاعتبارات التالية: يمكن تخيل منتج البرنامج ، كقاعدة عامة ، كصندوق أسود يتصل بالعالم الخارجي من خلال ثلاث طرق رئيسية:
- من خلال واجهة المستخدم ؛
- من خلال الوثائق التي شكلت للطباعة على الورق ؛
- عبر بروتوكولات تبادل البيانات الإلكترونية ( API / EDI ).
في هذه الأبعاد الثلاثة ، يرى المستخدمون النهائيون البرامج. من ناحية أخرى ، يهدف إنشاء البرامج على وجه التحديد إلى تكوين تدفقات البيانات هذه ومعالجتها.
مصدربالإضافة إلى ذلك ، تم اعتماد كائنات قاعدة البيانات الرئيسية والعمليات التجارية الآلية كإحداثيات إضافية داخل المشروع. للتنقل داخل مساحة الإحداثيات هذه ، تم تشكيل مصنفات مناسبة ، تم تقديم الدعم من مدير المشروع والمحللين. يتكون كل عنصر من عناصر المصنف من كود وتعريفه.
في سياق مشاريعي ، بالنسبة لكل مصنف ، تم الكشف عن ميزاته تدريجياً ، والتي يجب أن تؤخذ في الاعتبار إذا قررت تطبيق نهج مماثل.
- في حالتنا ، لم تكرر رموز النماذج المطبوعة ترقيم النماذج وفقًا لوثائق العميل. بالإضافة إلى ذلك ، كان النماذج الفردية عدة خيارات الطباعة. لذلك ، على سبيل المثال ، طوال وجود البرنامج ، تغير شكل أحد التقارير عدة مرات على أساس التغييرات في المستندات التنظيمية (لم يتغير اسم التقرير وجوهره). في الوقت نفسه ، بالنسبة للبيانات القديمة ، كان مطلوبًا الاستمرار في طباعة هذا التقرير في النماذج القديمة. تنطبق نفس الاعتبارات على التصنيف بموجب مشاريع البروتوكولات لتبادل البيانات الإلكتروني.
- في التسلسل الهرمي للنماذج ، يمكن أن تشتمل العناصر الفردية على لوحات تنقل (قوائم) ، ونماذج القوائم ، وبطاقات الكائنات ، وعلامات التبويب ، ولوحات المرشحات ، ونماذج تحميل / تفريغ البيانات ، وكذلك أشكال عمليات المجموعة المعقدة.
- من المرغوب فيه أن "تنمو" "أشجار" العمليات التكنولوجية بطريقة تجعل أوراقها عمليات تكنولوجية ذرية (غير قابلة للتجزئة) ، وعلى أساسها ، من الممكن ، بدوره ، ضمان تشغيل النظام الفرعي لتوزيع الوصول (النظام الفرعي الأمني).
- نظرًا لأنه يتم عرض جميع عناصر التصنيف مع هذا النهج على شاشات JIRA داخل حقل واحد ، فمن الضروري تقديم تدوين بدائي على الأقل بالإضافة إلى أسماء المكونات لتمييز نموذج "تسجيل الموظف" عن عملية "تسجيل الموظف".
بالنسبة لأولئك الذين لا يبحثون عن طرق سهلة ، يمكن تمييز مهام JIRA على أساس تسجيل الرموز المقابلة في حقل "المكونات". عند تسجيل المهام من أي نوع في JIRA ، في حقل "المكونات" ، تحتاج فقط إلى الإشارة إلى قائمة رموز الكائنات التي يهدف العمل المخطط لها إلى التغيير / التشكيل. استنادًا إلى نتائج حل كل مشكلة ، يجب على المسؤول المسؤول توضيح مكونات المكونات (إذا لزم الأمر). ثم يتم الحفاظ على المصنفات المكونة نفسها خارج JIRA.
لمحبي الراحة في هذا الصدد ، ربما يمكن
للمكونات الفرعية لبرنامج JIRA المساعد أن تساعد
كثيرًا .
تجدر الإشارة إلى أن استخدام المصنفات المترجمة بشكل صحيح لمكونات البرامج يوحِّد ضمنيًا الوعي الجماعي ولغة الاتصال لفريق المشروع ، مما يؤدي إلى زيادة في المستوى العام للتفاهم المتبادل. من ناحية أخرى ، فإن هذا النهج هو أحد أساليب الإكراه غير العنيف للمحللين على القيام بمهام أكثر تفصيلاً ، مما يزيد بدوره من دقة تقدير توقيت تنفيذ المتطلبات على المشروع.
لا تقلل قواعد التصنيف المعتمدة للمهام من الوقت الذي تقضيه في البحث ، ولكنها توفر أيضًا القدرة على التشغيل الآلي:
- تقديرات لإجمالي مدخلات العمل المخطط لها (أو تكاليف العمالة الحقيقية) للأعمال التي تهدف إلى تنفيذ بعض عناصر البرمجيات ،
- تقييم التوزيع الفعلي للأولويات - في مرحلة ما من المشروع ، قد يفاجأ مديره عندما يجد أن الجزء الأكبر من العمل لا يتم فيما يتعلق بالعناصر ذات الأولوية ،
- تحليل جودة تطوير الوثائق ،
- تقييم جودة إدارة المشروع من حيث التخطيط. فمن ناحية ، ليس من المنطقي تخطيط المهام التي لا يتم تكوين المكونات فيها (يتم تعديلها) ، ومن ناحية أخرى ، يشير تخطيط المهام ، الذي يتم خلاله تغيير عشرات الكائنات ، إلى أن المشكلة لم تتم صياغتها بعناية.
عندما تكون المهام ملزمة ، لا تربط يديك
عند وصف المبادئ العامة لنموذجنا
، قيل حول استخدام نوع واحد فقط من الاتصال "السبب" -> "الإجراء" (وفي إطار المشروع الموصوف ، كان هذا الاتصال كافياً). ومع ذلك ، فإن الرغبة في استخدام نفس آليات JIRA لأتمتة الإدارة في العديد من المشاريع المختلفة اللازمة لتوسيع عدد أنواع العلاقات المستخدمة وتوحيد النهج لتطبيقها.
يوفر مصدرJIRA "خارج الصندوق" للمستخدم عدة أنواع مختلفة من العلاقات بين المهام ، ويمكن أن يؤدي الاستخدام غير المنضبط لهذه العلاقات إلى عواقب وخيمة. حتى لا نخلط بيننا وبين الآخرين ، اتفقنا على القواعد الأساسية التالية لمهمة JIRA الملزمة.- إغلاق نفس النوع من الارتباط في الحلقة أمر غير مقبول (على الرغم من أن JIRA يسمح بذلك).
- «» (Depended) («» => «») , «» (waterfall): => => => => => . . , JIRA, , , .
- «» ( Blocks ) («» => «») (, ).
- «» ( Cloners ) («» => «») «». («») «».
- «» ( Relates ) («» => «») «». , , , . , , .
- «» ( Duplicate ) («» => «») «». , . .
Workflow
, , , , .
وفقًا للنهج المقترح ، فإن نفس الميزات متأصلة في جميع أنواع المهام المسجلة بواسطة JIRA. بادئ ذي بدء ، تتميز جميع أنواع مهام JIRA بنفس سير العمل. علاوة على ذلك ، في كل مهمة ، تم تحديد حالة العمل في المقام الأول من وجهة نظر المؤدي لهذه المهمة.أثناء توحيد المهام لعدة مشاريع ، تم تحديث سير العمل الموصوف مسبقًا . كان التغيير الرئيسي هو إدخال حالة "تقييم" إضافية تهدف إلى التغلب على المشكلات الموضحة في النقش على القسم. من ناحية ، تم بالفعل تسجيل المهام في هذه الحالة لدى JIRA ولن يتم توجيه انتباه مدير المشروع إليها. من ناحية أخرى ، فإن هذه المهام ليست مخيفة حتى الآن لتشتيت انتباه المسؤولين التنفيذيين.أيضًا ، تمت إعادة تسمية الحالة "خطة" إلى "تعيين" ، حيث تبين أن هذا الاسم كان أكثر تسامحًا فيما يتعلق بمهام النوع "متطلب" (بالنسبة إلى الحالة عند تشكيل حل للتصميم ، ولم يتم تخطيط مهام التنفيذ بعد).في سياق تحليل شامل للعديد من المشاريع ، تم تحديد سمات متأصلة في جميع أنواع المهام.* يتميز السمة التي سيتم مناقشتها خلال تشكيل مواصفات لكل من هذه الأنواع من المشاكلتعديل السمات العامة لكافة المهام في الانتقال من يوصف دولة إلى أخرى حسب الجدول التالي، حيث:
- ممكن لتغيير السمة.
- إدخال البيانات المطلوبة ؛
- يتم مسح قيمة الحقل.لم يتم توضيح التحولات "للعمل" و "التجنيب" في الجدول. لا تتوفر هذه التحولات إلا للمنفذ ؛ ولا يُفترض تغيير سمات المهام أثناء هذه التحولات. أيضا ، لم يتم وصف انتقال exhume. كما يوحي الاسم ، فإن استخدام هذا الانتقال غير مرغوب فيه للغاية. لا يتم استخدام هذا الانتقال من قبل مسؤول المشروع إلا إذا تم نقل المهمة عن عمد عن طريق الخطأ إلى الحالة "مغلقة" (في هذا الانتقال ، يُطلب فقط تسجيل سبب هذا الانتقال).أن تستمر
في الآونة الأخيرة ، أصبح مفهوم إدارة BPM ( إدارة العمليات التجارية ) ، والذي ينظر بشكل منهجي أنشطة الشركة من خلال منظور العمليات ، واسع الانتشار . أيديولوجية BPM هي أساس العديد من الأناجيل الحديثة للإدارة ، مثل:اليوم ، لا يوجد أي شواغر تقريبًا لمدير المشروع يمكنها الاستغناء عن اشتراط أن يكون لدى مقدم الطلب شهادة PMP أو ITIL . تصف العديد من الكتب المدرسية كيف ، باستخدام طرق وأساليب BPM في أي إنتاج تقريبًا ، من الممكن تحقيق مستويات جديدة من التنافسية والعلاقات مع العملاء والموردين والموظفين. في العديد من هذه الكتب ، حرصًا على تحقيق نتائج إيجابية على وجه السرعة ، يوصى بشدة باستخدام بعض تطبيقات BPMS . لكن لسبب ما ، نادراً ما صادفت الموادحول التطبيق المطبق لأساليب BPM وأساليب إنتاج البرامج (خاصةً في الحالات التي يكون فيها استخدام Agile الذي أثبتت كفاءته غير ممكن لسبب أو لآخر) وبشكل عام ، لم تكن هناك مواد عن الاستخدام الناجح لـ BPM من أجل " إنتاج " المورد الأكثر عيبًا بشدة (إذا كان أي شخص يعرف عن هذه المواد ، شارك في التعليقات). تعرف "الأناجيل" المذكورة أعلاه "القمم" (وهو أمر مهم). ومع ذلك ، كيف يمكن لفريق المشروع الوصول إلى هذه "القمم"؟لا تعني الإعلانات المتعلقة بتطبيق نهج العملية في الإدارة على الإطلاق استخدام مبادئ BPM في الممارسة. تقول تجربة مشاريع البرامج الخاصة بي ، كقاعدة عامة ، أن فريق المشروع مشغول للغاية بأتمتة BPM لصالح العميل بحيث لا يتوفر لديه الوقت لاستخدام هذه المبادئ من أجل تحسين أنشطته الخاصة.المصدر كانتحالة استخدام JIRA الأصلية الموضحة هنا تهدف في المقام الأول إلى تقليل الصداع الذي يصيب أعضاء فريق المشروع من إدارة مشروع برنامج. ومع ذلك ، فالتعديل التدريجي لمشروع JIRA في سياق حل المشكلات التطبيقية المحددة لإدارة المشروع ، أصبح من الواضح أن النموذج الذي تم إنشاؤه لبيانات المشروع يعكس بشكل كاف عمليات إنشاء البرامج من طرف إلى طرف. وهذا بدوره يخلق جميع الشروط المسبقة لزيادة كفاءة فرق المشروع من خلال استخدام آليات BPM. في الوقت نفسه ، يبدو أن قدرات JIRA تسمح تمامًا بالنضج المتسق لعملية تطوير البرمجيات دون استخدام BPMS المتخصصة. سيتم تقديم جميع الاقتراحات الإضافية لاستخدام JIRA لأتمتة إدارة مشاريع البرامج مع مراعاة هذا الاعتبار الرئيسي.إحدى الخطوات الأولى على سلم CMMI هي تحديد وتوثيق وتوحيد العمليات التنظيمية. لذلك ، كجزء من سلسلة المقالات "JIRA: قواعد إعداد البرامج اللذيذة في الوقت المناسب" ، من المفترض أن تصاغ باستمرار مواصفات لجميع أنواع المهام التي يتعين حلها ومحاولة صياغة جهاز معايير لتقييمها الشامل من وجهة نظر نهج العملية. سيتم تخصيص المقالة التالية لميزات تسجيل مهام نوع "المتطلبات" والعمليات التجارية لتنفيذها.