نویسنده: آنیتا هادیزاده – اسکرام مستر شرکت داتین

این نوشته برداشت آزادی از مجموعه سه ویدئوی منتشر شده توسط آقای Mike Cohn است که به چالش‌هایی که تیم‌ها در رابطه با تخمین زدن با استوری پوینت مواجه هستند، می پردازد .

قسمت اول / قسمت دوم

در این مطلب به یکی از جنبه‌های چالشی تخمین زدن کارها که سروکار داشتن با افراد تیم است، می پردازیم:

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

در ادامه، مثالهایی از تیم هایی که چالش های مربوط به افراد تیم را در تخمین زدن، تجربه کرده اند به اشتراک می‌گذاریم:

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

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

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

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

نمونه دیگر:

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

چنین شرایطی باعث شده بود که این تیم  مانند کمپ مطالعاتی برای نیروهای جدید شرکت عمل کند، وقتی نیروی جدیدی وارد شرکت می شد ابتدا برای یکی دو ماه در این تیم مشغول به فعالیت می شد و بعد به تیم های دیگر برای مدت طولانی تری می پیوست.

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

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

مشکل در هر دوی این مثال ها  این بود که اسکرام مسترها به جای شنیدن صدای جمعی تیم ، اقدام به مدیریت دیدگاه های شخصی افراد می نمودند.

در مثال اول افراد تیم  تا حد زیادی روی بخش های تخصصی خودشان متمرکز بودند و نمی توانستند تصور کنند چرا باید کاری غیر از کار تخصصی خودشان را تخمین بزنند. در مثال دوم، افراد تیم یا با دانسته های پیش فرض در مورد تخمین، از تجربه شرکت های قبلی شان، یا بدون هیچ دانشی درباره تخمین زدن وارد تیم شده بودند.

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

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

در ادامه پنج مشکل رایجی که اغلب در این خصوص روی می دهد را همراه با راهکارهایی که کمک می کند تا تیم با وجود پیش زمینه هایی که دارند، حین تخمین زدن، به نقطه مشترک برسند ، مطرح می کنیم :

• اعضای تیم احساس می کنند خارج از حوزه ی تخصص خودشان نمی توانند تخمین بزنند مثال: تسترها بگویند فقط می توانند بخش تست را تخمین بزنند

در چنین مثالی، تیم پیشنهاد می کند که انواع مختلف استوری پوینت را از کل کار بیرون بکشند، حالا  ببینیم چرا چنین کاری ایده خوبی به شمار نمی رود وغیر ضروریست:

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

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

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

 این تجربه در جلسات پلنینگ پوکر(planning poker )  زیاد تکرار شده است: تستر به کاری امتیاز 8 می‌دهد برنامه نویس امتیاز 5،  تستر چنین می گوید: این کار خیلی زمان تست نمی برد ولی برنامه نویسی اش باید سخت باشد چون دو ماه پیش که مشابه آن را انجام دادیم، بیشتر از تخمین طول کشید، بعد برنامه نویس کمی فکر می کند و تستر را تایید کرده عدد 5 را با 8 جابجا می کند. ممکن است برنامه نویس در پاسخ بگوید: بله متوجه شدم ولی این کاربسیار آسان است و تستر عددش را عوض کند و به 5 تغییر دهد.

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

ولی آیا این بدین معناست  که اگر تیم تخمین برنامه نویسی ، تست و … را جداگانه دهد موفق نخواهد بود؟ 

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

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

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

• مشکل بعدی به این دلیل به وجود می آید که  همه روی یک سطح  از کامل بودن  کار تخمین نمی زنند مثلا یک نفر ممکن است کار را تا مرحله نسخه گذاری تمام شده بداند و  تخمین بزند و دیگری تا رسیدن به مرحله تست پذیرش کاربر.  برای این دو تا وقتی که کار را تا نقاط پایان مختلفی تخمین می زنند بسیار دشوار است که به توافق برسند. برای حل این مشکل  باید بین اعضای تیم قرار گذاشته شود که  تمام تخمین‌ها برای رسیدن به یک تعریف ثابت و همیشگی از کار انجام شده باشد. تیم ها یی که (Definition of Done) “تعریف کار انجام شده ” دارند، (یعنی تعریف  ثابتی از  کارهایی که باید انجام شود تا یک قلم از بک لاگ انجام شده تلقی شود) در این زمینه موفق هستند. اگر نیاز است قبل از پایان کار یک قلم بک‌لاگ تست پذیرش کاربر، انجام شود باید این مرحله  در (DOD) “تعریف کار انجام شده” تیم تعریف  شود .

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

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

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

