كيف يمكنك تنظيم سباق التنمية؟[مغلق]

Question

لذا، لدي مجموعة متراكمة من الميزات ونحن على وشك البدء في مشروع كبير.أنا أعمل على تحديد هيكل سباقات السرعة لدينا وأنا مهتم بتعليقات المجتمعات.

ما أفكر فيه هو:

• التخطيط لسباق السرعة ليوم واحد
  • املأ الأعمال المتراكمة واكتشف ما سيفعله كل مطور بعد هذا السباق
• ثلاثة أسابيع من التطوير
  • يذهب!يذهب!يذهب!
• اجتماع الوقوف اليومي
  • تحقق لمعرفة ما إذا كان أي شخص يحتاج إلى المساعدة أو يشعر بأنه خارج المسار
• يومين من مراجعة العدو
  • تتم مراجعات الكود هنا، والعروض التقديمية لأصحاب المصلحة
• سباق السرعة ليوم واحد بأثر رجعي
  • ماذا فعلنا في السباق الأخير؟كيف يمكننا أن نفعل ما هو أفضل في المرة القادمة؟

يجب أن تنتهي سباقات السرعة دائمًا يوم الثلاثاء (لتجنب الكثير من التوتر في عطلة نهاية الأسبوع).

أي شيء آخر؟من الواضح أن هناك ما هو أكثر رشاقة من هذا.أريد أن أقدم للفريق مخططًا بسيطًا لكيفية العمل عندما نبدأ هذا المشروع.

Answer 1

سأفكر في تجربة سباقات السرعة التي تكون أقصر من شهر واحد.

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

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

بالطبع كانت هذه مجرد تجربتي - في تطوير تطبيقات الويب في الغالب مع فرق صغيرة (4-12) شخصًا.قد تختلف تجربتك.

ومع ذلك - سأحاول بالتأكيد تجربة سباقات السرعة القصيرة.مثل عمليات بناء التكامل - تصبح الكثير من الأشياء أسهل إذا قمت بها كثيرًا.

Answer 2

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

اطلب الطعام والمشروبات للفريق عندما يكونون في "المنطقة".

قم بإلغاء جميع الاجتماعات الأخرى للأيام التي تسبق جلسة التخطيط وأيام المراجعة وبعدها.

Answer 3

• تأكد من أن "الوقوف" يظل وقوفًا.من السهل جدًا الدخول في اجتماعات أطول فأطول.
• قد يكون يوم واحد من التخطيط للسباق وثلاثة أيام في النهاية أكثر من اللازم.جدولة فقط الكثير من الوقت الذي تحتاجه.
• +1 لفكرة التكرارات الأقصر.على المستوى الشخصي، نجحت أربع تكرارات مدتها أسبوع واحد في سباق السرعة بشكل جيد.الناس بارعون في تقدير المهام قصيرة المدى؛الماضي أنه يصبح المزيد والمزيد من التخمين.

Answer 4

يبدو وكأنه نهج جيد.أنا أؤيد ما قاله Adrianh وJedidja حول التكرارات الأقصر المحتملة.أنا أحب أسبوعًا واحدًا بنفسي.بالإضافة إلى التقدير الأفضل، فإنه يحافظ أيضًا على فكرة "برنامج العمل" في دورة أقصر بكثير.

بعض الأسئلة:

لماذا يتم ترك مراجعات الكود حتى النهاية؟إما أن تقوم بإقران البرنامج، أو قم بمراجعاتك أثناء تقدمك.

هل تعني 3 أسابيع من التطوير "التطوير والاختبار والتوثيق والتثبيت وما إلى ذلك"؟أي.كل ما عليك القيام به حقا؟

Answer 5

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

ننهي أيضًا سباقاتنا السريعة يوم الثلاثاء ونبدأ يوم الخميس ونغادر يوم الأربعاء لإنهاء الأمور السائبة ومعالجة الديون الفنية التي نشأت أثناء السباق.

Answer 6

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

Answer 7

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

أفكار مثل "إيقاف تشغيل الهواتف المحمولة، وإيقاف تشغيل تطبيقات المراسلة الفورية، وما إلى ذلك أثناء البرمجة" كلها أفكار سيئة.عندما تقوم بتعيين فريقك، فإنك تقوم بتعيينهم بثقة بأنهم يعرفون كيفية القيام بعملهم بشكل صحيح.إذا قمت بتعيينهم بهذا الفهم، فلماذا تريد تقييد قدرتهم على إنجاز عملهم بأفضل طريقة يعرفونها؟إذا كنت تستخدم SCRUM، فسيكون كل مطور قد اختار العمل الذي يشعر أنه قادر على القيام به، ومهمتك كـ Scrum-Master هي إزالة العقبات، وليس إنشائها.

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

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