فصل ماذا عن كيف - التصميم في بيئة رشيقة [مغلق]

Question

في بيئة رشيقة (scrum)، كيف يمكنك جعل إدارة المنتج تقوم بإنشاء عناصر أو قصص متراكمة صغيرة بما يكفي دون مطالبتهم بالقيام بكل التصميم، وهو ليس تخصصهم؟بمعنى آخر، كيف يمكنك فصل ماذا (متطلبات العمل) عن كيف (التصميم) في التطوير السريع؟

Answer 1

مع سكروم، ادارة المنتج يجب أن يكون شخص واحد:ال مالك المنتج .

ما تريد القيام به يتم خلال تخطيط العدو, حيث يجب أن يكون الفريق بأكمله (مالك المنتج، ومدير سكروم، والمطورين) حاضرًا.

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

على سبيل المثال كمستخدم StackOverflow، أود أن أرى سمعتي

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

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

Answer 2

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

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

ما يجب أن تضعه دائمًا في الاعتبار عند كتابة قصص المستخدم الخاصة بك أو مساعدتها في كتابتها، هو أن القصص يجب أن تكون استثمارًا. أنامستقل, نقابل للتفاوض, الخامسقابلة للعملاء، هقابل للقياس، سمول و تمستقر.

أعتقد أن استخدام القالب أدناه قد يكون مفيدًا في البداية للحفاظ على تركيز أمر الشراء على أهداف العمل:

"باعتباري - نوع المستخدم -، أريد -بعض الأهداف- لذلك -سبب ما-."

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

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

في المثال أعلاه، هناك اختباران محتملان للقبول هما:

"اختبار للتصويت على الإجابة"

"اختبار للتصويت ضد الإجابة"

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

Answer 3

لا تنس أنه يجب تصنيف العناصر المتراكمة للمنتج حسب الأهمية، باستخدام نظام الترجيح (الأعداد الأولية، فيبوناتشي،..)، بحيث إذا كان لديك عناصر في تراكمك تكون ذات أهمية مماثلة (أي.عنصرين بوزن 21)، فيجب من الناحية النظرية محاولة إدراجهما في السباق قبل الـ 13 والـ 8.

Answer 4

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

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