بازبینی Story Points

دوست داشتم بگویم که Story Points را من ابداع کرده‌ام، اما در صورت انجام چنین کاری، در حال حاضر احساس شرمندگی می‌کنم .......

این مقاله توسط Ron Jeffries نوشته شده است و در بلاگ ایشان وجود دارد. لینک.

دوست داشتم بگویم که Story Points را من ابداع کرده‌ام، اما در صورت انجام چنین کاری، در حال حاضر احساس شرمندگی می‌کنم. بیایید با هم نظرات من را در مورد Story Points مورد بررسی قرار دهیم. حداقل یکی از ما به نظرات من درباره این موضوع علاقه مند است.

در حقیقت Story ها، یک ایده از متدولوژی XP هستند و نه یک ایده که Scrum باشد. به نوعی، کارشناسان حوزه Scrum این ایده را پذیرفته‌اند، حتی اگر Scrum Guide (راهنمای اسکرام) به backlog item ها اشاره داشته باشد به هر حال استفاده از  backlog item ها به جای User Stories یک روش رایج در اسکرام است. حداقل تا اندازه‌ای که آنها به درستی متوجه موضوع شوند.

در جای دیگری من در مورد نحوه صحیح استفاده عمومی از استوری‌ها مطالبی را نوشته‌ام. در اینجا ما به موضوع “Story Points”  خواهیم پرداخت.

درXP در ابتدا Story ها بر مبنای زمان برآورد می‌شدند: زمان مورد نیاز برای اجرای یک Story

ما به سرعت به سراغ چیزی رفتیم که به آن « Ideal Days» (روزهای ایده‌آل) می‌گفتیم. این اصطلاح به طور غیررسمی به این شکل تعریف می‌شد که اگر مدیران یا مزاحمین شما را تنها بگذارند، چقدر طول می‌کشد تا این کار را یک گروه دو نفره(pairs) انجام دهد. برای تبدیل Ideal Days به زمان واقعی اجرا، آن را در  “load factor” ضرب می‌کردیم. load factor تقریباً در اکثر موارد 3 بود: سه روز واقعی برای انجام یک کار Ideal Day و تمام کردنش.

ما در مورد برآوردهای خود بر اساس تعداد روز‌ها صحبت کردیم و معمولاً توجهی به ویژگی «ایده آل بودن» نداشتیم. در نتیجه این نگرش یا رفتار ما، ذینفعان اغلب در مورد اینکه چگونه سه روز برای انجام یک کار یک روزه مورد نیاز است(تخمین زده می شود) یا با نگاهی به روی دیگر سکه، چرا نمی‌توان کار ۵۰ «روز» را در طی سه هفته انجام داد، دچار سردرگمی می‌شدند.

بنابراین، تا جایی که به خاطر دارم، دیگر تصمیم گرفتیم به جای “Ideal Days” تنها از عبارت “points” استفاده کنیم. بنابراین یک Story در سه Point تخمین زده می‌شود به این معنی که تکمیل آن حدود ۹ روز طول می‌کشد. در حقیقت ما از Point ها تنها برای تصمیم‌گیری در مورد میزان انجام کار استفاده کردیم که باید در یک iteration انجام شود، بنابراین اگر بگوییم این مقدار حدود بیست Point است، هیچ کس با این گفته مخالفتی نداشت.

ممکن است من پیشنهاد تغییر نام را داده باشم. اگر این کار را من انجام داده‌ام، در حال حاضر پشمان هستم. در اینجا برخی از نظرات فعلی من در مورد این موضوع، در قالب ایمیلی که به همکارم سایمون سوال پرسیده بود و من در پاسخ ارائه شده داده ام را مرور خواهیم کرد :

– آیا واقعاً از ابداع آنها پشیمان هستید یا احساس تاسف شما به دلیل استفاده نادرست از آنها در زمانی است که اندازه نسبی به درستی درک نشده است؟

من اینگونه پاسخ دادم که:

