توسعه دهندگان از چه روش هایی برای ارزیابی وظایف استفاده می کنند؟

سلام به همه! تئوری مورد نیاز برای شروع توسعه بسیار گسترده است. برخی از متخصصان (توسعه دهندگان پشتیبان در جاوا و سایر زبان ها) بیشتر آن را دارند، در حالی که برخی دیگر (به عنوان مثال، توسعه دهندگان فرانت اند در جاوا اسکریپت - React Native) کمی کمتر دارند. با این حال، هر دوی آنها باید نه تنها دانش فنی، بلکه همچنین دانش "سازمانی" زیادی داشته باشند. این دانش "سازمانی" یکی از نقاط تقاطع توسعه دهندگان فرانت اند و باطن است. امروز می خواهم در مورد یک جنبه از چنین دانش غیر فنی و سازمانی صحبت کنم - در مورد ارزیابی وظایف (تخمین). و از آنجایی که من فقط در متدولوژی Agile کار کردم (که در واقع محبوب ترین محسوب می شود)، در قسمت فرعی آن، Scrum ، ارزیابی وظایف را در زمینه 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 داستان تغییر دهند. اشاره می کند و می گوید که او به هر کسی که این وظیفه را بر عهده بگیرد کمک می کند تا آن را بفهمد. یا در نهایت خودش این کار را می کند. و به طور کلی، مهم نیست که دیگران به استدلال های او گوش می دهند یا نه، زیرا به هر طریقی، رتبه ای به این کار اختصاص داده می شود و تیم به سمت آشنایی با کار بعدی حرکت می کند. دفعات اول، تخمین ها نادرست خواهند بود، همانطور که تخمین های مقدار کاری که قصد دارید در دوره زمانی بعدی انجام دهید (اسپرینت) نادرست خواهد بود. به هر حال، این برآوردها دقیقاً بر اساس برآوردها انجام می شود. پس از مدتی، حدود سه ماه، تیم شروع به تخمین دقیق‌تر وظایف می‌کند و میانگین کاری که تیم می‌تواند در هر دوی سرعت انجام دهد، قابل مشاهده خواهد بود. اما این یک برنامه ریزی کلی از محدوده کار است، بیشتر مربوط به زمان است و در این مورد ممکن است عوامل مختلفی تأثیرگذار باشد. به عنوان مثال، یکی از توسعه دهندگان به مدت دو هفته به تعطیلات رفت. یعنی باید مقدار مشخصی از کار برنامه ریزی شده (عملکرد برنامه ریزی شده) را خط بکشید. یا یک توسعه دهنده جدید به تیم آمده است، اما نیازی نیست کاملا روی او حساب کنید، زیرا ... شما باید زمان مورد نیاز برای انطباق با پروژه را در نظر بگیرید، به نام onboarding . بسته به پیچیدگی پروژه، این می تواند دو هفته، به علاوه یا منهای در هفته باشد. این همه برای امروز است، امیدوارم دانش شما را در بخش غیر فنی دانش مانند برآورد مشکل کمی بهبود بخشیده باشم. اگر می‌خواهید عمیق‌تر به این موضوع و همچنین جزئیات اسکرام بروید، به شما اکیداً توصیه می‌کنم کتاب «اسکرام» نوشته جف ساترلند را بخوانید. من نمی توانم عواقب آن را تضمین کنم، زیرا شاید بعد از آن میل آزاردهنده ای برای تبدیل شدن به یک اسکرام مستر داشته باشید =D