بطور کلی نوع نوشتن یوزر استوری مناسب می تواند در مسیر چابک شدن تیم اسکرام تاثیر زیادی بگذارد. زیرا در ادامه راه بعنوان یک مبنا برای سنجش میزان کارها (از طریق استوری پوینت) قرار گرفته می شود و همچنین می تواند در جلوگیری از پیچیدگی های بی مورد و زمان گیر جلوگیری کند. به عبارتی شما با انجام این کار از هدر رفت زمان در آینده ای نزدیک جلوگیری می کنید.
روشهای مورد نیاز:
دو روش موفقی که بسیار مورد استفاده قرار می گیرند روش توسعه رفتار محور و روش توسعه فرضیه محور می باشند. مواقعی وجود دارد که شما از یکی یا از هر دو استفاده می کنید و زمانهایی نیز بسته به شرایط شما از روشی متفاوت. فراموش نکنید که نوشتن یوزر استوری از زمان برنامه نویس مفرط یا همان ایکس پی تا به امروز بنا بر نیازهای متفاوت شرکتها گستردگی زیادی را شاهد بوده است.
روشBehavior Driven Development (BDD)
از آنجایی که این امر از یک نیاز آماری و محاسباتی ناشی می شود، منطقی است که داستان های کاربر خود را شخصی سازی کنیم. یکی از راه های خوب این شخصی سازی، ادغام آن با روش توسعه رفتار محور می باشد و اطلاعات بیشتری در مورد آنچه مورد نیاز است، چرا مورد نیاز است و زمینه های اضافی را در یوزر استوری وارد کنید.
مثال:
به عنوان [نقش] من [ویژگی] را می خواهم بنابراین [سود]
ملاک پذیرش
با توجه به [متن]
وقتی [رویداد]
سپس [نتیجه]
همانطور که مشاهده می کنید چرایی و چیستی در این روش به راحتی به یک شخص فنی و حتی غیر فنی به راحتی انتقال داده می شود. همچنین، مقدار در جمله اول انتقال داده شده و معیارهای پذیرش به راحتی قابل آزمایش است.
روشHypothesis Driven Development (HDD)
روش توسعه فرضیه محور یک گام به عقب تر رفته و از انتقال خروجی های تجاری باز می گردد و می پرسد: چگونه بفهمیم که خواسته مد نظر برای کاربر نهایی ارزشمند است یا خیر؟
مثال:
ما معتقدیم که <این قابلیت>
منجر به <این نتیجه> خواهد شد
وقتی <سیگنالی قابل اندازه گیری می بینیم> می فهمیم که موفق شده ایم
آنچه مدیران عالی محصول روی میز می آورند ، نه تنها مجموعه ای از ایده های عالی از طرف خود ، طراحان ، مهندسان ، سهامداران و کاربران است ، بلکه توانایی آزمایش این ایده ها ، تفسیر نتایج و تصمیم گیری آگاهانه تر است.
توسعه فرضیه محور شما را در راه ایجاد یک فرضیه قوی کمک می کند و تعیین می کند که چگونه موفقیت ، ایمنی و رفتار را از ابتدا اندازه گیری کنید. این روش از زمان صرف شده و دلسردی تیم از آزمایشاتی که پس از انجام یک یوزر استوری میتواند گرفتار آن شود، جلوگیری می کند.
سفارشی سازی
مواقعی وجود دارد که شما نیاز دارید یوزر استوری را برای یک پروژه سفارشی کنید. البته که در همه موارد این سفارشی سازی به معنی بهتر کردن داستان شما نیست و باید آن را بر اساس نیاز خاص به محصول اضافه کرد و نه ترجیح. وقتی که مشتری برای یک محصول افزودن معیاری را برای تست یکی از ویژگی های نرم افزار خود تقاضا می کند جزو این نیازهای خاص است.
قالب:
از بین همه افرادی که <اقدام> می کنند (جمعیت)
چند <action> (عدد)
در <مشاهده> (مخرج)
از آنجایی که این امر از یک نیاز آماری و محاسباتی ناشی می شود، منطقی است که داستان های کاربر خود را شخصی سازی کنیم. یکی از راه های خوب این شخصی سازی، ادغام آن با روش توسعه رفتار محور می باشد و اطلاعات بیشتری در مورد آنچه مورد نیاز است، چرا مورد نیاز است و زمینه های اضافی را در یوزر لستوری وارد کنید.
مثال:
به عنوان [کاربر] [متریک] را می خواهم تا [بتوانم ویژگی جدید را آزمایش کنم]
ملاک پذیرش:
با توجه به وجود داده ها
وقتی از معیار بازدید برای خرید در صفحه اصلی استفاده می کنم
سپس نتیجه ای را مشاهده خواهم کرد:
از بین همه افرادی که از صفحه اصلی بازدید کرده اند (جمعیت)
چه تعداد روی دکمه "خرید" کلیک کردند (عدد)
برای بازدید از صفحه اصلی (مخرج)
اما جدای از اینکه چارچوب نوشتن یوزر استوری شما کدامیک است، رعایت نکاتی در همه این روشها بسیار ضروری است و باید به آنها توجه کرد. نکاتی که باید رعایت شوند عبارتند از:
1. بدون ابهام بودن
صفات یکی از مهمترین منابع ایجاد ابهام در یوزر استوری هستند. صفاتی مانند خوب، عالی، بهتر، کامل، عادی و... را در نظر بگیرید. بدلیل انتزاعی بودن این صفات معنا و شکل استفاده آنها برای افراد مختلف، متفاوت می باشد و این موضوع می تواند باعث ایجاد سوءتعبیراتی از یوزر استوری شود. بعنوان مثال بجای «کاربر می تواند با کلیکهای خیلی کم به کارایی الف برسد» میتوانید بگویید:«کاربر می تواند با 3 کلیک به کارایی الف برسد».
منبع ابهام دیگری که باید به آن دقت کرد فعلها هستند. فعلها مخصوصا با گرایش به گذشته می توانند دردسرهایی را برای تبیین درست یوزر استوری ها ایجاد کنند. افعالی مانند: انجام خواهد شد، تعریف می شود، در دسترس بوده است و استعلام شده بود جزو این گروه هستند که به روان و ساده بودن یوزر استوری لطمه می زنند. در کل استفاده از استفاده از جملات کوتاه و ساده بهترین راهکار برای یک یوزر استوری خوب و مناسب است و باعث می شود که از تعبیرات دوگانه دوری شود.
2. کامل بودن
برای اینکه تیم بتواند بیشترین درک را از بک لاگ محصول داشته باشد، یوزر استوری باید تمام اطلاعات مورد نظر را داشته باشد. نباید فراموش کنیم که اگر هنگام نوشتن یوزر استوری در دادن اطلاعات تکمیل کننده و جامع خساست به خرج دهیم در طول جلسات اسپرینت باید زمان اضافه ای را برای تکیل آن صرف کنیم.
3. با ثبات بودن
ثبات و تقارن خواسته های ما یکی از اصلی ترین ویژگی های مورد نیاز در اسکرام هستند. فراموش نکنید که هدف ما در پروژه حل کردن یکه مساله پیچیده می باشد و نباید خودمان با تغییر در نوع ارایه خواسته هایمان از تیم باعث پیچیدگی و سردرگمی آنها شویم. ثبات در نیازها حتی در مابقی متد های مدیریت پروژه هم از اهمیت بالایی برخوردار است. اگر پرهیز از دوباره کاری ها در تیم خود هستید حتما به این نکته توجه ویژه کنید.
4. امتیاز بندی شده بر اساس اهمیت
عنوان بهتر برای این ویژگی نوشتن یوزر استوری با این پیش فرض که قرار است بر اساس اهمیت کار امتیاز دهی و درجه بندی شوند، است. در توسعه یک محصول چابک باید به این نکته توجه شود که چیزی که از همان ابتدا برای تیم مهم است امتیاز بندی بک لاگ مخصول می باشد و این صرفا یک ارزش گذاری تجاری نیست و کارهای مورد نیاز برای رسیدن به آن ویژگی هم شدیدا مد نظر تیم است.حتی همه فعالیتهای تیم در طول اسپرینتهای پیش رو و نسخه های اولیه نرم افزار تحت تاثیر همین موضوع هستند.
5. مستقل بودن
یوزر استوری ها باید مستقل باشند. اهمیت این نکته هم در زمان امتیاز بندی بک لاگ محصول و هم در جلسه برنامه ریزی اسپرینتها گریبانگیر ما خواهد شد. البته در رعایت این نکته باید حواسمان به این موضوع هم باشد که نباید بین مستقل بودن یوزر استوری و کامل بودن آن یکی را فدای دیگری کنیم.
6. قابل تست بودن
قابل تست بودن به این معنی است که هر کسی می تواند وارد آن شود و بررسی کند که آیا داستانهای کاربر کار می کنند یا نه. در اینجا هم باز باید از استفاده از صفات دوری کرد. از عباراتی مانند کاربر پسند و به خوبی کار کند استفاده نکنید.
7. نحوه اجرا و پیاده سازی الزامات یوزر استوری را مشخص نمی کند
البته پیشنهاد دادن به تیم ممنوع نیست و همانطور که تیم توسعه می تواند ویژگی های کاربردی را پیشنهاد دهند، صاحب محصول می تواند پیشنهادات فنی ارائه دهد. اما نیازی به وسواس در این کار نیست و باید توجه داشت که نحوه اجرای کار در نهایت توسط تیم مشخص می شود.
8.توافقی بودن
چیزی که نباید هیچوقت از یادتان برود هدف نوشتن یوزر استوری است. شما قرار است نیازهای مشتری را در قالبی مشخص به تیم منتقل کنید. پس نباید از چیزی که مد نظر مشتری است فاصله بگیرید و در نظر داشته باشید که بهترین محصولی که از یوزر استوری شما حاصل می گردد وقتی است که توافق شکل گرفته با مشتری در آن به طور واضح بیان شده باشد.
9.قابل مذاکره بودن
اولین کسانی که بعد از نوشتن یوزر استوری نظرات خود را حول آن وارد می کنند، اعضای تیم می باشند. اما آنها تنها کسانی نیستند که با آنها سر و کار دارید. مشتری و مدیران بالا دستی را هم باید وارد لیست کنید تا متوجه شوید قابل مذاکره بودن چیزی که می نویسید چقدر مهم است. در یک داستان کاربر باید به وضوح مشخص شود که خواسته ها و چراها به گونه ای قابل آزمایش است که هم توسط مهندسی و هم از نظر تجاری قابل درک باشد.
نتیجه گیری نهایی
اکنون ما آشنایی خوبی با روشهای نوشتن یوزر استوری و همچنین نکات مهمی که باید رعایت کنیم، داریم. اما این پایان راه نیست و نوشتن یوزر استوری خوب نیاز به کسب تجربه در یک محیط تجاری جدی هم دارد. فاکتورهای زیادی وجود دارد که باید در هنگام قضاوت در مورد اینکه آیا یک داستان به نتیجه دلخواه خود می رسد در نظر گرفته شود ، از جمله اینکه آیا یک ساختار ، اندازه داستان ، برش های عمودی در مقابل برش های افقی و موارد دیگر دارد. یک روش آسان برای قضاوت این است که از روش INVEST بیل ویک استفاده شود.
در پایان باید به این نکته هم اشاره کنم که یوزر استوری بعنوان یک ابزار مدیریت پروژه در نظر گرفته می شود که به دستیابی نتیجه محصول کمک می کند. پس از وسواس بیش از حد در انتخاب روشها بپرهیزید و سعی کنید به هدف اصلی این ابزار وفادار بمانید.
