فیبوناچی تسک

:)))))

چُست و چابُک (agile)

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

:)))))

هدف agile (فیبوناچی تسک مدیریت چابک) چیه؟

هدف اصلی مدیریت چابک افزایش رضایت مشتری از محصوله. تیم چابک از مشتریان بازخورد و فیدبک میگیره. بازخورد و فیدبک ها رو در قالب sprint تبدیل به تسک های کوچک تر میکنه و محصول رو بهبود میده. این چرخه (اسکرام) بارها و بارها تکرار میشه تا هم محصول بهینه تر باشه هم رضایت مشتری بیشتر.

Agile process

ویژگی های مدیریت چابک چی هست؟

• پذیرفتن تغییر
• توسعه در بازه های زمانی کوتاه
• تعامل و گفت و گوی رو در رو با تیم
• سادگی

اعضای تیم اسکرام:

مالک محصول (product owner)

مالک محصول مشتری ها و نیاز هاشون رو بهتر از همه میشناسه و در نوشتن یوزر استوری ها (متاسفانه معادل فارسیش رو نمیدونم) به تیم اسکرام کمک میکنه. مالک محصول در واقع ارزش محصول رو مشخص میکنه و به تسک ها اولویت میده.

اسکرام مستر

کارایی تیم اسکرام، ساده کردن فرآیندها، مراقبت از تیم و برگزاری دورهمی ها برعهده اسکرام مستره.

بقیه تیم ها!

بقیه تیم ها (تیم هایی که وظیفه فیبوناچی تسک اجرای تسک ها رو دارن. مثلا: تیم توسعه، محصول و دیزاین) مسئول کیفیت محصول، تخمین زدن انجام پذیری تسک ها هستن.

جلسه ها چجورین؟

جلسه ها قبل از شروع هر اسپرینت برگزار میشن و زمان تقریبی برای هر جلسه حدود دو ساعت هست.

مرحله ۱:

جلسه با یوزر استوری ها شروع میشن. مثلا فرض کنیم مالک محصول توسعه یک ویجت خاص رو مطرح میکنه که مشتری ها تقاضاش رو دارن.

مرحله ۲:

تو این مرحله باید اعضای تیم، توسعه این ویجت خاص رو از ۳ جهت بررسی کنن و در نهایت برای هر سه مورد، یک عدد رو اعلام کنن:

فرق راحتی و پیچیدگی چیه؟
راحتی یعنی چی: فیبوناچی تسک فرض کنین برای بار اوله که قراره کار پیچیده ای رو انجام بدم. اگر بخوام به راحتی انجام این کار نمره بدم، مثلا عدد ۸، و اگه بخوام به پیچیدگی انجام این کار نمره بدم عدد ۱۳ رو میدم. اما اگه دوباره قرار باشه همین کار پیچیده رو انجام بدم، به راحتی انجام کار، عدد ۳ رو میدم (چون قبلا انجام دادم و اینبار سختیش کمتره)
اما بازم به پیچیدگی کار، عدد ۱۳ رو میدم.

واضح بودن مسیر یعنی چی:
فرض کنین برای داشتن ویجت، باید با شرکت های دیگه همکاری کنین و هنوز هم راجع بهش صحبت و جلسه ای نداشتین. تو این سناریو مسیر فیبوناچی تسک شفاف و معلوم نیست.

در ادامه هر کدوم از اعضای تیم برای هر سه ویژگی راحتی، پیچیدگی و واضح بودن مسیر یک عدد رو انتخاب و اعلام میکنن. زمان اعلام نمره ها باید همزمان باشه تا جواب اعضای تیم تحت تاثیر جواب همدیگه قرار نگیره. (social proof)

معمولا برای نمره دادن از سری اعداد فیبوناچی استفاده میشه: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89

چرا اعداد فیبوناچی:

۱. هدف اصلی نمره دادن به استوری اینه که ارزیابی کنیم که تسک میتونه وارد اسپرینت بشه یا نه و از نمره به عنوان معیار استفاده میکنیم. برای اینکه بگیم با انجام دادن این تسک موافق فیبوناچی تسک نیستیم باید نمره ماکسیمم داشته باشیم و اگر بخوایم از اعداد معمولی استفاده کنیم باید همه اعضای تیم موافق با یک عدد برای نمره ماکسیمم باشن (مثلا عدد ۵۹. اما چرا عدد ۴۸ نباشه؟!) اما تو سری فیبوناچی برای نمره دادن به استوری، ماکسیمم نمره رو عدد ۸۹ در نظر میگیریم.

