آموزش اسکرام؛ قسمت نهم: برآورد چابک

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

برآورد چابک نقش محوری و مؤثری در برنامه‌ریزی و مدیریت توسعه‌ی محصول ایفا می‌کند. به‌علاوه، ما پاسخ پرسش‌های زیر را نیز به کمک برآورد چابک پیدا می‌کنیم:

• در هر اسپرینت، چند قابلیت (Feature) تکمیل خواهد شد؟
• چه زمانی کار به‌پایان می‌رسد؟
• هزینه‌ی تکمیل Featureها چقدر است؟

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

در حوزه‌ی توسعه‌ی نرم‌افزار، برآورد به‌معنی ارزیابی کمّی (مقداری) میزان تلاش لازم برای انجام هر وظیفه (Task) خاص است. در جلسه‌ی برنامه‌ریزی اسپرینت، همه‌ی اعضای تیم اسکرام دورهم جمع می‌شوند و برخی آیتم‌های محصول یا PBIها را باتوجه‌به اولویت و اندازه‌ی برآوردشده‌ی آن‌ها بیرون می‌کشند. بنابراین، اندازه‌ی PBI معادل است با میزان تلاش لازم برای تکمیل هر PBI در طول اسپرینت که برحسب استوری‌پوینت‌های کاربر سنجیده می‌شود.

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

• تیم اسکرام (توسعه‌دهندگان و آزمون‌کنندگان و سایر اعضا)
• مالک محصول (فقط درصورتی‌که از طرف تیم دعوت‌ شده باشد)
• اسکرام‌مستر

بازی برآورد چابک، تکنیک فوق‌العاده‌ای است؛ زیرا عملکرد تیم اسکرام را بهبود می‌بخشد. می‌توانید تصور کنید در حال بازی، کار ارزشمندی نیز انجام می‌دهید. تیم با استفاده از این تکنیک می‌تواند بین ۲۰ تا ۶۰ داستان کاربر را در طول یک ساعت برآورد کند. هدف بازی برآورد چابک، برقراری تعادل بین «زمان صرف‌شده برای برآورد» و «ارزش کسب‌شده از برآورد» است.

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

در روش‌های سنّتی توسعه‌ی نرم‌افزار، نتیجه‌ی برآورد در قالب یک عدد (مثل ساعت یا روز) ارائه می‌شد؛ اما در چهارچوب اسکرام، با استفاده از ساختار شکست کار (WBS) پروژه را به وظایف کوچک‌تر تقسیم می‌کنیم و هرکدام از آن‌ها را برحسب استوری‌پوینت برآورد می‌کنیم. این برآوردها به مهارت‌های منابع ما بستگی دارد.

ارزیابی وظایف فنی کار آسانی نیست؛ به‌همین‌دلیل، نمی‌توان آن را به‌صورت مطلق در قالب اعداد بیان کرد. به‌عنوان‌ مثال، گاهی تیم برای حل مشکل به ۶ ساعت زمان نیاز دارد؛ درحالی‌که اصلاح کد واقعی فقط ۱۰ دقیقه زمان می‌برد. روش برآورد نسبی، بیشترین کارایی خود را در تخمین وظایف پیچیده نشان می‌دهد. به‌عنوان‌ مثال، به ظروف فلزی تصویر زیر توجه کنید:

فرض کنید از شما دو سؤال می‌کنند؛ ۱. ظرف اول چقدر بزرگ است؟ ۲. ظرف دوم چقدر بزرگ است؟ شاید برای شما پاسخ‌دادن به این دو پرسش کمی سخت و گیج‌کننده باشد. در مرحله‌ی بعد، به سؤال دیگری جواب دهید: ظرف دوم در‌مقایسه‌با ظرف اول چقدر بزرگ‌تر است؟ (ارزیابی نسبی) این بار شما راحت‌تر پاسخ می‌دهید. همان‌طورکه می‌بینید، برای برآورد وظایف پیچیده، با استفاده از تکنیک تخمین نسبی نتایج بهتری به‌دست می‌آورید. به این چند مثال ساده توجه کنید تا درک بهتری از برآورد نسبی کسب کنید:

اندازه/ وسعت استرالیا حدود دوبرابر اندازه/ وسعت هند است.

اندازه/ وسعت کانادا سه‌برابر اندازه/ وسعت هند است.

کانادا و ایالات‌متحده آمریکا هم‌اندازه یا هم‌وسعت هستند.

