https://virgool.ir/feed/@iamkheradmandSoftware Engineerfa2026-11-10 18:23:01https://files.virgool.ir/upload/users/157029/avatar/NsFf4W.jpghttps://virgool.ir/@iamkheradmandhttps://virgool.ir/@iamkheradmand/اسکرام-به-درد-تیم-من-نمیخوره-z5xjar4mtugkآرمان شهر اسکرام و توسعه چابک (Agile) به سکونتگاهی اجباری برای تیم‌ها تو شرکت‌های ایرانی تبدیل شد و فرار از این شهر به امری غیرممکن تبدیل شده چرا که هرگونه انتقاد و اعتراض به مثابه کفر تلقی میشه! دینی مقدس که پیروانش معتقدن هیچ‌گاه اون‌طور که باید درست اجرا نشده؛ چرا که اسکرام در اصل و اساس، جز در مسیر تعالی تیم گام برنمی‌داره ولاغیر.اجایل یا چابکی از اون دسته واژه‌ها و روش‌هایی بود که برای کشوری که تازه داشت با پدیده عصر یونیکورن‌ها و ظهور استارتاپ‌ها روبه‌رو میشد، به شدت جذاب بود؛ چرا که زمان مهمترین عنصر برای استارتاپ‌ها در شکست رقبا و فتح بازار کشور بود. اما به مرور و با گذشت زمان استارتاپ‌ها به کسب و کاری پایدار و بالغ تبدیل شدن؛ البته نه در همه ابعاد! عادت‌های قدیمی همچنان تکرار می‌شدن، بدون اینکه قرار باشه تو شرایط جدید همون نتایج گذشته رو رقم بزنن. اسکرام به‌تدریج به پدیده‌ای شبیه به Cargo Cult تبدیل شد: تقلید ظاهر یک روش، بدون درک علت و سازوکار موفقیت آن.مشکلات از جایی شروع شد که Agile از یک ویژگی به یک محصول تبدیل شد. چابکی در اصل قرار نبود اسم یک روش مشخص، مجموعه‌ای از جلسات یا چیزی باشه که سازمان بتونه اون رو بخره و پیاده‌سازی کنه. Agile یعنی یک تیم بتونه متناسب با شرایطش تغییر کنه، از نتیجه‌ی تصمیم‌هاش یاد بگیره و مسیرش رو اصلاح کنه. انگار که کافیه چندتا نقش تعریف کنیم، جلسات اسکرام رو برگزار کنیم و بعد با خیال راحت بگیم: "ما Agile هستیم!".مشکل اصلی متدولوژی آماده اینه که هیچ قانون و روشی بدون درنظر گرفتن Context معتبر نیست! اسکرام هم از این قاعده مستثنا نیست. اسکرام می‌تونه برای بعضی از تیم‌ها ابزار مفیدی باشه، اما وقتی بدون توجه به ماهیت کار به انتخاب پیش‌فرض همه‌ی تیم‌ها تبدیل میشه، دیگه در خدمت چابکی نیست. اون موقع به‌جای اینکه فرایند خودش رو با واقعیت تیم هماهنگ کنه، این تیمه که باید خودش رو به زور داخل قالب فریم‌ورک جا بده.این متن تلاشی برای اثبات بد بودن اسکرام نیست. مسئله اینه که تو خیلی از سازمان‌ها، اسکرام از یک ابزار اختیاری به نسخه‌ی پیش‌فرض همه‌ی تیم‌ها تبدیل شده؛ نسخه‌ای که ناموفق بودنش معمولاً به اجرای ناقص تیم نسبت داده میشه، نه به نامتناسب بودن خود چارچوب با مسئله. درمواردی حتی با اجرای درست و اصولی هم باز مشکلی حل نمیشه چرا که گره کار، خارج از تیم و مربوط به رویکرد سازمانهوقتی Velocity به هدف عملکرد تبدیل می‌شهآدم‌ها و سازمان‌های بالغ میدونن که به ندرت قراره نتایج فوری دریافت کنن. اون‌ها درک می کنن چیزهای خوب زمان می‌برن و نتایج ارزشمند یک‌ شبه به دست نمیاد؛ هر چیز خوبی برای شکل‌ گرفتن به زمان نیاز داره. با این‌ حال، خیلی از کسب‌وکارها همچنان به همون عادت‌هایی چسبیدن که در دوران رقابت برای فتح بازار شکل گرفته بود؛ انگار که سریع‌تر بودن، همیشه به‌معنای بهتر بودنه! وقتی کسب‌وکار به ثبات رسیده، محصولش بالغ شده و هر تغییر می‌تونه روی تعداد زیادی کاربر، فرایند و سیستم اثر بذاره، سریع بودن دیگه همیشه به‌معنای بهتر بودن نیست. توی این مرحله، تغییرها باید سنجیده‌تر، هدفمندتر و واقعا ارزشمند باشن؛ نه اینکه سازمان فقط به‌خاطر حفظ ظاهر چابکی، مدام چیزی رو تغییر بده یا سریع‌تر تحویل بده.مفهوم Velocity قرار بود صرفا معیاری مختص هر تیم برای مشاهده روند کار و برنامه‌ریزی بهتر باشه. اما توی خیلی از شرکت‌ها، به یک KPI برای سنجش بهره‌وری تبدیل شد.(منظور اینه که تیم با نگاه کردن به Velocity چند اسپرینت قبلی، بفهمه تقریبا تو هر اسپرینت چه مقدار کار می‌تونه انجام بده. مثلا اگه تیم توی اسپرینت های قبلی حدود ۳۰ استوری‌ پوینت کار کرده، برای اسپرینت بعدی هم به‌جای انتخاب ۵۰ امتیاز، حدودا همون ۳۰ امتیاز کار برمی‌داره. پس Velocity قرار نیست عملکرد یا سخت‌کوشی تیم رو اندازه بگیره؛ فقط به برنامه‌ریزی تقریبی کمک می‌کنه)مدیرها شروع میکنن به پرسیدن، چرا سرعت تیم کاهش پیدا کرده یا سرعت یک تیم رو با تیم دیگه مقایسه می‌کنن. اما تیم‌ها به‌مرور شروع کردن به:تقسیم کردن هدفمند کارها برای گرفتن امتیاز بیشتردادن استوری‌پوینت‌های غیرواقعیدوری کردن از کارهای پیش‌بینی‌نشده اما ضروری در اولویت قرار دادن کارهایی که صرفا اعداد و آمار دلیوری تیم رو بهتر می‌کننتحت فشار گذاشتن اعضای تیم برای کامل کردن سریعتر تسک‌هامحور قرار دادن تیم، نه ارزش های سازمانوقتی چنین نگاهی شکل می‌گیره، تیم احساس می‌کنه باید تو هر اسپرینت تعداد مشخصی امتیاز به دست بیاره؛ هدف اصلی دیگه حل مسئله و ایجاد ارزش نیست، بلکه جمع‌کردن امتیاز و حفظ نمودار Velocity برای گزارش به مدیران بالا رده و ذی نفع‌هاست (Stakeholders). اسکرام بیشتر به چیزی تبدیل شده که مدیریت می‌تونه کنترل و اندازه‌گیریش کنه، نه روشی که واقعا سازمان رو چابک کنه.تحویل دادن محصول اشتباه یا بی‌استفاده در زمان مشخص، همچنان شکست محسوب میشه! تموم کردن کار طبق تخمین و برنامه زمانی، وقتی خود نرم‌افزار ارزش واقعی ایجاد نمی‌کنه، دستاورد مهمی نیست.اسکرام لزوما تیم‌ها رو خودخواه نمی‌کنه، اما وقتی چابکی فقط در سطح تیم پیاده بشه و هر تیم با اهداف، بک‌لاگ و شاخص‌های جداگانه ارزیابی بشه، زمینه‌ی Local Optimization شکل می‌گیره؛ یعنی تیم برای موفقیت خودش تصمیم می‌گیره، حتی وقتی اون تصمیم به ضرر جریان ارزش در کل سازمانه. خروجی مهم‌تر از نتیجه (Output > Outcome)در ادامه بحث قبلی باید دید که تاثیراتش بر تیم به چه شکلی میشه.تو پایان هر اسپرینت، معمولا آمارهایی مثل تعداد تسک‌های بسته‌شده، work log اعضا تیم، کارهای منتقل‌شده به اسپرینت بعد و… از برد Jira استخراج میشن. این عددها می‌تونن برای پیدا کردن مشکل و بررسی روند کار تیم مفید باشن، اما وقتی تمام ارزیابی تیم به همین آمار محدود میشه، تفاوت بین Output و Outcome از بین میره.درواقع Output نشون میده که تیم چند تسک بسته یا چند امتیاز تحویل داده؛ اما Outcome دنبال نتیجه‌ میگرده: آیا مشکل مهمی از کاربر حل شده؟ آیا فرایندی سریع‌تر یا مطمئن‌تر شده؟ آیا ریسک یا خطایی کاهش پیدا کرده؟ ممکنه تیم توی اسپرینت تعداد زیادی تسک ببنده، بدون اینکه ارزش مهمی ایجاد کرده باشه. از طرف دیگه، ممکنه زمان زیادی صرف حل یک مشکل پیچیده، کاهش بدهی فنی یا جلوگیری از یک Incident بشه، اما چون خروجی اون به‌راحتی در نمودارهای Jira دیده نمیشه، تیم کم‌کار به نظر برسه.وقتی در پایان اسپرینت فقط گفته میشه "این اسپرینت کم کار کردیم" یا "این دفعه آمارمون بهتر بود"، اعضای تیم احساس می‌کنن کیفیت و نتیجه‌ی کارشون دیده نمیشه. به‌مرور انگیزه‌ی حل مسائل سخت و ارزشمند کمتر میشه و تمرکز تیم میره سمت کارهایی که سریع‌تر بسته میشن و عددهای بهتری می‌سازن. در چنین شرایطی، معیارها دیگه ابزاری برای یادگیری نیستن؛ تبدیل میشن به هدفی که رفتار تیم رو تغییر میده.عددها باید شروع یک گفت‌وگو باشن، نه حکم نهایی درباره‌ی عملکرد تیم. سوال اصلی نباید این باشه که "چقدر کار تحویل دادیم؟"، بلکه باید بپرسیم: "کاری که تحویل دادیم، چه تغییری ایجاد کرد؟"تیم، مقصر همیشگیکاهش سرعت جریان انجام کار، اغلب نتیجه‌ی تنبلی یا کم‌کاری اعضای تیم نیست؛ وابستگی به تیم‌های دیگه، جلسات و فرایندهای دست‌ و پاگیر، تغییر مداوم اولویت‌ها، تصمیم‌گیری‌های کند و موانع سازمانی معمولا نقش بسیار بزرگ‌تری دارن. چابکی همیشه برعهده تیم نیست بلکه بسیار بزرگتر و گسترده‌تر از توانایی تیم و شامل همه بخش‌های سازمانه!میخوام بگم که چابکی فقط به برگزاری جلسات اسکرام، برنامه‌ریزی اسپرینت و مدیریت بک‌لاگ خلاصه نمیشه. بخش مهمی از چابکی تیم به چیزهایی بستگی داره که کمتر بهشون توجه میشه؛ چیزهایی مثل : تمام تصمیم‌گیری‌ها از بالا انجام میشه و تیم‌ها اختیاری ندارنمدیرها جزئیات کار رو تعیین میکننمعماری سازمان بر پایه‌ی سیلوهای مستقله!زیرساخت مناسب برای تست‌نویسی یا اتومیشن تست‌‌ها وجود نداره ابزارهای Observability برای پیدا کردن سریع مشکلات کامل نیستن بدهی‌های فنی بیداد میکنهو ...تیمی که برای هر تغییر کوچیک نیاز به چند روز تست دستی داره، برای دیپلوی باید منتظر تیم‌های دیگه بمونه یا به‌خاطر بدهی‌های فنی از تغییر دادن بخش‌های مختلف سیستم می‌ترسه، صرفا با برگزاری منظم جلسات اسکرام چابک نمیشه!درواقع این زیرساخت‌ها و کیفیت فنی سیستم هستن که مشخص می‌کنن تیم با چه سرعت و اطمینانی می‌تونه تغییر ایجاد کنه، بازخورد بگیره و ارزش جدیدی رو به دست کاربر برسونه. مواردی که توی جلسات رترو مطرح میشه اما معمولا به جایی نمیرسه…سِرِمونی ها!اسپرینت یا ددلاین؟اسپرینت قرار بود یک چرخه‌ی کوتاه برای گرفتن بازخورد ایجاد کنه، اما در عمل خیلی وقت‌ها تبدیل میشه به پروژه‌ی کوچیک با ددلاین ثابت. تیم بارها این جمله رو می‌شنوه که: "شما این کارها رو برای این اسپرینت Commit کردین، پس باید تا آخر اسپرینت تموم بشن."این نگاه کم‌کم باعث میشه تیم نزدیک پایان اسپرینت اضافه‌کاری کنه، تست‌ها با عجله انجام بشن، کیفیت کد پایین بیاد، کارهای ناقص پنهان بشن و حتی بعد از یاد گرفتن چیزهای جدید، تیم از تغییر دادن Scope بترسه!مشکل از جایی شروع میشه که تخمین‌ها تبدیل به تعهد میشن و تعهدها هم کم‌کم شکل ددلاین به خودشون می‌گیرن. در این شرایط، اسپرینت به‌جای اینکه فرصتی برای یادگیری و گرفتن بازخورد باشه، تبدیل میشه به فشاری برای تمام کردن یک لیست از قبل تعیین‌شده؛ فشاری که در نهایت ریتم پایدار کار تیم رو از بین می‌بره.این فشار معمولا با پایان اسپرینت هم تموم نمیشه. تیم در طول اسپرینت تحت فشاره که همه‌ی کارهای Commit‌ شده رو تا ددلاین تموم کنه، اما وقتی برای رسیدن به این هدف اضافه‌کاری می‌کنه، تست‌ها رو با عجله جلو می‌بره یا کیفیت رو فدای زمان می‌کنه، توی جلسه‌ی Retro دوباره خودش مورد سوال قرار می‌گیره:"چرا اضافه‌کاری کردین؟ چرا کارها با عجله انجام شدن؟ چرا از اول Estimate دقیق‌تری ندادین؟ مگه تسک درست Refinement نشده بود؟"تیم توی یک موقعیت متناقض قرار می‌گیره؛ از یک طرف باید تحت هر شرایطی تعهد اسپرینت رو کامل کنه و از طرف دیگه نباید برای رسیدن به اون تحت فشار قرار بگیره یا اضافه‌کاری کنه. نتیجه این میشه که تیم هم به‌مرور یاد می‌گیره مشکلات واقعی رو پنهان کنه، تخمین‌ها رو بزرگ‌تر بده یا کیفیت رو طوری پایین بیاره که فقط کارها تا پایان اسپرینت بسته بشن. جلسات Refinement و Planning تعیین روزهای ثابت برای جلسات Refinement و Planning تو نگاه اول باعث نظم میشه، اما این مدل برای همه‌ی تیم‌ها جواب نمیده. توی تیم‌هایی که کارها پیچیده و حساس‌ان و وابستگی‌ها زیادن، همین تقویم ثابت می‌تونه خودش تبدیل به یک گلوگاه بشه.آماده کردن درست یک تسک پیچیده فقط به نوشتن چند خط توضیح و مشخص کردن Acceptance Criteria محدود نمیشه. نیازمندی‌ها باید بررسی بشن، ابهام‌ها برطرف بشن، وابستگی‌های فنی و محصولی مشخص بشن و گاهی چند راه‌ حل مختلف هم ارزیابی بشه. از طرف دیگه، پروداکت اونر و تک‌لید معمولا هم‌زمان درگیر مسائل عملیاتی، تصمیم‌های فنی، هماهنگی با تیم‌های دیگه و جلسات مختلف هم هستن.این مدل تیم رو مجبور می‌کنه حجم زیادی از کار رو یکجا تحلیل، آماده و تخمین بزنه؛ درحالی‌که میزان ابهام همه‌ی تسک‌ها یکسان نیست و بخش زیادی از جزئیات تازه زمان شروع پیاده‌سازی مشخص میشن. هرچقدر تعداد آیتم‌هایی که باید از قبل بررسی بشن بیشتر باشه، عدم قطعیت اون‌ها هم روی هم جمع میشه و برنامه‌ی نهایی شکننده‌تر میشه.وقتی پروداکت اونر و تک‌لید باید تا یک روز مشخص تعداد زیادی تسک رو برای اسپرینت ۲ هفته‌ای آماده کنن، مدام بین مسئله‌های مختلف جابه‌جا میشن و فرصت تمرکز عمیق روی کارهای مهم‌تر رو از دست میدن. در نتیجه، به‌جای اینکه زمان کافی برای تحلیل مسئله، تحقیق و طراحی راه‌حل‌های ارزشمند صرف بشه، تمرکز میره روی آماده کردن تعداد کافی تسک برای پر کردن ظرفیت دو هفته‌ی آینده. توی این شرایط، کارهای کوچیک و ساده معمولا سریع‌تر آماده میشن، اما تسک‌های بزرگ، حساس و ارزشمند یا سطحی بررسی میشن یا مدام به اسپرینت بعد منتقل میشن.به‌مرور هدف Refinement هم از "ایجاد درک کافی برای شروع کار" به "تکمیل برنامه‌ی اسپرینت" تغییر می‌کنه. تیم تحت فشار قرار می‌گیره که برای همه‌ی آیتم‌ها به نتیجه برسه، ابهام‌ها رو موقتا ببنده و یک تخمین قابل‌ارائه تولید کنه؛ حتی وقتی هنوز اطلاعات کافی برای تصمیم‌گیری دقیق وجود نداره.در نهایت، خروجی جلسه ممکنه روی کاغذ یک برنامه‌ی کامل و دقیق به نظر برسه، اما با شروع پیاده‌سازی، پیچیدگی‌های پنهان، وابستگی‌ها و محدودیت‌های فنی خودشون رو نشون میدن و همون برنامه خیلی زود نیاز به اصلاح پیدا می‌کنه. یعنی تیم زمان زیادی صرف ساختن تصویری از آینده می‌کنه که از همون ابتدا هم قطعیت چندانی نداشته.مشکل دیگه اینه که توی این مدل، اگر یک تسک تا جلسه‌ی Refinement یا Planning آماده نشه، ممکنه حداقل دو هفته عقب بیوفته؛ حتی اگه اولویت بالایی داشته باشه یا نیاز فوری شرکت باشه. این تاخیر نه به‌خاطر پیچیدگی واقعی کار، بلکه صرفا به‌خاطر از دست رفتن یک پنجره‌ی زمانی اسپرینت ایجاد شده.تو چنین شرایطی، تیم به‌جای اینکه فرایند رو با نیاز واقعی کار هماهنگ کنه، مجبور میشه کیفیت تحلیل و تصمیم‌گیری رو فدای تقویم اسکرام کنه!وابستگی شدید به Tech Lead و Product Ownerحتما براتون پیش اومده که توی روز برگزاری جلسات Refinement یا Planning، تک‌لید یا پروداکت اونر حضور نداشته باشن. اتفاقی که میوفته اینه که اعضای تیم توانایی تصمیم‌گیری ندارن و برنامه‌ی دو هفته‌ی آینده‌ی تیم تحت تاثیر قرار می‌گیره. در نتیجه، تیم نمیتونه به‌شکل بهینه پلن بشه و بخش زیادی از تصمیم‌ها تا زمان حضور تک‌لید یا پروداکت اونر عقب میوفته.از طرف دیگه، هر اقدامی برای تغییر تسک‌ها یا اولویت‌ها در طول اسپرینت هم ممکنه ممنوع اعلام بشه، چون با برنامه‌ای که اول اسپرینت بسته شده یا برداشت‌ای که از قوانین اسکرام وجود داره همخوانی نداره.پیامد بلندمدت این الگو، ضعیف شدن حس مالکیت یا Ownership و مسئولیت‌پذیری بین اعضای تیمه. وقتی تعریف نیازمندی‌ها، شکستن تسک‌ها و تصمیم‌گیری‌های فنی فقط توسط یک یا دو نفر انجام میشه، بقیه‌ی اعضای تیم به‌مرور نقش منفعل‌تری پیدا می‌کنن و انگیزه‌شون برای مشارکت فعال در حل مسئله کمتر میشه.در چنین شرایطی، اعضای تیم دیگه خودشون رو مالک نتیجه‌ی کار نمی‌دونن، چون مسیر کار، تسک‌ها و حتی راه‌حل‌ها از قبل توسط افراد دیگه مشخص شدن. در نتیجه، تیم به‌جای اینکه یک واحد Self-organizing و پاسخگو باشه، تبدیل میشه به گروهی از مجری‌ها که برای پیش بردن کوچک‌ترین کارها هم منتظر دستور یا تایید می‌مونن.این وضعیت فقط سرعت تصمیم‌گیری رو پایین نمیاره؛ بلکه چابکی، نوآوری و توانایی تیم برای واکنش به تغییرات رو هم به‌شدت کاهش میده. تیمی که بدون حضور یک یا دو نفر نمیتونه تصمیم بگیره، عملا یک تیم مستقل و چابک نیست.جلسه‌ Daily؛ بازجویی محترمانه؟!برای جلسه‌ی Daily تعریف‌ها، هدف‌ها و آنتی‌پترن‌های زیادی توی اسکرام تعریف شده، اما توی خیلی از تیم‌ها در نهایت این جلسه تبدیل میشه به گرفتن آپدیت روزانه از تک‌ تک اعضا.هرکس باید توضیح بده دیروز چه کاری انجام داده، امروز قراره روی چه چیزی کار کنه و آیا بلاکری داره یا نه. تک‌لید و پروداکت اونر هم در جریان وضعیت کارها قرار می‌گیرن و مسئول پیگیری مشکلات و بلاکرها میشن.در چنین شرایطی، Daily به‌جای اینکه به هماهنگی تیم و ایجاد درک مشترک کمک کنه، کم‌کم به یک جلسه‌ی گزارش‌دهی تبدیل میشه؛ گزارشی که اعضای تیم به تک‌لید یا مدیر خودشون ارائه میدن.مشکل فقط گزارش‌دهی نیست. وقتی حل کردن بلاکرها به جلسه‌ی Daily و حضور تک‌لید موکول میشه، یک پیام اشتباه به تیم منتقل میشه:"مسئولیت حل این مشکل با من نیست؛ باید تا فردا صبح صبر کنم تا تک‌لید پیگیریش کنه."در نتیجه، به‌جای اینکه اعضای تیم به محض روبه‌رو شدن با یک مشکل برای حل کردنش اقدام کنن، با افراد مرتبط صحبت کنن یا موضوع رو همون لحظه مطرح کنن، ممکنه تا Daily بعدی صبر کنن و مسئولیت حل مسئله رو به تک‌لید منتقل کنن.درحالی‌که یک تیم چابک نباید برای حل یک مشکل تا جلسه‌ی بعدی منتظر بمونه. ارتباط، هماهنگی و رفع بلاکر باید به‌شکل پیوسته و هر زمان که نیاز بود اتفاق بیوفته، نه فقط توی یک بازه‌ی پانزده‌ دقیقه‌ای از قبل تعیین‌ شده.جلسه Retrospective همین مسئله در مورد جلسات Retrospective هم وجود داره.اگه همین امروز یک مشکل جدی توی فرایند کار تیم وجود داره، چرا باید تا پایان اسپرینت صبر کنیم تا درباره‌ش صحبت کنیم؟ اگه یک تصمیم اشتباه گرفته شده یا یک فرایند داره به تیم آسیب می‌زنه، عقب انداختن بررسی اون تا جلسه‌ی Retro فقط باعث میشه مشکل برای مدت بیشتری ادامه پیدا کنه.از طرف دیگه، جمع کردن همه‌ی مشکلات، اتفاق‌ها و تصمیم‌های دو هفته‌ی گذشته توی یک جلسه، لزوما باعث بررسی عمیق و موثر اون‌ها نمیشه. معمولا زمان جلسه محدوده، موضوع‌ها زیادن و بعضی مسائل فقط مطرح میشن، بدون اینکه فرصت کافی برای پیدا کردن علت اصلی یا پیگیری راه‌حل وجود داشته باشه.مشکل خود این جلسات نیست. مشکل از جایی شروع میشه که تیم فکر می‌کنه هماهنگی فقط توی Daily، گرفتن بازخورد فقط توی Review و صحبت درباره‌ی مشکلات فقط توی Retro باید انجام بشه.بک‌لاگ، قبرستون تسک‌‌ ها!بک‌لاگ قرار نیست انبار تمام ایده‌ها، درخواست‌ها و تسک‌هایی باشه که از شروع محصول تا امروز مطرح شدن. بک‌لاگ باید یک لیست زنده از مهم‌ترین کارهای پیش‌روی تیم باشه؛ لیستی که با تغییر نیاز کاربر، شرایط بازار و چیزهایی که تیم در طول مسیر یاد می‌گیره، مدام تغییر کنه.اما توی خیلی از تیم‌ها، بک‌لاگ به‌مرور با صدها آیتم پر میشه. آیتم‌هایی که کسی مطمئن نیست هنوز ارزش دارن، اما چون یک روزی ثبت شدن، کسی هم جرئت حذف کردنشون رو نداره. در نتیجه، بک‌لاگ به‌جای اینکه مشخص کنه «کار مهم بعدی چیه»، تبدیل میشه به قبرستون ایده‌هایی که شاید هیچ‌وقت انجام نشن.آیتم‌های بالای بک‌لاگ معمولا شفاف‌ترن، اما هرچقدر پایین‌تر می‌ریم، اطلاعات کمتر و فرضیات بیشتر میشن. تا وقتی نوبت این کارها برسه، ممکنه نیاز کسب‌وکار، تکنولوژی یا حتی مسیر محصول کاملا تغییر کرده باشه.بااین‌حال، تیم‌ها ساعت‌ها برای نوشتن جزئیات، شکستن و تخمین زدن همین آیتم‌های دور وقت میذارن؛ کاری که بیشتر از ایجاد ارزش، فقط یک حس کاذب از قطعیت می‌سازه.مشکل خود بک‌لاگ نیست؛ مشکل جاییه که نگهداری و مرتب کردن بک‌لاگ از ساختن محصول مهم‌تر میشه. بهتره فقط کارهای نزدیک و ارزشمند با جزئیات کافی آماده بشن و بقیه‌ی ایده‌ها تا وقتی واقعا مهم نشدن، در حد یک یادداشت ساده باقی بمونن یا حتی حذف بشن. اگه یک ایده واقعا مهم باشه، دوباره برمی‌گرده.بک‌لاگ خوب، بک‌لاگی نیست که همه‌چیز توش وجود داشته باشه؛ بک‌لاگیه که تیم با نگاه کردن بهش، سریع بفهمه ارزشمندترین کار بعدی چیه.وقتی ماهیت کار تیم با اسپرینت همخوانی ندارههمه‌ی تیم‌ها روی یک محصول مشخص با مجموعه‌ای از قابلیت‌های قابل‌پیش‌بینی کار نمی‌کنن. بعضی تیم‌ها ماهیتی دارن که کارشون به‌صورت پیوسته، وابسته به نیاز دیگران یا همراه با عدم‌قطعیت زیاد شکل می‌گیره؛ در چنین شرایطی، برنامه‌ریزی ثابت برای دو هفته‌ی آینده همیشه تصویر واقعی از کار تیم ارائه نمیده.مثلا تیم‌های Platform و زیرساخت معمولا به چندتا تیم دیگه سرویس میدن. اولویت کارشون براساس نیاز تیم‌های سیروس گیرنده (نمیدونم واژه درستیه!)، محدودیت‌های فنی و وضعیت کلی سازمان تغییر می‌کنه. بنابراین ارزش کار این تیم‌ها بیشتر در کاهش وابستگی‌ها، ساده‌تر کردن توسعه و بالا بردن توان کل سازمان دیده میشه، نه لزوما در تکمیل یک فهرست ثابت از تسک‌ها در هر اسپرینت.تیم‌هایی که ممکنه بخش زیادی از زمانشون رو صرف کشف مسئله، آزمایش راه‌حل‌ها و بررسی امکان‌پذیری می‌کنن. نتیجه‌ی این کارها از قبل مشخص نیست؛ ممکنه یک آزمایش بعد از چند روز نشون بده مسیر انتخاب‌شده اشتباه بوده و ادامه دادن اون ارزشی نداره. توی چنین تیم‌هایی، یادگیری و کنار گذاشتن یک راه‌حل نامناسب خودش یک خروجی ارزشمنده، اما به‌سختی میشه اون رو از قبل به مجموعه‌ای از تسک‌های دقیق و متعهد شده تبدیل کرد.مشکل این تیم‌ها ضعف در تخمین یا برنامه‌ریزی نیست؛ مدل جریان کارشون با تعهد به یک Scope ثابت دوهفته‌ای همخوانی نداره. برای چنین تیم‌هایی، مدیریت کار بر اساس جریان، محدود کردن کارهای در حال انجام، مشخص کردن سیاست‌های اولویت‌بندی و انتخاب کار بعدی براساس نیاز واقعی سازمان می‌تونه مناسب‌تر از برنامه‌ریزی کامل اسپرینت باشه.اسکرام؛ نسخه‌ی شفابخش برای همهدر نهایت، مسئله این نیست که اسکرام خوبه یا بد، درست اجرا میشه یا نه؛ مسئله اینه که اسکرام فقط یکی از روش‌های سازمان‌دهی کاره و به‌تنهایی یک تیم یا سازمان رو چابک نمی‌کنه. انتخاب اسکرام به‌عنوان گزینه‌ی پیش‌فرض برای همه‌ی تیم‌ها، بدون توجه به تفاوت‌های ماهیتی‌شون، رویکردیه که باید عوض بشه.وقتی یه چارچوب نامناسب به زور به تیم تحمیل می‌شه، درنهایت انگشت اتهام به سمت خود تیم گرفته میشه و به ضعف در برنامه‌ریزی و تعهد تیم نسبت داده میشه : "تیم درست پلن نکرده"، "به تعهدش عمل نکرده" یا "Velocity پایینی داره".  در حالی که خیلی وقت‌ها مشکل اصلا از آدم‌ها نیست؛ مشکل از فرایندیه که ذره‌ای با واقعیت و جنس کار اون‌ها همخوانی نداره.چابکی واقعی فقط توی جلسات و سِرمونی‌ها شکل نمی‌گیره و همینطور که در بالا اشاره شد: زیرساخت تست، دیپلوی ساده و امن، Observability مناسب، معماری قابل‌تغییر، کنترل بدهی‌های فنی، کاهش وابستگی به تیم‌های دیگه و امکان تصمیم‌گیری سریع و داشتن اختیار، همگی به همون اندازه توی چابکی نقش دارن.باید روراست باشیم: معیار موفقیت این نیست که تیم چقدر "اسکرامی" و بی‌نقص قوانین رو اجرا می‌کنه. معیار واقعی اینه: از لحظه‌ای که یه نیاز یا مشکل شناسایی میشه، چقدر طول می‌کشه تا یه تغییر ارزشمند، باکیفیت و کم‌ریسک به دست کاربر نهایی برسه؟فرایند و متدولوژی باید مثل یک ابزار کمکی، مسیر رو برای تیم هموار کنه؛ نه اینکه تیم مجبور باشه خودش رو به زور توی قالب‌های از پیش تعیین‌شده‌ی یه فریم‌ورک خشک جا بده؛ فرایند باید در خدمت تیم باشه، نه تیم در خدمت فرایند.Ryan KheradmandRyan KheradmandWed, 05 Aug 2026 23:50:39 +0330https://virgool.ir/@iamkheradmand/کارمند-یا-برده-خلاهای-قانون-کار-wucvcrfydbkkآقای نورمن ال. ماخت توی کتاب تاریخ برده‌‌ داری توضیح میده که بسیاری از مورخین معتقد هستن تمدن‌های اولیه‌ای‌‌ مثل مصر، یونان و روم بدون استفاده گسترده از نیروی کار برده‌‌ها به وجود نمی‌ اومدن! جناب ارسطو در تایید برده‌داری یونانی‌ها حتی بحث رو در فلسفه خودش فراتر میبره : مردی که قابلیت تعلق یافتن به دیگری را دارد، ذاتا برده است...برده ‌داری در طی تاریخ چیز بدی محسوب نمی‌شد؛ نیروی کار ارزون قیمت و کم هزینه، عدم دسترسی به حقوق مدنی یا سیاسی و از همه مهمتر فرمانبرداری و اطاعت‌ پذیری. حتی با ظهور ادیان مسیحیت و اسلام، برده ‌داری هیچوقت ممنوع نشد و فقط ساختارمندتر ادامه پیدا کرد چرا که اقتصاد و جامعه به شدت به نیروی کار برده وابسته بود. ممکنه فکر کنید برده‌ داری قرن‌هاست که تموم شده، اما آمار چیز دیگه‌ای رو میگه! طبق گزارش سازمان ملل متحد امروزه تقریبا ۵۰ ميليون نفر در سراسر جهان در دام برده‌داری گرفتار هستن، برده ‌داری مدرن.احتمالا اولین چیزی که با دیدن کلمه "برده" به ذهنتون خطور می‌کنه تصویر یک انسان در بند غل و زنجیر که با بی‌رحمی و ضربات شلاق زیر گرمای آفتاب مجبور به کاره؛ تصویری که خیلی متفاوت‌تر از محیط کار فعلی‌تون به‌نظر میرسه اما… بیشتر بهش فکر کنیم، شاید بشه گفت که :‌ صورت دگر است، سیرت همان."برده فردی است که قانون و عرف او را نه به عنوان انسان، بلکه به‌مثابه مال یا کالایی تلقی می‌کنند؛ بدون حقی برای خود، موظف به تسلیم تمامی ثمره کارش به ارباب و کاملاً در خدمت اهداف اوست و تنها در حد یک حیوان کارگر تحت حمایت یا مجازاتِ دلخواه ارباب قرار می‌گیرد."کارمند طبق قانون به این شکل تعریف میشه که : زمانی که یک شخص نه برای دولت بلکه برای شخص خصوصی دیگر (حقیقی یا حقوقی) کار می‌‌کند، تحت شمول قانون کار قرار می‌گیرد. طبق ماده ۲ قانون کار، کارمندهای شرکت خصوصی در تعریف کارگر قرار می‌گیرند و کارگر از لحاظ این قانون کسی‌ست که : "به هر عنوان در مقابل دریافت حق‌السعی اعم از مزد، حقوق، سهم سود و سایر مزایا به درخواست‌ کارفرما کار می‌کند."قانون کار جمهوری اسلامی ایران با هدف تنظیم روابط کاری بین کارگر و کارفرما، حمایت از حقوق کارگر و جلوگیری از بهره‌کشی در سال ۱۳۶۹ تصویب شد که از جمله مهم‌ترین مفادهای اون میشه به تنظیم ساعات کار، حداقل دستمزد، شرایط احراز بازنشستگی، نحوه پرداخت حق‌بیمه، مقررات اخراج و بازگشت به کار اشاره کرد. این قانون در واقع قرار بود یک چارچوب منصفانه بین دو طرف بسازه طوری که منافع هر دو طرف حفظ بشه تا هر دو بدونن چه وظایفی دارن و چه حقوقی.تا اینجا متوجه شدیم ما به ازای کاری که انجام دادیم، دست مزد دریافت می‌کنیم و شامل حق و حقوقی شدیم اما ظاهرا همچنان در خدمت کامل کارفرما یا ارباب باقی موندیم؛ اما این چطور ممکنه؟!قانون کار در قبال اختیاراتی که به کارفرما اعطا می کنه، وظایفی رو هم طلب می کنه. طی سال های اخیر بارها شاهد بهره‌کشی از کارمندها به واسطه قراردادهای سفت و سخت و اختیارات قانونی با کمترین تعهدات و انجام وظیفه از طرف کارفرما بودم که به دلایل پیچیدگی‌های قانونی، هزینه های مالی و زمانی و… هیچکدوم پیگیری نشدن و همچنان ادامه دارن؛ درواقع کارفرمای عزیز از قانون، گل عطرش را می‌خواهد، نه تیغِ عدلش را.اختیاراتی که قانون به کارفرما سپرد، در عمل به ابزاری برای سرکوب حقوق و طنابی برای بستن دست کارگر تبدیل شد؛ برای مثال، قراردادهای کوتاه‌ مدت یا یک‌ ماهه معمولا به اهرمی برای فشار، تهدید و کنترل رفتار کارگرها بدل می‌‌شن تا همیشه در وضعیت ناامن و وابسته بمونن بدون اینکه مشکلی متوجه کارفرما بشه. در همین حال، قانون نه‌تنها هیچ حمایتی در برابر این فشارها ایجاد نکرد، بلکه هیچ اشاره‌ای هم (حتی غیرمستقیم) به سلامت روان، استرس شغلی، آزار روانی، فرسودگی شغلی یا فشارهای روانی سیستماتیک نکرده و این خلا قانونی، راه رو برای بهره‌کشی پنهان و خاموش باز گذاشت. یا مثال دیگه اینکه در بیشتر مواقع تعدیل نیروی انسانی اولین گزینه در مواجهه با زیان و ضرر ناشی از سومدیریت یا شرایط اقتصادیه؛ اون هم تحت عنوان "حفظ بقای شرکت"! نه اصلاح مدیریت، نه تغییر مسیر فقط حذف نیروها. اصولا قانون زمانی تاثیر گذاره که به درستی اجرا بشه و سنجش میزان و درستی اجرا با نظارت به دست میاد، بنده هیچ‌وقت شاهد بازرسی یا نظارت بر شرکت‌های خصوصی نبودم.متاسفانه به واسطه شرایط بد اقتصادی کشور و تحریم‌ها، تربیت همراه با سرکوب، نبود آموزش و یا سوتفاهمی از فلسفه رواقی‌گری (استوئیسم) بسیاری از کارمند های عزیز برای ندیدن و نشنیدن یک سر در زیر برف دارن و یک سر خم کرده در برابر کارفرما برای اطاعت؛ که البته ایرادی زیادی نمیشه گرفت، در شرایط فعلی همه چی روی غلتک کارفرماست و با شروع موج تعدیل‌ها از سال گذشته و جنگ در کشور با پدیده‌ای رو به رو شدیم که کارمندها حتی برای انتخاب بردگی داوطلبانه هم دچار چالش و سختی هستن! زمانی که آلودگی هوا، گرما یا سرما، کاهش ساعات کاری، حق اضافه کار، پاداش و... فقط متوجه کارمندان دولتی هست و نه کارگران، چاره ای بجز راضی بودن به همین خورده قانون نیست.تورم و مشکلات اقتصادی اگرچه گلوی کارگر و کارفرما رو باهم فشار میده اما ظاهرا این فشار یکسان نیست! این روزها جذب نیروی متخصص با حقوق پایین‌تر از عرف بازار دیگه اسمش "سوء‌استفاده" نیست، بلکه روال معمول شده. افزایش تقاضا برای شغل به هر قیمتی، جابه‌جایی و جایگزینی نیروها رو به ساده‌ترین کار دنیا و نیروی کار رو به ارزان‌ترین دارایی کارفرما تبدیل کرده.در واقع دریافت مزد و امکان ترک شغل تنها حق قانونی باقی مونده برای یک کارگر ایرانی هستن!محیط کاری حمایتی!وقتی به سازه‌های عظیم تاریخی مصری‌ها، یونانی‌ها یا هخامنشیان نگاه می‌کنیم، کمتر ممکنه از خودمون بپرسیم چطور ممکنه برده‌ها چنین اثر شگفت انگیزی رو خلق کرده باشن؟موضوع که وقتی مطالعه می‌کنید متوجه می‌شید : مهندسين، معماران و اساتید سازه‌ها، برده معمولی نبودن! اساتید سنگ تراش مصری تا مهندسين یونانی در ازای کار دستمزد دریافت می‌کردن و دارای جایگاه بالاتری بودن‌. پادشاهان از ۳ هزار سال پیش نکته ظریفی رو فهمیده بودن : شکوه و ظرافت با دست‌های به‌ زنجیر کشیده زیر ترس و اجبار خلق نمیشه.در مسیر تکامل، نه تنها هوش انسان بلکه احساسات و عواطف انسانی هم دوشادوش عقل رشد کردن. مغز انسان طوری تکامل پیدا کرد که تصمیم، خلاقیت و عملکردش بدون دخالت احساسات عملاً ناقص بود.با این حال، ما هنوز کار رو فقط به دو برچسب کار "کارمندی یا ذهنی" و کار "کارگری یا جسمی"  محدود می‌کنیم، در حالی که هیچ کاری جدا از عاطفه و احساس انسانی انجام نمی‌شه. بُعدی که قانون کار نه تنها برای رشدش کاری نکرد، بلکه حتی برای جلوگیری از آسیبش هم قدمی برنداشت. شما نمی‌تونید یه متخصص خلاق و دقیق باشید بدون اینکه احساس امنیت، احترام و ارزش کنید؛ حقیقتی که اربابان از فهمش عاجزند، عجزی که در طی زمان به پاشنه آشیل برای شرکت‌ها تبدیل شد. کیفیت طراحی و پشتیبانی اپلیکیشن‌های ایرانی توی مارکت‌، به‌خوبی گویای این وضعیت هست.بیماری‌های روانی و وضعیت سلامت روان فقط مختص به فرد نیست و آسیب‌های ناشی از اون کل سیستم رو در برمیگیره؛ استرس مزمن، تحقیر، عدم امنیت شغلی، کار بی‌پایان و نبود فضای روانی امن، نه‌تنها باعث افسردگی، اضطراب و فرسودگی شغلی می‌شن، بلکه مستقیما :بهره‌وری رو کم می‌کننغلط‌های کاری رو زیاد می‌کننغیبت و استعفا رو بالا می‌برنو فرهنگ سازمانی رو سمی می‌کننطبق گزارش سازمان جهانی بهداشت (WHO) ، افسردگی و اختلالات اضطرابی سالانه یک تریلیون دلار هزینه از دست رفته به اقتصاد جهانی تحمیل می‌کنن که بیشترش هم از کاهش بهره‌وری در محیط کاره! در نتیجه، پرداختن به سلامت روان در محل کار نه تنها یه موضوع دلسوزانه‌ست، بلکه منطق تجاری خوبی هم داره.در پایان باید بگم که برده‌‌ها انسان‌ هایی با احساس، هوش، خانواده و آرمان بودن که به‌ طور ناعادلانه آزادی و حقوقشون سلب شده بود؛ اون ها فقط "وظیفه" داشتن و نه "حق". اربابانشون اهمیت نمی‌ دادن که برده‌ها ظرف یک یا دو سال از فرط کار شدید جان‌ بدن؛ جایگزین کردن اون‌ها ساده بود…Ryan KheradmandRyan KheradmandTue, 21 Oct 2025 15:39:38 +0330