۲. برای نمره دادن به استوری عدد صفر بی معنیه اما سری فیبوناچی از عدد ۱ شروع میشه.

بعد از اعلام نمره ها نظر فردی که بالاترین نمره و پایین ترین نمره رو به تسک داده میشنویم و دوباره از اعضای تیم میخوایم که نمره نهاییشون رو دوباره اعلام کنن.

مرحله ۳:

بعد از اعلام نمره و توافق، تسک به اسپرینت ها خرد میشن و تیم در ددلاین تعیین شده کار ها رو پیش میبره.

هر روز جلسه روزانه برگزار میشه و اسپرینت ها توضیح داده میشه تا همه چی شفاف باشه و تیم در مسیر پیش بره.

مرحله ۴:

در انتهای هر اسپرینت، تیم برای پرزنت کردن تسک فیبوناچی تسک میره (همین که کل تیم برای پرزنت کردن میره باعث میشه که کار همه اعضای تیم دیده بشه نه فقط مدیر اون بخش)

مرحله ۵:
مرحله آخر گرفتن فیدبک هست و این چرخه دوباره تکرار میشه.

خب به همین سادگی، به همین کوتاهی! البته که جلسه ها خودشون کلی چالش دارن و agile به عمل سخت تره.

چگونه فعالیت‌های تجربه کاربری (UX) را در یک پروژهٔ چابک مدیریت کنیم؟

در این مقاله می‌خونید که چرا دیده شدن فعالیت‌های تجربه کاربری در تیمتون مهمه؟ و برای این کار، باید داستان کاربری، لیست کاری کانبان، و معیارهای پذیرش را چه کار کنید تا مدیریت تیم و همکاری اعضای توسعه و تجربه کاربری بهتر بشه؟

بر اساس یک تحقیق جدید، ۶۹٪ از پروژه‌های دارای کار طراحی تجربه کاربری (UX) هم ، از رویکرد چابک استفاده می‌کنند. اما از طرف دیگه، طراحی UX و روش‌های چابک همیشه متناسب باهم نیستند، چون فرایندهای چابک در اصل با در نظر گرفتن نیازمندی‌های UX ساخته نشده‌اند. به همین خاطر هم متخصص‌های UX همیشه مجبور بودند که انعطاف پذیر باشند، و کار‌شون رو با قواعد و سرعت تیم توسعه چابک هماهنگ کنند.

روش چابک معمولا در اسپرینت‌های یک یا دو هفته‌ای انجام می‌گیره، و گنجوندن همهٔ کارهای طراحی تجربه کاربری در این زمان محدود، چالش برانگیزه. به همین خاطر متخصص‌های UX معمولا یکی دو اسپرینت جلوتر از تیم توسعه کار می‌کنند و تا می‌تونند کارها رو جلوتر از تیم فنی انجام می‌دند. کارهایی مثل تحقیق رفتار مصرف کننده، آزمایش کردن نمونه اولیه، یا آماده کردن طراحی‌های نهایی برای پیاده سازی.

معیارهای روش چابک: داستان کاربر، کار (task) و استوری پوینت

در خیلی از تیم‌های چابک، برنامه‌ریزی برای ویژگی‌ها و قابلیت‌ها به شکل داستان کاربر (user story) ثبت می‌شه. یعنی برای عملکرد هر ویژگی، یک تعریف مختصر از دیدگاه کاربر می‌نویسند. در این تعریف باید روی کارهایی که کاربر می‌خواد انجام بده و اینکه اون ویژگی به چه درد کاربر می‌خوره، تمرکز بشه. شکل رایج داستان کاربری به‌صورت یک جمله است: «من به‌عنوان یک [نوع کاربر] می‌خواهم که [هدف]، تا [مزیت]». برای مثال: «من به‌عنوان صاحب حساب بانکی، می‌خوام پرداختهای بانکی را با استفاده از موبایلم انجام بدم، تا نیاز به مراجعه حضوری به بانک نداشته باشم.»

