فرادرسEpic در اسکرام چیست؟ – توضیح اپیک به زبان ساده
اکنون یک دهه است که «اسکرام» تبدیل به کلمه‌ای پرطرفدار در دنیای توسعه محصول شده و چرا که نه، داستان‌های موفقیت‌آمیز زیادی راجع به آن شنیده‌ایم. البته درباره «داستان‌های کاربر» که به معنای پیش‌نیازهای اسکرام هستند صحبت نمی‌کنیم، بلکه از داستان موفقیت تیم‌ها و سازمان‌هایی که می‌گوییم که روش‌شناسی اسکرام را در پیش گرفته‌اند. در هر صورت اما می‌خواهیم راجع به یکی دیگر از همان پیش‌نیازها حرف بزنیم: درباره Epic در اسکرام.
«حماسه» یا «اپیک» (Epic) را تا به امروز به عنوان داستانی طولانی راجع به قهرمانان بزرگ و افسانه‌ای تاریخی که دست به کارهای شجاعانه می‌زدند می‌شناختیم، اما در این مقاله به سراغ مفهومی کاملا متفاوت می‌رویم. به مطالعه ادامه دهید تا هرآنچه لازم است راجع به Epic در اسکرام بدانید را فرا بگیرید.
Epic در اسکرام چیست؟
اگر بخواهیم به ساده‌ترین شکل ممکن بگوییم، Epic در اسکرام (که خود زیرمجموعه مدیریت چابک یا Agile به حساب می‌آید)، یک وظیفه بزرگ است که می‌تواند به «داستان‌های کاربر» (User Stories) خردتر تقسیم شود. یک اپیک می‌تواند میان اسپرینت های مختلف و یا حتی تیم‌های چابک مختلف پخش شود. اپیک می‌تواند توضیحی سطح بالا از آنچه مشتری طلب می‌کند باشد و به همین ترتیب، مقادیری نیز در آن ضمیمه می‌شوند. همانطور که اشاره کردیم، اپیک یک پیش‌نیاز سطح بالا است و به همین خاطر، ابعاد و چشم‌انداز آن می‌تواند در گذر زمان دچار تغییر شود.
اپیک‌ها راهی کارآمد برای سامان‌بخشی به کارها و ساخت سلسله مراتب است. ایده کلی این‌ست که وظایف را به تکه‌های خرد و قابل پیاده‌سازی تقسیم کنید تا پروژه‌های بزرگ واقعا عملی شوند و بتوانید به صورت مداوم برای مشتریان خود ارزش‌سازی کنید. اپیک به تیم‌ها در تقسیم‌بندی کارها و حرکت به سمت هدفی بزرگ‌تر کمک می‌کند.
برای اینکه موضوع را بهتر باز کرده باشیم، مثالی از دنیای واقعی میزنیم. فرض می‌کنیم برگزاری مهمانی سال نو، یک پیش‌نیاز اپیک برای شما است. برای برگزاری چنین مهمانی مهمی، باید وظایف خود را سامان‌مند کنید: از بزرگ‌ترین اهداف گرفته تا ریزترین جزییات. باید بتوانید به تغییرها واکنش نشان دهید، پیشرفت خود را پایش کنید و به یک نقشه مشخص بچسبید. وقتی از اپیک خود باخبر می‌شوید، می‌توانید آن را به وظایف خردتر مانند فراهم آوردن فهرست مهمانان، تصمیم‌گیری راجع به خوراکی‌ها، خرید لوازم مورد نیاز، دکوراسیون منزل، خرید سال جدید و موارد مشابه تقسیم کنید.
برخی اپیک‌ها بسته به نیازهای گزارش‌دهی مدیریتی شکل می‌گیرند. برخی اپیک‌ها هم با در نظرگیری زمان‌بندی‌ها ساخته می‌شوند، زمان‌بندی‌هایی که نباید زیادی کوتاه یا زیادی طولانی باشند و به عبارت دیگر، بیشتر از دو هفته طول نکشند. یکی از رایج‌ترین راه‌های مدیریت این فرایند، «داستان‌سرایی» (Storytelling) نام دارد. اما داستان‌سرایی اصلا چیست؟
داستان سرایی چیست؟
داستان‌سرایی در اصل ابزاری است که به شما در تصویرسازی جریان رخدادها و تاثیری که روی اپیک می‌گذارند کمک می‌کند. اگر هم احساس کردید که الگوی کاری شما با هیچ‌یک از نمونه‌هایی که به سراغ آن‌ها خواهیم رفت تطابق ندارد، الگوی خودتان را بسازید. در واقع این را به خاطر داشته باشید که روش‌شناسی چابک هیچ مسیر از پیش مشخص شده‌ای ندارد و در عوض، مسیر و نحوه رسیدن به اهداف را به شما نشان می‌دهد و باقی مسائل به خودتان بستگی دارند.
یک‌بار دیگر به مثالی که پیشتر زدیم بازمی‌گردیم و سعی می‌کنیم اپیک بزرگ‌مان را به اجزای کوچکتر و قابل رسیدگی تبدیل کنیم. تقسیم کردن اپیک به اجزای کوچکتر بسیار مهم است تا تیم بتواند آن اجزا را برداشته و در برهه اسپرینت در اسکرام، نهایی‌شان کند. در واقع می‌توان این کار را با خلق یک اثر هنری مقایسه کرد که نیازمند دقت فراوان از نظر ابعاد، اولویت‌بندی، رسیدگی به اجزای متصل به یکدیگر و موارد این چنینی است. در ادامه به سراغ چند روش رایج برای تقسیم کارها می‌رویم.
تقسیم کار مبتنی بر جریان کاری
در مثالی که پیشتر به سراغ آن رفتیم، راجع به پروژه برگزاری مهمانی سال نو حرف زدیم و حالا بیایید ببینیم از نظر جریان کاری، چطور قادر به تقسیم کردن آن به اجزای کوچکتر هستیم. خرید کردن می‌توان یک جریان کاری باشد که در آن، موارد مورد نیاز را از بیرون تهیه می‌کنید. یک جریان کاری دیگر، غذا پختن برای مهمانان است و رسیدگی به دکوراسیون منزل را هم میتوانیم به صورت مشابه یک جریان کاری به حساب آوریم. می‌بینید این فرایند چقدر ساده است؟ مالک محصول یا گاهی مدیر محصول (که در اینجا همان میزبان مهمانی است) به راحتی قادر به اولویت‌بندی امور خواهد بود.
برخی گام‌های جریان کاری ممکن است در این لحظه مهم نباشند و بنابراین می‌توانید آن‌ها را به مراحل بعدی موکول کنید. برای مثال ممکن است پختن کیک را در اولویت گذاشته باشید، زیرا نیاز به اندکی زمان برای خنک شدن آن دارید. اما احتمالا همین کار را بتوان بعدا نیز انجام داد.
تقسیم کار مبتنی بر نقش
با توجه به اینکه افراد مختلف، نقش‌های گوناگونی را در یک پروژه برعهده می‌گیرند، Epic در اسکرام را می‌توان بسته به نقش‌ها نیز تقسیم‌بندی کرد. برای مثال میتوانیم نقش‌های «میزبان»، «مهمان» و حتی «آشپز» را در مهمانی خود داشته باشیم و وقتی صحبت از توسعه محصول باشد، قادر به افزودن نقش‌های هرچه بیشتر خواهید بود. در تقسیم کار مبتنی بر نقش، راجع به پرسونا های گوناگون صحبت می‌کنیم. برای مثال میزبان می‌تواند دنبال «برگزاری یک مهمانی موفقیت‌آمیز» باشد و مهمان به دنبال «چند بازی سرگرم‌کننده در مهمانی».
تقسیم کار مبتنی بر برنامه زمانی
برخی اپیک‌ها را می‌توان بسته به زمان مورد نیاز برای نهایی شدن، تقسیم‌بندی کرد. تیم توسعه معمولا کارها را براساس آنچه می‌توان در هر اسپرینت به دست آورد تقسیم می‌کند. اعضای تیم تمام اپیک را برداشته، تقسیم به برش‌های کوچکتر می‌کنند و سپس بسته به اولویت و ارتباط‌های میان وظایف، آن‌ها را در اسپرینت‌های مختلف جای می‌دهند.
همانطور که پیشتر اشاره کردیم، تقسیم‌بندی داستان‌های کاربر نیازمند توجه به فاکتورهای مختلف مانند ابعاد، اولویت و ارتباطات میان امور است. بنابراین دو رویکرد برای تقسیم‌بندی داستان‌های کاربر داریم: عمودی و افقی. بنابراین داریم راجع به چیزی مانند برش زدن یک کیک صحبت می‌کنیم. اگر کیک را افقی برش بزنید، یک لایه واحد به دست می‌آورید. اما اگر کیک را عمودی برش بزنید، مقداری از تمام لایه‌های کیک خواهید داشت.
تفاوت میان داستان، وظیفه و Epic در اسکرام چیست؟
تاکنون راجع به این صحبت کردیم که Epic در اسکرام چیست و چطور تقسیم‌بندی می‌شود. حالا بیایید راجع به این صحبت کنیم که چه ویژگی‌های متمایز‌کننده‌ای از سایر عناصر دارد. اپیک ما تا به این لحظه «برگزاری مهمانی سال نو» بوده. این کاری بزرگ است که دیدیم چطور به روش‌های گوناگون، تبدیل به وظایف کوچکتر می‌شود. نتایج این تقسیم‌بندی، «داستان‌ها» (Stories) هستند که می‌توانند در یک برهه اسپرینت به انجام برسند. اما داستان‌ها هم خود به قطعات کوچک‌تری به نام «وظایف» (Tasks) تقسیم می‌شوند. تیم توسعه این وظایف را برداشته و به آن‌ها رسیدگی می‌کند. زمانی هم که تمام وظایف به پایان رسیدند، داستان‌مان برچسب «پایان‌یافته» می‌خورد. بنابراین همه‌چیز به شکل زیر است:
- اپیک: پیش‌نیازی که بزرگ‌تر از آن است که در یک اسپرینت واحد نهایی شود. اپیک باید به قطعات کوچکتر و قابل رسیدگی (داستان‌ها) تقسیم شود.
- داستان: پیش‌نیازی که کسب‌وکار طلب می‌کند. داستان باید به‌گونه‌ای پیکربندی شود که در یک اسپرینت واحد به پایان برسد.
- وظایف: موارد ضروری هر داستان که وقتی کنار یکدیگر قرار می‌گیرند، داستانی کامل را شکل می‌دهند.
احتمالا این را شنیده‌اید که هرآنچه قابل اندازهگیری نباشد، نتیجه خاصی هم به همراه نمی‌آورد. همین موضوع در اینجا هم مصداق می‌کند. برای اندازهگیری میزان دستاوردها در هر اپیک، می‌توان به سراغ نمودارهای Burndown رفت. این نمودار به شما در پیش‌بینی مسیر پیش روی تیم توسعه هم کمک می‌کند. با توجه همیشگی به نمودار برن‌داون، مدیریت پیشرفت و موانعی که تیم با آن‌ها روبه‌رو است، آسان می‌شود. با این کار نه‌تنها شفافیت را در سیستم پدید می‌آورید، بلکه باعث شکل‌گیری اعتماد میان تیم و مشتریان می‌شوید.
نحوه شناسایی Epic در اسکرام چگونه است؟
اپیک یک کار نسبتا بزرگ است که نمیتوان در یک برهه واحد به آن رسیدگی کرد. داریم راجع به چیزی حرف میزنیم که نیازمند مباحثه و بارش فکری طولانی است تا قادر به تقسیم آن به اجزایی کوچکتر باشید. در سطح اپیک، ابعاد کارهای خردتر را به صورت حدودی تخمین میزنیم و برای این کار میتوانیم از واحدهای اندازهگیری گوناگون مانند سایزهای تیشرت، امتیاز یا هر چیز دیگری که تیم شما با آن راحت است، بهره بگیریم.
تیم توسعه سپس قادر به پایش میزان پیشرفت اپیک در نمودار Burndown است که هم مقدار پیشروی در امور را نمایش می‌دهد، هم بازتابگر موانع احتمالی در مسیر است.
مزایای اپیک
- اپیک به شما در درک پیش‌نیازهای سطح بالای ذینفعان و آنچه دقیقا مورد نیاز است یاری می‌رساند.
- اپیک باعث می‌شود در توافق با مشتری، قادر به تعیین ابعاد کار باشید.
- اپیک به شما کمک می‌کند که به پایش موارد بزرگ‌تر در بک لاگ محصول مشغول شوید و در عین حال، آن را غرق در امور مختلف نکنید. در واقع نوعی سلسله مراتب در بک‌لاگ پدید می‌آید و اپیک هم نماینده ایده‌ای اصیل است که معمولا ارتباطی تنگاتنگ با یک خروجی مشخص دارد.
- از سوی دیگر قادر به تخمین زدن مدت‌زمان مورد نیاز برای ارائه محصول خواهید بود. اپیک‌ها می‌توانند نگه‌دارنده فضا برای نقطه‌نظرهای جدیدی باشند که هنوز کاملا شکل نگرفته‌اند یا مواردی که تکامل آن‌ها تا زمانی که ساختار مطلوب را پیدا کنند به تعویق افتاده است.
- اپیک‌ها سپس تبدیل به چندین داستان کاربر می‌شوند که به تیم توسعه چابک در مدیریت موثر بک لاگ محصول یاری می‌رسانند.
مشکلات رایج و بالقوه اپیک
- اگرچه اپیک مزایای زیادی به هنگام مدیریت بک‌لاگ محصول با خود به همراه می‌آورد، اما هر سکه‌ای دو طرف دارد. گاهی از اوقات تیم‌ها ممکن است گیج شده و اپیک را چیزی فراتر از داستان‌های کاربری بزرگ ببینند. این موضوع زمانی دردسرساز می‌شود که تیم توسعه به ساخت ابزارهایی چندوجهی می‌پردازد تا میان اپیک‌ها و داستان‌ها تمایز قائل شود. از سوی دیگر ممکن است ابزارهایی بیش از اندازه پیچیده تدارک دیده شود تا بتوان اپیک‌ها را جداگانه از موارد موجود در بک لاگ پیش برد.
- تیم توسعه ضمنا ممکن است بدون اینکه ذهنیتی واضح راجع به کارهایی که باید انجام شوند داشته باشد، برخی اپیک‌ها را بیش از اندازه سطح بالا تخمین بزند. بدین ترتیب احتمال ابهام میان اعضای تیم بالاتر می‌رود و وقتی تخمین‌ها دقیق نباشند، عملا به هیچ دردی نمی‌خورند و کمکی به فرایند گزارش‌دهی نمی‌کنند.