• من قطعا از سوء استفاده آنها ابراز تاسف می کنم.(قطعا احساس تاسف من به دلیل است که از آنها استفاده نادرست می شود)• از نظر حتی  استفاده از آنها در بهترین حالت، برای پیش بینی «زمان اتمام کار» ایده ضعیفی است.• من فکر می‌کنم پیگیری یا ردیابی(tracking) نحوه مقایسه واقعیات با برآوردها در بهترین حالت کاری بیهوده است.• به نظر من مقایسه تیم‌ها بر اساس کیفیت تخمین‌ها یا سرعت، امری زیان بار است.

اجازه دهید کمی عمیق‌تر به این موضوع نگاه کنیم.

برخی از رویکردهای به “Agile” در واقع با هدف برنامه ریزی آسان‌تر، توصیه میکنند که نرمال سازی Story Point‌ها در تیم ها انجام شود. در حالی که ظاهرا این امر به اندازه کافی معقول به نظر می‌رسد، احتمال افتادن در دام مقایسه تیم‌ها بسیار بالا است و اغلب سازمان‌ها در چنین شرایطی قرار می‌گیرند.

انجام مقایسه – Comparing

قبل از هر چیز، حتی اگر آنها «از ظاهر یکسانی برخوردار باشند»، هر تیم دارای مهارت‌های خاص خود است و در محیط مختص به خود کار می‌کند. بنابراین، اگر آنها به دو استوری مشابه نگاه کنند، یکی از تیم ها بگوید این 2 و دیگری بگوید این 6 است، این مسئله چندان جالب نخواهد بود و مطمئناً روش مفیدی نیز برای مقایسه تیم‌ها محسوب نمی‌شود.

اکنون من و شما با دیدن آن موقعیت، با کنجکاوی برای فهمیدن این موضوع به آن نزدیک می‌شویم که آیا موقعیت‌ها برای مقایسه شدن به اندازه کافی شبیه هستند یا خیر؟، و سپس بررسی می‌کنیم که آیا قادر به ارائه کمک به تیم دارای برآوردهای بالا‌تر هستیم یا خیر؟. این شاید خوب باشد(خوب به نظر برسد). به صورت ضمنی و یا صریح نتیجه‌گیری کنید که تیم «کند‌تر» ضعیف‌تر یا به نوعی در هم ریخته است! اما این بسیار بد است و متاسفانه امری رایج است.

از نظر من، مقایسه دو تیم تولید کننده محصول برای بسیاری از مدیران وسوسه ای است که نمی‌توانند در برابر آن مقاومت کنند. همچنین معتقدم تا حدی این مسئله وسوسه انگیز است که در صورت امکان، مفهوم Story Point‌ها و حتی تصور برآورد کردن Story ها را کنار بگذارم. ما مجدد به این سوال خواهیم پرداخت که چگونه با برآورد‌های کمتری کار کنیم، در وبلاگ (ron jeffries) مقالات دیگری نیز وجود دارند که این موضوع را مورد بررسی قرار می‌دهند.

پیگیری و ردیابی – Tracking

برای بسیاری از مدیران، وجود یک estimate ضروری می باشد و وجودش یک امر «واقعی» یا بدیهی هست و به این معنی است که شما باید برآوردها را با واقعیت‌ها مقایسه و اطمینان حاصل کنید که برآوردها و واقعیت‌ها با یکدیگر مطابقت دارند! و حتی خودداری از انجام این کار به این معنی است که افراد باید بهتر تخمین زدن را یاد بگیرند.

به نظر من، نکته مهم در رابطه با Real Agile این است که چند کار بعدی را انتخاب کنیم و آنها را به سرعت انجام دهم. مسئله کلیدی یافتن با ارزش‌ترین کارها و انجام سریع آنها است. انجام سریع آنها در نهایت به انجام کارهای کوچک با ارزش بالا و تکرار سریع ختم می‌شود. برآورد هزینه story ها کمک چندانی به این موضوع نمی‌کند.

بنابراین اگر وجود یک برآورد باعث شود که مدیریت مسئله ارزش را نادیده بگیرد( their eye off the ball of value) و به جای آن به دنبال بهبود برآوردها باشد، نسبت به هدف اصلی یعنی ارائه سریع ارزش واقعی (deliver real value quickly) بی‌توجه می‌شود.

این مسئله باعث می‌شود به این نتیجه برسم که از برآوردها چه در Pointها و چه در زمان باید اجتناب شود.

فشار – Pressure

