في هذا المنشور ، سأتحدث عن المشكلات التي واجهها فريق Scrum Front End خلال عام في العمل على مشروع لائق. بدأنا تطوير المشروع من نقطة الصفر باستخدام مكدس تقنية React + Typescript. إذا نظرنا إلى الوراء ، أرى العديد من الملايين يلقون عبثًا ببساطة لأن عملية التطوير لم تبدأ من البداية. ولكن هناك أسباب لذلك.
أولاً كان عليك الفوز بالمناقصة. للقيام بذلك ، كان من الضروري تقديم منتج ذو قيمة دنيا بسرعة. وهنا يكمن الخطأ الأول الذي كلف مبلغًا لائقًا لعملائنا. هذا يبدو كالتالي: gash MVP بسرعة. يريد العميل أن يرى النتيجة بسرعة ، ولكن هذا يعني أننا نضحي ببنية تحتية جيدة وهندسة موثوقة وبعد مرور عام توصلنا إلى استنتاج مفاده أن هندسة الواجهة الأمامية تتطلب إعادة هيكلة جادة. حوالي بضعة أشهر. لذلك نحن تسربت 500000 روبل.
إذا نظرنا إلى الوراء ، يمكنني القول بثقة أن أول شيء فعله هو مراعاة جميع الوظائف التي أراد العميل رؤيتها في النهاية ، بعد بضع سنوات. لذلك يمكننا تجنب الأخطاء المعمارية في نمط "هذه البنية لا توفر هذا". نتيجة لذلك ، تطلبت كل شريحة رئيسية إعادة هيكلة خطيرة.
من أجل الفوز بالمناقصة ، أرسلت شركتنا مطورين لم يكن لديهم خبرة في تصميم التطبيقات الكبيرة وأنظمة قابلة للتوسيع يمكن الاعتماد عليها. العمل الواضح ، العطاء ليس أمرًا ، ولا أحد يريد أن ينثر أفراد جيدين. لكن عدم وجود مهندس فني على مستوى (الطبقة) أدى إلى حقيقة أن طلبنا تحول إلى كود معكرونة وتوقف عن تلبية متطلبات SOLID. وهنا يكمن خطأ كل عميل. لا يمكن الحفاظ على وتيرة التطوير المستمرة دون زيادة موارد الفريق. مبدأ Agile "يجب على المستثمرين والمطورين والمستخدمين أن يكونوا قادرين على الحفاظ على إيقاع ثابت إلى أجل غير مسمى" يعمل فقط في حالة ما إذا كانت المتطلبات معروفة وعملت منذ البداية ، تم تصميم مجموعة كاملة من الوظائف ، وهيكل موثوق به وقابل للتوسعة (بكلمة ، إذا تم التفكير في كل فصل مع مراعاة النهائي وظائف النظام) وعمليات محددة بوضوح. وهذا ما يجب القيام به في MPV قبل نشر المنتج. خلاف ذلك ، مع الوقت الخطي ، يزداد تعقيد التطبيق أضعافا مضاعفة. هذا يعني أن ميزة gash في السنة ستكلف O (e (N)) أكثر تكلفة مما كانت عليه في البداية.
في فريقنا ، كان المصمم الوحيد موظفًا بعيدًا. لقد كان خطأ جسيما. الموظف البعيد يعيش حياته دائمًا. إنه يرسم تصميمًا لنفسه ، بشكل جميل وجيد ، العميل سعيد. ولكن كل هذه السحر في النهاية تأتي إلى حقيقة أن لدينا N أنماط مختلفة والتنضيد على نفس الأشكال المنطقية. من البداية ، كان الأمر يستحق وضع شرط: أسلب إطارًا معينًا (كان لدينا تصميم النمل). إذا لم يكن هناك شيء ، افعل ما هو موجود. اعتقد العميل أن React كان منشئًا للكتلة. وما زال لا يفهم لماذا نشهد أشكالًا بدائية لمدة 4 أيام. React مُنشئ ، ولكن فقط إذا كان في بداية التطوير لدينا مجموعة من المكونات القابلة لإعادة الاستخدام المشابهة (إطار واجهة المستخدم). المصمم بدون تجربة تخطيط لن يقوم بذلك بنفسه أبدًا. لن يخبر المطور العميل أبدًا بهذا. هذا يجب أن يتبعه القائد. لذلك يجب أن يكون قائد فريق Front End هو المطور Front End في الماضي ، وليس Back End كما هو الحال دائمًا. لذلك ، توصلنا إلى استنتاج مفاده أنه ينبغي لفريق رشيق يعمل بكامل طاقته أن يضم قائدًا مختصًا في كل مجال من مجالات عمله (FE، BE). يجب أن يتمتع هؤلاء القادة بمهارات ناعمة قوية لكي ينقلوا إلى العميل ما أحاول أن أصفه في هذه المقالة. وهذا صعب للغاية.
عندما أصدرنا الإصدار الأول ، أدركنا أن هناك شيئًا ما ينكسر باستمرار في اليوم الأخير قبل العرض. على مدار عام التطوير ، يتحول كل فرع من فروع الإصدار إلى مجموعة من العكازات الجهنمية (قم بإيقاف تشغيله ، وقم بإزالته) والتي تنتهي بعد ذلك بطريقة سحرية في فرع التطوير. وهناك سلسلة من الالتزامات (قم بتشغيل هذا ، قم بتشغيله). بعد عام ، توصلنا إلى استنتاج مفاده أننا نحتاج إلى سياسة واضحة للفروع. ولكن الأهم من ذلك ، الشخص المسؤول الذي من شأنه القضاء على الفوضى القائمة. هذا يعني: إما لتهدئة رغبات العميل الفوضوية ، أو لتخفيف الخلل الفوضوي ، أو في كل موقف أن يكون له التكوين الخاص به تعطيل نوع من ميزات الرسوم أو الأزرار. التفاف كل زر في بيان إذا مجنون. لقد توصلنا إلى استنتاج مفاده أننا بحاجة إلى بنية واجهة للوحدات الأمامية للميزات الإضافية (تعطيل - تمكين). فكرت لفترة طويلة في كيفية تحقيق مثل هذه الهندسة المعمارية. لكن شيء واحد فهمته بالتأكيد. نحن بحاجة إلى سياق كامل. لذلك ولدت مكتبة شبيبة الفول (https://www.npmjs.com/package/js-beans). كان لكل موقف سياق json الخاص به. تم جمع المكونات الإضافية في سلسلة (سلسلة) من خلال نمط الوكيل. لذلك ، على سبيل المثال ، كان لدينا مصدر بيانات كصندوق منفصل ، وتم إجراء العديد من التحويلات كحقول وكيل بديلة تحل محل هذه الحاوية ، ولكن حقنها في نفسه. على سبيل المثال ، إذا كنت بحاجة إلى قياس نموذج البيانات لاختبار أداء FPS ، فأنا فقط أضف السطر لتمكين المكون الإضافي للتحجيم في ملف json. حدث شيء ما في الإنتاج ، لكنه لا يلعب محليًا ، فأنا أقوم بتشغيل جهاز التسجيل بخط واحد دون إعادة بناء الحامل (يستغرق الحامل حوالي 20 دقيقة ، وهناك عشرات المواقف لا تكفي دائمًا للجميع). أو إذا كنت بحاجة إلى إيقاف تشغيل وحدة ما بسرعة بسبب حقيقة أنه يمكن كسرها (قم بتعطيل الحبة الاختيارية في السياق).
مع مرور الوقت ، تم إيقاف المدرجات لمدة أسبوع. كان من المستحيل تطوير الجبهة محليا. لم نوفر الهندسة المعمارية ذاتية الحكم على mokas. كان علي أن أصابها بألم شديد. إذا نظرنا إلى الوراء الآن ، كنت سأفعل ذلك في البداية. ولكن كان لدينا MVP ، واضطررنا إلى كتابة التعليمات البرمجية دون هندسة عميقة. لكن العميل اعتبرنا محترفين ، واعتقد أننا يجب أن نكتب الشفرة على الفور دون أخطاء. هنا هو الخطأ التالي. اسم الشركة لا يتحدث عن الكفاءة المهنية للفريق. يتم تحديد الكفاءة المهنية للفريق من خلال الكفاءة المهنية لقائد الفريق. إذا لم يكن هناك قائد فني في الفريق ، فسوف يتوقف مشروعك خلال عام. لذلك دمج عدة ملايين إضافية.
كان لدينا مهندس معماري عن بعد. لكن كان هناك شيء واحد معروف عنه: هو. المرحلة الأخيرة من تطوير الزعيم وفقا لفلاديمير تاراسوف. في هذا مهندسنا حقق الكمال. خطأ رقم N: ليس لديك مهندس تقني يقوم بتصميم النظام على مستوى الفصل. ليس لديك أي شخص يطلب المساعدة إذا كنت في حالة توقف تام. طلب المساعدة من الفرق الأخرى الأكثر خبرة ، أخبرنا العميل بذلك. لكن لسبب ما ، لم يكن لدى الفرق الأخرى وقت لمساعدتنا. تم تعليق العلاقات العامة لدينا للشهر الثاني. أتمنى مخلصًا أن يكون هناك رجل شجاع يقوم بتتبعه. نتيجةً لذلك ، كافأت الحياة كودنا بوفرة غنية من الظواهر الخارقة في شكل السحر ومجموعات من العكازات لجميع المناسبات. واحد فقط كان في عداد المفقودين. التعليقات التوضيحية الخاصة
Magic و @ Kostyle. فكرة جيدة ل ES المقبل.
قررنا أن المزيد من الرجال المتوسطين وعدد أقل من الرجال كانوا أكثر ربحية للمشروع. الآن نحن نفكر بشكل مختلف. إذا كان لديك ميزانية صغيرة ، فأنت بحاجة إلى توظيف أخصائيين أغلى. إذا لم يكن لديك ، مثلنا ، أي مشاكل في الميزانية ، يمكنك حفظ بأمان على المتخصصين وتحويل Code Review إلى معركة من الوسطاء.
كنا نظن أننا سنلتقي بالمواعيد الفصلية. الآن نحن نفكر بشكل مختلف. باختصار ، من أجل الخير ، نحتاج إلى إعادة كتابة المشروع. ويفضل من الصفر. آمل ألا يعرف عملائنا أبدًا عن ذلك. بعد كل شيء ، كان لدينا مؤخرا فريق رائع بناء)
قررنا أن نتجول مع التقنيات الجديدة التي لدينا خبرة قليلة. وقد أوصى لنا. بالطبع أردنا اكتساب الخبرة. الآن أعتقد أنه سيكون من الأفضل استخدام فقط تلك التقنيات التي لدي خبرة.
قدمنا تقديرات تستند إلى يوم عمل 8 ساعات. في الواقع ، ينبغي تقديم التقديرات على أساس يوم عمل مدته 4 ساعات. لماذا لا يتضمن أي شخص الشاي ، ورواية القصص المثيرة للاهتمام ، والبحث عن مرحاض على المستكشف ، والتحدث على الهاتف ، والمراسلات ، ودراسة التقنيات الجديدة ، والأهم من ذلك ، النزاعات الحماسية داخل الفريق. هذا الأخير هو على الأرجح الأكثر حتمًا والأكثر تكلفة. على الرغم من أن نكون صادقين ، فبالنسبة لـ Open Space ، لا تزال بحاجة لرمي بضع ساعات. الحديث المستمر يقلل بشكل رهيب من التركيز. طوبى للعميل الذي يفهم كل هذا!
كانت تقديراتنا مرهقة وتحولت إلى جدلية تقنية مملة على أي حال. كانت فعالية التجمعات ضئيلة. ولكن وجدنا حلا: البيتزا اللذيذة. عندما تهيج رائحة لذيذة الأنف ، يبدأ الشخص بالتعبير عن أفكاره بشكل أكثر وضوحًا.
في البداية كان لدينا فريق صغير واحد ، ثم فريق كبير واحد. استغرق التخطيط 2-3 ساعات. ستاندوب 30 دقيقة. لما أحترم أمر الشراء الخاص بنا ، فذلك لأنه قرر تقسيمه إلى العديد من المشاريع الصغيرة وتخصيص أمر الشراء الخاص به في كل منها. ربما كان هذا أفضل قرار في تاريخ مشروعنا.
من البداية ، لم يكن لدينا وقت لكتابة الاختبارات. بعد نصف عام ، توصلنا إلى استنتاج مفاده أنه لا يزال يتعين عليهم كتابتهم. لكننا ما زلنا لا نجد الوقت لذلك. تراكم الديون التقنية ذات الأولوية الأعلى بكثير. لا تقم بحفظ الديون الفنية - وهذا هو اليوتوبيا. سيكون دائما.
استنتاجاتي الشخصية الشخصية:
- إذا لم يفهم المطورون لديك ما هو IOC for FrontEnd ، فغالبًا ما يكون قد فهموا أن الوقت سيكون متأخراً عندما يفهمون ذلك.
- إذا كان المطورون لديك لا يفهمون لماذا تحتاج FrontEnd إلى معرفة OOP ، فلا يمكن دعم الكود.
- المتخصصين الأقل تكلفة هم أفضل من المتخصصين الأكثر ربحية.
- إذا كان لديك مهندس معماري ، فمن المحتمل أنك تحتاج إلى مهندس آخر.
- إذا كنت تنشر MVP ، فقم بإنهائه وقم بتغيير المشروع.
- إذا تم تسجيل MVP بالفعل قبل ، لا تذهب إلى هذا المشروع.
- إذا صادفت MVP ولا ترغب في المغادرة ، فعلى الأرجح ستغير رأيك.
- إذا كنت zapilili MVP وتريد أن يستمر مشروعك ، فقم بإعادة كتابته من البداية.
- إذا قمت بعرض هذه المقالة على أحد العملاء ، فمن المرجح أن يتم طردك.
- إذا كنت تعمل على Agile ، فمن المرجح أنك تفهمني.
من غير المحتمل أن تتجنب كل هذه المشكلات حتى بعد قراءة هذه المقالة. هدفي هو أن أوضح لك أن هذا أمر لا مفر منه. وبغض النظر عن مدى صعوبة المحاولة ، فلن تحصل أبدًا على ظروف مثالية. لذلك فقط كن مستعدا لذلك. وقبل الفصل ، يمكنك عرض هذه المقالة بأمان على عميلك. فليكن جاهزا معنويا لهذا.
ملحوظة: مكسيم ، إذا قرأت هذا المقال من قبل ، فأعرف أن كل ما وصفته خيالي تمامًا وليس له أي تشابه مع مشروعنا) ولكن كل هذا ليس مهمًا ، لأنني اليوم في عطلة. أول عطلة في عام من العمل الشاق المضنية! (كما يؤدي FE).