بالنسبة للعديد من الفرق ، إعادة البناء هي ألم. لأنك إذا لم تقم بإعادة البناء ، فلن تقوم بتطوير المنتج الرئيسي ، وإذا لم تقم بذلك ، فإن الدين الفني للمشروع ينمو. في مرحلة ما ، توصلت الفرق إلى الفكرة: "دعونا نميز بين إعادة البناء وإعادة التخصيص وتخصيص ، على سبيل المثال ، 20 ٪ من ساعات العمل لدينا ، وبقية الوقت الذي سنستمر في المشاركة في التنمية!" هذه الفكرة ليست سيئة ، والشيء الوحيد هو أنه لكل 100 ساعة تطوير لن تحصل أبدًا على 20 ساعة نقية من إعادة البناء. لأن "التطوير" لا يعمل فقط مع الكود.
إذا كنا نتحدث عن الفرق الناضجة ، بدلاً من الفرق المصغرة المضغوطة في نقطة مادة لـ 3-5 أشخاص ، فإن "التطوير" يشمل مجموعة كاملة من أنشطة الفريق المختلفة إلى جانب كتابة التعليمات البرمجية. في "التطوير" ، يمكنك تدوين الاجتماعات التي لا يحبه الكثيرون ، والعمل مع الوثائق ، والحفاظ على التقارير في مديري المهام ، وما إلى ذلك. كل هذا يستهلك حوالي 30٪ من ساعاتنا المخصصة للتنمية. وبطريقة ما ، دون أن يلاحظها أحد ، اتضح أنه بدلاً من الصورة "80 ساعة من الكود ، 20 ساعة من إعادة التوطين" ، نحصل على رقم قبيح بـ 13 ساعة تقريبًا من أجل إعادة التجهيز مباشرة ، لأن كل شيء آخر استوعبته أنشطة أخرى.
فيما يلي سنخبرك بكيفية الجمع بين التطوير وإعادة التسكين حتى لا ينمو الدين الفني للمشروع مثل كرة الثلج ، بل نتحدث أيضًا عن التوزيع الصحيح للوقت وتحديد الأولويات.
لماذا تتسبب إعادة البناء في الكثير من المشاكل؟ بادئ ذي بدء ، نظرًا لحقيقة أنه لا يمكن للفرق تقييم مواردها بشكل كاف والجمع بين هذه العملية والتنمية. يبدو للناس أنه إذا كان يوم عملهم هو 8 ساعات في اليوم (40 أسبوعيًا) ، فمن المفترض أنهم يشاركون في التنمية طوال الأربعين ساعة. هذا ليس كذلك.
يمكن تقسيم عملية التطوير بأكملها إلى قسمين: هذه أنشطة جانبية وكل ما يتعلق مباشرة بالكود.
إليك ما يبدو عليه توزيع الوقت لأحد فرق التطوير لديناقد يكون لدى القارئ سؤال معقول: "كيف بنيت هذا المخطط؟" والآن سنحاول إعطاء إجابة. لم يتم أخذ البيانات من السقف ، ولكن بناءً على إحصائياتنا الداخلية. يقوم مطورونا بتتبع نشاطهم في جيرا. يتكون كل سجل عمل شخصي من أربعة أقسام: مراجعة الكود والمناقشات الفنية وتذاكر محددة و "كل شيء آخر". بفضل هذا التصنيف البسيط والشفاف ، قمنا ببناء تحليلات لمقدار الوقت الذي تقضيه الفرق في كل جانب من جوانب التطوير. إذا تعلق ثلث وقت العمل بالاجتماعات والمواقف والمراجعات - فكل شيء يقع ضمن المعدل الطبيعي. إذا تم إنفاق أكثر من 33٪ على هذه الأنشطة ، فسيواجه الفريق مشاكل ويجب معالجته.
يبدو أنه لا يوجد أي شيء وأن كل شيء منطقي ، لكن كيف يمكننا دمج إعادة بيع هذه القصة؟ تعلن "شهر إعادة بيع الأراضي" ويسجل على التنمية؟ ومع ذلك ، فإن أي منتج تجاري له جدوله الخاص ، وهو أمر غير مرغوب فيه للغاية للخروج منه. لا يزال إعادة بيع المباني يشبه المستنقع: إذا بدأت في التعامل معه ، فمن الصعب أن تتوقف ، فأنت تنجذب إلى هذا القاع. تعمل إعادة البناء على تحويل تركيز انتباه الفريق على نفسه ، ونحصل على بعض التحيز الوحشي نحو "ترتيب الأمور" في الكود المكتوب بالفعل بدلاً من نقل المشروع إلى مستقبل أكثر إشراقًا. فكيف لتوزيع الوقت؟
توفر الشريحة التالية بعض الإجابات:
الاحتفاظ بسجلات الوقت ، إنه مفيد للغايةتبقى الاجتماعات والمراجعات دون تغيير ، لأننا نعتقد أن هذه الأنشطة محسّنة قدر الإمكان وتم الاحتفاظ بها إلى الحد الأدنى المناسب (أولئك الذين عملوا في فرق استغرقت فيها الاجتماعات ومراجعات الكود 70٪ من الوقت سيؤكدون كلماتنا). لذلك ، نحن نأخذ الوقت الكافي لإعادة تشكيل الكود وإصلاح الأخطاء من التطوير. وهنا نطبق مرة أخرى نهج "الثلث والثلثين" ونقسم ساعات العمل التي تلقيناها إلى "إعادة بناء" و "أخطاء" ، والتي تفصل بوضوح بين هذه المفاهيم. يعد هذا النموذج قابلاً للتطبيق ويسمح لك بإيجاد الوقت لاستعادة النظام في المشروع ، على الأقل دون زيادة الدين التقني. إذا قضينا الكثير من ساعات "التطوير" ، فسيتوقف المشروع.
نحن نقترب من عملية إعادة البناء بشكل صحيح
لنفترض أنك قررت إعادة بناء ريفلاكتور بدلاً من إعادة كتابة مشروع من البداية. ولكن هنا لا يمكنك الاستيلاء على الأول والعازف كما هو الحال في الجيش ، "من هنا إلى الغداء". نظرًا لأن مواردنا محدودة وهدفنا هو إيقاف نمو الدين الفني (وتحقيق الحد الأمثل لحجمه) ، يجب أن نتعامل مع هذه المهمة بشكل معقول.
يبدو أن الحل الأفضل هو السماح لقائد الفريق أو مدير تطوير آخر بتحديد نطاق العمل وتعيين المهام والمضي في إعادة التسكين. ولكن هذا الخيار لديه عيب خطير. Timlid هو قائد فريقنا ، لكن مشاكل الموسيقيين المحليين ليست واضحة دائمًا للموصل. إذا كنت داعمًا لرأسية صلبة ونموذجًا يقرر فيه شخص واحد كيف ستحدث إعادة التوطين ، فأنت تجلس طوعًا في كاماز المحترقة ، التي تندفع مع الفرامل المكسورة من الجبل إلى الهاوية.
تُظهر تجربتنا أن إصدارًا قويًا من تطور الأحداث هو تعريف جماعي لمختلف اتجاهات إعادة البناء ، أي أنه يجب على المطورين المشاركة في تجميع قائمة من الأعمال المستقبلية. يمكن فقط للمؤلف المباشر للشفرة أن يعترف بصدق ما إذا كان هذا القسم مغلقًا بشكل كافٍ أو بسبب ضيق الوقت ، تم تكديس عكازات مختلفة هناك. بالإضافة إلى ذلك ، فإن المطورين هم في طليعة التكنولوجيا ، وهم قادرون على إجراء تقييم معقول لعناصر المشروع التي تحتاج إلى إعادة بناء وتلك التي يجب عدم لمسها.
بالنسبة لأنفسنا ، توصلنا إلى هذا النهج: يتذكر كل مطور المواقع النحيفة في المشروع ويكتب بطاقة حول ما يجب القيام به لتحسينه. على هذه البطاقات ، سيتم تحديد المهام. صحيح ، هناك فارق بسيط: بعد أول بطاقة تم استلامها بأسلوب "فعل الخير" دون أي سياق ، بدأنا نطالب بهذا السياق في شكل مضغوط.
نفس البطاقاتلكن تحديد مهمة لا يكفي لبدء تنفيذها. لذلك ، يجب تجميع قائمة مراجعة لكل بطاقة ، والتي تجيب على سلسلة من الأسئلة البسيطة مثل "هل نحن بحاجة إلى القيام بشيء متوازٍ؟" أو "هل هناك أي عوامل تمنعنا من إكمال هذه المهمة؟" بعد ملء قائمة التحقق هذه ، يتلقى المطور قائمة محددة من جميع المشاكل المحتملة وموانع التي تحتاج إلى حل في مرحلة العمل التحضيري.
خطوة إلزامية أخرى هي تحديد من هو في أي مناطق المشروع الذي يعرف أفضل. سيؤدي هذا إلى تحسين عملية إعادة التزويد وتزويد أعضاء الفريق بالمهام في تلك المناطق حيث يمكنهم إثبات أنفسهم على أفضل وجه. صحيح ، لقد واجهنا في يوم من الأيام موقفًا يفهمه عادة شخص واحد ونصف من جوانب المشروع ، لكن حتى هذه المشكلة يمكن حلها. للتخلص من فراغ المعلومات ، يجب على المطورين الذين ما زالوا "يتنقبون" في المنطقة التي يمر فيها بقية الفريق ، مشاركة معارفهم. يمكن أن يكون هذا توثيقًا أو نوعًا من العروض المصغرة أو حتى مقطع فيديو يحتوي على تفسيرات للرمز. من المهم نقل المعلومات إلى الزملاء والتأكد من وجود أقل عدد ممكن من البقع الداكنة.
وأخيرا ، يجب على الفريق الإجابة بوضوح على السؤال "ما هو حجم ديوننا الفنية؟" الدرجات مثل "C الصف" ، "مقبول" ، "خمسة من أصل عشرة" ، "يمكنك العيش" لم تعد تعمل. في السابق ، أجبنا على "خمسة من أصل عشرة" لسؤال مماثل من محطة الخدمة لأحد المشاريع ، وعندما قمنا بتحويل حجم الدين الفني إلى أرقام ، وصلنا إلى 650 ساعة. كان محرجا. فقط إجابة واضحة على هذا السؤال سوف تساعد على تقييم نطاق العمل المقبل بشكل معقول. هذا مهم أيضًا لأن المهام "التي لا نهاية لها" تقتل دوافع أعضاء الفريق ، وتثير غضب رجال الأعمال: يجب على كل من المطورين والإدارة أن يروا نقطة نهاية ملموسة يسعى الفريق إلى تحقيقها.
ترتيب الأولويات
بعد أن حددنا واجهة العمل ، نحتاج إلى الجمع بين إعادة البناء وإعادة التطوير. من الواضح ، لا يمكننا إيقاف نشر ميزة في أجزاء مختلفة من المشروع أو تخصيص بعض الوقت الخاص لهذا الحدث.
هذا هو المكان الذي يبدأ الجزء الأكثر صعوبة. يجب أن يحدد فريق التطوير بشكل معقول أي من لحظات التطوير أكثر أهمية وأي إعادة إحياء هو أمر مهم ، لا سيما عندما يتم نشر بعض الميزات في هذه المرحلة من الكود. ربما ، بعد إعادة التوطين ، سيكون المزيد من التطوير أسهل ، وفي بعض الحالات يمكننا إنهاء الميزة الخاصة بنا وعندها فقط refactor. نتواصل مع المنتج ونناقش القرار ونتفق على ما سيكون عليه الطلب. على سبيل المثال: "دعنا أولاً نصلح refactor - ليس فقط لأننا نشعر بذلك ، ولكن لأن المدة الإجمالية ستكون أقل في النهاية."
الشيء الأكثر أهمية هو عدم نسيان أن هدفنا هو تطوير منتج ، وعدم كتابة الكود المثالي من أجل الكود المثالي أو التخلص التام من الديون الفنية. يجب أن تكون التطوير كافية تمامًا في هذا الصدد: إذا أضرت إعادة بيع العقارات في الوقت الحالي بمهمة تطوير أعمالنا ، فسننتهي من كتابة جزء من التعليمات البرمجية الجديدة ، وعندها فقط نقوم بتصحيح الكود القديم. إذا كانت الظروف تشير إلى أنه سيكون من الأكثر ربحية للمشروع إعادة تشكيل هذا القسم (بغض النظر عن مدى ظهور واجهة العمل الرهيبة) ، لأن المزيد من العمل سيكون أكثر بساطة وأكثر متعة ، فإننا بحاجة إلى إعادة تشكيلها.
يتناسب هذا النهج بشكل سيء للغاية مع نموذج الإدارة الرأسية وفي بعض الأحيان ستواجه مواقف عندما تضطر إلى الدفاع عن قراراتك أمام العميل. ولكن على خلاف ذلك لا شيء.
ماذا نحصل نتيجة لذلك
من خلال النهج الموصوف ، نقوم بدمج عمليات إعادة هيكلة الممتلكات بشكل أساسي في التطوير الحالي ، ونقلل من حجم (أو نوقف النمو) الدين الفني ، وكل هذا دون أي خسائر كبيرة.
نعم ، من أجل إعادة البناء ، سيكون من الضروري تقليل الوقت اللازم لتطوير ميزات جديدة ، والتي ستزيد من الوقت ، لكن الخيار صغير: إما أن تقوم بإعادة التفاعل مع التطوير ، أو تأتي عاجلاً أم آجلاً في مثل هذه الكومة من العكازات والمشاكل والأخطاء التي سيكون من الأسهل إعادة كتابة المشروع من نقطة الصفر. لذلك إذا كنت تقدر عمل فريقك ، فلا يزال عليك التفكير في إعادة التنظيم بدلاً من إعادة الكتابة في المستقبل.
مواد مفيدة:1. تقرير أليكسي كاتاييف عن إعادة بناء المساكن: أمثلة عملية أكثر ، بالإضافة إلى قصة مذهلة للمدير جليب ، الذي لم يرغب في إعادة البناء ، حتى الآن ...
2.
لوائحنا لمناقشة المهام3.
لدينا مراجعة قائمة مراجعة التعليمات البرمجية