فشار مربوط به نگرانی ها در مورد estimate/actual، فشار طبیعی و قابل انتظار از سمت مدیران و به دلیل خواستن «بیشتر» است. هر چقدر هم که تیم کار بیشتری را انجام دهد کافی نیست و بیشتر و بیشتر و بیشتر مد نظر است!

بهترین راه برای ارائه ارزش، انجام کار بیشتر و بیشتر و بیشتر نیست! بلکه انجام مکرر کارهای کوچک و البته با ارزش(small valuable things) است. اگر به‌جای برآورد Storyها آنها را  «به اندازه کافی کوچک»(small enough) برش دهیم (Slicing)، می‌توانیم به جریان روانی از ارزش (smooth flow of value) دست یابیم که به صورت مستمر ارائه می‌شوند.(delivering all the time)

*** در این پاراگراف میشود به راحتی اشاره نویسنده به اصل دهم مانیفست اجایل رو به صورت کامل حس کرد: Simplicity–the art of maximizing the amount of work not done–is essential

تمرکز یا تاکید بر موارد بیشتر مانعی برای افزایش ارزش می‌شود. افزایش فشار برای انجام کارهای بیشتر در اکثر موارد به شکل اجتناب ناپذیری به نتایج بدی منتهی می‌شود: تیم تلاش می‌کند سریع‌تر پیش برود و این کار باعث کاهش کیفیت Code و Test ها می شود. خیلی زود bug های بیشتری در کار آنها مشاهده می‌شود و به دلیل افزایش نیاز به انجام مجدد کار برای رفع عیوب، سرعت کاهش می‌یابد، و در نهایت به دلیل افزایش سرعت و کاهش کیفیت کد این مشکلات تشدید و تکرار می‌شوند. به تدریج شرایط بد و بدتر می‌شود، فشار افزایش می‌یابد و به مسابقه‌ای تبدیل می شود که در نهایت نتیجه آن به فاجعه تبدیل می‌شود.

از آنجایی که برآوردها حداقل در اعمال فشار بی مورد نقش دارند، ترجیح می‌دهم از آنها اجتناب کنم.

من از این هم جلوتر خواهم رفت: ترجیح می‌دهم به طور کامل از iteration planning یا Sprint planning اجتناب کنم.زیرا ما برای خرج کردن بودجه در طی چند هفته آینده کار نمی‌کنیم بلکه باید دارای فهرستی از چند کار مهم بعدی باشیم.

پیش بینی برای Done

تهیه فهرستی از Features (قابلیت‌های) ضروری کاری معمول است، مدتی در مورد آنها فکر کنید و سپس تصمیم بگیرید که کدام از آنها Release بعدی محصول ما را تعریف کنند. سوال بعدی که مطرح می‌شود این است که «تمام این کارها در چه زمانی انجام می شوند؟»

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

بسیار بهتر است که برای مشتریان تاریخ نزدیکی را برای release بعدی انتخاب کنید و تا حد امکان موارد خوب را در آن release انتخاب کنید. انجام برآورد چه بر اساس Story Point‌ها و چه بر اساس زمان، مانع انجام این کار می‌شود. به عقیده من، در صورت امکان بهتر است از انجام آن اجتناب شود.

برش دادن – Slicing

سوالی که اکنون مطرح می‌شود این است که در صورتی که برآورد توسط Story رو دوست نداشته باشید، چه چیزی را دوست خواهید داشت؟(مناسب است). خوب، من به برش دادن Story به بخش‌های کوچکتر علاقه دارم، در این روش Storyهای بزرگ‌تر را به Storyهای کوچک‌تر تقسیم می‌کنیم به طوری که هر کدام تا حد امکان از ارزش بالایی برخوردار باشند اما انجام آنها نیازمند زمان بسیار کمی، در حالت ایده‌آل کمتر از یک روز و شاید تنها چند ساعت باشد.

در حال حاضر، من به دنبال بحث کردن در مورد الزام وجود نوعی برآورد در برش نیستم. اگر شما یا اعضا‌ء تیم به صورت ذهنی برآوردهایی را انجام دهید و هرگز در مورد آن با کسی صحبت نکنید، احتمالاً مشکلات مربوط به برآوردها چه بر اساس Story Point‌ها وچه بر اساس زمان به وجود نمی‌آیند. مطمئناً دانستن تفاوت بین «probably small enough» و «probably not small enough» در مقایسه با از اطلاع داشتن از تفاوت بین «سه روز» و «یک روز» یکسان نیست و کار سختی نخواهد بود.

