یکی از مشکلات اساسی در پروژه های نرم افزاری ارتباط مابین نفرات فنی و تجاری است. در واقع نبود یک زبان مشترک موجب می شود تا اکثر اوقات کج فهمی هایی در درک نیازهای واقعی مشتری اتفاق بیفتد. تیم های چابک نیز از این قاعده مستثنی نیستند و طبق تجربه این دوستان نیز با چنین مشکلی مواجه می شوند. قاعده یا فرمول کلی برای ثبت وضبط نیازمندی ها در روش های چابک وجود ندارد و شاید همان روش قبلی خودمان جوابگو باشد. ولی اکثر تیم های چابک از داستان کاربری(User Story) جهت این منظور استفاده می کنند. اما در استفاده از این روش باید حواسمان به چند نکته باشد که در این نوشته می خواهیم به آنها بپردازیم.
داستان کاربری چیست؟
داستان کاربری یک روش برای توضیح قابلیت یا ویژگی مورد نظر از زبان کسی است که نیازمند آن است(که معمولا کاربر یا مشتری است). خاصیت ویژه این توضیح، کوتاه و مختصر بودن آن است.
قالب داستان کاربری :
بعنوان <نوع کاربر> من می خواهم <قابلیت> تا بتوانم <دلیل>
یا ساده تر : من کی هستم – چی می خام – چرا این رو می خام
مثال :
- بعنوان کسی که زیاد به مسافرت میروم من می خواهم لیست بلیط های صادرشده خودم را ببینم تا بتوانم سریع دوباره به همان مقصد بلیط رزرو کنم
- بعنوان مسافر هتل من می خواهم رزرو اتاق را کنسل کنم تا بتوان پول خود را پس بگیرم
- بعنوان مدیر وبلاگ من می خواهم مطلب جدید در وبلاگ پست نمایم تا خوانندگان آن مطلب را بخوانند
- بعنوان کاربر آفیس ورد من می خواهم متن انتخاب شده را بولد کنم تا خواننده متوجه تاکید من بر این قسمت شود
چرا باید از داستان کاربری استفاده کنیم؟
- شرط اختصار و قابلیت برنامه ریزی
در نوشتن داستان کاربری تاکید بر این است که شرط اختصار رعایت شود به صورتی که ما روی یک استیکی نوت نیازمندی مورد نظر را بنویسیم. این باعث می شود که در جلسات برنامه ریزی بتوانیم به راحتی با آنها کار کنیم. اگر تجربه خواندن صفحات متعدد خصوصیات یک نیازمندی را داشته باشید حتما می دانید که از چه صحبت می کنیم. اصولا وقتی توضیحات زیاد در مورد یک نیازمندی نوشته شده است دیگر کسی حوصله خواندن آن را نخواهد داشت و همه سعی خواهند کرد که سریع سراغ مورد بعدی بروند.
- صحبت به جای نوشته
در تفکر چابک ما ارزشی داریم بعنوان “ارتباط با مشتری بالاتر از پیروی قرارداد”. این یعنی که به “نوشته بسنده نکن”. فرض کنید اسپرینتی شروع می شود و فرض می کنیم همه نیازمندی هایی که مشتری یا مالک محصول در بک لاگ محصول قرار داده درست است و شروع می کنیم به ساختن آنها. در واقع هدف ما برآورده کردن این نوشته یا همان قرار داد مابین طرفین است و نه بر طرف کردن نیاز واقعی مشتری یا کاربر.
پس داستان کاربری تاکید بر صحبت و تعامل بر روی نیازمندی ها دارد، به همین دلیل است که شرط اختصار رعایت می شود تا در جلسه برنامه ریزی جزئیات نیازمندی با صحبت بین طرفین معلوم و پدید آید.
- نیاز به جای راه حل
در برخی موارد نفرات تجاری سعی می کنند به جای پرداخت به نیاز واقعی به راه حل اشاره کنند. داستان کاربری با ایجاد شرایط صحبت و فرمت خاص خود باعث می شود تا این دوستان فقط بر روی نیاز خود تمرکز کرده و راه حل را به تیم توسعه بسپارند. مثال پایین را با هم بررسی کنیم که برای یک فروشگاه اینترنتی است :
“بعنوان خریدار من می خواهم به سایت لاگین کنم تا لیست خریدهای خودم را ببینم”
مشکل یا مورد این نیازمندی چیست؟ اگر تیم بدون صحبت بخواهد این کار را شروع کند چه می شود؟ شاید اگر تیم با مالک محصول کند که نیازمندی واقعی تو لاگین هست یا دیدن لیست خرید ؟ شاید تیم بتواند بگوید که ما می توانیم تمامی لیست خرید ها را به ایمیل خریدار ارسال نماییم تا دیگر او نیازی به لاگین به سایت نداشته باشد و شایدهای دیگر.
- خروجی که کار می کند به جای کار ناقص
یکی از ویژگی های مهمی که هر داستان کاربری باید داشته باشد این است که شرایط پذیرش کار مشخص شده باشد بدین صورت که یک توسعه دهنده پس از اتمام کار خود با پاس کردن شرایط پذیرش بتواند اطمینان حاصل کند که این نیاز مشتری را بر طرف خواهد کرد. ما در روش اسکرام تاکید داریم که به صورت Iterative Incremental کار می کنیم. Incremental یا افزایشی بودن کار به این معنی است که خروجی تکرار یا چرخش قابل استفاده است. مثال هایی از شرایط پذیرش :
- همه فیلدهای اجباری قبل از پست کردن فرم باید توسط مشتری پر شده باشند.
- پرداخت توسط همه کارت های شتاب قابل انجام باید باشد.
- پس از پرداخت حتما ایمیل حاوی اطلاعات پرداخت به مشتری ارسال شود.
یک داستان کاربری خوب چه ویژگی هایی باید داشته باشد؟
اصطلاحا در بین علمای چابک اعتقاد بر این است که داستان کاربری باید INVEST باشد :
- Independent : غیر وابسته باشد به صورتی که بتوان یک داستان را در یک اسپرینت بدون پیش نیاز یا پس نیاز انجام داد.
- Negotiable : هدف انجام نوشته نیست و این نوشته هم وحی منزل نیست و تیم می تواند بر روی دامنه یا نحوه انجام آن تعامل نماید.
- Valuable: کاری که انجام می شود برای مشتری یا کاربر با ارزش باشد، یعنی بعبارتی کارها یا نیازمندی به گونه ای نوشته شوند که نتیجه کار برای مشتری با ارزش باشد.
- Estimable : قابل تخمین زدن باشد، یعنی به اندازه ای جزئیات آن در آمده باشد تا تیم بتواند آن را تخمین بزند.
- Small یا Size : اندازه آن به گونه ای باشد که در یک اسپرینت قابل انجام باشد.
- Testable : قابل تست باشد و به گونه ای نباشد که کار یا خروجی نهایی توسط تیم قابل تست نباشد.
اما همه این ها در مورد یک داستان کاربری خوب است و همیشه قابل انجام برای هر نیازمندی نیست.
نکات مهم در مواجهه با داستان کاربری:
- صحبت فراموش نشود
بسیاری از تیم هایی که من دیدم سعی می کنند نوشته ها را ثابت در نظر بگیرند و شروع می کنند به تحلیل فنی کار و به اینگونه هیچ تعاملی مابین تیم و مالک محصول برای تغییر خود نیازمندی یا راه حل اتفاق نمی افتد.
روش های چابک بر اصل سادگی یعنی هنر به حداکثر رساندن کار انجام نشده تاکید دارند، یعنی بعضی اوقات می توان نیازمندی را از لیست حذف کرد و آن را انجام نداد ولی باید صحبت کرد و تعاملات را افزایش داد.
- داستان کاربری ضروری نیست ولی روح آن الزامی است
بعضی تیم ها دوست دارند به روش سنتی خود با نیازمندی ها مواجهه کنند، که این از نظر من مشکلی ندارد منتهی باید حواسشان باشد که اصول و روح چابکی (مانند تعامل و پی بردن به نیاز واقعی کاربر) در روش های آنها وجود داشته باشد.
- سومین بخش یا دلیل داستان مهم است
طبق تجربه مشاهده شده بعضی از مالکین محصول یا تیم ها علاقه ای به نوشته بخش سوم داستان ها ندارند و آن را یا اصلا نمی نویسند یا سرسری رد می کنند. بخش سوم که در مورد دلیل یا چرایی کار است بیشتر به نیت یا هدف کاربر اشاره دارد، این بخش به دو دلیل مهم است :
- نیاز واقعی کاربر یا مشتری معلوم می شود و شاید بتوان با یک قابلیت دیگر یا روشی دیگر همان نیاز را برطرف کرد.
- ما می توانیم یک پیش بینی از آینده نیز داشته باشیم که برای مثال امروز که صفحه لاگین می زنیم فردا هم باید صفحه لیست سفارشات طراحی کنیم و این دید کلی به تیم برای طراحی می دهد و از دوباره کاری جلوگیری می کند.
- نوشتن داستان کاربری به همراه تیم
اگر نوشتن و ایجاد داستان های کاربری به همراه و کمک خود تیم باشد، برنامه ریزی و همکاری خوب تیم در آینده به همراه خواهد داشت. بعضی جاها مشاهده شده مالکین محصول به تنهایی این موارد را می نویسند و یک لیست در اختیار تیم قرار می دهند که تیم موظف می شود از بالا شروع کند تا به پایین انجام دهند. در این صورت اولا کج فهمی بیشتری اتفاق خواهد افتاد ثانیا همراهی تیم کمتر خواهد بود.
- جزئیات فنی در دل داستان کاربری
اصولا بین علما اختلاف است که آیا داستان های فنی باید به صورت جداگانه نوشته شوند یا به همراه داستان های کاربری. در جواب باید بگویم جواب درست وجود ندارد، اما طبق تجربه برای داستان های فنی که ماهیت مستقلی دارند می توان به صورت داستان مجزا اقدام کرد (مثل نصب ویندوز سرور برای راه اندازی محیط توسعه). اما برای موارد یا جرئیات فنی بهتر است از Task فنی در داخل خود آن داستان کاربری استفاده کنیم. اصولا تاکید بر این است که داستان ها باید برای مشتری نهایی ارزشمند باشد، ولی اغلب داستان های فنی برای مشتری ارزشمند نیست به همین دلیل ترجیح داده می شود که از ترکیب این روش ها استفاده شود.
- شکستن کارها به میزان لازم
یکی از سوالات مهمی که پرسیده می شود این است که کارها چه میزان شکسته شوند؟ باید توجه داشته باشید که ما قرار نیست از اولین روز همه کارها را بشکنیم اصولا این کار یک فرآیند تدریجی است و به مرور کارها را می شکنیم. اگر به اندازه دو یا اسپرینت بعدی کار به اندازه خوب داشته باشیم (به اندازه ای که قابل تخمین باشند و حداکثر در یک اسپرینت انجام شوند) کافی است. هر چه قدر هم جلو می رویم می توانیم برای دو اسپرینت بعدی همان کار را تکرار نماییم. اگر در هر اسپرینت بتوانیم دو یا سه داستان کاربری را انجام بدهیم، معمولا اندازه آنها خوب است، نه خیلی کوچک و نه خیلی بزرگ.
- داستان کاربری به همراه ریشه یا دسته
وقتی تعداد داستان های کاربری بالا می رود، مدیریت و اولویت بندی آنها کار سختی می شود برای همین می توانیم از ریشه یا دسته استفاه کنیم. بدین صورت که هر دسته/ریشه حاوی چندین داستان کاربری است و ما به جای اولویت بندی داستان های کاربری، دسته ها را اولویت بندی می کنیم. در این حالت به راحتی می توان یک دید کلی نسبت به بک لاگ محصول داشت و برنامه نگه داری آن را به راحتی به پیش برد.
برای مثال : ریشه مدیریت ایمیل حاوی :
- ارسال ایمیل
- گرفتن ایمیل
- لیست ایمیل ها
همه کاربر نیستند
یکی دیگر از موارد شایع این است که همه کاربر هستند “بعنوان کاربر این رو می خوام” “بعنوان کاربر اون رو می خواهم”. در هر سیستمی همه کاربر نیستند و نقش های متفاوتی وجود دارند. مانند مدیر سیستم، مدیر عملیات، بازدید کننده و … . حتی اگر چنین نقش های ملموسی وجود ندارند می توانید از پرسونا یا شخصیت استفاده کنید، به صورتی که چند نفر فرضی با نام و عکس و مشخصات ایجاد نمایید و از آنها بعنوان نقش ها استفاده کنید. این به ما کمک می کند تا به نیازمندی ها از زوایای مختلف نگاه کنیم و بتوانیم به نیازهای واقعی مشتری یا بازار نزدیک تر شویم.
- “بعنوان کسی که زیاد مسافرت می کنم …”
- ” بعنوان مشتری طلایی هتل …”
- “بعنوان کاربر بازدیده کننده …”
در نهایت چابک و موفق باشید
ممنون بابت مطلب خوبی که راجع به داستان کاربر نوشته اید. اما به نظر من جای دو مطلب که بسیار با داستان کاربر در ارتباط است خالی می باشد.یکی
acceptance criteria و دیگری definition of done. که به نظر می رسه تنها با وجود این دو مورد می توان به نتیجه ی داستان کاربر اعتماد کرد.
ممنون از تذکر، البته در مورد شرایط پذیرش در بند “خروجی که کار می کند به جای کار ناقص” تقریبا توضیح داده شده است. ولی چشم در پست های بعدی به این موارد هم خواهیم پرداخت.
همچون قبل عالی. فقط یک سوال. گفتی که PBI خوب آن است که بدون پیش نیاز باشد. اما این عملا غیر ممکن است. شما در بسیاری از حالات نیازمند پیش نیاز هستید. بطور مثال PBI های epic وقتی شکسته می شوند عمدا به مواردی شکسته می شوند که ترتیب در اجرای آنها مهم است. یا حتی گزارش های سیستم. در بسیاری از موارد گزارش ها را تا زمانی که بخش های مختلف سیستم تکمیل نشده باشد نمی توان شروع کرد و حتی اگر هم بتوان شروع کرد صحیح نیست. چراکه سیستم در طول زمان تکمیل می شود و گزارش معمولا در انتهای چرخه باید تولید شود در غیر اینصورت بارها و بارها باید بازنویسی، تصحیح و تکمیل شود یا اینکه از ابتدا تحلیل کاملی از وضعیت سیستم داشت که با اصل scrum منتطبق نیست.
تصور می کنم این موضوع نسبی باشد و با واژه “بهتر است” آغاز گردد
همانطور که خودتون فرمودید گفتیم “خوب است”، یعنی همان “بهتر است”، در هر صورت ممنون بخاطر فیدبک موثر که شاید در انتخاب واژه ها بیشتر دقت کنیم (: