ضرب الاجل های خود را رعایت کنید: روش هایی که توسعه دهندگان برای برآورد تلاش استفاده می کنند

سلام، همه! مقدار زیادی نظریه وجود دارد که برای شروع توسعه نرم افزار باید بدانید. برخی از متخصصان (به عنوان مثال، توسعه دهندگان بک اند که از جاوا و سایر زبان ها استفاده می کنند) بیشتر آن را می دانند، در حالی که برخی دیگر (به عنوان مثال، توسعه دهندگان فرانت اند که از جاوا اسکریپت و React Native استفاده می کنند) ممکن است کمی کمتر بدانند. گفتنی است، هر دو گروه باید دارای حجم وسیعی از دانش نه تنها فنی، بلکه همچنین "سازمانی" باشند. این دانش "سازمانی" یکی از زمینه های همپوشانی برای توسعه دهندگان فرانت اند و باطن است. امروز می خواهم در مورد جنبه ای از این دانش غیر فنی و سازمانی صحبت کنم. امروز در مورد برآورد تلاش صحبت خواهیم کرد . از آنجایی که من فقط تجربه استفاده از متدولوژی Agile (که محبوب‌ترین روش در نظر گرفته می‌شود)، به‌ویژه چارچوب اسکرام را دارم، تخمین تلاش را در زمینه Scrum در نظر خواهم گرفت . درست در همان ابتدا، باید بگویم که برآورد تلاش دشوار است. برای من، این یکی از چالش برانگیزترین/ناخوشایندترین جنبه های شغل من به عنوان یک توسعه دهنده است. عوامل مختلفی وجود دارد که باید در نظر بگیرید که می تواند بر برآورد شما از تلاش مورد نیاز برای یک کار تأثیر بگذارد. علاوه بر این، برنامه های توسعه آینده بر اساس برآوردهای شما خواهد بود.

اگر تخمین بدی ارائه دهید چه؟

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

چگونه یک تخمین زمان انجام دهیم

به عنوان یک قاعده، تخمین ها بر حسب ساعت یا نقاط داستانی انجام می شود. ترجیح شخصی من این است که فرآیند تخمین را با استفاده از نقاط داستان انجام دهم . سخت است که در مورد اشیاء فیزیکی عینی اشتباه کنیم، اما نکات داستان کمی انتزاعی تر هستند. تیم‌های توسعه نرم‌افزار معمولاً تخمین‌هایی را به صورت مقدار زمان ارائه می‌کنند: ساعت، روز، هفته، ماه. این تخمین های زمانی در درجه اول بر اساس تجربه شخصی، حدس و گمان و/یا شهود است. در این مورد، توسعه دهندگان به سادگی به کار نگاه می کنند و فرض خود را در مورد اینکه چقدر زمان می برد بیان می کنند. در نتیجه، این تخمین ها به ندرت دقیق هستند، زیرا عوامل زیادی وجود دارد که می تواند بر مدت زمان کار تأثیر بگذارد. به همین دلیل است که بسیاری از تیم هایی که از متدولوژی Agile استفاده می کنند نیز از نقاط داستانی استفاده می کنند. بیایید شیرجه بزنیم!

نکات داستانی چیست؟

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

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

چگونه از نقاط داستان استفاده نکنیم

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

پوکر اسکرام چیست؟

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

تعداد نامشخصی از نقاط پایانی

کار بی نهایت طولانی

نیاز به استراحت

روش های کمتر رایج تخمین استفاده می شود:

• اندازه تیشرت - S، M، L، XL
• نژادهای سگ - چیهواهوا، پاگ، داشوند، بولداگ و غیره (شخصا، من فکر می کنم این عجیب ترین واحد اندازه گیری برای تخمین تلاش است =D)

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

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

فرض کنید تیم شما مقیاس زیر را برای تخصیص نقاط داستان به تخمین ها ایجاد کرده است: پوکر اسکرام برای هر کار انجام می شود و شما تخمینی را به شرح زیر ارائه می دهید:

• قبلاً هرگز عملکرد مشابهی را اجرا نکرده اید: +3
• عملکرد در اندازه متوسط ​​است: +2
• پیاده سازی بسیار پیچیده خواهد بود: +3
• تست های نوشتن برای عملکرد بسیار پیچیده خواهد بود: +3