به علاوه، یک ترفند وجود دارد که به آن در مقاله Getting Small Stories و Slicing, Estimating, Trimming اشاره شده است.  من آن را از Neil Killick آموختم: Story ها را تا زمانی برش دهید که تنها به یک acceptance test نیاز داشته باشند. با کمی تمرین این موضوع، هر چیزی به اندازه درستی برش داده می‌شود.

البته مقالات دیگری نیز در مورد موضوع تخمین نوشته شده‌اند.

پیش بینی آینده – Predicting the future

اما … آیا نیازی به مشروع دانستن(درست بودن) مدت زمان مورد نیاز برای release یک محصول وجود ندارد و آیا انجام برآورد برای آن ضروری است؟ ممکن است اینگونه باشد اما شاید این هدف با برآورد‌ کردن Story ها بدست نیاید. این احتمال وجود دارد که حتی سطح نیازهای خود را تا سطح استوری پایین نیاورید و اگر چنین کاری کنید، احتمالاً بسیار بزرگ و تا حد زیادی دچار اتلاف می‌شوند.

البته، اگر مجبور به انجام این کار هستید، کاری را که می‌خواهید انجام دهید. هر کاری که من انجام می‌دهم یا تئوری‌هایی را که در مورد نحوه انجام کار مطرح می‌کنم تنها یک ایده هستند. در نهایت باید کاری را انجام دهید که با توجه به شرایطی که در آن هستید منجر به موفقیت شما شود. البته به نظر من، روشی که در ادامه به آن اشاره می‌کنم منجر به کسب نتایج بهتری می‌شود.

در ابتدا در مورد یک یا چند قابلیت مهم برای release بعدی فکر کنید. در مورد مشکلاتی صحبت کنید که قادر به حل آنها هستید و اینکه چه نرم افزاری که دارید تولید می کنید در این فرآیند حل مشکلات می‌تواند کمک کند. در مورد ساده‌ترین قابلیت‌هایی صحبت کنید که ممکن است تا حدی قادر به ارائه کمک باشند. الزامی برای حل تمام مشکلات از سوی ما وجود ندارد: در اکثر موارد اگر بتوانیم کمی کمک کنیم کفایت میکند. فقط کافی است تا  هر چیزی در مسیر درست قرار گیرد.

دوم، به یک ضرب‌الاجل نزدیک (close-in deadline) فکر کنید، به طوری که احساس کنید می‌توانید تا آن زمان به قابلیت‌های خوبی دست پیدا کنید. ضرب‌الاجل را تعیین کنید و دست به کار شوید.

سوم، برش‌های کوچکی از قابلیت های مهم را ایجاد کنید و آنها را انجام دهید. باید بتوانید به راحتی آنها را در طی یک روز یا کمتر به انجام برسانید. تنها بر روی مهم‌ترین بخش‌های بعدی کار کنید:

don’t try to fill out the first capability all the way to the tiniest frill

سعی نکنید اولین قابلیت را با ریزترین امور غیر ضروری پر کنید. شما در حال تلاش برای وارد شدن به یک چارچوب ذهنی هستید که در آن فکر می‌کنید «اگر ما فقط این یک کار کوچک را انجام دهیم، آنگاه مشتری ما Jack، واقعا می‌تواند از آن استفاده کند». پس  آن کار کوچک را انجام دهید و اجازه دهید مشتری شما یعنی Jack آن را امتحان کند. ما می‌خواهیم تا حد امکان به سمت ارائه مستمر ارزش (continuous delivery of value) حرکت کنیم.

علاوه بر این، قصد داریم ارزش کاری را که انجام می‌دهیم چنان نمایان کنیم که مالک محصول ما و سایر ذینفعان همیشه در انتظار بیرون آمدن محصول نمانند. به این ترتیب بایستی کار درست را با و یا بدون استفاده از برآورد‌های Story انجام خواهیم داد.

جمع بندی

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