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

چهارشنبه ۱ خرداد ۱۳۹۸ - ۲۱:۳۰
مطالعه 13 دقیقه
اعضای تیم توسعه با شرکت در فرایند برآورد چابک، اندازه‌ی نسبی داستان‌هایی را تخمین می‌زنند که می‌خواهند در طول اسپرینت تکمیل کنند.
تبلیغات

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

چرا به برآورد چابک نیاز داریم؟

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

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

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

برآورد یا تخمین چیست؟

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

Agile estimation

چه افرادی باید در برآورد چابک شرکت کنند؟

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

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

بازی‌های برآورد چابک

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

Agile Estimation

تکنیک‌های برآورد چابک

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

برآورد نسبی

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

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

Relative Estimation

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

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

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

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

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

مزایای برآورد نسبی

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

اشتباهات متداول در استفاده از برآورد نسبی

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

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

برنامه‌ریزی پوکر

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

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

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

مقیاس برآورد چیست؟

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

Planning Poker

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

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

چه زمانی فعالیت برنامه‌ریزی پوکر را اجرا می‌کنیم؟

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

برنامه‌ریزی پوکر چگونه انجام می‌شود؟

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

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

کارت

تفسیر

صفر

آیتم یا به‌اندازه‌ای کوچک است که نمی‌توان هیچ اندازه‌ای برای آن در نظر گرفت یا پیشاپیش انجام‌ شده است.

۱/۲

برای برآورد آیتم‌های جزئی استفاده می‌شود.

۱-۲-۳

برای برآورد آیتم‌های کوچک به‌کار برده می‌شوند.

۵-۸-۱۳

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

۲۰-۴۰

برای برآورد آیتم‌های بزرگ‌تر مانند فیچرها یا استوری‌های سطح پایه استفاده می‌شود.

۱۰۰

نشان‌دهنده‌ی فیچرهای بسیار بزرگ یا اِپیک‌ها است.

آیتم به‌اندازه‌ای بزرگ است که برای برآورد آن از هیچ عددی نمی‌توان استفاده کرد.

؟

حالت اول: نشان‌دهنده‌ی این است که تیم آیتم را درک نکرده و باید درباره‌اش سؤالاتی از مالک محصول کند.

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

π

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

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

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

قوانین برنامه‌ریزی پوکر

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

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

برنامه‌ریزی پوکر مزایای خاصی برای دنیای چابک به‌همراه دارد؟

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

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

روش اندازه‌های تی‌شرت (T-Shirt Sizes)

T-Shirt Sizes

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

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

سیستم باکت

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

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

 The Bucket System

نکات

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

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

رأی‌گیری نقطه‌ای

Dot Voting

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

جمع‌بندی

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

تبلیغات
داغ‌ترین مطالب روز

نظرات

تبلیغات