یوزر اینترفیس به سبک اجایل
توسعه وب

یوزر اینترفیس به سبک اجایل #۳

۰ 192

و اما قسمت آخر؛ در دو پست قبلی کلیاتی درباره UI Development مطرح شد. در این قسمت بصورت کاربردی تر به این موضوع خواهم پرداخت.  همونطور که می دونید Iterative(تکرارشونده) و Incremental(تدریجی)  بودن توسعه، دو اصل حیاتی در بطن Agile هستن. بعضی ها فکر می کنن که این دو مورد فقط باید در توسعه Back-End محصول دیده بشه! بر خلاف این نظر در توسعه Front-End هم رعایت این دو اصل الزامی است.  دقت کنید جداسازی Front-End و Back-End از لحاظ تکنیک های پیاده سازی است و در خروجی یک چیز بیشتر نیست و اون کل محصوله که یک ماهیت بیشتر نداره. نکته ای که مهم است اینه که به Front-End نگاه Design و Development رو تواماً داشته باشید.

خوب حالا فرض کنید محصولی رو با استفاده از اسکرام قرار است تولید کنید. سوال اینه که یوزر اینترفیس رو از کجای چرخه توسعه نرم افزار باید شروع کنیم و دو اصل کلیدی فوق رو به چه صورت پیاده کنیم؟ عموماً در اکثر تیم های اسکرام، اسپرینت صفر (۰) وجود داره. بهترین زمان برای ترسیم یک شِمای کلی از اینترفیس در همین اسپرینت صفر است که می تونید در قالب پروتوتایپ های کاغذی آماده بشه و به پروداکت اونر ارائه شه. استفاده از پروتوتایپ های کاغذی مطابق با دو اصل کلیدی است. آهسته و پیوسته حرکت می کنیم و No More, No Less رو از همون ابتدای کار بهش توجه می کنیم. پروتوتایپ های کاغذی رو حتماً جدی بگیرید. به نظر من بعنوان یک عادت خوب قبل از شروع کدنویسیِ یک Task مرتبط با UI حتماً قبلش پروتوتایپ کاغذی ش رو داشته باشید. مزیت این کار این هست که آمادگیتون برای تغییر روی کاغذ خیلی بیشتر از حالتی است که کد نوشته شده. شما براحتی می تونید در حین صحبت با پروداکت اونر تغییرات لازم رو روی پروتوتایپ کاغذی بدید. قرار هم نیست در اسپرینت های ابتدایی کل UI بسته شه. در واقع روند تکامل تدریجی و تکرارشونده در کل اسپرینت ها وجود داره. مسلماً تا آیتم های بگ لاگ به یه حدی نرسه شروع طراحی پروتوتایپ های کاغذی معنایی نداره. شما در این زمان میتونید Mock-up های آماده برای فرم هایی مثل Login، ثبت نام یا گریدها داشته باشید. طبیعتاً این کار در ادامه باعث صرفه جویی در زمان میشه که شما میتونید از این زمان بدست اومده در جهت بالابردن کارایی UI و بهترکردن UX استفاده کنید. در جلسه Sprint Planning سعی کنید DoD رو برای UI خیلی کامل در نظر نگیرید البته نظر PO در این قسمت مهم تر است ولی بطور کلی سعی کنید اسپرینت به اسپرینت UI یک Task خاص رو تکمیل کنید در همون حدی که مورد انتظار PO است نه بیشتر و نه کمتر. توسعه Front-End چیزی است که شاید در طول اسپرینت های اولیه خیلی دستخوش تغییر بشه تا stable بشه. تا اون زمان سعی کنید از دوباره کاری ها جلوگیری کنید. معیار Just Enough  بر می گرده به DoD ای که برای هر Task در نظر گرفته شده. پس با کمک تیم و PO و با کمک پروتوتایپ های کاغذی که قبلاً رسم کردید حتماً DoD رو در Sprint Planning مشخص کنید تا دوباره کاری صورت نگیره.

