جيرا ضد الفوضى في التنمية: كيف لا تفقد المهام

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

معطى:

• تقوم بتطوير ودعم منتج برنامج معقد يعمل على عدة عملاء.
  
• لديك العديد من الفرق الهندسية (الخلفية ، IT Ops ، iOS ، Android ، الويب ، إلخ) التي تعمل بشكل مستقل عن بعضها البعض مع تراكم منفصلة ؛
  
• لديك العديد من خطوط الإنتاج ، بمعنى أن مدير منتج واحد يقود عدة مشاريع في اتجاهه ، ومدير آخر - بطريقته الخاصة ؛
  
• فرق الهندسة الخاصة بك وظيفية ، أي أنها غير مخصصة لفصل مجالات المنتجات ، ولكنها تحل مشاكل جميع الوحدات في وقت واحد ، وتخدم جزءًا معينًا من المكدس التكنولوجي ؛
  
• وبالطبع أنت تستخدم جيرا!
  

المشاكل:

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

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

هل هذا مألوف؟ دعونا نفكر فيما يمكننا القيام به حيال ذلك.

هيكل المشروع

سوف أقوم بتحليل المشكلة باستخدام مثال التطوير في Badoo. فكيف يعمل المشروع؟ ما هي المراحل التي يمر بها المشروع؟ ما القطع التي تتضمنها الميزة النموذجية الجديدة والتي تتطلب مشاركة العديد من الفرق؟

الفكرة والتصميم

يقوم مدير المنتج (PM) ، بعد أن توصل إلى ما يمكن تحسينه في المنتج ، بإنشاء بطاقة PROD مع النوع Project في Jira. يتكون وصف هذه البطاقة من رابط واحد لصفحة في كونفلوينس (تناظرية من يلا أتلاس التي تتكامل مع جيرا). هذه الصفحة نسميها PRD (مستند متطلبات المنتج). إنه عنصر أساسي للتنمية. في الواقع ، هذا هو وصف مفصل لما لا يزال يتعين القيام به في إطار المشروع.


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

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

عندما يتم توضيح جميع الفروق الدقيقة ، تتم ترجمة تذكرة PROD الأولية إلى تراكم التطوير المعلق. بعد ذلك ، مرة واحدة في الأسبوع ، يقوم فريق المنتج بفرز هذه الأعمال المتراكمة وفقًا للأولوية وفقًا لأهداف الشركة والعادم المقدّر وتعقيد التنفيذ. المشاريع المعترف بها بأنها الواعدة ، والانتقال إلى المرحلة التالية - التحلل. لهذا ، يتم إنشاء تذكرة MAPI خاصة (Mobile API) لفريق مهندسي النظام.

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



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

يتم تطبيق تحسين التدفق على أساس البرنامج المساعد Jira ScriptRunner ، الذي كتبت عنه في مقالة سابقة .

التحلل

بعد تلقي تذكرة MAPI جديدة مع PRD مرفقة بها ، يقرر مهندسو النظام:

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

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

يمكنك معرفة المزيد حول كيفية عمل فريق المهندسين المعماريين لدينا ومشاهدة وصف API الخاص بنا من التقرير .

نتائج عمل مهندسي النظام هي:

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

   
   
   
   
2. البروتوكول المعدل (ملف بتنسيقات Google Protocol Buffers) في المستودعات. إذا كانت هناك حاجة إلى ميزات جديدة أو تغييرات على الميزات القديمة لتنفيذ الميزات ، فستكون متاحة لمطوري جميع الفرق.
   
3. تذاكر لتطوير وفرق التعريب. لهذا ، لدينا واجهة خاصة تسمح لك بإنشاء التذاكر اللازمة لجميع الفرق المشاركة في آن واحد. يتم فتحه بواسطة ارتباط من تذكرة MAPI.
   
   
   
   بالنقر فوقه ، تفتح الواجهة التالية التي أنشأناها:
   
   
   
   بالنقر فوق الزر الموجود في أسفل النموذج (غير مرئي في لقطة الشاشة) ، ستظهر التذاكر اللازمة ، والتي سيتم ربطها تلقائيًا ببطاقة MAPI الأصلية. تجدر الإشارة إلى أن جميع فرق التطوير تعمل في منطقتنا (مشروع) جيرا: فريق الخلفية في SRV ، وفريق Android موجود في AND ، وفريق الويب موجود على الويب ، إلخ.
   
   تعتمد الواجهة على Jira REST API.
   

وبالتالي ، يمكن تصور هيكل المشروع على أنه المخطط التالي:

تطوير وإطلاق

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

عادةً ما يتم تشغيل ميزة في السيناريو التالي:

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

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

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

كيفية تسوية هذه المشاكل؟ كيف تتأكد من عدم ضياع أجزاء المشروع ، وتولي الفرق الاهتمام الواجب للمشروعات ذات الأولوية؟

جيرا الميزات القياسية

ما الذي يمكن أن توفره وظيفة Jira القياسية لمدير المشروع لحل هذه المشكلات؟ ليس كثيرا

• مرشحات
  
• مجالس kanban.
  

مرشحات

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

لوحات كانبان

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

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

نحن نستخدم لوحات kanban لتشكيل ومراقبة تراكم الفرق الهندسية. باستخدام أداة Swimlanes ، يمكن تجميع لوحة في مشاريع تتوافق مع الفرق الهندسية. وبالتالي ، باستخدام هذه الأداة ، يمكن لـ PM مراقبة تقدم مشاريعها في سياق فرق مختلفة ، وكذلك إعطاء الأولوية لتذاكر الفريق.


مخطط لوحة kanban للمنتج ، حيث يتم تجميع تذاكر مشروعات PM بواسطة فرق

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

اكسل

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



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

"ودعونا نعبر!"

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

كانت متطلبات الأداة كما يلي:

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

يبدأ PM في العمل باستخدام الأداة ، وإنشاء مساحة خاصة به (وحدة) ، مع الإشارة إلى اسمه واستعلام JQL:



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



في الأعلى روابط للتبديل بين الوحدات.

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

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



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

يتم الفرز ببساطة عن طريق سحب وإسقاط المشروع المطلوب إلى الموقع المطلوب في القائمة:



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

الاستنتاجات

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

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

شكرا لكم جميعا على اهتمامكم!