برآورد نسبی واحد ندارد و نسبت‌ها فقط با عدد بیان می‌شوند؛ درحالی‌که در اسکرام، این عددها استوری‌پوینت اسکرام (Scrum Story Points) نام‌ گرفته‌اند.

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

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

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

برنامه‌ریزی پوکر (Planning Poker) یکی از رایج‌ترین روش‌های برآورد و برنامه‌ریزی چابک است که برمبنای «نظر جمعی» پیش می‌رود و به‌منظور تخمین بک‌لاگ محصول به‌کار برده می‌شود. برنامه‌ریزی پوکر با واحدهایی نظیر استوری‌پوینت‌ها یا روزهای ایده‌آل یا واحدهای مشابه انجام می‌شود. در این روش، مشتری یا مالک محصول داستان‌های کاربر یا قابلیت‌های محصول (Feature) را برای تیم برآوردکننده شرح می‌دهد.

نکته: برنامه‌ی پوکر روش ارزیابی نسبی برای اندازه‌گیری PBIها است.

در سال ۲۰۰۲، جیمز گرنینگ اولین‌بار برنامه‌ریزی پوکر را به‌کار برد و پس از وی، در سال ۲۰۰۶ مایکل کوهن. در این فعالیت، کارشناسان درباره‌ی آیتم‌های بک‌لاگ محصول بحث می‌کنند تا مفروض‌ها را مشخص و با درک مشترکی PBIها را برآورد کنند. برنامه‌ریزی پوکر آیتم‌های برخوردار از اندازه‌ی مشابه را گروه‌بندی و بدین‌ترتیب، تخمینی نسبی ارائه می‌کند.

فعالیت برنامه‌ریزی پوکر به‌کمک دنباله‌ای از اعداد اجرا می‌شود که «مقیاس برآورد» نام دارد. ازآنجاکه هدف کاملا دقیق نیست، تیم عموما از همه‌ی اعداد مقیاس استفاده نمی‌کند. درعوض، اعداد کوچکی که تکرار بیشتری دارند و اعداد بزرگی که در انتهای دیگر دنباله متمایزتر هستند، بیشتر استفاده می‌شوند.

یکی از مقیاس‌هایی که مایکل کوهن پیشنهاد داده، دنباله فیبوناچی است: ۱، ۲، ۳، ۵، ۸، ۱۳، ۲۰، ۴۰ و ۱۰۰. این دنباله بیش از هر مقیاس دیگری در سازمان‌ها پذیرفته‌شده؛ اما برخی از تیم‌ها نیز از دنباله‌ی ضریب دو استفاده می‌کنند: ۱، ۲، ۴، ۸، ۱۶، ۳۲ و... . تیم PBIهای دارای اندازه‌ی مشابهی را در یک گروه قرار و در زمان برآورد، اعداد متناسب دنباله را به هر گروه نسبت می‌دهد. برای درک بهتر این مفهوم، به این مثال واضح توجه کنید: کارمندان اداره‌ی پست نامه‌های متعلق به یک منطقه‌ی مشابه را در یک گروه قرار می‌دهند تا فرایند تحویل نامه‌ها را ساده‌تر کنند. به‌طورمشابه، اعضای تیم (برآوردکنندگان) سؤالاتی درباره‌ی PBIها از مالک محصول می‌پرسند و با او بحث می‌کنند. وقتی همه‌ی Feature به‌طورکامل بحث شدند، برآوردکننده یک کارت را برمی‌دارد تا تخمین اعضای تیم را برمبنای آن شرح دهد. در این زمان، همه‌ی کارت‌های دیگر به اعضای تیم نشان داده می‌شود. اگر برآوردکنندگان استوری‌پوینت‌های مشابهی انتخاب کنند، برآورد آیتم در همین نقطه به‌پایان می‌رسد؛ درغیراین‌صورت، اعضای تیم باید باهم گفت‌وگو کنند تا روی نتیجه‌ی مشترکی به‌توافق برسند.

برآوردکنندگانی که بالاترین و پایین‌ترین استوری‌پوینت‌ها را تخمین زده‌اند، باید دلایل خود را به‌اشتراک بگذارند. پس از اتمام مباحثات، هریک از اعضای تیم دوباره یک کارت برآورد را انتخاب می‌کند و همه‌ی کارت‌ها به‌طور هم‌زمان باز یا نشان داده می‌شوند. این فرایند تا جایی ادامه پیدا می‌کند که تیم به‌ اتفاق‌نظر (اجماع) برسد؛ درغیر‌این‌صورت برآوردکنندگان می‌پذیرند که تخمین و برنامه‌ریزی هر آیتم مستلزم اطلاعات بیشتری است و باید تا زمان کسب اطلاعات لازم به‌تعویق بیفتد.

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

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

