🧮 به نهضت NoEstimates# بپیوندیم؟ هنوز Story Point برای تخمین اندازه تسک‌ها لازمه؟

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

مرگِ یک آیین قدیمی یا تکامل طبیعی؟

سوال تکراری همیشگی بعد از اینکه یک تیم یا شرکت تخمین Story Point رو کنار می‌گذاره؛ اینه: «خب جایگزینش چیه؟»
ولی عملا سوال بهتر اینه که اصلاً نیاز واقعی‌مون به Story Point چی بوده؟ و چرا به وجود اومده؟
این بحث، بحثِ خیلی از تیم‌های نوپا و بالغ دنیا طی سال‌های اخیر بوده.
عملا Story Point در سال‌های ابتدایی پیدایش مفهوم agile در توسعه نرم‌افزار، ناجی خیلی از تیم‌ها بود. یعنی وقتی تیم‌ها از تخمین زمانی (مثل person-hour یا person-day) خسته شده بودن و می‌دیدن این اعداد عموما دروغ می‌گن؛ Story Point با نگاه «بی‌خیال ساعت شید، فقط بگید این کار نسبت به اون یکی چقدر بزرگ‌تره» به وجود اومد. و واقعاً هم کمک کرد. تیم‌ها بهتر پیش‌بینی می‌کردن، Velocity داشتن، ظرفیت اسپرینت مشخص بود.

اما این سال‌ها بعضی از تیم‌ها Story Point رو کنار گذاشتن، مهم‌ترین دلایلی که من دیدم، اینا بوده:

۱. طی گذر زمان؛ Story Point تبدیل به دروغ شد!
همون چیزی که قرار بود جلوی دروغ رو بگیره، خودش تبدیل به دروغ شد.
چرا؟ چون مدیر محصول یا PO می‌گفت: «این فیچر باید تو همین اسپرینت جا بشه، پس ۸ نزنید، ۵ بزنید!»
یا توسعه‌دهنده از ترس فشار بعدی، همیشه عدد بزرگ‌تر می‌زد.
نتیجه؟ Velocity غیرواقعی، تخمین غیرواقعی، بی‌اعتمادی کامل. من از حدودای ۲۰۱۲-۲۰۱۳ یادم میاد که نهضت NoEstimates# با این گفتمان راه افتاده که تخمین، هزینه داره و اغلب دقتش اون‌قدری نیست که ارزش هزینه‌ش رو داشته باشه!

۲. تیم‌ها دیگه نیازی به «واحد خیالی» ندارن
وقتی تیم کوچیکه، در اثر تجربه و هم‌نشینی گاهی دیگه نیازی نمی‌بینن بگن «این ۵ پوینته، اون ۸ پوینته».
فقط می‌گن: «این کار حدود ۲-۳ روزه، اون یکی یه هفته».
و این تخمین «تقریبی و رنج‌دار» گاهی دقیق‌تر از Story Point در میاد!
از طرفی، تیم‌های خوب به جای اندازه تسک، روی شکل دادن (Shaping) فیچرها تمرکز می‌کنند و تخمین ریز نمی‌زنن.

۳. کار رو باید انجام داد چه یه روز چه ده روز!
بعضی تیم‌ها ماهیت تسک‌هاشون «ضرورتِ محصوله»، یعنی قابل حذف یا جایگزینی نیست، محصول هم باید تولید شه. لذا برای مدیر و شرکت مهمه که زودتر برسه، ولی اگر چند وقت دیرتر هم بشه، راهی جز پذیرش نداره. اینجاست که تیم می‌گه خب so what؟ تخمین بزنم که چی بشه؟ من که اول و آخر باید این کار رو انجام بدم!

۴. کارهای روتین، یا قابل پیش‌بینی هستن
وقتی کارها به طور نسبی زمان مشابهی برای اجرا نیاز دارن، یا توی چند دسته‌ی قابل پیش‌بینی قرار می‌گیرن، تکرار مکررات باعث می‌شه تیم بیخیال تخمین بشه و می‌دونه چه کاری حدودا طی چی زمانی انجام می‌شه. اینجا دیگه به جای story point گاها T-Shirt sizing هم جواب می‌ده (S, M, L, XL)

پس کِی و کجا Story Point هنوز مفیده؟

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

- تیم‌های جدید که هنوز Flow پایداری ندارن

- وقتی تیم‌ها توزیع‌شده (distributed) هستن و ارتباط لحظه‌ای کمه

یادمون نره که Agile یعنی انعطاف. اگر ابزاری به درد تیم شما نمی‌خورد، کنارش بگذارید. اینکه process templateهای متنوعی وجود داره، از مدل‌های ساده مثل kanban تا scrum و agile و حتی مدل‌های خیلی سخت‌گیر و دقیقی مثل CMMI هم هست، یعنی «نسخه واحد برای همه تیم‌ها و محصولات وجود نداره».

سوال این نیست که "Story Point خوبه یا بد؟"
سوال اینه: "برای تیم ما، در مرحله فعلی، چه چیزی بهترین کمک رو می‌کنه؟"

بعضی‌ها هم که story point رو گذاشتن کنار از سر بلد نبودنشون بوده! نه از سر مناسب نبودنش! و اساسا باید عارضه رو در خودشون پیدا می‌کردن یا اینکه تا زمان بلوغ، می‌رفتن سراغ متد دیگه‌ای که مبتنی بر SP نباشه، نه اینکه متد رو نگه دارن و SP رو از دلش بکشن بیرون.

این موضوع خیلی مفصله ولی امیدوارم در حد سرنخ دادن کمک کرده باشه... 😊

⌛ اصول نرم‌افزارهای انترپرایز یا Enterprise Software Principles
1️⃣ بخش یک: ساختار و سازمان‌دهی تولید (ابزار، فرایند، فرهنگ)

- ساختار و سازمان‌دهی تولید چیه؟

ساختار و سازماندهی تولید نرم‌افزار رو من ذیل ۳ مولفه اصلی بیان می‌کنم. یعنی فرهنگ، فرایند، و ابزار:

۱: ابزار:
ابزار را شاید بشه ساده‌ترین مولفه از بین ۳ عامل دونست (هرچند خیلی‌ها همین رو هم به درستی ندارن). ابزار یعنی هر سرویس سخت‌افزاری و نرم‌افزاری که به شما کمک می‌کنه تا چرخه عمر نرم‌افزار رو بهتر مدیریت و تجربه کنید. مثلا:

پلتفرم مناسب برای مستندسازی که جستجوی خوب، نسخه‌بندی، امکانات امنیتی، کامپلاینس، پشتیبانی از نمودار (به‌صورت کد، نه صرفاً تصویر)، و کوئری پویا از سورس‌کد یا سیستم مدیریت پروژه رو فراهم کنه.

یا سرور/سرویس Version Control و CI/CD درست و حسابی (منظورم TFS 2012 اونم به صورت شلخته نیست)

یا ابزارهای مدرن نظارت (منظورم observability است نه monitoring)

یا سرویس Secret Manager (منظورم KeePass نیست طبیعتا)

یا...

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

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

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

فرق سازمان با جامعه اینه که شما در جامعه وقت، زیاد داری! بین رنسانس تا انقلاب صنعتی چند قرن زمان برد، ولی یک سازمان چند قرن یا چند سال زمان نداره! حساب دو دو تا چهار تا است؛ دیر بجنبی زیان‌ده و ورشکسته می‌شی. حتی اگر دولتی باشی، به خودت میای و می‌بینی ۲,۲۴۵,۶۲۳ نفر کارمند داری که راهی جز تعدیل و جایگزینی درصد بسیار بالایی از اونها نداری... و دلیل اصلیش: «فرهنگ نیروی انسانی» است

همون‌طور که در ادبیات Enterprise Architecture اومده "Culture Ensures Sustainability" فرهنگ، پایداری رو تضمین می‌کنه. حالا فرهنگ مهندسی در اینجا به معنی ترکیب سه عامل است:

