على الأشواك والنجوم في طريقها إلى تحسين عمليات التنمية

أحلام ، أحلام

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

- أصدقائي في العمل الرشيق بالنسبة لي: العدو السريع ونقاط القصة وكل شيء ...
- نعم ، على الأقل سنراجع ...



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

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

نظرًا لأننا نعمل مع رسومات ثلاثية الأبعاد ثم استخدمنا مفهوم "عناصر التحكم + القوالب (موقع العناصر على الشاشة ، منطق التحولات)" ، لكي نكون أكثر تحديدًا ، كانت الأمور على النحو التالي:

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

مع هذا النهج ، كانت مراجعات الكود ترفا للتكلفة:

• تم تنفيذ التنمية في فرع واحد ؛
• أثرت التغييرات في مهمة واحدة على العديد من المستودعات والمتابعة التي ترتبط بأي مهمة كانت صعبة للغاية.

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

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

"حيثما يكون هناك حلم ، هناك دائمًا فرصة"

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

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




هنا ، بالمناسبة ، ما قمنا به

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

تعديل Gitflow الخاص بنا هو كما يلي:

• هناك فرع رئيسي (نسميه سيدًا ، ولكن يمكنك إعطاء أي اسم حتى لا يتم الخلط بينه) ؛
• هناك سباق في جيرا ، يتكون من مهام متراكمة توحدها هدف صغير واحد ؛
• يأخذ المطور المهمة من قائمة العناصر المفتوحة في السباق إلى التقدم ويقوم بإنشاء فرع ميزة من الرئيسي ، مشيرًا إلى رمز المهمة باسم فرع الميزة الخاص به (على سبيل المثال ، PLAYER-55) ؛
• بمجرد اكتمال العمل في المهمة ، يقدم المطور عمله للمراجعة: من خلال Gitlab ينشئ طلب دمج لإتقان المهمة ونقلها إلى Jira عند المراجعة مع رابط إلى طلب الدمج في التعليق ؛
• إذا اكتملت المراجعة وأغلقت جميع المناقشات ، فسيتم إغلاق المهمة في Jira ، ويتم دمج فرع الميزة في Master وحذفه ؛
• إذا كانت هناك تعليقات بعد المراجعة - في Jira ، يتم إعادة اكتشاف المهمة من Review ويتم تشغيل الخوارزمية من البداية ، باستثناء أنه تم إنشاء فرع الميزة بالفعل.

عندما يتم إغلاق جميع المهام ، ندخل مرحلة الإصدار:

• يتم استدعاء فرع الإصدار بعيدًا عن الرئيسي ، والذي يسمى رقمين ، على سبيل المثال ، الإصدار 3.0 ، حيث 3 هو رقم إصدار المشروع ، و 0 هو رقم فرع الإصدار (على التوالي ، سيطلق على فرع الإصدار التالي الإصدار 3.1 ، إلخ. ) ؛
• يتم إجراء اختبار إضافي لمرشح الإصدار (عادة تطوير عروض توضيحية صغيرة) ؛
• إذا لم يتم العثور على عيوب أثناء الاختبار ، فإن مرشح الإصدار جاهز للإنتاج: يتم تمييز آخر التزام في فرع الإصدار بعلامة إنتاج تتكون من 3 أرقام (على سبيل المثال ، prod-3.0.0 ، حيث 3 هو رقم إصدار المشروع ، 0 - رقم فرع الإصدار ، 0 - رقم إصدار الإنتاج) ، ثم يكون فرع الإصدار عالقًا في الشريحة الرئيسية ولا يتم حذفه ، على عكس Gitflow الكلاسيكي ؛
• إذا كانت العيوب لا تزال موجودة ، يتم تسجيلها في Jira كـ Bug ثم تشبه عملية إصلاح الأخطاء العمل مع مهمة في فرع الميزة (يتم فحصها فقط من الإصدار ، وليس من الرئيسي) وعندما يتم إغلاق جميع الأخطاء ، نضع علامة الإنتاج ، يتم إخراج الإصدار إلى prod ويتم دمج فرع الإصدار في master ، دون حذفه.

في حالة وجود أخطاء في الإنتاج ، هناك أيضًا اتفاق:

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

فلماذا بالضبط Gitflow وهذا فقط؟

