مرحبا يا هبر! اسمي مكسيم Lutzau ، في Promsvyazbank أعمل كمالك منتج. منذ ما يقرب من عام ، استمر تطوير بنك My Business Internet الجديد في إطار عمل Scrum ، وفي هذا الصدد ، تمكنت بالفعل من ملء المطبات. في هذا المنشور ، أود أن أتحدث عن أكثرها إيلامًا ، وكذلك عن الأدوات التي ساعدتنا في النهاية. حتى تتمكن من تجنب مثل هذه المشاكل.
يعارض بعض الموظفين بشكل أساسي التغيير
تم اعتماد إطار عمل سكروم في مصرفنا من أجل تسريع التطوير وتقليل TTM. عندما بدأ التنفيذ ، اتضح أن بعض الموظفين لم يكونوا مستعدين لذلك. لم يفهموا لماذا كان ذلك ضروريا وماذا سيعطي.
"كنا نعمل بشكل جيد ، لماذا نحتاج هذا؟" ، "لماذا لا نفعل ذلك بشكل مختلف؟" ، "من جاء ليعلمني هذا ، كيف يعرف أن هذا أفضل؟" - تساقطت أسئلة مماثلة باستمرار من جانبهم. وحتى عندما تلقى هؤلاء الموظفون إجابات ، فبعد فترة تكرر كل شيء مرة أخرى.
الحل الأكثر منطقية في هذه الحالة هو نقل الأشخاص إلى مشاريع أخرى. يجب أن يتم ذلك بالضرورة ، لأن الشخص الذي يشع سلبيًا يمكن أن يؤثر على الجميع. في تاريخنا ، هذا هو بالضبط ما شفاه جماعتنا - اختفى التوتر العام ، ويتم ضبط الجميع على إدراك المعلومات الجديدة.
لا يعتمد رد الفعل السلبي على التغييرات على العمر. كان عمر المطورين الذين تحدثنا عنهم أعلاه يزيد قليلاً عن 30 عامًا. في الوقت نفسه ، يعمل الشخص الذي يزيد عمره عن 50 عامًا بشكل مثالي في فريقنا - لم يكن لديه أي مشاكل مع سكروم.
من الصعب التفاعل مع الأشخاص الذين لا يعيشون مع سكروم.
يجب على أي منظمة التعاون مع الأشخاص الذين لا يعملون على سكروم. في حالتنا ، هذه فرق من مشاريع وإدارات أخرى. عادة ما يكون لديهم مراحل أطول من تنفيذ المشروع. بصراحة ، يعمل فقط مطورو RBS لدينا على Scrum حتى الآن.
قررنا ألا نفعل أي شيء مع هذه المشكلة - ألا ندخل في عمل الآخرين ببراعة. نطلب منهم فقط أن يفعلوا ما نحتاج إليه. عندما يعودون مع الحل ، نبدأ في ربط مهامهم. لا تعقد التفاعل إذا لم تنضج ثقافة الشركة بعد. بالطبع ، بعد التدريبات الصفرية ، هناك رغبة في تغيير كل شيء على الإطلاق ، ولكن من الأفضل التوقف في الوقت المناسب.
على الرغم من أننا لا نتسرع في الوحدات الأخرى ، إلا أنها تبدأ في العمل بشكل أسرع بالتعاون معنا. ندعو حراس الأمن إلى اجتماعاتنا وعروضنا التوضيحية ، والموافقة الآن على إصدار كامل الانتهاء يستغرق يومًا واحدًا فقط. قبل ذلك ، استغرق الأمر من أسبوع إلى أسبوعين.
"لن نكون في الوقت المناسب للسباق!"
بعد تنفيذ سكروم ، تحولنا من فترات إعداد التقارير الشهرية إلى سباقات لمدة أسبوعين. في البداية ، بسبب حجم المهام ، لم يرغبوا في ضغط المواعيد النهائية. لكن تعديل حجم العدو السريع إلى ما يجب القيام به خطأ كبير. على العكس من ذلك ، تحتاج إلى تعديل الخطط لمدة العدو. للقيام بذلك أمر بسيط للغاية - فقط قم بتحليل المهام. عندما يقل حجمها ، يكون من الأسهل ترتيبها وفقًا للخطة ، لإعطائها الأولوية. دفعات أصغر من التعليمات البرمجية أسرع للاختبار والتحقق والتفاوض مع حراس الأمن. بشكل عام ، أوصي بتقليل مدة العدو السريع ، إن أمكن ، من أسبوعين إلى أسبوع.
عندما لا يكون لدى أحد أعضاء الفريق الوقت للقيام بكل شيء مخطط له بحلول نهاية السباق ، فهناك رغبة طبيعية في تأجيل العرض التوضيحي - ليأتي إليه مسلحًا بالكامل. ولكن في هذه الحالة ، لا تزال بحاجة إلى الالتزام بالجدول الزمني. على أي حال ، يجدر الحديث عن نتائج العمل: ماذا فعلوا ، وماذا ولماذا لم يفعلوا ، وماذا فعلوا ليكونوا في الوقت المناسب. لذلك لا نهرب من المشاكل ، ولكن نلتقي معهم وجهاً لوجه ومن ثم يمكننا إيجاد الحلول معاً.
هذا النهج يزيد من الدافع ، بعد العروض التوضيحية المخططة غير الناجحة ، تنمو المسؤولية عن العمل. إذا كان المطورون قبل إعداد المنصة للعرض التجريبي في خمس دقائق ، فإنهم يقومون بذلك الآن في اليوم السابق للعرض التجريبي ، ثم يقومون بتلميع المطبات المتبقية لجعل كل شيء فائقًا.
"لماذا نحتاج إلى مواقف يومية؟"
في البداية ، كان الزملاء متشككين بشأن تشتيت انتباههم عن عملهم المعتاد في الاجتماعات الاحتياطية كل يوم. حتى إذا تم الاحتفاظ بها عبر الإنترنت وتتطلب 10 دقائق فقط.
في حل هذه المشكلة ، يساعد التشجيع الرمزي من شخص يجد لغة مشتركة مع الفريق. ذات مرة ، من أجل المتعة ، قلت أنني سأضع علامة على التقويم على أولئك الذين يأتون إلى الوقوف ، وبدأوا في وضع الإيجابيات. كانت النتيجة غير متوقعة ، وكان التأثير ملحوظًا بعد سباق واحد. عدم الرغبة في التعرض للقصف ، جاء المطورون أنفسهم إلى المواقف. حتى أنها تطورت إلى نكتنا المشتركة: الآن يهددون بوضع ناقص لي عندما لا يمكنني حضور أي اجتماع.
يعتقد الكثير من الناس أن اجتماعات scrum تستغرق الكثير من الوقت. يكفي أن نحسب هنا ما إذا كان الأمر كذلك بالفعل. لدينا ساعتان في الأسبوع من أصل 40. هذا ليس كثيرًا من أجل تنظيم العمل والبقاء على اطلاع على جميع الأشياء.
إذا كان الفريق بأكمله لا يريد الذهاب إلى اجتماعات الوقوف ، والاجتماعات نفسها ليست نشطة للغاية ، فهذه إشارة على أن العمل يسير بشكل خاطئ. كما لو تأخر الاجتماع لأكثر من 15-20 دقيقة. لا يجب أن تستغرق القصة عن أنشطته وخططه في الشخص أكثر من دقيقة أو دقيقتين.
هناك قاعدة أخرى مرتبطة بإدارة الوقت. إذا كانت مناقشة المهمة تستغرق أكثر من 30 دقيقة ، فإننا نوقفها. وهذا يعني أنه لم يكن لدينا الوقت لتطوير المهمة ، وأنها متحللة بشكل سيء ولا تزال تتطلب الوقت. هذا يستحق الانتباه إليه. لقد وضعنا حدًا زمنيًا قدره 30 دقيقة لأنفسنا - تحتاج كل شركة إلى إنشاء حاجز خاص بها.
تراكم غير مفهوم
يعتمد نجاح سكروم في المقام الأول على التخطيط الواضح. من الضروري تحديد عدد المهام التي يجب تقييمها ووصفها ، والتي يمكن تأجيلها في الوقت الحالي. لا تحاول تغطية كل شيء دفعة واحدة. يحتاج المطور إلى فهم ما سيفعله في السباقين التاليين. لفترات أطول ، تكفي فكرة تقريبية - في وقت لاحق ، كلما كانت التفاصيل أقل.
إدارة مجهرية غير مناسبة
ماذا يفعل المطورون اليوم؟ ماذا سيحدث غدا؟ يحدث أن المديرين يطرحون مثل هذه الأسئلة بانتظام. استطعنا أن نوضح لإدارتنا أنه يمكن العثور على جميع نقاط الاهتمام على السبورة أو من خلال الحضور اليومي. لا تقارير خاصة مع الجداول ومراقبة المهام في جيرا. تمكنا من الضغط على هذه الإدارة الجزئية لعقد اجتماعات أسبوعية مع الإدارة ، حيث أبلغ عن المهام المحددة التي يؤديها الفريق.
شيء تقريبا لم يكتب عنه
أخيرًا - هناك مشكلة واضحة لم أذكرها تقريبًا. لا حاجة لمحاولة الجمع بين سيد سكروم ومالك المنتج. هذا الأخير يقوم ببناء وحدة أعمال ، والعمل على تراكم ، وأداء مؤشرات الأداء الرئيسية. إنه مهتم بنجاح المنتج ويحاول الخوض في كل شيء - لذلك ، يبدأ في تحديد المواعيد ، ومناقشة بعض التفاصيل. بشكل عام ، فإنه يحمّل نفسه مع مجموعة من الوظائف ، وبسبب ذلك لم يعد هناك متسع من الوقت للتراكم.
حدث هذا لي. قمت بتنظيم اجتماعات ، ومواقف ، وحل مشاكل أعضاء الفريق. وبسبب هذا ، لم يتم عمل التراكم ، أي ببساطة لم يكن هناك وقت للنشاط الرئيسي. لقد وجدنا الآن مدير تطوير يتمتع بسلطة على الفريق وبدأ أيضًا في أداء وظائف أستاذ scrum ، حيث يتمتع بخبرة أكبر في العمل في هذا الإطار. الآن تمكنت من الابتعاد عن سكروم والتركيز بشكل كامل على مهام مالك المنتج ، الذي بدوره يجب أن يفكر في المتطلبات. بدون متطلبات جيدة ، لن يكون هناك منتج جيد. ونتيجة لذلك ، بدأ العمل المتراكم في التحسن ، جاء الزملاء ليفهموا كيف سنمضي قدمًا.
للوهلة الأولى ، يبدو سكروم بسيطًا جدًا ، ولكن لا يزال لديه العديد من المزالق. لقد عملنا على هذا الإطار لمدة عام تقريبًا ، ولكن الآن فقط بدأنا في تقييم قدراتنا بشكل أو بآخر ، بدأنا في زيادة سرعة التطور.