۱. شایستگی فنی (Technical Competence):
تسلط بر معماری، الگوهای طراحی، و...

۲. تعهد به فرایند (Process Commitment):
پایبندی به code review، testing، و documentation

۳. مهارت در ابزار (Tool Proficiency):
استفاده مؤثر از CI/CD، و observability tools

بعضی گزارش‌های McKinsey می‌گن حدود ۷۰٪ پروژه‌های تحول دیجیتال، به دلایل فرهنگی و سازمانی شکست می‌خورن. تجربه شخصی من در ایران این عدد رو حتی بالاتر، و حدود۹۰٪ نشون می‌ده.

تغییر فرهنگ، کندترین و حیاتی‌ترین بخش transformation است و نیازمند ۳-۵ سال زمان، تعهد مدیریت ارشد، و گاهی جایگزینی تدریجی ۲۰-۴۰٪ نیروی انسانی است.

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

چکیده:

- Tools Provide Acceleration, Not Discipline
- Processes Create Predictability
- Culture Ensures Sustainability

اگر از این مطلب استقبال بشه، در ادامه، موضوعات زیر رو هر کدوم ذیل ۳ مولفه‌ای که در این مقدمه عرض کردم در یک نرم‌افزار انترپرایز بررسی می‌کنم:

بخش دوم: الزامات توسعه و نگهداری محصول
بخش سوم: الزامات زیرساخت
بخش چهارم: الزامات امنیت
بخش پنجم: الزامات طراحی و نگهداشت محصول

💬 فیدبک شما حتمن در جهت‌دهی ادامه مطالب کمک می‌کنه 😊

💡🌱 چرا بیشتر برنامه‌های توسعه شکست می‌خورند؟ مشکل موقعیت‌یابی اشتباه!

وقتی آقای الف، (یک دولوپر از نظر مهارت فنی، جونیور، ولی با ۱۲ سال تجربه) برنامه یادگیری سال جدیدش رو برای من فرستاد تا نظرم رو بگم؛ لیستش از الگوهای طراحی مایکروسرویس تا هوش‌مصنوعی تا... رو در برداشت. ازش پرسیدم: «آخرین باری که یک Pull Request یا Merge Request دادی که به بخش محدودی از نرم‌افزار بهینگی کارایی یا ساختاری اضافه کرده باشه (و نه فقط خواسته‌ی تسک) و کامنت‌های بیسیک هم از دید دولوپرهای ارشد نگرفته باشه کِی بوده؟ پاسخ صریح و مطمئنی نداشت! این دقیقاً جاییه که اکثر برنامه‌های توسعه، چه فردی، تیمی یا سازمانی، شکست می‌خورن: ما به جای شناخت دقیق موقعیت فعلی، مستقیم سراغ مقصد می‌ریم. مشکل: ما نمی‌دانیم واقعاً کجا ایستاده‌ایم.

تصور کنید می‌خواهید از تهران به اصفهان بروید، اما GPS موقعیت فعلی‌تون را اشتباه تبریز نشون می‌ده. هر مسیری که انتخاب کنید، اشتباهه، نه به خاطر مقصد، بلکه به خاطر نقطه شروع. سه سناریوی واقعی از موقعیت‌یابی اشتباه:

1️⃣ سناریو ۱: دولوپر جونیور، آقای الف
موقعیت واقعی: کدهاش هنوز فراتر از خواسته‌ها نیست، متدهاش بنا به دانش کم، و نه ضرورت و اقتضای شرایط، بیش از ۸۰ خط می‌شن، استفاده بجا از الگوهای طراحی رو نمی‌دونه.

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

نتیجه: سه ماه وقت صرف یادگیری DDD می‌کنه، اما کدهایش همون if/else تودرتوی قبلی با اسامی fancy است. API چت‌جی‌پی‌تی صدا می‌زنه، توهم دانش GenAI داره.

هزینه: ۳۶۰ ساعت وقت + frustration + از دست دادن فرصت یادگیری Clean Code، کسب توهم بیشتر که مثل یک دیوار محکم جلو یادگیری صحیح و به‌جا رو ازش می‌گیره!