تفسیر رایج اعداد روی کارت‌ها را در جدول زیر مشاهده می‌کنید:

نکته ۱: در برنامه‌ریزی پوکر، «برآوردنکردن» پذیرفتنی است؛ ولی «شرکت‌نکردن» نه. اگر یکی از اعضای تیم از ارائه‌ی برآورد هر آیتم اجتناب کند، به این معنا نیست که باید از همکاری و مشارکت با هم‌تیمی‌ها و کمک برای رسیدن به نتیجه‌ی جمعی نیز سر باز بزند.

نکته۲: کارت π فرصتی به اعضای تیم می‌دهد تا مدتی با یکدیگر تعامل آزاد داشته باشند یا به‌تنهایی استراحت کنند. زمانی‌که این کارت نشان داده می‌شود، اعضای تیم واقعا به تنفسی کوتاه نیاز دارند تا دوباره بتوانند درباره‌ی برآورد تلاش‌ها باهم گفت‌وگو کنند.

قوانین بازی برنامه‌ریزی پوکر، به‌شرح زیر است:

• مالک محصول یک PBI که باید برآورد شود، انتخاب می‌کند و برای اعضای تیم می‌خواند.
• مالک محصول به پرسش‌ها پاسخ می‌دهد.
• هر عضو تیم به‌طورمخفیانه یکی از کارت‌ها را برمی‌دارد تا برآورد خود را ازطریق آن اعلام کند.
• زمانی‌که تمامی اعضا برآورد خود را انجام دادند، همه‌ی کارت‌ها درمعرض دید همه قرار می‌گیرد.
• اگر همه برآورد یکسانی کرده باشند؛ پس به اتفاق‌نظر رسیده‌اند و آن عدد به‌عنوان برآورد PBI انتخاب می‌شود.
• اگر برآوردها یکسان نبودند، برآوردکنندگان با یکدیگر بحث می‌کنند تا به توجیه مشترکی برسند یا افرادی که برآوردهای بالاتر و پایین‌تری درمقایسه‌با دیگران دارند، دلیل خود را برای دیگران توضیح می‌دهند.
• پس از خاتمه‌ی بحث، فرایند به مرحله‌ی چهار بازمی‌گردد و این چرخه تا جایی ادامه می‌یابد که اتفاق‌نظر عمومی حاصل شود.

• برنامه‌ریزی پوکر نقش مهمی در مشارکت اعضا بازی می‌کند. این فعالان اعضای تیم را دورهم جمع می‌کند تا به‌اتفاق تخمین درستی ارائه دهند؛ درحالی‌که هریک از اعضا به‌تنهایی ممکن است برآورد صحیحی نکنند.
• این فعالیت باعث می‌شود کارمندان درباره‌ی آیتم‌های بک‌لاگ محصول بیشتر فکر کنند و به ایده‌های جمعی ارزشمندی دست یابند. برنامه‌ریزی پوکر مباحثه درباره‌ی PBIها را تسهیل می‌کند.
• ازآنجاکه فعالیت برنامه‌ریزی پوکر مبتنی‌بر بحث و گفت‌وگو است، اعضای تیم داستان‌های کاربر را بهتر درک می‌کنند. به‌علاوه زمانی‌که آن‌ها ایده‌های خود را به‌اشتراک می‌گذارند، هرگونه سؤالشان نیز برطرف می‌شود. درنهایت، اعضای تیم برآورد صحیح اندازه‌ی آیتم‌ها را دریافت می‌کنند که این امر بازدهی سرمایه‌گذاری کارمندان را افزایش می‌دهد.

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

اندازه‌های تی‌شرت تکنیک یکپارچه‌ای برای برآورد فهرست (بک‌لاگ) بزرگی از آیتم‌های نسبتا بزرگ است. در این تکنیک، آیتم‌های هم‌اندازه باید به‌درستی در یک گروه قرار بگیرند. برچسب گروه‌ها یا مخازن مشابه با چیزی است که برای اندازه‌ی تی‌شرت به‌کار می‌رود؛ یعنی خیلی کوچک (Extra Small یا XS)، کوچک (Smsll یا S)، متوسط (Medium یا M)، بزرگ (Large یا L) و بسیار بزرگ (Extra-Large یا XL).