با جمع کردن هر جزء، در مجموع 11 امتیاز داستان به دست می آورید، اما چنین کارتی وجود ندارد، بنابراین شما 13 را پیشنهاد می کنید. یکی از همکاران تخمین زیر را برای کار ارائه می دهد:

• او قبلاً با کار مشابهی کار کرده است: +1
• عملکرد در اندازه متوسط ​​است: +2
• پیاده سازی دارای پیچیدگی متوسط ​​خواهد بود: +2
• تست های نوشتن برای عملکرد دارای پیچیدگی متوسط ​​خواهد بود: +2

نتیجه متوسط ​​او 7 امتیاز داستانی است، اما این عدد در سری فیبوناچی وجود ندارد، بنابراین او کارتی را با تقریبی ترین عدد ارسال می کند - 8. سایر اعضای تیم نیز برآوردهای خود را بر اساس دیدگاه های ذهنی خود انجام می دهند. سپس همه کارت‌های خود را نشان می‌دهند و متوجه می‌شوید که تقریباً همه همکاران شما 13 تخمین زده‌اند، به جز یکی از توسعه‌دهنده‌ها که 8 را پیشنهاد کرده است. در این مورد، او مجاز است با او صحبت کند و دلایلی را برای برآورد کمتر خود ارائه می‌دهد. فرض کنید او این توجیه را ارائه می دهد: او قبلاً روی همان کار کار می کرد و آنقدرها هم که به نظر می رسد دشوار نیست. در نهایت، او بقیه اعضای تیم را متقاعد می کند که نظر خود را از 13 به 8 نقطه داستان تغییر دهند و می گوید که به هر کسی که این کار را انجام دهد کمک خواهد کرد. یا شاید خودش این کار را انجام دهد. در هر صورت، فرقی نمی‌کند که دیگران استدلال‌های او را بپذیرند یا نه، زیرا به هر طریقی تخمینی برای کار تعیین می‌شود و تیم به بررسی بعدی می‌پردازد. در ابتدا، تخمین ها نادرست خواهند بود، همانطور که تخمین های مقدار کاری که می خواهید در دوره بعدی انجام دهید (اسپرینت) نادرست خواهد بود. پس از همه، این برآورد با استفاده از تخمین زده می شود. پس از مدتی، شاید سه ماه بعد، تیم شروع به تخمین دقیق‌تر زمان مورد نیاز برای انجام وظایف می‌کند و میانگین کاری که تیم قادر به انجام آن در یک سرعت است آشکار می‌شود. اما این یک فرآیند برای ایجاد یک برنامه کلی برای محدوده کار است. عمدتاً بر زمان تمرکز می کند، اما در این مورد ممکن است عوامل مرتبط بسیار متفاوتی وجود داشته باشد. به عنوان مثال، فرض کنید یک توسعه دهنده به مدت دو هفته به تعطیلات رفته است. شما باید مقدار مشخصی از کار برنامه ریزی شده را کاهش دهید (عملکرد برنامه ریزی شده). یا فرض کنید یک توسعه‌دهنده جدید به تیم ملحق شده است، اما هنوز به طور کامل به سرعت عمل نکرده است، بنابراین باید به او زمان بدهید تا از طریق فرآیند نصب با پروژه آشنا شود . بسته به پیچیدگی پروژه، این ممکن است دو هفته باشد، یک هفته طول بکشد یا بگذرد. برای امروز کافی است! امیدوارم دانش شما را در مورد برآورد تلاش، یک جنبه غیر فنی ضروری توسعه نرم افزار، اندکی بهبود بخشیده باشم. اگر می‌خواهید عمیق‌تر به این موضوع و جزئیات اسکرام بروید، اکیداً توصیه می‌کنم کتاب «اسکرام» نوشته جف ساترلند را بخوانید. من نمی توانم هیچ قولی در مورد عواقب آن بدهم، زیرا پس از خواندن آن میل آزاردهنده ای برای تبدیل شدن به یک اسکرام مستر پیدا خواهید کرد =D