☀️ 🧡 😑 التخطيط بالساعة وتحسين فعالية الأحداث الأخرى ✌🏼 🛄 🗼

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

بالطبع ، الإنترنت مليء بالمقالات حول من وكيف نما هذا السكير في حد ذاته ، وما حدث وما لم يفعل. أنا لا أتظاهر بأنني فريد ولم أقرأ كل شيء ، لأن هناك الكثير من كتاب هذه المقالات أكثر من وقت الفراغ. ومع ذلك ، أود أن أقول كيف قمنا في فريق تطوير Android ببناء (وما زلنا نبني) العملية ، عمليًا دون إضاعة الوقت في الاجتماعات والمناقشات. حدث ذلك فقط لأن وقتي (أنا PO) ووقت الفريق محدود للغاية ، وأنا أسعى جاهدين للقيام بكل شيء حتى لا تشارك في العمليات من أجل العمليات وفي نفس الوقت للحفاظ على مستوى عالي من الأداء والشفافية.

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

أنا مدير المنتج لفريق Android في Wrike. بالإضافة إلى ذلك ، كان لي دور مشرف لسيد الصفن.

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

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

PBR

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

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

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

أثبت هذا النهج نفسه للأسباب التالية:

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

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

"سنكتشف الأمر على الفور" - عادة ما تكون نهاية هذه المهمة غير مرئية حتى تكتمل تقريبًا.
« » — : « , ». , .
« » — , , .

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

ريترو

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

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

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

التخطيط

الجزء المفضل لدي من سكروم. يعجبني لسببين:

انه ممتع؛
عمليا لا يتطلب مشاركتي.

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

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

اليومي

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

مجموع

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

بالنسبة لي ، في النهاية ، هناك ثلاثة مؤشرات فقط منطقية: مستوى رضا الفريق بحيث لا يحترق الرجال ، وجودة المنتج وسرعة المهام.

وهذه المؤشرات في فريقنا عالية جدًا:

الجودة: 2-3 أخطاء بعد الإصدار (ولدينا إصدارات كبيرة) ؛
السرعة: فريقنا المكون من خمسة مطورين ، واثنان لضمان الجودة وواحد لتجربة المستخدم يدعم التغييرات التي ينشئها عشرين فريق ويب ؛
الرضا: خلال خمس سنوات من عملي في Wrike ، غادر الشركة مطور واحد و QA واحد.

الشربات على الكعكة

القليل من الرياضيات. لسباق لمدة أسبوعين اتضح:

10 يوميًا لمدة 15 دقيقة ؛
± 2 منتدى في الساعة ؛
التخطيط ساعة واحدة ؛
رجعي ساعة واحدة.

الإجمالي: 4 ساعات و 30 دقيقة ± 2 ساعة من 80 ساعة في سباق أسبوعين.

من الواضح أن هذا الرقم يجب أن يتم ضربه في عدد الأشخاص في الفريق لفهم عدد ساعات عمل الشخص التي يكلفكها الحدث. مؤشر بلادي 5.6٪ ± 2.5٪ مع حجم فريق من 9 أشخاص. كلما كبر الفريق ، زادت هذه القيمة. ولكن دعونا لا ننسى أن فريق سكروم لديه الأحجام الموصى بها ، مما يعني أن مؤشر الوقت الذي يقضيه في أحداث الفريق له حد معقول أيضًا.

بشكل عام ، حتى الآن. سيكون من المثالي إذا قمت بمشاركة الأرقام: كم من الوقت لديك في سكروم الحدث. حسنًا ، لجعل المقالة أكثر قيمة ، دعنا نناقش الفوائد والأضرار التي يمكن أن تحققها مثل هذه التحسينات في رأيك.

التخطيط بالساعة وتحسين فعالية الأحداث الأخرى

PBR

ريترو

التخطيط

اليومي

مجموع

الشربات على الكعكة

More articles: