‫‫‫‫‫ گذری بر فریم‌ورک‌ها و متودولوژی‌ها با محمداسماعیل پدران

اپیزود قبل دیگه رفتیم تو دل تیم و فرایندهاش؛ ادامه‌ی راه با محمد اسماعیل پدران عزیز همراه شدم و با شخصیت‌های فریم‌ورک‌ها و متودولوژی‌های مختلف آشنا شدیم. از اسکرام (Scrum)، کانبان (Kanban) و Extreme Programming گرفته که عموماً برای تیم‌های کوچک استفاده میشه تا Nexus و SAFe که خوراک تیم‌های بزرگه!

طبیعیه که در یک اپیزود نمیشه به جزئیات تک تک این موارد پرداخت. اما یک سوال اصلی شالوده‌ی بحث ما رو شکل داد؛ از کجا بفهمیم کدوم فریم‌ورک یا متودولوژی مناسب تیم ماست؟ آیا واقعا اسکرام بهترین فریم‌ورکه؟

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

مقدمه اپیزود گذری بر فریم‌ورک‌ها و متودولوژی‌های اجایل

سلام به همگی. پدرام کشاورزی هستم و خوش اومدین به پنجمین قسمت از پادکست اجایل گپ.
تو این فصل، هدفمون اینه که واقعاً بریم سراغ تجربه‌های واقعی از دل صنعت. چیزهایی که آدم‌ها واقعاً باهاشون دست و پنجه نرم کردن. قصدمون اینه که از دل همین گپ‌ها، درس‌هایی دربیاریم که به رشد صنعت کمک کنه.
خب، با این مقدمه، بریم سراغ قسمت امروز که اسمش هست «گذری بر فریم‌ورک‌ها و متدولوژی‌ها».

امروز همراه من محمد هست.
سلام محمد، چطوری؟

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

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

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

خب محمد، اگه بخوای خودت رو برای مخاطب‌ها معرفی کنی، از کجا شروع می‌کنی؟

ــ من تقریباً از سال ۹۰-۹۱ کار توی حوزه آی‌تی رو به‌صورت جدی‌تر شروع کردم. از اواخر دوران دانشگاه، بیشتر درگیر توسعه محصولات اینترپرایز شدم؛ مثلاً ERP یا سیستم‌هایی برای زنجیره تأمین.
اما همیشه یه چیزی گم بود... همیشه حس می‌کردم خروجی‌هایی که می‌دیم رضایت واقعی مشتری رو تأمین نمی‌کنه.
طرف می‌اومد می‌گفت این بخش رو می‌خوام، اون یکی رو نمی‌خوام... دائم نارضایتی بود.
این موضوع کم‌کم برام تبدیل شد به یه چالش ذهنی: واقعاً چرا؟ دنیا چطوری با این قضیه کنار میاد؟
چی کار می‌کنن که محصولاتشون این‌همه مشتری‌پسند درمیاد؟
از اونجا رفتم سراغ تحقیق و مطالعه، و فهمیدم که رضایت مشتری، اون چیزیه که باید محور باشه، نه مستندسازی زیاد.
بعدش بود که کم‌کم وارد دنیای اسکرام شدم. دوره‌ها رو گذروندم، با آدم‌های مختلفی تعامل داشتم، چه تو ایران، چه خارج از ایران... و الان بیشتر تمرکزم روی مفاهیم عمیق‌تره، مثلاً ترکیب اسکرام و کانبان که بهش می‌گن PSK. در ادامه حتماً راجع بهش صحبت می‌کنیم.

ایول. ببین، برای خود من توی این چند اپیزود قبلی، همیشه یه بخش جالب بوده: اون نقطه‌ای که آدم‌ها به اجایل، به اسکرام یا کمبان می‌رسن.
تقریباً همه یه حلقه‌ی گمشده‌ای رو اشاره می‌کنن که انگار همه‌چی به رضایت مشتری، به تحویل یه بخش کارکن از محصول برمی‌گرده... همون چیزی که بهش می‌گن «Working Software».

خب، حالا که رسیدیم به اینجا، بذار یه سوالی که خیلیا می‌پرسن رو بندازم وسط. می‌گن:
«آقا فرق این مایندست، فریم‌ورک، و متدولوژی چیه؟ یعنی چی اینا؟ کِی کدومش به درد می‌خوره؟»