داستان‌های کاربر معمولا در یک لیست به نام بَک‌لاگ (backlog) جمع‌آوری می‌شن. در این لیست، داستان‌ها اولویت‌بندی می‌شن و هزینه‌ یا نیازمندی‌های پیاده‌سازی اون‌ها برآورد و تخمین زده می‌شه. سپس تیم برنامه‌ریزی می‌کنه که دفعه بعد روی کدوم داستان کاربر (که فیبوناچی تسک همون طور که گفتیم، یکی از ویژگی‌های محصول یا خدماتشونه) کار کنه. تیم مقدار فعالیت‌های مورد نیاز برای ایجاد و پیاده‌سازی هر داستان کاربر رو تخمین می‌زنه و معمولا به شکل استوری پوینت (story points) ثبت می‌کنه. استوری پوینت‌ها معیارهایی نسبی هستند و نه مطلق. در استوری پوینت به جای اینکه تعیین کنیم برای اتمام یک کار چند ساعت نیاز داریم، مشخص می‌کنیم که یک کار در مقایسه با کارهای دیگه چقدر کار بیشتری نیاز داره. برای مثال، یک داستان با ۵ استوری پوینت بیش از دو برابر یک داستان ۲ پوینتی کار داره.

درنهایت معیارهای پذیرش (acceptance criteria) برای یک داستان کاربری به‌وضوح مشخص می‌کنند که اون داستان باید چه مشخصات و ویژگی‌هایی داشته باشه تا بتونیم بگیم اون داستان کاربری «کامل» شده.

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

حالا برای گنجاندن فعالیت‌های UX در روش چابک، می‌شه یا کارهای تجربه کاربری رو در میان کارهای دیگه مثل توسعه گنجوند یا اینکه برای تجربه کاربری یه لیست جدا ایجاد کرد. این دو پیشنهاد را در زیر موشکافی می‌کنیم:

پیشنهاد اول: گزارش فعالیت‌های UX به‌عنوان زیرمجموعه داستان‌های کاربری

هر داستان کاربر معمولا در یک اسپرینت انجام می‌شه، هرچند که تیم‌ها اغلب روی چند داستان کاربری به‌صورت هم‌زمان کار می‌کنند. اسپرینت (sprint) یک بازهٔ زمانیه که تیم برای انجام کارهای انتخاب شده، در نظر می‌گیره. این زمان معمولا یک تا دوهفته است. زمانی که تیم UX یک یا چند اسپرینت جلوتر از تیم توسعه است، کوتاه بودن این بازه‌ی زمانی ممکنه برنامه‌ریزی و پیگیری کار رو با چالش مواجه کنه. برای فیبوناچی تسک خیلی از تیم‌ها، مسئله چالش برانگیز اینه که جای فعالیت‌های UX کجای داستان‌های کاربریه.

وقتی که فعالیت‌های UX به‌صورت مناسبی در بک‌لاگ داستان کاربری گنجونده نشه، فعالیت‌های تیم تجربه کاربری نمود کمتری پیدا می‌کنه و درنتیجه ارزش فعالیت‌هاشون پیش اعضای دیگهٔ تیم کم می‌شه. نتیجه‌اش اینه که منابع کافی در اختیار UX قرار نمی‌گیره و برنامه‌ریزی ضعیفی براش انجام می‌شه. کار خیلی زیادی سر تیم طراحی تجربه کاربری می‌ریزه و نمی‌تونند به خوبی چشم‌انداز فعالیت‌های پیشِ روی تیم رو ببینند. درنتیجه طراحان UX ممکنه بیش از حد مشغول نیازهای لحظه‌ایِ تیم بشن و تصویر کلیِ پروژه را از دست بدن.

اگر تیم شما داستان‌های کاربر رو به کارهای کوچک (task) تقسیم می‌کنه، فعالیت‌های UX رو هم در لیست کارها قرار بدید تا تلاش‌های تیم طراحی تجربه کاربری در بک‌لاگ داستان‌های کاربر به درستی منعکس بشه. این کار به اعضای طراحی UX فرصت می‌ده درباره فعالیت‌های جاری و در حال انجامِ UX به بقیه اعضای تیم آگاهی بده. مزیت دیگهٔ این کار اینه که جلسه‌های بعدی تحقیقِ کاربر برای تمام اعضای تیم قابل مشاهده می‌شه، و توسعه‌دهنده‌ها، صاحب محصول و مدیران کسب و کار را تشویق فیبوناچی تسک می‌کنه که جلسه‌های تست رو هم دنبال کنند.

