الأفيال ليست زرافات ، وقصص المستخدم ليست متطلبات. لديهم سمات مشتركة وسياق مشترك ، لكن هذا لا يساويهم. ومع ذلك ، يعتقد الكثير من الناس أن قصص المستخدمين هي نوع من القراءة الجديدة لما يسمى تقليديًا بمتطلبات البرامج - بعد كل شيء ، يجب أن تكون هناك متطلبات في المشروع ، أليس كذلك؟ لذا سأجيب - لا ، ومرة أخرى لا . أولاً ، هذه ليست متطلبات ، وثانيًا ، المتطلبات ليست ما نحتاجه حقًا. تُعد قصص المستخدمين ، أولاً وقبل كل شيء ، فرصة لرؤية خيارات التنفيذ المختلفة ، بحيث يمكنك لاحقًا الاستفادة من الفرص التي تم فتحها. والمتطلبات ... هي حل كل شيء مقدمًا ، بحيث تتعثر لاحقًا فيه.
هل هناك فائدة من كتابة مثل هذا المقال؟ ألا يبدو ما ورد أعلاه واضحًا؟ لا ، أعتقد أن العبارات المتكررة مثل "المتطلبات في التراكم" تشير إلى أن نموذج التفكير ظل كما هو ، فقط العلامات تغيرت. بدأت تسمى وثيقة المتطلبات باسم backlog ، والمتطلبات نفسها - قصص المستخدمين ، والآن نحن "رشيقة" ...
علامة أخرى على سوء فهم محتمل هي الممارسة المنتشرة لتخزين قصص المستخدمين في قاعدة البيانات مع تخصيص معرف فريد. من الممكن أن يتم ذلك فقط من أجل الراحة ، ولكن من الممكن أن يكون هذا نتيجة للميل المستمر إلى التفكير من حيث المتطلبات.
لكن ممارسة تضمين قصص المستخدمين في العقد هي بالفعل علامة 100٪ على اعتبار قصص المستخدمين بمثابة متطلبات. المشكلة هنا هي أن قصة المستخدم ، بحكم تعريفها ، لا يمكن أن تكون واضحة كشرط ، وهذا يقلل من قيمة العقد. بالطبع ، يمكن أيضًا تفسير المتطلبات في بعض الأحيان بحرية إلى حد ما ، لكن أسلوب كتابتها يعني في البداية إزالة الغموض ، والذي لا يمكن قوله عن قصص المستخدم. بالإضافة إلى ذلك ، فإن المتطلبات مرنة للتغيير حيث يتم تضمينها في عقود المشروع. من أجل تغيير أو إضافة متطلبات جديدة ، يجب تمريرها من خلال بنك التعمير الصينى . بعبارة أخرى ، يجب على أصحاب المصلحة الموافقة والموافقة أولاً. انظر أدناه لمزيد من التفاصيل حول العقود.
إذن ما هي قصص المستخدم؟ اعتبرهم أداة تخطيط. بمساعدة قصص المستخدمين ، نعطي الأولوية ، ونقيم ونقرر في أي سباق سيتم تنفيذ الوظيفة المقابلة. هذه كلها ميزات نموذجية لأداة التخطيط ، لذا لا تحاول تحويلها إلى شيء آخر.
تكمن قوة قصص المستخدم في أنها تؤدي إلى الحوار. بدلاً من مجرد أخذ المواصفات التي يتم تفسيرها أولاً من قبل المطورين ونقلها إلى الزملاء ، ثم من قبل المختبرين ، نبدأ مناقشة. نحن ندرج موظفين ذوي مهارات مختلفة في الاتصال. وهكذا - لكل ميزة جديدة.
نظرًا لأن قصة المستخدم ، على هذا النحو ، لا تحمل الكثير من المعاني ، يمكننا ببساطة تجاهلها بعد تنفيذ الوظيفة المقابلة. إذا كنت ترغب في ذلك ، يمكنك الاحتفاظ بإحصائيات دقيقة حول عدد القصص المحققة ، ولكن هذا قد يكون محدودًا للغاية.
اتضح أننا لسنا بحاجة لمتطلبات؟ في الواقع، وهذا ليس صحيحا. بعد كل شيء ، هناك قيود بطريقة أو بأخرى. على سبيل المثال ، يجب أن تمتثل المعدات الطبية للوائح إدارة الغذاء والدواء . فلنسميها قيود إذن!
ومع ذلك ، فإن المتطلبات تصف النظام بالتفصيل ، فربما هناك بعض القيمة في مثل هذا الوصف بالنسبة لنا؟ على سبيل المثال ، كيف نحدد ما إذا كان بعض سلوك النظام هو خطأ أم لا ، إذا لم يكن لدينا متطلبات رسمية مقدمة بشكل أو بآخر؟ ستساعدنا تقنية "المواصفات حسب المثال" هنا. لذلك تقرر تنفيذ بعض الوظائف. أنت تكتب قواعد العمل وسلسلة من الأمثلة بطريقة تجعلها: أ) سهلة القراءة ؛ ب) قابلة للتحقيق. من هذا الوصف ، يجب أن يكون واضحًا ما يجب أن يفعله النظام. وأيضًا ، إذا حدث خطأ ما نتيجة للتغييرات - كان انتهاك قواعد العمل هو سبب هذا الخلل الوظيفي.
كما كتبت سابقًا ، يجب أن يكون وصف الخطأ بسيطًا وواضحًا. الأخطاء هي أشياء تدمر المعلومات ، وهي سيئة بغض النظر عما إذا كان لدينا وصف مطلب يغطي حالة معينة أم لا
عقد
(بواسطة Matthias Skarin)
إذن ما الذي سنستخدمه بدلاً من مواصفات المتطلبات؟ بعد كل شيء ، نحن بحاجة إلى فهم ما إذا كنا قد نفذنا بالضبط ما هو مطلوب؟ سوف نستخدم العقود الرشيقة. Agile - العقود هي فرصة لرؤية الغابة للأشجار ، فهي تسمح لك بالتركيز على جوهر المشروع وتحقيق الهدف المشترك ، والذي سيلبي تنفيذه احتياجات المستخدمين.
ضع في اعتبارك ، عندما تفكر في العقد أثناء المشروع للتحقق مما إذا كان شريكك قد انتهك أي شيء ، فهذا يعني بالفعل أن هناك خطأ ما. يجب أن يبني العقد الثقة بين الطرفين بحيث يصبح من الممكن تجاوز التفاصيل ، وعدم التورط فيها.
ملخص
- على الرغم من أن الفيل والزرافة لهما أربع أرجل ، إلا أنهما حيوانان مختلفان.
- قصص المستخدم ليست متطلبات ، ولكنها أداة تخطيط.
- أقرب شيء إلى المتطلبات هو المواصفات حسب المثال.