1. يُعد إدخال فروع الميزات طريقة لتقديم مراجعة ، والتي تسمح لك بمشاركة الخبرات ، وزيادة المستوى العام لتأهيل الفريق ، والأهم من ذلك ، نتيجة لذلك ، لتجنب الحصول على رمز منخفض الجودة في المنتج النهائي الذي لا يحتوي على نمط شائع ، يصعب فهمه ومليء بالأخطاء.
2. أعتقد أن الكثير من الناس على دراية بالحالة عندما يتم تقييم المشروع وفقًا للاختصاصات والمواصفات ، ويتم تخصيص ميزانية لذلك ، وتقوم بتنفيذ الوظيفة وفقًا للمتطلبات في الوثائق ، ولكن هنا ، من حيث لا شيء ، سوف يفرخ شخص من الرؤساء وتسمع: "أوه ، ولكن دعنا نضيف اثنين من أحادي القرن هنا ، سيعجب العميل "،" وهل يمكنك إتاحة الفرصة للاتصال بصديق في هذه المنطقة من خلال النقر على منطقة على الخريطة؟ ستكون قنبلة ، تابع "،" نحن بحاجة إلى إضافة وسيلة إيضاح "،" الآن يجب إزالة الأسطورة ، والتوقيعات أيضًا "،" إزالة التوقيعات غير ضرورية ، أعدها. " وكل هذا "مجاني بدون تسجيل ورسائل قصيرة". وبعد ذلك ، عند حساب التكاليف الفعلية ، اتضح أن الأمر استغرق الكثير من التطوير مع هذا العدد الصغير من المهام (بعد كل شيء ، لا يتم تسجيل "الطلبات" في Jira ، لأنه لا يمكن لكل مطور أن يرفض الرئيس أو يرسله لتسجيل "طلبه". "، وهذا يمكن فهمه). إن إدخال قاعدة تسمية الفروع الفردية برمز Jira وعدم القدرة على دمج الفروع في Master دون ربط بـ Jira يلغي وجود عمل وتضارب غير مسجلين قد ينشأان إذا "بدأ المطور في تنزيل الحقوق" ، مما يتطلب منك ملء "الطلب" كمهمة في Jira ، ويتيح لك أيضًا الحصول على فكرة واضحة عن مقدار العمل الذي تم القيام به بالفعل (يتم تأكيد المهام في Jira بواسطة الرمز المرتبط بها ، التعليمات البرمجية المكتوبة عن طريق التواصل مع المهمة المسجلة).
3. يساعد اتصال Gitflow مع Jira من حيث تحديث حالات المهمة على تجنب موقف يقوم فيه العديد من الأشخاص بنفس المهمة. في حالة تحديث الحالات وفقًا لمرحلة Gitflow الخاصة بهم ، سيرى الجميع أن مثل هذه المهام ومهامها قيد التنفيذ بالفعل أو قيد المراجعة ، على التوالي ، بالنسبة لهم ، هناك بالفعل فروع ميزات تتم كتابة الرمز فيها ، ولا تحتاج إلى أخذها. كما أنه من الواضح بوضوح من يفعل ما وما يمكن أن يؤثر على بعضهم البعض ، أي من الرجال يجب أن يتصل ويوافق على تنفيذ معين في كثير من الأحيان ، بحيث عندما لا يكون الاندماج مضطرًا إلى حل تعارضات رمزهم الطويلة بشكل مؤلم.
4. نظرًا لأننا نعمل على تطوير نظام أساسي لإنشاء التطبيقات ، يجدر النظر في أن المنتجات النهائية لشخص ما ستعتمد على سياستنا في دعم الإصدارات القديمة من النظام الأساسي وإدخال إصدارات جديدة. من الممكن أن يستخدم بعض مستخدمي النظام الأساسي لسبب ما أحدث إصدار من النظام الأساسي ويجدون خطأ متعلقًا بالمنصة. إذا قمنا بحذف فروع الإصدار ، فلن نتمكن من مساعدة مستخدمينا في مثل هذه الحالة ، خاصةً إذا تم حذف الوظائف التي يستخدمونها في نسختهم أو تعديلها في تنفيذ النظام الأساسي الجديد. وفقًا لذلك ، يتيح لك حفظ فروع الإصدار توفير الدعم للمستخدمين الذين لا يعملون مع أحدث إصدار من النظام الأساسي.

ماذا عن رشيقة؟

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



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

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

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

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

"ودعنا بسرعة" أو 3 تطبيقات تجريبية كاملة لمدة شهر

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

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

1. فرق صغيرة. 2-3 مطورين ومصمم واختبار ومدير.
2. التطوير الموازي (تم إنشاء عناصر التحكم سابقًا أولاً ، ثم النماذج مع مظهر التطبيق ومنطقه).
3. استخدام مهام مثل Story in Jira. لم تكن هناك مواصفات واضحة ومعارف تقليدية ، لذلك جمعت كل المعلومات المتاحة عن السلوك والمظهر المتوقع للتطبيق ووضعها كلها في Story. ثم تم اختبارها عليهم ، مما تسبب في رد فعل إيجابي بين المختبرين ، لأنه تم جمع جميع المعلومات في مكان واحد ، ولكن في نفس الوقت تم تقسيمها إلى أجزاء وظيفية ، مما سهل التحقق. ولم يكن على الفريق ككل قراءة مجموعة من النصوص الرسمية من أجل فهم المهمة وإكمالها بشكل صحيح. أيضًا ، على عكس مستندات Word ذات المواصفات ، تم تحديث القصة بشكل أسرع ، تلقى الأشخاص بسرعة وصفًا بتحسينات جديدة ، وبالتالي ، بدأوا في تنفيذها بشكل أسرع.
4. Gitflow مع تطوير وفروع رئيسية ، ولكن بدون ميزة:

• تم تنفيذ جميع عمليات التطوير في فرع التطوير ، ولكن لاستبعاد وجود مهام غير مسجلة ، يجب أن يتم تمييز كل التزام برمز المهمة من Jira ، والذي تم تنفيذه في إطاره ؛
• عندما تم حل جميع المهام المخططة للإصدار ، كان يتم تجميع بنية جديدة: أجرى قائد الفريق مراجعة لفرع التطوير ، وإذا كان كل شيء على ما يرام هناك ، تم دمج التغييرات في ماستر مع تعيين علامة برقم البناء. إذا تم الكشف عن أخطاء ومخالفات جسيمة أثناء المراجعة ، تم إرسال الرمز للمراجعات وفقط بعد إدخالها وإعادة فحصها ، تم إدخالها في سيد.
• تم ترقيم البنيات برقمين ، على سبيل المثال ، 0.1 - وهذا هو دائمًا رقم الإصدار التجريبي الأول ، حيث يعني 0 - الانتماء إلى إصدار الإنتاج ، 1 - رقم البناء. وهكذا ، في عدد كل بناء اختبار لاحق ، زاد الرقم الأخير ، حتى يعطي المختبر والمدير استنتاجًا مفاده أن البناء جاهز للإخراج في الإنتاج. وفقًا لذلك ، إذا كان هذا هو الإصدار الرابع من الاختبار (0.4) ، فقد أصبح أول إصدار إنتاج (1.0) وتم وضع العلامة المقابلة في الفرع الرئيسي. إذا تم الكشف عن عيوب في الإنتاج ، وتم إرسال بنية الإنتاج للتحرير ، فسيزداد الرقم الثاني أيضًا عند ترقيم جميع البنيات اللاحقة (1.1 ، 1.2 ، إلخ).

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

في رأيي المتواضع

ما رأيي الشخصي في هذا؟

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

هنا السر

على الرغم من الاستنتاجات المذكورة أعلاه ، وظهر لي شيء آخر:

- ليس الجميع مستعدًا لما يحلمون به.

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

لذا في عملية إدخال قواعد ومبادئ جديدة ، لم نواجه ردود فعل إيجابية ونتائج فحسب ، بل أيضًا بإدراك سلبي لما كان يحدث. بالنسبة للبعض ، كان العمل مع Jira و Gitlab يبدو كثيرًا من الضجة ، وكان تغيير هذا التصور صعبًا للغاية حتى صادف الناس وضعًا صعبًا حدث بسبب تجاهل سير العمل المقبول بشكل عام. تم تنفيذ بعض المهام بلا مبالاة ، ولم تؤخذ الأوصاف في بيانات القصة والمشكلة في الاعتبار أو تم اعتبارها على أنها "طلبات شخصية" ولم يتم تنفيذها ، على الرغم من التسجيل مع Jira ببيان واضح. , , . , , , , , , , « ». , - , .

- , , :

— , — , , , , , — .



, , , . — . , , — .

, , « ». , , , , — . , , .

, — , .