2️⃣ سناریو ۲: تیم توسعه (یک استارتاپ ۱۵ نفره)

موقعیت واقعی: Code coverage زیر ۳۰٪، هیچ integration test ندارن، deployment تقریبا دستی است، تیم آلوده به وایب‌کدینگ مخفی شده.

موقعیت ادراک‌شده: آماده رفتن به microservices، توانایی تحویل فیچر و توسعه سریع‌تر (وهم وایب‌کدینگ بدون سنجش میزان کد کثیف و ناکارآمد و ناهمگون)

نتیجه: شش ماه صرف split کردن monolith شد، اما debugging چندبرابر شد چون observability ندارند، روز به روز درک کدها سخت‌تر شده، هر اصلاح با وایب‌کدینگ موجب خطا و مشکل در جای دیگه می‌شه.

هزینه: ۶ ماه × ۱۵ نفر × میانگین حقوق = حداقل ۴.۵ میلیارد تومن + velocity کمتر شده

3️⃣ سناریو ۳: مدیر محصول تازه‌کار

موقعیت واقعی: هنوز نمی‌دونه چطوری یک user story خوب بنویسه یا backlog prioritize کنه

موقعیت ادراک‌شده: آماده طراحی استراتژی سه‌ساله محصول

نتیجه: یک سند ۴۰ صفحه‌ای strategy که هیچ‌وقت اجرا نمی‌شه، چون execution از پایه مشکل داره، مدیران فریفته‌ی محتوای غیرواقعی سند شدن

هزینه: اعتماد تیم + فرصت تمرکز روی مهارت‌های بنیادی

فریمورک سه‌مرحله‌ای برای موقعیت‌یابی صحیح

مرحله ۱: Assessment (ارزیابی بی‌رحمانه سطح فعلی) برای موقعیت‌یابی صحیح، باید از خود سؤالات سختی بپرسید که پاسخ‌شان قابل اندازه‌گیری باشه
و اگر نمی‌تونید موقعیت فعلی را با یک عدد یا fact مشخص کنید، هنوز موقعیت‌یابی نکرده‌اید.

مرحله ۲: Gap Analysis (محاسبه فاصله واقعی) حالا که موقعیت فعلی رو می‌دونید، باید بفهمید دقیقاً یک سطح بالاتر کجاست. نه دو سطح، نه سه سطح؛ فقط یک سطح. این مفهوم را Vygotsky، روان‌شناس روس، دهه ۱۹۳۰ ذیل Zone of Proximal Development (ZPD) تعریف کرده (اگر دوست داشتید بیشتر بخونید). و نشون می‌ده یادگیری فقط در یک باند باریک اتفاق می‌افته:

خیلی آسون » Comfort Zone (یادگیری صفر)
کمی چالش‌برانگیز » Learning Zone (یادگیری حداکثر) ← ZPD همینجاست
خیلی سخت » Panic Zone (یادگیری صفر)

مرحله ۳: Action Planning (طراحی گام اول قابل اجرا) بعد از شناخت موقعیت و تعیین گام بعدی، باید یک برنامه خیلی کوچیک طراحی کنید که در عمل اجرا شدنی باشه.

آمار: ۶۸٪ از مهاجرت‌ها به microservices در سازمان‌هایی که بلوغ کافی نداشتن، منجر به کاهش productivity شد (منبع: ThoughtWorks Technology Radar 2019)
یا ۷۵٪ از برنامه‌های یادگیری سال نو تا پایان فوریه رها می‌شن! (منبع: University of Scranton research) دلیل اصلی: اهداف خیلی بالاتر از سطح فعلی

خلاصه اینکه: فقط یک سؤال از خودتان بپرسید: «اگر بخوام امروز به کسی ثابت کنم دقیقا در چه سطحی هستم، چه عددی یا fact مشخصی می‌تونم نشون بدم؟ و این عدد با چه معیار و سنگ محکی سنجیده شده؟»

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