3 أميغو - وسيلة اتصال ، لخلق جودة المنتج

تخيل موقفًا - حيث يقوم المختبر بالعثور على خطأ ، ويبدأ مناقشته مع المطور - ويصر على أن هذا ليس خطأ ، لأن المواصفات لم تتحدث عن هذه الوظيفة. هل هذا مألوف؟

أو لأن المتطلبات كانت غامضة ، وأساء فهمها. أو بالعكس ، كان هناك الكثير من المعلومات فيها فقد التركيز وفقدت بعض المعلومات عن الأنظار أثناء التطوير.

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

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

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

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

3 أميغو ...

3 Amigo هي ممارسة توفر فهمًا عالميًا لما سيتم تسليمه إلى العميل. إنها تساعد في نقل صوت الفريق ، وليس تشابك الآراء المتفرقة.

تساعد طريقة الاتصال هذه داخل الفريق على:

• التوصل إلى اتفاق مشترك بشأن التوقعات قبل التنمية
• تشكيل اتفاق على كيفية القيام بالشيء الصحيح على الفور

يساعد أيضًا على فهم:

• ما المشكلة التي نحلها؟
• ما هي الحلول
• ماذا نحتاج أن نفعل حتى تكون المهمة جاهزة؟

يعد اجتماع الثلاثة أميغو طريقة للتفكير سويًا يسد الفجوة في فهم مواصفات العمل. إنها تساعد في تطوير قصص المستخدم الرائعة.

الهدف من ذلك هو القيام بالعمل في الوقت المحدد ، ولكن في الوقت نفسه لا تخطط للمستقبل ، بحيث يكون للتفاصيل الوقت الكافي.

لماذا 3؟ من هو المتقدم؟

اسم الممارسة لا يقتصر على ثلاثة سياقات ، ولكن فقط يخلق إطار عمل بسيط. للتأكد من أنه عند تطوير المتطلبات ، تم أخذ جميع الفروق الدقيقة ، الحالات الصريحة والضمنية في الاعتبار ، أن المواصفات تعكس الحاجة الفعلية للعميل - يلزم التفكير / سياقات مختلفة: الأعمال ، المطور ، الفاحص. علاوة على ذلك ، لا يقتصر الاجتماع على هؤلاء الأشخاص فقط. أنه ينطوي على كل من يشارك في تنفيذ هذا الشرط. على سبيل المثال ، إذا كانت مهمتك لا تحتوي على الويب فقط ، ولكن أيضًا على الجوال ، فأنت بحاجة إلى سياق إضافي. وهذا هو ، الشخص الذي سوف يقوم بتنفيذ في تطبيقات الهاتف المحمول. في فرقنا ، غالبًا ما يشارك في الاجتماع 4 مطورين (1 ios ، 1 android ، 1 back ، 1 front) ، ومحلل ومحلل أعمال.

محلل أعمال أو ص

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

المطورون

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

اختبار

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

متى يتم تطبيق الممارسة؟

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

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

وإذا كانت الوثائق كبيرة ومفصلة ، فقد تستغرق قراءتها وقتًا أطول من عملية الاختبار أو التطوير نفسها.

في خط أعمالنا ، قررنا تطبيق هذه الممارسة عندما بدأت المهام في الاختبار. حددنا 3 مشاكل رئيسية:

1. في مرحلة الاختبار ، حدثت عوائد كثيرة بسبب توضيح المتطلبات. كانت هذه فترات توقف ملموسة في الاختبار والتطوير ، عندما قرر محلل أعمال كيف يجب أن يعمل.
2. تأخر اختبار المهمة بسبب مواصفات مفصلة للغاية. كانت الحالات متكررة ، عندما كان بإمكان الفاحص قضاء 3-6 ساعات فقط في دراسة المتطلبات وتطوير حالات الاختبار ، وكان الاختبار نفسه يستغرق حوالي 30 دقيقة ، والأكثر فظاعة هو الحالة عندما بدأ الاختبار بعد أسبوعين من دراسة المواصفات ، كان الأمر معقدًا للغاية ومفصلة.
3. حسنًا ، كانت المشكلة الأكثر شيوعًا هي أنه أثناء اختبار القبول ، كان هناك الكثير من الأخطاء. تلك الأخطاء التي كان يمكن تجنبها إذا تم التفكير فيها قبل التطوير.

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

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

خطوات لممارسة AC

1. نقوم بصياغة المتطلبات كقصة مستخدم

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

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

أنا <role> ، أريد <action> بحيث <الدافع>

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

تقليديًا ، هناك مشكلتان عند تكوين قصة مستخدم:

• عند التسجيل ، إما لا تشير إلى الدور ، مما يترك العمل والدافع
• أو يشيرون إلى الدور والعمل ، ويطردون الدافع.

هذا في الواقع يسبب مشاكل ، وسأحاول شرح الأمثلة بأمثلة بسيطة.

1. معرفة "الدور" ، أنت ، كأعضاء في الفريق ، ستفهم بشكل أفضل حدود معايير القبول التي تحتاج إلى صياغتها. إذا لم تكن على دراية تامة بالشخص الذي شارك في قصة المستخدم هذه ، يمكنك إما القيام بذلك بما يتجاوز ما تحتاج إليه ، أو العكس ، يمكنك القيام بنوع من الوظائف.
   
   • على سبيل المثال : لم يفهم الفريق الدور في قصة المستخدم ، وعند العمل خلال المهمة ، قرر أنه سيفعل 3 طرق لـ api: add، edit and delete. وفي المقدمة ، سيقومون بإضافة أزرار تستدعي هذه الأساليب. عندما قدموا قرارهم إلى الشركة ، تلقوا ردود فعل مفادها أن عملائهم هم في الواقع محلل أعمال محدد يحتاج إلى طريقة لإضافة. وقال انه لن يحذف وتحرير. نعم ، ويمكنه استدعاء هذه الطريقة من خلال ساعي البريد.
