دیگه نوبتی هم باشه، نوبت بررسی داغ‌ترین بحثیه که تو اکثر شرکتا رواج داره؛ این اپیزود پارت اول از مناظره‌ی من و جواده در مورد بهره‌وریه! توی این پارت در مورد تأثیر هدف و تکنولوژی انتخابی بر روی بهره‌وری حرف زدیم.
اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید.
مقدمه و معرفی موضوع بهره‌وری
پدرام:
سلام به همه! من پدرام کشاورزی هستم و این پنجمین قسمت از فصل جدید «اجایل‌گپ»ه.
اگه بخوام یه یادآوری بکنم از هدف این پادکست، باید بگم که ما اینجا جمع شدیم تا بریم سراغ تجربه‌های واقعی‌ای که توی صنعت وجود دارن. می‌خوایم با کمک درس‌آموخته‌هایی که از هر قسمت درمیاد، یه جوری به رشد صنعت کمک کنیم.
خب، با این مقدمه بریم سراغ اپیزود پنجم، که قراره یه نگاه داشته باشیم به فریم‌ورک‌ها و متدولوژی‌ها.
پدرام:
سلام جواد! چطوری؟ خیلی خوش اومدی.
جواد:
عرض سلام دارم خدمت شما و همه مخاطب‌های عزیز. امیدوارم امروز گفت‌وگوی خوبی با هم داشته باشیم.
پدرام:
مرسی که دعوت رو قبول کردی. به نظرم بحث جذابی در پیش داریم، چون قراره بریم وارد فضای تیم بشیم و درباره‌ی فریم‌ورک‌ها و متدولوژی‌ها صحبت کنیم.
قبل از اینکه بریم جلو، لطفاً یه معرفی از خودت داشته باش تا مخاطب‌ها هم بدونن با کی طرفن.
از کجا شروع شد؟ مسیر ورود به دنیای چابکی
جواد:
من اگه بخوام از خودم بگم، از حدود سال ۱۳۹۰ یا ۹۱ بود که کار توی حوزه‌ی IT و برنامه‌نویسی رو جدی‌تر شروع کردم.
اون زمان، توی دوران دانشگاه بودم و کم‌کم وارد پروژه‌هایی شدم که یه مقدار حالت اینترپرایز داشتن. محصولات مختلفی رو توسعه می‌دادیم؛ مثلاً ERP یا سیستم‌هایی که به زنجیره‌ی تأمین مرتبط بودن.
اما همیشه یه چیزی اذیتم می‌کرد:
احساس می‌کردم توی تولید محصولات، یه حلقه‌ی گم‌شده وجود داره.
هیچ‌وقت مشتری‌هامون ۱۰۰ درصد راضی نبودن—حتی شاید نتونم بگم ۵۰ درصد راضی بودن!
همیشه می‌گفتن: "این قسمت خوبه ولی اون یکی رو نمی‌خوام."
این نارضایتی‌ها کم‌کم برام تبدیل شد به یه چالش ذهنی بزرگ.
با خودم می‌گفتم: دنیا چطوری داره انقدر محصول خوب تولید می‌کنه؟ چرا ما نمی‌تونیم رضایت واقعی مشتری رو جلب کنیم؟
اینجا بود که رفتم سراغ مطالعه. حدوداً سه چهار سال پیش بود که فهمیدم اصل ماجرا رضایت مشتریه؛
اما ما انگار اصل ماجرا رو رها کرده بودیم و فقط چسبیده بودیم به مستندسازی، بدون اینکه واقعاً بدونیم چطوری یه محصول خوب بسازیم.
پدرام:
دقیقاً. منم همیشه این قسمتِ داستان رو تو اپیزودهای قبلی دوست داشتم، اینکه چی شد اصلاً فرد به سمت اسکرام یا کمبان اومد.
برای من خیلی جالبه که خیلی‌ها به یه حلقه‌ی گم‌شده رسیدن و بعد رفتن سراغ روش‌های چابک.
و همیشه اون «ورکینگ سافتور» یا همون محصول قابل استفاده که اسلام هم خیلی بهش تأکید می‌کنه، خودش رو نشون داده.
فرق بین «مایندست»، «فریم‌ورک» و «متدولوژی»
پدرام:
ما توی اپیزود قبلی که با «مریم غفوری» صحبت کردیم، وارد دنیای تیم‌ها شدیم و مدل «تاکمن» رو بررسی کردیم.
یه سؤال خیلی پرتکرار اینه که فرق مایندست، فریم‌ورک، و متدولوژی چیه؟
من معمولاً این‌طوری توضیح می‌دم که: مایندست یا طرز فکر، اون باوره—اون فلسفه‌ای که توی ذهن ما شکل گرفته؛ مثلاً می‌گیم: "اگه این بشه، خیلی خوبه!"
اما این فقط توی ذهنه.
فریم‌ورک‌ها و متدولوژی‌ها، در واقع ابزارهایی هستن برای اینکه اون مایندست بیاد روی زمین، اجرایی بشه، لمس بشه.
اگر این ابزارها نباشن، اون باور فقط یه ایده‌ی خوب باقی می‌مونه، اما هیچ‌وقت محقق نمی‌شه.
فریم‌ورک چیه؟ خیلی ساده بگم: یه چهارچوبه با قوانین حداقلی.
مثل فوتبال—همه یه تصویری از قوانین کلیش داریم.
ولی اگه بیایم و بگیم: "اگه بازیکنی بیشتر از ۲۰ سانت بپره، خطاست!"
اون‌وقت داریم محدودیت اضافه می‌کنیم؛
داریم از «فریم‌ورک» میریم سمت «متدولوژی».
پس تفاوت اصلی اینه:
فریم‌ورک = آزادی بیشتر، حداقل قانون
متدولوژی = جزئیات بیشتر، محدودیت بیشتر
مثلاً:
اسکرام و کمبان: فریم‌ورک
XP یا اکس‌پی: متدولوژی
جواد:
آره، دقیقاً. به‌نظرم هرچی بیشتر فضا برای خلاقیت باز بشه، داریم به سمت «فریم‌ورک» میریم؛
هرچی قوانین و جزییات بیشتر بشه، داریم به سمت «متدولوژی» حرکت می‌کنیم.
اما اصل ماجرا اینه که همه‌چی باید با «تجربه کردن» در ناخودآگاه ما جا بیفته.
فقط با مطالعه یا شنیدن نیست. وقتی رفتیم تجربه‌اش کردیم، اون موقع اون مایندسته واقعاً شکل می‌گیره.
در مورد «چابکی» هم همین‌طوره.
طرز تفکر چابک مهمه. ابزارها صرفاً یه وسیله‌ان، نه هدف نهایی.
پدرام:
کاملاً موافقم. حالا این وسط یه سؤال دیگه:
از کجا بفهمیم از چه ابزاری باید استفاده کنیم؟ چرا باید اسکرام یا کمبان یا XP استفاده کنیم؟
اصلاً کی بفهمیم باید این ابزار رو بگذاریم کنار و یکی دیگه برداریم؟
جواد:
اینجا باید بریم سراغ مشکلات کلیدی.
مثلاً:
آیا تحویل محصول خیلی طول می‌کشه؟
آیا برنامه‌ریزی دقیق نداریم؟
آیا مشتری همیشه ناراضیه چون محصول نهایی با چیزی که تو ذهنشه فرق داره؟
آیا توی تیم، افراد با هم درست کار نمی‌کنن؟
یا اصلاً چندتا تیم داریم که به هم وابستن ولی هماهنگ نیستن؟
برای هرکدوم از این مسائل، یه ابزاری وجود داره.
ولی تاکید می‌کنم: این ابزارها «نسخه‌ی از پیش تعیین‌شده» نیستن.
هیچ‌کس نمی‌تونه بگه: "بریم اسکرام، حله!"
باید ببینیم تیم ما، محصول ما، و موقعیت ما چی می‌طلبه.
انتخاب ابزار مناسب با توجه به مسئله
پدرام:
پس یعنی ما باید اول مسئله رو بفهمیم، بعد بریم دنبال ابزار.
نه اینکه از قبل عاشق یه فریم‌ورک بشیم و بخوایم همه‌چیو با اون حل کنیم، درسته؟
جواد:
کاملاً درسته.
خیلی وقت‌ها ما یه مشکلی داریم ولی نمی‌دونیم دقیقاً اون مشکل چیه، واسه همین میریم یه فریم‌ورک می‌گیریم که شاید اصلاً برای مشکل ما طراحی نشده باشه.
مثلاً اگه مشکل ما «وابستگی بین تیم‌ها» باشه، احتمالاً اسکرام جواب نمی‌ده.
اینجا باید بریم سراغ چیزهایی مثل «نکسوس» یا «اسکرام اسکیل‌شده».
پدرام:
یا مثلاً اگه مشکل ما توی برنامه‌ریزی باشه، شاید XP (اکستریم پرگرمینگ) یا اصولی مثل TDD (تست‌محور توسعه دادن) بیشتر به دردمون بخوره.
جواد:
آره دقیقاً. باید ابزار رو متناسب با مشکل انتخاب کرد.
ما نباید به ابزار تعصب داشته باشیم.
اگه امروز کمبان بهم کمک کرد، فردا ممکنه ببینم باید یه تیکه از XP رو هم بیارم کنارش.
این انعطاف و تطبیق‌پذیری خیلی مهمه.
پدرام:
و یه چیزی که من همیشه به تیم‌ها می‌گم اینه که:
فریم‌ورک، ابزار، متدولوژی، همه وسیله‌ان.
اما اگر «هدف» رو گم کنیم، اینا تبدیل می‌شن به بوروکراسی.
جواد:
دقیقاً!
من به تیم‌هام همیشه می‌گم:
به‌جای اینکه بگیم "ما اسکرام هستیم"، بگیم "ما در حال تلاش برای حل فلان مشکل هستیم و فعلاً از اسکرام استفاده می‌کنیم."
این‌جوری وقتی نیاز به تغییر بود، راحت‌تر قبولش می‌کنن.
چون خودشون می‌دونن ابزار ثابت نیست؛ این هدفه که مهمه.
پدرام:
پس یه جورایی باید یه فرهنگ حل مسئله داشته باشیم، نه فرهنگ اجرای فریم‌ورک.
جواد:
آره. و این فرهنگ از مربی (coach)، اسکرام مستر یا لید تیم شروع می‌شه.
اونا باید فضای امن ایجاد کنن تا تیم بتونه ابزارها رو تجربه کنه، اشتباه کنه، اصلاح کنه.
نگاهی به فریم‌ورک‌ها و متدولوژی‌ها
پدرام:
خب حالا که صحبت‌هامون به اینجا رسید، بریم سراغ خود فریم‌ورک‌ها و متدولوژی‌ها.
کدوما رو داریم؟ و هر کدوم چه ویژگی و شخصیتی دارن که می‌تونیم ازشون استفاده کنیم؟
جواد:
اول از همه، بذار از اسکرام شروع کنم چون بیشتر شناخته‌شده‌ست.
تو اسکرام پنج تا رویداد (event) اصلی داریم:
اسپرینت، پلنینگ، دیلی، ریویو و رتروسپکتیو.
همه‌ی اینا حول یک چرخه‌ی تکرارشونده می‌چرخن.
ولی چیزی که مهمه اینه که اینا ابزارن برای بازخورد گرفتن، هم‌راستا شدن و بهبود.
و مهم‌تر از اون، «تعریف هدف اسپرینت»ه.
ما باید بدونیم توی هر اسپرینت داریم تلاش می‌کنیم چه مشکلی رو حل کنیم.
پدرام:
دقیقاً. و چیزی که توی خیلی از تیم‌ها جا می‌افته اینه که فکر می‌کنن چون دارن اسکرام اجرا می‌کنن دیگه نیاز به تغییر ندارن.
درحالی‌که اصل ماجرا تازه از اینجا شروع می‌شه!
جواد:
بله. من همیشه می‌گم که تیم‌های بزرگ ورزشی رو نگاه کن.
تمرین، مرور بازی، بهبود دائمی... اینا رو هیچ‌وقت کنار نمی‌ذارن.
پس چرا ما فکر می‌کنیم وقتی یه مدل داریم، دیگه نیازی به تمرین و بازنگری نیست؟
پدرام:
حرف حساب. خب حالا از اسکرام بیایم بیرون. درباره‌ی «کانبان» چی؟
خیلی‌ها می‌گن که کانبان روونه، ساده‌ست، ولی تو عمل خیلی عمیق و تأثیرگذاره.
جواد:
کاملاً درسته.
کانبان تمرکزش روی تصویرسازی جریان کاره.
یعنی اینکه بدونی کارت از کجا شروع می‌شه، از چه مراحلی رد می‌شه، و چطوری تموم می‌شه.
و از طرف دیگه، اصل «پول سیستم» خیلی مهمه.
یعنی کار به تیم فشار نمیاد، بلکه خودش وقتی ظرفیت داشت کار جدید برمی‌داره.
پدرام:
این باعث می‌شه تیم استرس کمتر داشته باشه، تمرکز بیشتر و در نهایت کیفیت بالاتر.
جواد:
دقیقاً. توی کانبان هم چند تا متریک اصلی داریم:
ویپ (WIP)، لید تایم، توان عملیاتی، و سن آیتم‌ها.
سن آیتم یه متریک ساده‌ست اما خیلی مهمه.
وقتی یه آیتم سنش زیاد شده یعنی یه مشکلی هست:
یا نیاز به تصمیم‌گیری داره، یا به یه نفر خاص وابسته‌ست، یا اصلاً اهمیتش کم شده.
و این‌ها چیزیه که می‌تونه توی روزمره‌ی تیم روشن بشه.
XP و نکسوس؛ برای مسائل خاص‌تر
پدرام:
خب حالا بریم سراغ XP. خیلی‌ها XP رو فقط با جملاتی مثل "تست بنویس"، "جفت‌برنامه‌نویسی کن" می‌شناسن. ولی به نظرم خیلی عمیق‌تر از ایناست. تو چطوری XP رو معرفی می‌کنی؟
جواد:
به‌نظرم XP یکی از رادیکال‌ترین متدولوژی‌هاست، چون خیلی ریشه‌ای به بحث کیفیت، بازخورد، و همکاری نگاه می‌کنه.
توی XP اولویت با کیفیت فنیه. یعنی شما باید دائم در حال Refactor، Test، Integration و Continuous Delivery باشی.
یه جورایی DNA XP، توسعه‌ی پایدار و تیمیِ نرم‌افزاره.
پدرام:
آره، به نظرم XP انگار برای تیم‌هایی طراحی شده که حاضرن خیلی دقیق، خیلی فنی، خیلی منظم و خیلی مسئولانه کار کنن.
جواد:
دقیقاً. XP برای جاهایی خوبه که مسئله‌ی اصلی تیم «کیفیت کد» یا «ریسک فنی» باشه.
ولی مثلاً اگه مشکل اصلی‌ت تعامل تیمیه، شاید XP کمکت نکنه؛ اون‌جا شاید اسکرام یا حتی Liberating Structures بهتر جواب بده.
پدرام:
حالا برسیم به نکسوس. خیلی‌ها نمی‌دونن نکسوس چیه و فکر می‌کنن اسکرام اسکیل‌شده فقط SAFE یا LeSS هست.
درحالی‌که نکسوس یه راه‌حل جمع‌وجور، ولی دقیق برای مقیاس‌پذیریه.
جواد:
آره نکسوس برای وقتی خوبه که چند تیم داری که همه روی یه محصول کار می‌کنن.
توی نکسوس، هماهنگی تیم‌ها و مدیریت وابستگی‌ها خیلی مهمه.
چیزهایی مثل: Nexus Sprint Planning، Nexus Daily، Nexus Integration Team، که کمک می‌کنن تیم‌ها توی یه ریتم مشترک کار کنن.
پدرام:
در واقع نکسوس می‌گه فقط کافی نیست که هر تیم اسکرام خوبی باشه؛ مهم اینه که این تیم‌ها بتونن با هم کار کنن.
جواد:
دقیقاً. چون اگه تیم‌ها با هم هماهنگ نباشن، یه سری تکه‌محصول خوب داری که به‌هم وصل نمی‌شن، و خروجی نهایی مشکل‌دار می‌شه.
نکسوس اومده تا به این هماهنگی کمک کنه، بدون اینکه پیچیدگی فریم‌ورک‌های سنگین‌تر رو داشته باشه.
چالش‌ها، سوءبرداشت‌ها، و نسخه‌پیچی‌های خطرناک
پدرام:
حالا بیایم یه‌کم صادقانه‌تر نگاه کنیم. خیلی وقتا می‌بینم سازمان‌ها صرفاً چون یه‌جایی گفتن "باید اسکرام پیاده بشه"، بدون اینکه بفهمن مسئله‌شون چیه، میرن سراغش.
جواد:
آره این خیلی دردناکه. اسکرام، XP، کانبان، همه‌شون ابزارن. ابزار رو باید برای مسئله انتخاب کرد، نه برعکس.
مثل اینه که تو سردرد داری، ولی بری مسکن معده بخوری چون تبلیغشو زیاد دیدی!
پدرام:
یا این جمله رو خیلی دیدم تو توییتر: «تروخدا ول کنید این اسکرام رو!» بعد توضیح طرفو که می‌خونی می‌بینی آدمای تیم دارن خروجی می‌دن، فیدبک می‌گیرن، دارن با کاربر حرف می‌زنن... یعنی کاملاً دارن چابک عمل می‌کنن، ولی چون اسمش اسکرام نیست، فکر می‌کنن خلاف جریانن!
جواد:
دقیقاً! چابکی یعنی طرز فکر. یعنی اینکه به مشتری گوش بدی، بازخورد بگیری، دائم بهبود بدی، تیم خودگردان باشه، خروجی ملموس بسازی.
حالا اینکه بهش بگی اسکرام یا نگیا، خیلی مهم نیست.
پدرام:
به نظرت از کجا باید بفهمیم چه ابزاری مناسبمونه؟ مثلاً کی بریم سراغ کانبان؟ کی XP؟ کی نکسوس؟
جواد:
پیشنهاد من اینه که اول بشینیم مشکل رو دقیق آبزرو کنیم.
مثلاً:
تحویل خیلی دیر انجام می‌شه؟
فیدبک از مشتری دیر می‌رسه یا اصلاً نمی‌رسه؟
تیم با هم مشکل داره؟
تعامل بین تیم‌ها خرابه؟
نمی‌دونیم اصلاً چی اول باید انجام بشه؟
هرکدوم از اینا می‌تونه راهکار متفاوتی بخواد.
پدرام:
یعنی بر اساس درد، نسخه بپیچیم.
جواد:
دقیقاً. و اینو هم بگم که گاهی لازم نیست یه فریم‌ورک کامل رو اجرا کنیم.
ممکنه فقط یه تیکه از XP مثل Pair Programming یا از کانبان مثل «ویژوال‌سازی جریان کار» به‌تنهایی برات خیلی مؤثر باشه.
ترکیب ابزارها، بهبود جریان کار، و مفهوم «پیشرفته‌تر شدن»
پدرام:
خب جواد جان، تا اینجا راجع‌به ابزارهایی صحبت کردیم که تیم‌های کوچیک می‌تونن استفاده کنن: اسکرام، کانبان، XP.
اما حالا یه‌سوال مهم... اگه تیممون رشد کنه چی؟ اگه چندتا تیم داشته باشیم که باید با هم روی یه محصول بزرگ کار کنن، اون‌وقت چی؟
جواد:
آره، اینجاست که دیگه ابزارهای پایه‌ای کافی نیستن.
مثلاً اسکرام فقط یه تیم رو پوشش می‌ده. ولی وقتی چند تیم داریم که دارن روی یه محصول جامع کار می‌کنن، دیگه ادغام و هم‌راستاسازی خیلی مهم می‌شه.
اینجا مفهومی به اسم نکسوس (Nexus) مطرح می‌شه.
پدرام:
نکسوس چی کار می‌کنه دقیقاً؟
جواد:
نکسوس یه چارچوبه برای هماهنگ کردن چند تیم اسکرام روی یه محصول.
تمرکز اصلیش هم ادغام خروجی‌هاست:
یه نکسوس اینتگریشن تیم داریم که وظیفه‌ش رسیدگی به اینه که کارها به هم بخورن،
یه اسکرام مستر سطح نکسوس داریم،
و یه سری رویداد اضافه برای هم‌راستاسازی تیم‌ها.
پدرام:
حالا یه حالت دیگه هم هست. فرض کن چند تا محصول جدا داریم، ولی همه‌شون زیر یه چتر کلی هستن، مثلاً یه پورتفولیو.
اون موقع چی؟
جواد:
اون حالت متفاوت‌تره.
توی نکسوس، کل تیم‌ها روی یه محصول واحد کار می‌کنن.
ولی توی حالت پورتفولیو، هر محصول می‌تونه جدا عرضه بشه.
مثل یه شرکت نرم‌افزاری که چند تا اپ مختلف داره، ولی همشون به هم ربط دارن یا زیر یه برند واحدن.
پدرام:
خیلی خوب شد که اینو گفتی. چون یه اشتباه رایج اینه که نکسوس رو می‌خوان برای پورتفولیو استفاده کنن، که اصلاً سازگار نیست.
PSK؛ ترکیب اسکرام و کانبان برای تیم‌های بالغ
پدرام:
خب حالا فرض کنیم تیممون به یه بلوغی رسیده.
یعنی چی؟
یعنی دیگه نمی‌خوایم بشینیم بحث کنیم که جلسه پلنینگ یعنی چی، یا دیلی چیه…
اینا رو بلدن.
الان دغدغه‌شون اینه که:
«چطوری جریان کاری رو بهتر کنیم؟
چطوری آیتم‌هامون زودتر تموم بشن؟
چطوری فیدبک سریع‌تر بگیریم؟»
جواد:
دقیقاً.
اینجا مفهومی میاد به اسم PSK – یعنی Professional Scrum with Kanban.
یه جور ترکیب بین اسکرام و کانبان برای تیم‌هایی که دیگه از مرحله مقدماتی رد شدن.
پدرام:
خب PSK دقیقاً چی به تیم اضافه می‌کنه؟
جواد:
PSK تمرکزش روی بهینه‌سازی جریان کاره.
ولی یه نکته مهم:
جریان کار فقط داخل تیم نیست.
دو تا مفهوم مهم داره:
آپ‌استریم (Upstream): یعنی قبل از اینکه تیم شروع کنه به کار
دان‌استریم (Downstream): یعنی بعد از اینکه کار تموم شد، مثلاً تحویل، نگهداری، یا پشتیبانی
پدرام:
یعنی PSK از این دید نگاه می‌کنه که:
«جریان تولید ارزش از کجا شروع می‌شه و کجا تموم می‌شه؟»
نه اینکه فقط بگه «از اسپرینت پلنینگ شروع می‌شه و به ریویو ختم می‌شه.»
جواد:
آره دقیقاً.
PSK کمک می‌کنه ببینیم:
چه آیتم‌هایی سن بالایی دارن؟
چرا یه کار این‌قدر طول کشیده؟
چطوری می‌تونیم lead time رو کم کنیم؟
آیا مشتری برمی‌گرده؟ راضی بوده؟ معرفی کرده به بقیه؟
پدرام:
یعنی PSK بیشتر تمرکزش روی جریان و تجربه‌ی کاربره.
نه صرفاً فرایند.
جواد:
آره. برای همین هم تمرین‌هایی مثل تحلیل سن آیتم‌ها، تعیین WIP، پیگیری سایکل‌تایم و لیدتایم داره.
حتی نمودارهای مخصوص به خودش رو هم داره.
پدرام:
یعنی PSK برای تیم‌هایی خوبه که هنوز اسکرام دارن، ولی می‌خوان کانبان رو هم بیارن وسط برای اینکه بهتر دیده بشن، بهتر تصمیم بگیرن.
چطور بفهمیم کِی از چه ابزاری استفاده کنیم؟
پدرام:
خب حالا بیایم یه قدم عملی‌تر برداریم.
همیشه این سؤال وجود داره که:
«ما از کجا بفهمیم که الان باید از اسکرام استفاده کنیم، یا کانبان یا XP؟»
جواد:
به‌نظرم باید با مشاهده‌ی نشانه‌ها شروع کنیم.
یعنی بشینیم و بپرسیم:
الان مهم‌ترین درد ما چیه؟
اگر تیم داره دائم کار می‌سازه ولی چیزی تحویل نمی‌ده، شاید مشکل توی تعریف «تعریف انجام کار (Definition of Done)» باشه.
اگر کار زیاده و هیچ‌چیز تموم نمی‌شه، شاید باید روی محدودیت WIP کار کنیم.
اگر اعضای تیم انگیزه ندارن، شاید مشکل در خودگردانی و شفافیت باشه.
پدرام:
یا مثلاً اگه چندتا تیم داریم که با هم هماهنگ نیستن، نکسوس یا SAFe می‌تونه مفید باشه.
اگه تیممون تجربه داره ولی سرعت فیدبک کمه، شاید PSK یا مفاهیم کانبان راه‌گشا باشه.
جواد:
دقیقاً. من یه مدلی برای خودم دارم به اسم «تجربه‌محور».
یعنی:
۱. اول مسئله رو تعریف کن.
۲. یه ابزار مناسب با اون انتخاب کن.
۳. یه بازه‌ی زمانی بذار برای امتحانش—مثلاً ۲ اسپرینت.
۴. بازخورد بگیر.
۵. اگه جواب نداد، نترس از تغییرش.
پدرام:
یعنی یه جور مدل چابک برای انتخاب ابزار هم داشته باشیم.
جواد:
آره. ابزار هم یه فرضیه‌ست. باید امتحانش کنیم، اندازه‌گیری کنیم، بازبینی کنیم و انطباق بدیم.
مثل هر چیز دیگه‌ای توی چابک.
پدرام:
و اینجاست که مربی‌گری اهمیت پیدا می‌کنه.
یه مربی خوب باید بلد باشه چطور این تصمیم‌گیری رو تسهیل کنه، نه اینکه نسخه بده.
جواد:
کاملاً درست. مربی نباید بگه «این خوبه، انجامش بده».
باید فضا بده تا تیم خودش به اون درک برسه.
در واقع مربی کمک می‌کنه تیم «خودفهم» بشه، نه «فرمان‌پذیر».
معرفی فریم‌ورک‌ها و متدولوژی‌های رایج
پدرام:
خب بریم سراغ خود فریم‌ورک‌ها و متدولوژی‌ها.
قراره امروز مرور کنیم که چه ابزارهایی در دنیای چابک وجود داره و هرکدوم چه ویژگی‌هایی دارن.
جواد:
بله. اول از همه می‌خوام تأکید کنم که این ابزارها «نسخه آماده» نیستن.
یعنی قرار نیست بری یه جایی و بگی: «ما اسکرام اجرا کردیم، پس موفقیم.»
باید ببینی چی برات مفیده و توی چه بافت و موقعیتی هستی.
🟦 اسکرام (Scrum)
جواد:
اسکرام یه فریم‌ورکه، یعنی حداقل‌ها رو مشخص می‌کنه ولی دستت رو برای طراحی باقی مسیر باز می‌ذاره.
پنج رویداد اصلی داره:
۱. اسپرینت: یک بازه‌ی زمانی ثابت، معمولاً ۲ تا ۴ هفته.
۲. برنامه‌ریزی اسپرینت (Sprint Planning)
۳. جلسه روزانه (Daily Scrum)
۴. بازبینی اسپرینت (Sprint Review)
۵. بازاندیشی اسپرینت (Sprint Retrospective)
در کنارش هم سه نقش اصلی داره:
مالک محصول (Product Owner)
تیم توسعه (Developers)
اسکرام مستر (Scrum Master)
هدف اصلیش: تولید محصول قابل استفاده در پایان هر اسپرینت با دریافت بازخورد سریع.
🟨 کانبان (Kanban)
جواد:
کانبان برخلاف اسکرام، خیلی ساختار رسمی نداره. بیشتر روی «جریان کار» تمرکز می‌کنه.
سه مفهوم کلیدی داره:
بصری‌سازی جریان کار (Workflow Visualization):
یعنی بدونی از لحظه‌ای که یه کار شروع می‌شه تا وقتی تموم می‌شه، چه مراحلی داره.سیستم کششی (Pull System):
هیچ‌کس کاری بهت نمی‌ده. خودت وقتی آماده‌ای، از توی بک‌لاگ کار می‌کشی.محدودیت کار در حال انجام (WIP Limit):
یعنی نمی‌ذاری هم‌زمان روی چندتا کار کار کنی. تمرکز، بهره‌وری میاره.
همچنین کانبان چندتا متریک کلیدی داره:
WIP (کارهای در حال انجام)
Cycle Time (زمان انجام یک کار)
Throughput (خروجی تیم در یک بازه زمانی)
Age of Work Item (سن آیتم کاری که هنوز تموم نشده)
🟪 اکس‌پی (XP – Extreme Programming)
جواد:
ایکس‌پی بیشتر مناسب تیم‌های نرم‌افزاریه که می‌خوان کیفیت کد و تعاملشون بالا بره.
چند تا اصل مهم داره:
برنامه‌نویسی دوتایی (Pair Programming)
تست‌نویسی پیش از توسعه (TDD)
انتشار مداوم (Continuous Integration)
داشتن ریتم پایدار توسعه
داشتن مشتری در کنار تیم
همه‌ی اینا برای اینه که فیدبک سریع بگیری و خطا رو زودتر بفهمی.
🟧 نکسوس (Nexus)
جواد:
نکسوس زمانی کاربرد داره که چند تیم اسکرام دارن روی یک محصول کار می‌کنن.
مثلاً ۳ تا ۹ تیم.
تمرکزش روی «یکپارچه‌سازی خروجی تیم‌ها» و «کاهش وابستگی» بین تیمت‌هاست.
مفاهیم جدیدی به اسکرام اضافه می‌کنه، مثل:
Nexus Integration Team
Nexus Daily Scrum
Nexus Sprint Backlog
🟫 اسکرام حرفه‌ای با کانبان (PSK)
جواد:
یه ترکیب بین اسکرام و کانبانه.
یعنی ساختار اسکرام رو داری ولی با مفاهیم کانبانی داری جریان کاری رو بهبود می‌دی.
مثلاً از متریک‌های کانبان برای اندازه‌گیری و بهبود استفاده می‌کنی.
در کنارش به مفاهیمی مثل آپ‌استریم و دان‌استریم هم توجه می‌کنی—یعنی قبل و بعد از کار تیم توسعه.
پدرام:
یعنی اگه خلاصه کنیم، می‌تونیم بگیم:
اسکرام: ساختار مشخص برای تیم‌های کوچیک
کانبان: مناسب بهبود جریان کار
XP: برای بالا بردن کیفیت توسعه نرم‌افزار
نکسوس: برای هم‌راستاسازی تیم‌های زیاد روی یک محصول
PSK: برای تیم‌هایی که اسکرام اجرا می‌کنن ولی می‌خوان جریان کارشونو عمیق‌تر بهبود بدن
درسته؟
جواد:
دقیقاً همین‌طوره.
تصمیم‌گیری در دنیای واقعی و جمع‌بندی
پدرام:
خب حالا بیایم یه قدم دیگه برداریم.
فرض کن یه شرکت چندتا تیم داره که هر کدوم دارن روی یه محصول کار می‌کنن.
دیگه فقط مسئله‌ی یک تیم یا یک محصول نیست.
اینجا چیکار باید بکنیم؟
با کدوم ابزار می‌تونیم به کل سیستم نگاه کنیم؟
جواد:
تو این شرایط، اول از همه باید بفهمیم که آیا این محصولات به هم مرتبط هستن یا مستقلن.
اگه محصولات مستقلن، هر تیم می‌تونه با روش خودش کار کنه.
ولی اگه محصولات به هم وابسته‌ان، باید یه نگاه سیستمی داشته باشیم.
پدرام:
یعنی مثل پورتفولیو منیجمنت.
جواد:
دقیقاً.
مثلاً یه بانک رو در نظر بگیر که چندین محصول دیجیتال داره: موبایل‌بنکینگ، سامانه‌ی وام، کیف پول دیجیتال...
اینا ممکنه توسط تیم‌های جدا ساخته بشن، ولی یه جاهایی به هم برخورد می‌کنن.
اینجا باید بدونیم کجاها نیاز به هم‌راستاسازی داریم.
پدرام:
و خب اینجاست که دیگه صرفاً داشتن اسکرام مستر یا اسپرینت پلنینگ جواب نمی‌ده.
جواد:
آره. توی این فضاها نیاز به چیزایی مثل OKR، استراتژی پورتفولیو، و ساختارهای مقیاس‌پذیر داریم.
ولی باز هم اصل داستان همونه:
مسئله رو درست بشناس
ابزار متناسب انتخاب کن
بازخورد بگیر
بهبود بده
جمع‌بندی نهایی
پدرام:
بیایم خلاصه کنیم.
ما امروز درباره‌ی چی حرف زدیم؟
راجع‌به اینکه:
هیچ فریم‌ورک یا متدولوژی‌ای قرار نیست معجزه کنه.
باید ببینیم مسئله‌مون چیه، بعد ابزار مناسب رو انتخاب کنیم.
اسکرام، کانبان، XP، نکسوس، PSK هرکدوم یه «کاراکتر» دارن.
بعضی وقت‌ها فقط به یه بخش از یه ابزار نیاز داریم، نه کلش.
انتخاب ابزار هم خودش یه فرایند چابکه: آزمایش، بازبینی، تطبیق.
و در نهایت، مربی‌گری یعنی کمک به تیم برای «خودفهمی»؛ نه «تحمیل نسخه».
جواد:
دقیقاً.
و من اینو به همه‌ی تیم‌هایی که باهاشون کار کردم می‌گم:
«قرار نیست همه‌چی رو بدونی، ولی قراره یاد بگیری. قراره سؤالات خوب بپرسی، آزمایش کنی، اشتباه کنی و یاد بگیری.»
این یعنی چابکی واقعی.
پدرام:
مرسی جواد عزیز بابت گفت‌وگوی ارزشمند و دقیق.
خیلی خوش گذشت.
جواد:
منم ممنونم از دعوتت. امیدوارم براتون مفید بوده باشه.
