متى يعتبر التكرار الرشيق كاملًا؟ [مغلق

Question

أنا أعمل على فريق يستكشف إمكانية تبني ممارسات التنمية الرشيقة.

أحد الأسئلة التي نواجهها هو تحديد متى يجب أن يكتمل التكرار (Sprint).

دعنا نقول أننا قمنا بتعريفنا المتراكمة الميزات ، وأنتجنا تقديرات نقاط القصة لهم ، وقررنا أن أول سباق لمدة 30 يومًا سيتضمن الميزات A و B و D و F. ماذا يجب أن تفعل إذا كنت فيك " إعادة الوصول إلى نهاية العدو وستكملت A و D و F - ولكن B كاملة بنسبة 80 ٪ فقط. هل يجب عليك:

1. أكمل العدو في الوقت المحدد ولكن استبعاد الميزة B (تأجيل العمل المتبقي إلى العدو المستقبلي)

2. قم بتمديد العدو في الوقت اللازم لإكمال الميزة B ولكن لا تبدأ العدو التالي.

3. قم بتمديد العدو في الوقت اللازم لإكمال الميزة B والبدء في العمل على العدو التالي.

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

المشكلة التي أراها مع الخيار 1 هي أن الفريق لا يقدم ما التزمت به. في بعض الحالات ، قد لا تتمكن من استبعاد الميزة B دون جعل الإصدار بالكامل عديم الفائدة (أو على الأقل أقل قيمة). قد يجعل من الصعب توجيه اتجاه العدو التالي بدون ميزة ب.

تكمن المشكلة في الخيار 2 في أن بعض أعضاء الفريق قد يكونون خاملين لفترة زمنية كبيرة - والتي تتناول الإنتاجية الشاملة. قد تتمكن من إضافة المزيد من اختبارات الوحدة ، أو تلميع الميزات ، لكنها لا تضيف قيمة نسبية. من الصعب أيضًا توضيح الإدارة للسياسة عن سبب كون معظم فريقك خاملاً.

يبدو أن الخيار 3 يعارض روح Agile - فأنت تعرض العدو التالي للخطر من خلال عدم السماح لنتائج واحد سابق بتوجيه التكرار التالي للتنمية.

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

Answer 1

الخيار 1 بالطبع. لك ● السرعة للتكرار التالي سيكون أقل ، لأنه يعتمد على الطقس الأمس, ، وبالتالي فإن التكرار التالي لديك فرصة أفضل للكاملة.

في Scrum أنت صندوق الوقت. وأنت فقط تقدم الميزات التي تعمل.

في ال تخطيط العدو لقد قدمت تقديرًا لما يمكنك تقديمه. يتعين على العميل قبول مستوى معين من عدم اليقين في التقدير ، أو أن يكون مستعدًا للموارد في الفريق.

إذا فاتتك التكرار التالي مرة أخرى ، فانتقل إلى طول التكرار الأقصر ، وتأكد من أن حجم الميزات الفردية أصغر.

Answer 2

عادة ما يمكنك القيام بالخيار 1 - إنهاء العدو. استخدم العمل المكتمل ، دع العمل غير المكتمل ينعكس في سرعة المشروع - لذلك يأخذ التخطيط المستقبلي في الاعتبار الصعوبات التي واجهتها.

نعم ، يعني الخيار 1 أننا لم ننهي ما التزمنا به - ولكن إذا كان هذا هو ما حدث ، فمن الأفضل أن نعترف بذلك وتعلم التعامل بشكل أفضل في المرة القادمة من إخفاءه. تحدث الأشياء السيئة للجميع - الشيء الحرج هو كيف نتحسن من حيث نحن.

يمكنك القيام بالخيار 2 - متابعة الانتهاء من العمل المتميز عن طريق تمديد العدو. فقط افعل ذلك إذا كان العمل أولوية عالية للعميل واختاروا صراحة القيام بذلك. إن تمديد طول العدو يجعلها أكثر صعوبة في المقارنة مع بعضها البعض - لأنها أطوال مختلفة.

بالتأكيد لا تدع عدوًا واحدًا يندمج في التالي - إما أنك تقوم بتوسيع العدو القديم ، أو أنك تبدأ جديد تمامًا. إذا سمحت لسباقين يندمجان في بعضهما البعض ، فأنت لا تقوم حقًا بالسباق وتنهار التخطيط ...

Answer 3

هل يمكنني الإجابة بـ "ذلك يعتمد"؟ بالإضافة إلى ذلك ، أود رمي "تعريف كامل".

لقد كان لدينا هذا الموقف عدة مرات وتعاملنا معه بشكل مختلف اعتمادًا على الظروف.

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

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

لذلك ، كان إما الخيار 4 أو الخيار 2 بالنسبة لنا عندما تم استدعاؤه.

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

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

الخيار 3 يبدو وكأنه الأكثر فوضى بالنسبة لي ، لذلك سأبذل ذلك.

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

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

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

لذلك ، هناك بعض الأشياء التي يجب مراعاتها.

• كم من الوقت ستحتاج إلى إنجازه؟ إذا كان يوم واحد أو يومين فقط ، فقد يكون تمديد العدو الخاص بك هو الخيار الأفضل.
• ما مقدار الجهد لإزالة الكود الموجود بالفعل؟ إذا كان الأمر فوضويًا ويستغرق وقتًا ، فقم بحل إلى الخيار 2 أو 4. إذا كان الأمر سهلاً ، فربما يكون الخيار 1 هو الطريق للذهاب.
• ماذا يفكر الفريق؟ ماذا يعتقد مالك المنتج؟ ماذا يفكر الآخرون؟ قد يكون لفشل الربيع تأثير على معنويات الفريق ، ولكن قد لا يكون كذلك.

Answer 4

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

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

• Sprint - يمكن أن يشمل ذلك أشياء مثل جميع القصص الخاصة بـ The Sprint "يتم" (انظر أعلاه ، يتم الاحتفاظ بأثر رجعي ، وقد شهد مالك المنتج عرضًا للوظائف وما إلى ذلك.

• إصدار Sprint - تم دمج تطوير السلسلة السابقة من Sprints بنجاح واختبار الانحدار ، وقد تم إصدار الوظيفة في البيئة الحية.

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

الشيء المهم هو عدم التغلب عليه. فقط تعلم منه ، والتكيف والمضي قدمًا.

Answer 5

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

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

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

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

Answer 6

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

المشكلة التي أراها مع الخيار 1 هي أن الفريق لا يقدم ما التزمت به. في بعض الحالات ، قد لا تتمكن من استبعاد الميزة B دون جعل الإصدار بالكامل عديم الفائدة (أو على الأقل أقل قيمة). قد يجعل من الصعب توجيه اتجاه العدو التالي بدون ميزة ب.

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