2. لا يفهم الفريق دوافع "الدور" الذي يصنعون به قصة المستخدم. نظرًا لسوء الفهم ، فقد تم تحديد حدود قصة المستخدم نفسه بشكل سيء. بالإضافة إلى ذلك ، قد لا تحل معايير القبول في النهاية مشكلة العميل النهائي ، على الرغم من أنها سوف تتوافق مع الإجراء الذي تم التعبير عنه في قصة المستخدم.
   
   • مثال : استأجر فريق قصة مستخدم حيث لم يستطع محلل الأعمال التعبير بوضوح عن الدافع. من ناحية ، كانت تترك العميل مخلصًا وإجراء تحسين له. من ناحية أخرى ، خفض التكاليف للبنك. في هذه الحالة ، كانت طرق التنفيذ ومعايير القبول مختلفة تمامًا. لأنه في الحالة الأولى ، ركز الفريق على معايير قبول المستخدم. في الثانية - اهتم الفريق بكيفية جعل تنفيذ أبسط وأسرع ممكن.

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

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

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

بعد اجتياز المتطلب مرحلة التحول إلى قصة مستخدم والتحقق من صحتها من قِبل الفريق (3 أميغو) ، يمكننا المضي قدمًا في وضع معايير القبول.

2. نحن نكمل معايير القبول لقصة المستخدم في اجتماع 3 أميغو

تحتاج أولاً إلى تحديد معايير القبول جميعها.

لذلك ، معايير القبول هي متطلبات من العميل ؛ مواصفات يمكن من خلالها التحقق من نظام قصة المستخدم /.

لديهم اسم بديل ، وشروط الرضا - شروط لتلبية التوقعات (المؤلف مايك كوهن).

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

تتمثل مهام المشاركين خلال الاجتماع في استكمال / إثراء السجل بعدد كافٍ من معايير القبول لتنفيذه لاحقًا.

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

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

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

على سبيل المثال:

*     ,     .*> 

3. نحافظ على التوقيت

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

إذا لم يتم ذلك ، فسيتم تأخير اجتماع 3 Amigo إلى حد كبير.

الوقت الأمثل لعقد اجتماع 3 أميغو هو من 30 دقيقة إلى 1 ساعة.

زيادة مقبولة في بداية المسار - عندما يتعلم الفريق التواصل وتطبيق هذه الممارسة.

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

4. لإكمال دراسة المعايير ، نستخدم منهج البحث عن USR

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

تتيح لك ميزة الاستدلال على USR مراعاة المعايير على جميع المستويات الضرورية للحصول على أكبر قدر من المعلومات حول ما يريده العميل.

وهكذا،

1. المستخدم - ماذا يريد المستخدم أن يفعل مع النظام؟
2. النظام - ماذا يجب أن يفعل النظام؟
3. المخاطر - ما هي المشاكل التي قد تنشأ؟

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

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

طرق لتطبيق الممارسة لتطوير حالات الاختبار قبل التطوير

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

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

كيف يمكن أن تبدو في العملية العامة (عندما تحتاج إلى عقد هذا الاجتماع)

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

نظرًا لأنك في سباق العدو تأخذ قصصًا جاهزة للعمل ، عندئذٍ يجب عقد اجتماع لثلاث قصص أميغو قبل التخطيط. خلاف ذلك ، فإنك تواجه خطر ارتكاب خطأ كبير مع التقدير الأولي. في الممارسة العملية ، وتقييم القصة بعد اجتماع 3 أميغو يختلف كثيرا عن الأصل.

أيضًا ، من المنطقي إضافة عنصر جديد إلى DOD كمؤشر على الاستعداد ، أن القصة جاهزة للعمل عليها في سباق السرعة.

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

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

ما هي نتيجة الاجتماع 3 أميغو؟

• نصوص / أمثلة (إجابات واضحة)
• القواعد المحددة / معايير القبول
• قصص جديدة / متحللة
• فهم مشترك للمنطقة المشكلة
• التعاطف (التعاطف ، المشاركة)

والنتيجة الرئيسية للأميغو الثلاثة هي اختبارات القبول المكتوبة بتنسيق " Given / When / Then" . في الواقع ، قد تستغرق كتابتها وقتًا أطول مما نود ، لذلك لا ينصح بإضفاء الطابع الرسمي على جميع المتطلبات في اجتماع ما عندما يكون الجميع معًا. عادة ، سوف يعمل مطور أو اختبار على هذا خارج منطقة الجزاء. وبمجرد تسجيل جميع المعايير وحالات الاختبار ، 3 يبحث Amigos باختصار عما حدث للتأكد من موافقة الجميع على ما تم تسجيله.

ربح استخدام ممارسة 3 أميغو

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

فيما يلي بعض المكافآت الإضافية:

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

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

المزالق

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

درجة الماجستير في مؤتمر QualityConf

في الفترة من 27 إلى 28 مايو ، كجزء من مهرجان RIT ++ ، في مؤتمر QualityConf ، سوف أقوم بإجراء فصل دراسي رئيسي حول تطوير المتطلبات باستخدام ممارسة 3 Amigo.
إذا كنت مهتمًا بهذا النهج ولديك أسئلة ، يمكنك أيضًا الاتصال بي على telegramTravieso_nastya.

نهج التاريخ

مؤلف النهج: جورج دينويدي ، 2009.

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

https://www.agilealliance.org/glossary/three-amigos/

https://www.infoq.com/interviews/george-dinwiddie-three-amigos

https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories

https://www.stickyminds.com/better-software-magazine/three-amigos