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

عکس پس زمینه توسط Guilia May در Unsplash با ویرایش های نویسنده. را

O مروری بر برآورد چابک

املاح آب در مقابل اندازه نسبی

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

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

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

وقتی بیشتر از آن ناشناخته است ، از اندازه نسبی استفاده کنید. متأسفانه ، انسان در هنگام کار در یک دامنه پیچیده مانند توسعه نرم افزار ، از تخمین و حتی بدتر از آن بد است.(2006 ، یورگنسن و گریمستاد). خوشبختانه ، مردم در مقایسه چیزها خوب هستند. برآورد چابک از اندازه نسبی برای ارائه روشی واقعی برای پیش بینی تیم ها استفاده می کند. این روش تخمین از توالی فیبوناچی به عنوان مقیاس شروع برای مقایسه موارد استفاده می کند. در دنباله فیبوناچی ، هر شماره مجموع دو عدد قبلی است: 0 ، 1 ، 2 ، 3 ، 5 ، 8 ، 13 ، 21…

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

توسعه دهندگان در اندازه تیم Scrum کارهایی که در مورد ارائه آنها پاسخگو هستند (توسعه دهندگان در Scrum شامل هر کسی است که برای توسعه کار ، از جمله تحلیلگران ، UX و متخصصان با کیفیت لازم باشد). آنها در مورد هر درخواست بحث می کنند و تعدادی از مقیاس فیبوناچی را که با اندازه کلی ارتباط دارد اختصاص می دهد. آنها از هر آنچه در مورد درخواست در آن مقطع زمانی می فهمند و آنچه انتظار می رود آن را کامل می نامند استفاده می کنند. این روش به نام Story Paining ، معتبر به ران جفری ، یک متخصص برنامه افراطی (XP) و رهبر اندیشه چابک نامیده می شود. در حالی که نقاط داستان شامل تلاش ، مانند تخمین مطلق ، این امر بیشتر ابهام مورد انتظار نیازهای چابک است. نقاط داستان نشان دهنده پیچیدگی ، عدم اطمینان و تلاش (نشانه) لازم برای تکمیل یا اجرای هر مورد کار است. هرچه این تعداد بیشتر باشد ، کار پیچیده تر و نامشخص تر و احتمالاً میزان تلاش برای تکمیل آن خواهد بود.

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

تیم ها هنگام استفاده از مقیاس فیبوناچی برای اندازه نسبی ، مزایای زیر را تجربه می کنند:

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

برنامه ریزی چابک

به تیم و روند اعتماد کنید

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

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

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

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

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

استفاده از برنامه ریزی افق در چابک. تصویر توسط نویسنده.

فیبوناچی عملی فیبوناچی

شروع شدن

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

تصویر توسط نویسنده

مربیگری مناطق خاکستری اندازه

این مکالمه با برخی از سؤالات متداول و نکات مربیگری در قسمت دوم ادامه می یابد: مربیگری مناطق خاکستری اندازه

کاردستی خود را صدا کنید ، حقیقت خود را بیان کنید ، تشکر کنید

برای دسترسی به یک کتابخانه رو به رشد وبینارهای توسعه حرفه ای و برای اشتراک در محتوای بیشتر به کانال YouTube من مراجعه کنید! بیشتر در Amplifyagility.com بخوانید