مطلب زیر، خلاصه ای از پست Maarten Dalmijn است که در Medium منتشر شده و نقدی بر جنبش #NoEstiames می باشد. من بر اساس تجربه شخصی با آقای مارتین موافق هستم و تخمین تسک و اسپرینت مهمترین بخش کار مدیریت پروژه هست (البته بعد از هنر کامیونیکیت)
آنچه باید بدانید :
اجایل (Agile) : بدون اینکه بدونیم اجایل چیست، این مطلب رو نمیتونیم بفهمیم. مطلب خلاصه و مفیدی اینجا هست.
استوری پوینت (Story Point) : یک روش خرد جمعی برای تخمین ساعت هست که هر Point در واقع معادل مقدار ساعت کار روی یک موضوع مشخص می باشد. به عبارتی یک نسبت پایه برای یک موضوع در نظر گرفته می شود و برای آن 1 Point در نظر میگیریم. مثلا تولید یک صفحه CRUD،دو روز یا به عباریتی 15 ساعت طول میکشد. حال برای فرمی با 3 Crud که به صورت Tablular تولید می شود، مثلا 3 پواینت در نظر گرفته می شود. البته ما الزامی در این مدل تخمین زمانی نداریم و من هم در اینجا صرفا برای آشنا شدن با این عبارت توضیح دادم.
در این روزها از جنبش #NoEstimates بیشتر از گذشته صحبت می شود و من می خواستم دلیل این جذابیت را بدانم، برای همین تیم من 3 ماه این مساله را مورد آزمایش قرار داد، ودر نهایت به این نتیجه رسیدم که چیزی که تیم NoEstimate میخواهند آن را باور کنیم در عمل به دست نمی آید.
قبل از اینکه در مورد مزایا و معایب #NoEstimates بحث کنیم ، بیایید ابتدا در مورد استدلال جنبش بحث کنیم.
دلایل جنبش برای عدم استفاده از تخمین زمانی :
اینها دلایل جنبش NoEstimate هستند که البته من هم با آنها موافق هستم. برآورد شما در نهایت صرفا برآورد هست ولی مهمتر از اون، این هست که کار به چه صورتی انجام خواهد شد. این نکته هم درسته که تلاش برای رسیدن به تخمین اولیه و نرسیدن به ددلاین،منجر به فشار بیش از حد به تیم شما خواهد شد. نکته بعدی هم این هست که شما تا زمانی که پیاده سازی رو شروع نکنید، شناخت واقعی از حجم کار نخواهید داشت. و در نهایت ، تلاش برای انجام کار طی برآورد زمانی، در صورتی که این برآوردها اشتباه باشد، فشار روانی زیادی به تیم وارد میکنه و قطعا بخشی از کار حذف میشود و البته در طولانی مدت، منجر به پیشرفت کمتر به نسبت هزینه بیشتر می شود.
اما !
اما من فکر میکنم، این برآوردهای زمانی نیست که این این فشار را به تیم وارد میکند، بلکه روشی که برای تشخیص، ابلاغ و درک این برآورد ها استفاده شده، باعث ایجاد این مشکل می شود. منظورم این است که وقتی در حین کار واقعی، متوجه این میشویم که برآوردهای زمانی رو باید اصلاح کنیم، این کار باید حتما انجام بشه، یعنی برآوردهای زمانی اولیه باید مرتبا بر روی تایم لاین (بر اساس داده های جدید ) به روز رسانی بشود. اما چرا این کار انجام نمیشود ؟ چون تیم های اسکرام به تخمین ها و جدول زمانی اولیه متکی هستند و علت این موضوع هم فشار خارجی (مشتری یا مدیران بالاتر یا ... ) می باشد ! (پاسخ به دلیل شماره دو جنبش)
و من قبول ندارم که راه حل این مساله کنار گذاشتن برآورد زمانی است و فکر میکنم نکته ای در این مساله پنهان شده است که اون نکته این هست :جنبش #NoEstimates خود در واقع نوعی برآورد زمانی است و به صورت خلاصه معنی #NoEstimates این است که شما برآورد رو انجام میدید اما به شکل متفاوتی .
در واقع در کار با اسکرام، تخمین و برآورد زمانی یک مساله کاملا اجباری است. اگر در این مورد تردید دارید ، آنچه در راهنمای Scrum نوشته شده است را میتوانید ببینید :
کلیه آیتمهای بک لاگ محصول دارای این ویژگی ها باید باشند : شرح، ترتیب ، برآورد و ارزش . Scrum Guide ، نوامبر 2017
پس بک لاگهای محصول در Scrum باید برآورد داشته باشند. این برآورد یا باید مانند زمانی که از Story Points استفاده می کنیم صریح باشد یا یک برآورد ضمنی ، با بخش کردن آیتمهای کاری به بخش های کوچکتر (Slicing) ، در هر صورت در یک Sprint جای خواهند گرفت. به عبارتی مهم نیست که از چه روشی استفاده می کنید و تیم توسعه باید سوال زیر را پاسخ دهد: آیا ما اعتقاد داریم که در اسپرینت جای می گیرد؟ پاسخ به این سوال بدین معنی است که برآورد انجام شده است !
با مقایسه کردن #NoEstimates با Story Points می توانم این را بگویم : برآورد با Story Points معمولاً به این معنی است که شما روی یک عدد از یک دنباله فیبوناچی با هم توافق می کنید:
1 2 3 5 8 13 20 40 100
وقتی #NoEstimates را انجام می دهید ، این توالی به دو عدد تقلیل می یابد:
1: در یک بازه زمانی قابل اجرا قرار میگیرد !
0: در Sprint نمی گنجد !
یعنی : یا در یک Sprint جا می گیرد یا جا نمیگیرد !
وقتی تیم شما مدل برآورد زمانی اول را انجام می هد، طبق روال عادی، افراد تیم معمولاً مکالمه بیشتری دارند تا ببینند آیا می توان برای بهبود جریان و پیش بینی زمان انجام کار، کارها را کوچک تر کرد و این مکالمه هست که کمک میکند تا بتوان تصمیم بهتری گرفت حال آنکه، در #NoEstimates انجام این کار ضروری نیست زیرا اگر پاسخ 0 باشد (یعنی در اسپرینت قرار نمیگیرد) افراد تیم باید صحبت کنند تا ببیند چه کاری می توان برای کوچکتر کردن آن انجام داد. خلاصه این بخش این می شود که در Estimate افراد برای بهبود کار، مکالمه میکنند، ولی در NoEstimate، افراد برای کاری که در اسپرینت قرار نخواهد گرفت برای کوچکتر کردن صحبت میکنند.
اگر با نتیجه گیری من موافق باشید که #NoEstimates هنوز نوعی تخمین است، سوالی که مطرح می شود این است که استفاده نکردن از Story Points و استفاده از #NoEstimates به جای آن چه تاثیری دارد؟
در تیم های اسکرام ما 2 ساعت در هر جلسه وقت صرف می کنیم. در طول این زمان ، 4 مرحله را دنبال می کنیم:
هنگامی که ما شروع به انجام #NoEstimates کردیم ، مرحله 4 را با این سوال ساده جایگزین کردیم: آیا در Sprint جای می گیرد؟ اگر بله ، پس آماده تحویل گرفتن است. درغیر اینصورت ، کار مورد نظر در Backlog رابه بخشهای کوچکتر تقسیم میکنیم. پاسخ به این سوال راحت تر است و قطعاً زمان کمتری نیز می برد.
در حالتی که برآورد ما بدون Story Points انجام می شود، در حدود 10 دقیقه صرفه جویی می کنیم. این تقریباً به همان اندازه زمان برگزار نکردن Daily Scrum است. آیا این مقدار وقت اضافی که صرفه جویی خواهید کرد واقعا ارزش این همه هیاهوی اطراف #NoEstimates را دارد؟
ما می توانیم توافق کنیم که شما با #NoEstimates کمی وقت صرفه جویی کنید ، اما چه چیزی را از دست می دهید و آیا این ارزش آن را دارد؟
وقتی از #NoEstimates استفاده می کنید ، اطلاعاتی را که هنگام استفاده از Story Points یا شکل دیگری از تخمین ارائه می شود از دست می دهید:
نتیجه گیری :
ضمنا لینک اولیه این مطلب از کانال خوب Iran Agile به دست اومده که در صورتی که علاقه مند به این موضوعات هستید مطالب خوبی رو پیشنهاد میکنه