من معمولاً اینجوری توضیح می‌دم:
مایندست یا طرز فکر، اون فلسفه‌ست، اون باورهای بنیادینی که تو ذهن ما شکل می‌گیره. مثلاً این باور که "مشتری باید در مرکز توجه باشه" یا "همکاری تیمی بهتر از فرماندهیه".

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

بذار یه مثالی بزنم.
مهدی حسینی یه بار گفت:
بازی فوتبال رو در نظر بگیر.
قوانین اصلیش هستن، همگی می‌دونیم بازی چجوریه. اون قوانین حداقلی مثل «توی زمین ۱۱ نفر»، «توپ از خط رد شد گل حسابه»، اینا می‌شن فریم‌ورک.
حالا اگر بیایم بگیم بازیکن حق نداره بیشتر از ۲۰ سانت بپره، یا پاس عرضی باید کمتر از ۱۰ متر باشه، اینا می‌شن محدودیت‌های زیادتر، یعنی می‌ریم به سمت متدولوژی.
یعنی دستمون بسته‌تر می‌شه.

خلاصه، هرچی دست تیم بازتر باشه، فریم‌ورکی‌تره؛ هرچی جزئیات و محدودیت بیشتر بشه، متدولوژیک‌تره.

خب محمد، تو چی فکر می‌کنی؟ چطوری می‌شه این تفاوت رو بهتر شفاف کرد برای بچه‌ها؟

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

مقایسه اسکرام، کانبان و XP، ابزارهای یک طرز فکر

پدرام: خب محمد، حالا که تفاوت مایندست و ابزارها رو گفتیم، بریم سراغ اینکه این ابزارها خودشون چی هستن. مثلاً اسکرام چی می‌گه؟ کانبان چی می‌گه؟ XP چی؟ تفاوتاشون کجاست؟

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

پدرام: دقیقاً. یعنی پدیداری (emergence) تو دل تیم شکل می‌گیره از دل بررسی و انطباق. همون سه ستون معروف: شفافیت، بازرسی، و انطباق.
و خب، اسکرام یه محدودیت زمانی هم داره؛ مثلاً اسپرینت که یه بازه‌ی مشخصه برای ایجاد یه تکه‌محصول.

محمد: حالا کانبان رو اگه بخوایم بگیم، کانبان بیشتر از جنس بصری‌سازیه (visualization).
یعنی چی؟ یعنی کاری کن که جریان کاری‌ت رو ببینی، گلوگاه‌هاش رو بشناسی، بعد با محدود کردن کارهای در حال انجام (WIP)، بهره‌وری رو ببری بالا.
ولی توش محدودیت زمانی مثل اسپرینت نداریم. تمرکز اصلی‌ش روی «جریان» و «زمان انتظار»ه.

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

محمد: آره، بعد XP، یا اکستریم پرگرمینگ، میاد از زاویه‌ی دیگه‌ای وارد می‌شه. اون تمرکزش روی کد زدنه، ولی با یه‌سری اصول که کمک می‌کنن کیفیت و سرعت بالا بره. مثلاً تست‌محور بودن، برنامه‌نویسی دونفری، ریفکتور دائم، انتشار مستمر...

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

محمد: دقیقاً. مثلاً خود من خیلی با PSK کار کردم. PSK یعنی Professional Scrum with Kanban. میاد قدرت برنامه‌ریزی و رویدادهای اسکرام رو می‌گیره، ولی از طرف دیگه، تمرکز کانبان روی «جریان» رو هم بهش اضافه می‌کنه.
وقتی این دو تا رو کنار هم بذاری، تازه شروع می‌کنی به دیدن چیزایی که قبلاً نمی‌دیدی.

پدرام: خب این خیلی مهمه. چون خیلی از تیم‌ها می‌خوان دقیق بدونن کدوم فریم‌ورک بهتره، ولی سؤال این نیست. سؤال اینه که تیم تو الان چه مسئله‌ای داره؟ این ابزار قراره چی رو حل کنه؟
اجایل یعنی حل مسئله، نه پرستش ابزار.