بعنوان مثال: یک قلم 5 استوری پوینت تخمین زده شده بوده ولی می توانسته 8 یا 3 باشد، زمانی که قلم جدید با آن قلم قدیمی که ضعیف تخمین زده شده مقایسه می شود تخمین خود قلم جدید هم اشتباه انجام می شود. مثلا قلمی که باید 8 استوری پوینت تخمین زده می شده  و 5 تخمین خورده، قلم جدید با آن مقایسه می شود و  باز به جای 8 عدد 5 را می گیرد.

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

اول از همه از تیم بخواهید از مقایسه با قلمهای خیلی قدیمی خودداری کنند. البته این کار را با ذهنیت محدود کردن انتخاب کارهای  قدیمی برای مقایسه انجام ندهید ولی به تیم در مورد مقایسه با قلمهای قدیمی ای که ممکن است به خوبی به یاد نیاورند هشدار دهید. قلمهای تخمینی مورد مقایسه، باید واقعی باشند تا منجر به تخمین های صحیح شوند.

 هر جلسه را با یک سری از نمونه های خوب برای مقایسه شروع کنید یک یا دو قلم برای هر سایز انتخاب کنید، قلمها می توانند از اقلامی باشند که پیاده سازی شده اند یا مواردی که  تخمین زده شده اند  ولی هنوز پیاده سازی نشدند. اکثر تیم ها از ترکیب هر دوی اینها استفاده می کنند. میتوان در هر جلسه  یک کپی از تخمین‌های قبلی انتخابی جهت مقایسه برای هر نفر بیاورید و ابتدای جلسه توزیع  کنید  یا اگر جلسه غیر حضوری است کمی قبل از شروع، این سری قلم‌ها را  برای افراد تیم ارسال کنید. همچنین بهتر است ابتدای جلسه دو سه مثال از پوینت‌های مختلف 2 یا 5 یا  8  بخوانید.

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

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

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

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

دوم ، می توان با به کارگیری روش های مختلف تخمین زدن، از “بریدن از تخمین زدن ” جلوگیری کرد . بعنوان مثال می توان از ترکیب تکنیک هایی مثل : ( Affinity Estimating) و (planning poker ) برای این منظور استفاده کرد.

(planning poker ) روش شناخته شده تری است . یک روش عالی که برای تجمیع کردن تیم روی هر تخمین از طریق بحث در خصوص جزئیات قلم در حال تخمین، طراحی شده است.  میتوان به تیم ها آموخت که  بین 15 تا 20 قلم را در هر ساعت با بکارگیری تکنیک planning poker تخمین بزنند. چنین هدفی برای تیم های با تجربه‌ی که آموزش دیده اند  و در حال تلاش برای توانا شدن در سریع تر تخمین زدن هستند،  قابل دستیابیست، اما این هدف همچنان در مقایسه با  آنچه با به کارگیری  روش Affinity Estimating ممکن می شود، آهسته می‌باشد.

Affinity Estimating یک روش سریع تخمین زدن  تعداد زیادی قلم از طریق محدود کردن بحث روی هر قلم است. اقلامی که روی تخمین آنها می توان سریع به توافق رسید، تخمین زده می‌شوند، اقلامی که بحث بیشتری نیاز دارند کناری قرار داده شوند تا تیم بعدا آنها را به روش planning poker تخمین بزند.

Affinity Estimating می تواند برای سبک نگه داشتن برنامه ریزی‌ها و جلوگیری از “بریدن از تخمین زدن ”  در جلسات، بسیار اثر بخش باشد . با به کارگیری این روش، می توان 100 آیتم را در یک ساعت تخمین زد. تیم ها معمولا نصف یا بیشتر اقلام را با روش Affinity Estimating تخمین می زنند و باقی را برای  تخمین به روش planning poker نگه می دارند و به این طریق می توان به طور قابل توجهی زمان کلی موردنیاز برای تخمین آیتم ها  را کاهش داد.