كيف تتعامل مع العملاء والتكرار في فريق Agile؟ [مغلق

Question

هذا الموضوع هو متابعة لي السابق. في الحقيقة سؤالين ، لذلك آمل ألا يعتمد أحد ، لأنهم يعتمدون على بعضهم البعض.

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

ماذا تفعل في التكرار الأول؟

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

كيفية التواصل مع العملاء؟

فكرنا الأولي في ضبط العملية على شيء مثل هذا:

alt text http://img690.imageshack.us/img690/2553/Communication.png

هل من الجيد أن يكون لديك نقطة محورية على جانب العميل أم أنه من الأفضل التواصل مباشرة مع جميع العملاء لمنع سوء الفهم؟

---

أي أفكار مرحب بها! شكرا مقدما.

Answer 1

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

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

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

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

Answer 2

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

Answer 3

ماذا ، بشكل عام ، تفعل في التكرارات القليلة الأولى إذا بدأنا من الخدش؟

تستخدم العديد من الفرق التكرار صفر إلى:

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

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

ما عليك سوى إعطائها شهرًا من التطوير لتدوين Code Core للتطبيق أو ابدأ بإطارات سلكية بسيطة ذات وظائف محدودة مسبقًا؟

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

ما الذي يريد العملاء رؤيته عادة؟ أشياء لامعة لا تعمل أو أشياء قبيحة تعمل؟

لتجربتي ، يريدون رؤية تقدم واضح وتريد الحصول على ملاحظات في أقرب وقت ممكن.

هل من الجيد أن يكون لديك نقطة محورية على جانب العميل أم أنه من الأفضل التواصل مباشرة مع جميع العملاء لمنع سوء الفهم؟

انت تحتاج واحد الشخص لتمثيل العملاء (الذي يطلق عليه مالك المنتج في Scrum):

• إنه يقدم صوتًا موثوقًا واحدًا
• لديه معرفة مثالية بالعمل (أي يمكنه الإجابة على الأسئلة)
• إنه يعرف كيفية تعظيم العائد على الاستثمار (أي كيفية تحديد أولويات الوظائف)

Answer 4

يريد Agile عمومًا تزويد العميل بشيء ذي قيمة ، بسرعة.

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

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

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

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

Answer 5

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

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

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

هتافات