از ابزار تا تفکر، راهی برای حل مسئله نه اجرای نسخه آماده

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

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

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

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

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

محمد: دقیقاً. حالا فرض کن یه تیم داریم که نسبتاً بلوغ داره، با اسکرام هم آشناست، ولی یه چیزی کمه. مثلاً جریان کاری هنوز خوب نیست. این‌جاست که PSK می‌تونه کمک کنه. یا ممکنه تیم توسعه بخواد کیفیت کد و همکاری‌ رو ببره بالا، اون‌جا XP می‌تونه وارد بشه.

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

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

پدرام: دقیقاً. اگه یه تیم، خوب ارتباط بگیره، یاد بگیره، فیدبک بگیره، با مشتری کار کنه، چه با اسکرام، چه با کانبان، چه با هیچی هم باشه، داره اجایل کار می‌کنه. اون اصل قضیه‌ست.

وقتی یک تیم کافی نیست، عبور از مرز تیم واحد

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

محمد: این‌جا دقیقاً جاییه که فریم‌ورکی مثل نکسوس (Nexus) وارد میشه. نکسوس مخصوص موقعیت‌هاییه که مثلاً سه تا تا نه‌تا تیم داریم و همگی روی یک محصول مشترک کار می‌کنن. دیگه چالش فقط تحویل محصول نیست، ادغام کار تیم‌ها، هماهنگی وابستگی‌ها، و هم‌راستاسازی هدف‌ها هم مطرحه.

پدرام: آره، منم تو پروژه‌هایی که چند تیم داشتن، دیدم که بزرگ‌ترین مشکل معمولاً اینه که یکی یه چیزی تحویل می‌ده، اون‌یکی نمی‌تونه استفاده کنه، چون هماهنگ نبودن. نکسوس یه ساختار بالاسری میده که اینا رو با هم قفل می‌کنه، درسته؟

محمد: دقیقاً. مفاهیمی مثل Nexus Integration Team یا Scrum of Scrums برای حل همین مشکلاتن. یا اگه محصولات مختلفی داریم که همه زیر یه سبد یا «Portfolio» هستن، اون‌وقت نیاز به دید سیستمی‌تری داریم، مثلاً SAFe یا LeSS.

پدرام: خب حالا برسیم به یه چیز هیجان‌انگیزتر: PSK یعنی ترکیب Scrum با Kanban. این دیگه خیلی منو جذب کرده چون تمرکز داره روی جریان کاری واقعی. هم کاری که قبل از Sprint شروع میشه، هم کاری که بعد از Sprint ادامه پیدا می‌کنه، نه فقط توی خود Sprint.

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

پدرام: به نظرم یه فرق مهمش با Scrum اینه که فقط روی رویدادها تمرکز نداره، بلکه متریک‌های کانبانی مثل WIP، Cycle Time، Age of Work Item و Flow Efficiency رو هم میاره وسط.

محمد: و این یعنی یه نگاه عمیق‌تر به رفتار تیم با کار، نه فقط رفتار تیم با جلسات.

پیشنهاد کتاب و منبع کاربردی

پدرام: محمد، برای کسی که می‌خواد این تفاوت‌ها و کاربردها رو بهتر بفهمه، کتاب یا منبعی سراغ داری؟

محمد: آره، من چند تا پیشنهاد اساسی دارم:

• When Will It Be Done از Daniel Vacanti – یه کتاب فوق‌العاده برای درک جریان کاری، PSK و متریک‌های کانبان توی محیط واقعی.

• وب‌سایت prokanban.org – پر از منابع رایگان و کاربردی برای Kanban حرفه‌ای.

• Fixing Your Scrum – کتابی با لحن ساده و داستان‌محور که می‌گه اگه اسکرام‌تون درست کار نمی‌کنه، از کجا شروع به اصلاحش کنید.

• Zombie Scrum Survival Guide – خیلی بامزه و واقعی. در مورد اسکرام‌هایی که اسماً اسکرامن ولی واقعاً مرده‌ان!

• The Five Dysfunctions of a Team از پاتریک لنچیونی – کمک می‌کنه بفهمید چرا یه تیم خوب کار نمی‌کنه، حتی اگه ابزارهاش درست باشه.