در سیستم Agile، قابلیت‌های کاربردی به صورت تدریجی توسعه می‌یابند و User Story اینکرمنتی هست که تیم موافقت کرده است به مشتری یا کاربر تحویل دهد. هر User Story باید به محصول ارزش اضافه کند. همانطور که می دانیم، داستان های کاربر معمولا توسط مالک محصول یا مدیر محصول نوشته می شود و سپس برای تایید ارسال می شود. با این حال، هر کسی که درک خوبی از مشکلات و نیازهای مشتری دارد، می‌تواند داستان‌های کاربر "User Story" را بنویسد. اما هر کسی که داستان کاربر را می نویسد باید به وضوح توضیح دهد که کاربر نهایی یا مشتری کیست، چه کاری باید انجام شود، چرا باید انجام شود، و چه ارزشی به آن افزوده می شود. یک داستان کاربر که به خوبی نوشته شده باشد بر چرخه عمر آن " Life Cycle" در هر مرحله تأثیر می گذارد.
چرخه عمر یوزر استوری
هنگامی که از چرخه عمر یک داستان کاربر صحبت می کنیم، به معنای مراحل مختلفی است که قبل از اینکه انجام شده در نظر گرفته شود و مقدار مورد نظر را تحویل دهد، از آن عبور می کند. اولین مرحله از چرخه عمر یوزر استوری در Agile زمانی است که الزامات مشتری تعریف می شود و چرخه حیات زمانی به پایان می رسد که داستان کاربر به کاربر تحویل داده شود. این یک ابزار ضروری برای پیگیری چگونگی توسعه محصول و کیفیت آن است. لایف سایکل داستان کاربر نیز برای نظارت بر سرعت پیشرفت محصول ضروری است. یکی دیگر از کاربرد های قابل توجه لایف سایکل یوزر استوری افزایش شفافیت در کار تیم است زیرا فعالیت های آن بیشتر قابل مشاهده است. قبل از قرار دادن داستان کاربر در Sprint، از سه تا C عبور می کند، یعنی کارت"Cards"، مکالمه"Conversation" و تأیید"Confirmation". این به این معنی است که داستان را روی کارت ها بنویسید، در مورد داستان با تیم بحث کنید و سپس معیارهای پذیرش"Acceptance Criteria " برای داستان کاربر" User Story" را تأیید کنید.
پس از انجام این کار، داستان کاربر برای کار آماده است. اکنون چرخه عمر"Life Cycle" آن شروع می شود و مراحل مختلفی را پیش از تحویل نهایی به مشتری می گذراند. اکنون در مورد این مراحل مختلف چرخه حیات یک داستان کاربر بحث خواهیم کرد.
کارگاه داستان نویسی
اولین قدم در چرخه حیات یوزر استوری، برگزاری کارگاهی برای نوشتن یوزر استوری است. یک چشم انداز محصول قبلا ایجاد شده است. هدف کارگاه یوزر استوری نویسی بیان دیدگاه از ویژگی های محصول در قالب داستان های کاربری است. اما برای این کار باید مطمئن شوید که Epic ها را در اولویت قرار داده اید. شما یوزر استوری ها را فقط از دل اپیک ها ایجاد خواهید کرد. به این ترتیب، بک لاگ پر خواهد شد و در کل پروژه استفاده می شود. وقتی کار در کارگاه تکمیل شد، تیم تعداد زیادی داستان کاربر" User Story" دارد که هر کدام حاوی اطلاعات مخصوص به خود هستند. ترجیحاً این کارگاه باید یک تلاش مشترک تیمی باشد. کارگاه داستان نویسی معمولاً یک جلسه طوفان فکری است که معمولاً شامل: مشتری، مدیر محصول، توسعه دهندگان و آزمایش کنندگان است. همچنین در طول این کارگاه تیم در مورد طول تکرار "iteration" و سرعت تیم"velocity" تصمیم می گیرد.
اولویت بندی داستان های کاربر
مرحله بعدی در چرخه حیات یوزر استوری ها اولویت بندی کردن انهاست. هدف در اینجا قرار دادن یوزر استوری های مختلف به ترتیب ضرورت تکمیل آنها است. بنابراین، پس از جمع‌آوری داستان های مختلف روی کارت‌ها، مالک محصول برای تعیین اولویت خود اقدام می کند. اولویت بندی مهم است زیرا تیم Agile نمی‌تواند روی تمام داستان‌های کاربر که روی برد قرار دارند کار کند. بنابراین، طبیعی است که آنها را اولویت بندی کنند. در اینجا، فوریت هر داستان در برابر تمام داستان‌های موجود در فهرست سنجیده می‌شود. نظرات، ایده‌ها و بازخورد برنامه‌نویس نیز هنگام تصمیم‌گیری اولویت در نظر گرفته می‌شود. یکی از روش‌های متداول برای تصمیم‌گیری اولویت، MoSCoW است.
در این روش از اولویت بندی شامل جدولی با موارد زیر است:
مواردی که باید داشته باشد"Must have" (ضروری است)
خوبه که داشته باشید "Should have" (ضروری نیست اما اهمیت دارند)
بد نیست که داشته باشید"Could have" (ضرورت ندارد و اهمیت بالایی هم ندارد)
نیاز نیست داشته باشید "Will not have" ( هیچ اهمیتی ندارد)
ویژگی‌های ضروری آنهایی هستند که باید در محصول وجود داشته باشند، به این معنی که ضروری هستند و اساس محصول هستند. ویژگی های Should have می تواند در محصول گنجانده شود تا به آن ارزش افزوده شود، و اولویت پس از تکمیل ویژگی های ضروری تعیین می شود. ویژگی‌های Could-have مواردی هستند که اگر به محصول اضافه شوند، می‌توانند ارزش بیشتری به آن اضافه کنند. با این حال، می توان از این ویژگی ها با محدودیت بودجه یا زمان جلوگیری کرد. و در نهایت، آنها ویژگی هایی نخواهند داشت که ارزش کمتر یا بدون ارزشی برای محصول داشته باشند و بنابراین می توان آنها را نادیده گرفت. اینها ویژگی هایی هستند که مشتری زیاد در مورد آنها اذیت نمی شود. هنگامی که اولویت تعیین می شود، تیم شفافیت دارد که تمرکز خود را در کجا باید قرار دهد، بنابراین جهت درست را به آن می دهد. در پایان، باید استدلال منطقی برای اولویت تعیین شده ارائه کرد، به این معنی که برای همه باید روشن شود که چرا یک داستان خاص بر داستان های دیگر در اولویت قرار گرفته است.
Backlog Refinement:
هدف از پالایش بکلاگ اطمینان از آماده بودن داستان ها برای اجراست. توسعه دهندگان گرد هم می آیند تا موانع فنی را که ممکن است ظاهر شوند یا وابستگی به تیم های دیگر را برطرف کنند. سپس تجزیه و تحلیل هزینه و فایده نیز برای توضیح هزینه های مربوطه و سود احتمالی آن انجام می شود. بنابراین، چندین داستان با اولویت بالا در نظر گرفته شده است که تیم می‌خواهد در اولین فرصت آنها را اجرا کند. این تیم بحث های گسترده ای در مورد جزئیات فنی دارد. این یک جلسه طوفان فکری دیگر برای تبادل نظر است. نتیجه مورد انتظار از جلسات بکلاگ ریفایمنت دستیابی به یک داستان کاربری دقیق تر است، و زمانی که سودمند به نظر برسد، ممکن است بیشتر شکسته شود. ایده این است که داستانی که وارد می شود باید معیارهای پذیرش "Acceptance Criteria" را که قبلاً تعیین شده بود، برآورده کند. همچنین باید نحوه حرکت رو به جلو را روشن کند. همچنین باید شامل تعریف انجام شده"Definition of Done" باشد تا نتایج بعداً بر اساس آن تأیید شوند. در نهایت، تصمیم گیری در مورد اینکه آیا داستان ارزش کافی را برای مشتری به ارمغان می آورد یا نه، خلاصه می شود.
جلسه برنامه ریزی اسپرینت
برنامه ریزی اسپرینت چیزی است که در اسکرام برای همه آشنا است. اعضا تیم دور هم می نشیند و در مورد نحوه انجام کار در طول مدت اسپرینت تصمیم می گیرند. بسیار محتمل است که قبل از اینکه تیم برای برنامه ریزی یک اسپرینت بنشیند، راه حل ها و مطالبات عقب افتاده خود را به مشتری ارائه کرده باشد. این فرصتی است تا ببینیم آیا خطاها یا ابهامات دیگری وجود دارد یا خیر که مطمعن شوند بکلاگ نیاز به اصلاح بیشتر دارد یا نه. این فرصتی برای توسعه دهندگان است تا راه حل ها را به همه ذینفعان و تیم درگیر در جلسه برنامه ریزی اسپرینت نشان دهند. باید اطمینان حاصل کند که داستان‌های کاربر در جلسه برنامه‌ریزی اسپرینت به‌خوبی اصلاح شده‌اند و از قبل به‌طور کامل مورد بحث قرار گرفته‌اند. برنامه ریزی اسپرینت نباید باعث تخلیه انرژی شود. در عوض، باید کارایی را افزایش دهد. مراحل قبلی بررسی می‌شوند تا اطمینان حاصل شود که اطلاعات جمع‌آوری‌شده مرتبط باقی می‌مانند. جلسه برنامه ریزی اسپرینت باید با توافق تیم در مورد بکلاگ برای اولین اسپرینت به پایان برسد. تیم باید با داستان‌ها، معیارهای پذیرش، طرح‌ها و قالب‌ها آماده باشد. بنابراین، داستان ها آماده اجرا خواهند بود.
پیاده سازی
اکنون که تیم با داستان ها آشنا شده اند، زمان اجرای آنها فرا رسیده است. همانطور که تیم Sprint را اجرا می کند، متوجه می شود که آیا یک یوزر استوری به خوبی آماده شده است یا نه. این موارد در هر کار جدیدی که در راه است یا برخی از کارهایی که زمان بیشتری برای آنها تخمین زده می شود منعکس خواهد شد. تیم باید بهترین راه حل ممکن را برای مقابله با چنین شرایطی پیدا کند. همچنین تجربیات و ورودی های ارزشمندی برای برنامه ریزی اسپرینت بعدی دریافت خواهد کرد. هنگامی که Sprint کامل شد و شما یک محصول در حال کار را آماده کردید، یک نسخه نمایشی از محصول را می توان در اختیار سهامداران قرار داد. داستان های کاربر آنچه را که انجام شده است و آنچه که در زمان نمایش نسخه نمایشی انجام می شود، توصیف می کند. در این زمان، سهامداران نیز بازخورد خود را در مورد محصول ارائه می‌کنند و تغییرات مورد نیاز را در صورت نیاز پیشنهاد می‌کنند. این پیشنهادات می توانند به داستان های کاربری تبدیل شوند و در Sprint های بعدی پیاده سازی شوند.
آزمایش کردن
هنگامی که یک یوزر استوریر به پایان می رسد، باید برای کارایی و عملکرد آزمایش شود. تیم ممکن است بهترین تلاش خود را در پیاده سازی یوزر استوری انجام داده باشد، اما باید اطمینان حاصل شود که کار می کند و راه حل مناسب مورد انتظار مشتری را ارائه می دهد. بنابراین، تیم آزمایش، داستان کاربر را برای کارایی و عملکرد مورد انتظار آزمایش می کند. یونیت تست، انواع تست ها وجود دارد تا ببینند آیا داستان تکمیل‌شده معیارهای پذیرش را برآورده می‌کند یا خیر. زمانی که User Story با تعریف Done مطابقت داشته باشد، آماده انتشار "Release" است.
اینجاست که چرخه عمر یوزر استوری به پایان می رسد. این آزمون معیارهای پذیرش را پاس کرده و در نهایت، آنچه مهم است این است که چه چیزی را در اسپرینت تکمیل می کنیم. اگر یک داستان کاربر را نتوان در یک Sprint تکمیل کرد، به Backlog محصول برگردانده می شود و در Sprint های بعدی برنامه ریزی می شود. اینها مراحل مختلف چرخه زندگی User Story در Agile هستند.
مترجم و نویسنده: علی امینی
اجایل شو شمارا به مطالعه مطالب زیر دعوت می کند:
معرفی 20 کتاب کاربردی برای مدیران محصول
اسپرینت پلنینگ مبتنی بر سرعت چیست ؟
برنامه ریزی انتشار (Release Planning) در اسکرام چیست ؟
