مدیریت محصول اجایل در خلاصه‌ترین حالت ممکن

این نوشته، ترجمه‌ی متن ویدیویی به همین نام (Agile Product Ownership in a Nutshell) است که توسط هنریک نیبرگ (Henrik Kniberg) سال‌ها قبل منتشر شده. ویدیویی که به نظرم هنوز هم بهترین ویدیو در مورد چرخه توسعه محصول اجایل در اینترنته؛ مختصر و مفید. به تازگی این ویدیو رو دوبله کردم و این متن، متن نسخه فارسیه (که البته جای دیدن ویدیو رو نمی‌گیره).بیاین در مورد توسعه نرم‌افزار اجایل از دید یه Product Owner صحبت کنیم.این «متین»ـه، یه محصول‌بان (Product Owner). چشم‌اندازی از محصول داره که واقعاً عاشقشه. به جزء نمی‌دونه که محصولش قراره چه کاری انجام بده، ولی خوب می‌دونه که چرا داریم می‌سازیمش و چه مشکلی رو و برای چه کسی قراره حل بکنه. دائماً در مورد این چیزها صحبت می‌کنه.این جا ذینفعان رو داریم. آدمایی که قراره سیستم در حال توسعه رو استفاده یا پشتیبانی کنن، یا به هر نحوی ممکنه رو کارشون اثر بگذاره. نظر متین اینه که این آدما عاشق سیستم ما میشن و تمام مدت ازش استفاده می‌کنن.نیازهای ذینفعان به شکل داستان کاربر (User Story) بیان میشه. برای نمونه‌، تو یه سیستم رزرو پرواز، آدم‌ها نیاز دارن بتونن یه پرواز رو جستجو کنند. این یه داستان کاربره. بیشتر مواقع داستان‌ها تقریباً معادل یه ویژگی (Feature) یا یه مورد استفاده (Use case) هستن. ذینفعان ایده‌های بی‌شماری دارن؛ متین بهشون کمک می‌کنه ایده‌هاشون رو به داستان‌های به نسبت متمایز تقسیم کنن.یکی هم باید سیستم رو بسازه. اونا اینجان: تیم کوچیک، کنار هم، خودسازمانده و همه‌فن‌حریف (Cross-functional) توسعه. از اونجایی یه تیم اجایل هستن، کارهاشون رو برای یه انتشار مهیب (Big-bang Release) جمع نمی‌کنن؛ بلکه زود و زیاد (Early and often) خروجی میدن. اونا هر هفته بین ۴-۶ داستان منتشر می‌کنن، و این میشه ظرفیت‌شون (Capacity). اندازه‌گیری‌ش خیلی ساده‌ست: کافیه تعداد داستان‌هایی که هر هفته منتشر می‌شه رو بشمریم. بعضی داستان‌ها بلند هستن و میشه دو تا شمردشون؛ بعضی‌هاشون کوتاه هستن و نصف به حساب میان. سرجمع هفته‌ای حدود ۴-۶ داستان میشه. برای حفظ این سرعت، و برای اینکه تو باتلاق تست رگرسیون دستی گیر نیفتن، روی تست خودکار و Continuous Integration سرمایه‌گذاری زیادی کردن. هر ویژگی، آزمون خودکار قبولی (Automated Acceptance Tests) داره و برای بیشتر کدها، تست قطعه (Unit Test) نوشته شده.مشکل اینه که کلی ذینفع با خواسته‌های متنوع وجود داره که قطعاً محدود به ۴-۶ ایده در هفته نمیشه. ایده‌های بسیار و آرزوهای بلند. هر بار هم که چیزی بهشون تحویل میدیم، ایده‌های بیش‌تری به ذهنشون می‌رسه و چیزهای بیشتری می‌خوان. چه اتفاقی میفته اگه تلاش کنیم هرچیزی از ما خواستن رو براشون انجام بدیم؟ له میشیم! در نظر بگیرین که تیم هر هفته کار روی ده داستان جدید رو شروع کنه. اگر ورودی ۱۰ و خروجی ۴-۶ باشه، بار زیادی رو دوش تیم قرار داده میشه و باعث چندوظیفگی (Multitasking)، بی‌انگیزگی، و در نهایت کاهش خروجی و کیفیت میشه. یه وضعیت باخت-باخت. مثل اینه که تلاش کنین کاغذهای بیشتری توی پرینتر بچپونین تا سریع‌تر چاپ کنه. یا اینکه ماشین‌های بیشتری رو راهی جاده‌هایی کنین که کیپ تا کیپ پرن. بی‌فایده است. این یه قاعده مبنایی در عالمه: اگر ورودی بیشتر از خروجی باشه، ازدحام بیش از حد یا نشتی نصیب‌تون می‌شه.روش اسکرام و XP برای جلوگیری از این مشکل، «آب‌و‌هوای دیروز»ـه. تیم می‌گه «ما تو چند هفته گذشته هفته‌ای ۴-۶ داستان رو انجام می‌دادیم. این هفته کدوم ۴-۶ ویژگی رو باید بسازیم؟». کار محصول‌بان اینه که بفهمه از بین همه داستان‌هایی که در دنیا وجود داره، کدوم ۴-۶ مورد رو باید بعد از این تحویل بدیم؟روش کانبان، اینه که تعداد کار درحال انجام رو محدود کنه. فرض کنین تیم تصمیم میگیره که ۵ عدد بهینه برای تعداد داستان‌هاییه که می‌تونن هم‌زمان پیش ببرن؛ درست به اندازه‌ای که همه مشغول باشن بدون اینکه بهشون فشار بیاد. پس WIP (کادا: کار درحال انجام؟) رو ۵ انتخاب می‌کنن. وقتی کار یه داستان به پایان می‌رسه، یه داستان جدید قبول می‌کنن و اینطوری مطمئن می‌شن هیچ وقت محدودیت ۵ داستان جاری رو نقض نمی‌کنن.هر دو روش خیلی خوب جواب میدن؛ به این معنی که تیم همیشه به اندازه کافی کار داره و می‌تونه به سرعت انجامشون بده.کنترل جریان کار، یه صف تو ورودی تیم ایجاد می‌کنه که اسکرام بهش می‌گه «خرمن کارهای محصول» (Product Backlog). صف باید مدیریت بشه. اگه ذی‌نفعان هر هفته ۱۰ درخواست جدید مطرح کنن و تیم ۴-۶ مورد رو برسونه، صف طولانی و طولانی‌تر میشه. تا به خودتون بیاین، می‌بینین به اندازه ۶ ماه لیست آرزو جمع شده. این یعنی به طور متوسط هر کاری که از تیم خواسته میشه، ۶ ماه بعد تحویل داده میشه. چقدر چابک!فقط یه راه برای متوقف کردن رشد خارج از کنترل صف وجود داره: نه گفتن! این مهم‌ترین کلمه برای یه محصول‌بان به حساب میاد و متین هم هر روز جلوی آینه تمرینش می‌کنه. «بله» گفتن به هر درخواست جدید ساده‌ست؛ به خصوص وقتی فقط قراره بره ته لیست. مهم‌ترین کار یه محصول‌بان اینه که تصمیم بگیره چه چیزی رو قرار نیست بسازه و عواقب این تصمیم رو بپذیره.محصول‌بان تصمیم میگیره که چی وارد بشه و چی دور انداخته بشه. به‌علاوه، ترتیب کارها رو هم تعیین میکنه؛ اینکه چی الآن ساخته بشه و چی بعداً. این کار سختیه. متین هم تنها نیست و با همکاری تیم و ذی‌نفعان انجامش میده.محصول‌بان برای اینکه اولویت‌بندی کنه، باید یه درکی از ارزش هر داستان و اندازه اون داشته باشه. بعضی از داستان‌ها اهمیت خیلی زیادی دارن،‌ بعضی دیگه ویژگی غیرضروری (bonus feature) به حساب میان. بعضی داستان‌ها تو چند ساعت ساخته می‌شن و بعضی دیگه چند ماه زمان می‌برن.حدس می‌زنین چه ارتباطی بین ارزش داستان و اندازه‌ی اون وجود داره؟ درسته؛ هیچی! بزرگتر به معنی بهتر نیست. یه سیستمی که استفاده می‌کنین رو در نظر بگیرین. حاضرم شرط ببندم که می‌تونین حداقل یه ویژگی خیلی ساده توی اون بگین که اهمیت خیلی زیادی داره و هر روز ازش استفاده می‌کنین. و حاضرم شرط ببندم که حداقل یه ویژگی خیلی بزرگ و پیچیده داشته باشه که کاملاً بی‌اهمیته! مثل اون گیره‌ی کاغذی که چند سال پیش توی مایکروسافت آفیس بود.ارزش و اندازه، چیزیه که به متین کمک می‌کنه هوشمندانه اولویت‌بندی کنه. این دو داستان تقریباً هم اندازه هستن، ولی ارزششون متفاوته. پس این یکی رو اول می‌سازیم. اینجا هم دو تا داستان داریم که ارزش یکسانی دارن، ولی اندازه‌شون فرق می‌کنه. پس این یکی رو اول می‌سازیم. بقیه‌شون هم به همین صورت.یه لحظه صبر کن! متین از کجا ارزش داستان رو می‌دونه؟ اندازه‌اش رو از کجا می‌دونه؟ راستش، خبر بد اینه که نمی‌دونه. این یه بازی حدسیه، یه بازی که همه توی اون حضور دارن. متین پیوسته با ذی‌نفعان صحبت می‌کنه تا بفهمه چی براشون ارزشمنده. و با تیم دائم گفتگو می‌کنه تا بفمهه از نظر اونا و به لحاظ سختی پیاده‌سازی، چه کاری بزرگه و چه کاری کوچیک؟ اینها حدس‌های نسبی هستن، نه عددهای دقیق. من نمی‌دونم وزن یه سیب یا یه توت‌فرنگی چقدره، ولی کامل مطمئنم که سیب دست کم پنج برابر بزرگ‌تره، ولی توت فرنگی خوشمزه‌تره؛ لااقل برای من. این تنها چیزیه که متین برای اولویت‌بندی کارها لازم داره. خیلی هم عالی.در آغاز یه پروژه، حدس‌هامون به ناچار افتضاح هستن. ولی مشکلی نداره، بیش‌ترین ارزش در گفتگوهاست تا اعداد. هربار تیم چیزی به کاربران ارائه میده، چیزی یاد می‌گیریم و بهتر می‌تونیم اندازه و ارزش رو حدس بزنیم. به همین خاطر به طور مداوم اولویت‌بندی می‌کنیم و تخمین می‌زنیم. تلاش برای اینکه از ابتدای کار همه‌اش رو درست انجام بدیم احمقانه‌ست، چون درست اون زمان کم‌تر از هر موقع دیگه می‌دونیم. حلقه‌ی بازخورد، دوست ماست.اولویت‌بندی به تنهایی کافی نیست. برای اینکه زود و زیاد خروجی بدیم، لازمه داستان‌ها رو به تکه‌های کوچیک بشکنیم، ترجیحاً فقط چند روز کار برای هر داستان [لازم باشه]. ما چنین قیف قشنگی هم لازم داریم: داستان‌های کوچک و مشخص در جلو و داستان‌های مبهم‌تر در پشت. با انجام این تجزیه به‌هنگام (JIT: Just-in-time) می‌تونیم از تازه‌ترین دریافت‌هامون درباره‌ی محصول و نیازهای کاربر بهره ببریم.به همه‌ی اینایی که در موردشون صحبت کردم، تخمین ارزش و اندازه داستان، اولویت‌بندی، و شکستن کارها، میگن «خرمن‌آرایی» (Backlog Grooming). متین هر چهارشنبه ۱۱-۱۲ کل تیم رو برای خرمن‌آرایی دور هم جمع می‌کنه، گاهی وقتا بعضی ذینفعان رو هم خبر می‌کنه. دستور کار [هر بار] متفاوته؛ بعضی وقت‌ها تمرکز روی تخمینه، بعضی وقت‌ها روی شکستن داستان‌ها، و گاهی هم روی نوشتن ملاک پذیرش یه داستان.امیدوارم متوجه شده باشین «تعامل و گفتگو» درونمایه بحثه. کار محصول‌بان در واقع همه‌اش در مورد تعامله. وقتی از محصول‌بانان باتجربه می‌پرسم که چی برای موفقیت لازمه، معمولاً روی اشتیاق و تعامل تاکید می‌کنن. این اتفاقی نیست که اولین اصل بیانیه اجایل اینه: «افراد و تعاملات مهم‌تر از فرآیندها و ابزارها هستن»وظیفه محصول‌بان این نیست که داستان‌ها رو لقمه حاضر و آماده کنه برای تیم. این یه کار خسته‌کننده و بی‌فایده‌ست. متین در عوض تلاش می‌کنه که همه چشم‌انداز رو درک کنن، تیم درارتباط مستقیم با ذینفعان قرار بگیره، و با تحویل پی‌درپی به کاربران واقعی، مسیر بازخورد کوتاه باشه. با این کار تیم مسئله و نیازمندی رو یادمی‌گیره و می‌تونه مسائل رو به تنهایی سبک-سنگین کنه و تصمیم بگیره؛ و در نتیجه متین می‌تونه روی دورنمای محصول تمرکز کنه.مدیریت محصول اجایل در یک نگاهمتین و تیم لازمه بین بعضی موضوعات تعادل برقرار کنن. بیاین چند مورد رو ببینیم:اوّل از همه، بین انواع گوناگون ارزش تعارض وجود داره.در ابتدای پروژه، دشمنامون ریسک و عدم قطعیت هستن. ریسک کسب‌وکاری داریم: آیا داریم چیز درستی رو می‌سازیم؟ ریسک انسانی داریم: آیا این تیم می‌تونن بسازنش؟ ریسک فنی داریم: آیا این برنامه روی پلتفرمی که می‌خوایم کار می‌کنه؟ آیا مقیاس‌پذیر هست؟ ریسک هزینه و زمان‌بندی داریم: آیا می‌تونیم محصول رو در زمان معقول و با هزینه معقول، به اتمام برسونیم؟دانش، درست مقابل ریسک قرار می‌گیره. به همین خاطر، وقتی عدم قطعیت بالاست، تمرکزمون رو روی جمع‌آوری دانش میذاریم؛ کارهایی مثل پیش‌نمونه‌های رابط کاربری، راه‌حل‌های روشنگرانه (Spike Solutions)، یا آزمایش‌ها. این‌ها برای مشتری چندان جذابیتی ندارن، ولی ارزشمندن؛ چون ریسک رو کاهش می‌دن.از منظر ارزش برای مشتری، در ابتدا منحنی به این شکله [با شیب کم]. با کاهش عدم قطعیت، به مرور بیش‌تر و بیش‌تر روی ارزش‌آفرینی برای مشتری تمرکز می‌کنیم. می‌دونیم که قراره چی و چطوری بسازیم، پس فقط انجامش میدیم! با انجام کارهای با بیشترین ارزش در ابتدا، چنین شیب تند خوبی در منحنی پیدا میشه. و بعد، به مرور منحنی ارزش شروع می‌کنه به تخت شدن. مهم‌ترین چیزها رو ساختیم و حالا داریم قابلیت‌های فرعی (Bonus Features) رو اضافه می‌کنیم؛ مثل تزیینات بستنی! الآن در وضعیت خوبی هستیم. متین و تیم‌ش هرزمان می‌تونن تصمیم بگیرن که کار رو متوقف کنن و برن سراغ یه کار دیگه؛ یه پروژه مهم‌تر، یا یه مجموعه قابلیت جدید به همین محصول اضافه کنن. این همون چابکی کسب‌وکاریه.بنابراین، وقتی صحبت از ارزش می‌کنیم، منظورمون ارزش دانش و ارزش مشتریه. ما باید بین این دو توازن برقرار کنیم.تعارض بعدی، بین تفکر کوتاه‌مدت و بلندمدته. در قدم بعدی چی باید بسازیم؟ اون باگ اورژانسی رو درست کنیم یا این قابلیت جدید که کاربران رو به وجد میاره؟ یا اصلاَ سراغ کار سخت به‌روزرسانی پلتفرم بریم که باعث میشه در آینده توسعه سریع‌تری داشته باشیم؟ باید به طور مدام بین کارهای واکنشی و فعالانه (reactive & proactive) توازن برقرارکنیم، بین پیشگیری از آتش و آتش‌نشانی.این مرتبط با یه تعارض دیگه هم هست. آیا ما باید روی ساختن چیز درست تمرکز کنیم، یا روی درست ساختن چیزها، یا سریع ساختنشون؟ در حالت ایده‌آل دوست داریم هرسه رو با هم داشته باشیم؛ ولی پیدا کردن تعادل کار سختیه.فرض کنین ما اینجاییم [در نقطه اشتراک ساخت چیز درست و درست ساخت چیزها]. تلاش می‌کنیم محصول عالی بسازیم، با یه معماری بی‌نقص. اگر وقت زیادی صرف کامل و بی‌عیب شدن بکنیم، ممکنه بازار رو از دست بدیم یا دچار مشکلات جریان نقدینگی بشیم.یا در نظر بگیرید اینجا باشیم [در نقطه اشتراک ساخت چیز درست و سریع ساختن]، و عجله داشته باشیم نمونه‌های اوّلیه رو تبدیل به محصول قابل استفاده کنیم. احتمالاً برای کوتاه مدّت خیلی خوب باشه، ولی در بلندمدّت در بدهی فنی غرق میشیم و سرعت‌مون به صفر میل میکنه.یا فرض کنین اینجا هستیم [در نقطه اشتراک درست ساخت چیزها و سریع ساختن] و در زمانی مثال‌زدنی، چیز باشکوهی می‌سازیم. فقط کاربرا بهش نیاز ندارن و یه وانت مسافرتی می‌خواستن!اینجا یه تنش سالم بین نقش‌های اسکرام داریم. محصول‌بانان تمایل دارن روی ساخت چیز درست تمرکز کنن، تیم تمایل داره روی درست ساختن چیزها تمرکز کنه، اسکرام‌باشی (Scrum master) و مربی اجایل تمرکزشون روی کوتاه‌تر کردن حلقه بازخورده.باید روی اهمیت سرعت تاکید کنیم. کوتاه کردن حلقه بازخورد، باعث سریع‌تر شدن یادگیری میشه، و سریع‌تر می‌فهمیم چیز درست چیه، و چطور باید درست اون رو ساخت. با این‌حال، هر سه دیدگاه مهم هستن و باید تلاش کنین تعادل رو برقرار کنین.در نهایت، یه تعارض بین توسعه محصول جدید و بهبود محصول قبلی داریم. «کارهای محصول» یا Product Backlog عبارت گمراه‌کننده‌ایه؛ چون به طور ضمنی میگه یه محصول وجود داره. پروژه هم واژه درستی نیست، چون به این معناست که یه زمان پایان برای توسعه داریم. کارهای محصول هیچ وقت واقعاً تموم نمیشه و تا وقتی عمر محصول به سر نرسه و خاموش نشه، کارهایی هست که برای نگهداری و بهبودش انجام بشه.خب، پس کی تیم توسعه یه محصول جدید رو شروع می‌کنه؟ چه بلایی سر محصول قبلی میاد؟ گرفتن یه محصول از یه تیم و دادنش به تیم دیگه، خیلی پرهزینه و ریسکیه. سناریوی متداول‌تر اینه که همون تیم در حالی که محصول جدید رو توسعه میده، از محصول قبلی هم نگهداری کنه. در واقع خرمن کارها، بیشتر از اینکه برای محصول باشه، برای تیمه: Team Backlog؛ چیزی که محصول‌بان انتظار داره تیم بسازه، و می‌تونه مخلوطی از کارهایی برای محصول‌های مختلف باشه. محصول‌بان باید به طور دائم بین این موارد توازن برقرار کنه.گهگداری یکی از ذینفعان متین رو صدا می‌کنه و میگه: «کی کار من تموم میشه؟» یا «چقدر از کار تا سال نو تموم میشه؟» به عنوان محصول‌بان، متین مسئول مدیریت انتظاراته. یا مهم‌تر از اون، مدیریت واقع‌گرایانه انتظارات. یعنی دروغی در کار نیست. می‌دونم، سخته، ولی کی گفته که اجایل ساده‌ست؟!پیش‌بینی کردن کار سختی نیست، تا وقتی که قرار نباشه دقیق باشه. اگر سرعت تیم یا ترکیب سرعت تمام تیم‌هایی که دارید رو اندازه بگیرین، می‌تونین یه نمودار کار انجام شده یا Burnup Chart رسم کنین. این نمودار، تعداد تجمیعی داستان‌هایی که طی زمان به دست کاربر رسیده رو نشون میده. اگر بخواین می‌تونین از Story Point هم استفاده کنین.به تفاوت این دو نمودار [ارزش برای مشتری و کار انجام شده] توجه کنید. این منحنی خروجی رو نشون میده و اون منحنی، دست‌آورد رو. این خروجیه، و اون، دست‌آوردیه که امیدواریم بهش برسیم. هدف ما این نیست که تا جایی که می‌تونیم خروجی تولید کنیم. هدفمون اینه که با کمترین خروجی، به نتایج مطلوب برسیم؛ ذی‌نفعان راضی. کمتر بیشتر است (Less is more).به نمودار نگاه کنین و یه روند خوش‌بینانه و یه روند بدبینانه بکشین. می‌تونین با جادوی آمار انجامش بدین یا به صورت دیداری ترسیمش کنین. فاصله بین این دو خط وابسته به اینه که چقدر سرعت‌تون متغیر و غیرقابل پیش‌بین باشه. این چیزیه که در طول زمان پایدارتر میشه و به دنبال اون زاویه ناشی از عدم قطعیت، تنگ و تنگ‌تر میشه.خب، به مدیریت انتظارات برگردیم.فرض کنین ذینفع می‌پرسه «کی همه‌ی این کارها انجام میشه» یا «کی ما به اینجا می‌رسیم؟» این یه سؤال با دامنه ثابت و زمان متغیره. متین از روندها کمک می‌گیره و میگه: «به احتمال زیاد بین فروردین و اردیبهشت».فرض کنین ذینفع می‌پرسه «چقدر کار تا سال نو انجام میشه؟». این یه سؤال با زمان ثابت و دامنه متغیره. روند انجام کار بهمون میگه «به احتمال زیاد همه این کارها، ‌بعضی از اینا و هیچ کدوم از اینا».حالا فرض کنین می‌پرسن «می‌تونیم این کارها رو تا سال نو انجام بدیم؟» تو این سؤال، زمان و دامنه ثابته. متین یه نگاهی به نمودار می‌کنه و میگه «نه؛ شرمنده! امکان نداره» و در ادامه میگه «این کارهاییه که تا سال نو می‌تونیم انجام بدیم» و «این هم زمانیه که برای کل این کارها لازم داریم».عموماً بهتره که اوّل دامنه رو کوچیک کنیم تا اینکه زمان رو افزایش بدیم. چون با کاهش دامنه در ابتدا، همچنان امکان تمدید زمان و اضافه کردن بقیه کارها وجود داره، در حالی که برعکسش ممکن نیست؛ ما نمی‌تونیم زمان لعنتی رو به عقب برگردونیم. زمان اونجوری خیلی آزاردهنده میشه، مگه نه؟متین انتخاب رو ساده می‌کنه و می‌پرسه: «ما می‌تونیم یه چیزهای رو اینجا بهتون بدیم و بقیه‌اش رو هم بعد. یا اینکه می‌تونیم اینجا هیچی تحویل ندیم و بعداً کلش رو بدیم. کدوم رو ترجیح میدین؟»محاسبات [پیش‌بینی] خیلی ساده‌ست و به همین خاطر متین هر هفته پیش‌بینی رو به روز می‌کنه.چیزی که اینجا خیلی مهمه اینه که متین به جای اینکه خیال‌پردازی کنه، از داده‌های تجربی برای پیش‌بینی استفاده می‌کنه. و در مورد عدم قطعیت روراسته. گفتم دروغی در کار نیست، درسته؟ این راه خیلی صادقانه برای ارتباط با ذینفعانه و اونا معمولاً از این روش استقبال می‌کنن. اگر سازمان‌تون حقیقت و صداقت رو دوست نداره، اجایل رو دوست نداره!یه هشدار هم بدم. اگر تیم در حال انباشت بدهی فنیه، اگر تست نمی‌نویسن و معماری رو دائم بهبود نمیدن، طی زمان کندتر و کندتر میشن و منحنی کار انجام شده تخت میشه. این پیش‌بینی رو تقریباً‌ غیرممکن می‌کنه. تیم مسئول حفظ سرعت پایداره و متین بهشون فشار نمیاره که میانبر بزنن.چی میشه اگه یه پروژه‌ی بزرگتر با چندین تیم داشته باشیم؟ و چندتا محصول‌بان داشته باشیم که هر کدوم خرمن کارهای خودشون رو دارن که برای یه بخشی از محصوله.به طور کلی اینجا هم مدل همونه. ما همچنان نیاز به مدیریت ظرفیت داریم، هنوز هم لازمه با ذینفعان تعامل کنیم، هنوز هم به محصول‌بان‌هایی نیازداریم که می‌تونن نه بگن، هنوز هم باید کارهامون رو سروسامون بدیم. سرعت، جمع خروجی همه است و می‌تونه مبنای پیش‌بینی قرار بگیره. یا اگر به نظرتون منطقی‌تر میاد، می‌تونین پیش‌بینی جداگانه‌ای برای هر تیم داشته باشین.در سناریوی چندتیمه، به محصول‌بان‌ها یه مسئولیت مهم اضافه میشه: باید با همدیگه صحبت کنن! [درسته] ما باید جوری تیم‌ها و کارها رو سامون بدیم که وابستگی‌ها کمینه باشه؛ ولی به هر حالی همیشه مقداری وابستگی وجود داره و به همین خاطر نیازه یه جور هماهنگی بین محصول‌بانها ایجاد بشه تا چیزها رو به ترتیب معقول بسازیم و از غیربهینه بودن پرهیز کنیم. در پروژه‌های بزرگ، برای هماهنگ کردن محصول‌بانان نیازمند یه نقش محصول‌بُد (CPO: Chief Product Officer) هستیم.بالا رفتیم هوا بود،‌ پایین اومدیم زمین بود، قصه‌ی اجایل همین بود!چند نکته در مورد ترجمه:در نسخه انگلیسی، اسم شخصیت اصلی Pat هست که یه اسم بدون جنسیته (و این به نظرم نکته قابل توجهیه). به همین دلیل در نسخه فارسی از «متین» استفاده کردم.به نظرم اجایل (Agile) رو نباید ترجمه کرد چون اسم خاصه و با A بزرگ نوشته میشه. مگر اینکه مثلاً بگیم «روش چابک توسعه نرم‌افزار»برای پرهیز از جدال «PM vs PO»، به جای مدیر محصول واژه‌ی تازه‌ی «محصول‌بان» رو ساختم. اگرچه به نظرم در فارسی میشه حساسیت رو کنار گذاشت و از «مدیر محصول» هم استفاده کرد.از «باشی» به معنی سردسته و سرپرست شغل (در ترکیب با کلمۀ دیگر؛ مثل حکیم‌باشی، منشی‌باشی، فراش‌باشی، آبدارباشی و...) کمک گرفتم و «اسکرام‌باشی» رو ساختم. البته «اسکرام‌سالار» هم جایگزین بدی نیست.از «بُد» به معنی دارنده، صاحب، خداوند (مانند: سپهبد) کمک گرفتم برای ساخت «محصول‌بُد». البته اول در نظرم بود به جای PO استفاده‌اش کنم که با پیشنهاد پویا، نظرم برگشت و شد CPO.به نظرم «آزمون واحد» (و تست واحد) که جایگزین متداول برای Unit Test ـه، جایگزین خوبی نیست. «واحد» در این ترکیب من رو بیش‌تر یاد «یکتا و یگانه» می‌اندازه تا بخش و «قطعه». پیشنهادم «آزمون قطعه» است.بحث در مورد اینکه «حالا چرا باید جایگزین فارسی پیدا کرد؟» مفصله و جاش اینجا نیست. شاید این نوشته کمک کنه به روشن شدن موضوع.