مزیت اصلی تکنیک اندازه‌های تی‌شرت، این است که آغازکردن برآوردها بسیار ساده می‌شود. همچنین، این تکنیک راهی عالی برای آشناشدن با مفهوم برآورد نسبی است؛ به‌همین‌دلیل، هم برای تیم‌های تازه‌کار روش مناسبی محسوب می‌شود.

اجرای سیستم باکت (Bucket System) بسیار سریع‌تر از برنامه‌ریزی پوکر پیش می‌رود. زمانی‌که گروه بزرگی از شرکت‌کنندگان باید تعداد زیادی از آیتم‌ها را برآورد کنند، سیستم باکت کارایی خود را نشان می‌دهد؛ زیرا به‌راحتی می‌توان آیتم‌ها را از دسته‌ای به دسته‌ی دیگر منتقل کرد. ارزش باکت‌ها طبق یک دنباله تعیین می‌شود: ۰، ۱، ۲، ۳، ۴، ۵، ۸، ۱۳، ۲۰، ۳۰، ۵۰، ۱۰۰ و ۲۰۰.

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

نکات

• اگر گروه متوجه شود آیتمی به‌جای باکت هشت به باکت یک تعلق دارد، می‌تواند دنباله را تغییر دهد.
• در سیستم باکت، رویکرد «تقسیم و کنترل» دنبال می‌شود؛ یعنی همه‌ی آیتم‌ها بین همه‌ی شرکت‌کنندگان تقسیم می‌شود. هر شرکت‌کننده می‌تواند بدون تأیید سایرین آیتم‌های در دستش را در پاکت‌های مناسب قرار دهد.
• آیتم‌ها باید در جای مناسب قرار بگیرند و هیچ آیتمی نباید بین دو گروه یا دو باکت نصب شود.
• اگر یکی از شرکت‌کنندگان داستان کاربر را درک نکنند یا اگر برخی از شرکت‌کنندگان کار خود را زودتر تمام کنند، داستان‌های کاربر بین آن‌ها ردوبدل می‌شود.
• در پایان کار، صحت گروه‌بندی‌ها را همه‌ی شرکت‌کنندگان بررسی می‌کنند. اگر هریک از اعضا متوجه شود که آیتمی در باکت نادرستی قرار دارد، آن را به اطلاع سایر شرکت‌کنندگان می‌رساند. گروه درباره‌ی این اختلاف بحث می‌کند تا به اتفاق‌نظر نهایی برسد.
• تسهیل‌کننده‌ی جلسه باید بررسی کند که هیچ‌کس آیتمی را جابه‌جا نمی‌کند؛ مگر اینکه گروه در‌حال‌تصحیح نهایی باشد.

سیستم باکت برای مرتب‌سازی اولویت از آیتم‌های بک‌لاگ محصول نیز استفاده می‌کند.

زمانی‌که با مجموعه‌ی کوچکی از آیتم‌ها کار می‌کنید و به هیچ تکنیک پیچیده‌ای نیاز ندارید، می‌توانید رأی‌گیری نقطه‌ای (Dot Voting) را انتخاب کنید. این روش مشابه با تکنیک «تصمیم‌گیری براساس رأی‌گیری» است. هرشخص تعداد محدودی استیکر (نقاط) دریافت می‌کند و می‌تواند ازطریق آن‌ها، به آیتم‌ها رأی دهد. هرچه تعداد نقطه‌ها بیشتر باشد؛ یعنی اندازه‌ی آیتم بزرگ‌تر برآورد شده است. این روش بسیار سریع و ساده پیش می‌رود و معمولا برای ۸ تا ۱۰ داستان کارایی مناسبی دارد.

فرایند برآورد در پروژه‌های اسکرام، نقش مهمی در جهت‌یابی صحیح و برنامه‌ریزی و مدیریت مناسب ایفا می‌کند. تکنیک‌هایی که در این مطلب شرح داده شدند، رایج‌ترین روش‌های برآورد نسبی اندازه‌ی آیتم‌های بک‌لاگ محصول برحسب استوری‌پوینت یا روزهای ایده‌آل هستند. هدف از برآورد و مرتب‌سازی و اولویت‌بندی آیتم‌هایی است که انجام آن‌ها را در طول اسپرینت می‌پذیریم.