یادداشت‌های در مورد روش‌های چابک اسکرام و تخمین زدن!

اینم یه تجربه پراکنده دیگه!

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

خب انروز بحث اسکرام/روش/ساختار توی گروه شرکت داغ بود منم چندتا مورد که به ذهنم میرسه رو اضافه کردم که گفتم شاید اینجا هم بدردتون بخوره.

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

۰ – اینکه من خودم و با اجازه بزرگترها خیلی از ما مهندس‌های نرم‌افزار رو در این حد از نظر احاطه به بحث توسعه فرآیند و ساختار نمیدونم که بتونن یه ساختار/روش کاری ایجاد کنن. پس ایده‌آل ام اینه که به یه روش/ساختار در سطح حلقه/تیم/شرکت به عنوان ریسمان محکم چنگ بزنم و از اون پیروی کنم. «پس به ریسمان محکم الهی چنگ بزنید و متفرق نشوید» آل‌عمران ۱۰۳

۱- به نظر بنده حقیر سراسر تقصیر، تمام روش‌های چابک/اجایل اومدن که دوتا کار کنن. اول عدم قطعیت رو مدیریت کنن. دوم تحویل به مشتری رو بیشینه کنن. پس جایی که ما با عدم قطعیت روبرو نیستیم یا تحویل به مشتری نداریم به نظرم اجایل اصالتا معنی نمیده.

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

۲- بازم به نظرم در جاهایی که بیشتر کارهای بیشتر تیم‌هاش از جنس عملیات و نگهداری هست آیا بایستی از اجایل استفاده کنیم؟ به نظرم آره. چون تهش ما هم عدم قطعیت داریم هم تحویل به مشتری. اما آیا اسکرام روش خوبی هست؟ به نظرم در تیم‌هایی که وزن توسعه توشون زیادتره بله. بقیه تیم‌ها چی؟ به نظرم اونها باید چیزی مثل کانبان/اسکامبان که مناسب‌تره استفاده کنن. ولی به نظرم باید بچسبیم به روش و سعی نکنیم مثلا بهبودش بدیم.

۳- و اما میرسیم به بحث جذاب تخمین. از نظر من تخمین درست کار خداست که تونست دنیا رو تو ۷ روز بی‌آفرینه و تازه معلوم نیست اون هفت روز واقعا چند روز بوده و بین علما اختلافه. یعنی چی؟ یعنی به تجربه به من ثابت شده که من و اکثر آدم‌هایی که دیدم نمیتونن درست تخمین بزنن. من خودم اینجوریم که اگه یه کاری از نظرم ۲ ساعت کار داشته باشه در عمل بطور متوسط ۶ ساعت طول کشیده تا انجامش بدم(من بصورت مداومی دارم چیزای مختلف رو میشمارم). و الان هر چی به ذهنم برسه و ضرب در ۳ میکنم. حالا این چه ایرادی داره. این باعث میشه من در هنگام قول دادن(بخونید پلنینگ) اگه بخوام زمان بدم همه چیز رو بدبینانه تخمین میزنم و این یعنی میزان کمتری کار تحویل میدم احتمالا. اما اگه بجای تخمین زمان در مورد بزرگی/سختی کار حرف بزنم و بگم این کار از نظر من واعضای تیم چقدر بزرگه، احتمالا تخمینم دقیق‌تره ولی زمانی هم براش نگفتم که بخوام چندبرابر تخمینم زمان بگم. و اگه چندتا اسپرینت بگذره عملا میتونم بگم من چقدر توان واقعی انجام کار دارم بدون اینکه تخمین زده باشم. نکته بعدی تخمین در آدمیزاد به تجربه ثابت شده که با بزرگ شدن کار بدتر میشه. یعنی من جارو زدن حال رو درست میتونم تخمین بزنم. ولی رفتن به کره ماه رو نه.
به همین خاطر اسکرام پوکر درست شده و از سری فیبوناچی که رشدش زیاده هم توش استفاده شده

فعلا همین!

2 دیدگاه در “یادداشت‌های در مورد روش‌های چابک اسکرام و تخمین زدن!

  1. امین می‌گوید:

    مطلب جالبی بود خیلی ممنون. با اجازه منم نظرم رو می‌گم.

    درباره مورد ۰ام، در کل با حرف‌تون موافقم. ولی این رو هم باید در نظر داشت که مثلا اسکرام یک روش تجویزی صرف نیست و مهم‌ترین سندی که برای اسکرام هست هم یک راهنماست. ولی دست بردن در اون راهنما یه شرط اساسی و مهمی داره که اون هم درک خوبی از چرایی وجود اون ایونت یا پراسسی که می‌خوایم تغییر بدیم و همین‌طور هدف اصلی که چابکی هست و در مانیفست اون گفته شده(که اسکرام قراره ما رو به اون سمت ببره)، هست. اگر در تیم ما مشکلی حس میشه که فکر می‌کنیم راهی برای چابکی بیشتر پیدا کردیم و تیم هم به اون بلوغ رسیده، میشه «تست»ش کرد. در تجربه من اغلب اوقات این مورد نبوده، ولی من شخصا همیشه در مقابلش ذهن بازی دارم.

    در مورد اجایل بودن، به نظرم همیشه باید چابک باشیم اگر چابکی رو واکنش سریع به تغییرات تعبیر کنیم. همون‌طور که گفتید چارچوبی که انتخاب می‌کنیم بستگی به کیس‌مون می‌تونه متفاوت باشه.

    در مورد بحث شیرین تخمین، آیا مستندی هست که خدا هم از قبل گفت در هفت روز می‌سازم یا ما فقط می‌دونیم که در هفت روز ساخته شده :))

  2. دهقانی می‌گوید:

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *