ما وراء Sprint 0: بديل لدمج الفرق

Scrum هي منهجية إدارة المشاريع الأكثر شيوعًا في العالم مع أكثر من 72٪ من الفرق التي تستخدم Scrum أو scrum-hybrid. من الجيد أنه إذا كنت تعمل في تطوير الويب ، فأنت تستخدم Scrum بشكل ما.

الاتجاه الحالي في سكرم هو "Sprint 0" أو ابن عمها الأكثر فنية "Design Sprint". لقد كتب الكثير حول ما إذا كانت هذه سباقات السرعة حقيقية (ليست كذلك) ولكن قيل القليل عن سبب وجودها في المقام الأول ، ولماذا يتمسكوا بعناد ، وما هي البدائل الموجودة.

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

بعض التعريفات السريعة قبل أن نبدأ:

• سبرينت 0
  الجهد الأولي للفريق لإنشاء المستندات الإرشادية المطلوبة لمشاريع سكروم: رؤية ، تراكم المنتج ، وتقديرات إصدار المنتج.
• سبرينت التصميم
  الجهد الأولي للفريق لإنشاء تصميم إرشادي لبقية الإصدار.
  

لماذا Sprint 0 و Design Sprint موجود

من الجيد أن نقول ، "Sprint 0 ليست عدوًا حقيقيًا ، لا تفعل ذلك." لكن هذه التكيفات في العدو السريع موجودة لسبب ما. تتبناها العديد من الفرق لأن مشروعهم لديه حاجة غير ملباة خارج النطاق المباشر لـ Scrum. ملاحظتي هي أن Sprint 0 و Design Sprint غالبًا ما تستخدم لمعالجة المواقف التالية:

1. عدم وجود رؤية إرشادية قوية ؛
2. عدم وجود تكامل التصميم في تدفق أعمال التطوير.

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

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

الرؤية والنموذج الأولي Sprint

في الحالة الأولى ، حيث يوجد نقص في الرؤية القوية ، تكون الوثائق أو الأفكار الإرشادية ضعيفة جدًا لبدء مشروع Scrum حقًا. لأية عملية (بما في ذلك سكرم) ، تحتاج إلى التوجيه قبل بدء الرحلة. يعد Agile أمرًا رائعًا لمعرفة أفضل طريقة للوصول إلى الهدف ، ولكن إنشاء الرؤية الأولية ليس ضمن نطاقه. في الواقع ، يفتقد Scrum تمامًا وصف الرؤية المطلوبة لبدء عملية التطوير. سواء كان الأمر يتعلق بـ Scrum بالفعل أم لا ، فإن Sprint 0 هو مجرد فريق ويب على الخطوط الأمامية ، باستخدام الأدوات التي لديهم ، في محاولة لمعرفة ما يحتاجون إلى القيام به قبل البدء في القيام بذلك.

العيب الحقيقي لـ Sprint 0 هو أن بناء المستند الإرشادي للمشروع في الوقت الذي يكون لديك فيه أقل المعلومات يوفر قيمة منخفضة لعملية التطوير التالية.

تحتاج رؤى المشروع الموجهة التي لا تتماشى مع الواقع الناشئ بشكل متكرر إما إلى المرور بعملية مكلفة لسبرينت 0 آخر ، أو في كثير من الأحيان يتم تجاهلها ببساطة.

البديل الأفضل هو النموذج الأولي Sprint: هو أول سباق يشترك فيه الفريق بأكمله بينما يقوم في الواقع ببناء النموذج الأولي نفسه.

عملية رؤية النموذج الأولي Sprint

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

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

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

مثال

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

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

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

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

ظهرت بعض المشكلات الأخرى بسرعة خلال هذا النموذج الأولي لسباق السرعة:

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

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

التصميم والنموذج الأولي Sprint

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

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

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

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

عملية تصميم النموذج الأولي Sprint

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

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

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

مثال

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

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

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

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

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

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

عندما يتم إكمال النموذج الأولي Sprint

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

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

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

بعض المشكلات الشائعة التي يجب الانتباه إليها أثناء سباق النموذج الأولي

تتضمن بعض المشكلات الشائعة التي يجب الانتباه إليها عند تنفيذ سباق النموذج الأولي ما يلي:

• اعتنق قيمة الدقة المنخفضة وتجنب التركيز على العناصر المرئية. كن يقظًا بشأن هذه النقطة حيث قد تحتاج الفرق الجديدة على هذا النهج إلى المساعدة والطمأنينة لأنها تتجاوز "أين الشعار" وتركز على أسئلة أعمق تتعلق بالوظائف والتسلسل الهرمي.
• جانب مختلف لما سبق ، كن يقظًا أيضًا بشأن عدم التعلق بأفكار التصميم / التخطيط الخاصة بك. من المفيد أن تتذكر أثناء سباقات السرعة الأولية أنه لا يتم إنشاء أي شيء ثمين وأن تظل بعيدًا عن النتائج النهائية. أيضًا ، إنه سبب آخر للحفاظ على النماذج الأولية في حدها الأدنى ، وبصراحة ، قبيحة إلى حد ما. إنه يخدم الغرض من إبقاء المستخدمين منفصلين.
• يعتبر الشراء المبكر للعملية من القيادة أمرًا بالغ الأهمية . نظرًا لأن الفريق بأكمله مشترك ، يحتاج العميل ورئيسك والمطورين جميعًا إلى دعم العملية ورعايتها من خلال مشاركتهم وإبداعهم ووقتهم. لا تكن قائدًا وحيدًا ، يحتاج فريقك بأكمله إلى التلويح بأصواتهم!
• التواصل السيئ هو كعب أخيل لجميع العمل الجماعي . لن يحل النموذج الأولي للعدو السريع مشكلات الاتصال المستمرة ولكنه سيضعها في المقدمة في وقت أقرب حيث يغوص الفريق بأكمله في سير عمل تعاوني على الفور تقريبًا. ستظهر أي مشكلات اتصال موجودة بالفعل في وقت مبكر وغالبًا في نموذج أولي سريع بينما تعمل على تحقيق توافق في الآراء وأول زيادة يتم إجراؤها. اغتنم الفرصة لتحسين التواصل وإشراك الفريق بأكمله في إيجاد الحلول.
• اختر الإطار الصحيح للواجهة الأمامية . إذا لم يكن لديك واحد بالفعل ، فقد تحتاج إلى تجربة العديد من أطر عمل الواجهة الأمامية قبل أن تجد واحدة تنقر على سير عمل فريقك. أوصي بالنظر في الحد الأدنى من الأطر مثل Fomantic أو Bulma وعدم الانغماس في الأجراس والصفارات. ومع ذلك ، فإن الإطار الصحيح هو دائمًا الإطار الذي يعمل مع فريقك.
• يحتاج فريق UI / UX إلى تطوير مستوى راحة مع إطار عمل الواجهة الأمامية والوصول إليه. من الناحية المثالية ، سيعملون مباشرة على النموذج الأولي ، وتجنب التسليم غير الضروري والحاجة إلى الترجمة من وسيط إلى آخر (أي من Sketch إلى النموذج الأولي). إذا لم يكن فريق الواجهة الأمامية لديك على دراية بـ CSS و HTML ، فإن النهج المزدوج (مع مصمم واحد ومبرمج واحد يعملان معًا في إطار العمل) يعمل جيدًا أيضًا.
• أخيرًا وليس آخرًا ، تذكر أنك ستصبح أفضل وأسرع كفريق ! يعد تشغيل نموذج أولي سريع السرعة مهارة تنمو مع الممارسة.

ماذا حدث بعد ذلك

الزيادة المنجزة في السباق الأول - النموذج الأولي الوظيفي منخفض الدقة - يمهد الطريق لجميع سباقات السرعة التالية. من خلال اختبار المستخدم للنموذج الأولي العملي لإمكانية الاستخدام وإمكانية الوصول والاستجابة ، يمكن أن يبدأ على الفور ، مما يضمن أن تكون سباقات السرعة المستقبلية على دراية بـ UX.

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

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

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

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

ملاحظة حول إعدادات الوكالة

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

خاتمة

يعالج Sprint 0 و Design sprint التحديات الحقيقية التي تواجه العديد من فرق سكروم: الافتقار إلى الرؤية ، الافتقار إلى التصميم المتكامل ، أو كليهما. إنها استجابات مفهومة ومنطقية ، لكنها لا تقدم قيمة عالية ولا تساهم في فرق أجايل قوية.

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

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

مزيد من القراءة على SmashingMag:

• أن تصبح ميسرًا أفضل
• التكيف مع أجايل لفرق العمل بدوام جزئي
• أهمية المشروع بأثر رجعي
• جلب عملية تصميم أفضل لمؤسستك