برای اینکه این رویکرد رو در مدیریت پروژه‌هاتون داشته باشید، باید ابتدا یک بک‌لاگ مناسب از داستان‌های کاربری تهیه کنید و سپس کسایی مانند صاحب محصول (Product Owner)، اسکرام مَستر و تیم توسعه، داستان‌ها را برای اسپرینت‌های آینده به دقت اولویت‌بندی کنند.

پیشنهاد دوم: قابل مشاهده کردن فعالیت‌های UX با استفاده از مراحل کانبان

تیم‌هایی که علاقه ندارند داستان‌های کاربری رو به ساب‌تسک بشکنند، می‌تونند از لیست کاری کانبان برای نمایش فعالیت‌های طراحی تجربه کاربری استفاده کنند. کانبان (Kanban) روشیه برای مصوّر کردن و پیگیری مراحل مختلف تکمیل کارها. مراحل تکمیل کارهای UX باید روی لیست کاری کانبان نمایش داده بشن. لیست کاری کانبان رو می‌تونید برای فعالیت‌های طراحی UX به‌صورت زیر تقسیم‌بندی کنید:
۱. تعریف (Definition)
۲. طراحی (Design)
۳. تست کاربردپذیری (Usability testing)
۴. آماده برای توسعه‌دهنده‌ها (Ready for Developers)
۵. پیاده‌سازی (Implementation)
۶. تست تضمین کیفیت (QA) یا یونیت (QA/Unit testing)
۷. آمادهٔ ارائه (Ready to ship)
۸. ارائه شده (Shipped)

یک تسک (داستان کاربری) باید از تمام این مراحل بگذره تا بتونیم بگیم به اتمام رسیده و کامل شده. این طور استفاده از لیست کاری کانبان باعث می‌شه فعالیت‌های طراحی تجربه کاربری به‌صورت واضح و الزام‌آور پیش بره.

یک صفحه کانبان برای تجربه کاربری که در تسکولو نوشته شده است. این صفحه می‌تواند شامل فعالیت‌های کلیدی UX مانند تعریف، طراحی، و تست کاربردپذیری باشد که قبل از مرحله توسعه فنی قرار می‌گیرد. این متد، کارهای طراحی کاربری را برای همه اعضای تیم قابل مشاهده می‌کند و همکاری تیمی را تشویق می‌کند. (برای تصویر بزرگتر، روی شکل کلیک کنید)

این لیست هشت‌تایی برای خیلی از تیم‌ها مناسبه اما ممکنه تیم شما با توجه به نیازهاتون مجموعه مراحل دیگری را ترجیح بده. برای مثال، ممکنه بعضی از تیم‌ها ترجیح بدن طراحی UX رو تنها در یک مرحله انجام بدن. درحالی‌که سایر تیم‌ها فعالیت‌های طراحی تجربه کاربری را به چندین مرحله تقسیم می‌کنند. (برای مثال: نیازمندی‌ها requirements، جریان‌کاری workflow، ساختن نمونه prototyping، ایجاد تسک task creation، تست کاربردپذیری usability testing، تحلیل و آنالیز، تکرار iteration، ساختن مدل mockup creation)

افزودن فعالیت‌های UX به لیست کاری کانبان می‌تونه وضعیت یوزر استوری رو به صورتی شفاف به تمام اعضای تیم نشون بده و یک جریان کاریِ هموار و هم‌زمان را برای آنها ایجاد کنه. همچنین این کار به تیم کمک می‌کنه که با اولویت‌بندی مجدد داستان‌های کاربری، برنامه‌ریزی مجدد فعالیت‌ها و محول کردن دوباره کارها، به چالش‌های پیش‌بینی‌نشده پاسخ بدن.

برای فعالیت‌های UX داستان‌های کاربری جداگانه در نظر نگیرید!

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

معیارهای پذیرش UX را در داستان‌های کاربری دخالت دهید

در فرایندهای چابک رایج، وقتی‌که تیم، داستان‌های کاربری را تعریف می‌کنه، اینکه معیار تکمیل و پذیرش (completion or acceptance criteria) اون داستان کاربری چیست رو هم تعریف می‌کنه. معیارهای پذیرش از قدیم متمرکز بودند بر تست‌های تضمین کیفیت QA / unit با هدف اینکه مطمئن بشن در پیاده‌سازی باگ وجود نداره. ولی نکته مهم اینه که باید در این معیارها، تجربه کاربری رو هم در نظر بگیریم. معیارهای پذیرش تجربه کاربری در شروع می‌تونند تابع استانداردهای واسط کاربر (UI) باشند. برای مثال، «تمام عناصر واسط کاربر به ظاهر، حس و رفتاری که در راهنمای سبک فرانت-اند مشخص کردیم، پایبند باشند» و یا «محصول نهایی تا ۱۰ پیکسل پس و پیش، مطابق مدل طراحی (mockups) باشد». علاوه بر اینها معیارهای کاربردپذیری را هم به معیارهای پذیرش تجربه کاربریتان اضافه کنید، مانند اینکه «طی تکمیل تسک الف، کاربر با هیچ‌گونه مشکل کاربردپذیری مواجه نشود.»

