برآورد چابک در اسکرام؟ امتیاز داستان و پوکر برنامه‌ریزی

Table of Contents hide

1 مشکلات

2 معدن مدیر پروژه/مالک محصول

7.1 کارت پوکر و دنباله فیبوناچی

7.2 ویژگی‌های برآورد مرتبط با دنباله فیبوناچی

7.3 اعداد ویژه در کارت پوکر

11 مقالات در تکنیک‌های اسکرام

در فرآیند توسعه نرم‌افزار، تیم اغلب یک سوال دارد:

چگونه زمان کار به‌طور دقیق‌تر برآورد می‌شود؟

برای صاحب پروژه یا محصول، این اطلاعات بسیار مهمی برای اندازه‌گیری منابع و زمان‌بندی‌های پروژه است، اما این عمل باعث بروز مشکلات زیادی شده است.

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

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

بسیاری از مدیران پروژه همیشه احساس می‌کنند که توسعه‌دهندگان بیشتر تمایل دارند که در برآورد کار خود «اغراق» کنند. به نظر می‌رسد که همه آنها از روش معمول برآورد کار استفاده می‌کنند: «برآورد سه برابر زمان واقعی به عنوان بافر»

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

مشکلات

معدن توسعه‌دهنده

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

معدن مدیر پروژه/مالک محصول

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

نتیجه

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

راه‌حل‌ها

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

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

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

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

1. مقایسه‌ها از فردی به فرد دیگر متفاوت نیست: پیچیدگی الزامات اغلب از فردی به فرد دیگر متفاوت نیست و زمان مورد نیاز برای عمل از فردی به فرد دیگر متفاوت خواهد بود.

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

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

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

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

سپس جنبه‌های مختلف راه‌حل را توضیح دهید.

زمانی که

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

چه کسی

فقط افرادی که کارها را انجام می‌دهند باید با هم ارزیابی کنند: دو نکته کلیدی:

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

چه چیزی

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

کارت پوکر و دنباله فیبوناچی

اینسری فیشراین ویژگی جالبی دارد و هر عدد مجموع دو عدد اول است. از طرف دیگر، هر چه تفاوت بین عدد و عدد بعدی بیشتر باشد، تفاوت بزرگتر است.

همانطور که در بالا نشان داده شده، فاصله بین 8 و 13 برابر 5 است و تفاوت بین 13 و 20 برابر 7 است. با این حال، این چگونه به برآورد پیچیدگی تقاضا مربوط می‌شود؟ ما در کلاس ریاضی نیستیم.

ویژگی‌های برآورد مرتبط با دنباله فیبوناچی

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

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

زیرا شکاف دیجیتال بزرگ است (نسبت تفاوت دو مقدار جلو و عقب دنباله فرمی نزدیک به 1.618 است)، می‌توان از برآورد اینکه “آیا این پیچیدگی 20 یا 21 است” اجتناب کرد. “اگر 13 می‌خواهید، 20 می‌خواهید، 40 می‌خواهید.

چنین شکافی می‌تواند تفاوت در برآوردهای یک نیاز مشابه را برجسته کند، زیرا تقریباً همه آنها بیش از 1.5 برابر بدتر هستند. این نسبت برای انسان‌ها نسبت به قضاوت اندازه نسبی بسیار آسان است و بنابراین می‌تواند بسیاری از جزئیات و هزینه‌های غیرضروری فرآیند برآورد مجدد را کاهش دهد.

اعداد ویژه در کارت پوکر

علاوه بر این، در تصویر بالا می‌توان چند عدد ویژه را مشاهده کرد که شامل 0، بی‌نهایت و علامت سوال است.

0 ممکن است به این معنی باشد که این نیاز اصلاً نیازی به انجام ندارد یا اینکه قبلاً انجام شده است.
بی‌نهایت به این معنی است که تقاضا واضح است، اما عددی که از حداکثر عدد فراتر می‌رود نشان می‌دهد که تقاضا نیاز به تقسیم به چندین نیاز با اندازه کوچکتر دارد.
علامت سوال نشان می‌دهد که تقاضا واضح نیست و نیاز به توضیح یا روشن‌سازی از سوی PO/PM دارد.

چگونه

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

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

3. اگر در تیم برآوردهای متفاوتی وجود داشته باشد، دو عدد به عنوان کوچکترین و بزرگترین برآورد می‌شوند و آنها ارزیابی می‌کنند که چرا پیچیده یا ساده هستند. در مثال بالا، در فرآیند برآورد، اگر یک نفر برآورد کند که امتیاز داستان 13 است، بیشتر افراد 20 و یک نفر دیگر 40 را برآورد می‌کنند. 13 و 40 تقریباً 3 برابر بدتر هستند، بنابراین اساساً باید اطلاعات مهمی وجود داشته باشد که همگام‌سازی نشده است.

برای مثال، افرادی که 13 را برآورد می‌کنند فکر می‌کنند که این تقاضا تقریباً مشابه یک نیاز در گذشته است و این نیاز به اندازه‌ای که تصور می‌شود پیچیده نیست. فردی که 40 را برآورد می‌کند ممکن است احساس کند که این نیاز نسبتاً پیچیده است زیرا به اندازه کافی با این نیاز یا فرآیند آشنا نیست.

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

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

دوباره، فقط کسانی که واقعاً وظایف را انجام می‌دهند یا نیازها را کامل می‌کنند می‌توانند در فرآیند رأی‌گیری شرکت کنند و PO/PM نمی‌تواند دخالت کند.

چرا

چندین مزیت برای این روش برآورد وجود دارد:

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

نتیجه‌گیری

از طریق فرآیند برآورد فوق، چنین تصمیمی باز، شفاف، عینی و توافقی است. برای دو نقش:

برای PO/PM:

نگران برآورد بیش از حد یک کار برای یک بافر توسط برخی اعضا نباشید.
درک دشواری‌های زیرین اجرای نیازها یا وظایف در فرآیند ارزیابی.
درک کنید که آیا بخش‌هایی از نیاز وجود دارد که نیاز به بیان واضح یا سوءتفاهم دارد.

برای تیم:

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

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

مقالات در تکنیک‌های اسکرام

This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.