كيف يمكن إنشاء عملية فعالة لإدارة المشروع في الظروف التي لا يمكن فيها تنفيذ "الصواب" و "الأفضل" ، ولكن لا يزال يتعين القيام به؟ تقدم المقالة نظرة عامة على استخدام JIRA لإدارة مشروع تطوير البرمجيات لصالح عميل حكومي كبير. سأكون سعيدًا إذا كانت الأساليب الموصوفة ستساعدك على زيادة فعالية فريقك شخصيًا وتقليل التوتر في المشروع. أي نقد هو موضع ترحيب.
مصدرابن الأخطاء الصعبة
انطلاقًا من العدد الكبير من المقالات النموذجية على الإنترنت حول كيفية تطبيق أنظمة إدارة المشروع بشكل صحيح في تطوير البرمجيات ، يعد هذا عملًا بسيطًا وممتنًا. ومع ذلك ، فإن الاستخدام الفعلي لأنظمة التحكم الآلي في المشاريع التي أتيحت لي فيها فرصة للمشاركة لم يكن "وردياً" كما قد يتوقع المرء. هناك العديد من الحالات النموذجية التي تمت مواجهتها في الممارسة العملية.
ظهرت أفضل الخيارات لاستخدام فريق المشروع لأحد أنظمة تتبع الأخطاء المتعددة. عادة ما يتم تطوير هيكل المهام والعمليات التجارية للمشروع "خارج الصندوق". تم استخدام هذه الأنظمة بشكل أساسي بواسطة فرق من المبرمجين والمُختبرين. مثلت مؤسسة التطوير هذه ثمارها على المشروعات الصغيرة مع العملاء من القطاع الخاص ، أو إذا كانت مهام فناني الأداء تشمل فقط دعم الضمان لمنتج البرنامج (تصحيح الأخطاء المكتشفة). ومع ذلك ، مع نمو المتطلبات الجديدة ، بدأ هذا النهج في الانزلاق. وقد تجلى ذلك في زيادة الوقت الذي يقضيه في مقارنة متطلبات العملاء والمعلومات المخزنة في برنامج bugtracker (وتجميع التقارير المتكاملة يدويًا) ، وكذلك في تقسيم الفريق إلى معسكرين (مبرمجين "جيدين" ومحللين "سيئين").
المواقف الأخرى تتلخص في إلهام "رائع" للقيادة ، عند استخدام "منهجيات" أفضل منهجيات تطوير البرمجيات في أنشطة فرق المشروع ، باستخدام الأدوات الإدارية. صحيح أن هؤلاء القادة يعتقدون أن أفعالهم اقتصرت فقط على عملية العثور على هذه "الرصاصة الفضية". لم تهتم بمفاهيم مثل "
العدو " أو "
مخطط احتراق المهام " أو "
مخطط التدفق التراكمي ". وحتى إذا كانوا قد أزعجت ، فإن مستندات إعداد التقارير التي يجب تشكيلها على حالة المشروع (مرة أخرى يدويًا) كانت مرتبطة بشكل جيد بهذه المنهجية الأفضل. أدت محاولات تعريف العملاء بهذه الطرق إلى حقيقة أن ظروف المشروع لم تتغير ، وإلى التقارير القديمة كان مطلوبًا بالإضافة إلى ذلك إنشاء تقارير إضافية جديدة (وفقًا للطريقة الجديدة). وقد ظهرت هذه التناقضات بشكل خاص في مشاريع العقود الحكومية ، التي تتعارض ظروفها التنظيمية بشكل مباشر مع التطبيق الناجح لشركة
Agile أو
RUP أو
PMBOK .
كان التفسير الأوتوماتيكي للإدارة هو مشروع تحسين نظام المعلومات على المستوى الاتحادي لصالح أحد عملاء الدولة الكبار. كجزء من هذا المشروع ، استخدم العميل نفسه
HP Service Manager و
JIRA . تم استخدام HP Service Manager لجمع وتحليل أخطاء البرنامج. بمساعدة JIRA ، خطط العميل لأنشطة موظفيه المتعلقة بتصحيح هذه الأخطاء ومواصلة تطوير النظام. تنص قائمة المهام في هذه الأنظمة على مجموعة كاملة من الخيارات الممكنة لمعالجتها. تم نشر الإجراءات التفصيلية لدعم هذه المهام ، التي شكلها مكتب مشروع العميل (أي الأشخاص غير المسؤولين عن الصيانة والتطوير) ، على منصة
كونفلوينس . تم السماح لموظفي المقاول بالنظامين ، وكُلفوا بمسؤولية دعم الحوادث والمتطلبات (مع إرشادات مؤقتة لمعالجة المهام وجدول تدريجي للغرامات). بالإضافة إلى ذلك ، تم نشر نسخة من JIRA في موقع المقاول ، وبمساعدة أنشطة فريق المشروع. تم تنفيذ تزامن أنشطة الأنظمة الثلاثة يدويًا (لهذا كان علي الاحتفاظ بـ "ورقة" في Excel ، حيث تمت الإشارة إلى علاقة المهام وحالتها الحالية). بالإضافة إلى ذلك ، لم تتناسب التقارير التي أنشأتها JIRA مع الإدارة ، وبالتالي كان على فريق المشروع تقديم تقارير كل ساعة عن أنشطتهم ، والتي قاموا بإنشائها يدويًا في Excel أيضًا. لم يكن الوضع غير مألوف عندما قام رئيس فريق التطوير أو رئيس مجموعات الدعم "بالتعليق" في العمل حتى وقت متأخر من الليل ، مما أدى إلى إنشاء تقارير موجزة عن حالة المشروع بناءً على نتائج فريق المشروع. تم الانتهاء من هذا المشروع بنجاح في الوقت المحدد وتم تذكره ، باستثناء انخفاض الإنتاجية القياسي ، وزيادة عدد الأعطال العصبية ، والإرهاق المهني السريع ، واستناداً إلى مكافآت الموظفين "الباقين على قيد الحياة" ، فإن الهوامش منخفضة بشكل غير متوقع. بعد هذه المشاريع ، يطاردنا الفكر لفترة طويلة: "إذا ابتكرنا أدوات تسهل بشكل كبير حياة العملاء ، فلماذا ، بسبب هذه الأدوات ، هل نزيد حياتنا سوءًا؟"
ميزات التنمية الوطنية
بإيجاز للتجربة ، يمكننا أن نستنتج أن أعظم المشاكل المتعلقة بأتمتة إدارة تطوير البرمجيات حدثت في مشاريع لأوامر الدولة.
مصدرعلاوة على ذلك ، أدت المحاولات المتكررة لحل هذه المشكلات وفقًا لأفضل ممارسات تطوير البرمجيات إلى استنتاج: هذه ليست مشاكل ، ولكنها شروط لا مفر منها لتنفيذ المشروع لصالح العميل الحكومي. سمح لنا تحليل لعدة مشاريع بتحديد الخصائص المميزة المعممة التالية لهذه الشروط:
- غالبًا ما تتم صياغة المتطلبات الأولية للمواصفات الفنية بشكل غامض ، حيث يضع العميل معاني جديدة في هذه المتطلبات مع تطور المشروع (الذي يرتبط ، في جملة أمور ، بتغيير في الإطار التنظيمي الحالي الذي يحكم العمليات التجارية الآلية) ؛
- يتراوح نطاق المتطلبات المسجلة في الشروط المرجعية من "تصحيح الكتابة" إلى "تنفيذ نظام فرعي لرصد وتحليل جميع العمليات" ، في حين يجب تنفيذ جميع المتطلبات دون قيد أو شرط (كقاعدة عامة ، لا يتم قبول المقترحات لتحسين الصياغة ، يمكنك فقط التأثير على بعض قيود على طريقة التنفيذ) ؛
- في بعض الأحيان ، يقوم العميل ، الذي ليس لديه أي فكرة عن كيفية حل المشكلة ، بـ "دفع" هذه المشكلات إلى المقاول ، بما في ذلك المتطلبات ، بعبارة بسيطة ، "مقصور على فئة معينة" (شيء مثل "... يجب على النظام الفرعي توفير توقعات لسعر صرف العملات الرئيسية لـ قصيرة ومتوسطة وطويلة الأجل ... ") ؛
- في حالة ارتباط العقد بتنقيح النظام الحالي ، يطلب العميل إدخال مكونات فردية قبل التشغيل التجريبي مع ضمان التشغيل دون انقطاع للنظام بأكمله (يمكن مقارنته باستكمال محرك السيارة أثناء التنقل) ؛
- يمثل العميل عدة وحدات (مؤسسات) ، غالباً ما تكون متطلباتها متناقضة ؛
- تظل ميزانية المشروع ومواعيده النهائية على حالها ، على الرغم من التغيير وإضافة المتطلبات ؛
- لا يسعى العملاء إلى التعاون مع المطورين (يعتمد التعاون على مبدأ "أنت تفعل ذلك أولاً ، ثم سنرى") ؛ يتجنب ممثلو العملاء مسؤولية اتخاذ أي قرارات بشأن تحديد المتطلبات ، وتجاهل توقيت تنسيق القضايا الإشكالية ، ولا جدوى من الحاجة إلى التنسيق قبل بدء التطوير ، لأن حقيقة أن الفريق لا يفي بالمواعيد النهائية لا يهم العميل (أي هذه هي مشاكلنا كأداء).
- من ناحية ، يحتاج العميل إلى الامتثال التام لحزمة الوثائق بالكامل للمتطلبات الرسمية لـ GOST ، من ناحية أخرى ، تطوير تعليمات إضافية لاستخدام المنتج في حل مشكلات معينة.
وكقاعدة عامة ، تثير كل هذه العوامل سخط فريق المشروع فيما يتعلق بـ "العملاء غير المناسبين" و "سوء إدارة المشروع". ومع ذلك ، نظرًا لموضوعية وتكرار الشروط المذكورة أعلاه ، فإن شكاوى فريق المشروع حول "التعقيد" للعميل الحكومي تشبه شكاوى فريق السفينة بشأن البرد والظلام في الليلة القطبية بعد أن فازت شركة الشحن بعطاء رئيسي للنقل على طول
طريق بحر الشمال .
بالإضافة إلى الظروف الخارجية ، كما اتضح فيما بعد ، يتم مشاركة الميزات المميزة المشتركة بواسطة فرق من الموظفين المشاركين في مشروع البرنامج.
- يمكن أن يتكون جوهر فريق المشروع من 5 إلى 12 موظفًا: مدير المشروع ، والمحللين ، والمختبرين ، والكتاب التقنيين ، والمبرمجين. على الرغم من أن بعض الموظفين يمكنهم في بعض الأحيان أداء عدة أدوار ، كقاعدة عامة ، تتميز فرق المشروع هذه بأنها " عامل حافلة " منخفض. هذا في حد ذاته يفرض أيضًا قيودًا على استخدام أساليب Agile (على سبيل المثال ، من غير المرجح أن يكون استخدام جدولة البوكر في ظل هذه الظروف مفيدًا).
- يجب على فريق المشروع ، جنبًا إلى جنب مع عمليات تطوير البرمجيات ، توفير دعم الضمان في وقت واحد (تصحيح أخطاء البرنامج) والدعم الموسع (الإكمال التشغيلي لوحدات النظام الفردية للتغيرات الحالية في العمليات التجارية للعميل).
- كجزء من أداء المهام الفردية ، يشارك الموظفون من الإدارات المجاورة للشركة ، بالإضافة إلى المقاولين من الباطن (الشركات الخارجية التي يفرضها العميل) ، والتي عادة ما تكون مهام المشروع لها أولوية ثانوية.
انتصار الأمل
الزواج الثاني هو انتصار الأمل على تجربة الحياة.
صموئيل جونسون
قبل عامين ، دُعيت كمحلل رائد لمشروع
ينفذه LANIT بأمر حكومي. تم تشكيل فريق المشروع في وقت سابق ، وتألف المشروع في تحسين كبير للنظام الآلي الذي كان قائما لأكثر من عقد من الزمان. بشكل عام ، كانت ظروف المشروع كما هو موضح أعلاه. في ذلك الوقت ، لم يستخدم فريق التطوير أيًا من أنظمة إدارة المشروع الحالية في عملهم (على الرغم من أن جميع الموظفين شاركوا تقريبًا في المشاريع التي استخدمت فيها هذه الأنظمة وكان لديهم رأي متشكك حول الحاجة إلى أتمتة الإدارة). ومع ذلك ، فإن الوضع الأولي الحالي وفر فرصة لاختبار أتمتة إدارة المشروع "من الصفر".
تم اختيار JIRA كمنصة أتمتة. ساهمت مجموعة من العوامل التالية في هذا الاختيار:
- القدرة على تسجيل العلاقات بين العديد من المهام ؛
- مرونة الإعدادات للإصدار محاصر.
- حفظ تاريخ جميع التغييرات في المشروع ؛
- العمارة مفتوحة جزئيا ، وإمكانية صقل لاحتياجاتك الخاصة ؛
- القدرة على التفاعل مع الأنظمة الخارجية التي تم استخدامها بالفعل من قبل فريق المشروع (SharePoint ، Git ، SVN ، إلخ) ؛
- القدرة على الاستخدام على الخادم الخاص بك (للمشاريع المغلقة) ؛
- التواجد في وحدة الموظف الذي لديه خبرة كبيرة في إدارة هذا النظام ويهتم بتوحيد تطبيقه.
من الناحية التاريخية ، تم استخدام الإصدار 6.4 من JIRA للاستخدام في العمل ، ومع ذلك ، فإن العناصر الفردية للحلول التي تم تنفيذها على هذا الإصدار في مشروعنا ظهرت جزئيًا في إصدارات JIRA الجديدة من الصندوق (والتي أكدت بشكل غير مباشر صحة القرارات المتخذة).
يسعى أتمتة إدارة المشاريع في البداية إلى تحقيق الأهداف التالية:
- تحسين نوعية نوم موظفي فريق المشروع (كما تعلمون ، الشخص الأكثر راحة يعمل بكفاءة أكبر بكثير) ؛
- ضمان التوزيع الشفاف للمسؤولية عن تنفيذ مهام المشروع ؛
- توفير "تعدد العمليات" لفريق المشروع ، أي موازاة العمل كلما كان ذلك ممكنًا ؛
- لتوفير التكوين التلقائي للوضع الحالي فيما يتعلق بتنفيذ كل من متطلبات العميل ؛
- توفير رصد للحالة الراهنة للمشروع ، مما يسمح بتحديد مشاكل ومخاطر المشروع في المراحل المبكرة ؛
- لتشكيل مناهج موحدة للمحاسبة ، وطرق لتقييم ومقارنة حالة مشاريع تطوير البرمجيات المختلفة (على غرار خدمات Google Analytics أو Yandex.Metrica ، التي تتيح لك تقييم أي مواقع باستخدام نفس المؤشرات) ؛
- لزيادة دقة تقدير توقيت المهام ، استنادا إلى الإحصاءات التي تم جمعها.
لتجنب "التشغيل الآلي للأتمتة" ، تم أيضًا مراعاة الاعتبارات (القيود) عند تصميم نموذج محاسبة البيانات في JIRA:
يجب ألا تزعج أتمتة إدارة المشروع فريق المشروع. بالنظر إلى التجربة السلبية السابقة في التشغيل الآلي لإدارة المشاريع ، كان أحد عوامل التنفيذ الرئيسية هو خلق مثل هذه الشروط التي اعتبرها كل موظف في فريق المشروع JIRA ليس كحمل إضافي في قارب المشروع ، ولكن كنظام ملاحة جماعي سيُخطر الفريق في الوقت المناسب بخطر وشيك ويساعد على تحقيق الهدف المشروع في أقصر الطرق وأكثرها أمانا. علاوة على ذلك ، يجب أن يسهل استخدام نظام الملاحة هذا حياة جميع أعضاء الفريق ، وليس فقط إدارة المشروع. للقيام بذلك ، في البداية تم التخطيط لإجراءات العمل مع JIRA مع الأخذ بعين الاعتبار تقليل كمية البيانات المسجلة بواسطة المبرمجين والفاحصين والكتاب التقنيين. من ناحية أخرى ، كان الهدف هو خلق بيئة عمل مريحة في JIRA لجميع موظفي المشروع ، مما سيساعدهم على ضمان التخطيط الفعال ليوم عملهم.
ضمان الاستمرارية. أحد أهداف أتمتة إدارة المشروع هو ضمان الاستمرارية بحيث يمكن لأي موظف مؤهل "التقاط" مسؤوليات أحد أعضاء الفريق المتقاعدين دون "فترة تجريبية" وبحد أدنى من الصداع ، بحيث "لا يلاحظ الفريق فقدان المقاتل". في هذا الصدد ، ذكرت حالة أخبرني بها أحد العملاء. ما إن بقي لرئيسه الذي أخبره بكلمة المرور من جهاز الكمبيوتر الخاص به مع نسخة طبق الأصل: "حسنًا ، كل شيء واضح هناك ، ستكتشف ذلك إذا حدث شيء ما ...". قضى هذا الموظف عدة ليال بلا نوم في فهم محتويات عدة مجلدات بأسماء "xxxxx1" و "xxxxx11" و "xxxxx111" (تم تغيير أسماء المجلدات لصالح الحشمة). يتطلب منع مثل هذه الحالات تسجيل نتائج عمل جميع موظفي فريق المشروع ، بما في ذلك مدير المشروع ، لدى JIRA.
بساطتها. لم يكن الهدف من أتمتة إدارة المشروع هو حساب مقدار الوقت الذي يقضيه الموظف وقت العمل في حل المهام المسندة إليه في غضون دقيقة واحدة ، ولكن لضمان حل المهام ذات الجودة المحددة في الوقت المطلوب. لذلك ، عند نشر مشروع في JIRA ، تم اعتماد مبدأ تقليل البيانات المسجلة في النظام. أي يجب أن تكون مجموعة المعلمات المسجلة في نظام التحكم ضرورية الحد الأدنى لاتخاذ قرارات مستنيرة ("
لا يتحقق الكمال عندما لا يكون هناك شيء يجب إضافته ، ولكن عندما لا يكون هناك شيء يجب إزالته "). لقد كان من المفهوم أن النموذج المعتمد لأتمتة إدارة المشروع يجب أن يعمل في ظروف من عدم اليقين وعدم الاتساق (على سبيل المثال ، يمكنك معرفة تاريخ المستند ، ولكن لا تعرف رقمه والعكس صحيح). عند كتابة المعلومات المسجلة ، استخدمنا ، كلما أمكن ذلك ،
قاعدة ميلر ، التي تنص على أن العدد الأمثل للأنواع (الحالات) يجب أن يكون ضمن "سبعة زائد أو ناقص اثنين" (مما يبسط بشكل كبير فهم عمل النظام من قبل الموظفين). لذلك ، على سبيل المثال ، عند تصميم دورة حياة المهام (سير العمل) ، كان من المفترض في البداية أن عدد الحالات يجب أن تمتثل لهذه القاعدة.
منهجية. يجب أن تساهم أتمتة إدارة المشروع في تماسك وتماسك تصرفات جميع العاملين في فريق المشروع (مما يمنع وضع "البجعة والسرطان والرمح").
في أحد المشاريع التي شاركت فيها ، قام فريق من المحللين بتطوير نموذج للنشاط الآلي في تدوين
IDEF0 خلال شهر واحد. يبدو أن استخدام المنهجية التي أنشأتها القوات الجوية الأمريكية (!) يضمن نجاح هذا النهج. ومع ذلك ، عندما درس رئيس قسم البرمجة التقرير التحليلي متعدد الصفحات ، كان أول سؤال له هو: "إذن ، ما الذي يجب عمله بالضبط؟". تحول النموذج الذي تم إنشاؤه إلى أنه غير مناسب للاستخدام كوصف لبيان المشكلة للمبرمجين. أعجب ممثلو العميل عدة مرات ، يتخطون مخططات عديدة ، لكنهم لم يجدوا أيضًا تطبيق هذا النموذج لتحسين أنشطتهم. في النهاية ، تزين هذه المخططات وصف العمليات التكنولوجية ، مما يعطي هذه الوثيقة سماكة وصلابة غير مسبوقة ، لكن التأثير الإيجابي للتحليل استُنفد في هذا الصدد. لم يتم الإعلان عن نتائج شهر عمل العديد من المحللين تقريبًا من قبل المشروع.
في ضوء هذه التجربة ، في أتمتة إدارة المشروع ، كان من المفترض إنشاء
ناقل واحد للمهام
من شأنه ضمان تحويل منسق لمتطلبات العملاء إلى منتج البرنامج النهائي في أقصر الطرق الممكنة وبأقل تكلفة. في الوقت نفسه ، على أساس رصد
المعلمات المتاحة لهذا الناقل ، كان من المفترض أن تحدد وتقيّم وتطور الخصائص الناشئة لفريق المشروع ، والتي كان من خلالها الحكم على حالة المشروع في جميع مراحله.
Kanban متن الداخل الى الخارج
في رأيي ، يعتمد نجاح التحكم الآلي إلى حد كبير على مدى دقة نموذج عنصر التحكم في نظام آلي.
نظرًا لأنه كان من المفترض أن تتم إدارة عملية إنشاء البرامج تلقائيًا ، فقد تم إجراء تحليل لهذه العملية. في رأيي ، تمثل عملية إنشاء وحدات برامج منفصلة دائمًا دورة حياة الشلال المتتالية الكلاسيكية. أولاً ، تظهر قائمة بالمتطلبات للمنتج الذي تم إنشاؤه. يمكن أن تأتي المتطلبات من مصادر مختلفة ولها درجات متفاوتة من التفاصيل. بعض المتطلبات مترابطة ، وجزء آخر مستقل نسبيا. للمتطلبات الفردية ، يمكنك صياغة مهمة تطوير فورًا ، بينما يحتاج الآخرون إلى توضيح وتطويل. أي
هناك دائمًا أعمال متعلقة بجمع متطلبات العملاء وفرزها وتوضيحها (في حين أن صياغة المتطلبات الفردية قد تكون غامضة حتى نهاية المشروع). بعد أن تكون المتطلبات محددة قدر الإمكان ، وكقاعدة عامة ، يتم تشكيل تعريفات المهام المزعومة لمجموعات من المتطلبات المترابطة ، والتي تفصل تفاصيل تنفيذ هذه المتطلبات وهي المادة المصدر للمبرمجين لبدء العمل. بعد البرمجة ، يتم اختبار الوحدات التي تم إنشاؤها بشكل مستقل ودمجها في النظام وإعادة اختبارها. وفقًا لتحديثات البرنامج المكتملة ، يتم إجراء تغييرات مناسبة على التصميم والوثائق التشغيلية ، وبعد ذلك يتم تنفيذ عدد من الأنشطة ،تهدف إلى التعرف على إكمال تطلعات (متطلبات) العميل والتنفيذ اللاحق للوظائف المتقدمة في التشغيل التجاري.مصدرالفرق الرئيسي بين الحياة الحقيقية ومخطط الشلال الجميل هو العشوائية (كل شيء يحدث ليس على مراحل وبشكل غير متسق). في الواقع ، فإن الانتقال من مرحلة التطوير إلى مرحلة أخرى لا يحدث بالضرورة إلا بعد الانتهاء الكامل والناجح من المرحلة السابقة. الشلال الحقيقي له عواقبه الخاصة من التناقضات ، في المناطق الخلفية من المياه الضحلة واللامبالاة ، المستنقعات من الإسهاب ، المنحدرات والجاكوزي من الغموض ، المنحدرات والأحجار الزلقة من الخيال الجامح ، وفي كثير من الأحيان النوافير وحتى السخانات لمتطلبات جديدة. لا يمكن إعادة تشكيل هذا العنصر في إطار المشروع ، تمامًا كما يستحيل على فريق السفينة إعادة إنشاء النهر الذي من الضروري ضمان تسليم شحنات العميل.من أجل شفافية توزيع المسؤوليات في أتمتة إدارة المشروع ، تم تنفيذ مبدأ "1 مهمة - 1 المنفذ". أي
من الواضح أن عملية إتمام المهمة لم تتضمن نقلها إلى فناني الأداء الآخرين. أتاح هذا المبدأ تطبيق نفس العملية التجارية على جميع أنواع المهام ، نظرًا لأن حالة العمل تم تحديدها بشكل أساسي من وجهة نظر المؤدي لهذه المهمة. تم تعديل سير عمل JIRA القياسي قليلاً. كان التغيير الرئيسي هو استبدال الحالة "المعاد اكتشافها" بالوضع "معلق" ، أي ينص عند تعليق العمل على مهمة لأي سبب من الأسباب. لتسجيل المهام التي تم اكتشافها ، تم استخدام حقل المستخدم "عداد إعادة اكتشاف". في الوقت نفسه ، تم تفصيل أنواع أسباب نقل المهام تحسبا للحل:- التنسيق مع العميل ؛
- طلب معلومات إضافية من العميل ؛
- في انتظار حل المهام / المهام الفرعية ذات الصلة ؛
- مطلوب توضيح لبيان المشكلة.
تجدر الإشارة إلى أن إدخال حالة "قيد الانتظار" نفذ فعليًا " زر إيقاف ناقل " لموظفي فريق المشروع ، مما كفل بدوره التحديد الجماعي للمشكلات في المراحل المبكرة من المشروع.
نتيجة للتحليل ، تم تنفيذ النموذج التالي لتسجيل معلومات المشروع في JIRA. لم يتم استخدام نهج مشاركة المهام القياسي الذي تمثله JIRA في المشروع. تم إنشاء ستة أنواع من المهام ، والتي تتوافق في جوهرها مع المراحل الرئيسية لتطوير البرمجيات:- "المتطلبات" - نوع المهمة لتسجيل متطلبات العملاء (مشابه في الإصدارات الجديدة من JIRA - ملحمة) ؛
- «» – , ( ) ( ) ( JIRA – story);
- «» – ;
- «» – , ;
- «» – , ;
- "التنفيذ" هو نوع المهمة لتسجيل نتائج العمل التي تهدف إلى إدخال البرامج المطورة في أنشطة العميل (إجراء الاختبارات ، والعروض التوضيحية ، وإصدار إصدار / تصحيح / datafix ، ونشر البرامج على خوادم العملاء ، وتدريب المستخدمين ، وما إلى ذلك).
تم استخدام المهام الفرعية لحل مشكلات معينة (الوقت الذي لا يتجاوز ساعتين) أثناء تنفيذ المهمة الرئيسية (على سبيل المثال ، لتنسيق قرار التصميم مع مبرمج أو مدير مشروع ، وإجراء مراجعات الكود ، وإعداد بيانات الاختبار ، وما إلى ذلك).وفقًا للقواعد الموضوعة في المشروع ، يعد تسجيل أحد المتطلبات أساسًا إلزاميًا للتخطيط لمهام أخرى. بعد تسجيل المتطلبات وتوضيحها مع العميل (إذا لزم الأمر) ، يتم تشكيل أنواع أخرى من المهام ، تهدف إلى تنفيذ هذا المطلب. بمعنى آخر ، في إطار النموذج المعتمد ، ينبغي دائمًا ربط المهام الأخرى بالشرط الذي يتم تحقيقه من أجله (باستخدام نوع الاتصال "السبب" -> "الإجراء"). من أجل تنفيذ أحد المتطلبات ، يمكن إنشاء العديد من مهام التطوير ، من ناحية أخرى ، يمكن إنشاء مهمة واحدة (للتحليل والتطوير والاختبار والتوثيق والتنفيذ) لصالح العديد من المتطلبات (على عكس نهج JIRA القياسي ، عند الافتراضيمكن ربط هذه المهمة فقط بمهمة واحدة من النوع ملحمة). في إطار النموذج المقترح ، من الممكن أيضًا ربط المهام التابعة الأخرى. من ناحية ، كفل هذا النهج اتساق القرارات المتخذة ، من ناحية أخرى ، وفر إمكانية انعكاس دقيق إلى حد ما للحالة الحقيقية للمشروع. في هذه الحالة ، هناك مجموعة متنوعة من الخيارات لتنظيم العمل ممكنة ، لفهم الالتباس الذي يبدو صعباً للغاية.
- الأزرق - المهمة مدرجة في خطة العمل ؛
- الأزرق - المهمة قيد التنفيذ ؛
- الوردي - المهمة لا يوجد بها منفذ.
- الأصفر - المهمة معلقة ، يتطلب حلاً ؛
- الرمادي - المهمة مغلقة (يمكنك نسيانها) ؛
- البرتقالي - تم تعطيل المواعيد النهائية لاستكمال المهمة.
يشير ظهور نقوش وعلامات حمراء على بطاقة المهمة إلى الحاجة إلى اتخاذ إجراء فوري فيما يتعلق بالمهمة (على سبيل المثال ، يتم عرض النقش باللون الأحمر إذا لم يتم تحديد الموعد النهائي).بالإضافة إلى الألوان ، مع تطور المشروع ، فإن بطاقات المهام على لوحة القيادة محاطة بعلامات إضافية تتيح لك تقييم حالة العمل في المشروع بنظرة واحدة.التسميات ذات الأولوية:
- عادي ؛
- مهم
- حرجة ؛
- الحجب.تسميات حول إطار المتطلبات:
- التطوير (المتطلبات في إطار المشاريع التي تهدف إلى مراجعة كبيرة للأنظمة الحالية) ؛
- دعم موسع (متطلبات الإكمال التشغيلي لوحدات النظام الفردية للتغيرات الحالية في العمليات التجارية للعميل) ؛
- دعم الضمان (اكتشاف أخطاء البرنامج) ؛
- الأنشطة غير المشروع (متطلبات رئيس المشروع المرتبط قبل العمل، و إعادة بيع ديون ، [خبر] ، وتطوير التكنولوجيات الجديدة، وتدريب الموظفين، وما إلى ذلك).تسميات سبب التوقع:
- طلب معلومات إضافية من العميل ؛
- التنسيق مع العميل ؛
- انتظار حل المهام / المهام الفرعية ذات الصلة ؛
- توضيح الصياغة مطلوب.العلامات الخاصة:
- تم الانتهاء من قاعدة البيانات في المهمة ؛
- عدد المتطلبات المتعلقة بالمهمة (كلما زادت المتطلبات ، كلما كانت المهمة أكثر أهمية) ؛
- عدد المهام الفرعية التي لم يتم حلها ؛
- تم اكتشاف المهمة.في الواقع ، أصبحت لوحة القيادة هذه الأداة الرئيسية لتلقي إجابة يومية على سؤال إدارة المشروع: "ما هو الأهم اليوم؟" ، مما سمح لنا بدوره بالرد في الوقت المناسب على المشكلات. من منظور النموذج المقترح ، لمنع حدوث مشاكل في المشروع ، من الضروري ضمان تقليل يومي في كمية الأحمر والبرتقالي والأصفر في لوحة القيادة المقترحة. من ناحية أخرى ، كان هناك سبب للقلق أيضًا هو الافتقار إلى المهام ذات الصلة بالشرط (أي الحالة عند التخطيط للشرط وعدم وجود عمل لتنفيذه).استخدام عوامل التصفية للوحة القيادة التي تم إنشاؤها مكّن في المجمع من التعبير عن الوضع وفقًا لقائمة المتطلبات المحددة. بفضل مساعدته ، كان من الممكن التنسيق السريع لأعمال فريق المشروع بأكمله ، مع تركيز الجهود على المجالات الأكثر إشكالية ، مع عدم فقدان صورة كلية للمشروع.شلال لا يمكن رشيق
من أجل تسجيل نتائج العمل على جميع أنواع المهام ، تم نشر مستودعين (لوثائق المشروع ورمز البرنامج). تنعكس إضافة (تغيير) المواد في هذه المستودعات تلقائيًا في المهام ذات الصلة بـ JIRA وكان النوع الرئيسي لإعداد التقارير من قبل فناني الأداء.تم تخفيض تنظيم العمل باستخدام النهج المقترح لتسجيل المهام في JIRA إلى المخطط التالي.- JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
- , . , , , . () .
- , , . , , ( ), () , , , ( ).
- ( ) , , . . , . «» , ( ).
- من الناحية المثالية ، يجب تشكيل مهام الاختبار قبل تسجيل مهام التطوير (التي تحدد أهداف المبرمجين). أثناء الاختبار ، لا يحتفظ المختبر المسؤول بسجل بالأخطاء المكتشفة فحسب ، بل يصحح أيضًا الأخطاء التي تم اكتشافها في مهمة الاختبار ودليل المستخدم.
- وفقًا للمتطلبات ، والتي بموجبها تم التخطيط لقائمة كاملة من الأعمال ، يتم تشكيل مهام التنفيذ (أثناء التسجيل ، يتم تحديد الأولوية والمواعيد النهائية لتنفيذ المتطلبات مرة أخرى في JIRA).
- بعد التسليم إلى العميل ، يمكن نقل الطلب إلى الحالة "المغلقة" مع الإشارة الإلزامية لتفاصيل وثيقة القبول.
تجدر الإشارة إلى أن تشكيل المهام من جميع الأنواع لتنفيذ شرط واحد ليس شرطا مسبقا للتخطيط الناجح. على سبيل المثال ، يمكن تعيين شرط بسيط مثل "تصحيح خطأ في اسم الحقل" مباشرةً إلى مبرمج. في الوقت نفسه ، خلال تنفيذ المشروع ، لوحظ أن حصة الأسد من التعليقات خلال الاختبارات الأولية والتشغيل التجريبي تمثلت في المتطلبات التي لم يتم تشكيل قرارات التصميم.
في إطار النهج المقترح ، أثبت تخطيط العمل باستخدام
طريقة تخطيط الموجة الدارجة نفسه جيدًا. في الوقت نفسه ، نظرًا جزئيًا للوحة القيادة الموضحة أعلاه ، كان من الممكن تجنب تجزئة وتعارض الأعمال المخططة. في المراحل الأولية للتسجيل ، كان الاختيار وفقًا للمتطلبات يشبه
مظلة حمراء ، حيث لم يتم تحديد تواريخ التوفر والمديرين التنفيذيين المسؤولين ، بالنسبة لمعظم المتطلبات ، وتم تخطيط العمل لجزء صغير منهم فقط. ومع ذلك ، فإن لوحة القيادة من المتطلبات تحولت تدريجيا إلى سجادة زرقاء وخضراء. أرغمتنا البقع الحمراء والبرتقالية التي تظهر على هذه السجادة على إجراء تعديلات يومية على المهام المقصودة ، مما ساعد على تقليل مخاطر المشروع.
أظهر نموذج تنظيم البيانات المقترح قابلية جيدة للتطوير. في البداية ، استخدم ثلاثة موظفين فقط من فريق المشروع (محلل واحد ومبرمجان) JIRA في عملهم ، بينما تم تسجيل متطلبات الأنظمة الفرعية الفردية. ومع ذلك ، بحلول نهاية المشروع ، تم تسجيل ومراقبة 100 ٪ من متطلبات التطوير والدعم الموسع في JIRA بمشاركة جميع موظفي فريق المشروع.
على الرغم من حقيقة أن فكرة أتمتة إدارة المشروع كانت تستند إلى نموذج متتالي من التطوير (الشلال) ، فقد تبين أنه في إطار النهج المقترح ، إذا رغبت في ذلك ، يمكن استخدام عناصر Agile دون ألم. ومن قال بشكل عام أن الشلال غير مرن؟ على سبيل المثال ، لتطبيق
Scrum ، في إطار النموذج المقترح ، يكفي ضمان انتظام الأحداث (المهام) لتنفيذ البرنامج ، ومن ثم ، سيتم "إجبار" جميع الأعمال المرتبطة بهذا الحدث على الامتثال لقواعد العدو المحددة بهذه الطريقة.
بالإضافة إلى ذلك ، فإن الطريقة المقترحة لتسجيل المهام لا تحد من مدير المشروع في تطبيق نهج كانبان واستخدام مجموعة كاملة من
لوحات معلومات Agile التي توفرها JIRA "خارج الصندوق".
أن تستمر
ما هي النتيجة؟ تم تطوير البرنامج المطور في التشغيل التجاري. أثناء الاختبارات الأولية والتشغيل التجريبي واختبارات القبول ، سجل العميل العديد من التعليقات على منتج البرنامج الذي تم تنفيذه. ومع ذلك ، وبناءً على مواد لتوضيح المتطلبات التي تم تخزينها في JIRA ، اضطر العميل إلى التعرف على 25 ٪ من التعليقات باعتبارها متطلبات جديدة تتجاوز نطاق المشروع (كان التعقيد المخطط له لتلبية هذه المتطلبات يتناسب مع المهمة الفنية المكتملة). لم تختف المشاكل المرتبطة بتنفيذ عقد أوامر الدولة ، ومع ذلك ، فإن مراقبة الامتثال للمتطلبات باستخدام JIRA مكنت من تحديد مخاطر التعطيل في مرحلة البدء والاستجابة لها بسرعة. وهذا بدوره كفل الديناميات الإيجابية للمشروع في جميع مراحله ، على الرغم من خصوصيات تطوير البرمجيات الوطنية. ولوحظ أنه إذا تم تسجيل متطلبات العميل لدى JIRA وتم تشكيل مهام التحليل والتطوير والاختبار عليها ، فهناك خلافات ونزاعات أقل بكثير بشأن هذه المتطلبات.
في المرحلة الحالية (مرحلة الصيانة) ، تنعكس جميع المتطلبات في JIRA. يستخدم جميع موظفي فريق المشروع بطريقة أو بأخرى JIRA في عملهم. تكلفة المبرمجين لتسجيل نتائج عملهم في JIRA تستغرق أقل من 1 ٪ من وقت عملهم. بالنسبة للمحللين ، على النقيض من ذلك ، أصبحت JIRA واحدة من أدوات العمل الرئيسية. العثور على مجموعة كاملة من المعلومات لأي من متطلبات العميل أقل من دقيقة. يتم إنشاء مستندات الإبلاغ بناءً على نتائج العمل المنجز تلقائيًا بناءً على البيانات الموجودة في JIRA. أيضًا ، بناءً على هذه البيانات ، يتم تكوين الوثائق المصاحبة للإصدارات (قائمة التغييرات وبرنامج اختبار الإصدار).
سنتين من الخبرة في تطبيق JIRA بموجب القواعد الجديدة أكدت الحقائق القديمة:
- لا يحل JIRA محل إدارة المشروع ، ولكنه يساعد على التنقل السريع لتدفق المهام المتنوعة ؛
- ستساعدك JIRA في تركيز مشروعك على المكان المناسب في الوقت المناسب ، لكنه لن يفعل ذلك من أجلك ؛
- لن تحل JIRA مشاكل المشروع بالنسبة لك ، ولكنها ستساعد في تحديدها بالفعل في المراحل المبكرة (في الوقت نفسه ، ستحدد المشكلات التي كنت ترغب في إخفاؤها) ؛
- مثل أي نظام آلي ، سوف تساعدك JIRA على تنفيذ أي من قراراتك بسرعة ، بغض النظر عما إذا كانت جيدة أو سيئة ؛
- لا تحل JIRA محل اتصالات موظفي فريق المشروع ، ولكنها ستساعد في حل النزاعات دون ألم.
- لن تنقذ JIRA الموظف من الفصل ، ولكنها ستساعد موظفًا آخر ، الذي حل محل المتقاعد ، على معرفة ذلك بسرعة ؛
- ستساعد JIRA في إنشاء مستندات الإبلاغ عن المشروع ، ولكن فقط على أساس المعلومات التي قدمتها للتسجيل.
والأهم من ذلك - JIRA لن تقرر ما إذا كنت ستستخدم مساعدتها أم لا.
وظائف LANIT للمهتمين