سعی کنید CSS Library آماده ای داشته باشید. بسته به نوع تمپلیت منوهای آماده، کنترل های تست شده و Design Pattern های مختلف در جعبه ابزار تیم داشته باشید تا بتونید وقت خودتون صرف آیتم های با اولویت تر کنید تا اینکه تیم یک هفته برای یک منوی Cross-Browser وقت بگذاره. دو اصل کلیدی بیان شده باعث میشه شما همیشه آمادگی لازم برای تغییرات رو داشته باشید. پاسخگویی مناسب به تغییرات درخواست شده از جانب مشتری از ارزش های مهم در Agile است. اگر تیم از تغییرات UI استقبال نمیکنه و دائم غر غر می کنه مطمئن باشید بعضی از مواردی که در بالا بیان شد رعایت نشده. ارتباطات در تیم اسکرام خیلی مهم است سعی کنید بین اعضای تیم، اسکرام مستر و پروداکت اونر ارتباطات رو به بهترین شکل مدیریت کنید.

علاوه بر تکمیل UI مربوط به یوزر استوری های هر اسپرینت که همون اسپرینت بگ لاگ میشه یک برنامه ریزی کلی متناسب با رلیز پلن برای UI داشته باشید. در مورد UX حتماً با سایر ذینفعان محصول صحبت کنید و به PO اکتفاء نکنید. مواردی که مد نظرشون رو هست رو حتماً لحاظ کنید. طبیعی است که صحبت با ذینفعان بصورت پیوسته از ابتدای کار تا انتهای کار باید مستمر باشه. مثلاً در جلسات مختلفی که ذینفعان هستن میتونید فیدبک ها رو یادداشت کنید. یا اگر محصول رلیز به رلیز در محیط مشتری مستقر میشه به اونجا برید و فیدبک ها را جمع آوری کنید. همیشه سعی کنید شما دنبال فیدبک باشید نه اینکه منتظر باشید فیدبک خودش بیاد.

نکته آخر این که Cross-Functional بودن تیم اسکرام نقطه مثبتی است در بهتر شدن فرآیند طراحی UI. چراکه افراد مستقیماً با یوزر استوری ها و حتی مواردی که مربوط به تحلیل و جمع آوری نیازمندی ها است در ارتباط هستن، در جلسات مختلفی مثل Sprint Review و Retrospective از نزدیک درگیر پروژه هستن که این موضوع دید کلی اونها رو نسبت به محصول تقویت میکنه و در ادامه کار از کوچکترین مساله ای که در بک لاگ اتفاق میفته مطلع میشن و این انسجام کاری باعث بهتر شدن فرآیند تولید محصول میشه.

امیدوارم این ۳ پست تونسته باشه به شما در طراحی UI به سبک اجایل کمک کنه.

موفق باشید.

در باره نویسنده / 

حمیدرضا متقیان

مدیر محصول Agile. علاقه مند به دنیای وب و ارزش آفرینی در کسب و کار دیجیتالی.

ارسال پاسخ

ایمیل شما نمایش داده نمی‌شود. موارد مورد نیاز علامتگذاری شده است *

*

code

عضویت در خبرنامه

نوشته های تصادفی

  • Scrum and XP

    انتشار ویرایش دوم کتاب Scrum & XP from the Trenches

    کتاب Scrum & XP from the Trenches نوشته Henrik Kniberg جزء کتاب های مرجع اسکرام است. اخیراً ویرایش دوم این کتاب منتشر شده که می تونید به رایگان نسخه PDF رو از سایت ناشر دانلود کنید.

  • چگونه یک طراح وب خوب شویم؟

    چگونه یک طراح وب خوب شویم؟

    این سوال اغلب مبتدیان و تازه کارانی هست که به این حرفه علاقه مندند و قصدشون اینه که در کارشون متبحر بشن. اما چگونه؟ یک اصل کلی در هر حرفه ای وجود داره و اون تمرین و ممارست هست. طراحی وب هم از این اصل مستثنی نیست. اما طبیعتا هر حرفه ای زیر و بم…

  • بندهای حیاتی یک قرارداد تولید نرم افزار

    بندهای حیاتی یک قرارداد تولید نرم افزار

    یک قرارداد محکم از اساسی ترین ملزومات موفق انجام شدن یک پروژه نرم افزاری هست. خیلی از اختلافات بین کارفرما و مجری با استناد به قرارداد رفع میشه و مهمتر از هر چیز بحث ضرر و زیان پروژه هست که برای طرفین مهم هست. بعنوان یک اصل کلی، کلیات و جزئیات قرارداد رو جدی بگیرین…