در سازمان‌هایی که طراحی تجربه کاربری به بلوغ کافی رسیده و مدیریت هم اعتماد کاملی به تیم UX داره، حتی معیارهای کمّی هم می‌تونند به‌عنوان معیارهای پذیرش در نظر گرفته بشن، مانند « کاربران، فرایند پرداخت را در دو دقیقه یا کمتر انجام دهند». ممکنه کامل کردن تست‌های بنچمارکِ کمّی (quantitative benchmarking tests) در طول یک اسپرینتِ چابک تا حدودی سخت باشه، و یا نتایج آماریِ به‌دست‌آمده از یک تحقیق کوچک ممکن است آن‌چنان هم قابل استناد نباشه. اما افراد حرفه‌ای UX می‌تونند تشخیص بدن که آیا فرایند طراحی در مسیر درست و رضایت‌بخشی قرار داره یا نه. این معیارها باعث ایجاد استانداردهای باکیفیت می‌شند. همچنین تیم رو مجبور می‌کنند قبل از ارائه محصول، در تست‌های کاربردپذیری شرکت داشته باشند.

برآورد استوری پوینت‌های تجربه کاربری

خیلی از تیم‌هایی که از فرمت یوزر استوری برای رهگیری کار استفاده می‌کنند، از استوری پوینت (story point) برای برآورد تلاش‌ها و فعالیت‌ها بهره می‌گیرند؛ اما چون طراحی تجربه کاربری معمولا پیش از توسعه فنی انجام می‌شه، بیشتر متخصص‌های UX که در تحقیق بالا باهاشون صحبت شده ترجیح می‌دن که فعالیت‌هاشون رو جدا از تیم توسعه برآورد کنند. دو برآورد جداگانه (یکی برای توسعه و یکی برای UX) به هر یک از زیرتیم‌ها اجازه می‌ده که کارایی خودشون رو بالا ببرند و از تمام ظرفیت‌ها استفاده کنند. به‌طور خاص، تیم طراحی تجربه کاربری می‌تونه برنامه‌ریزی کنه که روی چند داستان کاربری به طور همزمان کار کنه و یا بیش از یک اسپرینت به بعضی از داستان‌های کاربری اختصاص بده.

توسعه‌دهنده‌ها برای برآورد فعالیت‌هاشون چند سیستم‌ محبوب دارند ازجمله، سری‌های اعداد صحیح، سری فیبوناچی و توان‌های دوم. اما افراد حرفه‌ای طراحی تجربه کاربری ترجیح می‌دن که از فرمت‌هایی مانند سایزبندی تی‌شرت (S, M, L, XL) استفاده کنن. این سیستم به تیم UX اجازه می‌ده تلاش‌هاشون رو به شیوه‌ای برجسته و بدون تاثیر روی معیارهای سرعت سایر تیم‌ها، نشون بدن. البته این را هم باید مدنظر داشته باشید که استوری‌پوینت‌های جداگانه برای UX می‌تونه روی انسجام تیم تاثیر منفی بگذاره و باعث شه تیم UX به‌عنوان یک واحد کاری جداگانه در نظر گرفته شه، شبیه چیزی که در فرآیندهای توسعه آبشاری می‌بینیم. اگر می‌خواید استوری‌پوینت‌های UX رو به‌صورت جداگانه برآورد کنید، باید درنهایت برآوردهای جداگانهٔ تیم طراحی تجربه کاربری را با برآوردهای سایر تیم‌ها یک کاسه کنید.

نتیجه‌گیری

یکپارچه کردن تجربه کاربری و رویکرد چابک یک فرآیند پیچیده است. اما انعکاس فعالیت‌های UX در داستان‌های کاربری، به برنامه‌ریزی و زمان‌بندی کارها کمک می‌کند و همچنین همکاری میان اعضای تیم را بهبود می‌دهد.