برتر

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

تمام دوره های ما توسط کارشناسان معتبر صنعت تدریس می شود ، در دوره های تقاضا با 10 ٪ تخفیف ثبت نام می کنند

وبلاگ های مرتبط

• نحوه ساخت و هدایت یک تیم Scrum با عملکرد بالا
• غلبه بر چالش های رایج در مراسم اسکرام
• چگونه به تیم خود کمک کنیم تا کار را در اولویت کار قرار داده و Backlog Sprint را مدیریت کنید
• اشتباهات رایج برای جلوگیری از به عنوان استاد اسکرام
• 5 تاکتیک اصلی برای تیم های Scrum برای ارتباط با مشتریان

چرا از اعداد فیبوناچی در تخمین نقطه داستان استفاده می شود؟

توسعه دهندگان و تخمین:

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

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

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

اندازه:

اندازه یک داستان کاربر ترکیبی از 3 عامل است - C U E:

• پیچیدگی
• عدم اطمینان - عدم وضوح داستان کاربر
• تلاش

توسعه دهندگان ممکن است از یکی از سریال های زیر برای اندازه گیری داستانهای کاربر در یک محصول عقب مانده استفاده کنند:

• اعداد طبیعی: 1 ، 2 ، 3 ، 4 ، 5 و غیره.
• حتی اعداد: 2 ، 4 ، 6 ، 8 ، 10 و غیره.
• سری Fibonacci: 0 ، 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 21 ، 34 و غیره.
• سری فیبوناچی اصلاح شده: 0 ، 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 20 ، 40 ، 100.
• یا هر سری دیگر

در میان اینها ، سری فیبوناچی اصلاح شده محبوب ترین سری برای اندازه گیری است.

اعداد فیبوناچی چیست؟

سری Fibonacci از دنباله ای از اعداد تشکیل شده است که در آن هر عدد مبلغی از دو عدد قبلی است. دنباله فیبوناچی سنتی 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 21 ، 34 و غیره است. در پروژه های چابک ، این سری اصلاح شده است. سری Fibonacci اصلاح شده 0 ، 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 20 ، 40 ، 100 - دنباله ای است که برای تخمین اندازه نسبی داستانهای کاربر از نظر نقاط داستان استفاده می شود.

اهمیت اعداد فیبوناچی در اندازه چابک:

آنها نمایی هستند

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

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

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

با استفاده از سری Fibonacci در چنین مواردی مفید است زیرا داستانهای بزرگتر کاربر که منجر به برآورد متناقض بین اعضای تیم می شوند ، اکنون می توانند در داستانهای کاربر کوچکتر تجزیه شوند. آنها همچنین می توانند به نزدیکترین تعداد فیبوناچی سطل مشابه در عقب ماندگی گروه بندی شوند. داستانهای کاربر کوچکتر تفاوت سطل کوچکتر دارند ، که منجر به اندازه واقع بینانه تر (C U E) می شود.

آنها از عدد صحیح تشکیل شده اند

در چابک ، هر دو نیاز و راه حل در طی یک دوره زمانی تکامل می یابد. تخمین ها (اندازه داستان های کاربر) نیز هستند. هدف از اندازه گیری این است که یک برآورد سطح بالا و شروع کار را بدست آورید. بنابراین ، نیازی به سطح جزئیات در سطح اعشاری دقیق نیست. تلاش برای دقیق بودن ممکن است تیم را کند کند. از این گذشته ، مخروط عدم اطمینان می گوید که اندازه واقعی داستان های کاربر در جایی بین +160 ٪ و-160 ٪ از اندازه های تخمین زده شده اولیه به پایان می رسد.

شما باید کم و بیش انتخاب کنید

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

غیر خطی هستند

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

پیچیدن آن

توسعه دهندگان می توانند با توجه به توالی که استفاده می کنند، تجربیات متفاوتی با توالی های تخمینی متفاوت داشته باشند. با این حال، اکثر توسعه دهندگان استوری کاربر را از نظر اندازه نسبی اندازه گیری می کنند که ترکیبی از 3 فاکتور به نام های C-Cplexity، U-Uncertainty و E-Effort است.

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