یوزر اینترفیس(رابط کاربری) به سبک اجایل #31 min read
و اما قسمت آخر؛ در دو پست قبلی کلیاتی درباره UI Development مطرح شد. در این قسمت بصورت کاربردی تر در اجایل به این موضوع خواهم پرداخت. همونطور که می دونید Iterative(تکرارشونده) و Incremental(تدریجی) بودن توسعه، دو اصل حیاتی در بطن Agile هستن. بعضی ها فکر می کنن که این دو مورد فقط باید در توسعه Back-End محصول دیده بشه! بر خلاف این نظر در توسعه Front-End هم رعایت این دو اصل الزامی است. دقت کنید جداسازی Front-End و Back-End از لحاظ تکنیک های پیاده سازی است و در خروجی یک چیز بیشتر نیست و اون کل محصوله که یک ماهیت بیشتر نداره. نکته ای که مهم است اینه که به Front-End نگاه Design و Development رو تواماً داشته باشید.
خوب حالا فرض کنید محصولی رو با استفاده از اسکرام در اجایل قرار است تولید کنید. سوال اینه که یوزر اینترفیس رو از کجای چرخه توسعه نرم افزار باید شروع کنیم و دو اصل کلیدی فوق رو به چه صورت پیاده کنیم؟ عموماً در اکثر تیم های اسکرام، اسپرینت صفر (0) وجود داره. بهترین زمان برای ترسیم یک شِمای کلی از اینترفیس در همین اسپرینت صفر است که می تونید در قالب پروتوتایپ های کاغذی آماده بشه و به پروداکت اونر ارائه شه. استفاده از پروتوتایپ های کاغذی مطابق با دو اصل کلیدی است. آهسته و پیوسته حرکت می کنیم و 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 وقت بگذاره. دو اصل کلیدی بیان شده باعث میشه شما همیشه آمادگی لازم برای تغییرات رو داشته باشید. پاسخگویی مناسب به تغییرات درخواست شده از جانب مشتری از ارزش های مهم در اجایل است. اگر تیم از تغییرات UI استقبال نمیکنه و دائم غر غر می کنه مطمئن باشید بعضی از مواردی که در بالا بیان شد رعایت نشده. ارتباطات در تیم اسکرام خیلی مهم است سعی کنید بین اعضای تیم، اسکرام مستر و پروداکت اونر ارتباطات رو به بهترین شکل مدیریت کنید.
علاوه بر تکمیل UI مربوط به یوزر استوری های هر اسپرینت که همون اسپرینت بگ لاگ میشه یک برنامه ریزی کلی متناسب با رلیز پلن برای UI داشته باشید. در مورد UX حتماً با سایر ذینفعان محصول صحبت کنید و به PO اکتفاء نکنید. مواردی که مد نظرشون رو هست رو حتماً لحاظ کنید. طبیعی است که صحبت با ذینفعان بصورت پیوسته از ابتدای کار تا انتهای کار باید مستمر باشه. مثلاً در جلسات مختلفی که ذینفعان هستن میتونید فیدبک ها رو یادداشت کنید. یا اگر محصول رلیز به رلیز در محیط مشتری مستقر میشه به اونجا برید و فیدبک ها را جمع آوری کنید. همیشه سعی کنید شما دنبال فیدبک باشید نه اینکه منتظر باشید فیدبک خودش بیاد.
نکته آخر این که Cross-Functional بودن تیم اسکرام در اجایل نقطه مثبتی است در بهتر شدن فرآیند طراحی UI. چراکه افراد مستقیماً با یوزر استوری ها و حتی مواردی که مربوط به تحلیل و جمع آوری نیازمندی ها است در ارتباط هستن، در جلسات مختلفی مثل Sprint Review و Retrospective از نزدیک درگیر پروژه هستن که این موضوع دید کلی اونها رو نسبت به محصول تقویت میکنه و در ادامه کار از کوچکترین مساله ای که در بک لاگ اتفاق میفته مطلع میشن و این انسجام کاری باعث بهتر شدن فرآیند تولید محصول میشه.
امیدوارم این 3 پست تونسته باشه به شما در طراحی UI به سبک اجایل کمک کنه.
موفق باشید.
مطالب زیر را حتما مطالعه کنید
نحوه نصب ویندوز سرویس سفارشی
یوزر اینترفیس (رابط کاربری) به سبک اجایل #2
نحوه ساخت وب ستاپ در یک برنامه ASP.NET
یوزر اینترفیس (رابط کاربری) به سبک اجایل #1
رفع تداخل کتابخانه MS Ajax با jQuery
آموزش تکنیک CSS Sprites و ساختن Image Map
دیدگاهتان را بنویسید لغو پاسخ
این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش میشوند.
2 دیدگاه
به گفتگوی ما بپیوندید و دیدگاه خود را با ما در میان بگذارید.