من الناحية العملية ، غالبًا ما نواجه حقيقة أن مدير المشروع يريد تسريع عملية التطوير - فهو غير راضٍ عن سرعة تقديم الوظائف الجديدة. عادة ، يحتاج هؤلاء العملاء إلى منتجات معقدة مثل نظام إدارة المستشفيات ، ونظام تداول الصرف ، والأنظمة المصرفية ، والخدمات المصرفية.
في مثل هذه الحالات ، يمكنك الاتصال بفريق جديد من المتخصصين ، أو إنشاء عمليات في فريق موجود ، أو الجمع بينهما. النظر في إيجابيات وسلبيات كل نهج. إبداء تحفظ على الفور أن المقالة تناقش تطوير المشاريع الكبيرة والمعقدة (أكثر من 10000 ساعة).
لماذا لا يمكنك الاتصال المتخصصين الجدد على الفور
غالبًا ما يكون الخيار الأسهل والأكثر وضوحًا لزيادة سرعة التطوير هو ربط متخصصين جدد أو فريق. يبدو لمدير المشروع أن هذا يمكن أن يسرع من سرعة تقديم قيمة الأعمال للمستخدمين النهائيين. من الناحية العملية ، ليس هذا هو الحال دائمًا ، خاصة عندما تتطلب العمليات في المشروع المعالجة. نعطي مثالا واحدا من ممارستنا.
كان من الضروري ربط فريقين بمشروع تطوير قائم. تم تطوير المشروع لأكثر من 4 سنوات ويحتوي على عدد كبير من الأنظمة الفرعية (أكثر من 20) مع آلياتها وخدماتها المشتركة. تطلب الانحدار الكامل مشاركة 5-7 مهندسين لضمان الجودة وحوالي 4-6 أيام عمل. عند دخول المشروع وترك الفرق إلى المستوى المطلوب لحل المشكلات ، واجهوا الصعوبات التالية:
- جزء واحد من شفرة المصدر للنظام كان تحت سيطرة نظام التحكم في إصدار svn ، والباب الآخر. كانت SVN تحظى بشعبية كبيرة في السابق ، ومع ذلك ، بالنسبة للمشاريع الجماعية الكبيرة والتغييرات المتزامنة المتكررة ، فهي ليست مناسبة. لذلك ، قبل التبديل إلى git ، تم إنفاق جزء من الوقت على عمليات الدمج وتحرير التعارضات والعمليات الأخرى المتعلقة بالفروع في svn.
- كان هناك تعليمات قديمة لنشر البيئة ، لذلك جمعت الفرق جميع أنواع المزالق من هذا النظام ، ولم يتمكنوا من بدء المهام الأولى إلا بعد 3-4 أيام.
- كان المحللون الرئيسيون والخبراء الفنيون مشغولين في إعداد الإصدار ، لذلك كان من المستحيل الحصول بسرعة على معلومات توضيحية حول المهام الجديدة. كان إعداد المهمة على مستوى عالٍ جدًا. أدى ذلك إلى تباطؤ كبير في تنفيذ المهام.
- كان سير المهام صعبًا ، في البداية "تعثرت" الفرق حول كيفية التعامل مع المهمة طوال دورة حياتها.
- في البداية ، أراد العميل أن ينجح فقط بجهود مهندسي ضمان الجودة ، لكنهم لم يتمكنوا من التحقق بشكل كامل وفوري من الوظائف الجديدة لفرق التطوير المرتبطة ، بسبب الحمل الثقيل. لذلك ، كان علي العمل مع الوقت الإضافي.
- تم إجراء مراجعة الكود وفقًا للمبادئ والمعايير التي وضعها المشروع. لم يتم توثيق المعايير. لذلك ، تم قضاء وقت إضافي في تصحيح التعليقات.
نتيجة الفروق الدقيقة المذكورة أعلاه هي:
- تكاليف الوقت الإضافية التي يمكن إنفاقها على حل مشاكل العمل
- التطور البطيء للنظام بأكمله
- أو العمل الإضافي.
فكر في كيفية تجنب هذا الموقف.
تحليل العملية
قبل ربط المتخصصين الجدد ، من المفيد معرفة كيفية ترتيب عمل الفريق - من الضروري العثور على الاختناقات وإزالتها. عادة ، يتعامل رئيس الوزراء مع هذه المشكلة ، حيث إنه مسؤول عن المشروع ، ويريد أن ينفق طاقة أقل على عمليات التتبع.
إزالة الاختناقات يدفع المشروع إلى الأمام. على سبيل المثال ، يتم تقليل الوقت المطلوب لدخول أخصائي جديد أو فريق من الأخصائيين ، وزيادة مشاركة الفريق في المشروع ، وتقل تكلفة الساعة بسبب التنفيذ الصحيح للمهام في المرة الأولى. إذا تمت إزالة جميع الاختناقات ، سيحصل مدير المشروع على مثل هذه الزيادة السريعة في سرعة التطوير كما تسمح الممارسة الحالية وسياق المشروع. بشكل عام ، إنه جيد للجميع.
يمكن تحليل الاختناقات من جانبين: من الإدارة العليا / الخبير ومن الفريق. سنقوم بتحليل كل خيار على حدة.
خبراء خارجيين. في هذا النهج ، يتم تحليل عملية العمل إما من قبل فريق خارجي من الخبراء الخارجيين ، أو من قبل مدير المشروع مع قائد الفريق. مع هذا الأخير ، ليس حقيقة أنه سيظهر - من المهم أن يتمكنوا من التخلص من جميع الفروق الدقيقة في المشروع ، وإلا سيكون التحليل لا معنى له.
شرط مهم هو دعم إدارة المشروع والاستعداد للتغيير.
وفقا لذلك ، يغرق الخبير في المشروع ويحلل بالتفصيل الوثائق ، شفرة المصدر ، هيكل قاعدة البيانات ، عملية الإنتاج (من التحليلات إلى الإصدار). يبدو العمل المرحلي كما يلي:
- تعتبر سلسلة العمل بأكملها في المشروع من البداية إلى النهاية. يتم قياس وقت كل عملية.
- تم بناء مخطط جانت. ينظر الخبير إلى العمليات التي تجري بالتوازي ، أي واحدة تلو الأخرى.
- يفكر الخبير في كيفية جعل كل عملية أكثر إنتاجية وأقل تكلفة. كقاعدة عامة ، يفهم الخبير بشكل حدسي الأماكن التي تنشأ فيها أكبر الصعوبات ويبدأ في تدويرها لتحديث محتمل.
مزايا هذا النهج:
- يتم تحليل العمل من قبل شخص غير مشارك في المشروع. لديه رؤية مباشرة للعمليات ، لذلك ، يمكنه العثور على تلك المشاكل غير المرئية لأعضاء الفريق.
- الخبير ، كسلطة ، قادر على إقناع فريق لقبول التغييرات في العمليات. لا تسعى الفرق التي تعمل في مشروع لفترة طويلة إلى الابتكار. بالنسبة لهم ، هذا كثير من الضغط ، حيث سيتعين عليهم إعادة التعلم مرة أخرى. علاوة على ذلك ، فإن رد الفعل هذا يذهب حتى إلى تلك التغييرات التي ستساعد على العمل بكفاءة أكبر.
- تنفيذ سريع للحلول - من 2 إلى 15 يومًا. كل هذا يتوقف على التغيير والبيروقراطية العالمية داخل المنظمة.
- يأخذ فريق المشروع خبرة خبراء الطرف الثالث. في المستقبل ، سيساعد هذا على تكوين العمليات بشكل مستقل.
السلبيات:
- يحتاج الخبراء لقضاء الكثير من الوقت لفهم التعقيدات. يمكن للفريق دراسة تاريخ المشروع في يوم واحد ، بينما يحتاج الخبير إلى أسبوع ونصف على الأقل.
ما يجب القيام به حيال ذلك : حدد أهداف التحليل مع مدير المشروع / قائد الفريق. امنح الخبير جميع المشاريع "التمهيدية" ، ولا تخفي التفاصيل.
إذا كان العميل مخلصًا لدرجة أنه مستعد لتحليل المشروع بشكل متكرر ، فأنت بحاجة إلى استغلال الفرصة والموافقة على هذه الشروط. بعد ذلك ، سيكون من الممكن تعديل اتجاه التحليل بعد كل تكرار ، مع التركيز فقط على المطلوب. - قد لا يوافق بعض أعضاء الفريق على القرار. في وقت لاحق ، يمكنهم تخريب المشروع ، وتنفيذ الاتفاقية بشكل سيئ ، وهذا يؤثر على الحالة العامة للفريق.
ماذا تفعل حيال ذلك : ناقش كل قرار مع الفريق ، ولا تضعه قبل الوقائع.
الخيار المثالي: يقوم الخبير بتحليل العمليات بشكل مستقل ، ثم يناقشها مع الأشخاص الرئيسيين في المشروع. إذا كانت هناك تناقضات ، يناقشونها. سيؤدي هذا إلى تراكم الكثير من الأشخاص المخلصين للتغييرات التي ستؤثر على أعضاء الفريق الآخرين. سيكون من الممكن إقناع المتشككين المتحمسين.
من الفريق . يمكن أن يسمى هذا النهج بأثر رجعي ، وهو جزء لا يتجزأ من سكروم. تبدو العملية كما يلي:
- فريق المشروع بأكمله سيحضر
- يتولى أحد المشاركين دور الميسر (سيد الصفن). يتأكد من أن المحادثة تسير بطريقة بناءة.
- يناقش الفريق أساليبهم في العمل. تعتبر جميع الجوانب: العمليات ، والتشفير ، وتحديد الأهداف ، وما إلى ذلك. ثم يتم تمييز الإيجابيات والسلبيات.
- في تصويت عام ، يوافقون على التغييرات: يجب إصلاح الإيجابيات ، وإزالة السلبيات.
- بعد 3-4 أسابيع ، تتكرر العملية. ينظر الفريق إلى النتائج ، وإذا كان الجميع سعداء بكل شيء ، فإن العمل مستمر.
شروط مهمة:
- الدعم الإداري لأي تغييرات وابتكارات.
- تماسك الفريق والتركيز على التحسين.
إذا كانت ثقافة الشركة لا تشجع على المبادرة والابتكار ، فإن الاسترجاع ليس أفضل طريقة لإعادة تصميم العمليات. لن يتجاوز أعضاء الفريق "مستنقعهم".
مزايا النهج:
- مشاركة كل مشارك في مناقشة المشروع.
- القدرة على تحديد جميع الجوانب الإيجابية للمشروع ، وإذا لزم الأمر ، قم بتشكيلها في نموذج معين (أفضل الممارسات).
- يتبادل أعضاء الفريق الخبرات مع بعضهم البعض.
- حل تدريجي للمشكلات ، بدءًا من تلك التي تبطئ الفريق والمشروع أكثر ، وتنتهي بتحسينات صغيرة.
السلبيات:
- هناك خطر أن يتم حل المشاكل الصغيرة فقط ، وستبقى جميع المشاكل الرئيسية دون تغيير.
ما يجب القيام به حيال ذلك : يجب أن يؤثر رئيس الوزراء وقائد الفريق والميسر على رأيهم في الفريق من خلال السلطة. مهمتهم هي لفت الانتباه إلى المشاكل الهامة في مرحلة المناقشة. - بالنسبة للتغييرات الرئيسية التي تتطلب الكثير من العمل ، يلزم وقت إضافي للتنسيق مع الإدارة. ومع ذلك ، ليس حقيقة أن الإدارة ستوافق على الابتكارات.
ماذا تفعل حيال ذلك : الدفاع عن وجهة نظرك قبل أن تكون القيادة هي الحل الوحيد. - إذا لم يكن لدى الفريق تدريب مستمر (مؤتمرات ، تبادل الخبرات ، تدريبات) ، فمن المرجح أن تكون القرارات التي تم التوصل إليها قديمة وغير فعالة.
ماذا تفعل به : تبادل الخبرات باستمرار. المشاركة في المؤتمرات والاجتماعات ذات الصلة والتدريب الداخلي. إذا كنا نتحدث عن شركة كبيرة ، فإن الخيار الجيد هو الأيام التجريبية. في مثل هذه الأحداث ، تظهر الفرق النتائج التي حققوها في عملهم.
في معظم الحالات ، يمكنك الحصول عليها من خلال تكييف وتحسين العمليات الموضحة أعلاه. حتى إذا كان من الواضح في البداية أنه من الممكن حقًا إكمال المشروع في الوقت المحدد فقط من خلال جذب متخصصين / فرق جديدة ، فإننا نوصي بشدة بتجربة الخطوات المذكورة أعلاه.
إذا اعتقد مدير المشروع ، بعد إزالة الاختناقات ، أن السعة لم تصل إلى المستوى المطلوب ، يمكنك حينئذٍ توصيل فرق جديدة.
تجهيز البنية التحتية للفرق الجديدة
في هذه المرحلة ، يجدر تنفيذ الأعمال التحضيرية التي ستقلل من مدة وتكلفة التطوير ، وتساعد على إنقاذ الخلايا العصبية للمطورين. دعونا ننظر في الشروط التي يجب أن تكون:
- يجب تفصيل مهام الفريق الجديد بالتفصيل. يمكنك بدء كل منها دون انتظار - لا يوجد اعتماد على المهام الحالية أو المستقبلية. تم تحديد مجالات مسؤولية كل فريق.
إذا لم يكن هذا هو الحال ، فإن معظم الفريق الجديد سيقف خاملاً أو يشارك في مهام ثانوية لها أقل تأثير على قيمة المنتج. - بنية المشروع "صحيحة" ، أي مقسمة إلى وحدات ، أنظمة فرعية ، مكونات مشتركة.
إذا لم يحدث ذلك ، فسوف يفشل توصيل أمر جديد. سيعمل المطورون تحت سيطرة قائد الفريق الحالي ، ولكن يمكن للشخص إدارة ما لا يزيد عن 7-9 أشخاص بشكل فعال. سيتم تمزيق Timlid ، وسينتظر بعض أعضاء الفريق الخمول حتى يتم تكليفهم بالمهام.
إذا لم يكن من الممكن عزل الأجزاء المعزولة من رمز المشروع ، ولكنك بحاجة إلى المضي قدمًا ، فيمكنك محاولة تجاوز هذا القيد. من الضروري تقسيم المشروع إلى عدة أجزاء من خلال إعادة الهيكلة.
خيار آخر - بعد غمر شخصين أو ثلاثة في المشروع ، لإعطاء الفريق الجديد المزيد والمزيد من وظائف الأعمال الكبيرة. لذا ستقوم الفرق بتطوير المشروع بمعزل عن بعضها البعض ، وبسبب قيادة الفريق الجديد (الشخص المنغمس في الخفايا) سيقلل العبء على قائد الفريق الرئيسي. - يتم وصف عمليات العمل في المشروع بالتفصيل. على سبيل المثال ، هناك مهمة سير العمل ، وتظهر المهمة ليتم تنفيذها في نظام التحكم في الإصدار (تظهر الممارسة أنه ليس لدى الجميع GitFlow قياسي) ، يتم وصف التفاعل بين المشاركين في المشروع.
إذا لم يحدث ذلك ، فسيتم إنشاء الفوضى في المشروع. في هذه الحالة ، سيتعامل مدير المشروع فقط مع إدارة الطوارئ "اليدوية". - المكونات والوحدات المشتركة لديها وثائق ذات صلة ومفهومة. هناك اختبارات الوحدة والتكامل للأجزاء الرئيسية. هناك وصف واضح لهندسة المشروع بأكمله ، والآليات العامة ، بالإضافة إلى تعليمات حول كيفية تطبيقها. إذا لم يكن ما سبق موجودًا ، فمن الضروري إضافة مهام مماثلة إلى مجموعة الديون الفنية لتصحيح الوضع.
إذا لم يكن هذا هو الحال ، فإن خطر القيام بعمل مزدوج يزداد. ستتم كتابة كود مصدر ضعيف أو مكرر. في المستقبل ، سيؤدي هذا إلى دعم أكثر تكلفة للمشروع. كقاعدة ، يشير ربط فريق جديد إلى إمكانية الاتصال بالعديد من الفرق الأخرى. وبناءً على ذلك ، سيتم حساب تكاليف الوقت بواسطة مضاعف عدد الفرق. - هناك قواعد ثابتة لكتابة التعليمات البرمجية - رمز الاتفاقية ، ونصوص لتحديث بنية قاعدة البيانات - الترحيل ، والمبادئ العامة لمراجعة التعليمات البرمجية الإلزامية. على الرغم من التشابه القوي ، بالتأكيد لكل مشروع خصائصه الخاصة.
إذا لم يكن الأمر كذلك ، فسيزداد تعقيد وتكلفة دعم المشروع أكثر من مرة.
تسمح لك الشروط المذكورة أعلاه بتوصيل فرق جديدة بشكل أكثر فعالية. يتم تقليل الوقت الذي يستغرقه فريق لإدخال مشروع بشكل ملحوظ. يحدث الشيء نفسه مع تكاليف العمالة لدعم وتطوير المشروع.
كيف قمنا بتوصيل فريق إضافي بالمشروع
كانت لدينا حالة عندما كان المشروع بحاجة ماسة لتسريع عملية التطوير. تم ترك 2-3 أشهر حتى تم تشغيل النسخة الرئيسية التالية في التشغيل التجاري. كان المشروع نفسه نظامًا معقدًا تم تطويره بواسطة فريق واحد لمدة 3-4 سنوات.
بادئ ذي بدء ، لقد انغمسنا في سياق المشروع نفسه. والنتيجة هي الصورة التالية لاختناقات المشروع:
- لا توجد معلومات دقيقة واحدة حول كيفية تنفيذ الميزات. قائمة المهام والأخطاء والتحسينات قديمة.
- لا يوجد تكامل مستمر ، ويتم التطوير في فرعين.
- لم يتم تصحيح عملية اختبار المنتج. على سبيل المثال ، يمكن لمهندسي ضمان الجودة العثور على أخطاء تم إصلاحها بالفعل ، مما يؤدي إلى تكاليف عمل إضافية.
- كانت قاعدة حالات الاختبار في مهدها. بدأ مهندسو ضمان الجودة في كتابة الحالات لأنفسهم. وبسبب هذا ، لا يمكن لأحد تقديم تقييم معين لجودة المنتج والمخاطر المحتملة عند إصدار نسخة جديدة.
- لم يتم توثيق عملية العمل ، من الإنتاج إلى موافقة العميل. كان من المستحيل توقع التكوين الدقيق لوظائف التحرير ، بالإضافة إلى نقاط أخرى أقل أهمية.
بعد التحليل ، وضعنا خطة للقضاء على النقاط المذكورة أعلاه. بالطبع ، لم يوافق الفريق على الفور على التغييرات ، ولكن بدعم من القيادة ووضع مواعيد نهائية واضحة ، تمكنا من إقناع كل عضو في الفريق.
نسقنا إجراءاتنا مع الأشخاص الرئيسيين في المشروع: رئيس الوزراء ، قائد الفريق ، المحلل الرائد. يشكل هؤلاء الأشخاص الثلاثة معًا مركزًا واحدًا لفريق إدارة العملاء. كما أنها تعزز الحلول وترصد تنفيذها عمليا. بدون مثل هذا الفريق الإداري ، من المستحيل تنسيق إجراءات أكثر من ثلاثة فرق.
نتيجة لذلك ، تم تنفيذ / تحسين العمليات التالية:
- قمنا ببناء اتصالات بين جميع أعضاء فريق المنتج - المطورين والمحللين وأخصائيي الاختبار.
- قاموا بتوثيق الوظائف الحرجة والمعقدة لإجراء اختبار أكثر شفافية ، وإزالة العيوب ، وحل النزاعات ، وتخطيط العمل اللاحق.
- عمليات تطوير محسنة. اعتمده مشروع WorkFlow و GitFlow. لقد ساعدوا في تكوين التكامل المستمر وإجراء الاختبارات التلقائية في الوضع التلقائي.
- ضاعفنا سرعة تجميع مقاعد الاختبار.
- نظمت عملية الاختبار الصحيح. اختبار الانحدار الذي تم تنفيذه في نهاية كل تكرار.
- قدم عملية تخطيط التكرار.
- إجراء اختبار الحمل.
بناءً على نتائج التكرار الأول ، قمنا بإعداد البنية التحتية لربط فريق جديد. بالتوازي مع هذا ، انضم اثنان من مطورينا إلى الفريق الحالي للتعمق في قاعدة التعليمات البرمجية. ثم أصبح أحدهم قائد الفريق الجديد. في التكرار الثاني حقق الفريقان النتائج التالية:
- التكليف بعد 3 أشهر.
- تم إصلاح 70٪ من الأخطاء
- نفذت أربع ميزات خطيرة
- محسّن وزاد بسرعة 8 أضعاف سرعة تحميل بعض الصفحات
- تلقي معلومات دقيقة حول جودة المنتج بأكمله
- تكرارات خارطة الطريق المبنية
أعتقد أن من أهم إنجازات هذا المشروع فرحة العميل. لقد مثل بشفافية حالة المشروع في أي وقت ، وتم الوفاء بالالتزامات تجاه العمل بالكامل وفي الوقت المحدد.
الخلاصة
هناك طريقتان رئيسيتان لزيادة سرعة تطوير المشروع: إزالة الاختناقات وزيادة القدرات الإنتاجية. في الحالة الأولى ، يمكنك الحصول على زيادة 30-40٪ في سرعة التطوير ، في الثانية 70-80٪. لا تعطي الأوامر الإضافية زيادة مضاعفة في الإنتاجية ، حيث يتم قضاء المزيد من الوقت في التفاعل بين عدة فرق.
عوامل النجاح الرئيسية لتوسيع فرق التطوير هي:
- العمل التحضيري
- العمليات القائمة
- قائد أو عضو في فريق المشروع الذي من شأنه تعزيز أنشطة الفرق والإشراف عليها ،
- مركز واحد للتحكم في القيادة.
تعمل ثلاث فرق حاليًا على المشروع الذي وصفناه سابقًا (فريق قديم واثنان جديدان). زاد عدد المهام المنفذة بنسبة
1.9 مرة .