المبادئ المعمارية كقصص مستخدم "غير وظيفية" [مغلقة

Question

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

ومع ذلك ، هناك شيء واحد لا يقنعني. في منشور المدونة هذا يحدد Mike Cohn نوعًا معينًا من قصص المستخدم ، والذي أطلق عليه القيود ، والتي يمكن استخدامها لتحديد ما يسمى بالمتطلبات غير الوظيفية. أنا شخصياً لا أحب الكلمة قيد وحتى استخدام القالب الكلاسيكي "كـ ... ، أريد ... ، لذلك ...".

بدلاً من ذلك ، سأحاول جعل العميل يكتب ، دائمًا على البطاقات ، ربما مع القالب أعلاه ، أولئك الذين يطلق عليهم نيك روزانسكي وإيوين وودز ، في كتابهم الرائع بنية نظم البرمجيات, المبادئ المعمارية:

"المبدأ المعماري هو بيان الاعتقاد أو النهج أو النية التي توجه تعريف الهندسة المعمارية."

(يقومون أيضًا بتقسيم هذه المبادئ إلى مبادئ العمل و مبادئ التكنولوجيا, ، تمايز أعتقد أننا يجب ألا نهتم به.)

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

هل سبق لك أن جربت أي نهج مماثل؟ هل تثبطه لأي سبب؟ هل لديك أي اقتراح في هذا الأمر؟

Answer 1

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

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

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

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

ربما حاولت عمدا تمديد الإجابة بما يتجاوز نطاق الأسئلة حتى أتلقى بعض الملاحظات على أفكاري أيضًا.

شكرا يا سيد.

Answer 2

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

• سوف يدعم النظام ذروة استخدام 30 مستخدمًا.
• يجب أن تعمل الواردات يوميًا.
• يجب أن تكون جميع المرشحات ونتائج البحث في نفس الصفحة.

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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